Du ticket au fichier de tâche : l'agent rédige, une personne décide

La partie précédente s'achevait sur le troisième fichier, le fichier de tâche. Il porte la règle de la première partie : l'agent exécute un périmètre déjà décidé, il ne le décide jamais. D'où une objection évidente : qui rédige ce périmètre, et n'est-ce pas justement l'étape la plus lente ?

Non, à condition de laisser l'agent en écrire le brouillon.

Deux documents, une seule décision

Dans l'entreprise, la demande existe déjà par écrit. Elle s'appelle un , et elle est rédigée pour des personnes : langage métier, critères d'acceptation, captures d'écran, commentaires. Le ticket reste là où l'entreprise le range.

Le fichier de tâche reprend la même décision dans les termes du dépôt : les bibliothèques que l'on peut toucher, les fonctions du domaine à réutiliser, les commandes qui définissent « terminé », le plafond du . Un ticket précise rarement « ne pas modifier les existantes » ou « appeler canTransfer() depuis la bibliothèque du domaine ». Un fichier de tâche ne dit que cela.

Rédiger les deux à la main revient à faire le travail deux fois. Rédiger le ticket à la main et confier la traduction à l'agent, c'est autre chose. Une fois le code lu, l'agent dresse la liste des fichiers concernés plus vite que l'auteur du ticket lui-même.

Première étape : l'agent rédige

Prompt · du ticket au fichier de tâche

Lis AGENTS.md et docs/tasks/TEMPLATE.md. Voici le ticket tel que le métier l'a rédigé. Transforme-le en fichier de tâche pour ce dépôt.

N'écris pas de code. Indique les fichiers que tu modifierais et pourquoi, le périmètre que tu proposes, ce que tu considères hors périmètre, la checklist « terminé quand » avec les commandes exactes, et toutes les questions qui doivent être tranchées avant de commencer. Garde le diff sous 300 lignes ; s'il ne tient pas, découpe-le en tâches numérotées.

--- ticket --- ATLAS-218 · Exporter les transactions en CSV En tant que client, je veux exporter les transactions de mon compte, avec les filtres appliqués, pour faire le rapprochement sous Excel. Colonnes : date, libellé, catégorie, montant en MAD. 10 000 lignes au maximum. Doit fonctionner sur l'affichage mobile.

Le brouillon arrive en quelques minutes. Il est en général plus complet qu'un ticket écrit de mémoire, avec un réflexe qu'il faut connaître : il répond à ses propres questions. « L'export doit-il tenir compte des filtres en cours ? Je pars du principe que oui. » Cette hypothèse est une décision, et elle ne revient pas à l'agent. Enregistrez le brouillon sous docs/tasks/008-export-filtered-transactions-csv.md : les deux étapes suivantes travaillent sur ce fichier.

Deuxième étape : un second agent vérifie

Avant qu'une personne ne lise le brouillon, faites-le relire par un agent qui n'a pas pris part à sa rédaction. Une nouvelle session, ou un autre modèle, avec pour seul bagage le fichier de règles et le brouillon, pour qu'il n'ait aucun travail à défendre :

Prompt · vérifier la tâche avant qu'une personne la lise

Lis AGENTS.md, puis docs/tasks/008-export-filtered-transactions-csv.md. Ce n'est pas toi qui l'as rédigé. Confronte-le aux règles et réponds uniquement à ceci :

Le périmètre touche-t-il un chemin interdit par les règles, ou une bibliothèque dont la tâche n'a pas besoin ?
Chaque point de « terminé quand » est-il une commande ou un résultat visible, et non une opinion ?
Le diff proposé peut-il tenir sous 300 lignes ? Sinon, propose un découpage.
Quelles questions ouvertes le brouillon a-t-il tranchées seul au lieu de les poser ?
Manque-t-il dans la tâche un élément du ticket ?

Réponds par une liste numérotée de constats. Sans réécriture.

Cette vérification repère bien les défauts mécaniques : un périmètre qui déborde sur une bibliothèque partagée, un « terminé quand » qui se contente de « fonctionne correctement », un diff qui ne peut pas tenir, et chaque question que le brouillon a tranchée en silence.

Troisième étape : une personne décide

Ce qui reste est court. Réduisez le périmètre là où le brouillon s'est montré trop généreux. Répondez aux questions, dans le fichier. Décidez si c'est bien le changement que vous voulez : c'est la seule chose qu'aucun agent ne peut faire. Enregistrez le fichier, ou recollez-le dans le ticket si c'est là que votre équipe lit.

Quelques minutes pour l'agent, quelques-unes pour vous, et rien n'est écrit deux fois à la main. L'agent dispose désormais d'une tâche qu'il n'a pas décidée.

À quoi ressemble un bon fichier de tâche

Le fichier de tâche fait foi. Le code n'est que le détail.

# Tâche 008 : exporter en CSV les transactions filtrées d'un compte
 
## Objectif
Un client peut télécharger les transactions filtrées d'un compte dans un fichier CSV, sur ordinateur comme sur mobile.
 
## Périmètre
- Autorisé à modifier : `libs/feature/accounts`
- Nouveaux fichiers autorisés dans : `libs/feature/accounts/src/lib/` (un `transactions-csv.ts` pur et son fichier spec)
 
## Hors périmètre
- `libs/ui` (aucun nouveau composant partagé). `libs/data-access/*` (les transactions sont déjà dans le store). `libs/legacy/**`.
 
## Terminé quand
- [ ] `npm run lint:arch`, `npm run test` (sans assertion modifiée) et `npm run typecheck` passent
- [ ] Sur `/accounts/a-current`, filtrer par catégorie puis cliquer sur « Export CSV » télécharge uniquement les lignes filtrées (tranché : oui, commentaire 3 d'ATLAS-218)
- [ ] Colonnes dans cet ordre : date, libellé, catégorie, montant en MAD ; 10 000 lignes au maximum
- [ ] Sur l'affichage mobile, le bouton « Export CSV » est visible et le téléchargement fonctionne
- [ ] Diff ≤ 300 lignes
 
## Notes pour l'agent
- Analogue le plus proche à imiter : `libs/feature/accounts/src/lib/account-detail.ts`
- Fonctions utilitaires du domaine à réutiliser : `formatMad` et `categoryLabel` depuis `@atlas/domain`

La ligne « analogue le plus proche » est le héros discret du fichier. Les agents copient la forme. Montrez-leur la bonne, et le code revient avec l'allure du reste de la base de code.

Dès lundi

Arrêtez de rédiger les fichiers de tâche à la main. Collez le ticket et demandez le fichier de tâche, pas le code.
Lancez le de vérification dans une nouvelle session avant de lire le moindre brouillon.
Décidez dans le fichier, jamais dans le chat. C'est le fichier que l'agent lira la semaine prochaine.

Exercice : docs/tasks/TEMPLATE.md et la tâche 001 du dépôt de démonstration, une version terminée et plus courte de cet export. Départ : git switch -c m1/you main. Référence : origin/track1/m1-solution.

Une nouvelle fonctionnalité, c'est le cas facile. La partie suivante traite du code déjà en production : un module à migrer, où la première chose à relire est le plan de l'agent lui-même.

Parcours 1, partie 3 de la série gratuite qui accompagne le Vite et sûr : l'IA dans votre code Angular.