Avant, on disait « c’est poubelle »

Vous avez sans doute déjà entendu ce refrain. Un outil métier tourne depuis dix ans dans l’entreprise. Il a été développé par un prestataire avec qui on ne travaille plus, ou par un ancien salarié, ou par les deux à tour de rôle. Un jour il faut le faire évoluer, en sortir les données, ou simplement comprendre pourquoi il calcule ce qu’il calcule. On appelle un expert, puis un deuxième. Et la réponse tombe, à peu près dans les mêmes mots : « c’est trop compliqué », « c’est mal fait », « il n’y a pas de documentation », « la documentation ne correspond plus au code », « le code n’est pas commenté ».

La conclusion n’est pas toujours dite, mais tout le monde l’entend : il faut tout refaire. Avec le devis qui va avec.

J’ai tenu ce discours moi aussi, pendant des années, et pour de bonnes raisons. Quand on facture au jour, comprendre le code d’un autre sans plan ni carte coûte souvent plus cher que de repartir d’une page blanche. Le client finit par payer la découverte, puis la réécriture.

Cette année, chez plusieurs clients, j’ai fait autrement.

Quelques chantiers récents

Le premier : reprendre les données d’un Cegid Manufacturing et d’une Compta v9 datant de 2013. Des versions d’il y a treize ans, plus personne en interne pour expliquer les tables, et des années d’historique de production et de comptabilité que l’entreprise ne voulait pas perdre en changeant d’outil.

Le deuxième : un vieil Odoo v11, sorti en 2017 et hors support depuis longtemps, avec ses modules maison. La question du client était simple à poser et pénible à traiter : qu’est-ce qui relève du standard, qu’est-ce qui a été développé pour nous, et qu’est-ce qu’on peut emporter vers une version récente ?

Le troisième : une application maison en PHP, écrite au fil des années, sans documentation, que l’équipe utilise tous les jours et que personne n’ose plus toucher.

Il y en a eu d’autres. Les technologies n’ont rien à voir entre elles, les histoires non plus, et pourtant le déroulé a été le même à chaque fois. J’ai confié le code, le schéma de la base et des extraits de données à Claude Code (l’agent de développement d’Anthropic, qui travaille directement dans le terminal, lit les fichiers, lance les commandes et interroge les bases). Et à chaque fois, il m’a rendu trois choses :

1. Ce qu’il y a. Quelles tables portent quoi, quels champs servent encore, quels modules sont du standard et lesquels ont été ajoutés, quelles fonctions font vraiment le travail.
2. Comment c’est fait. Les choix de l’époque, les contournements, les endroits fragiles, avec les fichiers et les lignes à l’appui.
3. Comment le faire évoluer. Plusieurs options chiffrables, de la plus légère à la plus lourde, avec ce que chacune suppose pour le client.

Pour Odoo, par exemple, la méthode tient en une idée que n’importe quel développeur connaît mais que personne ne prenait le temps d’appliquer : comparer le code installé avec les sources officielles de la v11. Ce qui diffère, c’est le spécifique. Le reste, on sait où le retrouver dans une version récente. Là où il fallait des jours de lecture à la main, l’agent le fait en une session, et il explique ce qu’il trouve.

Un diagnostic sans procès

Ce qui m’a le plus frappé n’est pas QUE la vitesse, c’est SURTOUT le ton.

Quand un expert découvre le code d’un autre, il y a souvent un réflexe de procès. Le prédécesseur était incompétent, les choix étaient absurdes, rien n’est récupérable. Ce réflexe a parfois du vrai, et il sert aussi un intérêt commercial : plus l’existant paraît mauvais, plus la réécriture se justifie.

Claude Code n’a pas ce réflexe. Il décrit le code tel qu’il est. Quand une partie est fragile, il le dit, il dit pourquoi et ce que ça risque. Quand une partie tient debout, il le dit aussi, même si elle n’est pas écrite comme on l’écrirait en 2026. Et il lui arrive d’expliquer pourquoi le développeur de l’époque a sans doute fait ce choix : une contrainte de version, une base qui ne permettait pas mieux, un besoin client pressé.

Pour un dirigeant, ça change la conversation. On ne lui dit plus que son outil c’est « poubelle ». On lui dit ce qui marche, ce qui est risqué, et ce que coûterait chaque option. Il peut décider au juste prix, en tenant compte de sa taille, de son budget et de qui maintiendra l’outil demain.

Et puis il y a eu ce WordPress

La cerise sur le gâteau, c’est un gros site WordPress infecté par deux charges malveillantes différentes, accumulées au fil du temps. Le site était bloqué : plus de mises à jour possibles, et des spammeurs s’en servaient pour leurs propres envois.

Il y a encore un an, la quasi-totalité des experts, moi compris, auraient dit au client que c’était mort et qu’il fallait refaire le site from scratch. C’était la réponse raisonnable : on ne sait jamais si on a tout trouvé, et un site qu’on croit propre mais qui ne l’est pas coûte plus cher qu’un site neuf.

Cette fois, on l’a nettoyé entièrement. La démarche est classique, c’est son ampleur qui ne l’était pas : comparer chaque fichier du cœur, des thèmes et des extensions avec les versions officielles, chercher le PHP là où il n’a rien à faire, relire la base de données, comprendre comment chacune des deux charges s’installait et se protégeait. Ce travail, aucun prestataire ne le chiffrait à un prix acceptable pour le client. Avec Claude Code, il est devenu faisable dans des délais raisonnables.

Et le client a reçu, en plus d’un site qui fonctionne, un document qui dit exactement ce qui n’allait pas : ce que faisait chaque charge, où elle se cachait, et ce qui a été retiré. C’est ce document qui lui permet de faire confiance au nettoyage, et de comprendre comment ne pas revivre ça.

Pourquoi maintenant

Les assistants de code existent depuis plusieurs années. Ce qui a changé en 2026, c’est que les modèles frontières tiennent un projet entier en mémoire, qu’ils agissent au lieu de seulement suggérer (lancer une requête, lire un résultat, corriger leur hypothèse), et qu’ils le font avec un niveau de rigueur qui, à ce jour, me surprend encore.

Il y a aussi une raison que je n’avais pas vue venir, et que je pose comme une hypothèse : le vieux code est justement celui que ces modèles ont le plus lu. Du PHP des années 2010, des modules Odoo de toutes les versions, des schémas d’ERP documentés sur des forums disparus… Ce qui décourage un développeur de 2026 qui n’a jamais touché ces technologies est, pour le modèle, un terrain familier.

Les limites, pour être honnête

Rien de tout ça ne marche sans quelqu’un qui sait lire le résultat. J’ai écrit sur le paradoxe de l’expert : vous devez être expert pour vérifier ce que dit l’IA, et l’IA ne vous dispense donc pas de l’expertise. Ici, c’est ce qui se passe. Je connais les ERP et la sécurité depuis assez longtemps pour repérer une erreur, poser la bonne question, refuser une recommandation qui ne colle pas au contexte du client. Et l’agent se trompe parfois. Moins qu’avant, mais parfois.

Quelques règles que je m’impose :

• On travaille sur une copie, jamais sur la production.
• Chaque affirmation importante est vérifiée sur les données réelles : une table que l’agent dit inutilisée, on compte ses lignes et on regarde la date de la dernière écriture.
• Les données personnelles et les données sensibles du client ne partent pas chez un fournisseur américain sans y avoir réfléchi. Souvent, le schéma et des données anonymisées suffisent. J’en parle plus longuement dans Déployer l’IA sans enfreindre le RGPD et Où héberger son IA ?.
• Le client garde le livrable : la cartographie, les scripts et les règles. S’il change de prestataire demain, il repart avec. C’est ce que je défendais déjà dans mon carnet de chantier ERP.

Et une question reste ouverte, celle que je posais dans Qui formera les experts de demain ? : si l’agent fait la lecture à la place des juniors, où apprendront-ils à lire du vieux code ?

Pour un dirigeant, ça veut dire quoi ?

Que l’expression bien désagréable à entendre « c’est poubelle » mérite désormais un diagnostic avant d’être acceptée. Votre vieil outil métier contient des années de règles de gestion que personne n’a écrites ailleurs, et ces règles ont de la valeur. Pendant longtemps, les extraire coûtait trop cher. Ce n’est plus vrai dans la plupart des cas que j’ai vus, pour le moment du moins.

Refaire reste parfois la bonne réponse. Mais on peut maintenant le décider en connaissance de cause, avec une carte de l’existant sous les yeux, plutôt que parce que personne n’avait le courage d’ouvrir le capot.

On lit le code. On décide après.