Développement Piloté par l'Intention
Produire des critères d'acceptation utiles sans transformer la spécification en cérémonie. Inspectez d'abord le contexte disponible, exposez l'ambiguïté réelle et choisissez des méthodes de vérification adaptées au travail et à son risque.
Quand Activer
- L'utilisateur demande de clarifier une fonctionnalité, définir des critères d'acceptation ou dérisquer un changement avant l'implémentation.
- La demande touche la sécurité, l'authentification, les données persistantes, les migrations, les API externes ou la conformité.
- L'utilisateur souhaite préparer un artefact de transmission pour un autre agent ou une autre équipe.
- La demande est suffisamment ambiguë pour que le résultat attendu ne soit pas encore observable ou testable.
- L'utilisateur invoque explicitement cette compétence avec
/intent-driven-development.
Ne pas activer pour les modifications triviales, les corrections simples d'une ligne, les sessions de débogage actif, les demandes de revue de code ou les demandes d'implémentation dont les conditions d'acceptation sont déjà claires.
Comment Cela Fonctionne
- Inspecter d'abord le contexte – lit le dépôt, la documentation, les schémas et l'infrastructure de test pour obtenir des faits techniques avant de poser une question, en traitant les contraintes produit/métier comme quelque chose que seul l'utilisateur ou un artefact produit peut fournir.
- Choisir la profondeur – sélectionne une Capture Rapide (3 à 7 critères, risque faible/moderé) ou un Brief d'Acceptation Complet (sécurité, données, migration, changements transverses) en fonction du profil de risque.
- Demander de manière minimale – ne pose que les questions dont les réponses ne peuvent être déduites et qui modifient considérablement le périmètre ou le comportement.
- Rédiger des critères observables – chaque AC-NNN décrit une condition de départ, un déclencheur, un résultat attendu, un effet de bord interdit, une méthode de vérification et une priorité ; pas de mots vagues comme « correctement » ou « de manière sécurisée » sans preuve.
- Poursuivre ou transmettre – pour les demandes claires sans risque bloquant, enregistrer les critères et continuer ; pour les changements risqués, présenter les blocages et attendre la confirmation.
- Gérer les révisions – si un AC échoue en cours d'implémentation en raison de contraintes architecturales, le marquer
[révisé], mettre à jour le périmètre ou la méthode de vérification, incrémenter le numéro de révision et représenter uniquement les critères modifiés.
Exemples
Capture Rapide – « Ajouter l'export CSV au tableau de bord »
Objectif : Les utilisateurs authentifiés peuvent télécharger les données du tableau de bord sous forme de fichier CSV.
Dans le périmètre : Export des lignes actuellement filtrées ; le nom du fichier inclut la date.
Hors périmètre : Exportations planifiées, livraison par e-mail, format Excel.
Hypothèses : Le nombre maximum de lignes est inférieur à 10 000 ; pas de données personnelles dans les champs exportés.
AC-001 : L'export génère un fichier avec les bons en-têtes
- Scénario : utilisateur authentifié, au moins une ligne de données visible
- Action : cliquer sur « Exporter CSV »
- Attendu : le navigateur télécharge un fichier avec les colonnes [id, name, created_at]
- Ne doit pas : exposer des champs internes ou des lignes appartenant à d'autres utilisateurs
- Vérification : test d'intégration automatisé + vérification manuelle du schéma
- Priorité : Requis
Déclencheur de Brief d'Acceptation Complet – « Migrer l'authentification utilisateur vers OAuth »
Changement d'authentification + dépendance externe + données de session existantes → Brief complet avec tableau de revue des risques, décisions bloquantes sur la stratégie d'invalidation de session et AC de rollback explicite.
Révision de spécification existante – l'utilisateur colle un PRD
La compétence le révise pour détecter les limites de périmètre manquantes, les exigences non vérifiables (« le système doit être rapide ») et les hypothèses silencieuses, puis renvoie des critères corrigés ou supplémentaires sans recommencer la découverte.
Règles de Fonctionnement
- Inspecter le dépôt, la documentation, le ticket, le design et le contexte de test disponibles avant de demander des faits techniques qui peuvent être découverts localement.
- Ne pas déduire les contraintes produit ou métier du code. Les règles métier, les obligations de conformité et réglementaires, les SLA contractuels, la tarification, la politique de conservation des données, la priorisation et les utilisateurs cibles ne peuvent pas être lus dans un dépôt. Les traiter comme inconnues jusqu'à ce que l'utilisateur les fournisse ou qu'un artefact produit faisant autorité (PRD, contrat, document de politique) les énonce. Les enregistrer comme des hypothèses à confirmer, jamais comme des faits découverts. Le dépôt vous indique comment le système se comporte aujourd'hui, pas ce que l'entreprise exige qu'il fasse.
- Ne poser que des questions dont les réponses sont nécessaires et ne peuvent être déduites en toute sécurité. Grouper les questions courtes et connexes lorsque cela permet d'économiser des échanges inutiles.
- Ne pas bloquer l'implémentation par défaut. Lorsque l'utilisateur a demandé d'implémenter un changement suffisamment clair, enregistrer brièvement les hypothèses clés et les critères d'acceptation, puis poursuivre ou les transmettre au flux de travail d'implémentation.
- Exiger une confirmation explicite de l'utilisateur avant de poursuivre uniquement lorsqu'une décision non résolue pourrait créer une exposition matérielle en matière de sécurité, une perte de données, une migration irréversible, une rupture contractuelle/d'API, un coût significatif ou une action externe destructive.
- Ne pas écrire un document d'acceptation dans un dépôt, modifier des fichiers de projet, créer une branche, effectuer un commit ou invoquer une autre compétence à moins que l'utilisateur ne le demande ou que le flux de travail actif du dépôt ne l'exige explicitement.
- Traiter les tests automatisés comme des preuves, pas comme la vérité. Préférer l'automatisation lorsqu'elle est fiable et proportionnée ; permettre une vérification manuelle UX, d'accessibilité, de sécurité, juridique ou opérationnelle lorsque l'automatisation ne peut pas établir le résultat.
- Ne jamais inclure de véritables secrets, identifiants, jetons, clés privées, données personnelles ou charges utiles de production sensibles dans les critères d'acceptation, les fixtures, les exemples ou les artefacts sauvegardés. Utiliser des valeurs expurgées ou synthétiques.
- Ne pas exécuter de tests destructifs, de migrations, de sondes de sécurité, de tests de charge, d'appels externes payants ou d'opérations sur des données de production/en direct sans autorisation explicite et un environnement sûr identifié.
- Lorsqu'un critère d'acceptation ne peut pas être satisfait en raison d'une contrainte architecturale, de plateforme ou externe découverte lors de l'implémentation, ne pas le supprimer silencieusement ni le contourner. Mettre à jour le critère concerné (le marquer
[révisé], énoncer la contrainte et ajuster le périmètre ou la méthode de vérification), incrémenter le numéro de révision et représenter uniquement les critères modifiés à l'utilisateur avant de continuer. Exiger une confirmation explicite uniquement si la révision modifie une décision bloquante ou réduit matériellement les garanties de sécurité ou de correction.
Choisir la Profondeur
Utiliser la plus petite sortie utile.
Capture Rapide
À utiliser pour un changement clair mais non trivial avec un risque faible ou modéré. Produire :
- Objectif
- Dans le périmètre / Hors périmètre
- Hypothèses
- 3 à 7 critères d'acceptation avec méthodes de vérification
- Questions bloquantes, le cas échéant
Ne pas retarder l'implémentation pour approbation à moins qu'un risque bloquant des règles de fonctionnement n'existe ou que l'utilisateur n'ait spécifiquement demandé une spécification d'abord.
Brief d'Acceptation Complet
À utiliser pour les changements ambigus, transverses, sensibles à la sécurité, modifiant des données, de migration, de conformité ou à coût élevé, ou lorsque l'utilisateur demande un artefact de transmission. Produire le modèle complet ci-dessous et demander une confirmation pour les décisions bloquantes non résolues avant une implémentation risquée.
Révision de Spécification Existante
Lorsque l'utilisateur a déjà fourni un PRD, un ticket, un plan ou des critères d'acceptation :
- Le réviser au lieu de recommencer la découverte.
- Identifier les limites de périmètre manquantes, les hypothèses dangereuses, les contradictions et les exigences non vérifiables.
- Renvoyer des critères corrigés ou supplémentaires.
Flux de Travail
1. Établir l'Objectif et le Risque
Extraire ou demander :
- Le résultat observable pour l'utilisateur ou le système.
- Les acteurs concernés.
- La principale conséquence d'échec.
- Les dimensions de risque qui s'appliquent réellement : sécurité/vie privée, données persistantes, compatibilité/API, migration, dépendances externes, coût, concurrence, performance, utilisabilité/accessibilité.
Éviter de poser des questions génériques sur des risques non pertinents.
2. Découvrir le Contexte
Lorsque des artefacts locaux ou connectés sont disponibles, inspecter uniquement ce qui est nécessaire :
- Comportement existant et fichiers ou interfaces directement liés.
- Conventions du dépôt, documentation produit, contrats API, schémas de données ou historique des migrations.
- Infrastructure de vérification existante et commandes réalistes.
- Dépendances externes et leur testabilité en isolation.
Enregistrer les faits découverts séparément des hypothèses fournies par l'utilisateur. Si le contexte ne peut pas être inspecté, indiquer ce qui est inconnu et poser des questions ciblées.
Le dépôt révèle des faits techniques – comment le système se comporte aujourd'hui, ses conventions et ses contrats. Il ne révèle pas les contraintes produit ou métier : règles métier, obligations de conformité et réglementaires, SLA contractuels, tarification, politique de conservation des données, priorisation et utilisateurs cibles. Ne jamais les reconstruire à partir du code ou des noms. Les capturer uniquement auprès de l'utilisateur ou d'un artefact produit faisant autorité, et les lister comme des hypothèses à confirmer jusqu'à lors.
3. Définir le Périmètre
Indiquer :
- Objectif : une phrase décrivant le résultat attendu.
- Dans le périmètre : comportement que ce changement doit livrer.
- Hors périmètre : travaux adjacents tentants explicitement exclus.
- Hypothèses : affirmations non encore prouvées.
- Décisions bloquantes : choix non résolus qui affectent matériellement la sécurité ou le comportement.
4. Rédiger les Critères d'Acceptation
Utiliser AC-001, AC-002, etc. Chaque critère doit décrire un comportement observable et une méthode de vérification appropriée ; les critères et les tests ne sont pas tenus de correspondre un à un.
Pour chaque critère applicable, inclure :
- Scénario ou condition de départ.
- Action ou déclencheur.
- Comportement observable attendu.
- Effet de bord interdit lorsqu'il est pertinent.
- Méthode de vérification : test automatisé, vérification d'intégration, revue UX manuelle, vérification d'accessibilité, revue de sécurité, vérification opérationnelle ou acceptation des parties prenantes.
- Contrainte d'environnement/de sécurité lorsque la vérification pourrait affecter les données, les services, les coûts ou les secrets.
- Priorité : requis, important ou optionnel.
Ne pas utiliser de mots tels que « correctement », « de manière sécurisée », « rapide », « intuitif » ou « robuste » sans définir des preuves observables ou les enregistrer comme un jugement de révision humaine.
5. Couvrir Uniquement les Limites Pertinentes
Considérer ces catégories, mais n'inclure que celles qui s'appliquent :
| Catégorie | Inclure quand | Preuve typique |
|---|---|---|
| Chemin heureux | Comportement nouveau ou modifié visible par l'utilisateur | Flux réussi ou transition d'état |
| Validation | Le changement accepte une entrée | Entrée malformée ou valeur limite rejetée sans mutation |
| Autorisation/vie privée | Les données ou actions ont des limites d'accès | Accès refusé et aucune divulgation sensible |
| Persistance/migration | Les données stockées ou les schémas changent | Lecture arrière, migration, rollback ou comportement de sauvegarde |
| Compatibilité | Les API, fichiers, événements ou clients publics peuvent être rompus | Le contrat ou l'élément existant reste valide |
| Récupération d'échec | Le réseau, le service ou l'échec asynchrone existe | Aucun état partiel ou comportement de nouvelle tentative/dégradation clair |
| Idempotence/concurrence | Les répétitions ou écritures simultanées sont plausibles | Aucun effet de bord en double ou état final invalide |
| Performance | Un seuil utilisateur ou service est important | Conditions de mesure définies et seuil |
| UX/accessibilité | Une personne interagit avec le résultat | Clavier, retour d'information, récupération d'erreur, revue visuelle/manuelle |
6. Présenter et Continuer
- Pour une demande de clarification/spécification, présenter le brief et demander des décisions uniquement sur les bloqueurs listés.
- Pour une demande d'implémentation sans bloqueur, présenter un résumé compact des critères dans le cadre du travail et continuer avec l'implémentation.
- Pour une transmission à un autre agent ou une autre équipe, inclure suffisamment de contexte et de détails de vérification pour qu'ils puissent agir sans inventer d'exigences.
- Sauvegarder le brief dans un fichier uniquement sur demande. Utiliser un chemin approuvé par le dépôt s'il existe ; sinon, demander ou indiquer la destination choisie avant d'écrire.
Modèle de Sortie
Utiliser ce modèle pour un Brief d'Acceptation Complet. Omettre les sections non pertinentes pour une Capture Rapide.
# Brief d'Acceptation : <Nom du Changement>
**Statut :** Brouillon | Approuvé | Implémenté | Vérifié
**Révision :** <numéro>
**Préparé pour :** <utilisateur/équipe/agent, si connu>
**Approbation requise avant travail risqué :** Oui | Non - <raison>
## Journal des Révisions
| Rév | Date | Critères modifiés | Raison |
| --- | --- | --- | --- |
| 1 | <date> | — | Brouillon initial |
## Objectif
<Une phrase de résultat observable.>
## Périmètre
**Dans le périmètre**
- <comportement inclus>
**Hors périmètre**
- <travail adjacent exclu>
## Contexte
**Faits découverts** (techniques, vérifiés à partir du dépôt ou de l'artefact)
- <comment le système se comporte aujourd'hui, conventions, contrats>
**Contraintes produit/métier** (fournies par l'utilisateur ou l'artefact produit, jamais déduites du code)
- <règle métier, obligation de conformité/SLA, politique de conservation, priorité, utilisateur cible – ou « aucun fourni pour l'instant »>
**Hypothèses**
- <affirmation non vérifiée à confirmer ou valider>
**Dépendances et contraintes**
- <service externe, convention locale, obligation de compatibilité, limite d'environnement>
## Revue des Risques
| Domaine de risque | S'applique ? | Traitement requis |
| --- | --- | --- |
| Sécurité/vie privée | Oui/Non | <expurgation, autorisation, revue, etc.> |
| Données persistantes/migration | Oui/Non | <compatibilité, sauvegarde, rollback, etc.> |
| Effets externes/coût | Oui/Non | <environnement de test/test/autorisation> |
| Compatibilité/API | Oui/Non | <contrat à préserver ou versionner> |
| UX/accessibilité | Oui/Non | <preuve manuelle ou automatisée> |
## Critères d'Acceptation
### AC-001 : <comportement observable>
- **Scénario :** <condition de départ>
- **Action :** <déclencheur unique>
- **Attendu :** <résultat observable>
- **Ne doit pas :** <effet de bord interdit, le cas échéant>
- **Vérification :** <méthode et preuve attendue>
- **Environnement/sécurité :** <contraintes, le cas échéant>
- **Priorité :** Requis | Important | Optionnel
## Décisions Bloquer
- [ ] <uniquement les décisions qui empêchent une progression sûre ou correcte>
## Plan de Vérification
| Critère | Preuve de vérification | Statut |
| --- | --- | --- |
| AC-001 | <test/vérification/revue commande ou type de preuve> | En attente |
Exemples Réussite/Échec
Utiliser ces exemples pour juger si la compétence a réellement produit un brief vérifiable, et non une prose de planification.
Un critère d'acceptation échoué
AC-001 : L'export fonctionne correctement et est sécurisé.
Échoue – « fonctionne correctement » et « sécurisé » ne sont pas observables, il n'y a pas de scénario, de déclencheur, de résultat attendu ni de méthode de vérification.
Un critère d'acceptation réussi
AC-001 : L'export génère un fichier CSV avec les colonnes d'en-tête [id, name, created_at] uniquement.
- Scénario : Utilisateur authentifié consultant le tableau de bord avec au moins une ligne de données.
- Action : Cliquer sur « Exporter CSV ».
- Attendu : Le navigateur télécharge un fichier nommé dashboard-<date>.csv.
- Ne doit pas : Inclure les colonnes [internal_id, created_by] ou les données d'autres utilisateurs.
- Vérification : Test d'intégration automatisé (voir spec/test/export_test.py) + vérification manuelle du schéma sur un échantillon.
- Priorité : Requis
Réussi – chaque élément est observable et vérifiable.
Document généré par la compétence Développement Piloté par l'Intention. Réviser et approuver avant une implémentation risquée.