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.
| Niveau | Acte humain requis | Ce qu'il n'autorise pas |
|---|---|---|
| 1. Consultation | Aucun — l'agent peut lire et proposer | Toute écriture de code ou d'artefact de production |
| 2. Clarification | Répondre aux questions de l'agent | Répondre n'est pas consentir : aucune écriture de code ou d'artefact de production n'en découle |
| 3. Validation de la SPEC | Ouverture de l'Execution Gate (SQS ≥ 4/5, Test de l'Étranger) | Le déploiement |
| 4. Autorisation d'écriture | Lancement de l'exécution sur la SPEC validée | Toute action hors du périmètre de la SPEC |
| 5. Autorisation de déploiement | Décision explicite, chaîne de preuve complète | Les 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 :
| Type de point d'arrêt | Quand l'agent le déclenche | Exemple de déclencheur dans une SPEC |
|---|---|---|
| Approbation | Avant une action hors mandat ou irréversible | Toute migration de schéma |
| Avis d'expert | Quand la décision dépasse la SPEC | Choix d'un algorithme de scoring |
| Pluralité de points de vue | Quand plusieurs interprétations de l'intention sont plausibles | Règle métier ambiguë : présenter les options |
| Témoin | Pour porter une décision notable à la connaissance de l'humain | Dé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.
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.
| Élément | Déclaration attendue |
|---|---|
| Isolation | Processus, conteneur ou machine virtuelle |
| Sorties réseau autorisées | Aucune, ou liste de domaines |
| Credentials présents dans l'environnement | Liste, avec portée minimale et durée de vie |
| Ressources partagées en écriture | Registre de paquets, cache, dépôt, bucket, file de messages… |
| Espaces de coordination voulus | Par exemple un dépôt git utilisé comme mémoire partagée entre agents — ou « aucun » |
| Actions irréversibles possibles | Liste, 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é attendue | Pourquoi |
|---|---|
| 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'actions | Un dommage peut naître d'actions individuellement anodines |
| Autorisation humaine préalable par action irréversible, par une personne identifiable | Human 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'origine | Article 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 superflus | Un 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é.
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.
| Artefact | Ce qu'il documente |
|---|---|
| Intent Statement | L'intention et son auteur humain identifié |
| SPEC | Le périmètre délégué à l'agent |
| Trace de l'Execution Gate | La validation humaine avant exécution |
| Drift Lock | La 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
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 gateavant 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) ouJNSP(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.