Une IA corrige votre code après une mise à jour : quatre erreurs sur dix passent les tests

Votre équipe installe la nouvelle version d'un logiciel tiers que votre application utilise sans le réécrire. Le lendemain, tout va bien. Le site répond, les écrans s'affichent, les contrôles automatiques passent au vert. Trois semaines plus tard, la comptabilité relève un écart de quelques centimes sur chaque facture. Le calcul est faux, et personne ne sait depuis quand.

C'est le scénario que décrit une étude publiée le 5 novembre 2026. Quatre chercheurs y examinent ce qui se passe quand une intelligence artificielle répare du code après une mise à jour. Leur constat tient en une phrase : la correction peut tourner sans erreur et rendre un résultat faux.

Un mot de vocabulaire avant d'aller plus loin. Un test automatique est un petit programme qui vérifie qu'une fonction rend bien le résultat attendu. Vert signifie conforme, rouge signifie cassé. Toute la suite de cet article repose sur cette distinction.

Le jour où les totaux ne tombent plus juste

Les chercheurs ont étudié trois briques très répandues. D'abord le langage Python. Ensuite Node.js, qui fait tourner une grande partie des sites web. Enfin SQLite, la petite base de données intégrée à d'innombrables applications.

Ils ont recensé 60 changements documentés par les éditeurs de ces trois briques. Chaque changement correspond à une note de version, ce feuillet que l'éditeur publie à chaque mise à jour et que presque personne ne lit. Puis ils ont écrit 73 petites tâches de maintenance, chacune avec un avant et un après.

Trois exemples suffisent à comprendre le problème.

Une énumération — une liste fermée de valeurs autorisées — s'affichait « Priority.HIGH ». Après la mise à jour, le même appel affiche « 3 ». Le programme ne plante pas. Il écrit simplement autre chose dans vos rapports.

La fonction de somme de Python est devenue plus précise. Le résultat est meilleur au sens mathématique. Il ne correspond plus aux totaux déjà enregistrés dans votre comptabilité, et l'écart se propage de mois en mois.

Dans Node.js, la taille d'un tampon mémoire — la zone où le programme range les données qu'il envoie — a été multipliée par huit. Les fichiers envoyés sont découpés autrement. Personne ne voit d'erreur.

Ces trois cas ont un point commun. L'appel réussit, et le résultat change.

Quarante et une corrections fausses sur cent

Les chercheurs n'ont pas seulement regardé ce que produisent les modèles d'IA. Ils ont d'abord listé toutes les corrections plausibles prévues par leur banc d'essai. Puis ils ont demandé à un contrôle classique de les trier.

Ce contrôle exécute chaque correction sur des cas d'usage ordinaires, puis vérifie que le résultat correspond à ce qu'on attend. C'est exactement ce que fait une chaîne d'intégration automatique dans une entreprise.

Résultat : 41 % des corrections fausses franchissent ce contrôle. Autrement dit, quatre erreurs sur dix passent pour du bon code.

Le chiffre surprend, mais il s'explique. Les cas d'usage ordinaires sont ceux que tout le monde pense à tester. Ils décrivent la journée normale, jamais le jour où la donnée arrive dans un format inattendu.

L'analogie est celle du contrôle technique. Un examinateur qui vérifie seulement que le moteur démarre délivre le papier à une voiture dont les freins sont morts. Le véhicule roule. Il ne s'arrête pas.

Une seule vérification change presque tout

Les chercheurs ont alors ajouté un cas de test unique, écrit directement à partir de la note de version. Ce cas reproduit précisément la situation que l'éditeur décrit comme modifiée.

La part de corrections fausses acceptées tombe de 41 % à 6,5 %. Sur quinze changements que les chercheurs n'avaient jamais utilisés pour trouver ce résultat, la chute est la même : de 47 % à 6,1 %.

Le revers de la médaille est nul. Le nombre de bonnes corrections rejetées par erreur reste à 1 %.

Un test écrit depuis la note de version, et non depuis le code, suffit donc à bloquer l'essentiel du problème. C'est un geste d'une heure pour une équipe qui sait ce qu'elle cherche.

Les modèles testés confirment ce mécanisme. Sur 456 tentatives, l'un d'eux a produit 98 corrections fausses qui passaient le contrôle ordinaire. Avec le cas supplémentaire, il n'en reste que 24. Un autre passe de 71 à 8, un troisième de 49 à 7.

Ce que l'IA ne fait pas d'elle-même

Reste une question pratique. Pourquoi l'assistant ne rédige-t-il pas ce test tout seul ?

Les chercheurs ont essayé. Ils ont demandé au modèle d'écrire ses propres tests avant de réparer le code. Les résultats s'améliorent, mais peu : de 98 à 80 corrections fausses pour l'un, de 71 à 47 pour un autre. Aucune de ces améliorations ne résiste à un contrôle statistique sérieux.

La raison est simple à énoncer. Un modèle qui se trompe sur le sens d'un changement se trompe aussi sur le test qu'il écrit pour le vérifier. Il vérifie sa propre erreur.

Ils ont aussi testé une variante plus subtile. Un modèle extérieur lit la note de version et propose des cas de test. Il ne voit ni le programme ni les attentes gardées secrètes. Trois cas suffisent pour descendre à 7 %.

Un détail de cette expérience mérite d'être retenu. Les chercheurs ont demandé à ce modèle de signaler les cas où l'ancien résultat ne fait plus référence. Il s'est trompé précisément sur les cas révélateurs. Confier à une machine le soin de trier ses propres intuitions reste fragile.

Ce que votre équipe peut mettre en place cette semaine

Ajoutez un test par mise à jour, pas par fonction. Pour chaque logiciel mis à jour, lisez la note de version et écrivez un cas qui reproduit le changement décrit. Un seul cas suffit souvent.

Faites écrire ce test par quelqu'un qui n'a pas réparé le code. Le modèle qui corrige est le dernier à qui demander comment vérifier sa correction. Un collègue, un autre assistant, peu importe : la séparation compte plus que l'outil.

Gardez l'ancien résultat comme référence. La sortie du programme avant mise à jour est votre meilleure preuve. Conservez-la pour les traitements qui touchent à l'argent, aux stocks ou aux contrats.

Traitez le silence comme un signal. Une correction qui tourne sans erreur n'est pas une correction juste. Sur les changements étudiés, 25 des 66 tâches concernées échouaient sans jamais lever d'erreur.

Ne comptez pas sur le modèle pour se relire. Les tests qu'il écrit lui-même n'ont pas produit de gain mesurable. Le contrôle utile vient de l'extérieur.

Ce qu'il faut retenir

• Une IA peut réparer du code après une mise à jour et rendre un résultat faux sans afficher la moindre erreur.
• Sur l'ensemble des corrections possibles, 41 % des mauvaises passent un contrôle de tests ordinaire.
• Un seul cas de test écrit depuis la note de version fait tomber ce taux à 6,5 %, sans rejeter les bonnes corrections.
• Les tests qu'un modèle écrit pour lui-même n'apportent pas de gain mesurable.
• 25 des 66 changements étudiés se manifestent sans aucun message d'erreur.
• Pour chaque mise à jour : un cas de test écrit par quelqu'un d'autre, et l'ancien résultat conservé comme référence.