Le module a passé. Tous les tests au vert, chaque critère d'acceptation signé, une modernisation dont l'équipe était fière : une vieille routine tout croche, réécrite en un service moderne propre en une fraction du temps que ça aurait pris à la main. Le monde est passé à autre chose. Puis, trois semaines plus tard, ça a planté, sur un seul cas que personne n'avait pensé à tester, parce que le comportement dont il avait besoin n'était écrit nulle part où un test pouvait le rejoindre. Le vieux code avait une raison. Le nouveau code avait le code.
J'ai vu une version de cette scène se rejouer pendant 25 ans dans la livraison de logiciels d'entreprise, bien avant que l'IA sache faire la réécriture. Ce qui a changé, c'est la vitesse, et je veux lui donner son dû avant de me plaindre de quoi que ce soit, parce que les gains sont réels et que le monde qui les livre n'est pas naïf. Le piège est ailleurs. La modernisation n'est plus lente; elle a juste l'air finie quand elle est à moitié faite.
La modernisation du code hérité par IA est-elle vraiment rapide maintenant?
Oui. Pour vrai. C'est le bout où je refuse d'être la personne qui balaie une vraie avancée du revers de la main parce qu'elle complique mon argument, parce que l'avancée est réelle et les chiffres ne sont pas subtils. Du travail qui mangeait des trimestres prend maintenant des jours, et un gros morceau de la vieille corvée de modernisation, la traduction mécanique d'un cadre ou d'une version de langage vers un autre, est pas mal tombé de la courbe d'effort.
Assois-toi une seconde là-dessus. Mille applications, deux jours, cinq personnes. Le grand patron d'Amazon a plus tard chiffré le total à environ 4 500 années-personnes de travail sauvées sur son parc Java, avec plus de la moitié de ses systèmes Java de production modernisés en moins de six mois. Les chiffres de fournisseur méritent la pincée de sel habituelle, et ici c'est un fournisseur qui décrit son propre outil sur son propre code. Même coupé de moitié, ça décrit un vrai virage. Des migrations de cœur de système qui étaient jadis des marathons d'une carrière se bouclent dans un seul exercice financier. Si c'était toute l'histoire, je n'aurais rien à écrire, et j'en serais bien content.
Pourquoi du code modernisé passe tous les tests et plante quand même en semaine trois?
Parce qu'un transpileur traduit la syntaxe, pas l'intention. Cette phrase, c'est tout l'article, alors laisse-moi ralentir dessus. Une réécriture automatisée est extraordinairement bonne pour répondre à une question : qu'est-ce que ce code fait? Elle lit la branche, reproduit la branche, et les tests, eux aussi écrits contre ce que le code fait, virent au vert. La question qu'elle ne peut pas répondre, c'est celle qui compte vraiment sur la prochaine décennie : pourquoi cette branche est là au juste?
Ce ne sont pas les mêmes questions. Pantoute. Le « quoi » est lisible dans le source; une machine peut l'extraire, et de plus en plus, elle l'extrait magnifiquement. Le « pourquoi » n'est généralement pas dans le source du tout. Il vit dans une décision que quelqu'un a prise en 2009 après une mauvaise nuit, dans la lettre d'un régulateur, dans la mémoire musculaire d'une analyste partie depuis à la retraite au bord d'un lac quelque part et qui ne répond plus aux courriels. Le code, c'est le fossile. Le raisonnement qui l'a déposé, c'est le tissu mou, et le tissu mou, c'est exactement ce qui ne fossilise pas.
Et l'ampleur de ce tissu mou est facile à sous-estimer, parce qu'une bonne partie du monde roule encore sur du code assez vieux pour avoir des enfants.
Chacune de ces lignes est une décision qu'une personne a un jour prise pour une raison. Multiplie une fraction d'entre elles par les raisons que personne n'a captées, et tu as la vraie dette d'un programme de modernisation. Ce n'est pas la syntaxe. La syntaxe, c'est le bout pas cher astheure. Le bout cher, c'est l'intention, et plus la réécriture devient rapide, plus c'est tentant de sauter par-dessus l'intention et de livrer.
Qu'est-ce qu'une réécriture IA laisse tomber en silence?
Les raisons. Trois sortes, précisément, et je me suis brûlé avec les trois. L'exception enfouie dans une routine de vingt ans, la seule branche qui a l'air d'un bogue jusqu'à ce que tu apprennes qu'elle est porteuse. La règle qu'un analyste retraité a ajoutée après une panne, jamais documentée parce qu'à l'époque, c'était évident pour tout le monde dans la salle. Et la contrainte qui n'a jamais vécu que dans une personne, jamais dans un système, le genre d'affaire où toute l'équipe présumait que les autres le savaient déjà, fait que personne ne l'a dit tout haut, fait que personne ne l'a écrit.
Voici la mécanique cruelle de la chose. Une réécriture qui reproduit fidèlement le code va reproduire fidèlement la logique visible et jeter en silence le raisonnement invisible, parce que le raisonnement n'est pas du code. Pire. Elle blanchit la perte. Le vieux système avait au moins la branche bizarre plantée là comme indice, un artefact qu'on pouvait interroger. Le nouveau système bien propre a l'air tellement soigné, tellement évidemment moderne, que la contrainte manquante ne laisse aucune trace. On n'a pas juste perdu le savoir. On a enlevé la dernière preuve physique que le savoir a déjà existé, ce qui est exactement le piège qu'on a décrit dans la fuite des connaissances : au moment où la personne qui portait le contexte est partie, l'artefact qu'elle a laissé cesse d'être un registre et devient une énigme.
La version la plus étudiée de ça, ce n'est pas une routine COBOL. C'est une banque au complet. En avril 2018, TSB, au Royaume-Uni, a migré environ cinq millions de clients de la plateforme héritée qu'elle louait à Lloyds Banking Group vers un nouveau cœur bâti par sa société mère. Sur papier, c'était une modernisation. Dans les faits, à peu près 1,9 million de clients se sont retrouvés barrés dehors de leurs comptes en ligne, certains voyaient les mauvais soldes, et le ménage a coûté autour de 366 millions de livres, avec par la suite une amende de 48,65 millions ajoutée par les régulateurs.
Le bout intéressant, c'est la revue indépendante que TSB a elle-même commandée et publiée, un geste de transparence rare et vraiment louable. Elle n'a pas blâmé un seul bogue. Elle a conclu que le conseil avait des trous dans sa compréhension de la portée et de la complexité de la nouvelle plateforme, et que les tests n'avaient jamais roulé à l'échelle que le vrai système exigeait. Relis ça avec les lunettes d'aujourd'hui. Personne n'a perdu une ligne de code. Ils ont bougé avant d'avoir pleinement récupéré ce que le vieux système faisait et exigeait vraiment. La syntaxe a migré. La compréhension, non, et aucune vitesse IA n'aurait sauvé une migration rapide dans exactement la mauvaise moitié du problème.
Source : TSB, revue indépendante de la migration TI de 2018 (Slaughter and May).
Peut-on récupérer l'intention avant la réécriture?
On peut. Et c'est le bout vraiment porteur d'espoir, alors je veux lui donner de la vraie place, parce que récupérer l'intention, c'est là que la vitesse arrête d'être une menace et se transforme tranquillement en meilleur outil qu'on ait. Ce n'est pas une seule affaire. C'est deux, et chaque moitié demande un outil très différent.
La première moitié, c'est la logique documentée : les calculs, les chemins de décision, les dépendances qui sont vraiment dans le code, juste emmêlés et sans commentaire. L'IA est excellente là-dedans. Les outils de modernisation les plus crédibles traitent déjà ça comme l'étape un, pas comme une pensée après coup. Quand l'IA analyse des exigences enfouies dans du COBOL, elle peut les faire remonter; watsonx Code Assistant for Z d'IBM offre justement une étape de découverte des règles d'affaires dont le but complet est de faire ressortir les politiques et les calculs enfouis dans les vieilles applications COBOL et de les documenter avant que quiconque touche à la réécriture. Lis ça comme le signal que c'est : le plus gros nom de la modernisation de mainframe a bâti une étape de produit autour de l'idée qu'il faut récupérer les règles d'abord. Personne ne bâtit ça si traduire la syntaxe suffisait.
La deuxième moitié est plus dure, et aucun transpileur ne l'atteint. C'est le raisonnement qui n'a jamais été dans le code : le pourquoi derrière la règle bizarre, la panne qui a provoqué un fix, l'exception qui vit dans une personne. Cette moitié-là, ce n'est pas de l'extraction. C'est de la découverte, la vraie, celle où on s'assoit avec la superviseure qui roule le processus depuis onze ans et où on pose les questions que personne n'a pensé à poser. C'est toute la prémisse de l'intelligence des exigences : traiter l'intention derrière un système comme un artefact de première classe à récupérer et à rendre testable, pas comme un heureux sous-produit de la lecture du code. Dans une modernisation, les exigences, ce n'est pas le code. Ce sont les raisons pour lesquelles le code existe, et ces raisons doivent être ramenées à la lumière avant la réécriture, parce qu'après la réécriture, elles sont parties.
À quoi ressemble une modernisation du code hérité bien faite?
Ça ressemble à faire les deux moitiés dans le bon ordre. La découverte d'abord. La vitesse ensuite.
Concrètement : avant que le transpileur roule, sors les règles documentées du vieux système avec l'IA et mets-les devant du monde, puis fais de la vraie découverte sur les raisons derrière les branches bizarres, celles qui ont l'air fausses jusqu'à ce que quelqu'un explique la panne qu'elles empêchent. Écris chaque raison récupérée comme un énoncé testable, pour qu'elle devienne une exigence qu'un test peut tenir plutôt qu'une histoire qui s'évapore. Là, et seulement là, laisse l'IA aller à pleine vitesse, parce que maintenant elle court vers une cible qui inclut les bouts que tout le monde présumait. La vélocité arrête d'être un risque et devient un levier. C'est tout le recadrage de la modernisation du code hérité par IA : les exigences n'ont jamais été le code, et une fois qu'on les a récupérées, la réécriture est le bout facile, rapide et vraiment amélioré que tout le monde célèbre.
Saute cet ordre et la vitesse joue contre toi. Une réécriture rapide sur une intention non récupérée ne t'épargne pas le travail de découverte. Elle déplace juste la découverte en production, où elle arrive comme un incident au lieu d'une conversation, et où elle coûte plusieurs fois plus cher à régler. Une modernisation sans découverte n'échappe pas aux erreurs du vieux système. Elle les réexpédie, dans un nouveau langage, avec les preuves effacées.
La moitié de la modernisation que l'IA ne peut pas faire à ta place
La modernisation du code hérité par IA est vraiment rapide, et c'est une avancée réelle et précieuse. Un transpileur va transporter ta syntaxe en quelques mois. Il ne transportera pas l'intention : l'exception dans la branche bizarre, la règle qu'un analyste retraité a ajoutée après une panne, la contrainte qui n'a jamais vécu que dans une personne.
Fait que récupère les exigences avant la réécriture. Extrais les règles documentées avec l'IA, découvre les raisons non écrites avec le monde qui les porte, et écris chacune comme un énoncé testable. Ensuite, lâche la vitesse. Fais ça dans cet ordre et la modernisation garde la sagesse durement gagnée du vieux système tout en larguant son âge. Saute-le et tu réexpédies les vieilles erreurs, plus vite, dans un langage que personne ne peut blâmer.
Quelles sont les questions les plus fréquentes sur la modernisation du code hérité par IA?
