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