Expériences

L’arrivée des agents IA de développement dans notre quotidien chez CGM a rapidement fait apparaître une qualité inégale, des efforts dupliqués, des résultats peu fiables et l’absence de standards communs. Dans mon rôle de Software Engineer senior, j’ai répondu à ces enjeux en pilotant la création d’un cadre partagé pour l’équipe.

J’ai défini un modèle de gouvernance couvrant les responsabilités, les cycles de contribution et de revue, les tests indépendants, les phases de préversion, la composabilité, les règles d’activation non concurrentes et des seuils de qualité recommandés. Pour rendre l’évaluation reproductible, j’ai conçu une grille de notation pondérée et développé un outil déterministe en Python qui évalue les skills et les workflows, signale les problèmes critiques et classe les améliorations selon leur impact.

J’ai également créé des skills réutilisables pour le diagnostic sécurisé de Kubernetes, la gestion des tickets Jira, les pipelines et merge requests GitLab, les opérations Git locales, l’identification des environnements de fonctionnalités et l’évaluation automatisée de la qualité. Deux workflows d’orchestration combinent ces capacités dans des processus structurés de diagnostic et d’évaluation, avec des contrats explicites, des dépendances réutilisables, des garde-fous de sécurité et une gestion des échecs.

Ces ressources sont largement utilisées par l’équipe. Je continue à évaluer les contributions, à aider mes collègues à créer et déboguer leurs propres workflows, à les accompagner lorsqu’ils rencontrent des problèmes liés aux agents IA ou aux intégrations d’outils, et à faire évoluer le cadre à partir des retours d’usage.

L’authentification unique à l’échelle du groupe représentait l’étape suivante pour une plateforme SaaS de santé multi-tenant utilisée en France et en Italie. Dans mon rôle de Software Engineer senior chez CGM, j’ai conçu et implémenté de bout en bout l’intégration d’un fournisseur d’identité d’entreprise.

La frontière architecturale essentielle consistait à déléguer l’authentification tout en conservant la gestion des rôles, des autorisations et des périmètres organisationnels au sein de la plateforme, sans supprimer le mode de connexion existant par identifiant et mot de passe.

J’ai pris en charge l’architecture, la coordination avec les parties prenantes, l’implémentation Java/Quarkus, le modèle de sécurité et la documentation technique. L’intégration utilise le flux OIDC Authorization Code avec PKCE, les Pushed Authorization Requests, ainsi que la validation de state et de nonce.

J’ai conçu la gestion côté serveur de l’état d’authentification et des jetons externes, notamment leur renouvellement et leur suppression synchronisée avec le cycle de vie de la session, ainsi qu’un modèle d’association des identités indépendant du fournisseur qui refuse les correspondances ambiguës. J’ai également résolu le routage des callbacks pour des environnements de test dynamiques sans assouplir la validation des URI de redirection.

L’intégration est désormais en production et activement utilisée par des professionnels de santé, offrant une authentification fédérée sécurisée tout en préservant les frontières internes d’autorisation.

Les intégrations tierces n’utilisaient pas toutes les mêmes paramètres de connexion : les points d’accès variaient selon l’environnement de déploiement et le profil de l’utilisateur, tandis que la configuration correspondante était dispersée entre plusieurs fichiers et le code applicatif. Dans mon rôle de Software Engineer senior chez CGM, j’ai pris en charge le remplacement de ce modèle fragmenté par un système centralisé de résolution des configurations.

Orienter un utilisateur de test ou pilote vers un point d’accès hors production, tout en maintenant les professionnels de santé sur le point d’accès de production, nécessitait souvent une modification du code et un redéploiement, sans moyen simple de définir une exception pour un seul utilisateur.

J’ai remplacé ce fonctionnement par un modèle de résolution à trois niveaux, évalué pour chaque utilisateur et chaque intégration : une configuration spécifique à l’utilisateur est prioritaire, une stratégie propre à l’intégration applique les règles de routage, puis une valeur par défaut gérée en base de données sert de repli. Les changements courants de points d’accès et les configurations individuelles peuvent ainsi être appliqués sans redéployer l’application.

J’ai utilisé les patterns Strategy et Factory pour isoler et étendre les règles de routage. J’ai également conçu le modèle de données JPA, implémenté le service et l’API en Java/Quarkus, et documenté l’architecture dans une RFC formelle accompagnée de diagrammes techniques. Le système est activement utilisé en production.

Des produits CGM utilisés dans plusieurs pays devaient réutiliser certains services de la plateforme au nom d’utilisateurs déjà authentifiés, sans leur imposer une nouvelle connexion ni introduire plusieurs formats de jetons externes dans la plateforme.

Pour créer ce pont sécurisé, j’ai conçu et implémenté de bout en bout un mécanisme d’échange de jetons OAuth 2.0 dans mon rôle de Software Engineer senior chez CGM.

J’ai retenu la RFC 8693 et pris en charge l’ensemble du cycle de réalisation, de l’architecture du protocole et du modèle de sécurité à l’implémentation Java/Quarkus, au contrat OpenAPI et à la documentation destinée aux équipes consommatrices. J’ai conçu une architecture fondée sur les patterns Strategy et Factory, qui isole la validation propre à chaque partenaire et permet d’ajouter de nouvelles intégrations sans modifier le flux central.

Les scopes demandés sont limités aux autorisations accordées au partenaire avant l’émission d’un jeton interne uniforme, appliquant ainsi le principe du moindre privilège aux services en aval. Ce mécanisme est aujourd’hui en production et activement utilisé par des produits CGM, avec une frontière de sécurité unique et auditable pour les accès entre produits.

Les cartes de santé françaises et le DMP ouvraient un champ d’intégration entièrement nouveau pour la plateforme : lecteurs physiques, logiciel exécuté sur le poste de travail, événements de cartes en temps réel, transactions réglementées et protocoles de santé encore inconnus de l’équipe devaient fonctionner ensemble.

Alors Software Engineer de niveau intermédiaire chez CGM, j’ai mené l’investigation technique initiale et réalisé une preuve de concept fonctionnelle autour des lecteurs CPS et Carte Vitale et du DMP, le dossier médical partagé français.

J’ai cartographié et testé l’écosystème de bout en bout : sessions des lecteurs, accès aux cartes des professionnels et des patients, détection asynchrone de leur insertion ou retrait, et principaux parcours documentaires du DMP. J’ai créé des exemples Postman reproductibles et une documentation technique complète, puis contribué à définir une architecture séparant la gestion des événements côté frontend des opérations transactionnelles côté backend.

Mon rôle consistait à rendre cette intégration concrètement réalisable, et non à développer la fonctionnalité de production finale. J’ai livré des exemples fonctionnels, des diagrammes d’architecture, des démonstrations, des sessions de transfert de connaissances et un accompagnement aux équipes de réalisation. Celles-ci se sont appuyées sur ce travail pour livrer la fonctionnalité aujourd’hui largement utilisée par les médecins.

Un même code source devait adapter les services, les composants d’interface et les règles métier de la plateforme selon le pays, la région, le type de praticien et la spécialité, sans devenir un enchevêtrement de conditions. Alors Software Engineer de niveau intermédiaire chez CGM, j’ai contribué à l’étude et à la mise en œuvre du système de classification conçu pour répondre à ce besoin.

Avec un collègue, j’ai mené l’étude technique initiale. J’ai évalué Apache AGE face à la solution Neo4j précédemment envisagée, en reproduisant dans les deux technologies les principales requêtes de taxonomie et de parcours. Apache AGE conservait la modélisation en graphe et les requêtes Cypher tout en s’intégrant à l’infrastructure PostgreSQL existante, évitant ainsi de déployer et d’exploiter une technologie de base de données supplémentaire.

Après validation de ce choix, j’ai contribué activement à l’implémentation collective en Java/Quarkus, à la documentation, aux recommandations destinées aux développeurs, aux démonstrations et à l’accompagnement des équipes.

Le système en production combine une résolution par graphe, un cache Redis et une extension Quarkus fondée sur Gizmo, qui permet aux services de sélectionner déclarativement l’implémentation adaptée au contexte. Il est activement utilisé sur la plateforme et permet de gérer plusieurs pays depuis un même code source tout en maintenant les variations isolées et faciles à faire évoluer.

KimiaPay souhaitait valider un produit numérique d’avance sur salaire pour des employés ayant un accès limité au crédit traditionnel, avec la participation d’employeurs partenaires dans l’approbation des demandes et la garantie du remboursement. Pendant mon stage de fin d’études, j’ai occupé le poste de stagiaire Software Engineer et assuré seul la responsabilité technique au sein de la petite équipe de startup.

Le principal défi était architectural : transformer un produit financier comportant plusieurs acteurs, niveaux de validation, exigences de sécurité et besoins d’évolution en un système cohérent qu’un seul développeur pouvait livrer en quatre mois.

J’ai conçu une architecture orientée services comprenant une application mobile multiplateforme pour les emprunteurs, un back-office web pour les administrateurs et les représentants des employeurs, des services métier backend et une couche de données centralisée reliés par des API REST/JSON. J’ai ensuite décliné cette architecture jusqu’à l’implémentation, aux tests et au déploiement.

Le produit comprenait une authentification par jeton, la collecte des données d’identité et d’emploi, un contrôle d’accès par rôles, une validation à plusieurs niveaux, le suivi des prêts et un cycle de vie complet des demandes, de leur soumission au remboursement ou au litige. J’ai retenu AppGyver et Backendless afin d’accélérer la livraison sous les contraintes du projet, tout en utilisant des intégrations JavaScript personnalisées lorsque nécessaire. Le produit finalisé a été déployé et était prêt pour une phase pilote.

Amadeus souhaitait déterminer si la migration d’un serveur d’application de recherche de vols de Spring/JBoss vers Quarkus était techniquement réalisable et justifiée par sa valeur métier. Mon stage de deuxième année était consacré à cette évaluation. L’objectif n’était pas de modifier le comportement fonctionnel de l’application, mais de déterminer comment l’exécuter avec Quarkus et de documenter les implications pour de futures migrations.

Intégré à une équipe d’ingénierie agile, j’ai créé la version Quarkus de l’application et étudié des problèmes de compatibilité liés aux dépendances externes, à CDI, aux annotations Spring non prises en charge et au chargement des classes. Selon les contraintes, j’ai utilisé des producteurs CDI, adapté certains composants, développé des extensions Quarkus et comparé les deux applications côte à côte en mode débogage. J’ai également remonté à la communauté Quarkus de véritables limites du framework.

La migration est volontairement restée incomplète lorsque son périmètre a dépassé la durée du stage. J’ai plutôt livré un document technique exploitable pour la décision, recensant les blocages, les solutions, les compromis et les coûts de migration. Les premières mesures indiquaient des gains importants au démarrage, dont j’ai clairement documenté les limites.

Cette étude a fourni à Amadeus une base réutilisable pour évaluer de futures migrations et a renforcé mon jugement sur la compatibilité des frameworks et le retour sur investissement d’une migration. Travailler entièrement en anglais au sein d’une équipe internationale a également renforcé ma communication professionnelle au quotidien, lors des réunions, des échanges techniques et de la rédaction documentaire.

L’École Centrale de Lyon maintenait ses salles informatiques ouvertes le soir afin que les étudiants puissent travailler après le départ du personnel habituel. Une équipe de moniteurs étudiants rémunérés en assurait la supervision ; en tant que coordinateur, j’organisais le groupe et servais d’interlocuteur principal à l’administration.

Je recueillais les disponibilités, établissais les plannings, gérais les absences de dernière minute et équilibrais les heures mensuelles afin de maintenir une répartition aussi équitable que possible du travail et de la rémunération. Je veillais également au bon usage des salles, prenais en charge les incidents rencontrés par les utilisateurs, transmettais les problèmes non résolus et informais l’administration des difficultés opérationnelles.

Cette responsabilité m’a appris à coordonner une équipe avec équité, à assurer la continuité du service face aux imprévus et à faire le lien entre une équipe et une institution.

Le rythme soutenu du cursus de l’École Centrale de Lyon laissait parfois certains élèves avec le besoin de plus de temps et d’une autre manière d’aborder les notions difficiles. En raison de mon parcours en informatique, l’établissement m’a sélectionné et rémunéré pour animer les séances de renforcement en informatique dans cette discipline.

Je préparais les cours et les exercices, reprenais les notions mal comprises, corrigeais les travaux, animais des ateliers pratiques et proposais un accompagnement individuel. Les séances portaient principalement sur l’algorithmique avec Python, UML et la conception d’applications, ainsi que sur des notions plus générales d’ingénierie informatique.

Cette responsabilité m’a appris à repérer l’origine d’une difficulté, à adapter mes explications à chaque étudiant plutôt qu’à répéter le cours initial, et à rendre des concepts techniques clairs et concrets.

SUITE explorait une application mobile collaborative capable de faciliter le partage et la découverte de savoir-faire spécialisés ou locaux grâce à des contenus de formation, des demandes d’aide, des offres de service et des événements en ligne ou en présentiel. Pendant mon stage de DUT, j’ai occupé le poste de stagiaire développeur logiciel et développé seul le client mobile.

J’ai pris en charge le volet mobile, de l’analyse des besoins à l’architecture et à l’implémentation. J’ai modélisé les rôles et le domaine avec UML, puis développé l’application multiplateforme en React Native et l’ai intégrée à une API Django REST Framework existante, fournie par l’équipe SUITE. Le client consommait des endpoints REST/JSON et proposait des fonctionnalités distinctes pour les visiteurs, les apprenants, les formateurs et les administrateurs.

À la fin du stage, j’avais implémenté et présenté les principales vues mobiles et les parcours de bout en bout, notamment la consultation des formations, l’authentification, la publication de demandes d’aide ainsi que la création de formations, d’événements et d’offres. Cette expérience a été ma première prise en charge significative du cycle de développement d’un produit mobile, de la conception orientée objet et du choix des technologies à l’intégration d’API et à la démonstration du produit.