Étape 5 du cycle · /sdd exec

Exécution agent — orchestrer sans saturer

L'exécution agent est l'étape entre la Gate OUVERTE (SQS ≥ 4/5) et la Validation. C'est le moment où le Product Engineer orchestre l'agent IA avec un contexte optimisé — assez de contexte pour réussir, jamais assez pour saturer.

Les prérequis — abandon si un seul échoue

/sdd exec vérifie systématiquement ses prérequis avant tout lancement. Si l'un d'eux échoue, l'agent n'est pas lancé et la commande corrective est indiquée (/sdd gate, /sdd spec, /sdd research…).

La structure du prompt de lancement

Le contexte assemblé se divise en deux couches : le contexte permanent — AGENT-GUIDE condensé (règles TOUJOURS/JAMAIS, conventions, vocabulaire) et résumé d'ARCHITECTURE (≤ 500 tokens) — et le contexte de tâche — UNE seule SPEC, complète, avec les fichiers source pertinents listés en §6. Jamais deux SPECs non reliées, jamais le PRD complet.

## Contexte
[AGENT-GUIDE condensé]
[ARCHITECTURE résumé]

## Tâche
[SPEC §2 — Comportement Attendu]

## Critères de succès
[SPEC §3 — Critères d'Acceptation]

## Contraintes
[Règles TOUJOURS/JAMAIS applicables]
[Gouvernance applicable (sortie de regulatory-veto)]

## Fichiers à modifier/créer
[Liste]

La règle de placement compte autant que le contenu : l'Intent et la SPEC active se placent en tête de contexte, pour contrer le lost-in-the-middle effect — la tendance des modèles à dégrader leur attention sur le milieu d'un long contexte. Le budget total est vérifié par la skill context-budget avant lancement : au-delà d'environ 50K tokens — une heuristique de sobriété assumée, non sourcée, pas une limite technique —, on condense (résumés de fichiers volumineux, extraction d'interfaces) plutôt que de « tout injecter et espérer ». La gouvernance est qualifiée par regulatory-veto : un VETO Tier 1 interdit le lancement.

Un plan d'implémentation avant le code

L'agent ne commence jamais par coder : /sdd exec exige un plan d'implémentation que le PE valide avant la première ligne. Depuis la §3.6, ce plan est phasé en tranches verticales testables (.aiad/exec/EXEC-<SPEC-id>-plan.md) : chaque tranche déclare son objectif, ses fichiers, ses tests — obligatoires — et son « Done ». Un mini-gate (npx aiad-sdd mini-gate <SPEC-id> --phase N) valide chaque tranche avant la suivante. Cela évite le piège classique : 1 200 lignes de code horizontal avant le moindre test.

Maintenir l'agent dans le scope

Pendant la session, le PE observe : l'agent suit-il la SPEC ? Des signes de drift apparaissent-ils ? Un agent qui dérive n'est pas en faute si la SPEC était imprécise — c'est un Human Learning, pas une Lesson Learned. Plus de deux relances pour la même SPEC signalent une SPEC trop ambitieuse : direction /sdd split. Le prompt embarque aussi le contrat JNSP : face à une zone non décidable, l'agent pose // TODO-JNSP: <question> et s'arrête, plutôt que d'inventer la valeur manquante.

Les points d'arrêt en cours d'exécution

Autorisé à écrire sur une SPEC validée, l'agent n'est pas pour autant autorisé à tout : le continuum d'autorité exclut toute action hors du périmètre de la SPEC et, a fortiori, toute action irréversible non déclarée. Pendant la session, l'agent revient vers l'humain aux points d'arrêt prévus — approbation, avis d'expert, pluralité de points de vue, témoin —, précisés le cas échéant dans la section « Points d'arrêt de l'agent » de la SPEC. Si la SPEC déclare une action irréversible, son seuil d'arrêt s'applique : tout dépassement d'autonomie constaté arrête l'agent et déclenche une revue humaine immédiate, pas un signalement a posteriori.

Un mode de permission n'est pas un contrôle

Les harnesses proposent des modes de permission — approbation manuelle, classifieur automatique, listes d'autorisation. Ils réduisent la friction ; ils ne constituent pas une garantie opposable. En août 2026, Johann Rehberger a contourné le mode automatique de Claude Code dans 80 % de ses essais, et dans certains cas le classifieur a autorisé le processus malveillant puis bloqué la commande de remédiation lancée par l'agent. La protection d'une session d'exécution repose sur l'isolation : conteneur ou machine virtuelle, sorties réseau restreintes, aucun credential superflu (clés SSH, clés cloud) dans l'environnement de l'agent. Le mode de permission vient en complément, jamais en substitut — voir Autonomie de l'agent.

Déléguer à des sous-agents : déléguer tôt

Le coût d'une délégation dépend du mécanisme du harness. Si le sous-agent hérite de la conversation parente — c'est le cas par défaut dans certains harnesses —, son coût vaut contexte parent au moment du fork + travail propre, et non un coût marginal. Trois conséquences :

• déléguer tôt, quand le contexte parent est encore léger ;
• le point de fork est un poste de coût explicite du Context Audit ;
• si l'héritage est désactivé, le sous-agent part d'un contexte vierge et doit recevoir explicitement l'Intent Statement et la SPEC active.

La messagerie entre sessions d'agents ne dispense pas de la traçabilité : toute décision prise entre agents qui modifie un comportement est reportée dans la SPEC (Drift Lock).

Reprendre une session interrompue — /sdd resume

Les interruptions (timeout, erreur, limite de conversation, pause volontaire) sont normales — pas un échec. /sdd resume reconstruit un contexte minimal au lieu de réinjecter toute la session : inventaire du travail fait (git status, git diff), critères couverts vs restants, puis prompt de reprise contenant uniquement l'AGENT-GUIDE condensé, la SPEC complète et le résumé d'état.

ÉTAT DE LA SESSION — SPEC-NNN
══════════════════════════════
Fichiers créés     : [liste]
Fichiers modifiés  : [liste]
Tests ajoutés      : X (Y passent, Z échouent)
Critères complétés : X/Y

Travail restant :
- [ ] [Critère non couvert]

La boucle de feedback — /sdd context

Après chaque session, /sdd context compare l'estimation du budget (SPEC §6) avec la réalité : tokens consommés, dégradation observée, durée effective. Les recommandations produites améliorent la session suivante — c'est l'empirisme du framework appliqué au Context Engineering Budget lui-même.

Annotations machine-vérifiables dans le code produit

Tout le code applicatif produit pendant la session porte les annotations de traçabilité v1.10 — c'est ce qui rend le Drift Lock mesurable algorithmiquement :

/**
 * @intent INTENT-042
 * @spec SPEC-042-1-flow-auth
 * @verified-by tests/auth/oidc.test.ts
 * @governance AIAD-RGPD
 */

@spec est obligatoire (cardinalité 1..n) sur tout code applicatif ; @intent, @verified-by et @governance complètent la chaîne Intent ↔ SPEC ↔ Code ↔ Tests. Les annotations sont acceptées en JSDoc, commentaires // ou # et docstrings Python. Une fois toutes les tranches validées et les tests verts : direction /sdd validate.