Des specs aux tickets : Claude dans le cycle produit

Le meilleur usage des spécifications IA côté dev n’est pas d’écrire du code plus vite : c’est de découvrir les problèmes d’une spec avant qu’ils ne coûtent un sprint. Claude lit une spécification comme le fera le développeur qui l’implémente — littéralement — et en révèle les ambiguïtés, les cas limites absents et les contradictions pendant qu’elles ne coûtent encore qu’une reformulation. Puis il la découpe en tickets réellement actionnables : critères d’acceptation, cas d’erreur, dépendances.

Le résultat mesurable, c’est la chute des allers-retours : moins de « qu’est-ce qu’on fait si le champ est vide ? » posés en plein développement, moins de tickets rouverts parce que la demande avait deux lectures possibles, moins de démos où le produit découvre que le développeur a choisi l’autre interprétation.

Une spec floue coûte trois fois

La première fois en développement : le développeur bute sur un cas non prévu, interrompt, attend une réponse — ou tranche seul, dans le silence de la spec. La deuxième fois en revue ou en démo : l’interprétation choisie n’était pas la bonne, on rejoue le ticket. La troisième fois en production : le cas limite que personne n’avait écrit devient un bug signalé par un client.

Le plus frustrant est que ces défauts sont détectables à la lecture. Mais relire une spec en se mettant vraiment à la place de l’implémenteur est un exercice exigeant, que les équipes produit n’ont matériellement pas le temps de faire sur chaque document. C’est précisément un travail de lecture systématique — le terrain où l’IA excelle.

Chaque itération a aussi un coût invisible : le changement de contexte. Le développeur interrompu sur un cas ambigu ne perd pas cinq minutes — il perd le fil. Et le product manager sollicité en urgence arbitre mal, sans la vue d’ensemble qu’il avait au moment du cadrage. Beaucoup de mauvaises décisions de sprint naissent exactement là.

Le crible : ce que Claude demande à une spec

Concrètement, la spec passe un interrogatoire avant d’entrer en sprint. Les questions types :

• Chaque comportement décrit a-t-il un cas nominal, des cas d’erreur et des cas limites explicites — champ vide, doublon, droit manquant, service indisponible ?
• Deux lecteurs de bonne foi peuvent-ils comprendre deux choses différentes ? Chaque ambiguïté est signalée avec les deux lectures possibles.
• La spec contredit-elle un comportement existant du produit ou une autre spec en cours ? Les collisions sont listées avant l’implémentation.
• Que faut-il pour dire « terminé » ? Chaque exigence est reformulée en critères d’acceptation vérifiables.

Du document au ticket actionnable

Une fois la spec consolidée, le découpage en tickets devient un travail de structure que Claude exécute bien : des unités livrables indépendamment quand c’est possible, ordonnées par dépendances, chacune portant son contexte, ses critères d’acceptation et ses cas d’erreur. Le développeur ouvre un ticket et sait quoi faire — sans archéologie dans le document d’origine ni réunion de clarification.

Le découpage reste une proposition, pas un verdict : l’équipe le revoit en quelques minutes, fusionne ou resserre ce qui doit l’être. Ce qui prenait une réunion de préparation entière devient une relecture — et le rituel de planification retrouve son vrai rôle : arbitrer, pas déchiffrer.

Ce format a un second bénéfice, moins attendu : un ticket assez précis pour être implémenté sans question est aussi un ticket que Claude Code peut prendre en charge sous supervision. La qualité du cadrage amont détermine directement ce que l’IA peut exécuter en aval — les deux étages du cycle se renforcent.

Qui décide, à la fin ?

Le product manager, sans ambiguïté. Claude signale qu’un cas n’est pas couvert ; il ne décide pas de ce que le produit doit faire dans ce cas. Les arbitrages — périmètre, priorités, compromis d’expérience — restent humains, et c’est même l’intérêt du dispositif : le temps produit se déplace de la rédaction défensive vers la décision.

Le crible a d’ailleurs un effet pédagogique : au fil des relectures, les rédacteurs de specs intègrent les questions récurrentes et les anticipent. Les documents arrivent meilleurs — l’IA a relevé le niveau d’exigence de toute la chaîne, sans qu’une formation ait été nécessaire.

Dans le Programme Autonomie Claude, ce crible de spécification devient un skill d’équipe : la grille de relecture est adaptée aux standards de l’entreprise, versionnée, et appliquée de la même façon sur chaque document. Le cycle produit y gagne ce qui lui manque le plus : de la prévisibilité.