# Le vibe coding est-il sûr ? Ce qu'a trouvé un banc d'essai de 186 tâches réelles

> Des douze configurations d'agents, celle qui a le plus souvent produit du code fonctionnel l'a fait dans 57 % des tâches ; dans 11,8 % seulement, son code à la fois fonctionnait et réussissait le test de sécurité. Informer l'agent du risque a un peu aidé. L'étude pouvait tester chaque faille parce qu'elle avait déjà été trouvée et corrigée, et que le correctif était accompagné d'un test de sécurité. Le nouveau code de votre agent n'a pas encore de tel test.

Source: https://counterproof.io/fr/notes/le-vibe-coding-est-il-sur/ · Published 28 September 2026 · CounterProof est une pratique de Clavestra Capital Limited (Malte, C 113987).


**La configuration d'agent de l'étude qui a le plus souvent produit du code fonctionnel l'a fait dans 57 % des tâches. Dans 11,8 % des tâches seulement, son code à la fois fonctionnait et réussissait le test de sécurité.** Parmi ses solutions fonctionnelles, 79,3 % échouaient encore à un test de sécurité. Lorsque les agents ne recevaient aucune invite sur la sécurité, aucune configuration n'a produit de code à la fois fonctionnel et réussissant le test de sécurité dans plus de 12,9 % des tâches.

Ce sont les [chiffres phares](https://counterproof.io/glossary/#benchmark-score). Pour comprendre ce qu'ils signifient, il faut regarder comment le banc d'essai a été construit.

L'étude est *Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks* (Zhao, Wang, Zhang, Luo, Li et Li, ICML 2026, arXiv:2512.03262).

## Ce qu'a fait le banc d'essai

Les auteurs ont construit 186 tâches à partir de grands dépôts open source sur GitHub. Chacune partait d'un cas réel : un humain a implémenté une fonctionnalité, l'implémentation s'est révélée vulnérable, et la vulnérabilité a ensuite été corrigée. Ensemble, les tâches couvrent 79 catégories de faiblesses de la Common Weakness Enumeration de MITRE.

Pour chaque tâche, l'agent reçoit la base de code et une description de la fonctionnalité, « sans détails d'implémentation ni indications de sécurité ». On lui demande ensuite d'implémenter la fonctionnalité. Son patch est soumis à deux ensembles de tests écrits par des humains. L'un vérifie que la fonctionnalité marche ; l'autre recherche la vulnérabilité supprimée par le correctif du projet lui-même.

Les auteurs ont testé trois cadres d'agents (SWE-agent, OpenHands et Claude Code) avec quatre modèles : Claude 4 Sonnet, Kimi K2, Gemini 2.5 Pro et Gemini 3 Pro. Cela donnait douze configurations, chacune avec une tentative par tâche.

## Ce qu'il a trouvé

- La configuration qui a le plus souvent produit du code fonctionnel, SWE-agent avec Claude 4 Sonnet, l'a fait dans 57,0 % des tâches. Dans 11,8 %, le code réussissait aussi le test de sécurité. Comme l'écrivent les auteurs, « 79,3 % de ces solutions fonctionnellement correctes ne sont pas sécurisées ».
- OpenHands avec le même modèle présentait un profil semblable : 77,8 % de ses solutions fonctionnelles n'étaient pas sécurisées.
- Claude Code avec Claude 4 Sonnet a produit du code fonctionnel dans 41,4 % des tâches. Dans 5,9 %, le code réussissait aussi le test de sécurité.
- Lorsque les agents ne recevaient aucune invite sur la sécurité, la part la plus élevée de tâches résolues de manière à la fois correcte et sécurisée était de 12,9 %, pour SWE-agent avec Gemini 3 Pro, qui a produit du code fonctionnel dans 37,1 % des tâches.
- Sur les douze configurations, cette part s'établissait en moyenne à 8,4 % (notre calcul à partir du tableau 3) ; les auteurs décrivent la moyenne comme étant de « seulement environ 10 % ».
- Dans chacune des douze configurations, la plupart des solutions fonctionnelles échouaient à un test de sécurité. La proportion allait de 59 % à 86 %, selon notre calcul à partir du tableau 3 de l'article.

## Parler de sécurité à l'agent a un peu aidé

Les auteurs ont essayé deux invites sur la configuration qui a le plus souvent produit du code fonctionnel. La première donne à l'agent la liste complète des catégories CWE couvertes par le banc d'essai, avec leurs descriptions. Avant d'écrire du code, l'agent identifie les faiblesses que la tâche peut impliquer. La seconde invite nomme le ou les types de faiblesses que vise la tâche et demande à l'agent d'éviter les implémentations vulnérables.

Avec ces invites, la part des tâches donnant du code qui à la fois fonctionnait et réussissait le test de sécurité est passée de 11,8 % à 14,5 % et à 15,1 % respectivement. Mais la part donnant du code fonctionnel est tombée de 57,0 % à 50,0 % et à 55,4 %. Selon les termes des auteurs, l'amélioration « n'atténue pas substantiellement le problème de sécurité ».

Selon notre lecture, la seconde invite donne à l'agent une information dont un utilisateur ne dispose pas encore. Les auteurs relèvent que des experts humains peuvent identifier des risques de sécurité potentiels avant l'implémentation ; la première invite suit cette approche. La seconde nomme le type de faiblesse que la tâche a été construite pour tester. Hors d'un banc d'essai, cette information ne devient disponible qu'une fois la faille trouvée.

## Le test existait parce que la faille avait déjà été trouvée

C'est l'élément de la conception que nous soulignerions. Chaque tâche est accompagnée d'un test de sécurité ajouté par les développeurs du projet dans le commit qui a corrigé la vulnérabilité d'origine. Quelqu'un avait déjà trouvé la faille, et les développeurs du projet avaient écrit un test pour elle. C'est cette histoire qui permet au banc d'essai de rechercher la vulnérabilité. Les auteurs ont ensuite vérifié à la main chaque test de sécurité et révisé ceux qui étaient trop étroitement liés à une implémentation particulière.

La nouvelle fonctionnalité de votre agent n'a pas de tel test. Votre suite de tests vous dit ce que les tests fonctionnels du banc d'essai disaient aux auteurs : que la fonctionnalité marche. Or la plupart des solutions fonctionnelles de l'étude échouaient encore à un test de sécurité.

Trouver une faille pour laquelle personne n'a encore écrit de test, c'est le travail d'une revue adversariale. Notre page [*Revue de code adversariale : ce que le terme laisse de côté*](https://counterproof.io/fr/revue-de-code-adversariale/) expose ce que couvre ce travail et où se situent ses limites.

## Des modèles différents évitent des failles différentes

Les auteurs rapportent que « les cadres d'agents et les LLM sont doués pour éviter des vulnérabilités différentes ». Kimi K2 gérait mieux les défaillances cryptographiques, tandis que Gemini 3 Pro était meilleur pour faire respecter le contrôle d'accès.

Ce résultat concerne l'écriture de code. Il n'établit pas si un second modèle attraperait les failles dans le travail du premier. Un second modèle n'est pas non plus, par défaut, un contrôle indépendant : quand deux modèles se trompent, ils [se trompent souvent de la même façon](https://counterproof.io/glossary/#correlated-errors) (Kim et al., ICML 2025). Voir [*The attacker can run any model. How many do you run?*](https://counterproof.io/notes/the-attacker-can-run-any-model/).

C'est l'une des raisons pour lesquelles nous ne traitons pas l'accord entre modèles comme une preuve : l'affirmation selon laquelle il en est une fait partie des [cinq affirmations que nous nous refusons à faire](https://counterproof.io/refusals/).

## Une question que l'étude laisse ouverte

Chaque tâche partait d'une vulnérabilité qu'un humain avait introduite dans un projet réel. Dans la plupart des solutions fonctionnelles, les agents ont échoué au test de sécurité portant sur cette vulnérabilité. Mais l'étude ne se demande pas si les modèles avaient rencontré l'historique de ces projets, y compris les versions vulnérables, pendant leur entraînement. Voir [*The Illusion of the Score*](https://counterproof.io/notes/the-illusion-of-the-score/).

Elle ne peut donc pas distinguer entre la reproduction d'une faille rencontrée pendant l'entraînement et l'arrivée indépendante à la même erreur. Notre article de recherche, [Agentic Stemmatics](https://research.counterproof.io/agentic-stemmatics.html), examine comment distinguer ces possibilités.

## Ce que l'étude ne montre pas

- **Taux de base.** Les 186 tâches ont été choisies parce que chacune est sensible pour la sécurité et qu'un humain s'y est un jour trompé. Les taux décrivent ce type de fonctionnalité, non le code écrit par des agents en général.
- **Modèles plus récents.** L'étude a testé quatre modèles, avec une tentative par tâche pour chaque configuration. D'autres modèles, et des versions ultérieures, peuvent obtenir des scores différents.
- **Revue.** L'étude mesure un agent qui écrit du code sans revue humaine. Elle ne nous dit pas ce qu'une équipe, un outil ou un relecteur attraperait ensuite. Voir [*A Clean Benchmark Is Not a Clean Codebase*](https://counterproof.io/notes/a-clean-benchmark-is-not-a-clean-codebase/) et [*La vitesse passe. La complexité reste.*](https://counterproof.io/fr/notes/la-vitesse-passe-la-complexite-reste/).

Le résultat est limité, mais clair. Dans ces tâches sensibles pour la sécurité, la plupart des solutions fonctionnelles échouaient encore à un test de sécurité. Une suite de tests qui vérifierait seulement que la fonctionnalité marche ne révélerait pas cette distinction.

---

*Les citations de l'étude (Zhao et al., ICML 2026, arXiv:2512.03262) sont notre traduction de son texte anglais. 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.*


## Questions this page answers

**Le vibe coding est-il sûr ?**

Dans ce banc d'essai, pas par défaut. Des douze configurations d'agents, celle qui a le plus souvent produit du code fonctionnel l'a fait dans 57 % des tâches ; dans 11,8 % seulement, son code réussissait aussi le test de sécurité, et, lorsque les agents ne recevaient aucune invite sur la sécurité, aucune configuration n'a dépassé 12,9 %. Chaque tâche a été choisie parce qu'elle était sensible pour la sécurité ; ces taux décrivent donc ce type de fonctionnalité, non l'ensemble du code écrit par des agents.

**Si mes tests passent, le code est-il sûr ?**

Réussir des tests fonctionnels vous dit que la fonctionnalité marche. Dans l'étude, 79,3 % des solutions fonctionnelles de SWE-agent avec Claude 4 Sonnet, la configuration qui a le plus souvent produit du code fonctionnel, échouaient encore à un test de sécurité.

**Demander à l'agent de penser à la sécurité aide-t-il ?**

Un peu. Une invite demandait à l'agent d'identifier les risques à partir d'une liste fournie avant d'écrire du code. Une autre nommait le type de faiblesse qu'il devait éviter. La part des tâches dont les solutions à la fois fonctionnaient et réussissaient le test de sécurité est passée de 11,8 % à 14,5 % et à 15,1 % respectivement. Les deux invites ont aussi réduit la part des tâches aux solutions fonctionnelles.

**Un second modèle d'IA attraperait-il ce que le premier a manqué ?**

L'étude a mesuré l'écriture de code, non sa revue. Elle a constaté que des modèles différents évitent des faiblesses différentes. Savoir si un second modèle attrape les failles du premier est une question distincte. Des modèles d'entreprises différentes ne sont pas automatiquement indépendants.