Avant le code, faire produire le fonctionnel par l’IA

Série « Vibe coding avec Claude Code » · Article 2/5. Avant d’écrire une seule ligne de code, l’IA a d’abord fait un travail d’analyste : structurer un besoin, le reformuler, le découper. Voici comment, et sous quelle direction.

Sommaire de la série :

1. J’ai vibe-codé une application e-commerce complète avec Claude Code
2. Avant le code : faire produire le fonctionnel par l’IA (cet article)
3. Préparer le terrain : doc, archi et gouvernance avant la première ligne
4. La méthode au quotidien : comment Claude code, et comment je garde le contrôle
5. Bilan : ce que ça apporte, ce que ça coûte, et la recette à réutiliser

Dans le premier article de la série, j’ai montré le résultat : une application e-commerce event-driven, construite en quelques jours. Maintenant, on rembobine. On revient avant la première ligne de code, à la phase que tout le monde zappe quand on parle de vibe coding : le fonctionnel. Le recueil, l’affinage, le découpage, la feuille de route. Et la surprise, c’est que le tout premier travail de l’IA n’a pas été de coder, mais d’analyser. Mon fil rouge ne change pas d’un article à l’autre :

Je dirige, l’IA exécute.

Il s’applique aussi, et peut-être surtout, à cette phase amont. Je décris une intention en langage naturel, l’IA la structure et me la renvoie sous une forme exploitable, je corrige, on converge. À la fin, on a une spécification fonctionnelle claire, écrite avant de coder. C’est de ça que parle cet article.

💬 Où ça s’est joué : la « Phase 0 ». Une grande partie de la genèse fonctionnelle (et technique) ne s’est pas faite dans Claude Code, mais en amont, dans Claude Chat sur le web : une longue conversation de cadrage, plusieurs heures, à brasser le besoin et les options. C’est là qu’est né le périmètre fonctionnel, avant d’ouvrir le moindre fichier. Cette phase est hors des outils du dépôt (pas de log, pas de commit) : c’est une limite que j’assume et sur laquelle je reviens en fin d’article.

1. Recueil des besoins : je décris, l’IA structure

Le point de départ n’était pas un cahier des charges de quarante pages ni un backlog déjà ficelé. C’était une intention, formulée à voix haute, en langage naturel : « je veux une application qui me permette de voir et sentir une architecture event-driven sous des conditions réalistes, avec un e-commerce comme prétexte ». Rien de plus précis au départ.

Le travail de Claude, à ce stade, a été celui d’un analyste : prendre cette intention floue et la rendre structurée. Je décris, il reformule en un périmètre fonctionnel net, il me propose un vocabulaire, il liste ce qui manque, je tranche. C’est un aller-retour, pas une dictée. L’IA n’est pas un oracle qui « sait » ce qu’il faut faire : c’est un partenaire de reformulation très rapide, à qui je donne le cap et le jugement.

De ces échanges est sorti un périmètre fonctionnel simple et assumé, celui d’un e-commerce que tout le monde comprend :

Des clients (profil : nom et adresse), un panier, des produits (avec images, catégories et produits liés pour le cross-selling), des commandes, du stock, de l’expédition avec suivi, une page de paiement (factice, pas de vrai prestataire), un back-office pour gérer le catalogue et expédier, des e-mails (à la connexion et à la commande), et une recherche catalogue via Elasticsearch, à facettes.

Ce périmètre n’a rien d’extraordinaire, et c’est volontaire. L’important n’était pas quoi construire, mais de figer cette base assez clairement pour pouvoir, juste après, l’affiner dans la bonne direction.

🧭 Ça porte un nom (suite). Spécifier le « quoi » d’abord, le faire valider par un humain, puis dériver le plan et le code : c’est le cœur du spec-driven development (Thoughtworks, déc. 2025). Comme l’écrit Addy Osmani, « la spec devient le premier artefact que vous et l’IA construisez ensemble » (janv. 2026). Le goulot d’étranglement se déplace : il ne s’agit plus de coder vite, mais de spécifier clair. C’est exactement ce qui se joue dans ce chapitre.

2. Affinage fonctionnel : des objectifs observables, et une règle d’or

Voici le moment le plus important de toute la phase amont, et le plus contre-intuitif. L’affinage n’a pas consisté à ajouter des fonctionnalités. Il a consisté à reformuler l’objectif : on ne construit pas « un e-commerce de plus », on construit quelque chose qui rend quatre comportements d’architecture visibles et manipulables. Le fonctionnel se met au service d’objectifs observables, pas l’inverse.

Ces quatre objectifs, posés noir sur blanc avec l’aide de Claude, sont devenus la boussole du projet :

1. Un changement dans un module qui en affecte un autre, sans couplage direct.
2. Le mécanisme de communication entre modules : en mémoire, ou via un broker de messages (RabbitMQ).
3. Quel modèle de cohérence pour quelle interaction : transactionnel, cohérence éventuelle, ou saga avec compensation ?
4. La synchronisation d’un tiers (Elasticsearch) et sa cohérence éventuelle.

Tout le reste du fonctionnel n’est qu’un véhicule pour rendre ces quatre choses tangibles. Et c’est là qu’intervient la décision de cadrage qui a tenu tout le projet, la règle d’or que j’ai répétée à l’IA à chaque incrément :

« Le domaine est la seule chose simplifiée. Tout le reste est production-grade. Pas de TODO, pas d’exceptions avalées, pas de raccourcis. Le bon correctif l’emporte sur le correctif rapide, toujours. »

Cette phrase est avant tout une décision fonctionnelle : elle dit quoi simplifier (le métier, volontairement banal) et quoi ne jamais brader (la fiabilité, la concurrence, la gestion d’erreurs, les tests, la télémétrie). Sans cette ligne, une IA laissée libre aurait tendance à simplifier partout, y compris là où ça compte. Le rôle de Claude ici a été double : m’aider à formuler la règle clairement, puis se la voir rappeler à chaque incrément pour la tenir. La direction reste humaine ; l’IA exécute dans le cadre.

3. Découpage : sept contextes métier

Une fois le périmètre et les objectifs posés, il faut découper. En DDD (Domain-Driven Design), on parle de bounded contexts : des morceaux de métier cohérents, autonomes, avec chacun sa responsabilité claire. Claude a proposé un premier découpage, je l’ai challengé et réorganisé, et on a convergé sur sept contextes métier, plus un read-side dédié aux lectures transversales (Reporting), qui n’est pas un module métier à part entière.

La carte des contextes métier. Chaque boîte est une capacité métier autonome ; les flèches sont des relations fonctionnelles (le panier référence des produits et un acheteur, le checkout transforme le panier en commande, l’expédition et les notifications réagissent aux événements de la commande). Reporting lit en travers, sans rien posséder.

Ce découpage a une vertu que je voulais éprouver : chaque contexte est isolé (il ne référence les autres que par identifiant, jamais par une dépendance directe à leurs données), ce qui rend possible, plus tard, d’en extraire un en microservice sans tout réécrire. Le comment technique de cette isolation est le sujet de l’article 3 ; ce qui compte ici, c’est que le découpage fonctionnel a été pensé pour ça dès le départ, avec l’IA comme force de proposition et moi comme arbitre.

4. Allotissement et feuille de route : chaque incrément prouve une notion

Découper le métier ne suffit pas. Il faut décider dans quel ordre construire, et c’est l’autre grande décision amont. Le piège classique serait de bâtir tous les modules d’un coup puis d’intégrer à la fin (et de découvrir tous les problèmes au pire moment). On a fait l’inverse : un allotissement en incréments, où chaque incrément est livrable de bout en bout et prouve une des notions visées. La feuille de route a été co-construite : je donne l’objectif et l’ordre logique, Claude propose un séquencement, je réajuste. Pas de backlog formel ni de jalons datés : en solo, sans contrainte de livraison, la feuille de route était le backlog, et l’ordre logique des incréments tenait lieu de planning. En équipe, c’est cette même feuille de route qui alimenterait un backlog priorisé et des échéances.

La feuille de route. À gauche, l’incrément ; à droite, la notion qu’il rend tangible. L’incrément 3 (la commande et sa saga de paiement avec compensation) est le cœur du POC ; les incréments 9 et 10 sont arrivés plus tard, quand de nouveaux besoins sont apparus.

Deux principes ont guidé cette feuille de route. Le premier est le design-first : à l’intérieur de chaque incrément, on ne se jette pas sur le code. On refait d’abord une analyse poussée, puis on écrit la décision d’architecture, puis le modèle, puis le contrat, puis les tests, puis le code, puis la note pédagogique. Le détail de ce cycle est le sujet de l’article 4 ; ce qui compte ici, c’est que la réflexion précède toujours la frappe. Le second principe est que la feuille de route est un document vivant, pas un plan gravé dans le marbre. La preuve : les incréments 9 et 10 (gestion de l’identité, administration des acheteurs) n’étaient pas prévus au début. Ils ont été ajoutés quand le besoin est apparu, et la spec a été mise à jour en conséquence. C’est exactement l’esprit du spec-driven development : une spécification qu’on fait évoluer, qui reste la source de vérité.

Le document-source unique du projet (docs/PROJECT-CONTEXT-AND-PLAN.md). En haut, les quatre objectifs observables ; en bas, la feuille de route où chaque incrément prouve une notion. La spécification fonctionnelle existe pour de vrai, et elle est structurée.

5. Le fonctionnel documenté, base de dialogue « trois amigos »

Voici le point que je veux vraiment faire passer, et qui dépasse largement le code. Tous ces artefacts produits en amont (le document-source unique, la carte des contextes, la feuille de route, et plus tard les décisions d’architecture et les notes pédagogiques) ne sont pas des livrables « de dev ». Ce sont des supports de dialogue.

Dans une équipe, les bonnes décisions fonctionnelles se prennent à trois voix : le métier (qu’est-ce qu’on veut ?), le développement (qu’est-ce qui est faisable, et comment ?) et la QA (comment on saura que c’est correct ?). C’est ce qu’on appelle les « trois amigos ». Pour que ce dialogue soit possible, il faut un langage commun, lisible par les trois. Une spécification fonctionnelle structurée, écrite en clair et tenue à jour, est précisément ce langage. L’IA, en produisant et en maintenant cette doc sans relâche, sert donc bien plus que le développeur : elle outille la décision collective.

C’est aussi ce que dit l’industrie : dans le spec-driven development, la spec devient « la source de vérité partagée », un artefact vivant qui évolue avec le projet. Sur ecom, cette doc transversale (fonctionnel, mais aussi, on le verra, infrastructure et sécurité) joue ce rôle d’onboarding et de référence partagée.

⚖️ Honnêteté. Sur ce POC, j’étais seul : pas de vrai métier en face, pas de vraie QA dans la pièce. Le dialogue « trois amigos » n’a donc pas eu lieu pour de vrai. Ce que je montre, c’est que la documentation a été structurée pour pouvoir l’être : un analyste métier, un développeur et un testeur pourraient s’asseoir autour et la challenger. La structure est là ; la pratique d’équipe, elle, reste à vivre sur un vrai projet.

6. À retenir : Claude analyste, pas seulement développeur

Si vous ne deviez retenir qu’une idée de cet article : avant d’être un développeur, l’IA a été un analyste. Structurer un besoin flou, le reformuler en périmètre net, proposer un découpage en contextes métier, dérouler une feuille de route, tenir la documentation à jour : tout cela s’est passé avant la première ligne de code, et l’IA y a été d’une aide considérable. Mais à chaque étape, c’est un humain qui apporte l’intention, le jugement et l’arbitrage. « Je dirige, l’IA exécute » vaut pour le fonctionnel autant que pour le code.

✅ À retenir

• La phase la plus négligée du vibe coding, c’est l’amont. C’est pourtant là que Claude a apporté le plus de valeur en tant qu’analyste / PO : structurer, reformuler, découper, documenter.
• On a d’abord figé un périmètre fonctionnel simple, puis on l’a affiné non pas en ajoutant des fonctionnalités, mais en le mettant au service de quatre objectifs observables.
• La règle d’or est une décision fonctionnelle : simplifier uniquement le domaine, jamais la plomberie.
• Le métier a été découpé en sept contextes autonomes, et le travail aloti en incréments dont chacun prouve une notion ; la feuille de route est un document vivant.
• Le fonctionnel documenté n’est pas un livrable de dev : c’est une base de dialogue (métier, dev, QA) et un support d’onboarding.

➡️ Article suivant : « Préparer le terrain : doc, archi et gouvernance avant la première ligne ». On passe du fonctionnel aux fondations techniques : le brainstorming d’architecture décidé ensemble, les diagrammes C4 / UML, et le vrai différenciant, la gouvernance de Claude (agents spécialisés, commandes, règles encodées).

🛠️ À améliorer (transparence)

• Un domaine trivial allège l’analyse. Le métier était volontairement banal, donc le recueil et l’affinage ont été légers : peu de règles métier complexes à extraire. Sur un vrai produit, cette phase serait bien plus lourde, et les reformulations de l’IA exigeraient beaucoup plus de corrections d’un expert métier. Ne pas confondre « l’IA a structuré mon e-commerce jouet » avec « l’IA analyse n’importe quel domaine complexe sans supervision ».
• La Phase 0 est hors-outils. La genèse fonctionnelle s’est faite sur Claude Chat (web), sans log ni versionnement. Sur un projet sérieux, ce cadrage devrait atterrir dans le dépôt de spec dès le premier jour, traçable et réutilisable, pas dans une conversation web isolée.
• La feuille de route a grossi en cours de route. Les incréments 9 et 10 n’étaient pas prévus. C’est sain pour un document vivant, mais c’est aussi le signe que l’envisagement fonctionnel initial n’était pas exhaustif. Une vraie phase de cadrage produit aurait anticipé davantage.
• Le « trois amigos » est resté théorique. Faute d’équipe, la doc est une base de dialogue potentielle, pas un dialogue vécu. La valeur réelle de ces artefacts ne se mesure pleinement qu’en équipe.