Que fait Développement Piloté par l'Intention ?
Produisez des critères d'acceptation utiles sans transformer la spécification en cérémonie. Inspectez d'abord le contexte disponible, exposez les ambiguïtés réelles, et choisissez des méthodes de vérification adaptées au travail et à ses risques.
Quand activer
- L'utilisateur demande de clarifier une fonctionnalité, de définir des critères d'acceptation ou de 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 transition 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 en une ligne, les sessions de débogage actives, les demandes de revue de code ou les demandes d'implémentation dont les conditions d'acceptation sont déjà claires.
Comment ça 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, tout en traitant les contraintes produit/entreprise comme des informations que seul l'utilisateur ou un artefact produit peut fournir
- Choisir la profondeur — sélectionne une Capture Rapide (3-7 critères, risque faible/moyen) ou un Brief d'Acceptation Complet (sécurité, données, migration, changements inter-systèmes) en fonction du profil de risque
- Demander de manière minimale — ne pose que des questions dont les réponses ne peuvent pas être déduites et qui changent matériellement 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 secondaire interdit, une méthode de vérification et une priorité ; pas de mots vagues comme "correctement" ou "sécurisé" sans preuve
- Poursuivre ou transférer — pour les demandes claires sans risques bloquants, enregistre les critères et continue ; pour les changements risqués, présente les bloqueurs et attend la confirmation
- Gérer les révisions — si un échec d'AC survient en cours d'implémentation en raison de contraintes architecturales, le marque
[révisé], met à jour le périmètre ou la méthode de vérification, incrémente le numéro de révision, et ne représente que 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.
Périmètre inclus : Export des lignes actuellement filtrées ; le nom du fichier inclut la date.
Hors périmètre : Export programmé, livraison par email, format Excel.
Hypothèses : Le nombre maximal de lignes est inférieur à 10 000 ; aucune donnée personnelle dans les champs exportés.
AC-001 : L'export génère un fichier avec les en-têtes corrects
- 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, nom, date_création]
- 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.
Revue de spécification existante — l'utilisateur colle un document de spécifications produit
La compétence le révise pour identifier les limites de périmètre manquantes, les exigences non vérifiables ("le système sera 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
- Inspectez le dépôt, la documentation, le ticket, la conception et le contexte de test disponibles avant de demander des faits techniques qui peuvent être découverts localement.
- N'inférez pas de contraintes produit ou commerciales à partir 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. Considérez-les comme inconnus jusqu'à ce que l'utilisateur les fournisse ou qu'un artefact produit faisant autorité (document de spécifications, contrat, document de politique) les énonce. Enregistrez-les comme des hypothèses marquées pour confirmation, jamais comme des faits découverts. Le dépôt vous dit comment le système se comporte aujourd'hui, pas ce que l'entreprise exige qu'il fasse.
- Ne posez que des questions dont les réponses sont nécessaires et ne peuvent pas être déduites en toute sécurité. Regroupez les questions courtes et connexes lorsque cela permet d'économiser des échanges inutiles.
- Ne bloquez pas l'implémentation par défaut. Lorsque l'utilisateur a demandé d'implémenter un changement suffisamment clair, enregistrez brièvement les hypothèses clés et les critères d'acceptation, puis poursuivez ou transmettez-les au workflow d'implémentation.
- Exigez une confirmation explicite de l'utilisateur avant de procéder uniquement lorsqu'une décision non résolue pourrait créer une exposition matérielle à la sécurité, une perte de données, une migration irréversible, une rupture contractuelle/API, un coût significatif ou une action externe destructive.
- N'écrivez pas de document d'acceptation dans un dépôt, ne modifiez pas les fichiers du projet, ne créez pas de branche, ne commitez pas et n'invoquez pas une autre compétence sauf si l'utilisateur le demande ou si le workflow actif du dépôt l'exige explicitement.
- Considérez les tests automatisés comme des preuves, pas comme une vérité. Préférez l'automatisation lorsqu'elle est fiable et proportionnée ; autorisez la vérification UX manuelle, d'accessibilité, de sécurité, juridique ou opérationnelle lorsque l'automatisation ne peut pas établir le résultat.
- N'incluez jamais de secrets réels, d'identifiants, de jetons, de clés privées, de données personnelles ou de charges utiles de production sensibles dans les critères d'acceptation, les fixtures, les exemples ou les artefacts enregistrés. Utilisez des valeurs expurgées ou synthétiques.
- N'effectuez pas de tests destructifs, de migrations, de sondes de sécurité, de tests de charge, d'appels externes payants ou d'opérations contre des données de production/environnement réel sans autorisation explicite et un environnement sécurisé identifié.
- Lorsqu'un critère d'acceptation ne peut pas être satisfait en raison d'une contrainte architecturale, de plateforme ou externe découverte pendant l'implémentation, ne le supprimez pas silencieusement ni ne le contournez. Mettez à jour le critère concerné (marquez-le
[révisé], indiquez la contrainte et ajustez le périmètre ou la méthode de vérification), incrémentez le numéro de révision et ne représentez que les critères modifiés à l'utilisateur avant de continuer. Exigez une confirmation explicite uniquement si la révision modifie une décision bloquante ou réduit matériellement les garanties de sécurité ou d'exactitude.
Choisir la profondeur
Utilisez la plus petite sortie utile.
Capture Rapide
À utiliser pour un changement clair mais non trivial avec un risque faible ou modéré. Produisez :
- Objectif
- Périmètre inclus / 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 retardez pas l'implémentation pour approbation sauf si un risque bloquant des règles de fonctionnement existe ou si l'utilisateur a spécifiquement demandé une spécification en premier.
Brief d'Acceptation Complet
À utiliser pour les changements ambigus, inter-systèmes, sensibles à la sécurité, modifiant les données, de migration, de conformité ou à coût élevé, ou lorsque l'utilisateur demande un artefact de transition. Produisez le modèle complet ci-dessous et demandez une confirmation pour les décisions bloquantes non résolues avant une implémentation risquée.
Revue de Spécification Existante
Lorsque l'utilisateur a déjà fourni un document de spécifications produit, un ticket, un plan ou des critères d'acceptation :
- Révisez-le au lieu de recommencer la découverte.
- Identifiez les limites de périmètre manquantes, les hypothèses dangereuses, les contradictions et les exigences non vérifiables.
- Renvoyez des critères corrigés ou supplémentaires.
Workflow
1. Établir l'objectif et le risque
Extrayez ou demandez :
- Le résultat observable pour l'utilisateur ou le système.
- Les acteurs concernés.
- La principale conséquence en cas 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é.
Évitez 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, inspectez 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 si elles sont testables de manière isolée.
Enregistrez les faits découverts séparément des hypothèses fournies par l'utilisateur. Si le contexte ne peut pas être inspecté, dites ce qui est inconnu et posez 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 commerciales : règles métier, obligations de conformité et réglementaires, SLA contractuels, tarification, politique de conservation des données, priorisation et utilisateurs cibles. Ne les reconstruisez jamais à partir du code ou des noms. Ne les capturez qu'à partir de l'utilisateur ou d'un artefact produit faisant autorité, et listez-les comme des hypothèses à confirmer jusqu'à ce moment-là.
3. Définir le périmètre
Indiquez :
- Objectif : une phrase décrivant le résultat attendu.
- Périmètre inclus : comportement que ce changement doit fournir.
- Hors périmètre : travail adjacent tentant explicitement exclu.
- 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
Utilisez 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, incluez :
- Scénario ou condition de départ.
- Action ou déclencheur.
- Comportement observable attendu.
- Effet secondaire interdit lorsqu'il est significatif.
- 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/sécurité lorsque la vérification pourrait affecter les données, les services, le coût ou les secrets.
- Priorité : requis, important ou facultatif.
N'utilisez pas de mots tels que "correctement", "sécurisé", "rapide", "intuitif" ou "robuste" sans définir de preuve observable ou les enregistrer comme un jugement à réviser par un humain.
5. Couvrir uniquement les limites pertinentes
Tenez compte de ces catégories, mais n'incluez que celles qui s'appliquent :
| Catégorie | Inclure quand | Preuve typique |
|---|---|---|
| Chemin heureux | Nouveau comportement visible par l'utilisateur ou modifié | Workflow 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 publiques, fichiers, événements ou clients peuvent être rompus | Le contrat ou le fixture existant reste valide |
| Récupération après é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 les écritures simultanées sont plausibles | Aucun effet secondaire en double ou état final invalide |
| Performance | Un seuil utilisateur ou de 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ésentez le brief et demandez des décisions uniquement sur les bloqueurs listés.
- Pour une demande d'implémentation sans bloqueur, présentez un résumé compact des critères dans le cadre du travail et continuez avec l'implémentation.
- Pour un transfert à un autre agent ou équipe, incluez suffisamment de contexte et de détails de vérification pour qu'ils puissent agir sans inventer d'exigences.
- Enregistrez le brief dans un fichier uniquement sur demande. Utilisez un chemin approuvé par le dépôt lorsqu'il existe ; sinon, demandez ou indiquez la destination choisie avant d'écrire.
Modèle de sortie
Utilisez ce modèle pour un Brief d'Acceptation Complet. Ommettez les sections non pertinentes pour la 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
**Périmètre inclus**
- <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/entreprise** (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 "aucune fournie pour le moment">
**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 bac à sable/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 secondaire interdit, le cas échéant>
- **Vérification :** <méthode et preuve prévue>
- **Environnement/sécurité :** <contraintes, le cas échéant>
- **Priorité :** Requis | Important | Facultatif
## Décisions bloquantes
- [ ] <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 | <commande de test/vérification/revue ou type de preuve> | En attente |
Exemples de réussite/échec
Utilisez-les 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é.
Échoué — "fonctionne correctement" et "sécurisé" ne sont pas observables, il n'y a pas de scénario, de déclencheur, de résultat attendu ou de méthode de vérification.
Un critère d'acceptation réussi
AC-001 : L'export CSV inclut toutes les colonnes du tableau visible
- Scénario : utilisateur connecté avec le rôle "analyste", tableau de bord des ventes affiché, filtre par région réglé sur "Europe"
- Action : cliquer sur le bouton "Télécharger CSV"
- Attendu : un fichier nommé ventes_2025-01-15.csv est téléchargé ; le fichier s'ouvre dans un tableur et affiche les colonnes [date, produit, région, montant] avec une ligne par vente filtrée
- Ne doit pas : le fichier ne contient pas la colonne "numéro_de_carte_de_crédit" ni les lignes avec région != "Europe"
- Vérification : test Playwright automatisé qui vérifie le nom du fichier, l'en-tête et le nombre de lignes ; vérification manuelle rapide de l'absence de données personnelles dans l'export
- Contrainte d'environnement : le test s'exécute dans un conteneur Docker avec une base de données de test ; aucun appel API externe pendant le test
- Priorité : Requis
Réussi — chaque terme est observable ou mesurable, les limites du scénario sont explicites, la méthode de vérification est définie, les contraintes de sécurité sont énoncées.