Faire moderniser son vieux code par une IA casse plus de fichiers qu'elle n'en répare

Vous avez un site qui tourne depuis des années. Un développeur doit remettre à jour l'un de ses fichiers, et il en copie le contenu dans une fenêtre de discussion. Il écrit : « modernise ce code ». La réponse paraît plus propre : des lignes plus courtes, une écriture plus récente. Le lendemain, une page du site tombe en erreur.

Ce scénario n'est pas une fiction. Cinq chercheurs de deux universités bangladaises l'ont testé sur cent fichiers avec cinq assistants, puis ont mesuré le résultat. Leur constat tient en une phrase. Dans ce cadre, demander à une intelligence artificielle de moderniser un fichier isolé abîme plus de fichiers en bon état que cela n'en répare.

Les fichiers testés sont écrits en PHP, le langage qui fait tourner une grande partie des sites web, dont WordPress. Ils viennent de WordPress 4.0, sorti en 2014, et devaient être portés aux règles de PHP 8.3, une version récente du langage, sans changer leur comportement.

Deux mots de vocabulaire. Moderniser signifie remplacer des écritures anciennes par des écritures acceptées par la version actuelle du langage. Préserver le comportement signifie que le fichier continue de produire les mêmes résultats, les mêmes effets, et accepte les mêmes appels. Les deux objectifs ne vont pas ensemble par automatisme.

Ce que les chercheurs ont réellement mesuré

La démarche est simple, et c'est ce qui la rend utile. Chaque assistant reçoit un fichier complet, la consigne, et rien d'autre. Pas le reste du projet, pas les fichiers qui appellent celui-ci, pas les tests, pas les messages d'erreur. Les chercheurs gardent la première réponse, sans correction ni nouvel essai.

C'est l'usage courant : copier un fichier, lire la réponse, l'appliquer si elle paraît correcte.

Pour juger, l'équipe n'a pas demandé aux modèles si leur réponse était bonne. Elle a écrit 630 contrôles cachés, exécutés sur le fichier d'origine puis sur chaque réponse. Ils vérifient que le fichier se charge, qu'il produit les bonnes sorties, et que certains détails internes sont intacts. Deux auteurs les ont relus sans voir les réponses des modèles.

La méthode ressemble à un contrôle technique : on repasse la même voiture sur les mêmes bancs, avant et après, et on compare.

Deux repères servent de comparaison : le fichier laissé tel quel, et Rector, un outil à règles qui réécrit des motifs connus sans intelligence artificielle. Chacun affronte les mêmes contrôles.

Le résultat : au mieux 59 fichiers sur 100

Laissés tels quels, 83 des 100 fichiers passent tous leurs contrôles. Le code ancien fonctionne déjà, pour l'essentiel.

Après passage dans un assistant, le meilleur résultat tombe à 59 fichiers compatibles, obtenu par Claude Sonnet 4. GPT-5 Codex en laisse 58, Gemini 2.5 Pro 55, Gemini 2.5 Flash 50, et Llama 3.3 70B 33.

Selon le modèle, 32 à 51 fichiers qui fonctionnaient sont cassés, contre 1 à 10 fichiers défaillants réparés. Le solde est négatif pour les cinq.

Rector termine à 82 fichiers compatibles contre 83 au départ. Il casse 7 fichiers et en répare 6. Sa préservation n'est pas de l'inaction : il répare 62 contrôles défaillants, autant que la plupart des assistants. Il en casse 12, contre 122 à 215 pour les modèles.

Les chercheurs comptent comme régression tout contrôle qui passait avant et échoue après. Un fichier qui ne se charge plus fait échouer tous ses contrôles d'un coup : ils publient donc aussi le compte par fichier.

L'essentiel des dégâts ne corrige rien d'obligatoire

Un chiffre compte pour votre organisation. Sur les 511 points de modernisation détectés, 37 seulement sont obligatoires, soit 7 %. Les autres sont encore tolérés, mais signalés comme obsolètes, ou facultatifs. Un changement obligatoire est une écriture qui ne fonctionne plus, ou change de résultat, dans la nouvelle version. Un changement facultatif reste valable : syntaxe plus courte, style plus récent.

Autrement dit, 93 % des points détectés ne sont pas nécessaires pour que le code tourne.

Les chercheurs ont ensuite isolé les 73 fichiers compatibles sans aucun changement obligatoire. Les assistants en cassent entre 26 et 44, soit 36 à 60 %. Rector en casse 6, soit 8 %.

C'est la différence entre changer une serrure et refaire la porte : les deux se voient sur une photo, une seule était demandée.

Autre surprise. Gemini 2.5 Pro résout 72,8 % des points de modernisation, le meilleur score. Il finit pourtant avec 55 fichiers compatibles, derrière Claude Sonnet 4, qui en résout 53,2 % et en conserve 59. Le score de modernisation ne dit rien de la survie du fichier.

Pourquoi tant de fichiers ne se chargent même plus

Les chercheurs ont classé chaque régression par cause. Entre 66 % et 81 % des contrôles perdus, selon le modèle, se trouvent dans un fichier qui ne s'exécute plus du tout.

La cause la plus fréquente est une déclaration de type ajoutée que le langage refuse. Une déclaration de type est une étiquette posée sur une fonction : elle annonce ce qu'elle accepte et ce qu'elle renvoie. Mal posée, elle fait rejeter le fichier entier, comme une étiquette illisible bloque un colis au tri.

L'exemple le plus net concerne une méthode spéciale de PHP, qui intercepte l'écriture d'une propriété. Le langage impose qu'elle ne renvoie rien. Claude Sonnet 4 lui ajoute un type de retour qui accepte n'importe quoi : le fichier ne se charge plus, et ses neuf contrôles échouent.

Cette erreur ne demande aucune connaissance de WordPress. Elle se détecte avec les règles du langage seul : un simple contrôle de syntaxe l'aurait arrêtée avant tout test.

Les chercheurs ont simulé ce garde-fou : en écartant toute réponse qui ne passe pas le contrôle de syntaxe, chaque modèle récupère 8 à 15 fichiers. Il reste 14 à 38 fichiers d'écart avec le fait de ne rien toucher. Le contrôle est nécessaire, pas suffisant.

Ce que cela change dans votre façon de faire

L'étude ne dit pas qu'il faut interdire l'IA sur du code ancien. Elle dit qu'un fichier qui paraît plus propre ne prouve rien, et propose une chaîne de vérification simple.

Gardez l'original et comparez au comportement actuel. Le bon repère n'est pas la beauté de la réécriture, mais ce que le fichier faisait avant : une modernisation ne vaut que si elle bat le fichier inchangé.

Faites passer un contrôle de syntaxe, puis chargez le fichier. Refusez tout fichier qui ne se charge pas et gardez l'ancien : cela élimine la première cause de dégât. Un fichier peut aussi passer le contrôle et échouer à l'exécution, parce qu'il appelle du code absent ou change la façon dont les autres fichiers l'appellent.

Demandez le minimum. Une consigne qui ne traite que ce qui bloque dans la version cible réduit les dégâts. L'étude ne prouve pas que cela suffit : cette consigne plus étroite n'a pas été testée.

Relisez les types ajoutés en priorité. C'est le signe le plus visible d'une modernisation, et la source récurrente des fichiers bloqués.

Gardez l'outil à règles pour le mécanique. Rector ne comprend pas l'intention, mais il casse beaucoup moins. L'assistant reste utile pour expliquer ou traiter un cas que les règles ne couvrent pas.

Ce que l'étude ne prouve pas

Les résultats portent sur cinq versions précises de modèles, une seule consigne, et une seule réponse par fichier. Aucune boucle de correction n'est mesurée : c'est la première réponse qui est jugée, pas un assistant qui corrige ses erreurs au fil des essais.

Les 100 fichiers viennent d'un seul projet, WordPress 4.0, choisi pour ses nombreux motifs à moderniser. L'échantillon n'est pas représentatif de tous les projets PHP, et les contrôles portent sur des chemins choisis, pas sur le comportement complet.

Des modèles plus récents feront probablement mieux. La méthode d'évaluation, elle, ne change pas : comparer au code inchangé et séparer modernisation et préservation.

Ce qu'il faut retenir

• Sur 100 fichiers PHP anciens confiés à cinq assistants, aucun n'a laissé autant de fichiers en état de marche qu'en ne touchant à rien : 59 au mieux, contre 83.
• Le modèle qui modernise le plus n'est pas celui qui préserve le mieux. Gemini 2.5 Pro traite 72,8 % des points et garde 55 fichiers valides. Claude Sonnet 4 en traite 53,2 % et en garde 59.
• La majorité des fichiers abîmés n'avaient besoin d'aucun changement obligatoire : les assistants en ont cassé 36 à 60 %, contre 8 % pour l'outil à règles Rector.
• La cause la plus fréquente est banale : le fichier ne se charge plus, souvent à cause d'un type ajouté que le langage refuse. Un contrôle de syntaxe l'aurait écarté.
• Avant de confier du code à une IA : gardez l'original, rejouez les mêmes tests avant et après, imposez un contrôle de syntaxe, et ne demandez que le strict nécessaire.
• L'étude ne dit pas que l'IA est inutile. Elle dit qu'une réponse qui « paraît plus propre » ne prouve rien, et qu'il faut mesurer contre le code qui tournait déjà.