Ingénierie des systèmes agentiques : règles d'or, architecture et sécurité du « Human-in-the-Loop »

Quand une machine agit sans garde-fou

Le 1ᵉʳ août 2012, il a suffi de quarante-cinq minutes pour que la société de courtage Knight Capital perde environ 440 millions de dollars. Un déploiement logiciel défectueux avait réactivé du code obsolète sur un routeur d’ordres boursiers, qui s’est mis à inonder le marché de transactions erronées, sans qu’aucun mécanisme humain ne puisse l’arrêter à temps [1]. L’entreprise, l’un des plus grands teneurs de marché américains, ne s’en est jamais remise. Cette catastrophe n’est pas une histoire d’intelligence artificielle, mais elle raconte exactement ce qui se joue aujourd’hui : le coût d’une exécution automatisée dépourvue de garde-fous opérationnels en temps réel.

L’évolution de l’IA a amorcé une transition structurelle profonde : le passage de systèmes passifs, tournés vers la génération de réponses, à des agents autonomes orientés vers l’action. Contrairement aux interfaces classiques de traitement du langage, les architectures agentiques modernes conçoivent et exécutent des plans d’action multi-étapes, interagissent directement avec des environnements numériques et physiques, et manipulent des outils critiques : bases de données de production, passerelles de transaction financière, systèmes industriels. Ce déploiement s’appuie sur des protocoles émergents : le Model Context Protocol (MCP) d’Anthropic [3] et les protocoles de communication d’agent à agent (A2A) [4]. Ils permettent à un système de découvrir dynamiquement de nouvelles capacités au moment de l’exécution.

Cette autonomie accrue s’accompagne d’un élargissement considérable de la surface d’attaque et des risques opérationnels. Or les modèles de langage ont un défaut documenté : ils sont systématiquement trop sûrs d’eux. Les travaux sur leur calibration montrent qu’un modèle verbalise couramment une confiance de 90 % ou plus là où sa justesse réelle est nettement inférieure, et que les hallucinations surviennent fréquemment avec un niveau de certitude affiché élevé [2]. Un agent peut donc générer un plan d’action erroné, voire une hallucination destructrice, tout en se déclarant parfaitement confiant. Sous-estimer cette défaillance, c’est reproduire, à l’échelle logicielle, le scénario de Knight Capital.

Pour pallier ces vulnérabilités, l’intégration de protocoles de contrôle humain, le Human-in-the-Loop (HITL), ne doit pas être pensée comme une simple couche de validation ergonomique, mais comme une contrainte d’ingénierie fondamentale. Encore faut-il adapter le niveau de contrôle à la criticité des opérations, à la réversibilité des actions et aux impératifs réglementaires.

Trois régimes de supervision : HITL, HOTL, HOOTL

La première décision d’architecture consiste à choisir, pour chaque type d’action, qui décide et quand. La littérature sur les systèmes autonomes distingue trois régimes de supervision, une taxonomie héritée du débat sur les systèmes d’armes et transposable aux agents logiciels [5].

Régime	Temporalité	Autonomie	Cas d’usage recommandés	Charge cognitive	Enjeux opérationnels & RH
Human-in-the-Loop (HITL)	Interruption synchrone : l’agent gèle son exécution et attend une approbation humaine explicite.	Faible : l’agent propose, mais l’exécution physique de l’action est bloquée.	Opérations critiques et irréversibles : virements, modifications de bases, diagnostics médicaux.	Élevée : évaluation continue, analyse du contexte, validation manuelle.	Nécessite des équipes d’approbateurs dédiées et disponibles pour éviter les goulets d’étranglement.
Human-on-the-Loop (HOTL)	Surveillance asynchrone : l’agent s’exécute seul mais sous monitoring continu.	Modérée à élevée : l’agent agit dans des limites prédéfinies.	Moyenne criticité, volumes élevés : modifications de réservations, planification, mises à jour de statut.	Modérée : alertes déclenchées au franchissement d’un seuil ou sur comportement anormal.	Un superviseur peut piloter et auditer plusieurs agents en parallèle.
Human-out-of-the-Loop (HOOTL)	Audit a posteriori : aucune intervention en temps réel.	Maximale : l’agent est souverain dans son périmètre.	Faible risque, hautement standardisé : routage d’appels, réponses aux questions fréquentes.	Faible : analyse périodique des journaux et ré-entraînement.	Requiert des auditeurs de conformité réguliers et des annotateurs hors ligne.

Aucun de ces régimes n’est « meilleur » dans l’absolu : le bon système en combine plusieurs, action par action. Reste à savoir comment structurer, concrètement, le comportement de l’agent pour préserver l’autorité de l’humain.

Les règles d’or du Human-in-the-Loop

Règle 1. Séparer la proposition d’action de son exécution

L’architecture d’un agent ne doit jamais lui accorder la capacité d’exécuter directement et unilatéralement une action à effets irréversibles sur son environnement. L’agent doit produire une proposition d’action documentée (intention, paramètres, estimation des conséquences, données sources utilisées) et la soumettre à un moteur d’exécution cloisonné. L’exécution physique reste suspendue tant qu’un opérateur qualifié n’a pas validé la transaction. Cette séparation protège l’infrastructure contre les injections de requêtes malveillantes comme contre les déductions erronées du modèle.

Règle 2. Structurer les points d’interruption avant d’écrire le code

Les points de contrôle humain ne s’ajoutent pas après coup, en rattrapage. Les ingénieurs doivent cartographier les transactions à haut risque dès la conception. Cette structuration passe par des seuils d’intervention quantitatifs qui déclenchent automatiquement la mise en pause du système : plafonds de dépense, niveaux de sensibilité des données, critères réglementaires (GxP, HIPAA, RGPD).

Règle 3. Rendre le raisonnement de l’agent intégralement transparent

La confiance de l’opérateur dépend de la visibilité des étapes qui mènent à une recommandation. L’agent doit exposer, de manière intelligible, les données sur lesquelles il s’appuie, les règles métier appliquées et les alternatives écartées. Cette transparence gagne à être restituée via des interfaces accessibles (de type low-code ou no-code) pour que des équipes non techniques comprennent instantanément le motif d’une escalade et corrigent la trajectoire de l’agent sans lire de code brut.

Règle 4. Codifier les limites non négociables de façon déterministe

C’est la règle la plus contre-intuitive, et la plus importante. Un agent fondé sur un modèle probabiliste ne peut pas garantir le respect d’une contrainte de sécurité formulée uniquement en langage naturel. Les limites non négociables (restriction d’accès aux bases de production, plafonds budgétaires, périmètre d’outils autorisés) doivent être encodées de façon déterministe dans le harnais logiciel qui entoure le modèle. Le système intègre des validations de schémas strictes (typiquement via un validateur comme Pydantic) et des règles impératives qui bloquent une requête non conforme avant qu’elle n’atteigne l’interface du modèle ou une API externe. Le garde-fou vit dans le code, pas dans le prompt.

Règle 5. Concevoir pour une automatisation progressive

L’implémentation doit débuter au niveau d’intervention humaine maximal. Ce démarrage conservateur permet d’enregistrer les décisions, d’analyser les divergences entre propositions du modèle et corrections humaines, et de mesurer précisément la fiabilité du système. À mesure que les métriques s’améliorent et que les modèles se calibrent, les critères de mise en pause s’assouplissent : le système évolue d’un contrôle synchrone (HITL) vers une supervision par exception (HOTL). L’automatisation se mérite ; elle n’est jamais le point de départ.

Règle 6. Ancrer la gouvernance dans cinq obligations : le mémo « HEART »

Pour inscrire la collaboration humain-machine dans une démarche responsable, il est utile de résumer les obligations de contrôle sous un acronyme mnémotechnique, HEART, qui regroupe cinq piliers, chacun reconnu par ailleurs comme un principe de gouvernance de l’IA :

• Human safety & accountability : la sécurité humaine et la responsabilité juridique finale doivent incomber à une personne physique.
• Explainability : l’explicabilité de chaque choix structurant, pour proscrire l’effet « boîte noire ».
• Alignment : l’alignement continu des opérations de l’agent avec les objectifs métier et la charte éthique de l’entreprise.
• Review : l’audit et la réévaluation réguliers des performances et des comportements émergents.
• Trackability : la traçabilité technique absolue des actions de la machine et des décisions de validation humaines.

(HEART est ici un moyen mnémotechnique de regroupement, non un standard normatif établi : les cinq obligations, elles, sont des exigences classiques de gouvernance.)

Règle 7. Gérer dynamiquement les niveaux d’escalade

Le système d’interruption doit s’adapter à la nature de la demande. Lorsqu’il gèle son exécution, l’agent doit savoir distinguer une approbation simple (validation binaire), une demande de précision structurée (quand une variable essentielle manque), ou la délégation de l’exécution à un système tiers. Les retours de l’opérateur doivent être guidés par des invites de rétroaction structurées (pour éviter les réponses vagues) et mémorisés, afin d’enrichir le contexte d’apprentissage historique du système.

Règle 8. Borner strictement les itérations de l’agent

Pour prévenir l’épuisement des ressources et éviter qu’un agent ne s’enferme dans des boucles de correction infructueuses en cas de désaccord répété avec l’humain, les flux de travail doivent imposer une limite stricte d’itérations. Franchie sans validation acceptable, cette limite doit faire basculer le système vers un mode de repli sécurisé : suspension de la tâche et alerte d’un niveau de supervision supérieur.

Cadres d’architecture et standards émergents

Passer du principe à la production suppose des protocoles capables d’unifier l’exécution technique des tâches et le contrôle de conformité. Cinq références structurent aujourd’hui le champ.

Les 12 facteurs des agents (12-Factor Agents)

Inspiré de la méthodologie « Twelve-Factor App » du développement SaaS, le guide des 12-Factor Agents, théorisé par Dex Horthy (HumanLayer) dans la lignée des retours d’expérience sur l’orchestration d’agents de codage comme Claude Code et l’IDE CodeLayer, définit les critères d’applications agentiques fiables et exploitables en production [6].

Facteur	Description technique	Rôle vis-à-vis de la supervision humaine
F1. Natural Language to Tool Calls	Traduire l’intention exprimée en langage naturel en schémas d’appels d’outils.	Formalise de manière intelligible l’action que l’agent s’apprête à entreprendre.
F2. Own your prompts	Contrôle, versionnage et maîtrise des instructions transmises au modèle.	Empêche les dérives sémantiques et garantit la stabilité comportementale.
F3. Own your context window	Ingénierie de la taille et de la structure des données injectées dans le contexte.	Prévient la surcharge du modèle et limite les hallucinations décisionnelles.
F4. Tools are just structured outputs	Modéliser les connecteurs de l’agent comme des schémas de sortie stricts.	Autorise une validation déterministe avant toute communication externe.
F5. Unify execution state and business state	Synchroniser l’état d’exécution de la machine et l’état des bases de l’entreprise.	Évite les décisions fondées sur des données métier obsolètes.
F6. Launch/Pause/Resume with simple APIs	Démarrer, figer ou reprendre un flux via des API standards.	Indispensable pour suspendre l’agent durant les interruptions humaines asynchrones.
F7. Contact humans with tool calls	Intégrer la demande d’aide humaine comme une fonction exécutable par l’agent.	Permet à l’agent de mobiliser l’expertise humaine comme un outil, en cas d’incertitude.
F8. Own your control flow	Garder un contrôle déterministe sur le graphe de transition d’états.	Évite de confier la logique d’aiguillage à l’interprétation aléatoire du modèle.
F9. Compact Errors into Context Window	Simplifier et injecter intelligemment les erreurs système dans le contexte.	Aide l’agent à corriger ses erreurs sans intervention humaine systématique.
F10. Small, Focused Agents	Diviser le travail en une constellation de micro-agents spécialisés.	Isole les droits d’accès aux outils selon le principe du moindre privilège.
F11. Trigger from anywhere	Déclencher et superviser l’agent depuis n’importe quel canal (Slack, SMS, e-mail).	Rapproche les demandes d’approbation des espaces de travail des collaborateurs.
F12. Make your agent a stateless reducer	Éliminer les états internes volatils au profit d’un réducteur pur et sans mémoire.	Facilite la reprise après interruption et garantit la reproductibilité des audits.
F13. Pre-fetch all context (mention honorable)	Charger proactivement les données requises avant le processus décisionnel.	Améliore la rapidité et évite les requêtes de données intempestives en cours de flux.

Trois facteurs portent directement le contrôle humain : F7 (contacter l’humain comme on appelle un outil), F6 (suspendre/reprendre proprement) et F10 (petits agents à droits granulaires). Ce sont les fondations techniques du HITL.

AESP : la souveraineté économique reste à l’humain

Dès qu’un agent exécute des tâches financières (souscrire un service, régler une facture, gérer des actifs de tiers), surgit une tension entre la rapidité de la machine et le contrôle souverain des actifs par l’humain. Un travail de recherche paru début 2026, l’Agent Economic Sovereignty Protocol (AESP), formalise un invariant strict : l’agent est économiquement capable, mais jamais économiquement souverain [7]. Tout mouvement de fonds doit franchir un moteur de règles déterministes à huit niveaux de vérification avant d’atteindre la couche de règlement.

Règle de sécurité	Contrôle exercé	Conséquence d’une violation
Per-transaction limit	Plafond absolu autorisé pour un seul ordre de paiement.	Rejet automatique ou escalade vers une validation humaine.
Time-window limit	Dépense cumulée maximale sur une fenêtre temporelle glissante.	Suspension immédiate des capacités de paiement de l’agent.
Address allowlist	Adresses réseau ou portefeuilles cibles préalablement certifiés.	Blocage de toute transaction hors des destinations approuvées.
Chain allowlist	Restriction aux protocoles d’exécution autorisés.	Rejet immédiat de la soumission.
Method allowlist	Fonctions ou appels de contrats intelligents spécifiquement permis.	Blocage au niveau de la couche cryptographique.
First-payment review	Contrôle de conformité à la première interaction avec un tiers.	Exigence d’une approbation humaine renforcée.
Minimum balance	Réserve de trésorerie à préserver sur le compte d’origine.	Gel de l’engagement de nouvelles dépenses.
Budget limits	Enveloppe globale allouée au cycle opérationnel de l’agent.	Désactivation temporaire des outils financiers.

Ces contrôles d’exécution sont renforcés, au niveau de l’infrastructure, par des engagements cryptographiques signés bilatéralement (via la norme EIP-712) : aucune partie ne peut modifier unilatéralement les termes d’une transaction. Le protocole préserve en outre la confidentialité des flux grâce à des adresses éphémères dérivées par HKDF, qui empêchent un observateur externe de corréler les paiements d’un même agent. À ce stade, AESP reste une proposition académique récente, non un standard industriel adopté : sa valeur tient à la clarté de l’invariant qu’il pose, davantage qu’à une maturité éprouvée en production.

Certificats d’agents liés aux capacités

En production multi-agent, les architectures affrontent un risque de dérive que la recherche 2026 nomme le fossé capacité-identité : un agent, après avoir reçu une autorisation humaine pour un périmètre donné, modifie dynamiquement ses compétences à l’exécution (en important de nouveaux outils ou en déléguant à des agents subordonnés) sans que le système central ne détecte cette élévation de privilèges [8]. Les cadres classiques authentifient qui est l’agent, mais pas ce qu’il peut faire.

La parade proposée : des certificats d’identité liés aux capacités, qui lient cryptographiquement l’identité de l’agent à la liste exhaustive de ses outils déclarés, de ses modèles sous-jacents et de ses limites (concrètement, en étendant un certificat X.509 d’une empreinte du « manifeste de compétences »). Le mécanisme repose sur trois propriétés de sécurité :

• G1. Intégrité des capacités : toute modification de la configuration des outils invalide immédiatement les droits actifs et exige une ré-autorisation humaine explicite.
• G2. Vérifiabilité comportementale : toutes les actions doivent être auditables a posteriori pour détecter substitutions de modèles ou falsifications de paramètres.
• G3. Auditabilité des interactions : les échanges entre agents et avec les humains sont consignés dans un grand livre inviolable, fournissant les traces d’analyse médico-légale en cas d’incident.

KnowNo : ne déranger l’humain qu’à bon escient

Le HITL a un ennemi : la fatigue de l’approbation. Un agent qui demande une validation à chaque étape use ses superviseurs et perd tout intérêt. La méthode KnowNo [9], présentée dans les travaux Robots That Ask For Help (Ren et al., CoRL 2023), répond à ce problème en s’appuyant sur la prédiction conforme, qui offre une garantie statistique de couverture (la bonne option figure dans l’ensemble retenu avec une probabilité d’au moins 1 − α, où α est le taux d’erreur toléré par l’organisation) tout en minimisant les interruptions imposées à l’opérateur.

Le principe, sans équation, tient en une idée : au lieu de demander à l’agent « es-tu sûr ? » (question à laquelle il répond mal, cf. la sur-confiance des modèles), on calibre son incertitude sur des exemples validés par des experts, puis on n’escalade que lorsque plusieurs actions restent statistiquement plausibles.

Concrètement, face à un état x, l’agent considère un ensemble d’options 𝒴 = {y_1, …, y_m}. On dispose d’un jeu de calibration S_cal = {(x_i, y_i)} de n situations historiques, où chaque y_i est l’action validée par un expert. Pour chaque exemple, on calcule un score de non-conformité, l’inverse de la probabilité que le modèle attribuait à la bonne réponse :

s_i = 1 − f̂(y_i | x_i)

où f̂(y | x) est la probabilité assignée par le modèle à l’option y. On ordonne ces scores et l’on en tire le seuil quantile correspondant au niveau de tolérance visé :

q̂ = Quantile( {s_1, …, s_n} ; ⌈(n+1)(1−α)⌉ ⁄ n )

À l’exécution, face à une situation inédite x_test, l’agent construit l’ensemble des actions candidates acceptables en ne retenant que les options dont le score de non-conformité reste sous le seuil :

C(x_test) = { y ∈ 𝒴 : 1 − f̂(y | x_test) ≤ q̂ }

La décision d’interrompre ou non l’humain est alors gouvernée par la cardinalité de cet ensemble :

Ensemble C(x_test)	Décision du système
une seule option	Exécution autonome de l’action unique y*.
deux options ou plus	Interruption : escalade vers l’opérateur sous forme de QCM.

Si l’ensemble se réduit à une option, le modèle possède une certitude mathématiquement alignée sur le niveau de sécurité exigé, et il agit sans déranger le superviseur. S’il contient plusieurs options valides, l’agent identifie une zone d’ambiguïté, gèle son exécution et présente les choix présélectionnés. La garantie de complétion de la tâche vaut alors à condition que l’humain réponde correctement : KnowNo convertit la garantie statistique de couverture en garantie de réussite, au prix d’une question, posée seulement quand elle est nécessaire.

Quatorze principes pour le cycle de vie humain-agent

Enfin, la viabilité d’un système agentique ne se mesure pas aux seules performances de la machine : l’interaction humain-agent est une cible de conception à part entière. Une synthèse académique de 2026 [10] propose quatorze principes répartis sur quatre étapes de la vie opérationnelle d’un agent, de la mise en service à la réparation de la confiance après incident.

• Étape 1 : Cadrage initial et attentes. Annoncer explicitement les capacités, limites et modes de défaillance connus (Set Accurate Expectations) ; calibrer l’anthropomorphisme au contexte (neutre en environnement professionnel) ; établir un cadre relationnel clair (assistant de tri, copilote, conseiller) avant de confier des responsabilités réelles.
• Étape 2 : Interaction et contrôle partagé. Négocier dynamiquement le niveau d’initiative selon le risque, avec interruption et reprise instantanées (Negotiate Shared Control) ; rendre l’intention transparente ; ajuster les indices sociaux sans induire de dépendance ; réguler la proactivité pour protéger la concentration de l’opérateur.
• Étape 3 : Collaboration sur le long terme. S’adapter à l’état de l’utilisateur (fatigue, taux de correction) ; consolider en mémoire ses objectifs et ses valeurs, pas seulement ses actions passées ; prévenir activement la dépendance malsaine ; privilégier la cohérence comportementale (des erreurs prévisibles) à une excellence erratique.
• Étape 4 : Défaillance et réparation de la confiance. Soutenir une réparation partagée (interfaces de manipulation directe pour corriger l’agent) ; adapter la stratégie de récupération au type de panne (annulation d’état et audit pour les erreurs graves) ; combiner réparation cognitive (expliquer techniquement l’erreur) et affective (exprimer des regrets contextuels et réaffirmer les nouvelles consignes de sécurité).

Synthèse : trois directives pour les décideurs

Pour déployer des agents autonomes dans des flux industriels sans reproduire un scénario à la Knight Capital, responsables informatiques et ingénieurs système peuvent structurer leur architecture autour de trois directives.

1. Cloisonner le contrôle de sécurité dans l’environnement d’exécution. Proscrire les filtres de sécurité implémentés uniquement comme instructions sémantiques (system prompts). La validation des paramètres d’appels d’outils, la vérification des droits réseau et la gestion des budgets de transaction doivent être gérées par des modules déterministes écrits en langage impératif, externes au modèle.

2. Instaurer des points de contrôle dynamiques et une traçabilité inviolable. Structurer les flux complexes en graphes d’états gérés de façon asynchrone. L’interruption synchrone gèle l’exécution sans perte d’information pendant l’attente d’approbation. Chaque proposition, chaque retour d’opérateur et chaque validation finale sont consignés dans un journal de décisions à preuves cryptographiques, pour simplifier l’audit de conformité.

3. Utiliser l’humain comme correcteur contextuel et guide d’apprentissage. Orienter le superviseur vers les cas à forte valeur ajoutée. En calibrant statistiquement l’incertitude (à la manière de KnowNo), le système automatise les tâches standardisées à haute confiance et ne sollicite l’humain, sous forme de choix, que sur les situations ambiguës. Chaque correction humaine est stockée comme base de connaissances d’apprentissage adaptatif, réduisant graduellement le besoin futur d’interruptions manuelles.

Ces trois directives dessinent une même conviction, qui est au cœur de la Méthode MATIA™ : à l’ère des agents, la rareté ne se déplace pas vers la génération (elle devient abondante) mais vers la vérification. Un agent n’a de valeur en entreprise que si son autonomie est défendable devant un client, un auditeur ou un régulateur. Le Human-in-the-Loop n’est pas le frein de l’automatisation : c’est ce qui la rend industrialisable.

Pour transformer ces principes en architecture agentique gouvernée dans votre organisation, voir la Méthode MATIA™ et le Diagnostic IA Express.

---

Sources

[1] Knight Capital Group, Form 8-K (perte réalisée pré-impôt d’environ 440 M$), SEC EDGAR, 2 août 2012 ; et SEC, Order / communiqué 2013-222 (déploiement de code défectueux réactivant du code obsolète sur un routeur d’ordres ; ~45 min à l’ouverture du marché), 16 octobre 2013. https://www.sec.gov/newsroom/press-releases/2013-222 [2] Mind the Confidence Gap: Overconfidence, Calibration, and Distractor Effects in LLMs (arXiv:2502.11028, 2025), sur-confiance verbalisée des modèles (confiance affichée ~88-99 % vs justesse réelle bien inférieure) ; corroboré par Can LLMs Express Their Uncertainty? (arXiv:2306.13063). Le chiffre parfois cité de « 87 % de confiance » n’est pas sourçable à un benchmark précis et doit être tenu pour illustratif. https://arxiv.org/abs/2502.11028 [3] Anthropic, « Introducing the Model Context Protocol » (protocole ouvert de connexion des modèles aux outils et données), 25 novembre 2024 ; découverte dynamique des capacités documentée dans la spécification (tools/list, resources/list). https://www.anthropic.com/news/model-context-protocol · https://modelcontextprotocol.io [4] Google, « Announcing the Agent2Agent Protocol (A2A) » (interopérabilité agent-à-agent, complémentaire de MCP), 9 avril 2025 ; protocole reversé à la Linux Foundation, juin 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ [5] Taxonomie in-the-loop / on-the-loop / out-of-the-loop, origine dans la littérature sur les systèmes autonomes : Human Rights Watch & Harvard IHRC, Losing Humanity: The Case Against Killer Robots, 19 novembre 2012 (adaptation aux agents logiciels). https://www.hrw.org/report/2012/11/19/losing-humanity/case-against-killer-robots [6] Dex Horthy / HumanLayer, 12-Factor Agents, Patterns of reliable LLM applications (transposition des « Twelve-Factor App » aux agents ; F11 : « Trigger from anywhere, meet users where they are » ; F13 en mention honorable). https://github.com/humanlayer/12-factor-agents [7] Jian Sheng Wang, AESP: A Human-Sovereign Economic Protocol for AI Agents with Privacy-Preserving Settlement (arXiv:2603.00318, 27 février 2026), invariant « economically capable but never economically sovereign », moteur déterministe à huit vérifications, EIP-712, HKDF. Préprint de proposition, non un standard adopté. https://arxiv.org/abs/2603.00318 [8] Ziling Zhou, Governing Dynamic Capabilities: Cryptographic Binding and Reproducibility Verification for AI Agent Tool Use (arXiv:2603.14332, mars 2026), « capability-identity gap », certificats liés aux capacités (extension X.509), propriétés G1 (intégrité), G2 (vérifiabilité comportementale), G3 (auditabilité). Préprint. https://arxiv.org/abs/2603.14332 [9] Allen Z. Ren et al., Robots That Ask For Help: Uncertainty Alignment for Large Language Model Planners (« KnowNo »), CoRL 2023 (arXiv:2307.01928), prédiction conforme, score de non-conformité 1 − f̂(y|x), escalade vers l’humain si l’ensemble de prédiction n’est pas un singleton. https://arxiv.org/abs/2307.01928 [10] Haiyi Zhu, Canwen Wang, Qing Xiao, Hong Shen (Carnegie Mellon University), Design Principles for Human-Agent Interaction (arXiv:2606.20630, 2026), quatorze principes répartis sur quatre étapes (Initially, During Interaction, Over Time, When Things Go Wrong). https://arxiv.org/abs/2606.20630