Pour analyser une user story avec l’IA sans inventer, demandez d’abord quatre sorties séparées : faits sourcés, ambiguïtés, contradictions et informations manquantes. Transformez ensuite les inconnues en questions destinées aux responsables métier. Les critères d’acceptation et les cas de test ne doivent être rédigés qu’après validation. Cette séquence conserve la traçabilité et empêche une formulation plausible du modèle de devenir silencieusement une règle produit.
Pourquoi une user story ne suffit pas toujours pour concevoir les tests
Une user story exprime une valeur attendue dans un format concis. Elle ne contient pas nécessairement toutes les règles, exceptions, données, dépendances et réponses aux erreurs nécessaires à la conception des tests.
Une user story désigne une description brève d’un besoin formulée du point de vue d’un utilisateur ou d’une partie prenante. Sa concision facilite la conversation ; elle ne garantit pas qu’elle soit directement testable.
Un critère d’acceptation désigne une condition convenue permettant de déterminer si une fonctionnalité répond au besoin attendu. Pour être testable, le critère doit décrire un résultat observable et éviter les termes non mesurables comme « rapide », « intuitif » ou « sécurisé » sans définition supplémentaire.
Une condition de test désigne un élément d’un composant ou d’un système qui peut être vérifié par un ou plusieurs cas de test. Une règle de remboursement, une limite de saisie ou une transition de statut peuvent devenir des conditions de test après validation.
L’IA peut accélérer l’extraction et la mise en forme. Son principal danger est de combler une lacune avec une règle fréquente dans d’autres produits, mais absente du produit concerné.
Les quatre catégories à exiger dans l’analyse
Fait sourcé
Un fait est explicitement présent dans une source identifiée. Il doit être recopié ou paraphrasé sans élargir sa portée, avec un identifiant de document et un passage vérifiable.
Ambiguïté
Une ambiguïté admet plusieurs interprétations raisonnables. « Le remboursement est traité rapidement » ne permet pas de connaître le délai maximal, le point de départ du délai ni le statut visible pendant le traitement.
Contradiction
Une contradiction apparaît lorsque deux sources applicables imposent des résultats incompatibles. Le modèle peut la signaler ; il ne doit pas choisir la source gagnante sans règle de priorité.
Information manquante ou hypothèse
Une information manquante empêche de décider un résultat attendu. Une hypothèse est une proposition explicite destinée à être confirmée, jamais une règle utilisable comme oracle tant qu’elle ne l’est pas.
| Catégorie | Question de contrôle | Sortie attendue | Utilisable directement comme attendu ? |
|---|---|---|---|
| Fait sourcé | Où est-ce écrit ? | règle + référence | oui, si la source est autorisée et applicable |
| Ambiguïté | Quelles interprétations restent possibles ? | terme + impacts + question | non |
| Contradiction | Quelles sources s’opposent ? | passages incompatibles | non |
| Information manquante | Que faut-il savoir pour tester ? | question + décision requise | non |
| Hypothèse | Quelle proposition doit être confirmée ? | proposition étiquetée | non |
La méthode en 4 étapes : faits, questions, validation, critères
Étape 1 — Extraire les faits sans les interpréter
Objectif : créer une base de travail fidèle aux documents.
Action : identifier les acteurs, déclencheurs, préconditions, données, règles, résultats visibles, exceptions et dépendances. Exiger une référence pour chaque élément.
Résultat attendu : un tableau d’éléments explicites et sourcés.
Erreurs à éviter : ajouter une règle « habituelle » ; confondre un exemple avec une règle générale ; utiliser le titre d’une story pour préciser un détail absent du corps.
Étape 2 — Détecter ambiguïtés, contradictions et dépendances
Objectif : rendre visibles les obstacles à la conception.
Action : rechercher les termes non mesurables, les quantificateurs vagues, les états non définis, les erreurs sans comportement attendu, les règles de priorité manquantes et les systèmes externes.
Résultat attendu : une liste d’inconnues avec leur impact potentiel sur les tests.
Erreurs à éviter : reformuler l’ambiguïté sans la résoudre ; inventer une valeur limite ; traiter une dépendance externe comme toujours disponible.
Étape 3 — Poser les questions et documenter les décisions humaines
Objectif : convertir les lacunes en décisions explicites.
Action : formuler des questions fermées ou orientées décision, les classer par risque et les adresser au Product Owner, métier, UX, sécurité ou architecture selon le sujet.
Résultat attendu : un journal de décisions daté avec auteur, réponse et source mise à jour.
Erreurs à éviter : poser une question trop large ; accepter une réponse orale sans trace pour une règle critique ; demander à l’IA d’arbitrer entre deux responsables.
Étape 4 — Rédiger les critères et concevoir la couverture
Objectif : transformer les décisions validées en conditions observables.
Action : rédiger des critères atomiques, relier chacun à sa source, choisir une technique de conception et produire les cas avec leur couverture.
Résultat attendu : une chaîne source → décision → critère → condition → cas de test.
Erreurs à éviter : rédiger les critères avant les réponses ; regrouper plusieurs règles dans un attendu impossible à diagnostiquer ; supprimer les identifiants pendant la génération.
La série ISO/IEC/IEEE 29119 relie processus de test, documentation et techniques de conception. La partie ISO/IEC/IEEE 29119-3:2021 décrit des modèles de documentation de test, tandis que la partie 29119-4:2021 définit des techniques de conception. Ces normes ne rendent pas une sortie d’IA valide par elles-mêmes ; elles fournissent des repères pour structurer le travail.
Questions à poser pour rendre une story testable
Une bonne question réduit une incertitude qui change réellement la couverture ou le verdict.
Sur le périmètre
- Quels utilisateurs, pays, canaux et versions sont concernés ?
- Quels cas sont explicitement hors périmètre ?
- La règle s’applique-t-elle aux données existantes ou seulement aux nouvelles ?
Sur les données
- Quels champs sont obligatoires, facultatifs ou conditionnels ?
- Quelles valeurs, unités, tailles et combinaisons sont valides ?
- Que se passe-t-il pour une valeur vide, inconnue ou déjà utilisée ?
Sur les états et erreurs
- Quel est l’état initial et quels états finaux sont possibles ?
- Que voit l’utilisateur en cas d’échec ou d’indisponibilité ?
- L’action est-elle rejouable, annulable ou idempotente ?
Sur le temps et les dépendances
- Quand le délai commence-t-il et quand est-il considéré respecté ?
- Quel système externe intervient ?
- Quel comportement est attendu en cas de délai dépassé, erreur ou réponse partielle ?
Sur la preuve
- Quel élément observable démontre la réussite ?
- Quelle source décide du résultat attendu ?
- Quelle trace peut être utilisée sans exposer de donnée sensible ?
Prompt d’analyse d’une user story
RÔLE
Tu assistes un test analyst. Tu extrais et structures ; tu ne décides aucune règle métier.
SOURCES
- S1 : user story, source de besoin mais potentiellement incomplète.
- S2 : critères validés, source d’autorité pour les résultats attendus.
- S3 : glossaire validé.
- S4 : maquette informative.
TÂCHE
1. Extrais les faits explicites avec source et passage.
2. Liste séparément les ambiguïtés.
3. Liste les contradictions entre sources.
4. Liste les informations manquantes et dépendances.
5. Pour chaque élément, propose une question et explique son impact sur les tests.
CONTRAINTES
- N’utilise aucune connaissance externe.
- N’invente aucune valeur, exception ou règle.
- Ne rédige pas de critère d’acceptation tant que des décisions restent ouvertes.
- Marque « indéterminé » si les sources ne permettent pas de conclure.
FORMAT
Type | élément | source/passage | impact test | question | responsable suggéré
Le responsable suggéré est une aide d’aiguillage, pas une attribution d’autorité. L’équipe reste libre de modifier le circuit de décision.
Exemple hypothétique 1 — User story de remboursement
Entrée
En tant que client, je veux être remboursé rapidement lorsque ma commande est annulée afin de récupérer mon argent. Les remboursements passent par le prestataire de paiement.
Analyse attendue
| Type | Élément | Impact test | Question |
|---|---|---|---|
| fait | une annulation peut déclencher un remboursement | définir le déclencheur | quelles annulations sont éligibles ? |
| ambiguïté | « rapidement » | aucun verdict temporel possible | quel délai, à partir de quel événement ? |
| dépendance | prestataire de paiement | scénarios d’erreur et attente | quel statut si le prestataire ne répond pas ? |
| information manquante | moyens de paiement | partitions inconnues | quels moyens suivent ce parcours ? |
| information manquante | nouvel essai | couverture des pannes | la reprise est-elle automatique ou manuelle ? |
Le modèle ne doit pas proposer « remboursement sous 48 heures » sans source. Après validation des réponses, le testeur peut concevoir des partitions par moyen de paiement, des transitions par statut et des cas d’indisponibilité du prestataire.
Exemple hypothétique 2 — Création de compte et maquette partielle
La story demande un compte avec e-mail et mot de passe. La maquette montre un champ téléphone, tandis qu’un document ancien le présente comme obligatoire. Aucun statut de version n’est fourni.
L’analyse doit signaler :
- un fait : e-mail et mot de passe apparaissent dans la story ;
- une observation : le téléphone apparaît dans la maquette ;
- une contradiction potentielle : obligation dans un ancien document, absence dans la story ;
- une question de priorité : quelle source et quelle version font foi ?
Avant la réponse, aucun critère ne doit imposer ou interdire le téléphone. Après décision, le journal conserve l’auteur et la date, le critère reçoit un identifiant, puis les cas positifs et négatifs sont reliés à cette règle.
Construire une matrice de traçabilité utile
La traçabilité désigne la capacité à établir et suivre des relations entre des artefacts, par exemple entre une exigence et les tests qui la couvrent. Elle permet d’expliquer pourquoi un cas existe et de mesurer l’impact d’un changement.
| Source | Décision | Critère | Condition de test | Cas | Statut |
|---|---|---|---|---|---|
| US-12 §2 | DEC-07 | AC-12.1 | remboursement carte accepté | TC-101, TC-102 | validé |
| US-12 §3 | ouverte | — | délai de remboursement | — | bloqué |
La seconde ligne est aussi importante que la première : elle rend visible une couverture impossible tant que la décision n’est pas prise. Remplir artificiellement les cellules masquerait le risque.
Erreurs fréquentes lors de l’analyse d’exigences par IA
Générer les critères dans la même requête que l’analyse
Cette chaîne encourage le modèle à résoudre ses propres questions. Séparez l’extraction, la décision et la rédaction en étapes avec une validation humaine entre elles.
Demander « toutes les ambiguïtés » sans contexte de risque
Le résultat peut devenir une liste interminable de détails sans effet. Demandez l’impact sur le verdict, les données, les états ou la couverture et priorisez les questions qui bloquent une décision.
Accepter une question qui contient déjà la réponse
« Le remboursement doit-il être effectué sous 48 heures ? » introduit une valeur sans provenance. Demandez d’abord « quel est le délai maximal et quel événement le déclenche ? ».
Traiter la maquette comme une source métier
Une maquette montre des composants ; elle ne définit pas automatiquement leur caractère obligatoire, leur validation ou leurs effets. Déclarez son statut et faites confirmer les règles par l’autorité adéquate.
Supprimer les questions une fois résolues
Sans journal de décision, l’équipe perd l’origine du critère et peut rouvrir la même discussion. Conservez la question, la réponse, l’auteur, la date et la version de la source mise à jour.
Critères pour choisir un outil ou un modèle
Le meilleur choix dépend moins d’un classement général que du contexte du projet.
| Critère | Pourquoi il compte | Vérification pratique |
|---|---|---|
| fidélité aux sources | évite les règles inventées | jeu de stories avec réponses connues |
| gestion des longues entrées | utile pour plusieurs documents | test de récupération des passages décisifs |
| sortie structurée | facilite la traçabilité | validation de schéma et champs obligatoires |
| confidentialité | protège les exigences et données | contrat, conservation, accès, région, entraînement |
| stabilité | limite les variations | répétitions contrôlées et versionnement |
| intégration | réduit les copies manuelles | API, export, gestion des identifiants |
| coût de revue | détermine la valeur réelle | temps humain et corrections par story |
Conclusion
Une bonne analyse assistée par IA ne transforme pas les inconnues en réponses : elle les rend décidables. Commencez par séparer faits, ambiguïtés, contradictions et manques, puis placez une validation humaine avant tout critère ou cas de test. Pour appliquer ce protocole à un backlog réel, vous pouvez demander une revue d’analyse de test.