Le réusinage au rythme des missions : approche par « maillage d'agents » pour la modernisation des systèmes existants avec Red Hat AI

Les logiciels existants ne disparaissent pas d'eux-mêmes. Ces logiciels restent en production, accumulent une dette technique, résistent aux changements et deviennent discrètement un risque, non en raison de leurs fonctions, mais de ce qu'ils ne peuvent plus prendre en charge.

Ce défi concerne les principaux intégrateurs de systèmes (SI) travaillant pour le secteur public et l'industrie. Au sein d'un portefeuille d'applications critiques, les SI et les entreprises de l'aérospatiale gèrent des bases de code Python et Java vieillissantes devant évoluer vers une base moderne, sécurisée et pérenne, précisément Red Hat Enterprise Linux 10 (RHEL 10).

L'objectif ne se limite pas à une simple mise à jour logicielle. Il s'agit de maintenir la cadence de distribution des logiciels et de l'IA, ainsi que la posture de sécurité dont dépendent les centres de données publics, les zones de mission déployées ou les systèmes mobiles embarqués.

Cet enjeu n'a rien de théorique pour le gouvernement fédéral des États-Unis. Le cadre de gouvernance de l'IA de la GSA et le Department of War (DoW) exigent désormais que les agences et les services mettent en œuvre une IA responsable, au lieu de simplement l'adopter. Pour les acteurs de la défense et des missions, ce mandat ne représente pas une simple case à cocher. Il constitue un levier pour structurer l'usine logicielle avant de confier des tâches critiques aux agents qu'elle contient. 

Lors d'une récente mission, la compatibilité totale hors ligne constituait l'une des exigences impératives. Par conception, les environnements dédiés à la sécurité nationale sont souvent privés d'accès à Internet. Toute dépendance à un service externe (GitHub, API cloud, registre de paquets distant) peut se transformer en vulnérabilité ou en point de défaillance, ou rendre le système non conforme. 

La modernisation manuelle du système était techniquement possible, mais l'effort d'ingénierie estimé représentait des années de travail humain, ce qui rendait l'opération irréalisable à l'échelle requise. L'autre option consistait à ne rien faire et à continuer d'exploiter des systèmes vieillissants, malgré des risques opérationnels croissants. Nous nous sommes alors demandé s'il existait une troisième voie : créer un processus plus efficace grâce à l'automatisation agentique, pour permettre aux équipes d'ingénierie de superviser la modernisation à grande échelle plutôt que d'effectuer chaque étape manuellement.

Nous avons ainsi conçu une plateforme agentique reposant sur Red Hat AI et Red Hat OpenShift AI.

Les enjeux de la modernisation des systèmes existants à grande échelle

La migration d'un environnement de type « Brownfield », qui consiste à déplacer du code de production réel et non un simple prototype (POC), diffère fondamentalement de la création d'un nouveau projet. Il ne suffit pas de soumettre une requête à une IA pour considérer la tâche comme terminée.

Les bases de code existantes présentent souvent les caractéristiques suivantes :

• Architectures vieillissantes : Systèmes conçus selon des hypothèses, des frameworks et des infrastructures reflétant les normes techniques d'une époque antérieure.
• Couverture de tests limitée ou inégale : De larges sections de la base de code ont été écrites avant que les tests automatisés ne s'imposent comme une discipline standard.
• Contrats de comportement implicites : Dépendances entre les modules et les services existant en pratique, mais n'ayant jamais fait l'objet d'une documentation formelle ou d'une application stricte.
• Dette technique accumulée : Accumulation de solutions de contournement, de bibliothèques obsolètes et de correctifs de compatibilité intégrés progressivement au système de production.

Pour les missions de sécurité nationale, les enjeux d'un échec ne sont pas abstraits. L'échec d'une migration ne se limite pas à l'interruption d'une application ; il peut paralyser un workflow, retarder une mission ou introduire une vulnérabilité de sécurité dans une infrastructure qui protège des personnes.

Cet environnement constitue précisément le type de contexte où les grands modèles généralistes exploités via une API cloud ne représentent pas une option viable. Il est impossible d'envoyer du code sensible vers un point de terminaison externe. Il est impossible de tolérer un comportement d'inférence imprévisible à grande échelle. Même s'il était possible de se connecter à des modèles frontier du cloud, le volume de tokens et la surcharge de calcul ne pourraient se justifier lorsque les requêtes génèrent de longues chaînes de raisonnement dans des espaces de paramètres massifs. À l'échelle de la migration, lorsque les systèmes contiennent des millions de lignes de code, cette situation engendre rapidement de la latence, des coûts d'infrastructure et des risques opérationnels accrus.

Pourquoi les modèles efficaces et de petite taille sont les mieux adaptés

Pour la plupart des applications d'IA, le premier réflexe consiste à choisir le modèle le plus imposant disponible. Plus de paramètres, plus de contexte et des réponses plus pertinentes. Cette logique montre rapidement ses limites dans les environnements déconnectés, critiques et aux ressources limitées. Les grands modèles frontier introduisent souvent une latence excessive, des boucles de raisonnement imprévisibles et des besoins importants en mémoire GPU, difficiles à satisfaire dans une infrastructure contrôlée.

Les modèles de langage de petite taille (SLM) s'adaptent bien aux workflows agentiques, car ces systèmes exigent une exécution fiable et reproductible ainsi qu'une faible latence, plutôt qu'une simple mise à l'échelle brute. Les modèles de plus petite taille peuvent offrir un comportement rapide et déterministe, adapté aux tâches d'automatisation comme l'appel d'outils, l'orchestration et le raisonnement structuré. Ces modèles s'avèrent également plus faciles à affiner et à exploiter localement, ce qui permet aux équipes de déployer des flottes d'agents spécialisés sans dépendre de points de terminaison externes. En d'autres termes, lorsqu'un modèle ne « connaît » bien qu'un seul domaine, la distribution de probabilité s'affine et tend à produire plus souvent la même réponse.

Cela dit, nos tests ont révélé que les capacités des modèles restent étroitement liées à la longueur du contexte et au nombre de paramètres, en particulier pour les tâches de migration de code nécessitant la compréhension de vastes systèmes logiciels. Les modèles ayant obtenu de bons résultats lors des premiers tests incluent les variantes Llama 4 et les modèles Claude, principalement grâce à leurs fenêtres de contexte très étendues (> 256 000 tokens) et à leur solide capacité de raisonnement. À l'inverse, nous avons constaté que Claude analyse parfois de manière excessive des tâches d'ingénierie simples, produisant des chaînes de raisonnement inutilement longues qui augmentent la consommation de tokens et la latence. À l'échelle de la migration, ce comportement se traduit rapidement par des coûts de calcul importants.

Pour cette raison, nous exploitons actuellement Meta Maverick en local et effectuons des tests parallèles avec des modèles Mistral, compte tenu des besoins en mémoire GPU des modèles plus imposants. Nous réévaluons également Llama 4 Scout, qui offre de bonnes performances mais sollicite de la même manière les limites des ressources de calcul disponibles dans l'environnement actuel.

Afin de pallier ces difficultés, nous avons mis en œuvre une stratégie de modèle hybride utilisant des modèles plus petits, tout en procédant au réusinage des workflows pour atténuer les limites de contexte à mesure qu'elles se présentent.

Nos sélections de modèles actuelles pour le système d'orchestration :

• mistralai/Devstral-Small-2-24B-Instruct : Désigné pour les agents de codage. Contexte de 256 000 tokens, performances solides sur les benchmarks de codage, optimisé pour l'analyse de logiciels et les tâches de réusinage.
• mistralai/Ministral-3-14B-Reasoning : Désigné pour les agents hors codage. Contexte de 256 000 tokens, efficace pour le raisonnement structuré, l'analyse des dépendances et l'orchestration des workflows de migration.

En plus des modèles d'agents, le système utilise des modèles spécialisés pour l'indexation et la récupération de connaissances :

• gpt-oss-120B : Ce modèle permet de construire le graphe de connaissances GraphRAG représentant la structure globale de la base de code.
• intfloat/e5-mistral-7B-instruct : Il s'agit d'un modèle d'intégration utilisé pour l'indexation GraphRAG et la récupération vectorielle.

Ces choix ne constituaient pas des compromis. Ces décisions d'ingénierie répondaient aux besoins de l'environnement de calcul disponible. Les limitations de contexte rencontrées proviennent de la capacité des processeurs graphiques (GPU) et non de l'architecture elle-même. À mesure que l'infrastructure évolue, le système d'orchestration et la stratégie de sélection des modèles peuvent s'adapter.

L'architecture d'Agent Mesh : une « infrastructure d'orchestration de systèmes » agentique reposant sur OpenShift AI

Le cœur de cette plateforme repose sur un dispositif d'orchestration agentique, un framework modulaire qui coordonne plusieurs agents d'IA spécialisés, chacun étant responsable d'une partie spécifique du workflow de migration. Ce dispositif fonctionne sur OpenShift AI et tire parti de vLLM pour assurer une inférence de modèles efficace et à faible latence. Au fil du temps, ce modèle évolue vers ce que nous décrivons comme un Agent Mesh, une architecture d'« orchestration de systèmes » où plusieurs workflows agentiques peuvent interagir, coordonner des tâches et partager des états au sein de programmes de modernisation complexes.

Voici le fonctionnement actuel de l'architecture :

Les agents de codage , pilotés par Devstral, analysent le code source Python 2 ou Java existant, identifient les API obsolètes, génèrent des équivalents remaniés et produisent des tests de caractérisation qui capturent le comportement d'origine avant toute modification. Ces agents ne se contentent pas de traduire la syntaxe, ils s'efforcent de préserver l'intention comportementale.

Les agents qui n'effectuent pas de codage, pilotés par Ministral, réalisent des tâches de raisonnement sur l'ensemble du workflow, notamment la cartographie des dépendances, la planification de la migration et le suivi de la progression. Une logique d'orchestration déterministe régit le flux d'exécution ; les agents coordonnent ainsi les éléments migrés, validés ou bloqués, ainsi que les étapes suivantes.

Un agent de gestion de suivi personnalisé gère l'intégration avec GitLab (et peut être remplacé intégralement pour les environnements déconnectés). Ce composant constitue un code entièrement inspectable plutôt qu'une boîte noire, ce qui permet aux organisations d'intégrer le dispositif à leurs systèmes de développement et de gouvernance existants.

Le dispositif lui-même est conçu pour être modulaire et interchangeable, associant des agents sur mesure à des agents Open Source tels qu'OpenCode. Lorsque les organisations demandent si le système constitue une boîte noire, la réponse s'avère nuancée : la couche d'inférence LLM, comme tout réseau neuronal, demeure intrinsèquement opaque. Toutefois, la logique d'orchestration, le code des agents, les résultats et les pistes de décision s'avèrent entièrement traçables, auditables et inspectables, un point essentiel pour les organisations soumises aux exigences de sécurité et d'assurance du DoW.

vLLM, qui sert de moteur d'inférence au sein d'OpenShift AI, constitue un levier essentiel. Une inférence efficace ne représente pas seulement une optimisation des performances : dans les environnements aux ressources GPU limitées, elle rend les workflows multi-agents viables. Le service optimisé de vLLM permet à la plateforme de gérer les boucles de raisonnement itératives à étapes multiples nécessaires aux workflows de migration, sans épuiser les ressources de calcul pour une seule tâche.

À mesure que de nouveaux dispositifs agentiques apparaissent pour des tâches adjacentes comme les tests, l'examen de la sécurité, la génération de documentation ou la validation du déploiement, ces systèmes peuvent s'interconnecter via l'Agent Mesh global, permettant une automatisation coordonnée sur l'ensemble des pipelines de modernisation.

Le workflow de migration : Python d'abord, Java ensuite

La phase initiale de ce projet cible la migration de Python 2 vers Python 3, constituant à la fois un livrable concret et une validation du framework. Python 2 a atteint sa fin de vie en 2020, et les systèmes qui l'utilisent encore présentent des vulnérabilités non corrigées et ne bénéficient d'aucune prise en charge en amont. Pour les systèmes publics et d'entreprise, ce risque n'est pas seulement théorique.

Notre hypothèse, validée lors des tests, suggère que le coût de la migration évolue selon la complexité des dépendances externes. Les applications étroitement liées à des paquetages tiers obsolètes nécessitent un nombre bien plus important d'itérations d'agent pour réaliser une migration propre. Cette observation a guidé la conception du modèle : moins de sous-tâches agentiques par flux, un périmètre plus restreint par itération et des étapes de validation plus déterministes entre elles.

Objectif à 30 jours : Couverture de test de 80 %, aucune dépendance à GitLab requise et validation de l'équivalence fonctionnelle entre les versions Python 2 et Python 3.

Figure 1 : Workflow d'usine logicielle agentique composé d'agents de codage, d'agents de non-codage et d'outils sur OpenShift AI.

La feuille de route à 30/60/90 jours s'oriente ensuite vers la migration Java ciblant les versions OpenJDK et Corretto (7, 8, 11, 17, 21) pour passer à Java 25, avec des parcours de migration variant selon que l'environnement cible utilise RHEL 8 ou RHEL 9 ou 10. Il convient de préciser qu'il ne s'agit pas d'une solution miracle ni d'une approche universelle. Le framework agentique constitue un point de départ, et chaque agent qu'il contient est conçu pour une tâche spécifique du workflow de migration. Cette caractéristique permet de l'étendre à Java sans avoir à tout reconstruire.

Mesure de ce qui compte réellement : indicateurs clés de performance (KPI) pour les environnements de type « Brownfield »

De nombreux KPI de développement logiciel traditionnels et agentiques s'appliquent au développement de nouveaux projets (greenfield). Ces indicateurs partent du principe que l'architecture est connue, que la documentation est accessible et que le développement porte sur un nouveau projet. Ces indicateurs privilégient la vélocité.

Lors de la migration de systèmes de type « Brownfield », la vélocité sans exactitude ne constitue pas une réussite ; elle génère de la dette technique à la vitesse de l'IA.

Le cadre de KPI défini pour ce projet s'articule autour de trois questions :

Le code fonctionne-t-il ? Taux d'équivalence fonctionnelle, taux de réussite aux tests d'intégration, taux d'échec des changements. Ces indicateurs sont décisifs (go/no-go) : Si le code refactorisé ne produit pas de résultats identiques à l'original pour des entrées identiques, aucun autre facteur ne compte.

Comprenons-nous son fonctionnement ? Taux d'acceptation par le personnel de développement, delta de couverture de test, taux d'achèvement de la migration Une migration n'est pas terminée une fois que le code s'exécute. Elle s'achève lorsque les équipes de développement chargées de sa gestion peuvent le lire, lui faire confiance et en assurer la maintenance.

L'équipe peut-elle en assumer la responsabilité à long terme ? Score de confiance du personnel de développement, délai avant la première contribution, gain de capacité de développement Le principal indicateur de retour sur investissement (ROI) ne réside pas dans le coût par jeton par tâche. Cet indicateur mesure le temps que l'équipe d'ingénierie récupère sur les tâches de migration répétitives pour se consacrer à des contributions de mission à plus forte valeur ajoutée.

Les indicateurs de vélocité (débit, latence d'itération, actions de l'agent par minute) figurent sur un tableau de bord d'ingénierie pour optimiser le système. Ces indicateurs n'ont pas leur place dans une revue de programme en tant que mesures de réussite.

Possibilités offertes par Red Hat AI et OpenShift AI

Ce processus nécessite une plateforme capable de le prendre en charge efficacement. OpenShift AI fournit la couche logicielle de base pour l'ensemble des éléments décrits ici :

• Service de modèles avec vLLM : Une inférence efficace et évolutive pour les modèles de codage et de raisonnement qui alimentent le système d'orchestration.
• Flux de travail de personnalisation des modèles : Prise en charge du réglage fin, de LoRA et de la quantification pour les modèles devant s'exécuter dans des environnements aux ressources limitées.
• Prise en charge des clusters déconnectés : La plateforme permet un fonctionnement dans des environnements sans accès à internet, ce qui constitue ici un prérequis fondamental.
• Journalisation des audits et observabilité : La traçabilité et l'explicabilité requises par les parties prenantes de la mission sont intégrées à la plateforme plutôt que greffées a posteriori.
• Architecture modulaire et conteneurisée : Les agents sont conteneurisés, interchangeables et déployables via l'infrastructure OpenShift existante, déjà maîtrisée par les intégrateurs de systèmes, les entreprises aérospatiales et le gouvernement fédéral.

Figure 2 :  Composants et fonctionnalités pour la création d'agents avec Red Hat AI.

L'ajout de RHEL 10 en tant qu'environnement d'exécution cible n'est pas fortuit. RHEL 10 apporte un durcissement de la sécurité, une mise à jour de l'exécution pour les langages Python et Java modernes, ainsi que la fiabilité opérationnelle requise par les systèmes gouvernementaux. La migration vers cette version ne relève pas uniquement du cycle de vie logiciel, elle constitue une décision stratégique pour la sécurité et la préparation des missions (mission readiness).

Schéma global : Maillage d'agents (agent mesh) à travers les domaines de mission

Ce projet constitue une occurrence unique d'un processus que nous prévoyons de reproduire au sein de la base industrielle de défense, du gouvernement fédéral et, plus largement, de l'industrie. Les parcs logiciels existants sont considérables. Les ressources d'ingénierie permettant une migration manuelle font défaut à l'échelle requise par l'ampleur du problème. De plus, le délai de sécurité pour l'exécution de logiciels non pris en charge s'amenuise.

L'IA agentique sur une plateforme telle qu'OpenShift AI constitue un multiplicateur de force. Elle permet à une équipe d'ingénierie qualifiée de superviser la migration d'une base de code dont la modernisation manuelle prendrait des années. Ce processus s'effectue en une fraction de temps, avec la rigueur et la traçabilité exigées par les environnements critiques.

Dans ce modèle, les dispositifs agentiques coordonnent des agents spécialisés afin de réaliser des tâches de modernisation distinctes. À mesure que ces dispositifs s'étendent aux fonctions adjacentes (tests, examen de la sécurité, validation du déploiement, par exemple), ils commencent à former un maillage d'agents (agent mesh), une architecture composée de plusieurs plateformes d'agents coordonnant des workflows d'ingénierie complexes au sein de vastes parcs logiciels.

Les agents effectuent les tâches répétitives. Les équipes d'ingénierie assurent l'architecture, la supervision, l'évaluation des agents et la gestion des exceptions. Cette répartition du travail constitue le modèle.

Petits modèles Inférence efficace Agents modulaires Fonctionnement déconnecté Modernisation des systèmes en adéquation avec la mission

Réflexion finale

Les modèles de pointe constituent des moteurs de raisonnement puissants. Les plateformes agentiques spécialisées représentent des instruments au service des missions critiques.

Pour les organismes publics, l'enjeu ne se résume pas à l'adoption de la dernière tendance en matière d'IA. L'objectif consiste à disposer de l'infrastructure et des capacités d'IA nécessaires pour maintenir la sécurité et la modernité des systèmes critiques, tout en restant au service des missions critiques.

Nous développons cette approche avec Red Hat AI.

En savoir plus

• Red Hat AI
• Red Hat OpenShift AI