# La vitesse passe. La complexité reste.

> Trois études indépendantes, trois méthodes différentes — une étude ciblée de vulnérabilités, une comparaison contrôlée humain-modèle et un an d'observation de dépôts réels — convergent vers le même constat : le code généré par IA porte un coût de qualité mesurable qui survit au gain de productivité avec lequel il est arrivé.

Source: https://counterproof.io/fr/notes/la-vitesse-passe-la-complexite-reste/ · Published 25 August 2026 · CounterProof est une pratique de Clavestra Capital Limited (Malte, C 113987).


« L'IA écrit du code plus vite » ne fait pas débat. Savoir si elle écrit du code *pire* est une
question distincte, empirique — et nous préférons y répondre par des mesures plutôt que par les
éléments de langage de l'un ou l'autre camp. Trois études indépendantes, avec trois méthodes
différentes, convergent vers la même réponse.

## Le point de départ : un taux de défauts documenté

Nous traitons l'étude fondatrice en détail dans
[*A Clean Benchmark Is Not a Clean Codebase*](https://counterproof.io/notes/a-clean-benchmark-is-not-a-clean-codebase/)
(en anglais) : Pearce et al. (IEEE S&P 2022) ont trouvé **environ 40 % de 1 689 programmes
générés par Copilot** vulnérables aux classes de faiblesses du Top 25 de MITRE. L'étude est
désormais assez ancienne pour que son chiffre ne soit pas lu comme actuel — les modèles ont
changé depuis 2022. Ce qu'elle a établi, et sur quoi les travaux ultérieurs s'appuient : la
question est réelle et peut recevoir une réponse par des méthodes standard — scénarios ciblés,
grand échantillon, analyse statique contre une liste de faiblesses nommée.

## Le mécanisme : pas des bugs aléatoires, une absence systématique

Un chiffre seul ne dit pas quoi faire. Une comparaison contrôlée de code écrit par des humains et
de code généré par des LLM — structures de données, algorithmes, routines cryptographiques et
problèmes de type LeetCode, avec tests unitaires, fuzzing et analyse statique
(arXiv:2409.19182) — est allée plus loin et a trouvé ceci : le code généré par LLM est moins sûr
avant tout parce qu'il lui manque les **constructions de programmation défensive** — les
vérifications de bornes et la validation d'entrées qu'un ingénieur soigneux ajoute par habitude,
et non la fonctionnalité effectivement demandée. C'est cette absence qui invite les débordements
de tampon et d'entier. Sous fuzzing, le code généré par LLM était plus sujet aux blocages et aux
plantages que la base de comparaison écrite par des humains. Les défauts de correction pouvaient
être subtils plutôt qu'évidents : dans un cas, le modèle a produit une implémentation incorrecte
de SHA-1 qui compilait pourtant proprement — fausse, et silencieuse sur ce point.

Le constat qui devrait inquiéter quiconque prend « demande au modèle de corriger » pour un filet
de sécurité : la même étude a construit une boucle de rétroaction demandant au modèle de
régénérer le code et d'éliminer les problèmes qu'on venait de lui montrer. Cela n'a pas
fonctionné de manière fiable. Dans certains cas, la correction a réussi. Dans d'autres, le code
« corrigé » contenait de *nouveaux* problèmes — et dans certains cas, l'acte même de prompter a
introduit des problèmes dans des fichiers qui étaient sains avant. Laisser l'auteur noter ses
propres copies n'est pas une revue.

## La preuve en production : le coût ne passe pas avec la nouveauté

La preuve la plus récente vient d'entièrement hors du laboratoire. Une étude a suivi **807 dépôts
open source sur GitHub** ayant adopté l'assistant de codage Cursor entre janvier 2024 et mars
2025, contre un groupe témoin de 1 380 dépôts comparables sans lui — avec SonarQube comme
instrument de mesure des avertissements d'analyse statique, de la duplication et de la
complexité, jusqu'en août 2025. L'histoire de productivité s'est déroulée comme prévu : un pic
éphémère de commits et de lignes ajoutées les un à deux premiers mois, retour à la ligne de base
au troisième. Le coût de qualité, lui, n'est pas passé. **Les avertissements d'analyse statique
ont augmenté d'environ 30 % après l'adoption et sont restés élevés. La complexité du code a
augmenté de plus de 40 %** — davantage que la croissance de la base de code seule ne
l'expliquerait. Le gain de vitesse était temporaire. La dette, non.

## Une limite honnête

Ce n'est pas l'affirmation que le code généré par IA est toujours pire, comme loi générale. La
tâche, le modèle et la méthode de travail comptent tous — et une équipe qui traite la sortie de
l'IA comme un premier jet méritant la même discipline de revue que la pull request d'un ingénieur
junior obtient d'autres résultats qu'une équipe qui la livre sans relecture. Les études
ci-dessus ne testent ni chaque modèle ni chaque méthode de travail, et aucune n'isole la
discipline de revue comme variable. Ce qu'elles établissent de manière constante, à travers
trois méthodes indépendantes (tests CWE ciblés, comparaison contrôlée, données longitudinales de
production) : l'effet est réel et systématique plutôt qu'occasionnel — et demander au modèle de
vérifier son propre travail ne remplace pas le fait que quelqu'un d'autre le fasse.

## Pourquoi c'est une question de conformité, pas seulement d'ingénierie

En vertu du Cyber Resilience Act, un fabricant doit veiller à ce que les produits comportant des
éléments numériques soient *« conçus, développés et fabriqués de manière à garantir un niveau de
cybersécurité approprié en fonction des risques »* et *« mis à disposition sur le marché sans
vulnérabilité exploitable connue »* (règlement (UE) 2024/2847, annexe I, partie I, points 1) et
2) a)). Aucune des deux clauses ne mentionne la façon dont le code a été écrit. Toutes deux
deviennent plus difficiles, et non plus faciles, à satisfaire à mesure qu'une part croissante de
la surface d'une base de code a été produite par un processus présentant un déficit mesuré et
systématique précisément dans les constructions — vérifications de bornes, validation
d'entrées — qui empêchent une classe de faiblesses connue de devenir exploitable. Générer plus
vite sans réviser davantage n'est pas un raccourci autour de cette obligation. C'est une distance
qui grandit par rapport à elle.

## Pourquoi cela nous concerne

Chez CounterProof, nous pratiquons la revue adversariale de code écrit par des machines, et ces
trois études décrivent exactement l'écart que notre pratique existe pour combler : traiter la
sortie de l'IA — qu'elle génère ou qu'elle relise — comme une affirmation à vérifier, non comme
un résultat à croire. Voir la pièce compagnon
[*A Clean Benchmark Is Not a Clean Codebase*](https://counterproof.io/notes/a-clean-benchmark-is-not-a-clean-codebase/)
(en anglais) sur ce qui se passe quand l'outil de vérification est lui aussi fondé sur l'IA et
que sa propre fiabilité reste inexaminée. L'argument long, y compris la forme conditionnelle de
chaque affirmation ci-dessus, figure dans notre document de travail sur la collation et la
provenance du texte généré par des machines,
[lisible en intégralité ici](https://research.counterproof.io/) (en anglais). C'est un
prépublication à l'état de brouillon, non relue par des pairs, et elle le dit.

---

*Les sources citées ci-dessus ont été vérifiées contre leurs résumés publiés. Le chiffre de
Pearce et al. provient d'IEEE S&P 2022 et décrit Copilot tel qu'il existait au moment de cette
étude, pas les modèles actuels. Les chiffres Cursor proviennent d'une étude longitudinale de 807
dépôts contre un groupe témoin de 1 380, suivis de janvier 2024 à août 2025. Les dispositions du
CRA citées renvoient au règlement (UE) 2024/2847 et ont été vérifiées contre la version
linguistique française officielle. Cette page est une traduction de l'original anglais ; en cas
de divergence, l'original prévaut. Si quelque chose est faux ici, nous le corrigerons par écrit
sur cette page.*