Demandez à un agent de codage IA un endpoint d'upload et vous en obtiendrez un. Le code compile. La démo fonctionne. La pull request semble impeccable à 18 heures. Et quelque part à l'intérieur se cache un défaut de path traversal que personne ne remarquera avant que quelqu'un décide de regarder.
Ce n'est plus une inquiétude hypothétique. C'est un résultat mesuré, et le chiffre est inconfortable : le meilleur agent de codage d'un tout nouveau benchmark a produit du code à la fois fonctionnel et sûr dans seulement 25,1 % des tâches.
Le chiffre des 25 %, et pourquoi il devrait vous préoccuper
Le 14 octobre, un article publié sur Hugging Face a présenté le Last Secure Code Benchmark (LSCB), sous-titré « Is the Code You Vibe Secure? ». Le design est brutalement simple et, pour une fois, réaliste. Les chercheurs ont pris 150 vulnérabilités réelles, les ont étendues à 450 tâches réparties sur trois scénarios de vibe coding, puis ont lâché six agents de frontière dessus, dans sept langages dont Java, C, C++, JavaScript, Python, PHP et Go. La couverture s'étend à 24 CWE, dont 21 des CWE Top 25 de 2025 et 8 du Top 10 des faiblesses activement exploitées.
Les résultats se divisent en deux chiffres qui racontent des histoires très différentes :
- Sur le plan fonctionnel, les agents semblent excellents. Entre 73,6 % et 91,3 % des tâches passent les tests fonctionnels cachés. Le code fait ce qui était demandé.
- Fonctionnel et sûr à la fois, le tableau s'effondre. L'agent le plus solide, Claude Fable 5, atteint 25,1 %. Les cinq autres se situent entre 16,4 % et 24,7 %.
Comme les taux de réussite fonctionnelle sont bien plus élevés, la majeure partie de cet échec relève de l'insécurité et non de la casse. Le code tourne, la fonctionnalité se démontre et la vulnérabilité part en production. Les auteurs ajoutent que même le meilleur modèle ne passe que 12 % des scénarios de vulnérabilité, tous contextes de vibe coding confondus.
Comment le benchmark a été construit, et pourquoi il est équitable
Le choix de conception le plus important, c'est ce que les prompts omettent. Chaque énoncé ne demande que de la fonctionnalité et ne mentionne jamais la sécurité. C'est exactement ainsi que les équipes briefent un agent : ajoute un endpoint d'upload, et non ajoute un endpoint d'upload qui résiste au path traversal.
Chacune des 450 tâches a ensuite été notée deux fois par des tests cachés. Un ensemble vérifie que le code fait ce qui était demandé. Un second vérifie qu'il évite la faiblesse précise que représentait la vulnérabilité réelle d'origine. Utiliser de vraies vulnérabilités plutôt que des bugs synthétiques compte, et les tests cachés réduisent la possibilité qu'un modèle trompe un vérificateur visible.
Il faut garder les réserves honnêtes, car les chercheurs ont été prudents. Le benchmark mesure le comportement par défaut : les modèles n'ont reçu ni consignes de sécurité, ni compétence de codage sécurisé, ni boucle de relecture. Des agents dotés d'une exigence de sécurité explicite et d'une passe de revue automatisée feront probablement bien mieux. Une réussite signifie que le code a évité la faiblesse testée, pas que chaque autre ligne est saine. Et les environnements d'agents changent chaque mois : c'est un instantané, pas un verdict définitif.
Ce n'est pas un résultat isolé
Si le LSCB était la seule étude à pointer dans cette direction, il serait facile de la classer comme un gros titre anxiogène et de passer à autre chose. Ce n'est pas le cas. La mise à jour du printemps 2026 de Veracode sur la sécurité du code généré par IA a testé plus de 150 modèles sur 80 tâches dans quatre langages, vérifiées par analyse statique, et a trouvé la même forme de problème :
- Correction syntaxique : plus de 95 %
- Taux de réussite sécurité sans consigne de sécurité : environ 55 %
- Cross-site scripting : environ 15 %
- Injection de logs : environ 13 %
- Injection SQL : 82 %
- Deux ans de sorties de modèles : de 55 % à 55 %
C'est cette dernière ligne qu'il faut digérer. Chaque lancement de cette période a été couronné de bond en avant et, sur cette mesure, l'aiguille n'a pas bougé. Les modèles axés sur le raisonnement font mieux, autour de 70-72 %, une vraie amélioration et toujours rien à mettre en production sans revue. Au niveau du dépôt, le constat est comparable : le benchmark SusVibes rapporte que la plupart des solutions d'agents qui passent la partie fonctionnelle sont non sécurisées, avec le meilleur résultat annoncé autour de 11,8 % correct et sûr.
Le second mode de défaillance : des dépendances qui n'existent pas
Les bugs de sécurité sont le risque évident. Le plus étrange, c'est la chaîne d'approvisionnement, devenue silencieusement une attaque.
Une étude ayant généré 576 000 échantillons de code avec 16 modèles a constaté que 19,7 % des paquets recommandés n'existaient pas, soit plus de 205 000 noms inventés distincts. Les modèles ouverts hallucinaient 21,7 % du temps en moyenne, les commerciaux 5,2 %. Le taux n'est pas le point intéressant. Voici ce qui l'est : en répétant dix fois les mêmes prompts, 43 % des noms de paquets hallucinés revenaient à chaque exécution. Les inventions sont systématiques, pas aléatoires.
Un nom prévisible est un nom que quelqu'un peut enregistrer avant que vous ne le demandiez. Cette attaque porte désormais un nom, le slopsquatting, et un chercheur l'a démontrée en publiant un paquet vide sous un nom halluciné plausible, ensuite téléchargé des dizaines de milliers de fois. Confiez maintenant l'installation des dépendances à un agent autonome, et le seul point de contrôle humain de cette chaîne, remarquer le nom du paquet et décider de l'installer, disparaît sans bruit.
Ce que nous conseillons à nos clients
Rien de tout cela ne signifie ralentir ou renoncer aux gains de productivité. Cela signifie déplacer l'attention humaine. Cinq règles que nous appliquons :
- Nommez le risque dans le prompt, avant que le code existe. Cette modification touche des données utilisateur et le login : listez d'abord les exigences de sécurité, nous construirons contre cette liste. Cela coûte une phrase et le benchmark suggère que cela compte plus que le choix du modèle.
- Vérifiez contre les catégories qui échouent réellement. Ne demandez pas si c'est sécurisé. Cela produit un essai. Demandez précisément ce qui concerne des sorties atteignant une page sans échappement, des entrées utilisateur arrivant non vérifiées dans un log ou une requête, et tout ce qui est construit en concaténant des chaînes.
- Traitez chaque nouvelle dépendance comme un événement de chaîne d'approvisionnement. Pour chaque paquet : existe-t-il dans le registre officiel, qui le publie, quand a-t-il été publié pour la première fois, combien de versions a-t-il. Vous n'auditez pas du code, vous vérifiez si la chose a un passé.
- Gardez une porte humaine sur le diff. Les agents produisent plus de code, pas plus de logiciel relu. La revue est désormais le goulot d'étranglement et le contrôle le moins cher que vous possédez.
- Partez du principe que les valeurs par défaut sont non sécurisées et instrumentez-le. Ajoutez du SAST et du scan de dépendances dans la chaîne plutôt que de compter sur la prudence de l'agent.
La conclusion pour votre équipe
Le codage agentique a résolu la génération. Ce qui reste non résolu, ce sont la correction et la sécurité, et cette partie non résolue était exactement ce pour quoi les ingénieurs étaient payés. Les équipes qui gagneront les deux prochaines années ne seront pas celles qui font le meilleur prompt. Ce seront celles dont les chaînes de production rattrapent ce que l'agent a laissé derrière : des exigences écrites avant le prompt, un scan automatisé après, et un relecteur qui connaît les quatre ou cinq classes de faiblesses qui reviennent sans cesse.
La vitesse est désormais la base. Ce qui survit à une revue, à un scanner et à un test d'intrusion, c'est le produit.