La Démo Qui a Impressionné Tout le Monde
Lors d'une revue produit l'an dernier, un fondateur a présenté une nouvelle fonctionnalité. Elle était soignée, animée avec élégance. Les parties prenantes hochaient la tête. Quelqu'un a dit "c'est exactement ce que les utilisateurs demandaient." Ils l'ont livrée deux semaines plus tard.
Trois mois après, le taux d'adoption de la fonctionnalité était de 4 %. L'équipe avait construit exactement ce que les utilisateurs disaient vouloir — et les utilisateurs ne s'en servaient pas.
La leçon est brutale : ils ont construit ça si vite qu'ils n'ont jamais pris le temps de se demander s'ils le devaient.
La vitesse était devenue l'ennemie du jugement. L'IA ne fait qu'aiguiser le paradoxe : il n'a jamais été aussi facile de construire, ce qui rend savoir quoi construire avec l'IA plus crucial que jamais.
Ce Qu'est Vraiment le Vibe Coding
Le terme "vibe coding"(lien externe, nouvel onglet) — inventé par Andrej Karpathy début 2025 — décrit un mode de développement où vous décrivez ce que vous voulez en langage naturel, un agent IA génère le code, et vous itérez au feeling plutôt que sur spécification. Vous n'écrivez pas de code. Vous le dirigez.
Ça marche. Pour les prototypes, les projets annexes et les explorations préliminaires, c'est genuinement transformateur. Ce qui prenait une semaine à un développeur prend désormais une après-midi. L'énergie d'activation pour construire quelque chose est tombée à presque zéro.
C'est le problème.
Quand le coût de construction tombe à zéro, la seule contrainte restante est de décider quoi construire. La plupart des équipes n'ont jamais été très douées pour ça.
La Feature Factory, Maintenant avec l'IA
En 2016, John Cutler a popularisé l'idée de la "feature factory"(lien externe, nouvel onglet) — des organisations produit qui mesurent le succès au nombre de fonctionnalités livrées, pas à la valeur créée. Les équipes sprintent d'une demande à l'autre, livrent ce que les parties prenantes demandent, sans jamais questionner si ça compte.
Le vibe coding est une feature factory avec un turbocompresseur.
Quand une fonctionnalité prend six semaines à construire, la friction naturelle force la priorisation. On ne peut pas tout construire, donc on est forcé de choisir. Cette friction, aussi agaçante soit-elle, crée un forcing function pour la stratégie. Les équipes débattent de ce qui est le plus important. Les product managers doivent défendre leurs choix. Certaines mauvaises idées sont éliminées avant d'être livrées.
Quand une fonctionnalité prend trois heures, cette friction disparaît. Chaque idée semble valoir la peine d'être essayée. Le backlog n'est plus une contrainte ; il accélère. Et sans étoile polaire claire, les équipes finissent par livrer à vitesse maximale dans toutes les directions en même temps — ce qui revient à ne livrer dans aucune direction.
Ce que Stripe Réussit
Stripe(lien externe, nouvel onglet) a livré plus d'infrastructure développeur que presque n'importe quelle entreprise de sa taille. Mais explorez leur processus de décision produit et vous trouverez quelque chose de plus méthodique qu'on ne l'attendrait d'une puissance technique : une recherche utilisateur obsessionnelle, de longues périodes de délibération avant de s'engager sur de nouvelles surfaces, et une volonté brutale de ne pas construire des choses.
Patrick Collison a dit un jour que le vrai avantage compétitif de Stripe n'était pas son API — c'était son jugement sur ce que l'API devrait faire. N'importe qui peut construire une API de paiement. Construire la bonne API de paiement, avec les bonnes abstractions, pour les bons cas d'usage, demande un type de réflexion différent.
Ce jugement ne va pas plus vite quand le code va plus vite. Au contraire, un code plus rapide rend le jugement plus critique, parce que les mauvaises décisions se multiplient à la même vitesse que les bonnes.
Les Trois Questions Qui Vous Ralentissent (Intentionnellement)
Le vibe coding n'a pas besoin d'être l'ennemi d'une bonne réflexion produit. Mais il exige de mettre des garde-fous explicites autour de la couche de jugement — la partie qui ne peut pas être automatisée.
Avant de construire quoi que ce soit — peu importe la vitesse à laquelle l'IA peut le faire — trois questions :
Qui précisément va utiliser ça, et qu'est-ce qu'il va arrêter de faire à la place ? Pas "les utilisateurs veulent X." Quels utilisateurs, avec quel job-to-be-done, en abandonnant quelle alternative ? Si vous ne pouvez pas nommer le comportement que vous changez, vous ne savez pas ce que vous construisez.
Comment saurons-nous que ça a marché ? Pas "livré". Marché. Une métrique concrète, une comparaison avant/après, un taux d'adoption cible. Si la réponse est "on verra comment les gens aiment ça", ce n'est pas une métrique — c'est de l'espoir.
Quelle est la condition d'élimination ? À quel moment supprimons-nous ça si ça ne performe pas ? (C'est la métrique d'abandon que tout PO orienté résultats définit à l'avance.) Les fonctionnalités livrées sans condition d'élimination ne meurent jamais. Elles s'accumulent. Elles ralentissent tout. Elles deviennent la dette technique et produit que personne ne veut posséder.
Ces questions ne ralentissent pas le vibe coding. Elles le rendent utile.
Un risque connexe à comprendre : quand l'IA livre du code plus vite que quiconque ne peut le relire, vous accumulez aussi un nouveau type de dette technique bien plus difficile à détecter que le spaghetti traditionnel.
Le Takeaway
La contrainte sur votre produit n'a jamais été la vitesse à laquelle vous pouviez construire. C'était toujours la clarté avec laquelle vous pouviez penser. Le vibe coding supprime entièrement la première contrainte — ce qui signifie que la seconde est désormais tout. Investissez là.
