Standardisation d'un flow
| Présentation et définition du projet
Voici mon plus gros projet informatique, celui-ci a débuté lors de mon cursus d’alternance BAC+3 à l’école DevUniversity. Ce cursus m’a permis de préparer et d’obtenir deux diplômes: “Adminstrateur Système Devops” qui est un titre RNCP Niveau 6 et “Ingénieur DevOps” qui est un titre de formation continue délivré par l’Université Paris Sorbonne. Ce projet a duré 3 ans et s’est terminé lors de mon alternance durant laquelle je prépare le diplôme RNCP Niveau 7 “Expert en ingénierie du logiciel”.
Le travail que je vais vous présenter correspond à la mise en conformité d’un flow complet d’outils.
Notre équipe est en charge du développement et du maintien de tous les outils du flow qui sont lancés par des clients. Les clients sont différents collaborateurs internes qui utilisent tous ce flow standard. Des produits sont traités par ce flow, et chaque produit peut être traité plusieurs fois dans le temps.
Le problème était qu’une équipe de collaborateurs internes utilisaient auparavant un flow spécifique et peu automatisé. Tous les produits qui avaient été traités via cet ancien flow ne pouvaient pas être techniquement traités sur le flow standard.
L’entreprise a donc décidé de mettre en place un projet de mise en conformité de l’historique des produits générés par l’ancien flow afin de le rendre obsolète.
Pour faciliter la compréhension du reste de la présentation de ce projet, je renomme le flow standard : FLOW_STANDARD et l’ancien flow historique : FLOW_SPECIFIQUE.
| Contexte
Ce projet est d’une grande envergure et s’est pratiquement déroulé de façon simultanée avec une migration complète des outils internes vers le Cloud Azure. Cette migration a occupé une bande passante conséquente à toute l’équipe. Mon équipe est essentiellement constituée de développeurs, d’un chef de projet et d’un Product Owner.
L’architecte du FLOW_STANDARD m’a épaulé et aidé tout au long du projet. J’ai aussi effectué des points hebdomadaires avec mon tuteur entreprise qui s’assure du pilotage et du bon déroulement du projet.
Ce sujet m’a demandé de travailler beaucoup en autonomie et a nécessité une analyse approfondie du FLOW_STANDARD. J’ai découvert à travers ce travail le langage Perl que je ne connaissais pas auparavant. Cela m’a demandé beaucoup de travail pour monter en compétences sur ce langage afin de manipuler les librairies internes.
Concernant les utilisateurs, ce sujet était attendu depuis de nombreuses années et certains éprouvaient une frustration de continuer à utiliser le FLOW_SPECIFIQUE qui nécessitait beaucoup d’actions manuelles.
| Objectifs
Le premier objectif était de développer une solution automatisée permettant une mise en conformité de l’historique des commandes effectuée via le FLOW_SPECIFIQUE. Concrétement, le but était donc de développer une automation permettant le traitement de l’historique d’un produit afin de le rendre compatible et de pouvoir le lancer sur le FLOW_STANDARD.
Le second objectif était d’utiliser les librairies métiers de notre équipe pour développer la solution automatisée. Nos outils sont essentiellement codés en langage Perl et Python. Nous avons des librairies spécifiques qui permettent de manipuler tous les aspects métiers. La solution de mise en conformité devait donc utiliser ces librairies.
| Enjeux
Mise en conformité
L’historique des données des produits traités sur le FLOW_SPECIFIQUE n’était pas cohérent et on observait de nombreuses disparités. La nouvelle solution devait pourtant être à la fois automatisable mais aussi flexible afin de gérer tous les cas spécifiques de disparités.
Mise en obsolescence de la base de données du FLOW_SPECIFIQUE
La réalisation de ce projet avait aussi pour grand intérêt de rendre obsolète une base de données Ingress (version ancienne) dont les coûts de licence et de maintenance étaient élevés dans le Cloud.
Mise en obsolescence des outils du FLOW_SPECIFIQUE
Ce projet allait permettre de rendre obsolète de nombreux outils rédigés en Perl, bash et TCL. Ce point permet d’alléger le perimètre des outils à maintenir.
| Risques
Ce projet présentait un risque majeur lié à sa complexité métier et historique. Malgré une étude de faisabilité, cela nous ne a pas permis d’exclure le risque ne pas arriver à couvrir de manière automatique la mise en conformité de toutes les disparités de l’historique des données du FLOW_SPECIFIQUE. Ce risque a un fort impact sans être bloquant car les utilisateurs savent réaliser un flow complètement manuel. Cependant, cela serait très long et non souhaitable et il faudrait dans tous les cas trouver des solutions intermédiaires si il y a des disparités ne pouvant pas être automatisées.
| Etapes du projet
Recueil du besoin et élaboration de spécification techniques
Après que le Product Owner ait recueilli le besoin client, le projet a débuté par une phase de faisabilité et d’élaboration de spécifications techniques. Celles-ci ont été réalisées par l’architecte du FLOW_STANDARD, un développeur et moi-même.
Gestion d’une contrainte
Après analyse de faisabilité, nous avons mis en évidence des disparités de cohérence des données historiques liées aux produits traités sur le FLOW_SPECIFIQUE. Ces disparités causées généralement par des cas spécifiques traités manuellement ne permettent pas un flow complètement automatisable.
Afin de répondre à cette contrainte, il a été conclu avec le client de recréer le meilleur historique possible basé sur de nombreux critères sous forme d’un fichier .json. La solution devient alors une solution semi-automatique avec intervention humaine pendant son éxecution. Concrétement, l’automation doit générer un fichier .json comprenant toutes les informations liées à l’historique, s’arrêter, puis attendre que le client apporte les modifications nécessaires afin de reproduire la cohérence de l’historique. Une fois le fichier modifié, l’automation doit reprendre et continuer le traitement.
Pour répondre au besoin général et à cette contrainte, nous avons sélectionné l’outil Jenkins qui existait déjà dans l’équipe. Avant de choisir l’outil, j’ai effectué un POC (Proof of Concept) sur la possibilité de stopper l’automation et de mettre à disposition un fichier .json que les utilisateurs puissent directement le modifier dans l’interface. Je ferais un retour après expérience du choix de cet outil dans la « Mon regard critique ».
Démarrage de la réalisation
Un développeur de mon équipe m’a aidé à réaliser le début du projet en m’aidant dans la réalisation de la première étape de la solution qui consistait à extraire les données depuis la base de données du FLOW_SPECIFIQUE afin de générer le fichier .json qui sera ensuite modifier par les clients. Cette première étape d’automation est réalisé à partir d’un script Perl.
Cette aide était orientée fonctionnelle et m’a permis de m’assurer que je développe un code qui extrait bien toutes les données qui vont être nécessaires à la suite de l’automation. Ce travail m’a permis de collaborer avec un collègue expérimenté et d’apprendre des notions du language Perl.
Réalisation
J’ai ensuite travaillé sur ce sujet pendant une période de 3 ans avec plus ou moins des interruptions et une utilisation de ma bande passante à hauteur d’environ 50%.
Nous avons dans l’équipe des outils rédigés en Perl et en Python. La majorité des outils sont en langage Perl, mais il y a une volonté à vouloir les uniformiser avec le langage Python.
Les librairies métiers sont beaucoup plus complètes en langage Perl et il a été défini que je code la première partie de cette solution en langage Perl pour cette raison.
J’ai rédigé la deuxième partie de la solution automatisée en Python car elle n’était pas concernée pas des aspects métiers.
1 ère partie: Récupération des données historiques et correction des disparités
Tout d’abord, j’ai créé un répertoire versionné avec Subversion (outil utilisé par mon équipe) regroupant quatre scripts Perl. Le premier script est celui abordé précédemment qui extrait les informations depuis la base de données du FLOW_SPECIFIQUE et créé un fichier .json.
Ensuite j’ai rédigé 3 autres scripts qui vont mettre en conformité les données historiques de façon cohérente dans le fichier .json. Ceux sont des traitements purement métiers. C’est à ce moment là que la solution devait s’arrêter pour permettre une intervention humaine qui va s ‘assurer de la cohérence de l’historique des données dans le fichier .json.
2 ème partie: Mise en conformité des données dans l’environnement
J’ai ensuite créé un autre répertoire versionné regroupant aussi quatre scripts Python qui vont constituer la deuxième partie de l’automation. Cette deuxième partie permet d’effectuer de nombreuses actions à partir du fichier .json.
En effet, dans cette partie, le .json est définitif. Les scripts de la deuxième partie vont se servir de ce fichier .json pour appliquer des actions de mise en conformité dans l’environnement. Concrètement, plusieurs fichiers vont être créés/modifiés et des données en base de données vont être insérées afin d’émuler un historique cohérent et permettre d’utiliser le FLOW_STANDARD sur ces produits réalisés auparavant sur le FLOW_SPECIFIQUE.
Pipeline Jenkins
Une fois tous les scripts développés, j’ai créé un pipeline Jenkins permettant de les lancer successivement avec une interruption entre la partie 1 et 2 permettant une intervention humaine et potentiellement des modifications du fichier .json.
Phase de QA
Une fois les développements terminés, une phase de QA a démarré où les utilisateurs voulaient tester de réaliser le FLOW_STANDARD après avoir lancé cet automation de mise en conformité. Les utilisateurs ont sélectionné 6 cas de tests et cette phase a duré 3 mois.
Techniquement, j’ai mis en place un pipeline Jenkins « pointant » sur l’environnement de QA afin de proposer aux utilisateurs un test complet dans un environnement isolé.
Ma manager m’a demandé que je m’assure que cette phase de QA se déroule dans de bonnes conditions. Pour cela, elle m’a demandé de mettre en place une réunion hebdomadaire avec des personnes de mon équipe et parfois les clients. Elle m’a demandé aussi de tracer et suivre les actions à mener de notre côté pour s’assurer que cette phase se déroule bien.
J’ai aussi été en charge du support pendant la totalité de cette phase. A la suite de cette phase, j’ai mis en production tous les nouveaux outils ainsi qu’un pipeline Jenkins dédiée à l’activité de production.
| Les acteurs
Concernant les acteurs, ce projet m’a demandé de travailler avec deux collègues de mon équipe et des clients qui sont une autre équipe de l’entreprise. Les interactions ont été exclusivement à distance car l’équipe cliente est située dans un autre site de production en France.
J’ai réalisé de nombreuses réunions avec les clients afin de faire un point sur l’avancée du travail en cours. Ce projet m’a appris l’importance de bien échanger avec les clients. Il m’a aussi appris à adapter ma communication en fonction de mon interlocuteur. En effet, je devais parfois adapter ma rhétorique pour la rendre uniquement fonctionnelle (auprès des clients), et parfois la rendre à la fois technique et fonctionnelle (auprès de mon équipe, du management et du Scrum Master).
| Les résultats
Ce projet était désiré depuis de nombreuses années mais aucune ressource n’avait été mobilisée pour le mettre en œuvre. Depuis Mars 2026, tous les anciens produits ayant auparavant été traités sur le FLOW_SPECIFIQUE peuvent à présent être utilisés dans le flow standard. La base de données qui était associée au FLOW_SPECIFIQUE a pu être supprimée.
Les huit scripts représentent un total de X lignes de code.
| Les lendemains du projet
Les utilisateurs m’ont fait part de leur satisfaction de ne plus avoir à utiliser le FLOW_SPECIFIQUE qui nécessitait beaucoup d’actions manuelles. Quelques demandes additionnelles ont été faites par les utilisateurs pour améliorer encore le confort d’utilisation de ces nouveaux outils.
Ces petites demandes additionnelles ont été receptionées et priorisées, mais pour l’instant aucun développement n’a débuté.
| Mon regard critique
Ce projet a été pour moi très enrichissant autant sur le plan technique qu’ humain. En effet, ce travail m’a permis de progresser dans le développement logiciel. Cela a été moi un travail conséquent car je devais produire une solution dans un environnement existant et arriver à automatiser un historique complexe.
Je devais respecter le bon usage des librairies internes. J’ai même été amené à modifier ou ajouter une nouvelle fonctionnalité dans ces librairies. Je trouve cela très enrichissant de pouvoir avoir pu travailler et manipuler des librairies de différents niveaux.
Au niveau humain, ce projet m’a permis de travailler mon sens de communication et coordonner un cycle de vie du déploiement d’une application (QA).
C’est la première fois que j’ai dû mener un projet de cette envergure et je note néanmoins quelques axes d’amélioration. Tout d’abord, je pense qu’on aurait dû privilégier un outil moteur de flow au lieu de Jenkins, car sa fonction primaire est le déploiement d’outil et non l’orchestration de flow. Ensuite, malgré le fait qu’il y ait eu de nombreux échanges avec les clients, il y a une fois une incompréhension. Cela m’a appris que écrire et partager les points importants par email après une réunion permet parfois de s’assurer que tout le monde est aligné dans la compréhension des échanges.