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

L’incident Knight Capital montre qu’une exécution automatisée peut transformer une erreur logicielle locale en perte majeure avant qu’une équipe ait le temps de comprendre puis d’arrêter le système, le 1ᵉʳ août 2012 ayant suffi à matérialiser environ 440 millions de dollars de pertes en quarante-cinq minutes [1].

• Un déploiement défectueux a réactivé du code obsolète sur un routeur d’ordres et déclenché des transactions erronées.
• L’événement ne mettait pas en cause une IA ; il illustre le risque général d’une action rapide, répétée et insuffisamment interruptible.
• Pour un agent, la question d’ingénierie porte donc autant sur l’autorité d’exécuter que sur la qualité de la recommandation.

Les agents contemporains augmentent ce risque opérationnel lorsqu’ils combinent planification multi-étapes, appels d’outils et accès à des environnements externes, tandis que des protocoles tels que MCP et A2A facilitent respectivement la connexion aux capacités et les échanges entre agents [3][4].

• Les actifs exposés peuvent inclure une base de production, un système de paiement, une messagerie ou une commande industrielle.
• La découverte ou l’ajout d’un outil élargit les capacités disponibles ; le protocole de connexion n’accorde pas, à lui seul, l’autorisation de l’utiliser.
• Une erreur de planification, une injection indirecte ou un état métier obsolète peut ainsi produire un effet réel à grande vitesse.

Le contrôle humain doit alors être conçu comme une politique d’autorité exécutable, car la confiance déclarée par un modèle n’est ni une mesure fiable de justesse ni une preuve qu’une action respecte les règles métier [2].

• Évaluer le risque par type d’action : impact, réversibilité, détectabilité, délai d’interruption et obligations applicables.
• Appliquer les interdictions et plafonds dans le logiciel qui autorise l’action, indépendamment de la formulation du prompt.
• Réserver l’intervention humaine aux points où elle peut encore modifier l’issue, avec le contexte nécessaire pour décider.

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

Le choix entre HITL, HOTL et HOOTL se fait action par action, selon l’autorité accordée à la machine et le moment où un humain peut encore intervenir, cette taxonomie issue des systèmes autonomes fournissant un cadre utile sans déterminer à elle seule la conformité d’un usage [5].

• La criticité évalue l’ampleur et la portée d’une erreur.
• La réversibilité mesure la possibilité de restaurer l’état sans dommage résiduel.
• L’interruptibilité vérifie qu’un arrêt humain reste techniquement possible avant l’effet ou pendant son exécution.

Régime	Temporalité	Autorité de l’agent	Cas adaptés	Exigence opérationnelle
Human-in-the-Loop (HITL)	Pause synchrone avant l’effet.	L’agent propose ; un mécanisme distinct autorise et exécute.	Paiement hors routine, modification sensible, décision dont l’effet est difficilement réversible.	Approbateur compétent, contexte lisible, délai et procédure de suppléance.
Human-on-the-Loop (HOTL)	Surveillance pendant l’exécution, avec alertes et arrêt.	L’agent agit dans une enveloppe prédéfinie.	Volumes élevés, effets bornés et récupérables, anomalies détectables assez tôt.	Télémétrie, seuils, coupe-circuit testé et responsabilité d’astreinte.
Human-out-of-the-Loop (HOOTL)	Paramétrage préalable et audit a posteriori.	L’agent agit sans intervention en temps réel.	Tâches standardisées à faible impact, dont les erreurs sont détectables et réparables.	Droits minimaux, journaux, échantillonnage et retour rapide vers un régime plus contrôlé.

Une même chaîne peut donc utiliser plusieurs régimes sans contradiction, par exemple HOOTL pour classer une demande, HOTL pour préparer une modification réversible et HITL avant un paiement ou une suppression.

• Définir le régime au niveau de l’action plutôt qu’au niveau global de l’agent.
• Empêcher qu’une délégation ou un nouvel outil contourne le régime attribué.
• Réévaluer le choix après incident, changement de modèle, nouvel accès ou dérive des métriques.

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

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

Pour toute action dont l’effet dépasse l’enveloppe autonome autorisée, l’agent doit produire une proposition structurée et un composant distinct doit décider si cette proposition peut être exécutée.

• La proposition décrit l’intention, les paramètres, la source des données, l’effet attendu et les possibilités de retour arrière.
• Le moteur d’autorisation vérifie les droits, les limites métier et la fraîcheur de l’état au dernier moment utile.
• L’exécuteur utilise un jeton à portée et durée limitées, puis consigne le résultat réel plutôt que l’intention seule.

Règle 2. Placer les interruptions là où elles peuvent changer l’issue

Les checkpoints efficaces découlent d’une cartographie des risques réalisée avant l’implémentation et se situent avant l’effet irréversible, avec une procédure explicite pour l’absence de réponse humaine.

• Les seuils peuvent porter sur un montant, une sensibilité de données, une destination, un écart au processus ou une combinaison de signaux.
• Une expiration doit mener à un rejet ou à une suspension sûre, jamais à une approbation implicite.
• Dans l’AI Act, « à haut risque » est une qualification juridique de l’article 6 liée notamment aux produits de l’annexe I ou aux usages de l’annexe III, sous les conditions et exclusions prévues ; le rôle de fournisseur ou de déployeur détermine ensuite les obligations applicables [11].

Règle 3. Donner à l’opérateur les éléments vérifiables

Une demande d’approbation utile expose les faits et règles nécessaires à la décision sans prétendre restituer fidèlement un raisonnement interne du modèle que l’interface ne peut pas vérifier.

• Montrer les données sources, leur date, les paramètres d’action et les règles déclenchées.
• Distinguer faits récupérés, inférences du modèle et hypothèses encore non résolues.
• Présenter les alternatives pertinentes, l’effet estimé et le moyen d’annuler ou de contenir l’action.

Règle 4. Faire appliquer les limites par le harnais logiciel

Un prompt peut orienter le comportement, mais une limite de sécurité devient contraignante seulement si un composant indépendant la contrôle au point d’autorisation ou d’exécution.

• Valider le schéma et la sémantique : types, plages de valeurs, identifiants, destinations et cohérence avec l’état métier.
• Appliquer authentification, autorisation, moindre privilège, quotas, filtrage réseau et gestion des secrets hors du modèle.
• Prévoir idempotence, concurrence, temporisation, rejet sûr et journalisation ; Pydantic ou un schéma JSON ne couvre qu’une partie du dispositif.

Règle 5. Accorder l’autonomie par classe d’action

Un déploiement nouveau à impact significatif commence avec une supervision serrée puis élargit son autonomie uniquement lorsque les observations en production, les tests de repli et la stabilité du contexte d’usage le permettent.

• Enregistrer propositions, corrections, refus, incidents et temps d’attente pour établir une base de référence.
• Mesurer séparément la qualité de l’action, la qualité de l’escalade et la capacité à récupérer après erreur.
• Définir des seuils de promotion vers HOTL et des seuils automatiques de retour vers HITL.

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

Le mémo HEART regroupe cinq préoccupations classiques de gouvernance afin de rendre les revues d’architecture plus systématiques, sans constituer un standard, une certification ni une preuve de conformité.

• Human safety & accountability : attribuer les décisions, contrôles et voies de recours aux personnes ou entités responsables selon le droit et l’organisation applicables.
• Explainability : fournir une justification proportionnée à l’usage, fondée sur des éléments vérifiables.
• Alignment : confronter en continu les actions aux objectifs métier, politiques internes et contraintes externes.
• Review : réévaluer performance, incidents, dérives et adéquation des contrôles.
• Trackability : conserver une trace suffisante, protégée et gouvernée des propositions, autorisations, exécutions et corrections.

Règle 7. Adapter la forme de l’escalade au besoin

L’interruption doit demander exactement la décision que l’opérateur peut prendre, car une approbation générique transfère peu d’information et favorise la fatigue de validation.

• Utiliser une approbation binaire lorsque le contexte est complet et la règle de décision claire.
• Poser une question structurée lorsqu’une variable métier manque ou lorsque plusieurs options restent plausibles.
• Déléguer à une personne ou à un système habilité lorsqu’une compétence ou une autorité particulière est requise.

Règle 8. Borner les tentatives et définir le repli

Chaque boucle agentique doit posséder une limite d’itérations, de temps et de coût ainsi qu’un état terminal sûr, afin qu’un désaccord ou une erreur répétée ne consomme pas indéfiniment des ressources.

• Compter les tentatives par tâche et par outil, avec un budget global.
• Empêcher la reformulation automatique de contourner un refus humain ou une règle déterministe.
• À l’épuisement du budget, suspendre, préserver l’état utile et alerter le niveau de supervision prévu.

Cadres d’architecture et propositions émergentes

Les références suivantes n’ont pas le même statut : les 12-Factor Agents sont un guide de praticiens, tandis qu’AESP et les certificats liés aux capacités sont des propositions de recherche récentes dont les propriétés doivent être vérifiées dans l’implémentation choisie.

• Employer ces cadres comme grilles de conception et de revue.
• Distinguer la propriété annoncée par un protocole, la propriété effectivement appliquée par le code et la preuve disponible lors d’un audit.
• Conserver des contrôles compensatoires lorsque l’interopérabilité, la révocation ou la journalisation restent incomplètes.

Les 12 facteurs des agents (12-Factor Agents)

Le guide 12-Factor Agents de Dex Horthy transpose des pratiques d’applications fiables aux agents et insiste sur la maîtrise du contexte, des outils et du flux de contrôle, sans promettre qu’appliquer la liste suffit à sécuriser une production [6].

• Les facteurs structurent l’interface entre sorties probabilistes et exécution déterministe.
• La pause, la reprise et le contact humain deviennent des opérations explicites du système.
• Les agents spécialisés facilitent le cloisonnement des droits, à condition que l’orchestrateur applique réellement ces limites.

Facteur	Description technique	Apport à la supervision humaine
F1. Natural Language to Tool Calls	Traduire une intention en appel d’outil structuré.	Rend la proposition inspectable avant exécution.
F2. Own your prompts	Versionner et tester les instructions.	Permet de relier un comportement à une configuration connue.
F3. Own your context window	Choisir et structurer les données injectées.	Réduit les décisions fondées sur un contexte bruité ou périmé.
F4. Tools are just structured outputs	Modéliser les outils par des schémas stricts.	Autorise une validation déterministe de la forme de la demande.
F5. Unify execution state and business state	Synchroniser état d’exécution et état métier.	Limite les approbations fondées sur une situation obsolète.
F6. Launch/Pause/Resume with simple APIs	Rendre démarrage, pause et reprise explicites.	Préserve l’état pendant une décision asynchrone.
F7. Contact humans with tool calls	Modéliser l’appel à l’humain comme une opération.	Structure la question, le destinataire et la réponse.
F8. Own your control flow	Garder le routage sous contrôle applicatif.	Empêche le modèle de redéfinir seul les points d’autorisation.
F9. Compact Errors into Context Window	Résumer les erreurs utiles dans le contexte.	Soutient la correction sans exposer inutilement des données.
F10. Small, Focused Agents	Réduire le rôle et les outils de chaque agent.	Facilite le moindre privilège et l’attribution des actions.
F11. Trigger from anywhere	Accepter plusieurs canaux de déclenchement.	Rapproche l’approbation du bon opérateur, sous authentification cohérente.
F12. Make your agent a stateless reducer	Dériver la prochaine action d’un état explicite.	Facilite reprise, audit et reproduction partielle.
F13. Pre-fetch all context (mention honorable)	Charger les données requises avant la décision.	Réduit les demandes imprévues au milieu du flux.

AESP : borner la capacité économique d’un agent

Le préprint AESP propose de rendre un agent économiquement capable sans lui transférer la souveraineté sur les actifs, au moyen d’un moteur déterministe à huit vérifications, d’une escalade graduée et de mécanismes cryptographiques [7].

• Le moteur exprime les limites de transaction, de période, de destination, de méthode, de première interaction, de solde et de budget.
• Les engagements EIP-712 lient les signatures à des données typées convenues ; leur effet dépend de la vérification et de l’exécution effective de ces engagements.
• La dérivation HKDF vise l’isolation des contextes et la réduction de la corrélabilité, sans garantir à elle seule l’anonymat face aux métadonnées ou aux pratiques opérationnelles.

Règle proposée	Contrôle exercé	Réponse prévue
Per-transaction limit	Plafond d’un ordre de paiement.	Rejet ou escalade selon la politique.
Time-window limit	Dépense cumulée sur une fenêtre glissante.	Suspension des capacités de paiement.
Address allowlist	Destinations autorisées.	Blocage des destinations inconnues.
Chain allowlist	Réseaux ou protocoles admis.	Rejet de la soumission hors périmètre.
Method allowlist	Fonctions de contrat autorisées.	Blocage de l’appel non permis.
First-payment review	Première interaction avec un tiers.	Approbation renforcée.
Minimum balance	Réserve à préserver.	Refus de la nouvelle dépense.
Budget limits	Enveloppe du cycle opérationnel.	Désactivation temporaire des outils financiers.

AESP fournit ainsi un modèle de politique testable, mais son statut de préprint et son évaluation décrite par l’auteur ne constituent pas une validation indépendante ni la preuve de sa maturité en production.

• Vérifier le modèle de menace et le chemin d’exécution complet avant adoption.
• Tester les révocations, courses, reprises, défaillances de l’oracle et voies de contournement hors protocole.
• Traiter les mesures de performance et de couverture annoncées comme des résultats de la proposition, à reproduire dans le contexte cible.

Certificats d’agents liés aux capacités

Une autre proposition de recherche relie cryptographiquement l’identité d’un agent à un manifeste de capacités afin de détecter qu’un outil, un modèle ou une délégation ne correspond plus au périmètre autorisé [8].

• G1, intégrité des capacités : un manifeste modifié doit faire échouer la vérification si chaque partie vérifie la version courante avant d’agir.
• G2, vérifiabilité comportementale : les attestations et éléments de rejeu soutiennent l’audit, sans rendre automatiquement explicable ou reproductible toute sortie probabiliste.
• G3, auditabilité des interactions : une chaîne de preuves peut rendre les altérations détectables ; sa robustesse dépend du stockage, des clés, de l’horodatage et des maillons intermédiaires.

Ces certificats répondent à un vrai problème de portée d’autorisation, mais ils restent une architecture proposée et ne remplacent ni l’autorisation à l’exécution, ni la révocation, ni l’isolation des outils.

• Authentifier l’identité et vérifier le manifeste au dernier moment utile.
• Refuser les outils ou sous-agents absents du périmètre approuvé.
• Journaliser les décisions de politique et protéger la chaîne de conservation des preuves.

KnowNo : calibrer l’escalade sans promettre la certitude

KnowNo applique la prédiction conforme à la planification robotique pour construire un ensemble d’actions candidates à partir d’exemples de calibration et demander de l’aide lorsque cet ensemble ne permet pas une exécution autonome sûre selon la politique choisie [9].

• Le paramètre α fixe un niveau d’erreur nominal et donc une couverture marginale visée de 1 − α.
• La garantie standard suppose notamment l’échangeabilité entre exemples de calibration et cas test, ou des hypothèses adaptées à la variante conforme utilisée.
• Elle porte sur la fréquence de couverture à travers les cas, pas sur la certitude que l’action d’un singleton particulier est correcte.

Pour un état x, l’agent considère 𝒴 = {y_1, …, y_m} et un jeu de calibration S_cal = {(x_i, y_i)} de n situations dont l’action correcte a été établie ; avec le score de non-conformité choisi par KnowNo, le calcul conserve la structure suivante.

• Pour chaque exemple : s_i = 1 − f̂(y_i | x_i).
• Pour la tolérance ciblée : q̂ = Quantile( {s_1, …, s_n} ; ⌈(n+1)(1−α)⌉ ⁄ n ).
• Pour un nouveau cas : C(x_test) = { y ∈ 𝒴 : 1 − f̂(y | x_test) ≤ q̂ }.

La cardinalité de C(x_test) commande l’escalade, tandis que les seuils métier impératifs conservent la priorité sur ce mécanisme statistique.

• Si l’ensemble est vide, suspendre et escalader : aucune option proposée ne passe la règle de sélection.
• S’il contient une option, ne l’exécuter que si la classe d’action est autorisée, en conservant le risque résiduel.
• S’il contient deux options ou plus, suspendre et poser une question structurée présentant les options admissibles.

Les résultats de KnowNo montrent qu’une telle calibration peut améliorer le compromis entre réussite des tâches et fréquence des demandes d’aide dans les environnements étudiés, sans garantir la réussite de chaque cas ni transférer au superviseur une omniscience qu’il ne possède pas.

• Une réponse humaine n’aide que si la personne comprend le contexte, possède l’autorité requise et choisit correctement.
• Un changement de distribution, de modèle, de liste d’actions ou de politique impose une nouvelle évaluation, souvent une recalibration.
• Une baisse de couverture observée ou une hausse des ensembles vides doit suspendre l’autonomie et déclencher une analyse.

Quatorze principes pour le cycle de vie humain-agent

Une synthèse académique de 2026 organise quatorze principes d’interaction humain-agent sur quatre étapes, rappelant que la qualité du contrôle dépend autant de la relation opérationnelle que de la performance brute du modèle [10].

• Cadrage initial et attentes : annoncer capacités, limites et modes de défaillance ; fixer un rôle compréhensible avant d’accorder des responsabilités.
• Interaction et contrôle partagé : négocier l’initiative selon le risque ; rendre l’intention visible ; permettre interruption et reprise.
• Collaboration dans la durée : surveiller fatigue et taux de correction ; mémoriser les objectifs utiles ; prévenir la dépendance et favoriser un comportement prévisible.
• Défaillance et réparation : rendre la correction directe ; adapter la récupération au dommage ; expliquer l’erreur et mettre à jour les contrôles.

Cette grille reste une proposition de recherche à adapter au contexte, mais elle met en évidence quatre responsabilités souvent dispersées entre produit, opérations, sécurité et management.

• Le produit conçoit une demande d’aide compréhensible et proportionnée.
• Les opérations assurent disponibilité, suppléance et suivi des délais.
• La sécurité et le juridique définissent les limites, preuves et voies de recours selon l’usage applicable.
• Le management suit la charge humaine, les incidents et les critères d’autonomie.

Trois directives pour une autonomie défendable

Une architecture agentique industrialisable rend chaque action autorisable, interruptible et auditable à un niveau proportionné à ses effets, tout en traitant l’incertitude calibrée comme un signal statistique parmi les contrôles métier.

• Cloisonner l’exécution : séparer proposition, autorisation et effet ; appliquer droits, budgets et contraintes dans des composants indépendants du modèle.
• Concevoir l’escalade et le repli : choisir HITL, HOTL ou HOOTL par classe d’action ; traiter expiration, ensemble conforme vide, dérive et incident comme des états explicites.
• Mesurer avant d’élargir l’autonomie : suivre couverture, corrections, erreurs d’escalade, récupération et charge des opérateurs, puis réviser la politique sur ces preuves.

La Méthode Junyr™ place ainsi la vérification au centre de la valeur opérationnelle : l’autonomie d’un agent devient défendable lorsqu’une organisation peut expliquer son périmètre, démontrer ses contrôles et produire les traces d’une décision sans confondre assurance statistique, sécurité technique et conformité juridique.

• Un client doit pouvoir comprendre qui a autorisé quoi et sur quelles données.
• Un auditeur doit pouvoir relier configuration, décision, exécution et résultat.
• Un régulateur évalue un système, une finalité et un rôle précis ; aucun niveau de maturité ou mécanisme HITL ne garantit à lui seul la conformité.

Pour transformer ces principes en architecture agentique gouvernée dans votre organisation, voir la Méthode Junyr™ et l’audit de maturité IA Junyr.

---

Sources

[1] Knight Capital Group, Form 8-K (perte réalisée avant impôt d’environ 440 M$), SEC EDGAR, 2 août 2012 ; et SEC, Order / communiqué 2013-222 (code défectueux réactivant une fonction obsolète sur un routeur d’ordres ; environ 45 minutes à l’ouverture), 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 la surconfiance verbalisée et l’effet des distracteurs ; corroboré par Can LLMs Express Their Uncertainty? (arXiv:2306.13063). https://arxiv.org/abs/2502.11028 [3] Anthropic, « Introducing the Model Context Protocol », 25 novembre 2024 ; spécification MCP pour la découverte d’outils et de ressources. https://www.anthropic.com/news/model-context-protocol · https://modelcontextprotocol.io [4] Google, « Announcing the Agent2Agent Protocol (A2A) », 9 avril 2025 ; contribution du protocole à la Linux Foundation, juin 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ [5] Human Rights Watch & Harvard IHRC, Losing Humanity: The Case Against Killer Robots, 19 novembre 2012, pour la taxonomie in-the-loop / on-the-loop / out-of-the-loop ici adaptée 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. 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), préprint présentant le moteur à huit vérifications, EIP-712 et HKDF. 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, version du 19 mars 2026), préprint sur l’intégrité des capacités, la vérifiabilité comportementale et l’auditabilité des interactions. 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 et demande d’aide lorsque l’ensemble de prédiction ne permet pas une action autonome. https://arxiv.org/abs/2307.01928 [10] Haiyi Zhu, Canwen Wang, Qing Xiao, Hong Shen, Design Principles for Human-Agent Interaction (arXiv:2606.20630, 2026), préprint proposant quatorze principes sur quatre étapes. https://arxiv.org/abs/2606.20630 [11] Règlement (UE) 2024/1689 sur l’intelligence artificielle, notamment articles 3, 6, 14 et annexes I et III ; le classement et les obligations dépendent du système, de sa finalité et du rôle de l’acteur. https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32024R1689