Un nouveau benchmark académique suggère que le code produit par les agents de codage IA les plus populaires d’aujourd’hui peut très bien fonctionner — tout en restant dangereusement facile à pirater. Ces résultats soulèvent de nouvelles questions sur la sécurité du vibe coding, la pratique qui consiste à laisser des agents de grands modèles de langage écrire des logiciels avec très peu de supervision humaine, au moment même où cette technique gagne du terrain parmi les développeurs et les entreprises cherchant à aller plus vite.
Summary
Points clés à retenir
- Le vibe coding permet à un agent LLM d’accomplir des tâches de codage complexes à partir d’une simple instruction humaine, avec une supervision minimale pendant l’exécution.
- Les chercheurs ont construit SUSVIBES, un benchmark de 186 tâches d’ingénierie logicielle réelles tirées de projets open source où des programmeurs humains avaient auparavant commis du code vulnérable.
- Douze configurations agentiques de codage largement utilisées, exécutant des modèles d’IA de pointe, ont été testées sur ce benchmark, et chacune d’entre elles a obtenu de mauvais résultats en matière de sécurité.
- SWE-Agent associé à Claude 4 Sonnet a produit du code fonctionnellement correct dans 57 % des cas, mais seulement 11,8 % de ces solutions étaient réellement sécurisées.
- L’ajout d’indices de vulnérabilité dans les instructions de codage, une stratégie d’atténuation simple, n’a pas permis d’améliorer de manière significative les résultats en matière de sécurité.
Qu’est-ce que le vibe coding et pourquoi les préoccupations de sécurité augmentent
Le vibe coding décrit un style de développement dans lequel les ingénieurs confient une tâche de codage à un agent IA et le laissent travailler avec un minimum de points de contrôle en cours de route. Au lieu d’écrire eux-mêmes chaque ligne, les programmeurs humains donnent une instruction au modèle, examinent la sortie à un niveau élevé, puis passent à autre chose. Cette approche s’est imposée parce qu’elle peut accélérer considérablement la livraison de logiciels, en particulier pour des demandes de fonctionnalités qui prendraient autrement des heures à un développeur pour être implémentées manuellement.
Cette rapidité a un revers. À mesure que davantage d’équipes s’appuient sur des agents IA pour livrer du code en production, la question de savoir si ce code est réellement sûr à déployer devient difficile à ignorer. Une chercheuse nommée Danqing Wang a entrepris de tester précisément cela, en construisant un benchmark conçu pour mesurer non seulement si le code écrit par l’IA fonctionne, mais aussi s’il introduit les mêmes types de failles qui, historiquement, ont échappé aux relecteurs humains.
À l’intérieur du benchmark SUSVIBES
SUSVIBES répond à une question directe : à quelle fréquence le code généré par des agents répète-t-il les erreurs de sécurité que de vrais développeurs ont déjà commises ? Le benchmark puise ses cas de test directement dans l’histoire plutôt que dans des scénarios hypothétiques.
Il se compose de 186 tâches de demande de fonctionnalité issues de projets open source réels. Chaque tâche correspond à un cas où des programmeurs humains ont, à un moment donné, commis une implémentation vulnérable en construisant précisément cette fonctionnalité. Cette conception permet aux chercheurs de vérifier si un agent IA résolvant le même problème tombe dans le même piège ou parvient à l’éviter.
Pour mettre le domaine à rude épreuve de manière globale, l’étude a évalué 12 configurations agentiques de codage largement utilisées exécutant des modèles d’IA de pointe. L’idée était de capturer un instantané réaliste de la façon dont les développeurs déploient réellement ces outils aujourd’hui, plutôt que de tester un seul modèle isolément. L’une des configurations qui s’est distinguée pour une analyse plus approfondie associait le framework SWE-Agent à Claude 4 Sonnet.
Fonctionnel mais pas sécurisé : les résultats de SUSVIBES
Le résultat principal est sans détour : chaque configuration d’agent testée sur SUSVIBES a obtenu de mauvais résultats en matière de sécurité logicielle, quel que soit le modèle de pointe utilisé. Cette uniformité est en soi notable — elle suggère que le problème n’est pas lié à un modèle faible en particulier, mais à un fossé plus large dans la façon dont ces agents sont entraînés et sollicités pour écrire du code.
La combinaison SWE-Agent et Claude 4 Sonnet illustre clairement ce fossé. Parmi les solutions produites, 57 % étaient fonctionnellement correctes, c’est-à-dire qu’elles faisaient ce qui était demandé dans la requête de fonctionnalité. Mais lorsque les chercheurs ont vérifié ces mêmes solutions par rapport à des modèles de vulnérabilité connus, seulement 11,8 % étaient sécurisées. En d’autres termes, plus de quatre solutions fonctionnellement correctes sur cinq comportaient encore le type de faille qu’un programmeur humain avait déjà introduit au même endroit.
C’est là que les enjeux pratiques deviennent évidents. Un morceau de code qui s’exécute et passe les tests peut sembler prêt pour la production à un relecteur qui se concentre sur la fonctionnalité, tout en embarquant discrètement une vulnérabilité qui n’apparaîtra que lors d’un audit de sécurité ou, pire, lors d’une véritable intrusion. Pour les équipes qui se demandent de quel niveau de supervision le code généré par l’IA a encore besoin, cet écart entre correction et sécurité est le chiffre qui compte le plus.
Les indices de vulnérabilité ne résolvent pas le problème
Les chercheurs ne se sont pas contentés de documenter le problème — ils ont essayé de le résoudre. Une stratégie préliminaire consistait à enrichir la demande de fonctionnalité initiale avec des indices explicites de vulnérabilité, en orientant essentiellement l’agent vers le type de risque auquel il devait prêter attention.
Cela n’a pas fonctionné. L’étude a montré que cette approche n’a pas permis d’améliorer de manière significative les résultats en matière de sécurité, ce qui signifie que le simple fait de dire à l’agent ce qu’il doit éviter ne suffit pas à modifier son comportement en pratique. Ce résultat pointe vers un problème plus profond que la formulation des prompts : les modèles semblent dépourvus d’un mécanisme interne fiable de vérification du risque de sécurité, même lorsqu’on les y oriente explicitement.
Pris ensemble, ces résultats soulèvent de sérieuses inquiétudes quant au déploiement du vibe coding dans des applications sensibles à la sécurité, des systèmes financiers aux logiciels d’infrastructure, où une seule vulnérabilité négligée peut avoir des conséquences disproportionnées. Les chercheurs à l’origine de SUSVIBES ont rendu le code et le jeu de données publics sur GitHub, ainsi qu’un classement public qui suit les performances des différentes configurations d’agents sur le benchmark au fil du temps.
Pour un secteur qui se précipite pour adopter les agents de codage IA, l’étude est moins un verdict contre la technologie qu’un avertissement sur les limites des garde-fous actuels. Un code fonctionnel n’est pas la même chose qu’un code sûr, et tant que cet écart ne se sera pas réduit, la sécurité du vibe coding restera probablement un point de friction pour toute équipe qui développe des logiciels où le coût d’une faille cachée est élevé.
FAQ
Qu’est-ce que le vibe coding ?
Le vibe coding est une approche de développement logiciel dans laquelle des agents de grands modèles de langage réalisent des tâches de codage avec une supervision minimale de la part des ingénieurs humains.
Que mesure le benchmark SUSVIBES ?
SUSVIBES est un benchmark de 186 tâches réelles d’ingénierie logicielle avec des vulnérabilités connues, utilisé pour évaluer les performances de sécurité du code généré par des agents.
Dans quelle mesure le code généré par les agents LLM actuels en vibe coding est-il sécurisé ?
Les tests de SWE-Agent avec Claude 4 Sonnet ont montré que, bien que 57 % du code généré soit fonctionnellement correct, seulement 11,8 % est sécurisé contre les vulnérabilités.
Les stratégies comme l’ajout d’indices de vulnérabilité améliorent-elles la sécurité en vibe coding ?
Les tentatives préliminaires, telles que l’ajout d’indices de vulnérabilité, n’ont pas significativement amélioré les performances de sécurité du code généré par des agents.
{« @context »: »https://schema.org », »@type »: »FAQPage », »mainEntity »:[{« @type »: »Question », »name »: »Qu’est-ce que le vibe coding? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Le vibe coding est une approche de développement logiciel dans laquelle des agents de grands modèles de langage réalisent des tâches de codage avec une supervision minimale de la part des ingénieurs humains. »}},{« @type »: »Question », »name »: »Que mesure le benchmark SUSVIBES? », »acceptedAnswer »:{« @type »: »Answer », »text »: »SUSVIBES est un benchmark de 186 tâches réelles d’ingénierie logicielle avec des vulnérabilités connues, utilisé pour évaluer les performances de sécurité du code généré par des agents. »}},{« @type »: »Question », »name »: »Dans quelle mesure le code généré par les agents LLM actuels en vibe coding est-il sécurisé? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Les tests de SWE-Agent avec Claude 4 Sonnet ont montré que, bien que 57% du code généré soit fonctionnellement correct, seulement 11,8% est sécurisé contre les vulnérabilités. »}},{« @type »: »Question », »name »: »Les stratégies comme l’ajout d’indices de vulnérabilité améliorent-elles la sécurité en vibe coding? », »acceptedAnswer »:{« @type »: »Answer », »text »: »Les tentatives préliminaires, telles que l’ajout d’indices de vulnérabilité, n’ont pas significativement amélioré les performances de sécurité du code généré par des agents. »}}]}
Article produit avec l’assistance de l’intelligence artificielle et relu par l’équipe éditoriale.
