Le vibe coding — décrire une app en langage naturel et laisser l'IA la générer — a transformé le prototypage. En entreprise, la promesse est séduisante : des équipes métier qui produisent leurs propres outils sans attendre l'IT. Le problème, c'est ce qui se passe quand ces outils quittent le bac à sable pour la production.
Pourquoi "ça marche en démo" ne suffit pas en entreprise
Une démo répond à une question : est-ce faisable ? La production en pose d'autres : est-ce sûr, traçable, maintenable, conforme ? Le générateur optimise pour la première, pas pour les secondes. Et en entreprise, ce sont les secondes qui comptent — parce qu'un incident ne touche pas un écran de démo, il touche des clients, des données réglementées, une réputation.
Quatre murs reviennent systématiquement.
1. La sécurité
C'est le mur le plus dangereux parce qu'il est invisible à l'usage. Une étude de Stanford estime que 45 % du code généré par IA contient des vulnérabilités. Sur les apps no-code IA adossées à Supabase, le RLS mal configuré expose les données : la faille publique CVE-2025-48757 a montré 1 app sur 10 en fuite sur la vitrine de Lovable elle-même.
Le générateur produit ce qui s'affiche, pas ce qui protège. Tant que personne n'audite, l'application semble fonctionner parfaitement — pendant qu'elle laisse potentiellement fuiter des données.
2. La dette technique
Le code généré devient vite une boîte noire : logique dupliquée, contextes étroits, conventions absentes. Tant qu'on reste dans le périmètre que l'IA maîtrise, ça avance. Dès qu'il faut modifier finement, intégrer un système existant ou diagnostiquer un bug subtil, la dette se paie — et personne dans l'équipe ne comprend vraiment ce que le code fait.
C'est le "mur de la complexité" : passé 80 %, chaque correction de l'IA risque d'en casser une autre.
3. La gouvernance et le shadow IT
Quand des outils naissent en dehors de l'IT, ils ignorent souvent les conventions de l'entreprise : nommage, intégration au SI, gestion des accès, sauvegardes. On se retrouve avec une prolifération d'outils non recensés — du shadow IT — que personne ne pilote et que personne ne peut reprendre si la personne qui l'a créé part.
Le risque n'est pas l'outil lui-même, c'est l'absence de propriété claire et de gouvernance.
4. La conformité
Les outils générés par IA ne s'alignent pas spontanément sur SOC 2, RGPD, HIPAA ou les politiques internes. Journalisation des accès, durée de conservation, localisation des données, traçabilité : autant de sujets que le générateur ne traite pas, et qui sont non négociables en entreprise dès qu'on touche à des données personnelles ou réglementées.
Comment encadrer le vibe coding en entreprise
Le vibe coding n'est pas à bannir — il est à cadrer. Les pratiques qui tiennent :
- Revue de sécurité systématique avant toute mise en production (RLS, accès, surface anon, dépendances).
- Tests automatisés (statiques et dynamiques) intégrés au cycle, pas optionnels.
- Un humain qui valide le modèle de menace : quelles données, quels accès, quels cas d'abus.
- Une gouvernance : inventaire des outils, propriété claire, conventions, plan de reprise.
- Une ligne nette entre proto (vibe coding libre) et production (cadre strict ou reprise sur mesure).
FAQ — vibe coding en entreprise
Faut-il interdire le vibe coding aux équipes métier ?
Non. L'interdire pousse le shadow IT dans l'ombre. Mieux vaut l'encadrer : autoriser le prototypage libre, et imposer une revue de sécurité + une décision (reprise ou non) avant toute mise en production avec des données réelles.
Le code généré peut-il passer un audit SOC 2 ou RGPD ?
Pas en l'état, généralement. Il faut ajouter la journalisation, la gestion fine des accès, la maîtrise de l'hébergement et la traçabilité — autant d'éléments que la génération ne fournit pas. C'est faisable en reprenant la base proprement.
Comment savoir si un outil interne généré est à risque ?
Commencez par la surface la plus exposée : la sécurité des données. Un audit gratuit teste, en lecture seule, ce qui est accessible sans authentification. C'est le point de départ le plus rapide.
Le vibe coding va-t-il devenir sûr par défaut ?
Il progresse, mais la sécurité et la conformité sont des décisions de conception, pas de génération. Tant qu'un humain ne valide pas le modèle de menace et la gouvernance, le "ça marche" de l'IA ne garantit pas le "c'est conforme".
Ce qu'on en retient
- Quatre murs en production : sécurité, dette technique, gouvernance, conformité.
- Le plus dangereux est invisible : la sécurité (45 % du code IA est vulnérable).
- Cadrer plutôt qu'interdire : revue de sécurité, tests, gouvernance, ligne proto/production.
- La conformité (SOC 2, RGPD) se construit — elle ne se génère pas.
Un outil interne généré qui porte des données réelles ? Auditez-le avant qu'il ne devienne un risque.