Vibe coding

Ce que le terme recouvre

L'expression désigne une manière de programmer qui déplace l'effort : au lieu de composer chaque ligne, on formule une intention, on obtient une proposition de code, on l'exécute, on constate le résultat et on corrige la consigne. La boucle est courte, et le développement ressemble davantage à une conversation avec une machine qu'à une séance d'écriture. Le vocabulaire employé, fait de descriptions et de retours, n'est plus celui d'un langage de programmation. On décrit un comportement, on juge un résultat, et la syntaxe devient un détail.

Le terme est souvent employé de façon péjorative, pour désigner du code produit sans relecture. Dans les faits, il couvre un spectre large : d'un prototype jetable écrit en une heure à une application maintenue, où le modèle sert d'accélérateur mais où la relecture reste centrale. La différence entre les deux cas tient moins à l'outil qu'à la discipline de celui qui l'utilise et au niveau d'exigence qu'il s'impose. Un même outil produit ainsi du prototype jetable et du code maintenu, selon la personne qui tient le clavier.

Où cela fonctionne

Sur un prototype, une page de démonstration, un script d'extraction ou un tableau de bord interne, l'approche est efficace. Le coût d'erreur est faible, le code peut être jeté, et l'objectif est de vérifier une idée rapidement. Un artisan qui veut tester un formulaire de devis, une association qui veut un annuaire de ses membres, y trouvent un moyen d'aller vite sans mobiliser un prestataire pour une première version. Le critère n'est pas la technicité du projet, mais le coût d'une erreur non détectée.

L'approche convient aux projets bien cadrés, où l'on sait décrire le résultat attendu et où les technologies sont courantes. Elle devient plus délicate sur les systèmes qui touchent à l'argent, à la santé, aux données personnelles ou à l'accès à un bâtiment. Là, le code doit être relu, testé et documenté par quelqu'un qui en répond, quelle que soit la manière dont il a été produit au départ. Un formulaire qui perd un message ou une facture mal calculée coûte plus cher que le temps gagné.

Le risque principal

Le modèle produit du code plausible, pas du code vérifié. Il peut invoquer une fonction qui n'existe pas dans la bibliothèque installée, ignorer un cas limite, ou reprendre un motif obsolète trouvé dans ses données. Sans exécution ni test, ces défauts restent invisibles jusqu'au jour où ils cassent quelque chose en production. La vitesse de production augmente, et avec elle la quantité de code que personne n'a réellement examinée. Le modèle ne connaît ni votre infrastructure, ni vos conventions de nommage, ni vos contraintes de sécurité.

Le garde-fou tient en trois gestes : exécuter, tester, relire. Exécuter chaque version produite dans un environnement réel, écrire quelques tests sur les cas qui comptent, et faire relire par une personne compétente avant toute mise en production. Un développement assisté sans ces trois étapes n'est pas du développement plus rapide : c'est une dette technique contractée à crédit, dont l'échéance arrive sans prévenir, souvent un jour de forte activité. Ces trois gestes prennent du temps, et c'est ce temps qui distingue un gain réel d'une illusion de vitesse.