Vibe coding : ce que ça permet vraiment

Le vibe coding consiste à décrire en langage naturel ce qu'un programme doit faire, et à laisser un modèle écrire le code. Vous jugez le résultat à l'usage plutôt qu'à la lecture. C'est devenu une manière crédible de fabriquer des outils, à condition de savoir exactement où elle s'arrête.

J'ai livré de vrais outils comme ça, et j'en ai jeté d'autres après trois semaines. Voici ce que cette pratique permet réellement, où elle casse, et comment s'y mettre sans se raconter d'histoires.

Avant de vous lancer, évaluez votre projet. Quatre questions suffisent à savoir si vous êtes sur le bon terrain.

Qu'est-ce que le vibe coding ?

C'est une manière de programmer où l'on décrit l'intention plutôt que l'implémentation. Vous ne tapez pas de boucles ni de conditions : vous dites « je veux un outil qui prend un fichier de commandes, repère les doublons et me sort un tableau propre », et un modèle produit le programme correspondant.

La différence avec l'autocomplétion assistée n'est pas de degré, elle est de nature. Dans un éditeur classique augmenté, vous écrivez du code et la machine complète vos phrases. Ici, vous ne lisez plus forcément le code produit : vous exécutez, vous constatez le résultat, et vous corrigez en reformulant. Le programme redevient une boîte noire que l'on juge par son comportement.

Le terme vient du monde du développement, où il désigne, non sans ironie, ce moment où l'on code « à l'ambiance » : on avance à la description et à l'essai, sans passer par la compréhension ligne à ligne. Ce qui était une plaisanterie de développeur est devenu une pratique de travail parce que la qualité du code généré a franchi un seuil.

Ce que ce n'est pas

Trois confusions reviennent en permanence, et les lever évite beaucoup de déceptions.

Ce n'est pas du no-code. Une plateforme sans code vous enferme dans un catalogue de briques préexistantes : vous assemblez ce que l'éditeur a prévu. Ici, il n'y a pas de catalogue, il y a un vrai programme, dans un vrai langage, que vous pouvez héberger où vous voulez. La liberté est totale, la responsabilité aussi.

Ce n'est pas la fin de la programmation. Le code existe toujours, il tourne toujours sur un serveur, il peut toujours planter à trois heures du matin. Ce qui change, c'est qui l'écrit, pas s'il existe.

Ce n'est pas magique. Un modèle produit un programme qui correspond à ce que vous avez dit, pas à ce que vous vouliez dire. L'écart entre les deux est exactement le même que celui qui a toujours séparé un cahier des charges d'un logiciel réussi. Il n'a pas disparu, il s'est déplacé.

Comment fonctionne le vibe coding ?

La boucle tient en quatre temps, et elle se répète des dizaines de fois par séance.

Vous décrivez. En français ou en anglais, ce que le programme doit faire, avec quelles entrées et quelles sorties. Plus la description est précise sur le résultat attendu, moins vous ferez d'allers-retours.

Le modèle produit. Il écrit les fichiers, installe les dépendances nécessaires, et souvent lance lui-même le programme pour vérifier qu'il démarre.

Vous testez. Pas en lisant le code, en l'utilisant. Vous donnez un vrai fichier, vous cliquez sur les vrais boutons, vous regardez si le résultat est celui que vous attendiez.

Vous corrigez en décrivant. « Le tableau ne trie pas dans le bon ordre », « il plante quand le fichier est vide », « ajoute une colonne avec la date ». Le modèle relit son propre code et corrige.

Ce cycle est le cœur de la pratique, et c'est aussi là que se joue la réussite ou l'échec. Un utilisateur qui teste sérieusement, avec de vrais cas et de vraies données bancales, obtient un outil solide. Un utilisateur qui teste le cas idéal obtient un outil qui casse au premier fichier mal formé.

Pourquoi ça fonctionne seulement maintenant

Trois évolutions se sont rejointes. Les modèles écrivent du code nettement plus juste qu'il y a deux ans. Ils tiennent des contextes beaucoup plus longs, donc gardent en tête un projet entier plutôt qu'un fichier isolé. Et surtout, ils sont devenus des agents : ils exécutent les commandes, lisent les messages d'erreur et corrigent seuls, au lieu de se contenter de proposer du texte.

Cette troisième évolution est la vraie bascule. Un modèle qui voit son erreur et la répare change la nature du travail : vous n'êtes plus l'intermédiaire qui copie des messages d'erreur, vous êtes le commanditaire qui juge le résultat.

Quels outils de vibe coding utiliser ?

Trois familles, et le choix dépend surtout de votre point de départ.

Les agents en terminal

Ce sont les plus puissants. Ils travaillent directement dans un dossier de votre machine, créent et modifient les fichiers, lancent les commandes, lisent les erreurs. Claude Code appartient à cette catégorie, et c'est celui que j'utilise.

Leur force est l'autonomie : on peut leur confier une tâche longue et les laisser dérouler. Leur défaut est l'entrée en matière, qui suppose d'être à l'aise avec un terminal. Pour quelqu'un qui n'a jamais ouvert de ligne de commande, ce n'est pas la première marche.

Les éditeurs augmentés

Un éditeur de code classique dans lequel un assistant est intégré profondément : il voit tout le projet, propose des modifications sur plusieurs fichiers et applique les changements après validation.

C'est le bon compromis pour qui veut garder un œil sur ce qui se passe. On voit les fichiers, on voit les différences avant de les accepter, et on peut intervenir à la main quand c'est plus rapide. C'est la porte d'entrée que je conseille à quelqu'un qui a déjà des notions.

Les plateformes tout-en-un

Vous décrivez une application dans un navigateur, elle est générée, hébergée et mise en ligne sans que vous voyiez jamais un fichier. C'est la voie la plus accessible pour un débutant complet, et la plus rapide pour montrer une idée à quelqu'un.

Le prix à payer est la dépendance : votre application vit chez un prestataire, avec ses limites et ses tarifs. Pour un prototype ou un outil interne, c'est parfaitement acceptable. Pour un produit que vous comptez faire vivre des années, la question de la portabilité doit être posée dès le premier jour.

Comment choisir

Une règle simple : partez du plus accessible et montez quand vous butez. Si vous n'avez jamais programmé, commencez par une plateforme, livrez quelque chose, prenez confiance. Si vous connaissez un peu, prenez un éditeur augmenté. Si vous êtes déjà technique, l'agent en terminal vous donnera un plafond bien plus haut.

Ne cherchez pas l'outil parfait, ils progressent tous vite et se ressemblent de plus en plus. Ce qui fait la différence dans le résultat, c'est la façon de commander, pas la marque.

Quels sont les avantages du vibe coding ?

Quatre gains, dont un seul est vraiment évident.

La vitesse. L'évident. Un outil interne qui aurait demandé une semaine se livre en une soirée. Sur du petit périmètre, le facteur est réel et se compte en dizaines.

L'accessibilité. Des gens qui ne programmeront jamais peuvent fabriquer l'outil dont ils ont besoin. C'est le changement le plus profond, et il touche des métiers entiers : marketing, comptabilité, logistique, tous ceux qui bricolaient dans un tableur des choses qui méritaient un vrai programme.

Le prototype comme langage commun. Montrer une maquette qui fonctionne remplace vingt pages de spécifications que personne ne lit de la même façon. Sur un projet à plusieurs, c'est un accélérateur de décision plus qu'un gain de développement.

Le droit d'essayer. Le plus sous-estimé. Quand un essai coûte deux heures au lieu de deux semaines, on tente des choses qu'on n'aurait jamais budgétées. La plupart ne donnent rien, une sur dix change une façon de travailler. Cette économie de l'essai est ce qui a le plus changé ma manière de travailler.

Où cette pratique casse

Voici la partie que les articles enthousiastes passent sous silence, et c'est pourtant celle qui décide de vos ennuis futurs.

La dette invisible

Un code que vous ne lisez pas est un code dont vous ignorez la qualité. Tant que le programme fonctionne, l'illusion tient. Le jour où il faut modifier un comportement, ajouter un cas particulier ou comprendre pourquoi un chiffre est faux, l'ignorance se paie d'un coup.

J'ai vu ce moment plusieurs fois, et il ressemble toujours au même scénario : un outil qui a très bien marché pendant deux mois devient impossible à faire évoluer, parce que personne, ni vous ni le modèle, ne sait plus quelle partie fait quoi.

Le mur des deux mille lignes

Il existe un seuil, empirique et remarquablement constant, autour d'un à deux milliers de lignes. En dessous, le modèle garde une vue d'ensemble et ses corrections sont chirurgicales. Au-dessus, il commence à réparer un endroit en cassant un autre, parce qu'il ne tient plus la totalité de la logique en tête.

Ce mur ne s'annonce pas. Il se manifeste par un symptôme précis : vous corrigez un problème, un autre apparaît ailleurs, vous corrigez celui-là, le premier revient. Si vous tournez trois fois dans cette boucle, ce n'est pas un mauvais jour, c'est le signal qu'il faut découper le projet en morceaux plus petits ou faire relire par un humain.

La sécurité

C'est le point qui devrait retenir le plus d'attention et qui en retient le moins. Un modèle produit du code qui fonctionne, pas nécessairement du code sûr. Les fautes classiques, données non validées, secrets écrits en clair, absence de contrôle sur qui a le droit de faire quoi, ne se voient pas à l'usage : l'application marche parfaitement jusqu'au jour où quelqu'un s'y intéresse.

La règle que j'applique sans exception : dès qu'un outil est accessible depuis internet ou qu'il manipule des données personnelles, il passe sous les yeux de quelqu'un qui sait lire du code. Ce n'est pas de la prudence excessive, c'est le minimum. L'outil d'évaluation en haut de page vous dit à partir de quand cette relecture devient obligatoire.

Le piège du presque fini

Le dernier écueil est psychologique. Ces outils amènent très vite à quatre-vingts pour cent du résultat, ce qui donne le sentiment d'avoir presque terminé. Les vingt pour cent restants, les cas limites, la gestion des erreurs, les comportements bizarres, prennent en réalité autant de temps que le reste, voire davantage.

Ce n'est pas propre à cette pratique, c'est la loi du développement logiciel depuis toujours. Mais la vitesse du début rend la déception plus brutale, et beaucoup de projets s'arrêtent exactement là.

Vibe coding pour débutants : comment commencer

Voici le chemin que je conseille à quelqu'un qui n'a jamais écrit une ligne de code.

Choisir le bon premier projet

Le meilleur projet de départ a quatre caractéristiques : il vous sert personnellement, il n'est utilisé que par vous, il ne touche aucune donnée sensible, et vous pouvez le jeter sans conséquence. Un convertisseur de fichier, un tableau de bord personnel, un outil qui range vos photos, un calculateur métier.

Le pire projet de départ est celui qui a des utilisateurs, des enjeux d'argent ou des données de clients. Ce n'est pas une question de difficulté technique, c'est une question de coût de l'erreur pendant que vous apprenez.

Les cinq règles qui changent tout

• Décrivez le résultat, pas la méthode. Dites ce que le programme doit produire, pas comment vous imaginez qu'il devrait s'y prendre. Vous vous tromperez plus souvent que lui sur le comment.
• Une demande à la fois. Cinq changements demandés ensemble donnent cinq changements approximatifs. Un seul donne un résultat net que vous pouvez valider.
• Testez avec des données réelles et sales. Le fichier avec des accents, la ligne vide, la date au mauvais format. C'est là que se cachent les défauts.
• Demandez des tests automatisés dès le début. Ce sont des petits programmes qui vérifient que le programme principal fait ce qu'il doit. C'est le seul filet qui permette de reprendre un projet trois mois après.
• Gardez l'historique. Utilisez un outil de versions, ne serait-ce que pour pouvoir revenir en arrière quand une modification casse tout. Le modèle peut vous le mettre en place en deux minutes.

Les premiers jours, concrètement

Prenez un vrai besoin, pas un exercice. Décrivez-le en trois phrases à l'outil de votre choix, laissez-le produire une première version, et utilisez-la immédiatement. Notez ce qui ne va pas, demandez une correction à la fois, recommencez.

En une soirée, vous aurez quelque chose qui marche. En une semaine, vous aurez compris que la difficulté n'est pas de faire produire du code, mais de savoir dire ce que vous voulez. Cette découverte est le vrai contenu de l'apprentissage.

Un exemple complet, du besoin à l'outil

Le plus parlant reste un cas réel. Voici, résumé, comment s'est déroulé un outil que j'utilise encore.

Le besoin. Je recevais chaque mois des exports de positions de plusieurs clients, dans des formats différents, et je passais une heure à les uniformiser avant de pouvoir les comparer. Un travail sans aucune valeur ajoutée, répété douze fois par an.

La première consigne. Trois phrases, pas plus : un programme qui lit tous les fichiers d'un dossier, quel que soit leur format de colonnes, les ramène à un tableau unique avec date, mot-clé, position et domaine, et écrit le résultat dans un seul fichier. La première version est arrivée en quatre minutes et fonctionnait sur deux fichiers sur trois.

Les corrections. Le troisième fichier utilisait un point-virgule comme séparateur et des dates au format américain. Deux demandes, deux corrections, dix minutes. Puis un cas que je n'avais pas prévu : certaines lignes n'avaient pas de position, parce que le mot-clé était sorti du classement. J'ai demandé qu'elles soient conservées avec une valeur vide plutôt que supprimées, parce que la disparition d'un mot-clé est précisément l'information intéressante.

Le filet. J'ai demandé des tests automatisés couvrant les trois formats et le cas de la ligne vide. Cinq minutes de plus. Ce sont eux qui m'ont permis, quatre mois plus tard, d'ajouter un quatrième format sans rien casser.

Le bilan. Une heure de travail au total, une heure économisée chaque mois depuis. Et surtout : je n'aurais jamais écrit ce programme à la main, parce que le calcul de rentabilité ne l'aurait jamais justifié. C'est exactement ce que je voulais dire par l'économie de l'essai.

Notez ce qui a fait la réussite de ce cas : un périmètre minuscule, aucune donnée sensible, un seul utilisateur, et des tests demandés avant que le projet ne grossisse. Les quatre critères de l'outil d'évaluation, réunis.

Ce que ça coûte

La question arrive toujours, et la réponse dépend de l'outil choisi.

Les agents en terminal et les éditeurs augmentés fonctionnent avec un abonnement mensuel, de l'ordre de quelques dizaines d'euros, ou avec une facturation à l'usage. Pour un usage individuel régulier, l'abonnement est presque toujours plus avantageux, et il rend la dépense prévisible, ce qui compte quand on débute et qu'on ne sait pas doser.

Les plateformes tout-en-un facturent souvent à la fois la génération et l'hébergement. C'est confortable au début et cela devient le poste à surveiller si l'application prend de l'ampleur, d'autant que la migration ailleurs n'est pas toujours simple.

Le vrai coût est ailleurs, et il est en temps. Une séance productive de deux heures produit un outil ; une séance mal engagée produit trois heures de corrections en boucle et un projet abandonné. La différence tient presque toujours à la clarté de la description initiale, ce qui est une bonne nouvelle : c'est le seul paramètre que vous contrôlez entièrement.

Comment apprendre le vibe coding

Il n'y a pas grand-chose à apprendre au sens scolaire, et beaucoup à pratiquer. La compétence ne porte pas sur une syntaxe, elle porte sur trois choses.

Savoir spécifier. Décomposer un besoin flou en comportements précis, envisager les cas limites avant qu'ils ne surviennent, dire ce que le programme doit faire quand les choses se passent mal. C'est le métier d'analyste, et il n'a jamais été aussi utile.

Savoir juger. Reconnaître un résultat faux, un comportement suspect, une réponse trop belle. Cela s'acquiert en testant beaucoup, sur ses propres données, avec l'obsession du cas tordu.

Comprendre les concepts, pas la syntaxe. Vous n'avez pas besoin de savoir écrire une boucle. Vous avez besoin de savoir ce qu'est une base de données, pourquoi on ne stocke pas un mot de passe en clair, ce qu'est une clé d'API et pourquoi elle ne se met pas dans une page web. Une dizaine de notions de ce type couvre l'essentiel des erreurs graves.

La meilleure formation reste donc un projet réel dont le résultat vous importe. Les cours théoriques sur la manière de formuler des consignes vieillissent en quelques mois ; la capacité à spécifier et à juger ne vieillit pas.

Quels emplois et quelles carrières

La question qui inquiète, alors répondons franchement.

Le métier de développeur ne disparaît pas, il se déplace vers le haut. Écrire la première version d'un programme perd de la valeur ; concevoir une architecture qui tiendra, relire du code produit par une machine, garantir la sécurité et arbitrer les compromis en gagne. Le travail se déplace de la production vers la conception et le contrôle.

Deux profils voient leur situation s'améliorer nettement. Les développeurs expérimentés, dont le jugement devient le goulot d'étranglement et donc la ressource rare. Et les experts métier qui savent maintenant fabriquer leurs propres outils sans passer par une file d'attente informatique : un contrôleur de gestion qui produit son tableau de bord, un juriste qui automatise un tri de documents.

Le profil fragilisé est celui du développeur junior cantonné à des tâches simples et répétitives, exactement celles que ces outils font le mieux. Le conseil qui en découle est brutal mais utile : ne construisez pas votre valeur sur la production de code, construisez-la sur la compréhension des systèmes et sur la capacité à décider.

Un nouveau rôle apparaît, encore mal nommé, qui tient de l'analyste et du chef de produit technique : quelqu'un qui sait traduire un besoin métier en spécification exécutable, faire produire, et vérifier. Ce n'est pas un métier créé de toutes pièces, c'est un métier qui existait à la marge et qui passe au centre.

À qui appartient le code produit

La question revient dans toutes mes formations en entreprise, et elle mérite une réponse nette plutôt qu'un haussement d'épaules.

Le code généré vous revient, dans les conditions prévues par les conditions d'utilisation du service que vous employez. C'est le cas chez les principaux éditeurs, mais cela se vérifie avant de bâtir un produit dessus, pas après. Lisez la clause de propriété du service, une fois, et archivez-la.

Deux points appellent plus d'attention. Les dépendances d'abord : un modèle installe volontiers des bibliothèques tierces, qui viennent chacune avec leur licence. Certaines interdisent un usage commercial sans contrepartie. Demandez la liste des dépendances et de leurs licences, c'est une question à laquelle l'outil répond en quelques secondes. Vos données ensuite : si vous collez des extraits de fichiers clients dans une conversation, ces contenus quittent votre système. Pour un usage professionnel, cette question se règle au niveau de l'organisation et du contrat, pas au niveau de l'utilisateur.

Rien de tout cela n'est bloquant. Mais une entreprise qui découvre ces sujets après avoir mis un outil en production les découvre toujours au mauvais moment.

Ce que j'en fais concrètement

Je m'en sers tous les jours, et toujours dans le même périmètre : des outils internes, pour moi ou pour un client, qui ne manipulent pas de données sensibles et dont l'échec ne coûte qu'une matinée.

Des exemples réels : un script qui compare deux exports de crawl et me sort les URL qui ont changé de statut, un générateur de fichiers de redirections à partir d'un tableau, un petit tableau de bord qui agrège les positions de plusieurs clients, les outils interactifs que vous trouvez dans mes articles. Aucun de ces programmes n'existerait si j'avais dû les écrire à la main : ils n'auraient jamais valu le temps qu'ils auraient coûté.

Ce que je ne fais pas : le site d'un client, une application avec des comptes utilisateurs, tout ce qui touche à un paiement. Pas par principe, mais parce que je sais que je ne relirai pas le code assez sérieusement pour engager ma responsabilité dessus.

La ligne est là, et elle est simple à retenir : fabriquez tout ce dont l'échec ne coûte qu'à vous. Pour le reste, servez-vous de ces outils pour aller vite, mais faites relire par quelqu'un dont c'est le métier.

Écrit par

Anthony Courtin

Consultant SEO, GEO & automatisation IA

J'accompagne des PME et des indépendants sur la visibilité (Google, ChatGPT, Perplexity) et sur l'usage réel de l'IA au travail. J'interviens en entreprise pour former les équipes et repenser les process. Tout ce que j'écris ici, je l'utilise en mission.

Me suivre sur LinkedIn Ma chaîne YouTube