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...