La thèse en une phrase : générer une app « aux vibes » —tu décris ce que tu veux et l’IA écrit le code— est merveilleux pour prototyper et un désastre pour tenir en production. Pas parce que le code sort mauvais : aujourd’hui il sort étonnamment bon. C’est parce qu’une app vivante n’est pas le code qu’on voit dans la démo ; c’est tout ce qu’on ne voit pas —les tests qui préviennent quand quelque chose casse, l’observabilité qui te dit pourquoi, la sécurité qui empêche qu’un client voie les données d’un autre, et une personne qui répond quand ça tombe à trois heures du matin. C’est le 70 % ennuyeux, et c’est justement ce que le vibe coding ne te donne pas du même geste qui te donne le bel écran.
Ce qu’est le vibe coding en production et pourquoi il trompe tant
Le terme a été popularisé par Andrej Karpathy début 2025 pour décrire une chose qu’on faisait déjà tous : se laisser porter, décrire à l’IA ce qu’on veut et accepter le code qu’elle renvoie sans le lire ligne par ligne. Et ça marche : en une après-midi tu as une app qui démarre, qui fait le login, qui enregistre des choses dans une base de données et que tu montres en réunion sous les applaudissements. Le problème, ce n’est pas cette après-midi. Le problème, c’est la conclusion que presque tout le monde en tire : « si j’ai monté ça en une après-midi, le système entier est à une semaine ». Il ne l’est pas. Ce que tu as monté, c’est la partie qu’on voit, et la partie qu’on voit est la partie bon marché.
C’est le même mirage que d’habitude, en habits neufs. Une démo qui marche avec des données propres, un seul utilisateur et zéro trafic réel ne dit rien de ce qui se passe quand mille personnes arrivent, que la moitié des données arrivent à moitié remplies et que quelqu’un tente d’entrer là où il ne devrait pas. La démo est une promesse ; la production, c’est l’encaissement de cette promesse. Et entre les deux se trouve le travail dont personne ne parle à l’appel de vente, parce qu’il ne brille pas sur un écran.
Ce que le vibe coding ne génère pas (et c’est ce qui sépare la démo du système)
Ce n’est pas que l’IA écrive du code faible. C’est qu’un système en production est bien plus que du code, et ces autres couches ne sortent pas d’un joli prompt. Voici celles qui manquent presque toujours :
- Des tests qui préviennent avant le client. Le code généré fait ce que tu as demandé le jour où tu l’as demandé. Personne ne garantit qu’il le fera encore quand tu toucheras autre chose dans trois semaines. Sans filet de tests, chaque changement est un pari et celui qui découvre que tu as cassé quelque chose, c’est ton utilisateur.
- L’observabilité : savoir ce qui se passe quand ça se passe. Dans la démo, si ça casse, tu le vois sur ton écran. En production ça casse sur le téléphone d’un client à 800 km et tu ne l’apprends pas, sauf si tu as monté logs, métriques et alertes. Sans ça, ta première source de monitoring est un mail furieux.
- Sécurité et isolation des données. Le vibe coding te monte le login ; ce qu’il te monte rarement bien, c’est que l’utilisateur A ne puisse pas, en touchant l’URL, voir les données de l’utilisateur B. Les permissions, l’isolation entre clients et le traitement des données personnelles sont précisément là où une app improvisée devient une fuite.
- Un responsable et un processus. Un système vivant a besoin de quelqu’un qui le déploie avec jugement, qui décide ce qu’on touche et ce qu’on ne touche pas, et qui est là quand ça tombe. Du code sans responsable n’est pas un système : c’est une bombe à retardement qui marche jusqu’à ce qu’elle s’arrête et que personne ne sache pourquoi.
Chacun de ces points est invisible dans la démo et déterminant en production. Et aucun ne se règle avec un meilleur prompt : ça se construit avec du métier, ce que justement le vibe coding te pousse à sauter parce que « ça marche déjà ».
Alors, le vibe coding ne sert à rien ? Au contraire
Ça sert, et beaucoup, si tu le mets au bon endroit. Comme outil de prototypage, c’est l’un des meilleurs arrivés depuis des années : il valide une idée en une après-midi au lieu de deux semaines, te laisse montrer quelque chose de tangible en réunion, et écarte ce qui n’a pas de sens avant de dépenser un euro à le construire bien. L’erreur n’est pas d’utiliser le vibe coding ; l’erreur est de confondre le prototype avec le produit et d’envoyer en production ce qui est né pour être jeté.
| Le vibe coding est génial pour | Et dangereux pour |
|---|---|
| Valider une idée avant d’investir | Stocker de vraies données clients |
| Prototypes internes et démos | Tout ce qui a des utilisateurs externes |
| Explorer le ressenti d’une fonction | Des processus dont dépend le métier |
| Apprendre et faire des essais rapides | Tout ce qui doit tenir un lundi matin |
La règle est simple : utilise le vibe coding pour décider quoi construire, pas pour le construire. Le prototype te dit si l’idée en vaut la peine ; à partir de là, ce qui tient en production se bâtit avec l’ennuyeux —le même métier qu’il faut pour automatiser un processus métier sans qu’il casse au premier coup ou pour mettre un agent IA vraiment au travail dans une entreprise. Ce travail n’est pas plus lent par caprice : c’est ce qui sépare une démo applaudie d’un système encore debout le mardi.
Que faire d’un prototype qui marche
Si tu as généré quelque chose « aux vibes » et que ça résout vraiment une douleur, la bonne nouvelle c’est que tu as déjà le plus dur : la certitude que l’idée vaut. Ce qui vient après n’est pas de le réécrire par plaisir, c’est de lui donner ce qui lui manque pour vivre hors de ton écran —filet de tests, monitoring, sécurité, déploiement avec jugement et quelqu’un qui répond. C’est la partie qu’on traite comme ce qu’elle est, de l’infrastructure, dans l’infrastructure d’IA pour l’entreprise : prendre ce que valide le prototype et le laisser tourner sans dépendre de ce que quelqu’un le surveille.
Alors oui au vibe coding —pour prototyper, pour valider, pour écarter vite. Et non au vibe coding en production, non parce que l’IA écrit mal, mais parce que la production, c’est les 70 % que l’IA ne génère pas avec le prompt : les tests, l’observabilité, la sécurité et le responsable. L’IA ne se présente pas dans une démo avec des données bidon. Elle s’implémente sur du réel, et le réel exige l’ennuyeux. C’est ça, le travail, et c’est justement la partie qu’on ne voit pas.