Vibe coding

Comment ça marche

Le vibe coding, c’est décrire une application en langage courant et laisser l’IA la construire, écran par écran, sans regarder le code. « Je veux un outil où mes commerciaux saisissent leurs visites, avec un tableau de bord par région. » Quelques minutes plus tard, l’outil existe, on l’essaie, on demande des changements, et on recommence jusqu’à ce que ça ressemble à ce qu’on voulait.

Le terme vient de 2025, quand les outils sont devenus assez bons pour que cette façon de faire produise quelque chose d’utilisable. Elle marche parce que les modèles connaissent les façons classiques de construire une application et les reproduisent vite. Elle atteint ses limites dès que l’application doit être sûre, juste dans tous les cas, et vivre plusieurs années.

Un exemple concret

1. Vendredi, une heure. La responsable commerciale décrit l’outil à un service de vibe coding. Elle obtient un formulaire de saisie, une liste des visites et un tableau de bord. Elle le montre à l’équipe : tout le monde voit enfin la même chose.
2. Ce qui manque, repéré lundi. Deux commerciaux ont saisi la même visite ; un montant négatif est passé ; la suppression efface sans confirmation ; l’outil est accessible sans mot de passe par son lien.
3. Consolidation, trois jours avec un agent de code. Les règles sont écrites (une visite = un client, une date, un commercial ; montant positif ; suppression réservée au responsable), les tests ajoutés, l’authentification mise en place, le code rangé dans Git, l’hébergement choisi.
4. Résultat : le prototype a servi à se mettre d’accord. L’outil final partage son apparence et presque rien de son code.

Sans le prototype, l’équipe aurait passé trois réunions à décrire l’outil. Sans la consolidation, elle aurait perdu des données au premier incident.

Ce que ça change pour une équipe

• Les idées se testent au lieu de se discuter. Une maquette fonctionnelle en une heure vaut mieux qu’un cahier des charges de dix pages pour savoir ce qu’on veut.
• Les métiers construisent leurs premiers outils. Un responsable qui connaît son besoin peut obtenir un outil personnel sans attendre l’informatique.
• La frontière avec le vrai développement devient claire. Prototype d’un côté, outil de production de l’autre, avec une étape de consolidation entre les deux, dont on sait ce qu’elle coûte.
• Le rôle du développeur change. Moins d’écriture de code, plus de spécification, de revue et de sécurité.

Les limites et les erreurs fréquentes

• Mettre le prototype en production. C’est l’erreur classique : ça marche en démo, donc on l’ouvre à tout le monde. Les données, la sécurité et les cas limites n’ont jamais été traités.
• Ne pas pouvoir expliquer ce que fait l’outil. Si personne ne comprend le code, personne ne peut le corriger. Un outil utilisé a besoin d’un responsable qui le comprend, au moins dans les grandes lignes.
• Oublier les données. Où sont-elles stockées ? Par qui ? Sauvegardées ? Un service de vibe coding héberge souvent la base chez lui, à des conditions qu’on n’a pas lues.
• Accumuler des outils orphelins. Dix prototypes, zéro maintenu. Un inventaire et une règle simple : tout outil utilisé par plus d’une personne a un propriétaire.