Vibe coding et cybersécurité : la dette cachée du code généré par l'IA

En moins de trois ans, l'intelligence artificielle est passée du gadget à l'outil de travail quotidien pour des millions de développeurs. GitHub Copilot, ChatGPT, Cursor, Claude : écrire une fonction, un composant ou une page entière en décrivant simplement son intention est devenu la norme. La promesse est bien réelle – on va plus vite. Mais une question, longtemps restée théorique, est désormais mesurable : à quel prix pour la qualité du code, et surtout pour sa sécurité ?

Chez Webego, nous accompagnons des entreprises qui intègrent ces outils dans leurs projets web. Nous en tirons un constat simple : l'IA est un formidable accélérateur, mais utilisée sans méthode, elle fabrique une dette invisible qui se paie plus tard – en bugs, en failles, et en heures de maintenance. Cet article fait le point, chiffres officiels à l'appui, sur le lien entre le « vibe coding » et le risque cyber, puis détaille les garde-fous concrets pour capter la vitesse de l'IA sans hériter de ses défauts.

Le « vibe coding », c'est quoi exactement ?

L'expression « vibe coding » s'est popularisée début 2025. Elle décrit une manière de programmer où l'on formule une intention en langage naturel (« crée-moi un formulaire de contact qui envoie un e-mail ») et où l'on accepte la production de l'IA sans nécessairement la lire, la comprendre ou la vérifier en profondeur. On code « au feeling », en se laissant porter par ce que la machine propose.

Il faut distinguer deux usages qui n'ont rien à voir. D'un côté, le développement assisté : un développeur expérimenté utilise l'IA pour aller plus vite, mais relit, teste et corrige chaque suggestion – il garde le contrôle. De l'autre, le vibe coding au sens strict : on délègue non seulement l'écriture, mais aussi le jugement. C'est cette seconde pratique qui pose problème, car personne ne valide réellement ce qui part en production.

Pourquoi se répand-elle ? Parce que la pression à livrer vite est constante, parce que l'IA rend le développement accessible à des profils non techniciens, et parce que son adoption est massive : selon l'enquête Stack Overflow 2024, près de deux développeurs sur trois déclarent déjà utiliser l'IA dans leur processus de développement. Le métier se transforme : le développeur devient en partie relecteur et « prompteur ». Encore faut-il qu'il relise vraiment.

Ce que les données révèlent : la qualité du code se dégrade

Ce n'est plus une intuition, c'est mesuré. L'outil d'analyse GitClear a examiné 623 millions de changements de code réalisés entre 2023 et 2026, dans des dépôts appartenant à de grandes entreprises technologiques et à des sociétés de toutes tailles, à mesure que la part de code écrite avec l'IA augmentait. Le résultat n'est pas un jugement esthétique : c'est un faisceau d'indicateurs objectifs, tous orientés dans le mauvais sens.

La lecture est sans appel. On copie-colle désormais près de cinq fois plus qu'on ne réorganise le code. Les blocs dupliqués atteignent leur plus haut niveau jamais mesuré. Le refactoring – ce travail de fond qui consiste à ranger, simplifier et factoriser – s'est effondré. Et l'on produit de plus en plus de code que l'on jette presque aussitôt (le « churn »).

Aucun de ces indicateurs ne juge le talent des développeurs. Ils mesurent la durabilité du code : sa capacité à être compris, corrigé et fait évoluer dans le temps. Or un code moins durable est, mécaniquement, un code plus difficile à auditer… et donc à sécuriser.

Le phénomène s'auto-entretient. Plus le code est dupliqué et instable, plus il devient coûteux d'y ajouter des tests ou de le sécuriser ; les équipes, sous pression, préfèrent alors générer une nouvelle version plutôt que de comprendre l'ancienne. La dette s'accumule silencieusement, jusqu'au jour où un incident – un bug bloquant ou une faille exploitée – la rend soudain visible, et très chère à rembourser.

Pourquoi maintenabilité rime avec sécurité

On pourrait croire que qualité et sécurité sont deux sujets distincts. En réalité, ce sont les deux faces d'une même pièce. Un code difficile à maintenir est un code difficile à protéger. La chaîne de cause à effet est directe :

• La duplication propage les failles. Une fonction vulnérable copiée-collée à douze endroits, ce sont douze correctifs à appliquer le jour où la faille est découverte – et il y en aura toujours un qu'on oubliera. Un code factorisé se corrige en un seul point ; un code dupliqué se corrige partout, ou nulle part.
• L'absence de refactoring crée des angles morts. Un code que l'on ne réorganise jamais devient un empilement que plus personne ne comprend entièrement. Et l'on ne protège pas ce que l'on ne comprend pas : les zones que personne ne relit sont exactement celles qu'un attaquant explore.
• Les erreurs masquées cachent les intrusions. La hausse de 47 % des constructions qui « avalent » les erreurs est un signal de sécurité majeur. Une exception ignorée en silence, c'est une défaillance – parfois une tentative d'intrusion – qui ne déclenche aucune alerte.
• Le churn élevé laisse passer les régressions. Du code écrit vite, remplacé vite et mal testé laisse filer des régressions, y compris de sécurité : un contrôle d'accès désactivé « le temps d'un test », une validation retirée et jamais remise.

La recherche académique va dans le même sens : les blocs de code dupliqués sont associés à un taux de défauts plus élevé. Autrement dit, la dette technique et la dette de sécurité ne sont pas deux dettes différentes – c'est la même dette, et le vibe coding la contracte plus vite qu'on ne la rembourse.

Les risques concrets du vibe coding

Au-delà des statistiques, voici les dangers très concrets que nous rencontrons sur le terrain quand l'IA produit du code accepté sans vérification.

1. Des secrets en clair

Les modèles proposent régulièrement des exemples contenant des clés d'API, des mots de passe ou des jetons d'authentification « en dur » dans le code. Copiés tels quels puis poussés sur un dépôt – parfois public – ces secrets deviennent une porte d'entrée directe. De nombreuses fuites de données commencent exactement ainsi : une clé oubliée dans un commit.

2. Des réglages non sécurisés par défaut

L'IA propose souvent le chemin le plus court, rarement le plus sûr. On retrouve typiquement des requêtes SQL construites par concaténation (ouvrant la porte à l'injection SQL), un partage de ressources entre origines (CORS) ouvert à tous, une validation des entrées absente, ou un chiffrement faible voire obsolète. Chacun de ces « détails » est une vulnérabilité classique – et le code généré les reproduit d'autant plus qu'ils sont fréquents dans les exemples publics sur lesquels les modèles ont appris.

3. Des dépendances fantômes (le « slopsquatting »)

C'est un risque récent et particulièrement vicieux. Les modèles « hallucinent » parfois le nom d'une librairie qui n'existe pas. Des attaquants surveillent ces noms inventés, les enregistrent sur les registres publics (npm, PyPI…) et y déposent du code malveillant. Le développeur qui installe la dépendance suggérée par l'IA importe alors, sans le savoir, un cheval de Troie directement au cœur de son application. C'est une attaque de la chaîne d'approvisionnement logicielle rendue possible par le vibe coding.

Concrètement : un modèle suggère d'installer un paquet au nom plausible mais inexistant. Un attaquant qui a anticipé cette hallucination l'a déjà publié, piégé. En une seule commande d'installation, le code malveillant s'exécute avec les mêmes droits que votre application – lecture des bases de données, accès aux secrets, exfiltration – sans qu'aucune ligne suspecte n'apparaisse dans votre propre code.

4. Du code non maîtrisé

C'est le risque le plus insidieux, car il n'a pas de signature technique : livrer une logique que l'on serait incapable d'expliquer. Le jour d'un incident de sécurité, une équipe qui ne comprend pas son propre code est paralysée – impossible de diagnostiquer rapidement, de corriger sereinement, ou d'auditer. La vitesse gagnée à l'écriture est alors reperdue, au centuple, pendant la crise.

En France, la cybercriminalité ne faiblit pas

Ce risque ne se joue pas dans le vide. Pendant que la qualité du code baisse, la pression cyber, elle, monte. Les statistiques officielles du Service statistique ministériel de la sécurité intérieure (SSMSI), publiées en open data par le ministère de l'Intérieur, le confirment sans ambiguïté.

Le rapprochement est parlant : la surface d'attaque logicielle s'élargit – plus de code, plus dupliqué, moins audité – au moment précis où la cybercriminalité progresse en France. Chaque raccourci de développement devient une porte potentielle, dans un contexte où les portes sont de plus en plus poussées. Face à des attaquants qui automatisent eux aussi leurs méthodes, laisser des vulnérabilités élémentaires dans son code n'est plus une négligence anodine : c'est une invitation.

Ces données proviennent du jeu ouvert « SSMSI – Base des séries chronologiques », publié sous licence ouverte sur data.gouv.fr.

Coder avec l'IA sans creuser la dette : le protocole Webego

L'IA n'est pas l'ennemie. Le problème n'est jamais l'outil – c'est l'absence de garde-fous. Voici les pratiques que nous mettons en place avec nos clients pour profiter de la vélocité de l'IA sans en subir la dette.

1. Revue humaine systématique. Aucune ligne générée ne part en production sans qu'un développeur l'ait lue, comprise et validée. L'IA propose, l'humain dispose – et reste responsable de la logique livrée.
2. Analyse statique automatisée (SAST). Un outil scanne le code à chaque enregistrement (commit) et détecte automatiquement les motifs dangereux : injections, secrets, mauvaises pratiques, avant tout déploiement.
3. Contrôle des dépendances (SCA) et verrouillage des versions. On vérifie chaque librairie importée – existence réelle, réputation, vulnérabilités connues – et l'on fige les versions dans un fichier de verrouillage. C'est la première parade contre le slopsquatting.
4. Détection de secrets. Un scanner de secrets branché sur le dépôt bloque tout envoi contenant une clé ou un mot de passe, avant même qu'il ne quitte le poste du développeur.
5. Tests automatisés et maîtrise du churn. Des tests attrapent les régressions ; un code couvert par des tests se réécrit moins « à l'aveugle » et reste stable dans la durée.
6. Culture du « comprendre avant d'accepter ». La règle la plus simple, et la plus efficace : si personne dans l'équipe ne peut expliquer ce que fait un bloc de code, il ne passe pas. Point final.

Conclusion

Le vibe coding n'est pas une mode passagère : c'est la nouvelle façon d'écrire du logiciel, et elle est là pour rester. Mais les données sont claires – livré sans discipline, il échange de la vitesse aujourd'hui contre de la dette technique et de sécurité demain. Dans un contexte de menace cyber croissante, mesurée noir sur blanc par les chiffres de l'État, ce troc peut coûter très cher.

La bonne nouvelle, c'est que le remède est connu et à la portée de toute équipe sérieuse : garder l'humain dans la boucle, outiller la revue et la sécurité, et ne jamais livrer ce que l'on ne comprend pas. L'IA est un excellent copilote. Elle reste un très mauvais commandant de bord.

Sources

• GitClear – The Maintainability Gap : 2026 AI Code Quality Research (623 M de changements analysés, 2023–2026).
• GitClear – AI Copilot Code Quality, 2025 (211 M de lignes, 2020–2024).
• SSMSI / Ministère de l'Intérieur – Les infractions liées au numérique enregistrées de 2016 à 2023.
• Données ouvertes – SSMSI – Base des séries chronologiques, data.gouv.fr.