Thierno DIALLO

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.

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.