21 juin 2026
Vibe coding : ce que ça change vraiment pour les équipes produit
Le vibe coding n'est pas une baguette magique : c'est une nouvelle façon de livrer plus vite, à condition de garder du jugement produit, de l'architecture et de la responsabilité humaine.
Ce que j'appelle vraiment vibe coding
Le vibe coding, pour moi, ce n'est pas demander à Cursor, Claude Code ou un autre assistant IA de coder à votre place pendant que vous regardez ailleurs. C'est travailler avec un copilote très rapide, très littéral, parfois brillant, parfois naïf, qui transforme une intention produit en code exécutable beaucoup plus vite qu'avant. La différence est subtile mais importante : l'IA accélère l'aller-retour entre idée, implémentation et test. Elle ne décide pas ce qui mérite d'exister.
Dans mes missions, je l'utilise comme une extension de l'atelier de construction. J'écris le cadrage, je découpe le problème, je donne le contexte métier, je demande une première version, puis je relis, je corrige, je simplifie et je teste. Quand cela marche bien, on ne sent pas une magie. On sent une réduction massive du frottement entre la conversation produit et le logiciel qui tourne vraiment. C'est moins romantique que le mot vibe, mais beaucoup plus utile.
La vitesse change le périmètre possible
La première conséquence est évidente : on livre plus vite. Mais la vraie conséquence est plus profonde : on ose explorer des périmètres que l'on aurait auparavant écartés trop tôt. Une équipe produit peut tester deux parcours au lieu d'un, ajouter un écran d'administration interne, écrire une migration propre, générer des tests de régression, brancher un export CSV, documenter une API, ou refaire un composant maladroit sans transformer chaque décision en mini-projet. Les petites dettes de produit deviennent moins coûteuses à rembourser.
Cela change aussi la dynamique avec les métiers. Au lieu de promettre une évolution pour dans trois sprints, on peut parfois revenir le lendemain avec une version utilisable. Pas parfaite, mais tangible. Dans un projet de copilote interne, par exemple, j'ai pu itérer rapidement sur l'interface de validation humaine : affichage des sources, bouton de correction, statut de confiance, historique des décisions. Sans assistant IA, ces raffinements auraient probablement été repoussés derrière le cœur algorithmique. Avec le vibe coding, ils sont revenus au centre, parce que le coût de les essayer avait chuté.
Ce que ça ne remplace pas
Le risque est de confondre vitesse et direction. Un assistant de code peut produire beaucoup de lignes cohérentes, mais il ne sait pas naturellement quelle contrainte métier est non négociable, quelle donnée est sensible, quel raccourci va casser la confiance utilisateur, ni quel comportement sera acceptable devant un comité de conformité. Il peut proposer une architecture. Il ne portera pas la responsabilité si cette architecture devient incompréhensible dans trois mois.
Le jugement humain reste donc le centre du travail : choisir le bon problème, réduire le scope, nommer les abstractions, décider où mettre un humain dans la boucle, écrire les tests qui protègent le vrai risque, et dire non quand l'IA produit une solution séduisante mais fragile. Plus l'assistant est puissant, plus l'ingénieur ou le product builder doit être clair. Le vibe coding récompense les gens qui savent expliquer, vérifier et trancher. Il ne sauve pas les équipes qui n'ont pas de cap.
Deux exemples très concrets
Sur des outils internes IA, j'ai utilisé ce mode de travail pour accélérer la partie qui est souvent sous-investie : les écrans d'opérations. Logs lisibles, filtres par statut, vues de comparaison entre sortie du modèle et correction humaine, petites actions de reprise. Ce ne sont pas des fonctionnalités spectaculaires, mais ce sont elles qui rendent un système exploitable. L'assistant IA m'aide à produire vite la mécanique. Mon rôle reste de savoir quelles informations donnent réellement du pouvoir à l'équipe qui va opérer le système.
Autre cas : un prototype agentique où plusieurs étapes devaient être orchestrées, testées et expliquées à une équipe non technique. L'IA a accéléré la création des routes, des mocks, des tests et de la documentation initiale. Mais la décision importante n'était pas dans le code généré. Elle était dans le découpage des responsabilités : quelles étapes devaient être déterministes, lesquelles pouvaient appeler un modèle, où fallait-il arrêter le workflow, et comment rendre l'échec lisible. C'est exactement la frontière : l'IA augmente l'exécution, pas la responsabilité produit.
Le vrai changement pour les équipes produit
Le vibe coding rend les équipes plus proches du matériau logiciel. Les PM peuvent formuler des demandes plus précises parce qu'ils voient plus vite ce que coûte une idée. Les ingénieurs peuvent consacrer plus de temps aux décisions qui comptent vraiment, parce que l'assistant absorbe une partie de la friction répétitive. Les designers peuvent obtenir des variantes fonctionnelles plutôt que des promesses abstraites. Mais cela ne fonctionne que si l'équipe accepte de traiter l'IA comme un atelier, pas comme un stagiaire autonome.
Ma conviction est simple : les meilleures équipes produit ne vont pas remplacer leur exigence par des assistants IA. Elles vont augmenter leur cadence sans baisser leur niveau de jugement. Si vous voulez comprendre où ce levier peut vraiment accélérer votre roadmap, et où il risque au contraire d'ajouter du bruit, le bon point de départ est souvent une courte session de cadrage. Mon calendrier est ouvert pour en parler quand le sujet mérite d'être construit sérieusement.