Les risques liés à la sécurité du Vibe Coding ne sont pas comparables aux risques de sécurité habituels

Il était probablement inévitable que le vibe coding entraîne une série de changements complexes dans les pratiques de codage et le développement de logiciels. Alors que le code généré par l’IA continue de constituer une part plus importante des bases de code réelles, l’un des changements les plus importants a été un changement majeur de l'ampleur des risques liés à la cybersécurité, et la nature de ces risques.

En résumé, le Vibe coding est la notion de créer des produits avec rien que des outils d'IA et des prompts. Il convient de le distinguer du codage agentique ou de l'ingénierie agentique, qui impliquent une utilisation plus réfléchie des outils de codage d'IA par un programmeur expérimenté. Le terme a été inventé dans un tweet d'Andrej Karpathy, un développeur renommé et vétéran de l'IA, dans lequel il décrivait un style de AI Coding débridé qui repose entièrement sur les incitations d'un grand modèle de langage (LLM), permettant à l'utilisateur de « se laisser complètement porter par l'inspiration » et d'« oublier que le code existe ».

Il l’a décrit comme une approche ludique pour des « projets de week-end sans lendemain », mais la prolifération de l’IA puissante dédiée au codage a ouvert la voie au Vibe coding sur le lieu de travail, y compris dans les logiciels de production traitant des données sensibles. Fin 2025, des études sectorielles indiquaient que le code généré par l’IA représentait désormais 22 % de l’ensemble du code intégré.¹ Sur GitHub, les rapports estiment que 46 % de l'ensemble du code écrit a été généré par Copilot.²

Cette situation a entraîné une augmentation majeure du nombre de vulnérabilités et des problèmes de sécurité, au-delà de ce qui pourrait être expliqué par l’augmentation naturelle du volume et de la vitesse du nouveau code rendu possible par les assistants de codage. Une analyse de bases de code réelles a révélé que, si les équipes assistées par l'IA livraient du code quatre fois plus rapidement, elles généraient en revanche dix fois plus de failles de sécurité.³

Renoncer complètement au Vibe Coding reviendrait à renoncer à des gains de productivité considérables liés à l'automatisation et à une participation accrue, mais il est clair que les pratiques de codage sécurisé doivent évoluer en conséquence. Les contrôles de sécurité traditionnels sont conçus pour remédier aux erreurs que commettent généralement les développeurs, plus précisément les développeurs humains ayant reçu une formation. Les entreprises ont désormais besoin d’une posture de sécurité modernisée et d’outils de sécurité perfectionnés, adaptés à la nouvelle réalité portée par les agents IA et les personnes novices qui pratiquent le vibe coding.

Qu’il s’agisse de différentes plateformes, d’environnements ou de modèles de langage de grande envergure (LLM), les études menées dans le secteur montrent systématiquement que le recours accru à la génération de code par l’IA s’accompagne d’une augmentation des vulnérabilités en matière de sécurité des applications (AppSec).

Exemples :

• Une étude de décembre 2025 sur les référentiels open source a révélé que le code généré par l’IA introduisait des vulnérabilités de sécurité dans 45 % des tâches de développement. En comparant les pull requests (PR) assistées par l’IA aux PR uniquement humains, les chercheurs ont constaté que les PR alimentées par l’IA généraient 2,74 fois plus de problèmes de sécurité (et 1,7 fois plus de problèmes au total) que le code écrit par des humains.⁴

• Un rapport de GitGuardian publié en 2026 sur la prolifération des secrets affirme que les commits assistés par Claude Code révélaient des secrets plus de deux fois plus souvent que les commits réservés aux humains. Au total, le nombre de données confidentielles codées en dur (telles que les mots de passe et les clés API) exposées dans des commits GitHub publics a augmenté de 34 % en glissement annuel en 2025, ce qui représente la plus forte hausse jamais enregistrée en une seule année.⁵ 

• Un rapport d’octobre 2025 a noté que les vulnérabilités critiques et les expositions de données dans les applications codées par vibe, telles que des API mal configurées et d’autres problèmes d’authentification, étaient souvent exposés « à la vue de tous », accessibles directement via des endpoints publics.⁶

Les équipes de sécurité doivent également garder à l’esprit que les dépôts publics sur GitHub (et les services similaires) ne constituent que la partie émergée de l’iceberg. GitGuardian indique que les dépôts internes sont six fois plus susceptibles de contenir des secrets codés en dur que les référentiels publics.

Tout aussi préoccupant est le fait que les identifiants sensibles exposés dans le cadre du Vibe Coding semblent moins susceptibles d’être traités et corrigés que les problèmes de sécurité découlant des processus de développement traditionnels. Le rapport de GitGuardian indique que près de 70 % des identifiants exposés qui avaient été validés comme légitimes en 2022 sont restés valides jusqu’en janvier 2025. 64 % étaient encore exposés et non révoqués en janvier 2026. Dans un incident notable, Football Australia a involontairement exposé ses clés d’accès AWS dans le code source de son site web, elles sont restées exposées pendant plus de 700 jours.

Dans l’ensemble, ces tendances laissent penser que les risques de sécurité liés au Vibe Coding s’accumulent à un rythme supérieur à celui pour lequel les programmes de résolution traditionnels ont été conçus.

La fréquence et l’ampleur des failles de sécurité dérivées de l’IA semblent persister même si les fonctionnalités des LLM continuent de s’améliorer. Les observateurs du secteur ont donc suggéré que les modules de formation et les benchmarks utilisés pour optimiser et valider les performances des modèles ne sont pas toujours naturellement adaptés à la génération de code sécurisée dans le monde réel.⁴ La plupart des études évaluent le code généré par l'IA de manière isolée, en mettant l'accent sur son exactitude (à savoir s'il se compile, s'exécute et accomplit sa tâche) et sur sa performance sur des benchmarks de référence.⁷

Mais dans les environnements de développement d'entreprise, les modèles ne fonctionnent pas de manière isolée. Le rapport de GitGuardian a révélé que l’infrastructure liée aux LLM, telles que les services d’orchestration, de génération augmentée de récupération (RAG) ou de stockage vectoriel, exposait des secrets à un taux cinq fois supérieur à celui des fournisseurs de modèles principaux.⁵

En d'autres termes, de nombreux risques de sécurité liés au Vibe Coding ne sont pas dérivés des LLM : ils découlent de l'écosystème dans lequel les modèles sont utilisés. Les nouveaux fournisseurs d’inférence, passerelles, registres et couches d’Intégration sont rapidement intégrés aux workflows de production, souvent trop rapidement pour que les mesures de sécurité (ou les développeurs débutants) puissent suivre le rythme.

L'IA agentique ajoute une complexité supplémentaire aux enjeux de sécurité : lorsqu'un agent d'IA se voit accorder un accès local aux fichiers, aux référentiels d'identifiants et aux terminaux, l'ordinateur lui-même peut devenir une nouvelle surface d'attaque potentielle. L’injection de prompt et les attaques dans la chaîne d’approvisionnement qui exploitent des références locales exposées peuvent se transformer en risques organisationnels. Dans le cas du tristement célèbre ver Shai-Hulud, qui a compromis le plus grand registre JavaScript au monde fin 2025, près de 60 % des machines compromises n'étaient pas des postes de travail personnels, mais des environnements d'exécution d'intégration continue/livraison continue (CI/CD)⁴ (dont l'objectif, ironiquement, est justement d'automatiser les tests de sécurité et de garantir la qualité du code).

Un facteur aggravant important des risques liés à la sécurité du codage « vibe » réside dans la manière dont les modifications de code générées par l'IA sont généralement regroupées : en moyenne, les développeurs assistés par l'IA produisent plus de trois fois plus de commits que leurs homologues travaillant de manière traditionnelle, mais regroupent ces commits dans un nombre nettement inférieur de pull requests (PR), qui sont par ailleurs beaucoup plus volumineuses. Ces PR issues du Vibe Coding ont généralement une portée plus large, modifiant plusieurs fichiers et services.

Le « Rapport sur les habitudes des développeurs » de Cursor, publié au printemps 2026, indiquait que le nombre moyen de lignes de code par pull request avait augmenté d'environ 250 % d'une année sur l'autre (et que ce taux de croissance lui-même s'accélérait). Les « méga-PR », que Cursor définit comme des PR contenant des modifications portant sur au moins 1 000 lignes de code, sont passées d’une part de 8 % de l’ensemble des PR en janvier 2025 à 13,9 % de l’ensemble des PR en mai 2026.⁸

Les pull requests volumineuses et tentaculaires, qui touchent de nombreuses parties de la base de code, sont bien plus difficiles à examiner de manière exhaustive que les pull requests plus petites et mieux ciblées. Des modifications isolées apportées à un service ou à un bloc de code peuvent nécessiter des modifications supplémentaires ailleurs afin d’éviter des problèmes en aval, mais ces effets secondaires ont moins de chances d’être détectés lors de la révision du code si la pull request examinée adopte une approche « à l’aveuglette » qui détourne l’attention du réviseur. Une étude menée par Apiiro, une plateforme dédiée à la sécurité des applications, a révélé que, bien que le volume de PR des équipes assistées par l’IA ait diminué de près d’un tiers, ces équipes ont livré 10 fois plus de failles de sécurité.³

Bref, l'IA accélère chaque étape de la création de code, y compris la mauvaise habitude d'implémenter trop de modifications à la fois. Le fait de concentrer et d'accélérer le changement peut également concentrer et accélérer les risques liés à chaque fusion.

Une étude à grande échelle portant sur 500 000 échantillons de code, présentée lors du 36e symposium international de l’IEEE sur la fiabilité des logiciels (ISSRE 2025), a déterminé que « le code généré par l’IA diffère du code écrit par des humains non seulement par le nombre de vulnérabilités de sécurité, mais aussi par leur nature et leur distribution. » 

Cela soulève une préoccupation existentielle : les cadres existants pour évaluer la qualité du code et les vulnérabilités sont « centrés sur l’humain, conçus autour d’hypothèses concernant la cognition humaine, les modes d’erreur et les processus de révision. » Le code généré par l'IA présente des caractéristiques et des tendances nettement différentes, ce qui rend ces cadres d'évaluation centrés sur l'humain inadaptés à son analyse.⁷

Pour aggraver encore la situation, les recherches menées sur les risques de sécurité liés au codage automatique ont également mis en évidence de multiples types d'attaques émergentes qui n'ont pas d'équivalent dans les logiciels codés par des humains.

Les LLM, et les outils de codage IA qu'ils alimentent, ont tendance à recommander des packages qui n'existent pas réellement, et des recherches ont montré que ces noms de packages hallucinés se répètent parfois dans différents scénarios et même dans différents modèles. Le « slopsquatting », une forme d'attaque de type « hallucination de paquet », exploite cette tendance.

Les cybercriminels pratiquant le slopsquatting observent les noms des paquets hallucinés que les LLM génèrent de manière répétée et préenregistrent ces noms de paquets (auparavant) fictifs sur des registres publics. Lorsque des développeurs Vibe, qui ne connaissent souvent pas du tout les bibliothèques couramment utilisées (et sont donc peu susceptibles de repérer une fausse bibliothèque), valident du code contenant ces noms de bibliothèques, ils installent sans le savoir du code malveillant.

Ce phénomène n'a pas d'équivalent dans le développement logiciel traditionnel. Un programmeur humain aurait peu de chances d’inventer de toutes pièces un paquet qui n’existe pas, et même si c’était le cas, il serait à la fois impossible et peu réaliste pour un cybercriminel potentiel de le prévoir, de deviner le nom de ce paquet imaginaire et d’enregistrer du code malveillant sous ce nom de paquet.

Les attaques de type « porte dérobée dans les fichiers de règles » exploitent les fichiers de configuration (« règles ») utilisés pour personnaliser le comportement des agents d'IA lors de la génération ou de la modification de code sur des plateformes telles que Cursor, GitHub Copilot et Claude Code.

Les cybercriminels modifient généralement des fichiers de règles open source populaires, en y intégrant des instructions malveillantes sous la forme de caractères Unicode cachés, pratiquement impossibles à détecter. Une fois ces modifications acceptées, ce code malveillant sera activé lors de chaque session de AI coding suivante faisant référence au fichier de règles infecté. Par conséquent, tout code généré au cours de ces sessions sera compromis ; toutefois, comme le résultat compromis est constitué de caractères Unicode qui sont pour l'essentiel invisibles, il semble correct lors de la révision du code.

L'objectif des cybercriminels consiste généralement à introduire des vulnérabilités et des « portes dérobées » dans le code généré par la suite (ainsi que dans les applications utilisant ce code), afin de pouvoir les exploiter ultérieurement.

Bien informées de ces schémas spécifiques, les organisations devraient actualiser leurs bonnes pratiques en matière de sécurité afin de tirer parti des avantages du code généré par l'IA sans pour autant être victimes des vulnérabilités découlant d'un codage Vibe Coding irréfléchi.

Bien que ces failles de sécurité puissent provenir des imperfections des outils d'AI coding, la prise de conscience de ces risques est due à un échec de supervision humaine. En fin de compte, ce sont toujours les développeurs qui décident quelles modifications et quels ajouts sont acceptés, révisés ou ignorés. Les assistants de codage continuent d'étendre et d'améliorer leurs garde-fous intégrés, mais la vérification humaine reste le dernier obstacle à la mise en production des vulnérabilités de sécurité, c'est pourquoi les paramètres par défaut d'IBM intègrent des vérifications manuelles et une validation par un intervenant humain à chaque étape.

Cela dit, il existe des moyens d’améliorer l’efficacité de la vérification humaine.

• Les failles dissimulées dans des pull requests volumineuses et très étendues sont nettement plus difficiles à spotter lors d'un contrôle de sécurité que celles qui se trouvent dans des pull requests plus ciblées. Les équipes de sécurité devraient donc mettre en place des directives adaptées concernant la taille des PR.

• Les paquets doivent faire l'objet d'un examen particulièrement minutieux afin de minimiser le risque d'attaques de type « slopsquatting ». Les équipes de sécurité doivent garder à l'esprit qu'à chaque nouvelle itération d'un modèle d'IA donné, de nouveaux schémas d'« hallucinations » au niveau des paquets peuvent apparaître.

• Les développeurs et les équipes de sécurité devraient se familiariser avec les différences entre les défauts de code écrits par l'homme et ceux générés par l'IA.

Les entreprises devraient considérer le code généré par l'IA comme une catégorie distincte de données d'entrée nécessitant des contrôles de sécurité spécifiques et dédiés (plutôt que de se contenter d'intégrer les résultats de l'IA dans des processus de révision standard, conçus pour l'intervention humaine).

En règle générale, les entreprises doivent traiter tout code ou module dérivé de l’IA comme une entrée non fiable de la même manière qu’elles traiteraient le code d’une bibliothèque externe. Les tests de sécurité par analyse statique (SAST) devraient constituer une étape obligatoire que toutes les contributions issues de l'IA doivent franchir avant d'être intégrées au code source. Les fichiers de règles tiers, tels que les fichiers open source, les règles Cursor préconfigurées, les fichiers Claude.md , les instructions Copilot ou les Modes Bob, doivent faire l'objet d'un examen minutieux et être ensuite ajoutés de manière sélective à une liste blanche, plutôt que d'être autorisés par défaut.

L'amélioration continue des plateformes d'ingénierie agentique offre la possibilité de combattre le feu par le feu grâce à la détection des secrets basée sur l'IA, dans laquelle les identifiants spécifiques à l'IA, tels que les clés API des modèles de langage à grande échelle (LLM) ou les jetons de bases de données vectorielles, disposent de leurs propres signatures de détection dédiées.

 IBM Bob, par exemple, dispose d’outils intégrés pour imposer un codage sécurisé et un contrôle d’accès à grande échelle grâce à une combinaison de modes personnalisés de Bob, de l'intégration de HashiCorp Vault et d'IBM MCP Gateway. Il effectue également une révision du code en temps réel, en analysant celui-ci pour détecter les problèmes de complexité, les vulnérabilités potentielles et les possibilités de refactorisation pouvant être traitées directement ou examinées ultérieurement dans le panneau Bob Findings .

La capacité à détecter les défauts récemment introduits dans une base de code dépend en grande partie de la lisibilité de cette base de code. L'établissement et l'application de normes de qualité du code sont donc essentiels pour faciliter des vérifications de sécurité productives. L'adoption de normes communes et la refactorisation régulière permettront d'optimiser les chances d'identifier et de corriger le code présentant des failles de sécurité.