Technologies

Sécurité : les bons et les mauvais points du vibe coding

Un test de 5 outils de vibe coding montre qu’ils produisent tous du code présentant des failles de sécurité. (Photo : Pixabay)

Le vibe coding produit du code qui n'est pas totalement sécurisé, incluant y compris des failles critiques, souligne une étude. En particulier quand la logique métier est prépondérante. Une supervision attentive permet toutefois de maîtriser ce risque.

PublicitéLes plateformes de vibe coding génèrent systématiquement du code non sécurisé en réponse à des prompts de programmation courants, y compris la création de failles classées comme « critiques », souligne une récente étude Tenzai. Plus précisément, selon cette start-up spécialisée dans la sécurité, ces outils sont efficaces pour éviter les failles de sécurité génériques, mais peinent à distinguer un code sûr d'un code dangereux lorsque le contexte joue un rôle majeur.

Menée en décembre 2025, cette évaluation a comparé cinq des outils de vibe coding les plus connus (Claude Code, OpenAi Codex, Cursor, Replit et Devin) en utilisant des prompts prédéfinis pour créer les trois mêmes tests d'applications. Au total, le code généré par les cinq outils sur 15 applications (trois chacune) contenait 69 failles. Environ 45 d'entre elles ont été classées comme « faibles à modérées » en termes de gravité, tandis que la plupart des autres ont été classées comme « élevées » et une demi-douzaine comme « critiques ». Si le nombre de failles faibles à modérées était identique pour chacun des cinq outils, seulement Claude Code (4 failles), Devin (1 faille), et Codex (1 faille) ont généré des failles jugées critiques.

Les failles les plus graves concernaient la logique d'autorisation des API (vérifier qui est autorisé à accéder à une ressource ou à exécuter une action) et la logique métier (en autorisant un utilisateur à réaliser une action qui ne devrait pas être possible), deux éléments essentiels pour les systèmes de e-commerce par exemple. « Les agents [générateurs de code] semblent très vulnérables aux failles liées à la logique métier. Alors que les développeurs humains ont une compréhension intuitive qui les aide à saisir le bon fonctionnement des processus, les agents ne disposent pas de 'bon sens' et dépendent principalement des instructions explicites », soulignent les chercheurs de Tenzai.

En revanche, ces outils ont permis d'éviter les failles courantes qui affectent depuis longtemps les applications codées par des humains, telles que les vulnérabilités SQLi ou XSS, qui figurent toutes deux dans le Top 10 OWASP (Open Web Application Security Project) des risques de sécurité sur les applications web. « Parmi toutes les applications que nous avons développées, nous n'avons rencontré aucune faille SQLi ou XSS exploitable », confirme Tenzai dans son étude.

Supervision humaine

L'argument de vente du vibe coding repose sur l'automatisation des tâches de programmation quotidiennes, ce qui augmente la productivité. Bien que cela soit indéniablement vrai, le test de Tenzai montre que cette idée présente des limites : la supervision humaine et le 'debugging' restent essentiels. Au cours de l'année qui a suivi le développement du concept de vibe coding, d'autres études avaient déjà démontré que, sans supervision adéquate, ces outils sont susceptibles d'introduire de nouvelles failles de sécurité.

PublicitéMais le problème ne réside pas seulement dans le fait que les plateformes de vibe coding ne détectent pas les failles dans leur code. Dans certains cas, définir ce qui est approprié ou pas à l'aide de règles génériques ou d'exemples est tout simplement impossible. « Prenons l'exemple du SSRF (Server-Side Request Forgery) : il n'existe pas de règle universelle permettant de distinguer les requêtes URL légitimes de celles qui sont malveillantes. La frontière entre sécurité et danger dépend fortement du contexte, ce qui rend impossible toute solution générique », souligne Tenzai.

La conséquence ? Après avoir inventé les agents de vibe coding, l'industrie devrait maintenant se concentrer sur des agents de vérification de ses résultats. Ce qui, bien sûr, est le domaine dans lequel opère Tenzai, une petite start-up tout juste sortie de la phase de développement. « D'après nos tests et nos recherches récentes, il n'existe actuellement aucune solution globale à ce problème. Il est donc essentiel que les développeurs comprennent les pièges fréquents des agents de codage et s'y préparent en conséquence », souligne la start-up.

La clef, bien déboguer

La question fondamentale soulevée par le vibe coding n'est donc pas celle de l'efficacité des outils, mais bien celle de leur utilisation. Et de l'efficacité des contrôles de la production du vibe coding. « Lors de la mise en oeuvre de méthodes de vibe coding, les entreprises doivent s'assurer que des revues de sécurité du code font partie intégrante du cycle de développement et qu'elles sont bien systématiques, appuie Matthew Robbins, responsable de la sécurité offensive au sein la société de services Talion. Les cadres de référence en matière de bonnes pratiques, tels que les Secure Coding Practices d'OWASP, et les normes SEI CERT, doivent aussi être mis à profit. »

Le code doit être testé à l'aide d'analyses statiques et dynamiques avant d'être déployé, ajoute Matthew Robbins. « Bien que le vibe coding présente un risque, celui-ci peut être géré en respectant scrupuleusement les processus et directives standard de l'industrie qui vont au-delà du debugging et de l'assurance qualité traditionnels », souligne le responsable.

Les humains pris de vitesse ?

Cependant, selon Eran Kinsbruner, vice-président du marketing produit chez Checkmarx, une société spécialisée dans les tests applicatifs, le debugging traditionnel risque d'être dépassé à l'ère de l'IA. « Exiger davantage de debugging n'est pas une bonne approche pour résoudre un problème lié à la vitesse de l'IA. Le debugging suppose que les humains puissent examiner de manière pertinente le code généré par l'IA après coup. À l'échelle et à la vitesse du vibe coding, cette hypothèse s'effondre », estime-t-il.

Selon lui, la seule réponse viable consiste à intégrer la sécurité au coeur du processus de génération du code. « En pratique, cela signifie qu'une forme de sécurité agentique doit devenir un élément inhérent aux assistants de codage IA, directement intégré dans les environnements de développement axés sur l'IA, et non ajouté en aval », dit-il.