Assistants IA et qualité logicielle : sommes-nous en train d’automatiser nos mauvaises pratiques ?
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 leurs performances
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.
Code Python : Sélectionner tout - Visualiser dans une fenêtre à part
2
É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.Envoyé par GPT-4
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.
Code Python : Sélectionner tout - Visualiser dans une fenêtre à part
2
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.
Les versions plus récentes des grands modèles de langage étaient plus susceptibles de produire un résultat contre-productif lorsqu'elles étaient confrontées à une simple erreur de codage.
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 de 19 %. Une précédente étude a révélé que l'utilisation d'outils d'IA n'augmente pas la vitesse de codage, mais augmente significativement le taux de bogues.
L'étude a porté sur 16 développeurs expérimentés qui travaillent sur de grands projets open source. Les développeurs ont fourni une liste de problèmes réels (corrections de bogues, nouvelles fonctionnalités, etc.) qu'ils devaient traiter - 246 au total - et ont prévu combien de temps ces tâches allaient prendre. Ensuite, les chercheurs ont attribué au hasard à chaque problème l'autorisation ou l'interdiction d'utiliser l'IA pendant le travail sur le problème.
Lorsque l'IA est autorisée, les développeurs peuvent utiliser les outils de leur choix (principalement Cursor Pro avec Claude 3.5/3.7 Sonnet) ; lorsqu'elle est interdite, ils travaillent sans l'aide de l'IA générative. Les développeurs accomplissent ces tâches (qui durent en moyenne deux heures chacune) tout en enregistrant leur écran, puis déclarent eux-mêmes le temps total de mise en œuvre dont ils ont eu besoin. Le travail s'est déroulé entre février et juin 2025.
Lorsque les développeurs sont autorisés à utiliser des outils d'IA, ils mettent 19 % plus de temps à résoudre les problèmes, ce qui représente un ralentissement significatif qui va à l'encontre des convictions et des prévisions des experts. L'écart entre la perception et la réalité est frappant : les développeurs s'attendaient à ce que l'IA les accélère de 24 %, et même après avoir subi le ralentissement, ils pensaient encore que l'IA les avait accélérés de 20 %.
« Nous pouvons clairement constater que les développeurs mettent beaucoup plus de temps lorsqu'ils sont autorisés à utiliser des outils d'IA », ont écrit les chercheurs dans leur rapport.
Vers une utilisation plus mature et plus lucide de l’IA
Faut-il pour autant abandonner les assistants de codage ? Probablement pas. Mais leur positionnement doit évoluer. Ils ne peuvent plus être perçus comme des développeurs virtuels, mais comme des outils d’amplification, utiles uniquement entre les mains de professionnels capables de juger, corriger et contextualiser leurs suggestions.
Les équipes les plus avancées adoptent désormais une approche pragmatique : limitation des usages en production critique, obligation de revue humaine systématique, et formation explicite aux biais et limites de l’IA. L’objectif n’est plus d’écrire plus de code, mais d’écrire du meilleur code, avec une responsabilité clairement assumée par l’humain.
Une question ouverte pour l’industrie du logiciel
Si les assistants de codage IA semblent aujourd’hui « moins bons », ce n’est pas nécessairement parce que la technologie régresse, mais parce que les attentes ont explosé plus vite que les capacités réelles. L’écart entre la promesse marketing et la valeur effective devient plus visible à mesure que ces outils s’installent dans les flux de travail quotidiens.
La vraie question n’est donc pas de savoir si l’IA peut coder, mais dans quelles conditions elle améliore réellement la qualité logicielle sans appauvrir les compétences humaines. Tant que cette question restera sans réponse claire, le doute persistera : et si, à force de vouloir coder plus vite, on finissait par coder moins bien ?
Source : Jamie Twiss
Et vous ?
Que pensez-vous de ces retours d'expérience ? Vous semblent-ils crédibles ou pertinents ?
Répondre avec citation
Partager