Le meilleur ROI de l’IA pour le moment est de corriger le code ancien, et non d’écrire du code nouveau

Chaque démo de produit d’IA que je regarde commence de la même manière : une boîte de prompt vide, une demande en anglais clair, et une application fonctionnelle quelques minutes plus tard. C’est un véritable tour de magie. C’est aussi, je dirais, la chose la moins intéressante qui se passe actuellement dans l’IA d’entreprise.

Le travail le plus conséquent se déroule ailleurs, dans un endroit beaucoup moins glamour : à l’intérieur de bases de code de quinze ans que personne ne veut toucher, écrites par des ingénieurs qui ont quitté l’entreprise il y a dix ans, exécutant une logique métier que personne n’a pleinement comprise depuis des années. La plupart des couvertures de l’IA ont cela à l’envers. Le code legacy n’est pas une dette technique. C’est une intelligence métier accumulée : des décennies de décisions, encodées sous forme de logiciel, avec les personnes qui ont pris ces décisions ayant depuis longtemps quitté l’entreprise.

Le développement de nouveaux projets obtient les créneaux de clôture. Le code ancien obtient l’argent, à contrecœur, et généralement sans la compréhension nécessaire pour le dépenser bien.

La véritable pénurie n’est pas les développeurs, c’est la mémoire

Ce n’est pas un problème isolé. Une étude de Pegasystems de 2025, menée par le cabinet de recherche Savanta auprès de plus de 500 décideurs IT dans le monde, estime que l’entreprise moyenne mondiale gaspille plus de 370 millions de dollars par an en raison de son incapacité à moderniser efficacement les systèmes legacy, avec près de 134 millions de dollars liés à des projets de transformation lents et gourmands en ressources seuls.

Nous avons récemment travaillé avec une société de distribution de batteries qui exécutait plus de quinze applications legacy, le type de dispersion qui s’accumule sur vingt ans de fusions, d’intégrations ponctuelles et d’ingénieurs résolvant le problème d’aujourd’hui sans trop penser à celui de demain. Enfouis dans ce code se trouvaient des règles de tarification, des seuils d’inventaire et des contraintes de distribution qui représentaient des années de décisions institutionnelles, écrites nulle part ailleurs que dans une logique que personne n’avait pleinement cartographiée.

Il est tentant d’appeler cela un problème de talent : embaucher plus de développeurs, migrer plus rapidement. Mais vous ne pouvez pas embaucher pour sortir du fait que la personne qui comprenait pourquoi un module fonctionnait d’une certaine manière a quitté l’entreprise en 2014. La plupart des entreprises souffrent d’une pénurie de mémoire, et non d’une pénurie de talents. Et jusqu’à récemment, il n’y avait pas de véritable moyen de résoudre cela à grande échelle. Vous payiez une poignée d’ingénieurs seniors pour conserver les connaissances institutionnelles dans leur tête indéfiniment, ou vous les perdiez le jour où ils partaient.

Ce que l’IA change vraiment

Nous n’avons pas pointé un outil de génération de code sur la base de code ancienne et nous n’avons pas dit de tout réécrire ; c’est à peu près la façon dont vous effacez discrètement la logique métier que vous ne saviez pas exister. Au lieu de cela, nous avons utilisé des agents d’IA pour effectuer les travaux de base sans gloire en premier : tracer la façon dont les quinze applications et plus se connectaient réellement les unes aux autres, faire surface les décisions intégrées dans la logique qui n’avaient jamais été écrites ailleurs, et conserver ce contexte comme quelque chose que l’organisation pouvait interroger, et non comme quelque chose qui ne vivait que dans la tête d’un ingénieur. Cela correspond à ce que d’autres fournisseurs d’IA documentent désormais publiquement : les conseils d’Anthropic sur la modernisation des systèmes COBOL avec Claude Code décrivent la même séquence, en automatisant les phases d’exploration et d’analyse en premier lieu, plutôt que de passer directement à la réécriture.

Les agents n’étaient pas notés sur la quantité de code qu’ils généraient. Ils étaient notés sur la quantité de connaissances institutionnelles qu’ils pouvaient faire surface et conserver. Les ingénieurs ont ensuite travaillé aux côtés des agents sur la migration et la génération de tests réels, en vérifiant l’interprétation des agents de la logique métier par rapport à la façon dont le système se comportait en production, et non en leur faisant confiance aveuglément. Un signal utile que nous avons regardé : l’explication de l’agent d’une règle correspondait-elle à un modèle que nous pouvions vérifier indépendamment dans les journaux de production, ou était-ce une supposition plausible ? L’écart entre ces deux est exactement là où les projets de modernisation de legacy vont généralement mal.

L’estimation originale du projet était de huit mois et demi. Il a été clôturé en quatre, une réduction de 53 %. Mais le résultat le plus durable n’était pas le calendrier. Les connaissances institutionnelles qui disparaissaient auparavant chaque fois qu’un ingénieur quittait l’entreprise sont devenues quelque chose que l’organisation pouvait réellement conserver.

Les ingénieurs logiciels ont passé des décennies à écrire du logiciel. La prochaine décennie pourrait être consacrée à l’excavation, l’IA agissant moins comme un auteur et plus comme un archéologue, reconstruisant soigneusement le raisonnement enfoui dans le code qui a survécu à ceux qui l’ont écrit.

Un cadre approximatif pour faire cela sans casser les choses

Les projets qui se déroulent bien semblent suivre à peu près la même séquence, que le système soit un moteur de tarification ou un pipeline de réclamations ;

Découvrir : cartographier la façon dont les systèmes se connectent réellement, et non la façon dont le diagramme d’architecture de 2016 le dit.

Comprendre : faire surface la logique métier et les hypothèses qui la sous-tendent, en langage clair que peut vérifier un expert de domaine.

Vérifier : contrôler que l’interprétation est correcte par rapport au comportement réel de production, et non seulement par rapport aux commentaires du code.

Transformer : migrer ou reconstruire uniquement une fois que les trois premières étapes sont validées, avec des humains qui valident.

Passer directement à la transformation, et vous ne modernisez pas. Vous pariez avec une logique que vous ne comprenez pas encore.

Pourquoi cela compte au-delà des équipes d’ingénierie

La mémoire institutionnelle ne disparaît pas simplement lorsqu’un ingénieur senior prend sa retraite. Cela devient une responsabilité aiguë au moment exact où une entreprise peut le moins se le permettre : lors d’une acquisition, lorsque le nouveau propriétaire doit comprendre ce qu’il a réellement acheté ; lors d’une migration ERP, lorsque l’ancienne logique doit être traduite dans un nouveau système correctement pour la première fois ; lors d’une audit de conformité ou de réponse aux incidents, lorsque quelqu’un doit expliquer pourquoi le système s’est comporté d’une certaine manière, sous un délai, à un régulateur qui n’acceptera pas « la personne qui l’a construit a quitté en 2014 » comme réponse.

Traité de cette façon, la modernisation de legacy cesse d’être un poste de dépense d’ingénierie et commence à ressembler à une question de résilience organisationnelle, ce qui signifie que ce n’est pas seulement les DSI qui devraient s’en soucier. C’est les DSI qui évaluent ce qui se passe lorsque le personnel technique clé part, les équipes de fusions et acquisitions qui tentent de tarifer ce qu’elles acquièrent réellement, et les conseils d’administration qui réfléchissent à la quantité de connaissances opérationnelles de l’entreprise qui n’existe nulle part ailleurs que dans le code que personne ne lit actuellement.

L’avertissement qui compte

Rien de tout cela ne fonctionne sans surveillance. La version la plus risquée de cette approche est celle où l’interprétation d’un agent de l’ancienne logique métier est faite sans vérification, car les systèmes legacy sont exactement l’endroit où une hypothèse d’IA confiante et erronée coûte le plus cher. L’autonomie totale sur votre dernier microservice est un pari raisonnable. L’autonomie totale sur le moteur de tarification que personne n’a touché depuis 2011 ne l’est pas. La valeur est que l’IA rend possible de redevenir, une fois de plus, les ingénieurs qui comprennent l’entreprise, sur un système que personne ne comprend actuellement. Cela ne les remplace pas.

Où je pense que cela va

Pendant vingt ans, les entreprises ont traité les logiciels legacy comme quelque chose à fuir : un centre de coûts à financer à contrecœur et à moderniser le plus rapidement possible. Je pense que l’IA va révéler que beaucoup de ce code était en fait l’un des dépôts de connaissances les plus précieux que l’entreprise ait jamais construit. Il lui manquait juste quelque chose capable de le lire. Les chercheurs documentent déjà l’autre côté de cette boucle : une revue de la littérature multivocale de 2026 sur le développement assisté par LLM constate que la poursuite actuelle de la vitesse accélérée par l’IA est elle-même en train de créer une « dette d’intégration rapide », du code expédié plus rapidement qu’il ne peut être compris. La modernisation de legacy n’est que la facture qui arrive enfin, une génération plus tôt.

Je serais curieux de savoir si d’autres dirigeants d’ingénierie et de technologie voient le même changement : le retour sur investissement de l’IA se manifeste-t-il davantage dans ce que vous construisez, ou dans ce que vous êtes enfin capable de comprendre et de préserver ? Et pour ceux qui ont essayé de faire tourner des agents d’IA contre un système véritablement ancien et non documenté, où l’interprétation de l’agent a-t-elle tenu sous vérification, et où s’est-elle discrètement effondrée ?