À propos de moi

L'arrivée des agents IA de développement dans notre quotidien a rapidement fait apparaître une qualité inégale, des efforts dupliqués et l'absence de standards communs. Pour y remédier, j'ai piloté la création d'un cadre commun pour l'équipe.

J'ai défini un modèle de gouvernance qui répond aux questions essentielles : qui est responsable d'un skill, comment les contributions sont revues, comment chacun est testé indépendamment puis diffusé d'abord en préversion, comment les skills se composent, comment les règles d'activation évitent que deux d'entre eux se disputent la même demande, et quels seuils de qualité sont attendus avant tout partage. Pour rendre l'évaluation reproductible et objective, j'ai conçu une grille de notation pondérée et développé un outil déterministe en Python qui note 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 que l'équipe peut combiner : gestion des tickets Jira, pipelines et merge requests GitLab, opérations Git locales, identification des environnements de fonctionnalités, évaluation automatisée de la qualité, et diagnostic Kubernetes limité à l'investigation en lecture seule, afin qu'un agent puisse aider à diagnostiquer un cluster sans pouvoir le modifier. Deux workflows d'orchestration combinent ces skills dans des processus structurés de diagnostic et d'évaluation, chacun avec un contrat explicite, des dépendances déclarées, des garde-fous de sécurité et une gestion des échecs définie.

Ce cadre est utilisé par l'équipe. Je continue à évaluer les contributions, à aider mes collègues à créer et déboguer leurs propres workflows, à les débloquer lorsqu'un agent ou une intégration d'outil se comporte mal, et à faire évoluer le modèle au fil des retours.

L'authentification unique à l'échelle du groupe représentait l'étape suivante pour une plateforme SaaS de santé multi-tenant utilisée dans plusieurs pays. J'ai conçu et implémenté de bout en bout l'intégration d'un fournisseur d'identité d'entreprise. La décision qui a structuré tout le reste a été de 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, et sans supprimer le mode de connexion existant par identifiant et mot de passe.

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

L'essentiel de la difficulté se situait après la connexion. 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, et la configuration correspondante était dispersée entre plusieurs fichiers et le code applicatif. Orienter un utilisateur de test ou pilote vers un point d'accès hors production, tout en maintenant les professionnels de santé sur celui de production, imposait le plus souvent une modification du code et un redéploiement — sans moyen simple de définir une exception pour un seul utilisateur.

J'ai pris en charge le remplacement de ce fonctionnement par un modèle de résolution à trois niveaux, évalué pour chaque utilisateur et chaque intégration : une valeur définie pour un utilisateur précis l'emporte sur la stratégie propre à l'intégration, qui l'emporte elle-même sur la valeur par défaut gérée en base de données. Le routage des points d'accès n'était toutefois que le déclencheur : j'ai conçu le service pour le cas général, c'est-à-dire définir n'importe quelle configuration dont la valeur dépend de l'utilisateur — ses attributs, son profil ou tout autre critère utile à une intégration.

J'ai conçu le modèle de données JPA, implémenté le service et l'API en Java/Quarkus, et documenté l'architecture dans un document de conception formel (une RFC) accompagné de diagrammes techniques. Les patterns Strategy et Factory isolent les règles propres à chaque intégration, si bien qu'en ajouter une ne demande pas de toucher au flux de résolution.

Les changements de points d'accès et les exceptions individuelles relèvent désormais de la configuration, et non du déploiement. Le système est utilisé en production.

Tous les documents cliniques de la plateforme passent par un unique service de stockage, initialement adossé à une instance MinIO auto-hébergée que j'avais contribué à développer. Lorsque l'entreprise a migré la plateforme vers Azure, un collègue et moi avons pris en charge le volet stockage. Les médecins utilisent le produit pendant leurs journées de consultation : il n'y avait donc pas de fenêtre de maintenance suffisante pour migrer tous les documents en une fois. La migration devait se faire plateforme en fonctionnement, sans perdre un seul fichier.

Plutôt qu'une bascule unique, nous avons rendu le service capable de dialoguer avec les deux systèmes de stockage en même temps, et déplacé la décision de routage dans la base de données : chaque tenant MinIO pointait vers le tenant Azure qui le remplaçait, et le bucket de chaque cabinet pointait vers celui qui le détenait physiquement. Migrer un bucket devenait une mise à jour en base plutôt qu'un déploiement, et un feature toggle permettait de renvoyer instantanément tout le trafic vers MinIO, puisque rien n'y avait été supprimé, précisément pour assurer la rétrocompatibilité.

J'ai développé l'outillage de migration en Python, exécuté comme job Kubernetes : copie parallélisée, table de suivi rendant chaque exécution reprenable, et comparaison du nombre d'objets des deux côtés avant tout basculement du routage : copier, vérifier, puis basculer. Nous le lancions en dehors des heures de consultation, migrant un ensemble de buckets, puis nous arrêtions et reprenions plus tard là où nous nous étions arrêtés. J'ai également écrit les chemins de lecture et d'écriture rétrocompatibles permettant aux deux systèmes de coexister pendant que les buckets basculaient un à un.

Le chantier s'est étendu sur environ neuf mois, de la conception à la bascule finale, sans interruption de service ni perte de données. Une fois la production stabilisée sur Azure, j'ai pris en charge le nettoyage : suppression de l'ancienne implémentation, du feature toggle, des scripts de provisionnement et des dépendances.

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 et sans que la plateforme ait à comprendre plusieurs formats de jetons externes. J'ai conçu et implémenté de bout en bout un mécanisme d'échange de jetons OAuth 2.0 pour établir ce pont.

Je me suis appuyé sur le standard OAuth 2.0 Token Exchange (RFC 8693) et j'ai pris en charge l'ensemble du cycle de réalisation : architecture du protocole, modèle de sécurité, implémentation Java/Quarkus, contrat OpenAPI et documentation destinée aux équipes consommatrices. La validation des jetons propre à chaque partenaire est isolée derrière une même interface, si bien que la plateforme peut accepter plusieurs émetteurs externes sans que le flux d'échange ait à les connaître.

Les scopes demandés sont limités aux autorisations accordées au partenaire avant l'émission d'un jeton interne uniforme : un produit partenaire n'atteint que les services pour lesquels il est enregistré — le moindre privilège, appliqué à la frontière plutôt que dans chaque service en aval.

Le mécanisme est utilisé en production par des produits CGM et offre aux accès entre produits une frontière de sécurité unique et auditable.

Les cartes de santé françaises et le DMP — le dossier médical partagé national — ouvraient un champ d'intégration entièrement nouveau pour la plateforme : lecteurs physiques, logiciel exécuté sur le poste du praticien, événements de cartes en temps réel, transactions réglementées et protocoles de santé que personne dans l'équipe n'avait encore manipulés.

J'ai mené l'investigation technique initiale et réalisé une preuve de concept fonctionnelle couvrant la carte CPS du professionnel, la Carte Vitale du patient et les principaux parcours documentaires du DMP.

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 de leur retrait, et échanges de documents exigés par le DMP. J'ai produit des exemples Postman reproductibles et une documentation technique, et 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, 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, qui s'en sont servies 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. J'ai contribué à l'étude et à la mise en œuvre du système de classification conçu pour y répondre.

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 de graphe. Apache AGE conservait la même modélisation en graphe et les mêmes requêtes Cypher, mais s'exécutait dans l'infrastructure PostgreSQL déjà exploitée par la plateforme : l'équipe obtenait ainsi les fonctionnalités de graphe recherchées sans avoir à déployer, superviser et sauvegarder une seconde base de données.

Après validation de ce choix, j'ai contribué activement à l'implémentation collective en Java/Quarkus, ainsi qu'à la documentation, aux recommandations destinées aux développeurs, aux démonstrations et à l'accompagnement qui ont rendu le système utilisable par les autres équipes.

Le système en production combine une résolution par graphe et un cache Redis qui permet à un service de déclarer la variante dont il a besoin au lieu de multiplier les conditions. Il est utilisé sur toute la plateforme et permet de gérer plusieurs pays depuis un même code source, en gardant la logique de variation à un seul endroit.

KimiaPay souhaitait valider un produit numérique d'avance sur salaire destiné à des employés ayant un accès limité au crédit traditionnel, où des employeurs partenaires participaient à l'approbation des demandes et à la garantie du remboursement. J'étais le seul responsable technique au sein d'une équipe de startup, pendant mon stage de fin d'études.

Le principal défi était architectural : transformer un produit financier comportant plusieurs acteurs, plusieurs niveaux de validation, des exigences de sécurité et des 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 couvrait l'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 le cycle de vie complet d'une demande, de sa soumission au remboursement ou au litige. J'ai retenu AppGyver et Backendless afin d'accélérer la livraison sous les contraintes du projet, et écrit du JavaScript sur mesure lorsque nécessaire. Le produit finalisé a été déployé, 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 construit la version Quarkus de l'application et étudié les problèmes de compatibilité qu'elle faisait apparaître : dépendances externes, CDI, annotations Spring non prises en charge et chargement des classes. Selon les contraintes, j'ai utilisé des producteurs CDI, adapté certains composants, développé des extensions Quarkus ou comparé les deux applications côte à côte en mode débogage pour repérer où elles divergeaient. J'ai également remonté à la communauté Quarkus de véritables limites du framework.

La migration est volontairement restée incomplète dès lors que son périmètre a dépassé la durée du stage. J'ai livré à la place un document technique exploitable pour la décision : blocages rencontrés, solutions trouvées, arbitrages effectués et coûts de migration à envisager. Les premières mesures indiquaient des gains importants au démarrage, dont j'ai clairement documenté les limites.

Amadeus disposait ainsi d'une base réutilisable pour évaluer de futures migrations, et j'en suis sorti avec une bien meilleure compréhension de la compatibilité des frameworks et de ce qu'implique réellement une migration : comment l'évaluer, la préparer et la mener en limitant les risques. Travailler entièrement en anglais au sein d'une équipe internationale — collaboration quotidienne, réunions, échanges techniques, documentation — a également renforcé ma communication professionnelle.

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.

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 sur l'algorithmique avec Python, UML et la conception d'applications, ainsi que sur les notions d'ingénierie informatique que le cursus supposait acquises.

Réexpliquer une notion de la même façon ne fonctionne presque jamais. L'essentiel du travail consistait à repérer où la compréhension avait lâché, puis à reprendre l'explication par un autre chemin.

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 ; je coordonnais cette équipe et j'étais l'interlocuteur principal de l'administration.

Je recueillais les disponibilités, établissais les plannings, gérais les absences de dernière minute et équilibrais les heures mensuelles afin que le travail et la rémunération restent aussi équitables que possible. Je veillais également au bon usage des salles, prenais en charge les incidents signalés par les utilisateurs, transmettais ce que je ne pouvais pas résoudre et informais l'administration en cas de difficulté.

Le poste consistait surtout à maintenir un planning équitable et un service ouvert malgré les imprévus, et à être la personne que l'équipe comme l'école pouvaient appeler.

SUITE explorait une application mobile collaborative destinée à faciliter le partage et la découverte de savoir-faire spécialisés ou locaux, à travers 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'étais le seul développeur du client mobile.

J'ai pris en charge ce volet, de l'analyse des besoins à l'architecture et à l'implémentation. J'ai modélisé les rôles et le domaine avec UML, 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 principaux écrans et les parcours de bout en bout : consultation des formations, authentification, publication de demandes d'aide, de formations, d'événements et d'offres. C'était mon premier produit mobile mené de bout en bout : choix de la technologie, modélisation du domaine, intégration d'une API que je n'avais pas écrite, et démonstration du résultat.