Code généré par IA : près de la moitié contient une faille

Le chiffre vient de l’étude la plus solide sur la sécurité du code généré par IA : dans son rapport GenAI Code Security, Veracode a soumis plus de 100 modèles à 80 tâches de développement et mesuré que 45 % des extraits produits contenaient une vulnérabilité du Top 10 OWASP. Pas du code maladroit : des failles exploitables, injection SQL, cross-site scripting, cryptographie faible.

La question n’est donc pas de savoir si votre équipe produit du code généré vulnérable. Elle en produit. La question est de savoir ce qui, dans votre chaîne de livraison, l’empêche d’atteindre la mise en production.

Ce que mesure Veracode

Les détails du rapport méritent lecture. Java est le langage le plus touché, avec 72 % d’échec sur les tâches testées. Sur certaines classes de failles, les résultats sont massifs : 86 % des extraits n’étaient pas protégés contre le cross-site scripting, 88 % étaient vulnérables à l’injection dans les logs. Et le point le plus important : les modèles plus grands ou plus récents ne font pas mieux. La qualité syntaxique du code généré progresse d’année en année, sa sécurité, elle, stagne, ce que la mise à jour de printemps 2026 de Veracode confirme : malgré les annonces des éditeurs, les nouveaux modèles échouent toujours sur les mêmes classes de vulnérabilités.

Pourquoi le modèle ne réglera pas ça seul

La raison est structurelle. Un modèle apprend sur le code public existant, qui contient ces failles en quantité. Face à une tâche, il reproduit le pattern le plus fréquent de ses données d’entraînement, et le pattern le plus fréquent n’est pas le plus sûr. Que la sécurité stagne pendant que tout le reste s’améliore est le signe d’un problème systémique, pas d’un retard de version.

S’ajoute un piège de vérification : une faille est invisible dans le chemin nominal. Le code fonctionne, la démo passe, les tests fonctionnels sont verts ; rien, dans la boucle de feedback naturelle d’un agent ou d’un développeur pressé, ne signale le problème. La sécurité est précisément le type de défaut que la vitesse aggrave : plus de volume au même taux de failles, c’est plus de failles en production.

Attendre que le prochain modèle règle la question est donc une politique de sécurité fondée sur l’espoir, et les mesures successives montrent que l’espoir ne paie pas.

La réponse est dans le pipeline

Ce qui fonctionne existe depuis longtemps, et le code généré le rend simplement obligatoire : une analyse statique de sécurité bloquante dans la CI, un scan de secrets sur chaque commit, un audit des dépendances à chaque ajout. Ce dernier point mérite une mention particulière : les agents proposent volontiers des bibliothèques plausibles mais obscures, parfois inexistantes, et des attaquants publient des paquets sous ces noms hallucinés en espérant qu’une équipe pressée les installe. Une dépendance nouvelle n’entre pas sans vérification.

L’avantage du pipeline sur la vigilance individuelle : il s’applique à chaque diff, humain ou généré, y compris le vendredi soir. Et un agent corrige souvent de lui-même quand le scan lui renvoie une erreur explicite. Le socle de guardrails en CI décrit l’installation de ces briques dans l’ordre utile.

Une revue humaine là où l’erreur ne pardonne pas

Les scanners attrapent les patterns connus, pas les erreurs de logique : un contrôle d’accès oublié, un token qui traverse un log, une validation faite côté client seulement. Sur ces sujets, la revue humaine reste irremplaçable, à condition de la concentrer. Cartographiez les chemins sensibles, authentification, paiements, uploads, tout ce qui touche aux données personnelles, et exigez-y un relecteur expérimenté, quel que soit l’auteur du code. C’est le même principe de niveaux de revue par risque qui desserre le goulot de la revue générale : de l’attention là où elle compte, pas partout.

Prévenir en amont avec des skills de sécurité

Le dernier étage traite le problème à la source : puisque le modèle reproduit ce qu’on lui montre, montrez-lui vos exigences. Une skill de sécurité, chargée par l’agent sur les tâches concernées, encode vos règles : requêtes paramétrées systématiques, échappement des sorties, bibliothèque de cryptographie approuvée, secrets gérés par le coffre de l’équipe, validations d’entrée attendues. Des consignes explicites améliorent nettement ce qui sort de l’agent ; elles ne suffisent pas, et c’est pourquoi le pipeline reste derrière.

Ces règles relèvent autant de la gouvernance que de l’outillage : c’est à votre politique IA d’équipe de dire qui définit les chemins sensibles et ce qui y est exigé.

Près de la moitié du code généré contient une faille, et ce chiffre ne bougera pas assez vite pour vous. Votre pipeline, lui, peut bouger cette semaine, avec ou sans nous ; et si c’est avec nous, ce sera dans le cadre d’un accompagnement en ingénierie agentique, scans, carte des chemins sensibles et skills de sécurité compris.