Il y a trois semaines, je fixais une page Notion à vingt-deux heures trente. Un client avait envoyé un brief pour une plateforme de réservation personnalisée. Le brief comprenait quatre points de balle et un emoji. Littéralement juste : « comme Calendly mais pour les toiletteurs de chiens 🐶 ». C'était tout. Pas de flux utilisateur. Pas de cas limites. Aucune idée s'ils voulaient une SaaS ou une installation mono-tenant. Et ils avaient besoin d'une spécification avant vendredi.
J'avais l'habitude de redouter ces moments. Maintenant j'y attends presque avec impatience.
Parce que j'ai construit un flux de travail autour de Claude qui transforme ce genre de chaos en spécification structurée et défendable en un couple d'heures. Je l'ai affiné sur peut-être 40 projets chez Seahawk au cours des 18 derniers mois, et cela m'a épargné au moins trois rewrites « mais je pensais que ça ferait X » qui auraient coûté de l'argent réel.
Laissez-moi vous le présenter correctement.
---
Pourquoi un brief vague est en fait un bon point de départ
Voilà le truc avec les briefs vagues : ils contiennent du signal. Le truc Calendly du toiletteur de chiens te dit l'industrie, le produit de comparaison et l'échelle implicite (petite entreprise, pas enterprise). Ce n'est pas rien.
L'erreur que j'avais l'habitude de faire était d'essayer immédiatement d'étoffer le brief moi-même. Je faisais des suppositions, je les intégrais dans un document, puis un client acceptait quelque chose qui était 40% mes devinettes. C'est un désastre qui attend.
Claude n'a pas ce problème. Il pose des questions. Ou plutôt, quand tu le prompts correctement, il génère les questions que tu aurais dû poser.
Mon premier geste sur tout nouveau projet est de coller le brief brut dans Claude et de lui demander d'identifier chaque hypothèse que tu devrais faire pour construire la chose. Pas des fonctionnalités. Des hypothèses. Le résultat est généralement 15-25 questions, et environ un tiers d'entre elles sont des questions que j'aurais passées sous silence.
Pour le projet de toiletteur de chiens, Claude a surfacé des choses comme : le toiletteur a-t-il plusieurs membres du personnel, ou s'agit-il d'une opération en solo ? La réservation doit-elle tenir compte de la taille de l'animal affectant la durée du rendez-vous ? Y a-t-il une caution ou une capture de paiement au moment de la réservation ? Je n'avais pas du tout pensé à la taille de l'animal. Le client non plus, comme il s'est avéré. On a attrapé ça lors de l'appel de découverte au lieu du sprint trois.
---
La structure de prompt qui fonctionne vraiment
J'ai essayé beaucoup de façons différentes de faire du prompt pour le travail de spécification. Des trucs génériques comme « aide-moi à concevoir une app de réservation » te donnent des déchets génériques. Ce qui fonctionne c'est un input structuré qui donne à Claude assez de contexte pour contraindre son output.
Voici le modèle brut que j'utilise maintenant :
- Définition du rôle. Je dis à Claude qu'il agit en tant que gestionnaire de produit senior qui a livré du B2B SaaS avant et qui est allergique à la dérive de portée.
- Brief brut. Colle-le textuellement, aussi brut soit-il.
- Contraintes. Gamme budgétaire, pile technologique si connue (on utilise par défaut WordPress/WooCommerce pour la plupart des sites clients, Laravel personnalisé pour tout ce qui est plus lourd), timeline, taille de l'équipe.
- Format d'output. Je demande un document structuré avec des sections spécifiques : énoncé du problème, personas utilisateurs, flux utilisateur principaux, liste de fonctionnalités (MVP vs. post-lancement), questions ouvertes et risques.
La partie contraintes est celle que la plupart des gens passent sous silence. Ça compte énormément. « Budget : £8 000, timeline : 8 semaines, deux développeurs et un designer à temps partiel » produit une spécification très différente du même brief sans contraintes. Sans elles, Claude sera heureux de specifier un produit qui prendrait six mois et £60k à construire. Ce qui est amusant à lire et inutile à livrer.
---
Itérer sur la spécification avec des invites adversariales
Obtenir un premier brouillon de spécification, c'est la partie facile. La vraie valeur réside dans l'itération.
Après que Claude produit le document initial, j'effectue ce que j'appelle une passe adversariale. Je lui demande littéralement : « Maintenant, argumentez contre cette spec. Où la dérive de périmètre risque-t-elle de se produire ? Qu'avons-nous sous-estimé ? Quelle fonctionnalité de cette liste causera le plus de dette technique dans 12 mois ? »
Seahawk avait un client fintech en 2022 qui voulait un tableau de bord pour suivre les portefeuilles de micro-investissements. La première spec semblait solide. La passe adversariale a signalé que la fonctionnalité « mises à jour des prix en temps réel » dans le MVP faisait beaucoup de travail et nécessiterait probablement une architecture WebSocket que notre calendrier et notre budget ne prévoyaient pas. On l'a détecté. On l'a limité à un interrogage toutes les 60 secondes pour le MVP, avec le temps réel en tant que fonctionnalité de phase deux. Le client était d'accord. L'aurions-nous détecté sans la passe adversariale ? Peut-être. Mais probablement pas avant que quelqu'un soit trois semaines dans le développement.
L'étape adversariale ajoute peut-être 20 minutes au processus. Ça en vaut toujours la peine.
---
Traduire la spécification en user stories
Une fois que la spec est assez solide pour que je n'en sois pas gêné, je passe à la génération de user stories. C'est là que Claude brille vraiment, car écrire de bonnes user stories est fastidieux et facile à faire mal.
Je resoumets la spec à Claude et je lui demande des user stories au format standard : « En tant que [rôle], je veux [action] afin que [résultat]. » Je lui demande aussi de signaler les critères d'acceptation pour tout ce qui n'est pas trivial, car « en tant que toiletteur, je veux bloquer du temps de vacances » comporte un nombre surprenant de cas limites (des blocs récurrents ? quel fuseau horaire ? notifie-t-il les clients ayant des réservations existantes ?).
Quelques points sur lesquels j'insiste :
- Les stories doivent être rédigées pour un persona spécifique, pas un « utilisateur » générique
- Chaque story obtient une estimation de complexité approximative (S/M/L, rien de plus granulaire à ce stade)
- Tout ce qui est dans le panier « L » est signalé pour une décomposition ultérieure avant d'être intégré à Jira
Ce dernier point compte. Une story L lors d'une réunion de planification de sprint est essentiellement une grenade. Faire en sorte que Claude les identifie tôt signifie que nous avons une conversation avant que quelqu'un ne commence à construire.
---
Où je trace la ligne avec Claude
Je veux être honnête à ce sujet, car je vois beaucoup de commentaires enthousiastes selon lesquels l'IA fait tout maintenant.
Claude n'est pas bon pour prendre des décisions. Il est excellent pour présenter les options et les compromis, mais la décision réelle de savoir s'il faut construire un système de notification personnalisé ou utiliser Novu (que nous avons utilisé sur trois projets et que nous recommanderions) nécessite toujours quelqu'un qui connaît le projet, le client et les capacités de l'équipe.
J'ai aussi trouvé qu'il était peu fiable sur tout ce qui implique des versions de bibliothèques spécifiques ou des comportements d'API de niche. Pour les discussions d'architecture générale, c'est correct. Pour « cette version spécifique de WPGraphQL gérera-t-elle ce modèle de requête spécifique sous charge », je préférerais tester que faire confiance.
Et honnêtement ? L'invocation elle-même demande du talent. Un junior de mon équipe a essayé d'utiliser le même flux de travail et a obtenu des specs médiocres en retour, car le encadrement des contraintes et des rôles n'était pas assez strict. L'outil amplifie celui qui l'utilise. Ce n'est pas une critique, juste la peine d'être réaliste.
---
Organiser la sortie en document vivant
La spec que Claude produit n'est pas l'artefact final. C'est une entrée.
Mon livrable réel au client est un document Notion qui est construit à partir de la sortie Claude mais réorganisé dans un format qui a du sens pour l'approbation. Généralement :
- Résumé exécutif (3-4 phrases, pas de jargon)
- Périmètre (ce qui est inclus, ce qui est explicitement exclu)
- Personas utilisateur (2-3 max, au-delà c'est du bruit à ce stade)
- Flux principaux (écrits sous forme d'étapes numérotées, pas en prose)
- Tableau des fonctionnalités (colonnes : fonctionnalité, MVP ou phase 2, effort estimé, responsable)
- Questions ouvertes (tout ce qui bloque une décision, avec une personne responsable de la réponse)
- Risques et atténuations
Cette section des questions ouvertes, je l'ai commencé après un projet en 2020 qui a mal tourné parce que tout le monde supposait que quelqu'un d'autre avait établi la politique de conservation des données. Assigner une personne à chaque question ouverte signifie que cela ne reste pas indéfiniment suspendu.
Le doc Notion est partagé avec le client, il commente directement dedans, et on fait un appel de 45 minutes pour le parcourir. Rien ne va chez un développeur tant que chaque question ouverte n'a pas de réponse.
---
The Actual Time Savings, Honestly Stated
Avant ce workflow, une spec pour un projet de complexité moyenne (disons, un portail d'adhésion ou une boutique e-commerce personnalisée) me prenait une journée et demie. Écrire, douter, réécrire. Envoyer un brouillon à un collègue, recevoir des commentaires, les intégrer.
Maintenant, c'est plus proche de deux à trois heures pour le brouillon assisté par Claude, puis peut-être une heure supplémentaire d'édition humaine et de polissage orienté client. Disons trois à quatre heures au total.
Ce n'est pas une économie négligeable sur une année. Chez Seahawk, on livre des specs sur peut-être deux ou trois projets par mois. Même en étant conservateur, c'est 50-70 heures par an que je ne passe pas à écrire des specs de première version à partir de zéro.
Mais le vrai gain, honnêtement, c'est la qualité. La relecture contradictoire en particulier détecte des choses que j'aurais ratées. L'identification des hypothèses au départ signifie que les appels de découverte sont plus productifs parce qu'on discute de vraies décisions, pas moi en train de me battre pour combler des lacunes que je n'avais pas remarquées.
---
FAQ
Est-ce que ce workflow fonctionne aussi bien pour les outils internes que pour les projets clients ?
Oui, et parfois ça marche même mieux pour les trucs internes parce que tu connais l'utilisateur mieux que n'importe quel brief client ne peut te le dire. J'ai utilisé essentiellement le même processus quand on spécifiait l'outil de suivi du temps interne de Seahawk l'année dernière. L'input de contrainte était facile parce que je connaissais le budget (£0 en dépenses externes, un développeur, trois semaines) et les personas c'étaient littéralement des gens au bureau.
Un fondateur non-technique peut-il utiliser ça sans un développeur ?
Jusqu'à un certain point. L'identification des hypothèses et les étapes de story utilisateur fonctionnent très bien sans connaissances techniques. Où ça devient compliqué c'est la relecture contradictoire et l'estimation d'effort. Tu as besoin d'un peu d'expérience pour savoir quand Claude sous-estime la complexité. Si tu n'es pas technique, fais cette étape avec quelqu'un qui a livré du logiciel avant, même si c'est juste un appel d'une heure.
Comment tu gères l'information client confidentielle en utilisant Claude ?
J'anonymise tout ce qui est sensible avant que ça aille dans un prompt. Les noms clients deviennent « [Client] », toute donnée personnelle identifiable est supprimée. Je n'utilise Claude via l'API que pour les trucs vraiment sensibles, où les termes de traitement des données d'entreprise d'Anthropic s'appliquent, plutôt que le produit grand public. Ça vaut le coup de lire la politique d'utilisation d'Anthropic avant de décider ce qui convient à ton contexte.
La spec survit-elle toujours au premier contact avec les développeurs ?
Non. Et elle ne devrait pas. La spec est un mécanisme de forçage pour avoir les bonnes conversations tôt, pas un contrat qui fige la réflexion. Ce que je dis aux clients c'est : la spec c'est une compréhension partagée de ce qu'on construit aujourd'hui. Ça va changer. Ce qu'elle fait c'est rendre ces changements visibles et délibérés plutôt qu'accidentels.
---
Une spec n'est pas un document. C'est un argument. Tu argues que tu comprends le problème assez bien pour construire quelque chose qui vaut le coup de construire. Claude ne fait pas cet argument pour toi. Mais c'est un partenaire remarquablement utile pour te battre pendant que tu figures ce que tu veux vraiment dire.
Ça vaut bien deux heures du temps de n'importe qui.