Le gain de productivité est réel, mais une question l'accompagne en arrière-plan : quelle est la qualité de ce code, et combien va-t-il vous coûter en maintenance par la suite ? Les recherches scientifiques dressent un tableau qui donne à réfléchir. Le code généré par l'IA est plus long, plus souvent dupliqué et plus difficile à maintenir, avec 1,7 fois plus de problèmes que le code écrit par un humain. Peter Verrykt, Business Unit Lead Data & AI chez Xylos, se penche sur les causes et pose la question que peu osent formuler à voix haute : le code IA verbeux est-il une nécessité technique ou un modèle commercial ?

Avant d'aborder les causes, posons les bases. Ces deux dernières années, plusieurs études à grande échelle ont comparé systématiquement le code IA au travail humain. Ce qu'elles montrent ensemble :

1. Faire correspondre des schémas, pas comprendre

L'architecture d'un modèle de langage prédit à chaque fois le morceau de code suivant le plus probable, sur base de statistiques issues de ses données d'entraînement. Il n'y a là aucun instinct natif d'optimisation, pas plus qu'une conscience de ce qui est superflu ou de ce que la codebase contient déjà.

Un développeur senior qui écrit une fonction de tri sait que la bibliothèque util existante possède déjà une implémentation. Le modèle, lui, ne le sait pas, sauf si cette information figure explicitement dans le contexte. Il écrit donc une nouvelle implémentation, avec gestion des cas limites, logging et documentation inclus.

2. Entraîné sur internet : la quantité prime sur la qualité

Tous les grands modèles de code sont entraînés sur du code public : dépôts GitHub, Stack Overflow, blogs techniques et documentation. Cela semble prometteur, mais internet n'est pas une bibliothèque curated de bonnes pratiques. C'est un fourre-tout : tutoriels détaillés qui expliquent chaque étape, réponses Stack Overflow copiées, vieux code d'entreprise truffé de contournements historiques et projets de débutants à la structure superflue.

La majorité de ces données reflète le développeur internet moyen, rarement le codeur le plus élégant. Les modèles apprennent donc le style statistiquement moyen, pas le style optimal. Ce que le code trouvé sur internet surreprésente :

• Du code pédagogique qui explique tout étape par étape (tutoriels, cours).

• De la programmation défensive avec de nombreux try-catch et une gestion d'erreurs étendue.

• Du boilerplate et des structures basées sur des templates.

• Des schémas dépassés, courants à l'époque mais devenus superflus.

• Du code copié sans adaptation au contexte local.

3. La programmation défensive comme réflexe par défaut

Une étude de CodeRabbit a montré que le code généré par l'IA contient près de deux fois plus de vérifications null, de retours anticipés et de schémas défensifs que le code humain. En développement web, c'est souvent la bonne approche. En data engineering, cela peut tourner à la catastrophe.

Un exemple concret du côté pervers de la programmation défensive dans Claude Code (Medium, novembre 2025). La demande faite à l'IA : écrire une transformation simple pour transformuserrecord(record).

Sortie de l'IA (simplifiée) :

Le problème : dans un pipeline de données, ce schéma masque les enregistrements corrompus. Un user_id manquant devient -1, une valeur en soi valide qui a des effets indésirables en aval. Le modèle a opté pour une robustesse qui serait correcte dans un autre contexte, mais qui pollue ici le pipeline. Le code fait ce qui était demandé, et reste pourtant sémantiquement erroné pour ce cas d'usage.

4. Aucun contexte de la codebase existante

Un agent qui écrit du code sans contexte complet de la codebase démarre chaque fonction comme s'il s'agissait du tout premier bout de code du projet. Les fonctions utilitaires existantes sont réécrites, les constantes codées en dur plutôt qu'importées, et les conventions de nommage de l'équipe sont ignorées.

L'étude longitudinale de GitClear sur 211 millions de lignes de code le montre concrètement : le code copié-collé est passé à 12,3 % de toutes les lignes modifiées, contre 8,3 % en 2021, soit presque une fois et demie plus. Dans le même temps, le refactoring (réutiliser et déplacer du code) est tombé sous les 10 %, contre 25 % auparavant. L'IA duplique là où un humain réutilise.

5. RLHF : récompensé pour des réponses détaillées

C'est le point le plus controversé. Les modèles sont affinés via le Reinforcement Learning from Human Feedback (RLHF). Les évaluateurs humains ont historiquement souvent préféré des réponses plus détaillées qui semblent complètes, même quand une réponse plus courte est techniquement plus correcte. Il en résulte une préférence structurelle pour la verbosité.

Cela ne signifie pas que les modèles ont été délibérément conçus pour facturer plus de tokens. Le résultat reste toutefois le même : des modèles récompensés pour des réponses détaillées produisent du code plus long, et sous une facturation basée sur les tokens, cela joue directement en faveur du fournisseur.

Pour rendre cela concret, comparons à quoi ressemble une tâche typique en style humain et en style IA. Portez attention au nombre de lignes et aux hypothèses implicites. La tâche : valider une adresse e-mail et l'enregistrer dans une base de données.

La version IA est correcte en soi. Dans certains contextes, elle est même meilleure : validation d'e-mail plus stricte, type hints, logging et un objet de retour explicite. Si ce schéma se répète sur l'ensemble d'une codebase, pour chaque fonction utilitaire, il génère des milliers de lignes supplémentaires à maintenir, comprendre et déboguer, alors que la logique métier reste identique.

La structure d'incitation

La tarification actuelle des tokens est asymétrique : les tokens de sortie coûtent 5 fois plus cher que les tokens d'entrée. Chaque ligne de code supplémentaire qu'un modèle écrit génère davantage de tokens de sortie, et davantage de tokens de sortie signifie une facture plus élevée. À court terme, le fournisseur n'a financièrement que peu d'intérêt à être concis.

Cela ne signifie pas que les modèles ont été délibérément conçus pour être verbeux afin de gagner de l'argent. Il n'en reste pas moins un problème structurel d'incitations mal alignées que l'industrie ferait bien de reconnaître honnêtement :

• L'entraînement RLHF récompense les réponses détaillées et complètes, y compris pour le code.

• Les utilisateurs, en particulier les non-techniciens, jugent souvent qu'un code plus étoffé représente « plus de travail » et « plus de valeur ».

• Les fournisseurs mesurent la qualité via des benchmarks (exactitude, réussite des tests), rarement via la longueur du code ou sa maintenabilité.

• Un « score d'efficacité » standardisé pour le code généré fait défaut dans les benchmarks publics.

Le contre-argument

L'autre son de cloche mérite tout autant d'attention. Il existe bel et bien de bonnes raisons pour lesquelles le code IA s'avère plus long :

La conclusion est nuancée. Une partie du code supplémentaire a une valeur réelle. Une autre partie est un artefact du processus d'entraînement et de la structure d'incitation. Le problème, c'est que l'industrie met les deux dans le même panier, avec des conséquences financières et techniques concrètes.

Le code IA verbeux a un effet direct sur votre coût en tokens, mais le coût indirect pèse plus lourd : une dette technique qui s'accumule à mesure que l'IA écrit une part croissante de la codebase.

Le problème des 80 %

Augment Code (avril 2026) a documenté ce qu'elle appelle le problème des 80 % : les agents IA livrent du code qui fonctionne mais reste structurellement incomplet. Un composant de dashboard généré typiquement récupère des données et affiche une grille. Ce qui manque : la gestion des états d'erreur, un loading skeleton, la logique de rafraîchissement des données, les attributs d'accessibilité, les labels ARIA et une vérification d'authentification.

Le piège est dans la finition : ajouter les 20 % manquants après coup coûte plus cher que de construire correctement dès le départ. Chaque correctif exige d'abord de comprendre l'intention derrière le code généré, alors que les agents documentent rarement leurs choix architecturaux.

Quatre mécanismes d'accumulation de dette

• Dette de compréhension : pour chaque correctif, un ingénieur doit reconstituer l'intention du code généré.

• Dette de duplication : le code copié exige des mises à jour synchronisées à plusieurs endroits à chaque correction de bug.

• Dette de test : le code généré s'optimise pour les tests existants, rarement pour les cas limites qui devraient exister.

• Dette d'architecture : le code généré sans vision du système ne s'intègre pas dans les couches d'abstraction existantes.

Pour comprendre en profondeur le comportement de codage de l'IA, il faut regarder les sources. Les grands modèles de code sont entraînés sur des jeux de données qui se recoupent largement.

• Dépôts publics GitHub : la plus grande source. Contient du code remarquable à côté de projets d'étudiants de première année, de projets abandonnés et de code truffé de quick-fixes.

• Stack Overflow : des réponses sous licence CC-BY-SA. Les réponses populaires ne sont pas forcément les meilleures, ce sont les plus « likées », et les likes dépendent en partie de leur accessibilité.

• Blogs techniques et tutoriels : par nature pédagogiques, donc détaillés et pas à pas avec un maximum d'explications.

• Documentation officielle et références d'API.

• CodeSearchNet, The Pile et des jeux de données agrégés similaires, aux normes de qualité variables.

Une étude de Cracks in The Stack (arXiv 2025) a analysé le jeu de données The Stack v2 et a trouvé des attributions d'origine de fichiers incorrectes. Celles-ci conduisent à du code sous licences incompatibles et, plus grave, à du code buggé étiqueté à tort comme valide. Les modèles entraînés sur des données buggées apprennent des schémas buggés. Hubinger et al. ont par ailleurs montré que les LLM peuvent introduire des vulnérabilités et que ce comportement est particulièrement difficile à supprimer par fine-tuning. Un schéma une fois appris reste présent dans le modèle.

Un modèle de langage apprend la distribution statistique de ses données d'entraînement. Il écrit donc du code qui ressemble à la moyenne de GitHub, pas à ses meilleurs 5 %. Les ingénieurs de haut niveau réputés pour leur code élégant et minimal, pensez à un one-liner de Linus Torvalds ou à un contributeur Rust qui évite les blocs unsafe, ne représentent qu'une infime minorité des données. Le fine-tuning par instructions et le RLHF corrigent cela en partie, jamais totalement. Le modèle ne dépasse jamais ses données d'entraînement, et ces données reflètent le développeur internet moyen, rarement le meilleur d'entre eux.

Le message est clair : continuez à utiliser l'IA, car le gain de productivité est réel. Faites-le les yeux ouverts, avec des lignes directrices claires et des contrepoids techniques.

1. Fournissez toujours le contexte de la codebase.
Assurez-vous que l'agent ait accès aux modules, conventions et guides de style existants pertinents avant que le code ne soit généré. Sans ce contexte, l'agent réinvente la roue, avec en prime des rayons et des catadioptres que personne n'a demandés.

2. Définissez un guide de style de codage pour l'IA.
Écrivez explicitement dans votre prompt ou votre instruction système : « Utilise les fonctions utilitaires existantes de /utils, respecte notre nommage défini dans CONVENTIONS.md, n'écris pas de logging inline sauf demande explicite. » L'IA suit les instructions mieux qu'elle ne les extrapole.

3. Demandez délibérément du code concis.
Ajoutez à votre prompt : « Écris le moins de lignes de code possible qui résolvent complètement la tâche. » Les modèles répondent bien aux instructions explicites de concision. Sans cette instruction, ils privilégient l'exhaustivité.

4. Passez en revue le code généré de façon structurelle, pas seulement fonctionnelle. La couverture de tests ne garantit pas que le code fait les bons choix architecturaux. Évaluez aussi : est-ce que cela s'intègre à la structure existante, y a-t-il des doublons, la gestion d'erreurs convient-elle à ce contexte ?

5. Utilisez le linting et l'analyse statique comme garde-fou. Des outils comme Pylint, SonarQube ou ESLint détectent automatiquement la duplication, les code smells et les écarts de style dans le code généré. Intégrez-les comme étape obligatoire dans votre pipeline CI/CD, avant le merge.

6. Mesurez votre code churn par développeur et par outil IA. Le constat de GitClear selon lequel le churn a grimpé à 7,9 % met en lumière un problème qui reste invisible sans mesure. Ajoutez des métriques de churn à votre dashboard d'ingénierie, car un taux de churn élevé est un signal précoce de problèmes de qualité.

7. Ajustez vos attentes selon le modèle. Haiku écrit plus vite mais avec moins de nuance, Opus écrit plus lentement mais avec davantage de conscience architecturale. Sachez quel modèle exécute quelle tâche et calibrez l'intensité de votre revue sur le modèle qui a généré le code.

8. Traitez le code IA comme du code externe. La meilleure pratique du secteur : traiter le code généré par l'IA comme du code provenant d'une bibliothèque externe. Ne lui faites pas confiance aveuglément, comprenez ce qu'il fait, testez-le explicitement et documentez son origine pour la maintenance future.

L'IA écrit du code plus vite. Cela ne fait aucun doute. La vitesse et la qualité restent toutefois deux choses différentes, et plus de lignes de code n'équivaut pas à plus de valeur. Les chiffres donnent à réfléchir : 1,7 fois plus de problèmes, 4 fois plus de duplication, une activité de refactoring divisée par deux et un taux de churn qui a doublé.

Une partie de cette verbosité apporte une valeur réelle : de meilleures annotations de type, une gestion d'erreurs plus robuste, une documentation explicite. Une part substantielle est un artefact de la façon dont les modèles apprennent, à savoir sur la moyenne d'internet, récompensés pour l'exhaustivité et sans vision de la codebase sur laquelle ils construisent.

La question de savoir si des tokens sont brûlés délibérément n'a pas de réponse simple. Les incitations sont structurellement mal alignées, ce qui appelle des contre-mesures délibérées : instructions claires, contexte de codebase, revue par les pairs, linting et suivi du churn. Voyez-y un usage responsable d'un instrument puissant qui connaît ses limites.

Le message clé

• Le code IA compte 1,7 fois plus de problèmes que le code humain (CodeRabbit, 2025), en grande partie à cause de lacunes structurelles dans l'entraînement et les incitations.

• La verbosité a en partie des causes légitimes (robustesse, type-safety), mais est aussi renforcée par un entraînement RLHF qui récompense l'exhaustivité.

• La dette technique s'accumule vite : 4 fois plus de duplication, refactoring divisé par deux, 7,9 % de churn en 2 semaines.

• La solution : des instructions explicites pour la concision, du contexte de codebase, une revue structurelle et des métriques de qualité pilotées par le CI/CD.

Peter Verrykt est Business Unit Lead Data & AI chez Xylos et accompagne les organisations dans la transformation des données en valeur business concrète. Vous voulez garder le code IA de votre équipe sous contrôle ? J'en discute volontiers.

CodeRabbit : State of AI vs Human Code Generation (déc. 2025) | GitClear : AI Copilot Code Quality 2025 (211M de lignes) | Cotroneo et al. arXiv 2508.21634 (août 2025) | Monash/Otago : Comparing Human and LLM Generated Code (jan. 2025) | Augment Code : The 80% Problem (avr. 2026) | METR : AI tooling slowed developers down (jul. 2025) | Stack Overflow : Bugs and Incidents with AI Coding Agents (jan. 2026) | Cracks in The Stack arXiv 2501.02628

Avertissement : les exemples de code sont simplifiés à titre illustratif. Les études citées sont évaluées par les pairs ou publiées par des institutions reconnues, et sont citées fidèlement quant au fond, sans reproduction littérale.