Moderniser un vieux logiciel avec des agents IA : ce qui marche vraiment
Mistral a migré 40 000 lignes de Fortran avec des agents, l'équipe de Next.js a trié 1 462 tickets. Deux retours d'expérience qui montrent où l'IA aide, et où l'humain reste indispensable.
Beaucoup de PME font tourner un logiciel critique écrit il y a quinze ou vingt ans : une base de données maison, une application de bureau, un outil développé par un salarié parti depuis. Il marche, mais plus personne n'ose y toucher. Les agents de programmation par IA promettent de faciliter ces reprises. Deux retours d'expérience publiés ce mois-ci, l'un par Mistral AI, l'autre par l'équipe de Next.js, montrent ce qu'ils apportent vraiment. Leur conclusion commune est rassurante et exigeante à la fois.
Mistral : 40 000 lignes de Fortran migrées
Le 9 septembre, Mistral a raconté la migration d'un simulateur de réservoirs d'un opérateur européen de l'énergie, écrit en Fortran 77, vers C++. Le premier lot portait sur 40 000 lignes, sur un ensemble d'environ 300 000. Le code n'avait aucun test et aucune documentation centralisée : la situation de nombreux logiciels anciens.
La méthode, telle que la décrit Mistral :
- D'abord un banc de comparaison. Avant de migrer quoi que ce soit, l'équipe a construit un dispositif qui compare les résultats numériques de l'ancien et du nouveau code, y compris à des étapes intermédiaires choisies par les ingénieurs du client.
- Ensuite la documentation. Plus d'une centaine d'agents ont documenté le code existant, en lisant aussi les anciens documents PDF, chaque contribution étant relue par un agent de revue.
- Enfin la migration, module par module. L'autonomie complète des agents a produit du C++ qui ressemblait à du Fortran, et une organisation entièrement automatisée a calé sur les bogues complexes. L'approche retenue : un travail mené par des humains, avec des agents qui codent, testent et relisent, sur des modules de taille limitée, avec une architecture validée par un ingénieur du métier et une revue humaine de chaque modification.
Les trois leçons tirées par Mistral : construire le banc de comparaison avant d'écrire la moindre ligne de migration ; organiser la documentation avant de compter sur les agents, car ils ne peuvent pas migrer un code que personne ne sait lire ; et préférer, à cette échelle, un flux structuré avec revue humaine à l'autonomie complète comme au travail entièrement manuel.
Next.js : 1 462 tickets traités en trois semaines
Le 4 septembre, l'équipe de Next.js a raconté comment elle a réduit son stock de signalements de bogues. Le 10 août, il comptait encore 2 244 tickets ouverts. Environ trois semaines plus tard, 1 462 avaient été fermés et le stock était passé sous la barre des 1 000. L'équipe a construit un agent de recherche qui, pour chaque ticket, lit la discussion, cherche les corrections liées, tente de reproduire le bogue sur les versions actuelles, puis rend un avis argumenté.
Deux choix méritent l'attention. L'agent était en lecture seule : il pouvait enquêter, pas fermer un ticket ni modifier du code. Et il était configuré pour ignorer les instructions trouvées dans le texte des tickets, une protection contre les tentatives de manipulation. Les mainteneurs ont relu chaque avis avant de fermer. Depuis, l'équipe laisse les agents fermer seuls les cas les plus clairs, jusqu'à 25 par semaine, quand deux agents indépendants sont d'accord ; toute modification de code reste relue par un humain.
Ce que ça veut dire pour votre vieux logiciel
Ces deux expériences disent la même chose : les agents accélèrent énormément le travail de compréhension et de transformation du code ancien, à condition d'être encadrés. Pour une PME, cela change la donne sur trois points :
- Documenter devient abordable. Comprendre ce que fait un vieux logiciel, quelles règles métier il contient, était le poste le plus long d'une reprise. Les agents le raccourcissent fortement, sous relecture humaine.
- Les tests d'abord, toujours. Avant de toucher au code, il faut un moyen de vérifier que le nouveau fait exactement ce que faisait l'ancien : mêmes calculs, mêmes résultats sur vos cas réels. C'est la leçon numéro un de Mistral, et c'est valable sans IA.
- Petit à petit. Une reprise par modules, avec l'ancien et le nouveau qui cohabitent, est moins risquée qu'un grand remplacement en une fois.
Enfin, ces exemples rappellent qu'un agent n'a pas besoin d'agir pour être utile. L'agent de Next.js ne fermait rien lui-même pendant la première phase : il enquêtait et présentait ses preuves, et les humains décidaient. Pour une première utilisation sur un logiciel critique, c'est le bon niveau de confiance.
Ce que nous proposons
Reprendre un logiciel métier ancien fait partie de notre travail : nous commençons par comprendre et documenter ce qui existe, nous construisons les tests de comparaison, puis nous modernisons par étapes, avec une version testable toutes les deux semaines. Le code source et la documentation vous sont remis à la fin. Si un vieux logiciel fait tourner votre entreprise et vous inquiète, nous expliquions aussi dans cet article qu'il n'est pas nécessaire d'avoir tout spécifié pour commencer. Prenons 30 minutes pour en parler.