Vibe coding en entreprise : la liberté de créer,le devoir de prouver
Avec le vibe coding, tout le monde sait fabriquer une application. Plus personne ne sait laquelle croire.
En bref
Le vibe coding consiste à décrire un besoin en langage naturel pour qu’une IA écrive le code. Personne ne relit ce code. C’est un excellent moyen de prototyper, pas de produire. En entreprise, un prototype devient un produit fiable sous trois conditions. Les indicateurs sont définis en commun. La donnée est une donnée de référence. Un responsable répond quand l’outil tombe en panne.
-
On prototype beaucoup plus vite, même sans notion technique. Mais un prototype n’est pas un produit, et beaucoup pensent le contraire.
-
Le vrai risque : ne pas savoir ce qui sépare le prototype du produit final, ni réparer l’outil quand il tombe en panne.
-
Tous les prototypes ne méritent pas la production. Il faut choisir.
-
Et demain, quand l’IA décidera de plus en plus pour nous, une question deviendra centrale : comment prouver ce qui est vrai ?
Lundi, 9 h. Le directeur commercial pose son téléphone sur la table du comité. Dessus, une application de suivi des ventes par boutique, avec ses filtres, ses graphiques, son petit logo.
Il l’a faite dimanche. En deux heures. En parlant à une IA.
Puis il se tourne vers le CDO : « Votre projet de reporting, c’était combien de mois, déjà ? »
Personne ne répond. La vraie réponse est trop longue pour un comité.
Cette réponse, la voici.
Pourquoi un prototype vibe codé n’est pas un produit
Ce que le directeur commercial a fait porte un nom : le vibe coding. On décrit ce qu’on veut, en français. L’IA écrit le code. On corrige en parlant, sans jamais toucher une ligne.
Et ça marche. C’est justement ça, le problème.
En un après-midi, quelqu’un qui n’a jamais codé obtient un outil qui tourne. Ce qui n’est pas tombé, c’est tout ce qui vient après : brancher la vraie donnée, décider qui voit quoi, tenir quand deux cents personnes l’ouvrent le même matin, survivre au départ de son créateur. Le dimanche montre la façade. Le chantier, lui, est derrière.
Le vibe coding commence au moment où plus personne ne relit le code. Il devient un risque d’entreprise au moment où plus personne ne saurait le relire.
Un développeur qui ne relit pas fait un pari : si ça casse, il saura ouvrir le capot et comprendre ce qu’il y a dessous (les données utilisées, les droits d’accès, les dépendances à d’autres outils, les cas limites). Une contrôleuse de gestion qui génère une application ne fait pas de pari. Elle voit le capot, mais ne sait pas ce qu’il y a dessous.
La ligne rouge n’est pas entre l’IA et l’humain. Elle est entre ne pas relire et ne pas savoir relire.
Reste à savoir qui se trouve aujourd’hui de chaque côté de cette ligne. Indice : vous déjeunez probablement avec certains d’entre eux.
Qui fait du vibe coding en entreprise ?
Ce sont surtout des profils métier déjà à l’aise avec la technique et la data, plus que des développeurs. Quatre profils se distinguent selon qu’ils relisent le code, et qu’ils sauraient le relire.
| Niveau | Qui | Relit le code ? | Saurait le relire ? |
| Assisté | Un développeur, avec l’IA en autocomplétion | Oui, tout | Oui |
| Délégué | Un développeur qui confie des tâches à un agent IA | Les modifications | Oui |
| Vibe expert | Un profil technique pressé | Non | Oui |
| Vibe métier | Un profil non technique | Non | Non |
Les quatre niveaux d’usage de l’IA pour coder, selon la relecture du code.
On lit partout que « tout le monde » s’y met. Le chiffre le plus repris vient des plateformes elles-mêmes : environ 60 % d’utilisateurs non développeurs chez Lovable, 63 % chez Taskade (synthèse 13labs, 2026). C’est un peu comme demander à une salle de sport si les gens font du sport.
Côté développeurs, 72 % déclarent que le vibe coding ne fait pas partie de leur travail professionnel, alors que presque tous utilisent l’IA d’une manière ou d’une autre (Stack Overflow Developer Survey 2025). Côté métiers, personne ne sait vraiment.
Mais ceux qui s’y mettent vraiment, on les connaît déjà. Le fichier Excel de quarante onglets avec des macros que personne n’ose ouvrir, la base Access « temporaire » en service depuis 2009 : c’était déjà eux. Ils bricolaient déjà. Ils bricolent maintenant beaucoup plus vite. Ajoutez les agences, les consultants qui prototypent pour convaincre (oui, nous aussi), et notre directeur commercial du dimanche.
Si ces visages vous semblent familiers, c’est normal : ils ont déjà joué cette pièce. Et on connaît la fin.
Des macros Excel au Vibe coding : le même cycle
Le vibe coding rejoue le cycle de chaque outil en libre-service : autonomie, prolifération, puis crise de gouvernance.
| Macros Excel
Années 1990-2000 Le tableur programmé |
Base Access
Années 2000 La base temporaire |
Self-service BI
Années 2010 Chacun son rapport |
Vibe coding
2025 On parle, ça code |
Vibe coding et outils en libre-service : quatre outils, un même cycle (autonomie, prolifération, crise de gouvernance, puis l’outil suivant arrive).
Le self-service BI est l’épisode le plus récent. On a promis l’autonomie aux métiers. On a obtenu des milliers de rapports, dont beaucoup ne sont plus ouverts par personne, et des réunions où l’on débat du chiffre au lieu de débattre de la décision. Le vibe coding, c’est le même film avec un turbo : il n’y a même plus d’outil à apprendre. On parle, l’IA fait.
Prenez le taux d’écoulement de la collection printemps. Trois directions, trois applications, trois chiffres. Personne n’a menti. Chacun a demandé à l’IA de « calculer le taux d’écoulement », et l’IA a choisi une définition : sur le stock initial ou reçu, avec ou sans les retours, en pièces ou en valeur. Le calcul était juste. Le sens manquait : personne ne le lui avait donné, ou chacun lui avait donné le sien.
Ce film a pourtant connu des fins heureuses. Excel et le self-service BI ont très bien marché là où il existait une définition partagée des indicateurs, une donnée de référence et quelqu’un à appeler en cas de panne. La gouvernance n’est pas le frein de l’autonomie. C’est ce qui lui permet de durer.
Alors, faut-il jeter l’application du dimanche ? Non. Le directeur commercial a fait quelque chose de très utile ce jour-là.
Juste pas ce qu’il croit.
Pourquoi un prototype vibe codé reste utile : la toile
Un prototype vibe codé est un excellent outil d’essayage. Il révèle le besoin, mais il ne doit pas être mis en production tel quel.
En haute couture, avant de couper dans le tissu définitif, l’atelier monte le vêtement en toile de coton écru. On l’essaie sur la cliente, on épingle, on reprend une épaule. Puis on la met de côté. Personne n’a jamais vendu une toile.
L’application du dimanche est une toile, autrement dit un prototype. Et c’est une excellente toile. Un métier ne sait pas écrire un cahier des charges, personne ne sait vraiment. Mais tout le monde sait dire « non, pas comme ça » devant quelque chose qui tourne.
Le vibe coding est le meilleur outil d’essayage jamais inventé. Et le pire outil de production.
Le vrai livrable du dimanche, c’est donc le besoin que l’application a fait apparaître : les trois indicateurs que le directeur regarde vraiment, le filtre ajouté en premier, celui qu’il n’a jamais touché. On garde le besoin. On jette le code. Faire des toiles est sain. L’erreur commence quand on les met en boutique.
Le code devient jetable. Ce qui reste, c’est la description précise du besoin, et celui qui la possède, possède le produit. Quand créer devient gratuit, choisir devient le métier : décider quelles toiles méritent de devenir des pièces.
Encore faut-il avoir le temps de trier. Car pendant ce temps, l’atelier continue de produire, en masse. Et certaines toiles sont déjà en boutique.
Comment encadrer le vibe coding : durée de vie et criticité des données
Pour encadrer le vibe coding sans l’interdire, on authentifie les outils plutôt que de les bannir, et on module le contrôle selon la durée de vie de l’outil et la criticité de la donnée.
Le réflexe serait de fermer l’atelier : interdire le vibe coding à ceux qui se trouvent du mauvais côté de la ligne rouge. Ça ne marchera pas. On n’a jamais réussi à interdire Excel.
Le luxe connaît bien ce problème. Il s’appelle la contrefaçon : un objet qui ressemble à l’original sans en avoir la qualité. Et les maisons y répondent moins par l’interdiction que par l’authentification : le certificat, le numéro de série, la puce cousue dans la doublure.
Transposé à la data : chacun fabrique ce qu’il veut, mais seul ce qui s’appuie sur la donnée certifiée porte le label de la maison. Le contrôle quitte l’atelier pour se porter sur la signature. Authentifier, au fond, c’est prouver.
Reste à savoir quoi laisser libre et quoi encadrer. Deux questions suffisent : combien de temps l’outil va-t-il vivre, et quelle donnée touche-t-il ?
Matrice : durée de vie de l’outil × criticité de la donnée.
Un outil jetable sur une donnée sans enjeu est un terrain de jeu : liberté totale. Un outil jetable sur une donnée sensible est une toile : on essaie sous surveillance, avec une date de péremption de 90 jours. Un outil durable sur une donnée sans enjeu devient une pièce, avec un passage léger en production. Un outil durable sur une donnée sensible ne se vibe code pas seul : il passe par l’équipe data.
Un passage léger en production, c’est un propriétaire nommé, une relecture du code par quelqu’un qui sait le lire, un branchement sur la donnée certifiée et un suivi de l’usage. Pas un projet de six mois : une check-list.
Ces règles valent pour les deux ou trois années qui viennent, tant qu’on fabrique encore des applications et des dashboards. Car très vite, l’application elle-même pourrait disparaître.
Du dashboard à l’agent : qui dira ce qui est vrai ?
À terme, l’interface disparaît : on pose une question, l’IA répond, puis elle finit par décider.
Pourquoi le directeur commercial a-t-il passé son dimanche à coder ? Pour décider. C’est la seule raison d’être de la data. Le dashboard, l’application, le reporting ne sont que des moyens, et leur interface ne cesse de rétrécir : hier, on construisait le dashboard, aujourd’hui, on demande à l’IA de le faire, demain, on posera simplement la question.
Un dashboard, c’est une carte routière : toutes les routes sont dessus, à vous de trouver la bonne. Parler à ses données, c’est utiliser un GPS. Il croise la circulation, les accidents, un arrêté municipal que vous n’auriez jamais lu, et recommande un itinéraire. Mais il faut encore lui donner l’adresse.
Demain, on lui dira : « Je veux la mer, et y être dans deux heures. » Il choisira la plage, la route et l’heure de départ. Transposez : « Je veux écouler la collection avant fin mars, sans démarque qui abîme la marque. » L’agent proposera la destination et le chemin. Pour l’instant, il propose et nous choisissons. Mais à force de lui confier nos envies plutôt que nos adresses, il finira par choisir à notre place.
Le jour où le GPS choisit la destination, ce n’est plus un outil. C’est un décideur.
Ce jour-là, savoir coder ne servira plus à grand-chose. Une autre question deviendra centrale : qui a le droit de dire ce qui est vrai ? Et surtout, comment le prouver ?
Vibe coding en entreprise : ce qu’il faut retenir
Un outil vibe codé est d’abord un prototype. Il devient un produit fiable sous trois conditions : des indicateurs définis en commun, une donnée de référence et un responsable qui répond quand l’outil tombe en panne.
Les points clés
-
Le vibe coding crée un prototype en quelques heures, mais pas la mise en production ni l’exploitation.
-
La ligne rouge sépare ne pas relire le code et ne pas savoir le relire.
-
Les profils métier qui s’y mettent bricolaient déjà sous Excel ou Access. Le même cycle se répète.
-
Sans définition partagée, l’IA choisit la sienne : trois applications donnent trois taux d’écoulement.
-
Le coût d’un outil est dans sa vie, pas dans son écriture : maintenance, sécurité, support.
Le vibe coding réduit fortement le coût du prototype. Il ne réduit pas celui de la gouvernance, qui transforme un prototype en produit.
Etablissez votre roadmap Data & IA en 15 minutes
Faites notre diagnostique et repartez avec une vision claire sur vos projets Data
FAQ : vibe coding en entreprise
Créer un outil en décrivant son besoin à une IA, qui écrit le code. Il devient un risque pour l’entreprise quand plus personne ne saurait relire ce code.
À prototyper très vite, et surtout à révéler un besoin : devant un outil qui tourne, un métier sait dire ce qu’il veut. On garde le besoin, on jette le prototype.
Presque rien à créer, autant qu’un autre outil à faire vivre : maintenance, sécurité, support. Mais ce coût arrive plus tard, sans être rattaché à aucun projet.
Des chiffres contradictoires d’un outil à l’autre, des droits d’accès mal définis, une maintenance sans responsable et une dépendance à celui qui a créé l’outil.
Oui, après un passage léger : un propriétaire, une relecture du code, la donnée certifiée, un suivi de l’usage. Si elle touche une donnée sensible et doit durer, elle passe par l’équipe data.
Non, ça ne fonctionne pas. Mieux vaut authentifier : laisser créer, mais signaler clairement quels outils s’appuient sur la donnée certifiée.
Ils ont optimisé leur performance avec MeltOne
