Assistants de code IA : la qualité se dégrade-t-elle ?

Ces derniers mois, j'ai remarqué une tendance inquiétante dans le fonctionnement des assistants de code IA. Après deux ans d'amélioration constante, la plupart des modèles de base ont atteint un plateau au cours de 2025 et, depuis peu, ils semblent même régresser. Une tâche qui prenait cinq heures avec l'aide de l'IA, et dix sans elle, en demande désormais sept ou huit, voire davantage. Au point que je retourne parfois à d'anciennes versions des grands modèles de langage (LLM).

J'utilise beaucoup de code généré par des LLM dans mon travail de directeur général de Carrington Labs, un fournisseur de modèles de prévision des risques pour les prêteurs. Mon équipe dispose d'un bac à sable dans lequel nous créons, déployons et exécutons du code généré par IA, sans intervention humaine. Nous l'utilisons pour extraire des variables utiles à la construction de modèles, en appliquant une sorte de « sélection naturelle » à l'ingénierie des variables. Cela me donne une occasion unique d'évaluer les performances des assistants de programmation.

Jusqu'à récemment, le problème le plus courant des assistants de code IA était une mauvaise syntaxe, suivie d'une logique défaillante. Le code produit par l'IA provoquait souvent des erreurs de syntaxe ou s'embrouillait dans une structure incorrecte. C'était frustrant : la solution consistait généralement à relire le code à la main, en détail, pour traquer l'erreur. Mais, au bout du compte, le problème était réparable.

Or les LLM sortis récemment, comme GPT-5, échouent de façon bien plus insidieuse. Ils génèrent souvent du code qui ne fait pas ce qui était demandé, mais qui, à première vue, s'exécute avec succès, en évitant erreurs de syntaxe et plantages évidents. Pour y parvenir, ils suppriment des contrôles de sécurité, fabriquent de fausses sorties au format attendu ou recourent à d'autres astuces qui évitent les défaillances à l'exécution.

Tout développeur vous le dira : un échec silencieux est bien pire qu'un plantage. Les résultats erronés se cachent discrètement dans le code et ne ressurgissent que bien plus tard. Cela crée de la confusion, et c'est beaucoup plus difficile à détecter et à corriger. Ce comportement est si inutile que les langages de programmation modernes sont volontairement conçus pour échouer vite et bruyamment.

Je constatais ce problème de façon sporadique depuis quelques mois, mais j'ai récemment mené un test simple, quoique systématique, pour déterminer si la situation empirait réellement. J'ai écrit du code Python qui chargeait un dataframe, puis cherchait une colonne inexistante.

Il est évident que ce code ne s'exécutera jamais avec succès. Python renvoie un message d'erreur clair, expliquant que la colonne « index_value » est introuvable. Toute personne qui verrait ce message vérifierait le dataframe et constaterait que la colonne est absente.

J'ai envoyé ce message d'erreur à neuf versions différentes de ChatGPT, principalement des variantes de GPT-4 et du plus récent GPT-5. J'ai demandé à chacune de corriger l'erreur, en précisant que je voulais uniquement le code complet, sans commentaires.

C'est évidemment une tâche impossible : le problème vient de données manquantes, pas du code. La meilleure réponse serait donc un refus pur et simple ou, à défaut, du code qui m'aiderait à déboguer le problème. J'ai effectué 10 essais pour chaque modèle et classé le résultat comme utile (lorsque la réponse supposait que la colonne était probablement absente du dataframe), inutile (par exemple, une simple reformulation de ma question) ou contre-productif (par exemple, la création de fausses données pour éviter l'erreur).

GPT-4 a donné une réponse utile 10 fois sur 10. Dans trois cas, il a ignoré mon instruction de ne renvoyer que du code, en expliquant que la colonne était probablement absente de mon jeu de données et que je devrais régler le problème de ce côté. Dans six cas, il a tenté d'exécuter le code, mais en ajoutant une exception qui soit levait une erreur, soit remplissait une nouvelle colonne avec un message d'erreur si la colonne restait introuvable (la 10e fois, il a simplement répété mon code d'origine).

GPT-5, à l'inverse, a trouvé une solution qui fonctionnait à chaque fois : il prenait simplement l'index réel de chaque ligne (et non le fameux « index_value », qui n'existe pas) et lui ajoutait 1 pour créer new_column. C'est le pire résultat possible : le code s'exécute avec succès et semble, à première vue, tout faire correctement, mais la valeur obtenue est en réalité un nombre aléatoire. Dans un cas réel, cela provoquerait un casse-tête bien plus grand plus loin dans le code.

Je me suis demandé si le problème était propre à la famille GPT. Je n'ai pas testé tous les modèles existants, mais, par vérification, j'ai refait l'expérience avec les modèles Claude d'Anthropic. J'ai observé la même tendance : face à ce problème insoluble, les anciens modèles Claude haussent en gros les épaules, tandis que les plus récents résolvent parfois le problème et parfois le balaient simplement sous le tapis.

Je n'ai aucune information privilégiée sur les raisons pour lesquelles les nouveaux modèles échouent de façon aussi pernicieuse. Mais j'ai une hypothèse étayée. Je pense que c'est le résultat de la manière dont les LLM sont entraînés au code.

Les anciens modèles étaient entraînés sur du code à peu près comme sur n'importe quel autre texte. De grands volumes de code présumé fonctionnel servaient de données d'entraînement pour fixer les poids du modèle. Ce n'était pas toujours parfait, comme s'en souvient quiconque a utilisé l'IA pour coder début 2023, avec ses erreurs de syntaxe fréquentes et sa logique défaillante.

Mais ces modèles ne supprimaient certainement pas de contrôles de sécurité et ne trouvaient pas de moyen de fabriquer des données plausibles mais fausses, comme le fait GPT-5 dans mon exemple ci-dessus.

Mais une fois les assistants de code IA lancés et intégrés aux environnements de développement, leurs créateurs ont compris qu'ils disposaient d'une puissante source de données d'entraînement étiquetées : le comportement des utilisateurs eux-mêmes. Si l'assistant proposait du code, que ce code s'exécutait avec succès et que l'utilisateur l'acceptait, c'était un signal positif, le signe que l'assistant avait bien fait son travail. Si l'utilisateur rejetait le code ou si celui-ci ne s'exécutait pas, c'était un signal négatif, et, lors du réentraînement du modèle, l'assistant était orienté dans une autre direction.

C'est une idée puissante, qui a sans aucun doute contribué à l'amélioration rapide des assistants de code IA pendant un certain temps. Mais à mesure qu'arrivaient de plus en plus de programmeurs peu expérimentés, elle a aussi commencé à empoisonner les données d'entraînement. Les assistants qui trouvaient des moyens de faire accepter leur code aux utilisateurs ont continué à le faire de plus en plus, même si « cela » signifiait désactiver des contrôles de sécurité et fabriquer des données plausibles mais inutiles. Tant que la suggestion était acceptée, elle était jugée bonne, et il est peu probable que la douleur ressentie par la suite puisse être remontée jusqu'à sa source.

La toute dernière génération d'assistants de code IA est allée encore plus loin, en automatisant une part croissante du processus de programmation grâce à des fonctions proches d'un pilote automatique. Cela ne fait qu'accélérer le nivellement par le bas, puisqu'il reste moins de points où un humain peut voir le code et comprendre que quelque chose cloche. À la place, l'assistant va probablement continuer à itérer pour tenter d'obtenir une exécution réussie. Ce faisant, il en tire sans doute les mauvaises leçons.

Je crois fermement en l'intelligence artificielle et je considère que les assistants de code IA jouent un rôle important pour accélérer le développement et démocratiser la création de logiciels. Mais la course au gain à court terme et le recours à des données d'entraînement bon marché, abondantes mais finalement de mauvaise qualité continueront de produire des modèles pires qu'inutiles. Pour que les modèles s'améliorent de nouveau, les entreprises d'IA spécialisées dans le code doivent investir dans des données de haute qualité, voire rémunérer des experts pour étiqueter le code généré par IA.

Sinon, les modèles continueront à produire des déchets, à s'entraîner sur ces déchets et, par conséquent, à en produire encore davantage, tel un serpent qui se mord la queue.