Moderniser un logiciel ancien avec des agents IA

Un retour d'expérience qui concerne aussi les PME

Dans l'article « Modernizing complex legacy code with AI agents », signé par Carlo Antonio Patti et Rasul Alakbarli, l'équipe d'IA appliquée de Mistral raconte la migration d'un simulateur de réservoir appartenant à un opérateur énergétique européen. Le code d'origine était écrit en Fortran 77, ne disposait d'aucune suite de tests ni d'une documentation centralisée, et devait être réécrit en C++ moderne. Le premier sprint a porté sur 40 000 lignes, sur un total de 300 000.

À première vue, ce projet semble très loin du quotidien d'une TPE ou d'une PME francilienne. Pourtant, le problème de fond est universel : un logiciel cœur de métier construit il y a longtemps, dont les auteurs sont partis, dont la logique n'est écrite nulle part ailleurs que dans le code lui-même, et que l'on hésite à faire évoluer de peur de tout casser.

Chez comm.it, nous rencontrons régulièrement cette situation sous d'autres formes : une application de gestion développée en interne il y a des années, un outil de facturation bricolé autour d'une base de données vieillissante, des scripts d'automatisation que seul un ancien collaborateur comprenait, un CRM ou un ERP maison qui a grandi sans plan d'ensemble. Les enseignements tirés par Mistral s'appliquent remarquablement bien à ces cas.

Cet article reprend les grands principes de ce retour d'expérience et explique comment nous les transposons dans nos missions de modernisation logicielle, d'automatisation et d'intégration de l'IA pour nos clients.

Traduire du code ne suffit pas : il faut le repenser

L'un des messages les plus importants de l'article source est le suivant : traduire une syntaxe d'un langage à un autre est devenu une tâche largement maîtrisée par les modèles d'IA récents. Ce qui reste difficile, c'est la refonte architecturale.

Le Fortran 77 illustre bien ce piège. Ce langage ne connaît ni modules, ni espaces de noms, ni types structurés. L'état du programme vit dans des blocs COMMON, c'est-à-dire une mémoire globale partagée par tout le programme. Les variables sont typées implicitement selon leur première lettre, si bien qu'une faute de frappe crée silencieusement une nouvelle variable au lieu de déclencher une erreur. Les noms sont limités à six caractères et deviennent vite cryptiques.

Passer à un langage orienté objet impose donc de regrouper des données éparpillées dans des structures cohérentes, de remplacer des écritures globales par des valeurs de retour, de déplacer des boucles d'un endroit à un autre. Résultat : il n'existe plus de correspondance ligne à ligne entre l'ancien et le nouveau code, ce qui rend la vérification de la migration particulièrement délicate.

Ce que cela signifie pour vos applications métier

Dans une PME, le constat est le même, même si les technologies diffèrent. Recopier à l'identique un vieil outil dans un langage récent ne règle rien : vous obtenez un logiciel neuf qui garde toutes les faiblesses de l'ancien. La vraie valeur d'une modernisation tient dans trois questions :

• Quelle architecture cible permettra de faire évoluer l'outil sereinement pendant les années à venir ?
• Comment découper le travail en morceaux gérables, sans interrompre l'activité ?
• Comment prouver que le nouveau système fait exactement ce que faisait l'ancien ?

Ce sont précisément les trois questions que se posait l'équipe de Mistral avant de lancer le moindre agent. C'est aussi par là que nous commençons chaque projet.

Premier principe : construire le filet de sécurité avant de migrer

Avant de laisser travailler les agents, les auteurs ont bâti ce qu'ils appellent un harnais de parité (parity harness). L'idée est simple : démontrer que les deux versions du logiciel produisent les mêmes résultats numériques, non seulement en sortie finale, mais aussi sur des points intermédiaires critiques identifiés par les ingénieurs du client.

Concrètement, l'équipe a ajouté :

• des sous-programmes capables d'exporter l'état de l'ancien code à des moments précis ;
• un framework de test permettant de recharger ces points de contrôle dans le nouveau code ;
• des fichiers d'instructions destinés à guider les agents pour qu'ils utilisent correctement ces outils.

Selon les auteurs, cet investissement initial a été largement rentable : il a sécurisé les longues sessions de travail des agents et fourni un argument simple et convaincant pour déclarer un module terminé. Ils recommandent d'en faire l'une des toutes premières étapes de tout projet de modernisation.

Notre transposition : des tests de non-régression métier

Pour une PME, un simulateur physique laisse place à des calculs bien plus familiers : un montant de facture, une remise, un stock, un planning, une commission commerciale, une relance client. Le principe reste identique. Avant de toucher au code, nous cherchons à capturer le comportement actuel de l'outil :

• en identifiant avec vos équipes les cas d'usage critiques et les résultats attendus ;
• en enregistrant des jeux de données de référence produits par l'ancien système ;
• en mettant en place des tests automatisés qui comparent systématiquement ancien et nouveau comportement.

Ce filet de sécurité a un double bénéfice. Côté technique, il permet de travailler vite sans craindre les régressions. Côté direction, il fournit une preuve objective que la migration est réussie, bien plus parlante qu'une simple assurance verbale du prestataire.

Deuxième principe : documenter avant de migrer

Dans le projet décrit par Mistral, la documentation était dispersée entre de vieux PDF et des commentaires enfouis dans le code. L'un des bénéfices annexes les plus importants a été de réconcilier cette documentation et de la rapprocher du code.

La méthode est élégante. Un programme procédural peut être représenté sous forme d'un arbre d'appels (qui appelle qui). L'équipe a généré cet arbre avec un analyseur sur mesure, puis a lancé plus d'une centaine d'agents pour documenter chaque nœud, en partant des feuilles et en remontant vers la racine. Chaque agent pouvait consulter les PDF pertinents grâce à de la reconnaissance de caractères (OCR) et proposait sa contribution sous forme de demande de fusion. Un agent relecteur, déclenché à intervalles réguliers, examinait les nouvelles propositions et planifiait des corrections si nécessaire.

La leçon formulée par les auteurs est limpide : on ne peut pas migrer un code que personne ne sait lire.

Notre transposition : rendre au savoir métier sa juste place

C'est souvent le chantier le plus sous-estimé dans les PME, et pourtant celui qui apporte le plus de valeur immédiate. Le jour où la personne qui connaissait l'outil quitte l'entreprise, une partie du savoir-faire de l'entreprise risque de disparaître avec elle.

Nous utilisons l'IA pour :

• cartographier l'application existante : modules, dépendances, flux de données, échanges avec la messagerie, le réseau ou d'autres logiciels ;
• générer une documentation lisible, rattachée au code, puis la faire valider par vos équipes ;
• rassembler les sources éparses (anciens cahiers des charges, tableurs, notes internes, documents scannés) pour reconstituer les règles de gestion.

Même si vous décidez finalement de ne pas migrer tout de suite, cette documentation réduit votre dépendance à une seule personne et facilite toute évolution future.

Troisième principe : structurer les agents et garder l'humain dans la boucle

La partie la plus instructive de l'article concerne le degré d'autonomie accordé aux agents IA. L'équipe a testé plusieurs approches avant de trouver la bonne.

Première tentative : autonomie totale. Un agent par sous-programme, chacun traduisant sa fonction de manière indépendante pendant une semaine. Le résultat fonctionnait, mais ce n'était pas une modernisation : les blocs globaux étaient simplement devenus des structures globales, les sauts de type GOTO étaient conservés tels quels. En somme, de l'ancien code retapé dans une nouvelle syntaxe.

Deuxième tentative : des agents spécialisés. Un planificateur, un codeur, un testeur et un relecteur qualité travaillant ensemble sur chaque module. La qualité du code s'est nettement améliorée. Mais face à la complexité du code source, les agents finissaient par buter sur un bogue, tenter quelques corrections, puis rester bloqués faute d'intervention.

Solution retenue : un humain pilote un workflow d'agents. Un opérateur supervise un enchaînement codeur, testeur et relecteur, module par module. On conserve la qualité de la deuxième approche, tout en ajoutant un point de contrôle humain capable de débloquer les agents.

Le workflow détaillé

Avec les ingénieurs du client, l'équipe a utilisé l'arbre d'appels pour isoler des modules indépendants de taille raisonnable, empiriquement moins d'environ 10 000 lignes. Chaque module suivait le même parcours :

1. génération de l'architecture cible ;
2. revue de cette architecture par un expert métier ;
3. après validation, découpage en une file de tâches ;
4. pour chaque tâche, une boucle planifier, implémenter, tester, recommencer ;
5. revue humaine des propositions de code jusqu'à leur fusion.

Notre transposition : l'IA comme accélérateur, l'expertise comme garde-fou

C'est exactement la philosophie que nous défendons chez comm.it. Les agents IA sont des accélérateurs puissants pour analyser, réécrire, tester et documenter. Mais ils ne remplacent ni la compréhension de votre métier, ni le jugement d'un développeur expérimenté.

Dans nos projets de développement de CRM, d'ERP ou d'outils métier, nous organisons le travail ainsi :

• validation de l'architecture avec vos référents métier avant toute écriture de code ;
• découpage progressif pour livrer des modules utilisables au fil de l'eau plutôt qu'une bascule unique et risquée ;
• agents encadrés par des workflows clairs et par nos propres développeurs, qui relisent, corrigent et décident ;
• revues systématiques avant toute mise en production.

Cette approche permet de bénéficier de la vitesse de l'IA sans en subir les dérives, comme ce code qui « marche » mais reste impossible à maintenir.

Connaître les limites pour mieux s'engager

Les auteurs ont l'honnêteté de préciser les conditions favorables de leur projet : le code d'origine était autonome et exécutable, ce qui facilitait grandement les comparaisons. Ils reconnaissent que des migrations dépendant de systèmes externes, sans version de référence exécutable, ou reposant sur des règles documentées nulle part, poseraient des difficultés supplémentaires non traitées dans leur article.

Cette lucidité est précieuse. Dans les PME, les applications anciennes sont rarement isolées : elles échangent avec une messagerie, un logiciel comptable, un site web, des équipements réseau, parfois des systèmes de vidéosurveillance ou de contrôle d'accès. C'est là que notre double compétence prend tout son sens. En maîtrisant à la fois le développement logiciel, l'automatisation des processus et l'infrastructure réseau, nous pouvons évaluer l'ensemble des dépendances d'un outil avant de proposer un plan de migration réaliste.

Nous préférons toujours un diagnostic initial honnête à une promesse intenable : certains outils méritent d'être migrés, d'autres d'être simplement documentés et sécurisés, d'autres encore d'être remplacés par une solution plus standard.

Ce qu'il faut retenir

Les trois enseignements mis en avant par l'équipe de Mistral résument parfaitement la démarche à adopter :

• Construire le filet de sécurité d'abord : des tests de parité sont la preuve la plus simple et la plus convaincante qu'un module est terminé.
• Remettre la documentation en ordre avant de s'appuyer sur les agents : on ne migre pas un code que personne ne comprend.
• Privilégier des workflows structurés avec revue humaine : à grande échelle, ils surpassent aussi bien l'autonomie totale que le travail entièrement manuel.

Pour une TPE ou une PME, ces principes se traduisent par des bénéfices concrets : réduction de la dépendance à des personnes clés, sécurisation des outils qui font tourner l'activité, ouverture vers des technologies maintenues et vers de nouvelles automatisations, et capacité à intégrer l'IA sur des bases saines.

Comment comm.it vous accompagne

Que votre application métier ait cinq ou vingt ans, la démarche commence toujours par une écoute attentive de vos besoins. Nous pouvons intervenir à chaque étape :

• audit et cartographie de vos logiciels existants et de leurs dépendances ;
• documentation assistée par IA pour préserver votre savoir-faire ;
• mise en place de tests de non-régression adaptés à vos règles de gestion ;
• modernisation progressive ou développement sur mesure de vos outils cœur de métier ;
• automatisation des processus qui gravitent autour de ces outils.

Prêt à transformer ces enjeux en avantage concurrentiel ? Contactez comm.it pour en discuter.

Source : Modernizing complex legacy code with AI agents | Mistral