Concevoir : besoins et conception en une session

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Faire produire par Claude une spécification de besoins et de conception à partir d’un intent.md
• Faire appliquer les politiques de l’organisation pendant la rédaction, et non des semaines plus tard

Ce qui change

Traditionnellement, besoins et conception sont deux phases menées par deux équipes : des analystes formalisent l’idée en exigences, puis des designers les retraduisent en conception. La séparation existe pour la responsabilité, mais elle est lente et elle perd de l’information.

Dans un cycle AI-native, une fois l’intent.md accepté, Claude produit un spec.md qui couvre les deux, contraint par les skills de l’organisation — marque, sécurité, conformité, expérience utilisateur — et qui signale les points de tension. Le product owner relit la spécification ; il ne l’écrit pas. Il peut aussi maquetter le parcours dans Claude Design à partir de l’intention, puis l’exporter vers Claude Code.

Pour démarrer

• Prérequis : un intent.md, et les politiques de marque, de sécurité, de conformité et d’UX écrites sous forme de skills (leçon 6).
• Infrastructure : un product owner avec un accès à Claude ; aucune compétence d’ingénierie n’est nécessaire.

Mise en œuvre

1. Donnez l’intent.md à Claude avec une consigne du type : « Produis une spécification de besoins et de conception pour intégrer cette intention à notre base de code existante. Applique les skills disponibles pour respecter nos règles de marque, de sécurité et d’UX. Documente-la entièrement dans spec.md. Décris clairement les points de tension, en particulier quand deux politiques se contredisent. »
2. Pour aller plus loin, automatisez : la fusion d’un intent.md dans le lieu des intentions déclenche une tâche non interactive qui produit la spécification avec les skills chargées et la propose en pull request (la leçon 12 décrit la mécanique). La première intervention du product owner devient la relecture.
3. Relisez : chaque question ouverte de l’intention est-elle traitée ou reportée ? Traitez d’abord les points de tension signalés : ce sont ceux qu’un analyste aurait fait remonter. Le product owner les règle avec le responsable de chaque politique avant que les développeurs ne voient la spécification.
4. Enregistrez spec.md à côté de intent.md : la paire de fichiers garde la trace de ce qui a été demandé et de ce qui a été décidé.

Exemple : extrait de spec.md

## Exigences
- E1. Un adhérent connecté voit l'état, la prochaine étape et une date estimée de chaque remboursement en cours.
- E2. L'état prend l'une de quatre valeurs : reçu, en traitement, accepté, payé.
- E3. La réponse ne contient que ces trois champs.

## Points de tension
1. La skill « espace-adherent-ux » exige une date sur chaque statut ; la skill « ton-de-marque »
   interdit d'annoncer une date de paiement comme un engagement. Je ne peux pas satisfaire les deux
   telles qu'écrites. Proposition : libellé « Date estimée ». Responsable : conformité.
2. L'ancien système de remboursement accepte 50 requêtes par seconde ; aucun test de charge n'a été fait.
   Responsable : équipe du système de remboursement.

Les exigences sont numérotées pour que le plan et la revue puissent les citer.

Gouvernance

Au lieu de découvrir les conflits de politiques en revue, des semaines plus tard, la politique en vigueur est lue et appliquée pendant la rédaction. La spécification, la consigne qui l’a produite et les versions des skills utilisées sont versionnées. Le product owner signe la spécification et transmet les points de tension aux responsables nommés.

Mesurer

• Indicateur avancé : le délai entre le commit de l’intent.md et celui du spec.md pour le même changement, comparé à l’ancien cycle besoins plus conception.
• Indicateur retardé : les reprises d’exigences après le début de la construction, c’est-à-dire les commits de spec.md postérieurs au premier plan.md du même changement.

À vous de jouer

Une spécification en une session. Reprenez un intent.md accepté. Demandez à Claude une spécification de besoins et de conception qui numérote les exigences et signale explicitement les points de tension entre vos règles. Si vous n’avez pas encore de skills, donnez-lui deux politiques écrites, par exemple une règle de marque et une règle de sécurité. Relisez d’abord les tensions : qui, dans votre organisation, devrait trancher chacune ?

Sources officielles : Requirements and design (Claude Academy) · The AI-native SDLC playbook — Stage 2: Design · Skills

Points clés à retenir

• Claude transforme l’intention en spec.md, besoins et conception ensemble, contraint par les skills de l’organisation
• Les points de tension entre politiques sont signalés pendant la rédaction, avec un responsable pour chacun
• Le product owner relit et signe ; il n’écrit plus la spécification
• intent.md et spec.md côte à côte : ce qui a été demandé, et ce qui a été décidé