Deuxième volet de notre série sur le Product building. Cela étant le profil du Product Builder, place à la méthode qui rend cette pratique possible : le Spec-Driven Development.
Le product building tient une promesse simple : porter une fonctionnalité de l’intention à la production, vite, sans multiplier les intermédiaires. Mais cette promesse ne tient que si l’on change de méthode. Car pendant des années, la façon de travailler a été la même : découper un besoin en user stories, les affiner en refinement, les étaler sur un sprint, les livrer une à une. Ce découpage était une réponse rationnelle à une contrainte réelle, le développement coûtait cher, il fallait avancer par petits pas vérifiables.
Mais quand l’IA génère le code en une fraction du temps, ce découpage granulaire perd une partie de son sens. La contrainte n’est plus le build, c’est la clarté de la spécification. Et si le vrai document de travail n’était plus une constellation de tickets, mais un texte unique, complet, qui devient la référence pour l’humain comme pour la machine ? C’est le pari du Spec-Driven Development (SDD), la méthode qui structure le product building.
Du backlog éclaté au PRD unique
Le principe du SDD tient en une phrase : faire de la spécification la véritable source de vérité. On ne pilote plus le développement à partir d’un empilement de user stories, mais à partir d’un document central le “PRD”, Product Requirement Document, qui décrit tout ce dont l’IA a besoin pour produire le bon livrable.
Un PRD « source de vérité » ne se contente pas de lister des fonctionnalités. Il rassemble :
- Le besoin : le problème réel à résoudre ;
- Les personas : pour qui l’on construit ;
- Les contraintes : techniques, réglementaires, business ;
- Les règles métier : la logique qui gouverne le produit ;
- Les spécifications fonctionnelles : le comportement attendu, précisément.
Ce document devient la base de connaissances sur laquelle les modèles s’appuient pour générer le code. On passe d’un mode où le savoir est dispersé dans les têtes, dans les tickets, dans les conversations, à un mode où il est explicite, centralisé et exploitable.
Le « sprint en un jour »
C’est la conséquence la plus spectaculaire du SDD, et celle qui fait le plus parler : quand la spécification est solide, la valeur d’un sprint peut être produite en une seule journée.
L’IA lit le PRD, propose un plan, génère le code, le teste, le déploie. Ce qui prenait deux semaines de cérémonies, d’allers-retours et d’attente peut se condenser en quelques heures. L’accélération des cycles est réelle et, sur certains périmètres présentés lors de la Product Conf, elle est massive.
Mais cette vitesse a un prix, et il faut le nommer clairement.
Le revers : le MVP « ultra fat » et le risque anti-lean
Quand construire devient si rapide, une dérive guette. Le MVP, Minimum Viable Product, par définition minimal, a tendance à grossir. Puisqu’il ne coûte presque rien d’ajouter une fonctionnalité, on en ajoute. Le « minimum viable » devient un MVP « ultra fat », riche mais éloigné de son intention première.
Le risque, c’est de s’éloigner des principes lean sous prétexte qu’on en a les moyens. L’esprit du MVP n’a jamais été de faire petit par contrainte, mais de faire juste pour apprendre vite. Si l’IA nous pousse à construire plus parce que c’est facile, on retombe exactement dans le piège du produit surchargé mais plus rapidement.
Le SDD ne dispense donc pas de discipline. Il la déplace : de l’exécution vers le cadrage. Toute l’exigence se concentre désormais sur la qualité de la spécification.
Cas pratique : unifier des « empty states » avec un skill Spec-Driven
Pour rendre les choses concrètes, prenons le cas pratique présenté en atelier, autour de l’outil Lovable. L’objectif était modeste et parfaitement réaliste : harmoniser l’apparence de deux pages « Review » et « Forecast » d’un outil d’animation de Sprint Review, lorsqu’elles n’ont pas encore de données à afficher (les fameux empty states), et corriger au passage le libellé d’un bouton.
Le déroulé illustre parfaitement la logique Spec-Driven :
| Étape | Ce qui se passe |
| 1. Invocation | L’utilisateur appelle le skill dédié (/SpecDriven) |
| 2. Planification | L’IA analyse la demande, le code source existant et le design system |
| 3. Approbation | L’IA propose un plan d’action que l’utilisateur valide avant tout code |
| 4. Création | L’IA génère le code en respectant l’architecture modulaire — ici, un nouveau fichier de style plutôt qu’une modification risquée de l’existant |
| 5. Déploiement | L’outil commite sur GitHub, déclenche le pipeline de déploiement et génère les notes de version |
Le point remarquable n’est pas la génération de code en elle-même. C’est l’étape de planification et d’approbation, qui remet l’humain dans la boucle avant l’exécution. L’IA ne fonce pas tête baissée : elle lit le contexte, propose, attend la validation. C’est la spécification et le skill qui la structure et qui encadre la réflexion en amont du code, sur la faisabilité, la pertinence et l’analyse de l’existant.
La formalisation, nouvelle compétence reine
Ce que le SDD révèle, finalement, c’est que la qualité de la formalisation devient la compétence la plus stratégique. Un PRD bien construit produit un livrable pertinent en une journée. Un PRD approximatif produit, tout aussi vite, quelque chose dont personne ne veut.
C’est un changement de nature du travail produit et tech. Moins de temps passé à écrire des lignes de code, beaucoup plus à écrire ce qu’il faut construire, pour qui, et pourquoi. La rigueur ne disparaît pas, elle remonte simplement d’un cran, là où elle a le plus d’impact.
Cette bascule prolonge ce que nous décrivions déjà dans notre article sur l’IA dans les métiers produits : la valeur ne se joue plus dans la production, mais dans la qualité du contexte qu’on donne à l’IA.