2026-06-05

Le vibe coding est mort, place aux specs ? Les product managers ont une troisième voie : dire ce qu'on veut et l'IA le construit

Ces derniers temps, le monde des méthodologies se bat autour d’un titre qui fait peur : « Le vibe coding est mort — vite, passez au spec-driven development. »

Le vent tourne, c’est un fait. Spec Kit sur GitHub dépasse les quatre-vingt-dix mille étoiles, AWS a lancé Kiro autour du principe « d’abord la spec, ensuite le code », et Thoughtworks a inscrit le spec-driven dans son Technology Radar. Le discours dominant est clair : la spec est l’unique source de vérité ; le code n’en est que le produit. En cas de conflit, on change le code, jamais la spec.

Ça paraît logique. Mais si vous êtes product manager, ne vous précipitez pas à suivre la mode et à reprendre des cours de rédaction de specs.

Le pendule a trop oscillé

Voici comment les choses se sont passées :

D’abord le vibe coding a enflammé l’industrie — une phrase à l’IA et ça déverse du code à la pelle. Grisant, mais les déconvenues ont vite suivi : pas de structure, impossible à maintenir, personne ne pouvait expliquer ce que le système faisait vraiment. Alors le balancier est parti à l’autre extrême : tout écrire en spec d’abord, le plus détaillé possible, et laisser l’IA exécuter.

Le problème, pour un product manager, c’est que « rédiger une spec préalable exhaustive » vous est parfaitement familière — c’est le PRD. Ce document qui fait parfois des dizaines de pages, périmé avant d’être terminé, que personne ne lit en entier. L’une des grandes libérations de l’ère IA, c’était précisément de vous délivrer de ce labeur documentaire ; le spec-driven vous le remet exactement entre les mains, avec une étiquette plus tendance.

Passer du « coder dans le vide » au « tout spécifier », c’est troquer un extrême pour un autre. Aucun des deux n’est l’endroit où un product manager devrait se trouver.

La troisième voie : la spec ne s’écrit pas, elle se dit — et elle s’exécute

Le vibe coding est trop fragile, l’écriture de specs trop lourde. Entre les deux, il existe une voie — celle que doaipm emprunte depuis le début : dire ce qu’on veut et l’IA le construit.

Son principe central : vous n’avez pas besoin d’une spec couchée dans un document ; vous avez besoin d’articuler clairement ce que vous voulez faire. Or « formuler clairement » est précisément le cœur de métier du product manager — ce n’est pas une nouvelle compétence à acquérir.

Concrètement, cela se décompose en deux choses :

Premièrement, la spec vit dans la conversation, pas dans un document. Pas besoin de produire une spec complète avant de commencer. Vous exprimez votre intention — quel problème vous résolvez, pour qui, quelles sont les contraintes clés, ce qui constitue un succès — puis vous laissez l’IA en faire quelque chose qui tourne immédiatement. Là où c’est flou, l’IA vous relancera (un bon agent devrait poser 3 à 5 questions tranchantes avant de se lancer) ; vous clarifiez dans l’échange. La clarification se produit dans le dialogue, pas dans un document que personne n’a envie de lire.

Deuxièmement, le prototype haute-fidélité qui tourne est lui-même la meilleure spec. Un texte de spécification, dix personnes en tireront dix interprétations ; un prototype cliquable, fonctionnel, avec de vrais états (chargement / vide / erreur / succès), tout le monde le comprend d’un coup d’œil. Le prototype haute-fidélité est une spec qui se fait comprendre seule — elle ne se lit pas, elle s’expérimente. C’est aussi pourquoi doaipm s’oppose aux wireframes basse-fidélité : à l’ère de l’IA, construire directement quelque chose de réel est plus rapide et génère moins de malentendus que de dessiner un semblant de maquette.

Et la « structure », elle vient d’où ? — Petits pas et filet de sécurité

Certains objecteront : sans spec solide, comment éviter de retomber dans les travers du vibe coding, de perdre le contrôle ?

Grâce à deux choses, pas à un document épais :

Petits pas rapides. Changez une seule chose à la fois, vérifiez, observez, passez à l’étape suivante. La structure émerge d’une succession de petites étapes vérifiables — elle n’est pas planifiée une fois pour toutes avant de commencer.
Le filet de sécurité. Pas de vraies clés ni de vraies données dans le prototype ; les boutons irréversibles (mise en ligne, suppression, paiement) restent à la main de l’humain ; ne touchez pas à la production ; demandez quand vous doutez. Le pouvoir de décision reste toujours entre vos mains — c’est précisément ce qui rend le product manager irremplaçable.

Dire que la spec est l’unique source de vérité, c’est oublier une chose : à l’ère de l’IA, la « source de vérité » la plus haute-fidélité n’est pas un document — c’est le produit qui tourne sous vos yeux.

Alors, à quoi croire aujourd’hui

Ne choisissez pas de camp entre « vibe coding » et « spec-driven » — c’est un faux dilemme.

Ne faites pas comme le vibe coding : ne déléguez pas votre cerveau à l’IA sans réfléchir.
Ne faites pas non plus comme la rédaction de specs lourdes : ne reprenez pas le fardeau documentaire dont l’ère IA venait juste de vous décharger.
Empruntez la voie du milieu : formulez clairement ce que vous voulez (vous savez déjà faire ça), laissez le prototype haute-fidélité parler pour vous (l’IA s’en charge), avancez pas à pas, tenez le filet de sécurité.

Ce n’est pas un énième framework à apprendre — il y en a déjà bien assez. C’est un retour au geste le plus fondamental du product manager : savoir ce qu’on veut, le dire clairement, et le faire tourner.

言出，法随。

Pour aller plus loin