Vous avez déjà eu ce moment : vous codez, les idées coulent, tout semble fluide, et pourtant, quelque chose dans le fond vous dit que ça pourrait mal tourner. C’est ce qu’on appelle le vibe coding. Pas une méthode officielle, pas un framework, mais une façon de travailler où la créativité prend le pas sur la rigueur. Et ça marche… jusqu’au jour où ça plante.
Le vibe coding, c’est quand vous savez que votre code va fonctionner, même si vous ne l’avez pas testé. C’est quand vous skippez les revues de code parce que « ça sent bon ». C’est quand vous avez une intuition, pas une documentation. Et pourtant, dans les équipes qui réussissent, ce vibe n’est jamais laissé seul. Il est encadré. Par des humains. Pas par des bots. Pas par des règles automatiques. Par des gens qui regardent, posent des questions, et disent : « Attends, là, je sens que tu as oublié quelque chose. »
Qu’est-ce que le vibe coding vraiment ?
Le vibe coding n’est pas un mot inventé pour les réseaux sociaux. C’est une réalité dans les startups, les équipes de R&D, les laboratoires de prototypage rapide. Des développeurs expérimentés, souvent autodidactes, qui travaillent avec une intuition aiguisée. Ils n’ont pas besoin de 15 tests unitaires pour valider une fonction. Ils sentent quand ça va. Et souvent, ils ont raison.
Mais cette intuition a un prix. Elle ignore les cas limites. Elle oublie les scénarios de sécurité. Elle suppose que tout le monde utilise le même environnement. Et quand ça plante - et ça plante toujours - les dégâts sont plus gros parce que personne n’a posé la question : « Et si… ? »
Le rôle humain dans le vibe coding
Le human-in-the-loop (HITL), c’est la pratique où un humain intervient à des étapes clés du processus de développement. Pas pour contrôler, mais pour équilibrer. Dans le vibe coding, HITL n’est pas une contrainte. C’est un catalyseur.
Prenons un exemple réel : une équipe à Madison développe une API pour gérer les réservations de vélos en libre-service. Un développeur écrit le code en 45 minutes, le déploie, et dit : « Ça marche, j’ai testé avec trois scénarios. »
Un collègue, lui, regarde le code, pose une question : « Et si quelqu’un commande un vélo à 3h du matin avec une carte expirée ? »
Le premier développeur rigole. « Personne fait ça. »
Le second lance un test. Résultat : l’API plante. Pas parce que le code est mal écrit, mais parce qu’il n’a pas traité l’erreur de carte expirée. Pas un bug de syntaxe. Un bug de contexte. Un bug que seul un humain pouvait voir.
C’est ça, le HITL dans le vibe coding : pas de révision de code formelle. Pas de checklist. Juste une conversation. Une question. Un regard.
Trois pratiques qui changent tout
Vous ne pouvez pas forcer quelqu’un à arrêter de coder en vibe. Mais vous pouvez rendre cette pratique plus sûre. Voici trois approches simples, mais puissantes, que les meilleures équipes utilisent.
- Le check-in à deux : Avant de déployer, le développeur partage son code avec un collègue. Pas pour le corriger. Pour dire : « Qu’est-ce que tu sens ? » Si la personne répond « Ça sent le risque », on s’arrête. Pas parce que c’est technique. Parce que l’intuition collective est plus forte que l’intuition individuelle.
- Le test du « et si ? » : À chaque commit, on pose une question : « Qu’est-ce qui peut aller de travers ici ? » Pas une liste de cas. Une seule question, posée par quelqu’un d’autre. Souvent, la réponse est : « Et si l’utilisateur est en mode hors ligne ? » Ou : « Et si la base de données est en maintenance ? » Ces questions ne sont pas dans les specs. Elles viennent de l’expérience.
- Le rétro après une défaillance : Quand un bug passe en production, on ne cherche pas qui a fait l’erreur. On demande : « Qu’est-ce qu’on a oublié de vérifier ? » Et on écrit la réponse en une phrase : « On a oublié de tester l’authentification avec un token expiré. » Cette phrase devient une règle tacite. Elle ne s’écrit pas. Elle se raconte.
Pourquoi ça marche mieux que les processus rigides
Les grandes entreprises ont des processus. Des checklists. Des outils de qualité. Des audits. Et pourtant, ce sont souvent elles qui ont les pires bugs de sécurité.
Pourquoi ? Parce que la rigueur tue l’adaptabilité. Quand vous avez 20 étapes pour déployer une ligne de code, vous arrêtez de penser. Vous suivez. Vous cochez. Et vous ratez les choses qui ne sont pas dans la checklist.
Le vibe coding avec HITL, lui, garde la vitesse. Il garde la créativité. Mais il ajoute une couche de vigilance humaine. Pas mécanique. Pas algorithmique. Humaine.
Un développeur qui sent que quelque chose ne va pas… c’est plus fiable qu’un outil qui détecte 1000 faux positifs par jour.
Les pièges à éviter
Le HITL ne doit pas devenir une nouvelle forme de micro-management. Voici trois erreurs courantes :
- Transformer le check-in en revue de code formelle : Si vous exigez des commentaires sur chaque ligne, vous tuez le vibe. Le but n’est pas de tout documenter. C’est de capter les intuitions.
- Attendre que quelqu’un d’autre voie le problème : Si vous pensez que « l’autre va voir », vous ne faites pas de HITL. Vous faites de la négligence. Le HITL demande une participation active.
- Ne pas valoriser les « fausses alertes » : Quand quelqu’un dit « Je sens que ça va péter » et que ça ne péte pas… vous devez quand même remercier la personne. Parce que la prochaine fois, ça va péter. Et elle l’aura vu.
Comment commencer ?
Vous n’avez pas besoin d’outils coûteux. Pas de logiciel spécial. Juste trois choses :
- Un moment dans la journée où vous demandez à quelqu’un : « Tu veux jeter un œil à ce que je viens d’écrire ? »
- Un espace où on peut dire « Je ne suis pas sûr » sans être jugé.
- Un rituel simple : après chaque déploiement, on écrit sur un tableau blanc : « Ce que j’ai oublié de vérifier. »
Ça ne prend pas 10 minutes par jour. Mais ça évite des semaines de dépannage. Et surtout, ça transforme le vibe coding d’une pratique risquée en une force.
Le vrai secret ?
Le vibe coding ne doit pas être éliminé. Il doit être amplifié.
Les meilleurs développeurs ne sont pas ceux qui suivent les règles. Ceux qui sentent quand quelque chose est juste. Mais même les meilleurs ont besoin d’un regard extérieur. Pas pour les corriger. Pour les confirmer. Ou pour les arrêter.
Le HITL dans le vibe coding, c’est la différence entre un génie qui échoue et un génie qui dure.
10 Commentaires
Emeline Lavalle
J'adore cette approche. J'ai vu des équipes qui déployaient en prod sans test parce que "ça sent bon"... et puis un jour, une facture a été générée pour 12 millions d'euros à cause d'un bug de décimale. On a tous ri, mais ça a coûté trois semaines de boulot. Le vibe, c'est génial, mais il faut un regard qui dit "hésite".
Beau Graves
Exactement ce que je disais à mon équipe la semaine dernière. Je travaille dans une startup et on a mis en place le check-in à deux. Pas de revue formelle, juste un quick slack : "Tu veux jeter un œil ?" Et devine quoi ? On a évité trois bugs critiques en un mois. Le vrai secret, c'est pas la technique, c'est la confiance.
Nadine McGee
Et si tout ça c'était juste un moyen pour les managers de garder le contrôle sans avoir l'air de le faire ? Je veux dire... qui décide qui a "le bon vibe" ? Et si c'est juste les gens qui parlent comme toi ? Parce que moi je sens que ça sent le contrôle masqué...
Romain Grima
Je suis tombé sur ce post en pleine nuit en train de débugger un truc qui "devrait marcher". J'ai appelé un collègue. Il a dit "et si le serveur de config est down ?". On a testé. On a tout cassé. Et on a corrigé avant l'alerte client. Merci pour ce rappel. Le vibe, c'est la flamme. L'humain, c'est la lampe.
Yacine Merzouk
HITL ? C'est juste du corporate-washing pour dire qu'on a peur de la créativité. Les vrais devs, ils codent, ils déplient, et ils laissent les machines gérer les cas limites. Si ton code plante, c'est que t'étais pas assez bon. Pas besoin de "regard humain" pour sauver ton ego.
Yann Cadoret
Le vibe coding c'est une notion vague qui sert à justifier des pratiques irresponsables. On ne peut pas remplacer la documentation par une "intuition". C'est comme dire qu'on peut conduire sans permis parce qu'on a "le feeling". C'est dangereux. Et ça finit mal. Toujours.
Andre Jansen
Je suis un ancien dev de la NASA. J'ai vu des systèmes qui ont volé... puis qui se sont écrasés. Parce qu'on a oublié un point de contrôle. Un seul. Et maintenant, on parle de "vibe" ?! Non. Non. Non. Il faut des procédures. Des audits. Des signatures. Des vérifications. Pas des "je sens que". C'est de la folie.
Marcel Gustin
Le vibe coding c'est la magie. Et le HITL ? C'est le sorcier qui dit "non, tu vas pas faire ça". Les outils sont des balais. Les humains, c'est les vrais sorciers. 🧙♂️🔥
George Alain Garot
Vous avez tous loupé le point. Le vrai problème, c'est que les gens confondent intuition et arrogance. Le vibe coding n'est pas un talent. C'est un symptôme de l'ignorance des fondamentaux. Et les "check-ins" ? C'est juste du baby-sitting pour devs qui n'ont jamais lu un manuel de sécurité.
Yanis Gannouni
J'ai passé 12 ans dans des grandes entreprises avec des processus rigides. Puis j'ai rejoint une start-up. J'ai vu des bugs qui auraient pris des mois à détecter avec des outils. Et j'ai vu des devs qui, en 10 secondes, disaient "ça va péter ici". Parce qu'ils avaient déjà vécu ça. Le vrai HITL, ce n'est pas une méthode. C'est une culture. Et elle se construit avec des histoires. Pas des checklists.