46 % du code est généré par IA. Votre Review Policy a-t-elle suivi ?

Mise à jour le 3 juillet 2026

Le débat sur l’adoption de l’IA générative dans le développement logiciel est clos. La question qui reste ouverte, et qui concerne directement les DSI et CTO, est celle de la gouvernance :

comment revoir, sécuriser et valider un code que personne dans l’équipe n’a écrit ligne par ligne.

Le constat chiffré

Trois données, prises ensemble, dessinent le problème avec précision :

  • 46 % du nouveau code produit aujourd’hui est généré par IA, contre environ 10 % en 2023. La bascule s’est faite en moins de trois ans.
  • Le code co-écrit avec l’IA contient 1,7 fois plus de problèmes majeurs que le code écrit entièrement par des développeurs humains, selon une analyse portant sur 470 pull requests open-source.
  • 45 % des échantillons de code généré par IA contiennent au moins une vulnérabilité du Top 10 OWASP — injection, gestion défaillante de l’authentification, exposition de données sensibles, etc.

Pris isolément, chacun de ces chiffres pourrait être une anecdote. Ensemble, ils décrivent une tendance structurelle : le volume de code généré augmente plus vite que la capacité des organisations à le vérifier.

Pourquoi l’écart se creuse

Le problème n’est pas la qualité intrinsèque des modèles — elle progresse. Le problème est que les pratiques de revue n’ont pas changé au même rythme que le volume produit.

Trois mécanismes expliquent l’écart :

  1. La revue humaine n’a pas été redimensionnée. Un développeur qui review 200 lignes écrites par un collègue applique un niveau d’attention qu’il n’applique plus à 2 000 lignes générées en quelques minutes par un agent. Le volume dilue la vigilance, alors même que le volume est justement ce qui a changé.
  2. Le code généré « a l’air correct ». Un agent produit un code syntaxiquement propre, souvent bien structuré en surface. Cette apparence de qualité crée un biais de confiance : le relecteur cherche des erreurs de logique évidentes, pas des failles de sécurité qui ne sautent pas aux yeux — injection SQL dans une requête qui fonctionne, credentials en clair dans un fichier de configuration généré « pour aller vite ».
  3. L’IA ne connaît pas vos règles métier ni votre modèle de menace. Un agent de code peut produire une fonction techniquement correcte tout en ignorant une contrainte de conformité, une règle d’autorisation spécifique à votre organisation, ou un cas limite propre à votre domaine. Ce sont précisément les angles morts qu’une revue standard, calibrée sur du code humain, ne cible pas.

Ce que cela change concrètement pour votre Review Policy

Une politique de revue conçue pour du code humain n’est pas transposable telle quelle au code généré. Voici les ajustements que nous recommandons lors de nos missions de conseil et d’audit :

Distinguer explicitement l’origine du code dans le processus de revue. Un commit généré par un agent IA devrait déclencher un chemin de revue différent — a minima un contrôle de sécurité systématique — plutôt que d’être traité comme n’importe quel commit humain.

Cibler la revue de sécurité sur les patterns à risque connus. Étant donné que près d’un échantillon sur deux présente une vulnérabilité OWASP, la revue de code IA devrait prioriser une checklist ciblée : validation des entrées, gestion des secrets, contrôle d’accès, sérialisation — plutôt qu’une lecture linéaire.

Introduire des points de contrôle humains sur les composants sensibles. Les algorithmes métier critiques, les modules d’authentification et la logique financière ne devraient jamais être générés puis validés sans une revue d’architecte, indépendamment de la vitesse promise par l’outil.

Documenter le contexte du prompt, pas seulement le code produit. Un code ne peut être correctement audité sans connaître l’intention et les contraintes qui ont guidé sa génération. Conserver la trace du prompt (contexte, objectif, contraintes) devient un élément de traçabilité aussi important que le commit lui-même.

Tester les agents, pas seulement leur production. Au-delà de la revue de code, une nouvelle discipline s’installe : évaluer la fiabilité de l’agent lui-même — comportement non déterministe, tendance à l’hallucination sur certains types de tâches, dérive au fil d’une session longue.

Le coût de l’inaction

Ce n’est pas une question théorique. Plusieurs études convergent sur un même constat : au-delà d’un certain seuil d’adoption sans gouvernance, les équipes perdent entre 20 et 30 % de leur capacité de sprint à corriger des bugs qui remontent directement à du code généré par IA non maîtrisé. Le gain de vitesse initial est réel — mais il est partiellement, voire totalement, absorbé par la dette qualité et sécurité accumulée en aval.

Autrement dit : adopter l’IA générative sans adapter la politique de revue ne fait pas disparaître le travail de vérification. Il le déplace, plus tard, sous une forme plus coûteuse — en production, ou en incident de sécurité.

Notre accompagnement

Chez ITTEST, notre service Conseil & Audit IA intervient précisément sur ce point de bascule : mise en place de standards qualité adaptés au code généré, définition d’une Review Policy différenciée, structuration de la documentation (SKILL.md, traçabilité des prompts) et formation des équipes de test à l’audit du code et des agents IA.

Si votre organisation a adopté des outils de vibe coding sans avoir formalisé cette distinction dans son processus de revue, c’est le moment de le faire — avant que le volume ne rende le rattrapage plus coûteux qu’aujourd’hui.

Envie d’évaluer où en est votre organisation ? Contactez notre équipe pour un audit de votre politique de revue actuelle face au code généré par IA.

Sources : analyse CodeRabbit sur 470 pull requests open-source (décembre 2025) ; GitHub Octoverse 2025 ; recherche indépendante sur les vulnérabilités OWASP dans le code généré par IA. Chiffres consolidés en 2026.