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.