Vibe coding en production : deux fonctionnalités en huit jours

Le retour d'expérience qui suit mérite mieux qu'un partage LinkedIn : au sein d'un grand éditeur de logiciels créatifs, une équipe resserrée — un product manager, trois ingénieurs, un designer — s'est donné huit jours ouvrés pour livrer deux fonctionnalités en production, dans la vraie base de code du produit, en construisant directement avec des outils de codage assisté par IA. Pas un prototype jetable, pas une démo de keynote : du code livré, sous contraintes réelles. C'est exactement le terrain d'expérimentation qui manquait au débat sur le « vibe coding ».

Huit jours, deux fonctionnalités, zéro maquette-fleuve

L'objectif de l'équipe n'était pas la vitesse pour la vitesse : c'était de tester des boucles de feedback resserrées entre design, ingénierie et produit, sous une vraie pression produit. Résultat le plus frappant : le rôle des maquettes s'est inversé.

Avant, le designer produisait des dizaines d'écrans annotés dans Figma pour spécifier chaque comportement. Pendant l'expérience, Figma est resté — mais pour collaborer, plus pour spécifier : vingt minutes à une heure de croquis sur quelques écrans clés, puis construction directe dans le code. Le designer passe l'essentiel de son temps à construire l'expérience, plus à la décrire. Les contraintes réelles remontent immédiatement, pas trois semaines plus tard en réunion de recette.

Ce que la maquette statique ne montrera jamais

Le passage le plus utile du retour d'expérience tient en une liste : le timing, le mouvement, les retours d'interface et les comportements d'état — tout ce qui fait qu'une interaction est juste ou fausse — n'existe pas dans une maquette statique. En construisant tôt, l'équipe a itéré par incréments : un pinceau seul, puis l'annotation de texte, puis l'annotation d'image. Chaque incrément a fait remonter ses cas limites pendant qu'ils étaient encore bon marché à corriger.

Même logique pour l'accessibilité : traitée pendant le développement, au moment où elle se règle en dix minutes, plutôt que documentée après coup dans un audit que personne ne lira. C'est une conviction que je partage — sur ce site, le contraste AA, la navigation clavier et les tailles de cibles se sont décidés dans le code, pas dans un document (les lois UX que j'applique fonctionnent pareil : une loi qu'on n'applique pas n'est qu'une citation).

Le malentendu du vibe coding

L'idée reçue la plus tenace : coder avec l'IA rendrait la collaboration moins nécessaire. Cette expérience démontre l'inverse. L'ingénierie n'a jamais été aussi sollicitée — garantir la stabilité en production, éprouver les idées d'interaction ; le produit non plus — aligner les problèmes à résoudre, arbitrer les priorités. Les passages de relais se sont transformés en travail qui se chevauche autour de builds en cours, au lieu de documents qui attendent leur tour.

Le vibe coding sous contraintes réelles ne contourne pas la rigueur : il la rapproche du moment où l'idée devient une expérience.

Les questions que l'article laisse ouvertes

L'auteur a l'honnêteté de lister ce que l'expérience n'a pas résolu :

• Le rythme : à cette vitesse, il faut une discipline explicite pour lever la tête et réfléchir — la réflexion ne se produit plus toute seule dans les temps morts.
• L'altitude : garder la vision stratégique quand on a les mains dans le grain du code, toute la journée.
• Les limites : certaines situations — exploration large, systèmes de design fondateurs — où le processus classique reste supérieur.

Ce que j'en retiens, à mon échelle

Je pratique cette méthode en solo depuis 2024 — j'ai raconté pourquoi je travaille seul et avec l'IA. Cette expérience la valide dans un contexte que je ne peux pas tester : une grande organisation, une base de code partagée, un pod cross-fonctionnel. Trois convergences me frappent.

D'abord, la spécification devient construction : mes clients ne reçoivent plus de maquettes-fleuves, ils reçoivent des builds cliquables dès la deuxième semaine. Ensuite, la qualité se décide au moment du build — accessibilité, performance, états vides : tout ce qui coûtait une passe de recette se traite au fil de l'eau. Enfin, la conclusion de ce designer est la mienne : l'empathie, le jugement, le goût et le métier ne sont pas remplacés par l'outil — ils deviennent la seule chose qui distingue deux personnes équipées du même outil.

La différence entre leur configuration et la mienne : eux resserrent la boucle à l'intérieur d'un pod ; moi je supprime le pod — et c'est le client qui joue le rôle du produit, en direct. Les deux configurations racontent la même chose : le coût de la distance entre l'idée et l'expérience s'est effondré. Ceux qui organisent encore leur production autour de cette distance paient un impôt invisible.