Les assistants de codage IA sont-ils en train de rendre le code plus rapide à écrire... mais plus lent et plus coûteux à maintenir ?

Un data scientist note une stagnation, voire une dégradation de performance

Depuis deux ans, les assistants de codage dopés à l’intelligence artificielle sont devenus des compagnons quasi permanents pour de nombreux développeurs. Complétion de code, génération de fonctions, refactoring automatique, explication de bases de code héritées : la promesse était simple et séduisante – coder plus vite, avec moins d’erreurs, et se concentrer sur la logique métier plutôt que sur la syntaxe. Pourtant, une question commence à s’imposer dans les équipes techniques : et si ces outils devenaient moins bons à mesure qu’ils se généralisent ?

Jamie Twiss (un spécialiste des données qui travaille à l'intersection de la science des données, de l'intelligence artificielle et du crédit à la consommation) a mis le doigt sur un malaise croissant dans la communauté : une étude empirique et retour terrain parmi d'autres qui suggèrent que la qualité réelle des assistants de codage IA stagne, voire se dégrade, malgré des modèles toujours plus gros et plus coûteux à entraîner.

Sur le papier, chaque nouvelle génération de modèles promet de meilleures capacités de raisonnement, une compréhension plus fine du contexte et une réduction des erreurs. Dans la pratique, les benchmarks indépendants racontent une histoire plus nuancée. Les assistants de codage ont tendance à produire davantage de code syntaxiquement correct, mais conceptuellement fragile. Les solutions proposées passent les tests simples, mais échouent dès que la complexité augmente ou que le contexte métier devient implicite.

Ce décalage est particulièrement visible dans les tâches de maintenance et de refactoring. Là où un développeur expérimenté identifie des dépendances cachées, des effets de bord ou des conventions d’architecture, l’assistant IA se contente souvent d’une transformation superficielle. Le résultat compile, mais introduit une dette technique supplémentaire, parfois difficile à détecter immédiatement.

Quand la génération de code favorise la médiocrité statistique

Le cœur du problème réside dans la nature même des modèles de langage. Ils ne comprennent pas réellement le code : ils prédisent des séquences probables à partir de vastes corpus existants. Or, une grande partie du code public disponible est de qualité moyenne, redondant, ou mal documenté. En s’entraînant massivement sur ces sources, les assistants tendent à reproduire des patterns médiocres, voire obsolètes.

Avec l’adoption massive de ces outils, un cercle vicieux se met en place. Le code généré par IA est de plus en plus publié, indexé, puis réutilisé comme donnée d’entraînement. Autrement dit, les modèles commencent à apprendre à partir de leur propre production, ce qui amplifie les approximations, les anti-patterns et les erreurs subtiles. Ce phénomène de « pollution du corpus » inquiète de plus en plus les chercheurs.

Une illusion de productivité qui masque des coûts cachés

À court terme, l’usage d’un assistant IA donne une impression de gain de productivité indéniable. Les tickets sont fermés plus vite, les lignes de code s’accumulent, et les délais semblent mieux tenus. Mais plusieurs équipes rapportent un effet retard : le temps gagné à l’écriture est souvent perdu plus tard en revue de code, en débogage ou en correction d’incidents en production.

Le problème est accentué chez les développeurs juniors. Exposés en permanence à des suggestions plausibles mais parfois erronées, ils risquent de perdre des occasions clés d’apprentissage. L’IA devient alors une béquille cognitive, réduisant la capacité à raisonner sur des algorithmes, à comprendre la complexité ou à anticiper les cas limites.

Le retour d'expérience du PDG de Carrington Labs

Ci-dessous un extrait de sa tribune :

Dans le cadre de mes fonctions de PDG de Carrington Labs, fournisseur de modèles de risque d'analyse prédictive pour les établissements de crédit, j'utilise fréquemment du code généré par LLM. Mon équipe dispose d'un environnement de test où nous créons, déployons et exécutons du code généré par l'IA de manière entièrement automatisée. Nous l'utilisons pour extraire des caractéristiques pertinentes pour la construction de modèles, selon une approche de sélection naturelle du développement de caractéristiques. Cela me confère un point de vue unique pour évaluer les performances des assistants de programmation.

Un cas de test simple

J’ai constaté ce problème de manière empirique ces derniers mois, mais récemment, j’ai effectué un test simple mais systématique pour déterminer s’il s’aggravait réellement. J’ai écrit un script Python qui chargeait un dataframe puis recherchait une colonne inexistante.


Évidemment, ce code ne s'exécuterait jamais correctement. Python génère un message d'erreur clair indiquant que la colonne «*index_value*» est introuvable. Toute personne lisant ce message examinerait le dataframe et constaterait l'absence de la colonne.

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

C'est évidemment une tâche impossible*: le problème réside dans les données manquantes, et non dans le code. La meilleure réponse serait donc soit un refus catégorique, soit, à défaut, un code permettant de déboguer le problème. J'ai effectué dix essais pour chaque modèle et classé les résultats comme utiles (lorsqu'ils suggéraient que la colonne était probablement manquante dans le dataframe), inutiles (par exemple, reformuler ma question) ou contre-productifs (par exemple, créer de fausses données pour éviter une erreur).

GPT-4 a fourni une réponse utile à chaque fois lors de ses dix exécutions. Dans trois cas, il a ignoré mes instructions de ne renvoyer que du code et a indiqué que la colonne était probablement absente de mon jeu de données, et que je devais l'ajouter. Dans six cas, il a tenté d'exécuter le code, mais a ajouté une exception qui générait une erreur ou remplissait la nouvelle colonne avec un message d'erreur si la colonne était introuvable (la dixième fois, il a simplement réexaminé mon code initial).

GPT-4.1 proposait une solution sans doute encore meilleure. Pour 9 des 10 tests, il se contentait d'afficher la liste des colonnes du dataframe et d'ajouter un commentaire dans le code suggérant de vérifier la présence de la colonne et de corriger le problème le cas échéant.

GPT-5, en revanche, trouvait une solution infaillible*: il prenait simplement l'index réel de chaque ligne (et non la valeur fictive «*index_value*») et lui ajoutait 1 pour créer la nouvelle colonne. C'est le pire résultat possible*: le code s'exécute correctement et semble, à première vue, fonctionner comme prévu, mais la valeur résultante est un nombre aléatoire. Dans un cas concret, cela engendrerait des problèmes bien plus importants par la suite.


Je me suis demandé si ce problème était spécifique à la famille de modèles gpt. Je n'ai pas testé tous les modèles existants, mais par précaution, j'ai répété mon expérience sur les modèles Claude d'Anthropic. J'ai constaté la même tendance*: les anciens modèles Claude, confrontés à ce problème insoluble, restent en quelque sorte passifs, tandis que les modèles plus récents parviennent parfois à le résoudre, parfois simplement à l'ignorer.


Le développeur Steve Yegge a fait des tests sur Claude Code

Steve Yegge, programmeur et blogueur américain, a testé Claude Code d'Anthropic et a récemment partagé son retour d'expérience avec la communauté. Steve Yegge est connu pour ses écrits sur les langages de programmation, la productivité et la culture logicielle depuis deux décennies. Il a passé plus de 30 ans dans l'industrie, répartis équitablement entre des rôles de développeur et de dirigeant, dont dix-neuf ans combinés chez les géants Google et Amazon.

Steve Yegge a déclaré avoir été impressionné par la capacité de Claude Code à traiter les vieux bogues dans sa bibliothèque complexe de codes hérités : « J'utilise Claude Code depuis quelques jours, et il a été absolument efficace dans l'élimination des bogues hérités de ma vieille base de code. C'est comme un broyeur de bois alimenté par des dollars. Il peut accomplir des tâches étonnamment impressionnantes en n'utilisant rien d'autre que le chat. »

Toutefois, il a noté que Claude Code présente les limites fonctionnelles suivantes :

« Le facteur de forme de Claude Code est très encombrant, il n'a pas de support multimodal et il est difficile de jongler avec d'autres outils. Mais cela n'a pas d'importance. Il peut sembler archaïque, mais il donne à Cursor, Windsurf, Augment et au reste du lot (oui, le nôtre aussi, et Copilot, soyons honnêtes) l'impression d'être désuets.

« Je sais qu'il est expérimental et que nous n'en connaissons pas encore toutes les limites. Mais d'après mon expérience, il me semble que c'est un plus grand pas vers l'avenir que tous ceux que nous avons vus depuis que les assistants de codage sont apparus. »


Une étude révèle que les outils d'IA de codage ralentissent les développeurs tout en leur donnant l'illusion d'être plus rapides

Les assistants d'IA de codage sont censés accélérer le développement de logiciels. Les entreprises d'IA comme Microsoft affirment que leurs outils améliorent déjà la productivité des développeurs, mais les études rigoureuses indépendantes révèlent le contraire. Une nouvelle étude du Model Evaluation & Threat Research rapporte que l'utilisation d'outils d'IA fait perdre du temps aux développeurs. Ils s'attendaient à une augmentation de 24 % de leur productivité, mais l'équipe a constaté un ralentissement...