Vibe coding en entreprise : où l’autoriser, comment l’encadrer
Guide publié le 12 octobre 2026, établi à partir des recommandations de l’ANSSI et des études publiées sur la sécurité du code généré par l’IA.
Le vibe coding, c’est créer un logiciel en le décrivant à une IA plutôt qu’en l’écrivant soi-même. En 2026, un contrôleur de gestion, une chargée de RH ou un ingénieur qualité peuvent construire en une après-midi l’outil qu’ils attendaient de la DSI depuis deux ans. Faut-il l’interdire, le laisser faire, ou l’encadrer ? Ce guide explique ce qu’est le vibe coding, ce que montrent les études sur ses risques, et le cadre en trois couleurs que nous recommandons aux grandes organisations.
Vibe coding : la définition
Le terme a été lancé par Andrej Karpathy, cofondateur d’OpenAI, en février 2025 : il décrivait une façon de programmer où l’on exprime son intention à l’IA et où l’on accepte ce qu’elle produit, sans forcément lire le code. Le dictionnaire Collins en a fait son mot de l’année 2025, le 6 novembre 2025, en le définissant comme une méthode de développement qui transforme le langage courant en code grâce à l’IA.
En entreprise, le mot a pris un sens plus large : on parle de vibe coding dès qu’une personne qui n’est pas développeur fait construire un outil par une IA. C’est l’héritier du « citizen development » et des outils low-code, avec une différence de taille : il n’y a plus de plateforme qui limite ce que l’on peut faire. L’agent écrit du vrai code, qui peut tout faire, y compris des erreurs.
Les outils du vibe coding
| Famille | Exemples | Point d’attention |
|---|---|---|
| Agents de code | Claude Code, OpenAI Codex, GitHub Copilot en mode agent, Cursor, Mistral Vibe | Ils agissent sur des fichiers et peuvent lancer des commandes : à utiliser avec un compte d’entreprise et des droits limités. |
| Plateformes de génération d’applications | Lovable, Replit, Bolt, Base44 | L’application est hébergée en ligne par défaut : c’est là que se concentrent les fuites de données publiées. |
| Fonctions intégrées aux suites | App Builder dans Microsoft 365 Copilot, artefacts de Claude | Restent dans l’environnement de l’entreprise ; le risque devient la prolifération d’outils non documentés. |
Pour choisir entre les agents de code, voir notre comparatif Claude Code ou Codex et notre guide Claude Code en entreprise.
Ce que le vibe coding change vraiment
- Des prototypes en heures plutôt qu’en semaines, pour tester une idée avant de mobiliser la DSI.
- Des outils personnels ou d’équipe qui remplacent un fichier Excel fragile, consolident des exports, automatisent une tâche répétitive.
- Un meilleur dialogue avec les développeurs : un prototype qui marche vaut mieux qu’un cahier des charges.
Ce qu’il ne faut pas en attendre : une application critique, connectée au système d’information et exposée aux clients, construite par une personne seule sans relecture. Ce cas relève toujours d’un projet piloté par la DSI.
Les risques, chiffres à l’appui
Le rapport 2025 de Veracode, qui a fait compléter 80 tâches de code par plus de 100 modèles, montre que dans 45 % des cas les modèles ont introduit une vulnérabilité du Top 10 OWASP. En mai 2026, la société RedAccess a recensé 380 000 applications et bases publiques créées avec Lovable, Base44, Replit ou Netlify, dont environ 5 000 exposaient des informations sensibles d’entreprise, selon VentureBeat. En juillet 2025, un agent de Replit a effacé la base de production d’un utilisateur malgré une consigne de gel des modifications.
Ces chiffres ne disent pas que le code de l’IA est mauvais par nature. Ils montrent qu’il reproduit des failles connues quand personne ne vérifie. Les cinq risques à retenir :
- L’exposition : une application publiée sur internet sans authentification.
- Les secrets : clés d’API ou mots de passe écrits dans le code ou collés dans la conversation.
- Les données : des données personnelles traitées hors du registre RGPD.
- Les actions irréversibles : un agent qui supprime ou envoie, sur des données réelles.
- La dépendance : un outil indispensable que personne d’autre ne sait maintenir.
Ce que disent l’ANSSI, le RGPD et l’AI Act
L’ANSSI et son homologue allemand, le BSI, ont publié en octobre 2024 un document commun sur les assistants de programmation par IA. Ils demandent de n’utiliser ces outils qu’avec l’accord explicite de l’entreprise, de relire et tester le code produit, de maîtriser ce qui est envoyé à l’éditeur, et de se méfier d’un code qui peut paraître parfait tout en étant défectueux.
Côté RGPD, la règle est simple : un outil qui traite des données personnelles est un traitement, quelle que soit la façon dont il a été écrit. Côté AI Act, l’obligation de maîtrise de l’IA de l’article 4, en vigueur depuis le 2 février 2025, concerne aussi les builders ; et une application qui intègre elle-même de l’IA, par exemple pour trier des candidatures, peut relever d’un usage à haut risque.
Interdire, laisser faire ou encadrer ?
Interdire ne marche pas : les outils sont gratuits, accessibles depuis un navigateur ou déjà intégrés à la suite bureautique, et les usages partent sur des comptes personnels. Tout laisser faire ne tient pas non plus : le premier incident sert de prétexte à tout fermer. Nous recommandons un feu tricolore qui trie les projets selon ce qu’ils touchent et à qui ils servent.
| Niveau | Quand | Ce qu’on demande |
|---|---|---|
| Vert : on laisse faire | Outil personnel, données fictives ou non sensibles, sur le poste | Respecter les trois interdits |
| Orange : un référent relit | Outil partagé en équipe, données internes, environnement de l’entreprise | Checklist de revue et inscription au registre |
| Rouge : la DSI valide | Données sensibles ou personnelles, connexion au système d’information, exposition sur internet, IA embarquée, décisions sur des personnes | Revue de sécurité, avis du DPO si besoin, décision de mise en service |
Deux règles rendent ce tri efficace : un seul critère rouge classe le projet en rouge, et un outil personnel qui commence à être partagé passe automatiquement en orange. C’est à ce moment précis que la plupart des outils sortent du radar.
Les trois interdits de la charte builders
- Aucun secret (mot de passe, clé d’API, jeton) confié à l’agent ni écrit dans le code.
- Aucune application publiée sur internet sans l’authentification de l’entreprise.
- Aucune donnée personnelle, sensible ou confidentielle hors du circuit validé par la DSI et le DPO.
Autour de ces trois interdits, une charte builders fixe les outils autorisés, l’environnement de travail, la vérification, le registre, le passage en production, la fin de vie des outils et le signalement des incidents. Elle doit tenir sur deux pages : une charte que personne ne lit ne protège rien.
Téléchargez le kit Vibe coding (Word + Excel, gratuit)
Le guide de 14 pages avec un modèle de charte builders en 14 articles, et le classeur de 7 outils pour piloter le vibe coding dans votre organisation.
- Le feu tricolore calculé en 10 questions
- La charte builders prête à adapter
- La checklist de revue en 20 points
- Le registre des outils et le plan pilote sur 30 jours
Vérifier sans savoir coder
Un builder n’a pas besoin de lire chaque ligne de code. Il doit savoir vérifier. Les réflexes que nous enseignons :
- Spécifier avant de demander : le problème, l’utilisateur, les données, le résultat attendu, ce que l’outil ne doit jamais faire, trois exemples concrets.
- Demander un plan d’abord, le corriger, puis faire construire étape par étape.
- Travailler sur des données fictives tant que l’outil n’est pas validé, et garder un historique des versions.
- Tester les cas limites : fichier vide, très grand fichier, doublons, accents, dates au mauvais format.
- Comparer à un calcul fait à la main sur un petit échantillon.
- Demander à l’agent une revue de sécurité : secrets, accès, saisies, dépendances, actions destructrices.
- Faire tester par un collègue qui n’a pas construit l’outil.
Démarrer en 30 jours
- Semaine 1 : choisir les outils autorisés avec la DSI, adapter la charte, définir l’espace de travail, nommer un référent par direction pilote.
- Semaine 2 : former 8 à 12 builders volontaires à spécifier, construire, vérifier et classer.
- Semaine 3 : chacun construit un outil d’équipe sur un vrai besoin, passe la checklist et l’inscrit au registre.
- Semaine 4 : bilan des outils construits et utilisés, du temps gagné et des points de checklist en échec, puis décision d’extension.
Questions fréquentes
Le vibe coding, c’est du no-code ?
Non. Le no-code assemble des briques prévues par une plateforme. Le vibe coding fait écrire du vrai code par une IA : il va plus loin, mais sans les garde-fous d’une plateforme, d’où le besoin de règles.
Faut-il savoir programmer pour faire du vibe coding ?
Non pour construire un outil simple. Mais il faut savoir spécifier un besoin, tester avec des cas limites et reconnaître ce qui doit passer par la DSI. Cela s’apprend en une journée.
Quels outils autoriser ?
Ceux que la DSI peut gérer avec des comptes d’entreprise : agents de code sous licence professionnelle, fonctions intégrées à la suite bureautique. Les plateformes qui hébergent l’application en ligne par défaut demandent des règles plus strictes, notamment sur l’authentification.
À lire aussi : Claude Code en entreprise, Claude Code ou Codex : quel agent de code choisir, Claude Skills : 10 skills prêtes à installer et Cowork, Work, Vibe Work : quatre façons de déléguer du travail à une IA.
Sources
- ANSSI et BSI, AI Coding Assistants, 4 octobre 2024.
- Veracode, 2025 GenAI Code Security Report, 30 juillet 2025.
- VentureBeat, 5,000 vibe-coded apps just proved shadow AI is the new S3 bucket crisis, 8 mai 2026.
- eWeek, AI Agent Wipes Production Database, Then Lies About It, juillet 2025.
- Cloud Security Alliance, The Vibe Coding Governance Gap, 2 juin 2026.
