L'agent Claude au service de votre produit

En tant que développeur, on commence à bien appréhender les différents outils IA à notre disposition, pourquoi pas en faire bénéficier nos équipes produit !

Dans cet article, nous allons créer un outil, un agent IA, actionnable facilement par notre équipe produit, Product Owner ou Product Manager (PM). Il s'agit d'un outil dont l'équipe pourra se servir au quotidien dans le but d'être guidée lors de la rédaction des User Story.

Ce sera un gain de temps et d'efficacité, ce qui permettra de se focus sur les tâches à plus forte valeur ajoutée.

Créons notre nouvel assistant IA

Génération du skill story-interview

Notre assistant a pour mission de questionner notre équipe produit sur un nouveau besoin afin de rédiger le contenu de notre User Story dans un format attendu et compris par l'ensemble de l'équipe.

Pour cela, on va créer un skill assez générique qui pourra être réutilisé dans d'autres projets. On lui fournira, en complément, des fichiers de référence qui donneront du contexte sur les besoins du projet en lui-même.

Notre skill va agir en 3 étapes : la première consistera à prendre connaissance des fichiers de référence, le but étant d'éviter de (re)questionner l'équipe produit à chaque création d'US. Puis viendra une interview, avec une liste de questions autour du besoin qui nous amènera à la dernière étape : la production de la Story.

Voici notre skill, que je vous invite à intégrer au dépôt du projet suivant le chemin : .claude\skills\story-interview\SKILL.md, on verra comment le rendre accessible à l'équipe produit plus tard dans l'article :

 1---
 2name: story-interview
 3description: Guide l'utilisateur dans une interview à questions fixes, posées une par une, pour transformer une idée en ticket de développement complet (User Story, Technical Story, Documentation ou Bug). À utiliser dès que l'utilisateur veut rédiger/spécifier un ticket, une User Story, une "US", une story technique, une tâche de documentation, un bug, ou tout élément de backlog — même s'il ne le formule pas explicitement ainsi (ex. "j'ai besoin d'un ticket pour...", "peux-tu spécifier la fonctionnalité X", "rédige-moi un bug pour...", "documente ce processus").
 4---
 5 
 6# Story Interview
 7 
 8## But
 9Transformer une idée en ticket complet, ancré dans le produit réel, et strictement conforme à la structure attendue par le projet.
10 
11## Avant de commencer
12Lire entièrement :
13- `.claude/skills/story-interview/references/product-context.md` — à quoi sert l'application, les personas, les fonctionnalités existantes.
14- `.claude/skills/story-interview/references/us-template.md` — la structure exacte que doit avoir le ticket final.
15 
16Ne jamais halluciner un persona ou une fonctionnalité : s'appuyer uniquement sur ce qui est documenté dans `.claude/skills/story-interview/references/product-context.md`. Si l'utilisateur mentionne un élément absent de ce fichier, le signaler et proposer de l'y ajouter plutôt que de l'inventer silencieusement.
17 
18## Déroulé de l'interview
19Poser les questions suivantes **une par une**, dans cet ordre, en attendant la réponse de l'utilisateur avant de passer à la suivante :
20 
211. **Type de ticket**
22   > "De quel type de ticket s'agit-il ?"
23   - **User Story** — fonctionnalité métier
24   - **Technical Story** — refacto, upgrade de dépendances, dette technique
25   - **Documentation** — docs, guides, READMEs
26   - **Bug** — correction d'un comportement incorrect
27 
282. **Utilisateur** — relire au préalable la section "Personas" de `.claude/skills/story-interview/references/product-context.md`
29   > "Qui est l'utilisateur principal de cette fonctionnalité ? (ex : un client, un administrateur, …)"
30 
313. **Action souhaitée**
32   > "Que veut-il pouvoir faire concrètement dans l'application ?"
33 
344. **Contexte métier** — relire au préalable la section "Fonctionnalités existantes" de `.claude/skills/story-interview/references/product-context.md`
35   > "Quel est le contexte métier autour de ce besoin ? (processus existant, contraintes, périmètre de l'application concernée…)"
36 
375. **Critères d'acceptation**
38   > "Quels sont les critères qui te permettront de dire que la fonctionnalité est conforme au besoin ? Liste les comportements attendus, les règles de gestion ou les cas particuliers importants."
39 
406. **Confirmation finale**
41   > "Voici ce que j'ai compris. Est-ce que tu veux modifier ou compléter quelque chose avant que je génère le ticket ?"
42 
43   Présenter un résumé structuré des réponses collectées (type de ticket, utilisateur, action, contexte, critères d'acceptation) et attendre la validation ou les corrections de l'utilisateur avant de continuer.
44 
45## Restitution finale
46Une fois la confirmation obtenue, générer le ticket en respectant **strictement** la structure définie dans `.claude/skills/story-interview/references/us-template.md` : mêmes sections, même ordre, mêmes intitulés. Remplir chaque section à partir des réponses validées, en tenant compte du type de ticket identifié à la question 1. Laisser inchangées les sections déjà pré-remplies par une instruction ou une note fixe dans le gabarit (par exemple un texte indiquant qu'elle sera complétée par une autre équipe).
47 
48Afficher le ticket final directement dans le chat, formaté en Markdown. Ne pas écrire de fichier.

Seconde étape : lui transmettre notre contexte produit

Nous voilà avec notre skill, on peut y voir qu'on fait mention de 2 fichiers qui sont references/product-context.md et references/us-template.md

Pour l'exercice, on va imaginer que le site des elePHPants enclenche une mutation en site d'e-commerce.

Quelques fonctionnalités basiques existent comme l'inscription, la commande, la gestion de stock. Et on imagine quelques personas comme un visiteur, une collectionneuse et un admin.

Voici notre fichier de référence product-context.md :

 1# Contexte produit — elephpant-store
 2 
 3## Objet de l'application
 4 
 5`elephpant-store` est un site e-commerce de vente d'éléphants PHP.
 6 
 7## Personas
 8 
 9### Alex — Visiteur anonyme
10- Parcourt le catalogue d'éléphants (nom, couleur, marque, prix) sans compte.
11- Doit s'inscrire pour pouvoir passer commande.
12 
13### Nadia — Client inscrit
14- Possède un compte (inscription requise).
15- Passe des commandes et consulte son historique.
16 
17### Marcel — Administrateur
18- Gère le catalogue d'éléphants (création, modification, suppression, consultation).
19- Gère le stock (quantités disponibles).
20- Pas de gestion des clients/commandes précisée à ce stade.
21 
22## Fonctionnalités existantes
23 
24- **CRUD éléphant** : un éléphant possède un nom, une couleur, une marque (optionnelle) et un prix. Création, lecture, mise à jour, suppression gérées côté admin.
25- **Gestion du stock** : l'administrateur gère les quantités disponibles par éléphant.
26- **Inscription** : un visiteur peut créer un compte pour devenir client inscrit.
27- **Commande** : un client inscrit peut passer commande sur le catalogue.

Définir le format de la Story

Ici, on va rester sur un format de Story classique, avec description du besoin, les éléments de contexte, une partie « Analyse technique » qui devra être remplie dans un second temps par l'équipe de développement et, enfin, une partie "Critères d'acceptation" sous forme de liste.

Le tout avec un titre qui respecte le format "qui", "quoi" et "pourquoi". Voilà pour notre fichier de référence us-template.md :

 1# Template : User Story
 2 
 3Ce fichier définit le format cible **exact** que Claude doit respecter scrupuleusement lors de la génération de la User Story.
 4 
 5---
 6 
 7## Format du fichier généré
 8 
 9```markdown
10# ETQ [utilisateur], JV [action/fonctionnalité], AD [bénéfice]
11 
12## Besoin
13 
14[Description claire et concise du besoin exprimé par l'utilisateur]
15 
16## Contexte
17 
18[Contexte métier de l'application relatif au besoin : processus existant, enjeux, périmètre]
19 
20## Analyse technique
21 
22[À compléter par l'équipe de développement]
23 
24## Critères d'acceptation
25 
26- [ ] Critère 1
27- [ ] Critère 2
28- [ ] ...
29 
30---
31 
32## Règles strictes à respecter
33 
34- Le titre suit **exactement** le format : `ETQ ... JV ... AD ...` (ETQ = "En tant que", JV = "Je veux")
35- Le titre est limité à **100 caractères maximum** — reformule de façon concise si nécessaire
36- Pas de champ "Priorité", "Complexité", "Story Points" ou équivalent — jamais
37- La section **Analyse technique** reste **vide** — ne pas la commenter, ne pas l'expliquer
38- Les critères d'acceptation sont **exclusivement métier** : comportements attendus, règles de gestion, cas limites fonctionnels
39- Aucun critère technique (ex : "l'API doit retourner un 200", "stocker en base de données")
40- Le fichier est livré en `.md` téléchargeable

Et maintenant c'est parti pour un test !

Notre outil est prêt, il reste à le transmettre à l'équipe produit. Pour ce faire, nous compressons le dossier « story-interview » et le transmettons à notre équipe produit.

À partir de maintenant, nous nous plaçons dans le contexte de l'équipe produit qui dispose d'un compte Claude et a donc accès aux conversations avec ce dernier via le site web.

Nous nous rendons sur la page de configuration des skills. Nous cliquons en haut à droite sur "Ajouter", puis sur "Téléverser une compétence".

On glisse notre zip et nous voilà avec notre nouvelle compétence !

On ferme la page de configuration et on retourne sur le chat, on clique sur le "+" en bas à gauche, puis sur "Compétences" et enfin sur "story-interview".

On remarque qu'on peut aussi invoquer directement notre skill, comme en CLI, avec /story-interview. C'est parti !

Ça commence plutôt bien, il nous demande le type de ticket qu'on souhaite faire :

Puis, l'utilisateur cible :

Pour le besoin, on va s'orienter vers la génération d'une notification lorsqu'une commande est finalisée et on va lui exprimer le contexte de notre application :

Là, je l'ai challengé un peu et je lui ai demandé de me proposer des critères d'acceptation. C'est sur ces 2 dernières étapes qu'utiliser le skill en CLI avec le code à portée de main permettrait à Claude d'être encore plus pertinent et autonome !

Claude nous propose un résumé de l'interview afin de vérifier que tout est ok :

Et enfin la génération de la Story, qu'il ne reste plus qu'à copier-coller dans notre outil de gestion de projet :

 1# ETQ client authentifié, JV être notifié lors de la finalisation de ma commande, AD suivre son statut
 2 
 3## Besoin
 4 
 5En tant que client authentifié, je souhaite recevoir une notification lorsqu'une commande que j'ai passée est finalisée, afin d'être informé de son statut sans avoir à consulter systématiquement mon profil.
 6 
 7## Contexte
 8 
 9Aujourd'hui, aucune notification n'existe dans l'application. Un client inscrit peut passer commande, et celle-ci apparaît dans son profil pour suivi. Cette fonctionnalité vient compléter ce processus existant en ajoutant une notification au moment de la finalisation, sans modifier le fonctionnement actuel de l'historique des commandes dans le profil.
10 
11## Analyse technique
12 
13[À compléter par l'équipe de développement]
14 
15## Critères d'acceptation
16 
17- [ ] Une notification est émise dès qu'une commande est finalisée (validée) par le client
18- [ ] La notification indique au minimum le numéro de commande et son statut
19- [ ] La notification est visible par le client authentifié qui a passé la commande
20- [ ] Si la commande échoue ou est annulée avant finalisation, aucune notification n'est émise
21- [ ] L'historique des commandes dans le profil client reste inchangé et continue de fonctionner comme aujourd'hui
22- [ ] Le client ne reçoit qu'une seule notification par commande finalisée (pas de doublon)

La suite ? Viser la lune !

À ce stade, nous pouvons déjà proposer un gain de temps phénoménal à notre équipe produit, tout en sachant qu'on peut encore améliorer le skill, car il pourrait être totalement autonome dans la création et dans la mise à jour du ticket sur votre outil.

Par exemple, pour une utilisation en CLI avec les issues de GitHub comme gestion de projet, c'est très simple d'indiquer au skill de passer par les commandes gh, si vous utilisez Gitlab, Jira, vous avez à minima des API à dispos (le MCP de Jira est souvent capricieux.), pour lesquelles vous pouvez agrémenter votre skill de script qu'il va pouvoir exécuter !

Concernant notre workflow de développement, la suite vous la voyez venir à 3 km, c'est un skill orienté équipe de développement, qui va répondre aux 2 besoins suivants : l'analyse technique et l'implémentation de la Story. Ce sera pour un prochain épisode !

Écrit par

William Suppo

Je mange du PHP au p'tit dej', et vous ?