Lors de mes trois années d’apprentissage, j’ai rejoint une équipe Agile Scrum avec de nombreux profils métier : développeurs, architectes, IVVQ, UX/UI Designer, Scrum Master, Product Owner (PO), Product Manager (PM)… Nous côtoyions quotidiennement différentes autres équipes, ainsi que les plateformes de maintenance et de test. C’est pourquoi le service était également organisé en Lean SAFe. Ma première année m’a donc permis de participer et de m’accoutumer aux diverses cérémonies Agile.
Durant cette même période, j’ai pu observer l’ensemble du processus de développement : de la découpe du Backlog, à l’assignation des story et leur suivi régulier en daily/stand-up, jusqu’à leur présentation au PO après leur passage à « Done« . J’ai constaté des stratégies de tests sur différents niveaux afin d’assurer le bon déroulement et la non-régression du code à l’ajout de toute nouvelle fonctionnalité au produit. Puis leur passage en CI/CD jusqu’à leur mise en production.
Enfin, j’ai pu me rendre compte de la complexité du produit développé par l’équipe, par la compréhension du besoin et du contexte dans lequel il est utilisé. J’ai alors compris la force de la coopération entre les différents corps de métiers pour mener à bien ce projet de grande envergure.
NB : Pour des raisons de confidentialité, je ne pourrai pas montrer beaucoup d’illustrations précises de mon travail.
Le produit sur lequel j’ai travaillé est un produit Naval. Il s’agit d’un système de gestion de communications à l’intérieur et vers l’extérieur d’un navire.
Mes missions ont été :
1. L’ajout d’une interface pour une nouvelle fonctionnalité
2. La mise à jour de contrats JAVA
3. La modification de différents types de tests
Pour entraîner les marins à établir des communications, il leur faut une interface dédiée. Sa réalisation a été ma première mission.
Pour cela, j’ai d’abord appris en pair-programming à utiliser le framework Angular. À l’aide de Bootstrap et ses Web Toolkit, et par la réutilisation de composants HTML, CSS, JS « maisons », j’ai suivi la maquette de l’interface, réalisée sous Adobe XD par l’UX/UI Designer, pour développer la nouvelle page afin de respecter la charte graphique du progiciel.
Les liens entre le Front-End et le Back-End ont été effectués via des API codées en JAVA dans le Back et appelées en TypeScript dans le Front.
Tous mes développements ont été versionnés sous git. Mes collègues m’ont fait ma première revue de code, et une fois validé par le PO, ma branche git locale a été mergée à une branche plus importante encore en cours de développement. Le code a ensuite été testé, mais pas par moi, puis intégré via Jenkins.
Lors de la démo de sprint, le PM a été satisfait de cette nouvelle interface. Mission accomplie !
Dans le Back-End, il y a un projet pour chaque type et modèle d’appareil utilisé dans une communication. Une communication peut, par exemple, nécessiter cette suite d’appareils :
Enregistreur vocal > Appareil de chiffrement > Switch > Radio HF > Antenne HF
Sur plus d’une dizaine de projets différents, je devais alors modifier des contrats de Business Object.
J’ai eu des difficultés sur cette mission, et après plusieurs contrats modifiés, il m’a été demandé de passer à ma dernière mission.
Avec le recul, je peux analyser ce qu’il s’est mal passé :
1) Sortant fraîchement de mon BTS, je ne maîtrisais pas les notions de contrat JAVA, ni celles de Business Object. J’avais déjà lancé des tests jUnit mais très peu. Je n’avais aucune connaissance de Maven, ni de ce qu’était un Nexus. Du coup, je me suis mise une pression folle en me disant que si l’on me confiait cette mission, c’était parce que mon maître de stage était sûr que je pouvais me débrouiller seule pour la mener à bien.
2) Même après une explication théorique, j’avais beau avoir le code sous les yeux, je n’y comprenais pas grand-chose. J’aurais dû demander à mon maître de stage de prendre davantage de temps avec moi pour qu’il me montre, dans le code, ce qui était vraiment attendu et pourquoi pas faire du pair-programming avant de me lancer seule.
3) Une fois modifié en local, je lançais les tests jUnit déjà mis en place pour ne pas créer de régression de code. Cependant, le plus souvent, des tests étaient désormais en erreur. J’ai perdu énormément de temps avec cela. Aujourd’hui, je sais que cela peut être causé par diverses sources :
pom.xml n’est plus à jour
Je sais maintenant que je peux prendre le temps nécessaire pour comprendre un sujet et n’ai plus peur de demander de l’aide en cas de besoin. Je ressors grandie de cet échec et sais dorénavant quoi faire pour éviter de reproduire ces erreurs.
Cette dernière mission signe aussi la fin de ma première année d’apprentissage, elle était donc bien plus courte que les autres : j’ai eu pour story la modification de tests Front-End pour correspondre à la mise à jour d’anciennes interfaces.
Pour cela, je me suis légèrement formée à l’utilisation de Robot Framework et de Selenium IDE que je ne connaissais pas.
Robot Framework est un framework de test qui nous a permis d’automatiser une série de tests fonctionnels et qui utilise une syntaxe très lisible, car très proche du langage humain. Pratique pour une débutante comme moi !
Selenium IDE est installé dans les extensions du navigateur (Chrome ou Firefox). Grâce à cet outil, différents cas d’usage avaient été enregistrés précédemment, directement sur l’interface web du logiciel via le navigateur. Un « cas d’usage » correspond par exemple à une série de clics sur des boutons et à de la saisie de texte dans des champs de formulaire. Ce déroulement d’interactions humaines avec l’interface est alors rejoué ensuite automatiquement par la machine. Après une mise à jour des interfaces, ce genre de test est véritablement pratique pour vérifier la continuité du bon fonctionnement des pages. Les tests remontent des erreurs lorsque des interactions avec des composants disparaissent. Cela nous permet de vérifier à nouveau les modifications et de corriger le test en accord avec la nouvelle interface.
Les modifications étaient certes mineures mais correspondaient à l’attendu. Mission réussie !
Ne soyez pas effrayé ! Ce projet sur lequel j’ai passé les deux années suivantes de mon apprentissage peut avoir l’air compliqué mais je vous assure qu’il ne l’est pas tant.
En plus, il apportait de la valeur ajoutée au produit tout en aidant les différentes équipes !
En fonction des besoins client, leurs navires seront équipés d’appareils différents. Selon cet appareillage, le client a donc la possibilité d’utiliser diverses solutions développées par Thales, chacune gérant des lots spécifiques d’appareils. Du point de vue du développement, au sein de l’entreprise, chacune de ces solutions est portée par une équipe de développement dédiée qui devra donc configurer le lot d’appareils géré par leur solution.
Le produit de mon équipe – le système de gestion des communications – nécessite d’avoir la main sur l’ensemble de ces appareils. Il utilise donc un fichier comportant toutes les configurations de l’ensemble des appareils. Ce dernier est produit en se s’appuyant sur ceux des autres équipes, puisqu’il faut que toutes les solutions puissent fonctionner ensemble mais cela créer de nombreux problèmes.
En effet, si une configuration utilisée en amont est modifiée entre-temps alors la dernière solution comporte des erreurs puisqu’elle n’est plus à jour. Cela est amplifié par le fait que ces fichiers de configurations changent constamment de support : Word, puis duplication et modifications vers un Visio, puis rebelote vers un Excel. Il y a donc plus de stress dans les équipes, de la perte de temps et donc d’argent pour l’entreprise.
Pour y remédier, il faudrait par exemple n’avoir plus qu’un seul référentiel sur disons… un seul outil ?
Ha ha ! Vous me voyez venir ☺ Oui, c’est là où mon projet intervient !
Capella MBSE est une solution open source très complète et puissante pour l’ingénierie des systèmes basée sur des modèles (en gros ça veut dire que tout ce qu’on peut programmer peut être représenté sous forme de schémas). En voilà quelques exemples, à droite.
Capella est intéressant pour le projet car : il est déjà utilisé dans l’entreprise, il offre une IHM où l’on peut représenter une configuration et est capable de générer des fichiers.
Il faudrait préparer Capella pour en faire un outil maintenable et simple d’utilisation pour toutes les équipes.
Il s’agissait donc en réalité d’un POC (Preuve de Concept) pour examiner la faisabilité de ce nouvel outil. Nous avons jalonné le développement de l’outil ainsi :
J'ai créé un projet en ligne dédié à mon outil et Capella peut effectivement être versionné sous git, donc la possibilité de revenir sur des versions antérieures de configurations ou d'en faire des copies altérées est tout à fait possible. Je commence à rédiger la documentation de l'outil en la versionnant elle aussi.
Il n'y a pas de tutoriels vidéo pour prendre facilement en main Capella. Je suis alors une petite formation avec une étude de cas sur le logiciel, je fais de la veille en m'informant sur des forums spécialisés et teste des plugins pour rendre la saisie plus simple. Je m'arrête sur les plugins PVMT (Property Values Management Tools) pour faciliter la saisie et Python4Capella actuellement en développement pour la génération de fichier directement depuis Capella.
À la place des cases colorées par défaut des schémas de Capella, je peux mettre des photos des équipements ! Ce sera ainsi beaucoup plus parlant pour les équipes qui doivent configurer les appareils réels, non ? J'utilise le plugin PVMT et je préremplis pour chaque appareil ses différentes propriétés pour faire gagner du temps aux futurs utilisateurs lors de la saisie. Je crée ainsi une banque de quelques appareils : switchs, AGTW, PC...
Vient maintenant la logique de connexion entre les appareils. Je m'aperçois que les ports de chaque switch, par exemple, doivent aussi être configurés avec leurs propres propriétés. Je mets à jour les modèles des appareils dans la banque de templates d'appareil. Le futur utilisateur n'aura plus qu'à copier-coller le modèle qui l'intéresse avant de le configurer plus précisément lui-même.
Toutes les informations saisies dans Capella sont retranscrites dans un immense fichier XML. Je me l'approprie et crée un script Python capable trier les informations et de les ordonner dans un fichier intermédiaire en JSON. On y retrouve par catégorie d'équipement, tous les appareils saisis par l'opérateur ainsi que toutes leurs propriétés.
Des tests sont effectués avec d'autres plugins développés en interne directement depuis Capella pour générer un fichier de configuration mais les résultats sont limités : suffisant pour générer des configurations pour certaines équipes mais pas pour la mienne dont le produit est trop complexe. Néanmoins la génération est possible. Je crée alors un second script Python et teste la génération d'une configuration d'une autre équipe depuis le fichier intermédiaire généré plus tôt, cette fois. Le résultat est satisfaisant : je peux déjà reproduire un petit fichier de configuration utilisable par une autre équipe. Il faut peaufiner l'outil et les scripts et nous pourrons assurément réutiliser le fichier intermédiaire pour générer le fichier de configuration final.
Les modélisations des templates d'appareils dans Capella ont été affinées, si bien que j'ai pu modéliser l'ensemble des appareils d'un navire de faible envergure. Le script de génération du fichier intermédiaire a également été retravaillé et le fichier intermédiaire qui en résulte est maintenant plus complet : il contient désormais les propriétés également présentes sur tous les ports des appareils. C'est très enthousiasmant pour la suite !
La valeur ajoutée du POC est certaine et mérite d'être connue par mes supérieurs et d'autres équipes que cela pourrait intéresser. Je présente sur un stand lors de deux importants événements inter-entreprise mon outil. Son intérêt est reconnu et le développement du projet sera poursuivi par le prochain apprenti.
La documentation sur la prise en main de l'outil que j'ai alimentée tout au long du processus est perfectionnée. J'y note également les bonnes pratiques à adopter sur Capella afin d'éviter tout bug. Enfin, je reste disponible et forme plusieurs membres de différentes équipes à l'utilisation de mon outil.
Dans un élan de proactivité, je trouve que le fichier intermédiaire est aussi très intéressant pour rapidement se rendre compte du nombre d’appareils déployés. En effet, il permettrait de détecter au plus tôt des erreurs, tels que le manque d’un modem, avant de lancer tout le processus de génération qui, même optimisé, prendra forcément un certain temps.
J’apprends en autonomie à utiliser Flask pour qu’à l’exécution d’un petit script Python additionnel, une application web très visuelle (une couleur par catégorie d’équipement) remonte les différents nombres d’équipements présents dans le fichier intermédiaire, donc bien implémentés par l’opérateur de saisie dans Capella.
Je remercie encore Thales pour m’avoir permise d’intégrer une de ses équipes de développement pendant mes trois années de formation. Cette expérience a été extrêmement enrichissante !
En effet, j’ai vécu une vraie immersion dans le monde du travail en tant qu’ingénieure logiciel Full-stack sur de multiples missions toujours plus différentes les unes que les autres et pour autant bien essentielles. J’ai également eu la chance d’avoir un tuteur exceptionnel sur cette période, et je pèse mes mots, à l’écoute et bienveillant, qui m’a fait confiance sur un projet innovant et de valeur que j’ai eu le plaisir et la fierté de porter durant deux ans. J’ai aussi pu côtoyer chaque jour un projet de grande envergure déjà déployé depuis des années sur un nombre conséquent de navires français. On se rend alors compte de la force d’un tel grand groupe aux échelles nationale et internationale et en tant que collaboratrice, des possibilités d’évolution qu’il offre.