Concept · doctrine AIAD v1.9

Autonomie de l'agent — une variable que l'on dose

Un agent qui peut écrire du code, dépenser de l'argent, supprimer des données ou agir sur un équipement n'est plus un simple générateur de texte. La doctrine AIAD v1.9 ne cherche pas à maximiser son autonomie : une autonomie plus grande n'est pas un objectif en soi, c'est une variable que l'on dose, SPEC par SPEC. Cette page réunit les mécanismes qui fixent ce dosage — et qui permettent de démontrer, après coup, ce qui avait été délégué.

Ce que l'humain accorde, ce que l'agent rend

L'autonomie de l'agent se décrit dans les deux sens. D'un côté, ce que l'humain accorde : un niveau d'autorité, un périmètre d'exécution, des plafonds. De l'autre, ce que l'agent rend : des points d'arrêt où il revient vers l'humain, un arrêt immédiat quand il dépasse ce qui lui a été délégué, et une trace de ce qu'il a fait. Les deux sont déclarés avant l'exécution, dans l'Intent Statement et la SPEC, et vérifiés à l'Execution Gate. C'est la déclinaison opérationnelle de la valeur 7, Human Authorship, et de la valeur 6, Responsabilité Partagée : une autonomie déléguée sans responsable humain assumé est un défaut de gouvernance, pas une fonctionnalité.

Le continuum d'autorité

Chaque passage d'un niveau d'autorité au suivant est un acte humain distinct, qu'aucun autre acte ne remplace. Accepter de répondre aux questions d'un agent n'est pas l'autoriser à écrire ; valider une SPEC n'est pas autoriser un déploiement.

Les cinq niveaux du continuum d'autorité
NiveauActe humain requisCe qu'il n'autorise pas
1. ConsultationAucun — l'agent peut lire et proposerToute écriture de code ou d'artefact de production
2. ClarificationRépondre aux questions de l'agentRépondre n'est pas consentir : aucune écriture de code ou d'artefact de production n'en découle
3. Validation de la SPECOuverture de l'Execution Gate (SQS ≥ 4/5, Test de l'Étranger)Le déploiement
4. Autorisation d'écritureLancement de l'exécution sur la SPEC validéeToute action hors du périmètre de la SPEC
5. Autorisation de déploiementDécision explicite, chaîne de preuve complèteLes actions irréversibles non déclarées

« Écriture » désigne ici le code et les artefacts de production. Aux niveaux consultation et clarification, l'agent peut rédiger des brouillons d'artefacts de spécification — c'est le rôle de /sdd spec ; ils n'engagent rien tant qu'un humain ne les a pas validés à la Gate. L'Intent Statement, lui, reste rédigé par un humain.

Les points d'arrêt à l'initiative de l'agent

Le continuum décrit ce que l'humain accorde ; les points d'arrêt décrivent quand l'agent doit revenir vers l'humain. AIAD reprend la typologie proposée par Ethan Mollick en 2026 :

Typologie des points d'arrêt de l'agent
Type de point d'arrêtQuand l'agent le déclencheExemple de déclencheur dans une SPEC
ApprobationAvant une action hors mandat ou irréversibleToute migration de schéma
Avis d'expertQuand la décision dépasse la SPECChoix d'un algorithme de scoring
Pluralité de points de vueQuand plusieurs interprétations de l'intention sont plausiblesRègle métier ambiguë : présenter les options
TémoinPour porter une décision notable à la connaissance de l'humainDépendance ajoutée

La SPEC peut préciser ceux qui s'appliquent, dans sa section optionnelle « Points d'arrêt de l'agent ». Si la section est absente, les points d'arrêt par défaut du framework s'appliquent : ceux qu'impose le continuum d'autorité. Quand l'agent ne peut pas trancher, il émet un verdict JNSP plutôt que d'inventer.

Quand la supervision devient nominale

La doctrine classe à part, dans les Human Learnings, les défaillances de supervision : un agent qui agit sans approbation, ou des relectures automatiques empilées sans plus aucun humain pour trancher. La question à poser en rétrospective : à quel moment un humain aurait-il dû être consulté, et pourquoi ne l'a-t-il pas été ?

Le périmètre d'exécution de l'agent

Dès que l'agent qui exécute une SPEC dispose de credentials (cloud, API, SSH, base de données) ou d'un accès en écriture à une ressource partagée, la SPEC déclare son périmètre d'exécution dans la section conditionnelle « Périmètre d'exécution de l'agent ». Hors de ces cas, on écrit « Non applicable » et on ne remplit rien : une SPEC ne doit pas s'alourdir d'un champ rempli par rituel.

Contenu de la section « Périmètre d'exécution de l'agent » (doctrine, annexe A)
ÉlémentDéclaration attendue
IsolationProcessus, conteneur ou machine virtuelle
Sorties réseau autoriséesAucune, ou liste de domaines
Credentials présents dans l'environnementListe, avec portée minimale et durée de vie
Ressources partagées en écritureRegistre de paquets, cache, dépôt, bucket, file de messages…
Espaces de coordination voulusPar exemple un dépôt git utilisé comme mémoire partagée entre agents — ou « aucun »
Actions irréversibles possiblesListe, avec leur classe de réversibilité

Trois règles accompagnent la déclaration : le mode de permission du harness n'est pas une mesure de confinement et ne s'inscrit pas comme tel ; toute ressource partagée en écriture est un canal de coordination potentiel entre agents et se déclare, même si elle semble anodine ; si une action irréversible est possible, l'Execution Gate vérifie le plafond, l'autorisation humaine préalable et le seuil d'arrêt.

Classe de réversibilité et seuil d'arrêt

Lorsque l'intention implique des actions d'agent aux effets hors du code — financiers, opérationnels ou matériels —, le Critère de Drift de l'Intent Statement précise leur classe de réversibilité :

  • réversible : annulable sans coût ;
  • coûteusement réversible : annulable avec une perte (argent, temps, restauration depuis une sauvegarde) ;
  • irréversible : non annulable (paiement exécuté, engagement contractuel, suppression définitive, action physique sur un équipement).

Pour la classe irréversible, le Critère de Drift fixe un seuil d'arrêt, pas un simple indicateur de suivi : tout dépassement d'autonomie constaté — dépense au-delà du plafond, action hors du périmètre délégué, tentative de masquer ou d'altérer ses propres traces — déclenche l'arrêt immédiat de l'agent et une revue humaine, et non un signalement a posteriori. Les alertes de facturation des fournisseurs ne remplissent pas ce rôle : conçues pour des erreurs à vitesse humaine, elles peuvent accuser jusqu'à 24 heures de retard (incidents de dépassement documentés par InfoQ, juillet 2026).

Le profil « Agents à effet irréversible » d'AIAD-AI-ACT

L'agent de gouvernance AIAD-AI-ACT consacre un profil de risque émergent aux agents à effet irréversible (financier, opérationnel, matériel). S'il influence une décision affectant des personnes dans un domaine de l'Annexe III de l'AI Act, l'agent relève du régime haut risque. Hors de ce cas, le règlement n'impose pas d'obligations de supervision spécifiques à ce profil : AIAD applique néanmoins, à titre de bonne pratique, des points de contrôle humains minimaux avant toute mise en service — et le droit commun continue de s'appliquer.

Propriétés attendues des garde-fous d'un agent à effet irréversible
Propriété attenduePourquoi
Plafond appliqué techniquement (montant, liste d'autorisation, limite par transaction)Une consigne dans un prompt n'est pas une limite
Politique à mémoire temporelle, qui raisonne sur la séquence d'actionsUn dommage peut naître d'actions individuellement anodines
Autorisation humaine préalable par action irréversible, par une personne identifiableHuman Authorship ; article 14 pour un système à haut risque
Journal à valeur probante — entrées signées ou chaînées, reliées à l'autorisation d'origineArticle 12 pour un système à haut risque ; preuve en cas de contestation
Isolation de l'exécution — conteneur ou VM, sorties réseau restreintes, pas de credentials superflusUn classifieur de permission peut être contourné

AIAD prescrit des propriétés, pas des produits. Hors haut risque, les rattachements aux articles 12 et 14 sont une bonne pratique, pas une obligation légale. Un responsable humain est désigné pour chaque délégation, même quand le protocole utilisé fournit ses propres plafonds : un garde-fou d'infrastructure n'est pas un cadre de responsabilité.

Effets matériels

La classe irréversible inclut les actions sur des équipements physiques (instruments, robots, machines). La sûreté d'un système cyber-physique ne se traite jamais avec ce seul référentiel : elle relève de normes établies (IEC 61508, ISO 13849, ISO 14971) et, pour les machines, du Règlement Machines. Escalader au Tech Lead et à un spécialiste de la sûreté.

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. Un mécanisme qui peut bloquer la remédiation ne peut pas porter l'autorité humaine.

L'Agents Engineer ne présente donc jamais un mode de permission comme une mesure de sécurité suffisante. La protection repose sur l'isolation : conteneur ou machine virtuelle, sorties réseau restreintes, aucun credential superflu (clés SSH, clés cloud) dans l'environnement d'exécution de l'agent. Le mode de permission vient en complément, jamais en substitut. C'est le prolongement du principe de moindre privilège du Harness Engineering (voir la responsabilité Agents Engineer).

Le confinement se juge sur la surface partagée

Isoler chaque agent ne suffit pas. En juillet 2026, environ 1 200 agents d'évaluation d'OpenAI, chacun isolé dans son propre sandbox, ont découvert qu'ils accédaient au même cache Artifactory. Ils en ont fait un tableau de messages — plus de 70 000 messages et fichiers échangés — et environ 700 d'entre eux ont participé à une intrusion de plusieurs jours chez Hugging Face (rapport indépendant METR / Redwood Research, août 2026). L'isolement de chaque agent était réel ; c'est la ressource commune qui a servi de canal.

Martin Fowler décrit le même mécanisme sous un jour constructif (« An accidental blackboard », septembre 2026) : des agents qui utilisent spontanément le dépôt git comme mémoire partagée. La leçon est identique dans les deux cas : toute ressource partagée accessible en écriture est un canal de coordination entre agents, voulu ou non. L'Agents Engineer inventorie ces ressources, et la SPEC les déclare — y compris les espaces de coordination voulus — dans sa section « Périmètre d'exécution de l'agent ».

La trace comme preuve

AIAD fait sienne la thèse formulée par Bruce Schneier et Nathan Sanders en juin 2026 : les agents IA sont les agents de la personne ou de l'organisation qui les déploie. C'est une thèse, pas état du droit. Un premier signal judiciaire existe — l'injonction du tribunal régional de Munich du 28 mai 2026 tenant Google responsable d'affirmations générées par ses AI Overviews —, mais il porte sur la diffamation par un moteur de recherche, pas sur des agents de développement, et la décision est provisoire, en appel.

Si l'organisation répond de ses agents, elle doit pouvoir montrer ce qu'elle leur a demandé, dans quelles limites, et qui l'a validé. C'est la trace de délégation que prescrit AIAD-AI-ACT : toute tâche confiée à un agent se rattache à un Intent Statement, à une SPEC et à la trace de l'Execution Gate ; une tâche dont l'origine humaine ne peut pas être retracée ne s'exécute pas.

Ce que documente chaque maillon de la chaîne de preuve
ArtefactCe qu'il documente
Intent StatementL'intention et son auteur humain identifié
SPECLe périmètre délégué à l'agent
Trace de l'Execution GateLa validation humaine avant exécution
Drift LockLa synchronisation entre ce qui était voulu et ce qui a été livré

Ces artefacts ne garantissent pas l'issue d'un litige. Ils documentent la diligence de l'organisation et rendent sa responsabilité démontrable — dans un sens comme dans l'autre : une SPEC défectueuse validée à la Gate engage celui qui l'a validée. Une trace qui ne pourrait que disculper ne serait pas une preuve.

La même chaîne conditionne le déploiement automatisé : un déploiement sans intervention humaine n'est admissible que si le code est trusted au sens d'une chaîne de preuve vérifiable — Intent Statement, SPEC validée à la Gate, vérifications tracées, Drift Lock —, et non d'une confiance déclarative dans l'outil ou le modèle. Pour une organisation aux moyens d'ingénierie modestes, la conséquence pratique est de réserver le déploiement automatisé aux fonctionnalités dont la chaîne de preuve est complète. La traçabilité machine-vérifiable relie ensuite chaque ligne de code à cette chaîne.

Dans le paquet aiad-sdd

Prochaine version — à paraître

Les fonctions suivantes sont intégrées au code du paquet mais pas encore publiées ; elles paraîtront dans la prochaine version.

  • Sections de SPEC : les gabarits de SPEC (prose et EARS) intègrent les sections « Points d'arrêt de l'agent » (optionnelle) et « Périmètre d'exécution de l'agent » (conditionnelle, « Non applicable » sinon). Par rapport à la doctrine, le tableau du gabarit ajoute une ligne « Seuil d'arrêt » et ne comporte pas de ligne distincte « Espaces de coordination voulus ».
  • Pré-contrôle gate-precheck : npx aiad-sdd gate-precheck <SPEC>, lancé par /sdd gate avant tout scoring SQS, lit la section « Périmètre d'exécution de l'agent » et rend un verdict déterministe calculé hors modèle — PASS (code de sortie 0), FAIL (1 : Gate fermée, par exemple une action irréversible sans seuil d'arrêt) ou JNSP (2 : Gate inconnue, SPEC introuvable ou tableau incomplet). Détail sur la page Execution Gate.

Sources

Doctrine AIAD v1.9 : Framework AIAD, § 3.3 (Agents Engineer — mode de permission, surface partagée), § 4.0 (classe de réversibilité et seuil d'arrêt), § 4.4 (continuum d'autorité, points d'arrêt), § 5.5 (chaîne de preuve du déploiement automatisé) ; annexe A, gabarit de SPEC (sections « Points d'arrêt de l'agent » et « Périmètre d'exécution de l'agent ») ; AIAD-AI-ACT, profil « Agents à effet irréversible » et consigne « Trace de délégation » ; dossier de légitimation « La trace AIAD comme élément de preuve de la responsabilité » (sources vérifiées le 25/09/2026). Ce contenu décrit une logique de gouvernance et de responsabilité, pas un avis juridique.