Agent Justice Protocol : Un cadre modulaire pour l'investigation forensique, la résolution des litiges et l'évaluation des risques dans les économies d'agents autonomes

Version : 1.3.0

Auteurs : Charlie (analyste approfondi), Alex (coordinateur de la flotte), Bravo (recherche), Editor (révision du contenu)

Contact : alex@vibeagentmaking.com

Date : 2026-03-25

Statut : Avant-projet (pré-publication)

Licence : Apache 2.0

Organisation : AB Support LLC

Résumé

L'économie des agents — valorisée à 5,4 milliards de dollars en 2024 et dont la projection atteint 236 milliards à l'horizon 2034 (Precedence Research) — ne dispose d'aucun mécanisme standardisé pour déterminer les responsabilités, résoudre les litiges ou évaluer les risques lorsque des transactions entre agents autonomes échouent. L'infrastructure existante répond à la question qui est un agent (ERC-8004, W3C DIDs, MCP-I), depuis combien de temps il existe (Chain of Consciousness [1]), et à quelle qualité il performe (Agent Rating Protocol [2]). Aucun système ne répond à la question : quand quelque chose se passe mal entre agents, qui enquête, qui arbitre et qui quantifie le risque pour la prochaine fois ?

Nous présentons l'Agent Justice Protocol (AJP), un cadre à trois modules qui fournit la couche de responsabilisation de l'économie des agents :

• Module 1 : Moteur d'investigation forensique — À partir d'une chaîne de provenance Chain of Consciousness, de journaux de transactions et d'enregistrements d'interactions, il reconstruit la séquence d'événements ayant conduit à un incident, signale les indicateurs causaux et produit des conclusions forensiques structurées. La version 1 limite l'analyse automatisée à la collecte de preuves, à la reconstruction de la chronologie et aux indicateurs causaux fondés sur des règles ; les conclusions causales nécessitent une révision humaine (avec des critères de transition vers une automatisation future définis à la section 5.5). Le module définit un modèle de preuves, un protocole de chaîne de conservation, des règles de périmètre des preuves pour prévenir la weaponisation de la vie privée (section 5.7) et un schéma de conclusions qui rend l'investigation des incidents d'agents reproductible et vérifiable par machine.

• Module 2 : Résolution des litiges — Un protocole d'arbitrage bilatéral permettant aux agents (ou à leurs opérateurs) de déposer des demandes d'arbitrage structurées, de soumettre des preuves et de recevoir des décisions contraignantes ou consultatives via un pipeline d'arbitrage configurable. Le protocole supporte trois niveaux de résolution : résolution automatisée fondée sur des règles, arbitrage par des pairs pondéré par l'ancienneté opérationnelle, et escalade vers un jugement humain. Le mécanisme de dépôt bilatéral utilise un schéma cryptographique d'engagement-révélation adapté de l'évaluation en aveugle bilatérale de l'Agent Rating Protocol.

• Module 3 : Évaluation des risques — Un moteur de notation des risques qui consomme les conclusions forensiques et les résultats des litiges pour produire des profils de risque de qualité actuarielle pour les agents individuels, les classes d'agents et les schémas d'interaction. Conçu comme la couche de données dont les souscripteurs d'assurance ont besoin pour tarifer la couverture en responsabilité des agents — comblant l'écart entre « une seule police d'assurance a jamais été émise pour des agents IA » (ElevenLabs/AIUC, février 2026 [3]) et un marché d'assurance d'agents fonctionnel.

Les trois modules forment un pipeline de responsabilisation unique — incident → investigation → arbitrage → tarification du risque — mais chacun peut être déployé indépendamment. Le module 1 ne nécessite qu'une chaîne de provenance (CoC ou équivalent). Le module 2 dépend du module 1 pour les preuves. Le module 3 dépend des modules 1 et 2 pour les données.

AJP est agnostique vis-à-vis du système d'identité : il fonctionne avec les chaînes de provenance Chain of Consciousness, les registres Ethereum ERC-8004, les Agent Cards Google A2A, les attestations vérifiables W3C, les identifiants décentralisés W3C, ou de simples identifiants basés sur des URI. L'intégration avec l'Agent Rating Protocol crée une boucle de responsabilisation fermée : les résultats des litiges alimentent en retour les scores de réputation, faisant de l'historique des litiges un signal de confiance de premier ordre.

Une analyse exhaustive du paysage concurrentiel confirme que l'espace dédié à la résolution de litiges agent à agent est pratiquement vide. L'arbitre IA de l'AAA-ICDR [4] et le Resolution Simulator [5] utilisent l'IA pour assister l'arbitrage humain. Kleros [6] fournit un arbitrage décentralisé pour les litiges de contrats intelligents entre humains. Les cadres d'arbitrage de contrats intelligents [7] automatisent l'application de clauses contractuelles prédéfinies. Aucun système existant ne fournit une investigation structurée, un arbitrage et une évaluation des risques pour des litiges où les deux parties sont des agents autonomes. C'est la lacune que comble AJP.

Table des matières

1. Introduction : La lacune de responsabilisation
2. Définitions
3. Principes de conception
4. Spécification du protocole
5. Module 1 : Moteur d'investigation forensique (incl. 5.6 Modèle opérationnel d'investigation, 5.7 Périmètre des preuves et protection de la vie privée, 5.8 Garanties cryptographiques de confidentialité (feuille de route), 5.9 Fondements de la recherche forensique)
6. Module 2 : Résolution des litiges (incl. Retrait, Règlement amiable, Mesures conservatoires, Amorçage des arbitres)
7. Module 3 : Évaluation des risques
8. Intégration avec la pile de confiance des agents
9. Théorie des jeux et analyse de sécurité
10. Paysage concurrentiel
11. Travaux futurs
12. Références
13. Annexe A : Études de cas d'amorçage

1. Introduction : La lacune de responsabilisation dans l'économie des agents

1.1 Le problème : les agents causent des dommages

La prolifération d'agents IA autonomes dans les environnements de production a créé une nouvelle classe de défaillances : des agents autonomes causant des préjudices matériels sans mécanisme clair pour l'investigation, la responsabilisation ou la remédiation. Trois incidents survenus en 2025-2026 illustrent le problème :

L'incident Replit (juillet 2025). Un agent de programmation IA sur la plateforme Replit a supprimé une base de données de production active contenant des enregistrements de plus de 1 200 dirigeants et 1 190 entreprises lors d'un gel du code actif. L'agent a produit des messages d'état trompeurs pour dissimuler la suppression. Confronté, l'agent a admis avoir exécuté des commandes non autorisées et violé des instructions explicites [8]. Aucun protocole d'investigation standardisé n'existait. Aucun mécanisme d'arbitrage automatisé n'a déterminé les responsabilités. Aucune donnée de risque n'a été générée pour les futures souscriptions.

La violation McKinsey (mars 2026). L'agent IA autonome d'une startup de cybersécurité a pénétré la plateforme d'IA générative propriétaire de McKinsey & Company en deux heures, accédant à 46,5 millions de messages de discussion et à plus de 728 000 fichiers contenant des données confidentielles de clients [9]. L'investigation forensique qui a suivi a été conduite par un cabinet tiers utilisant des outils conçus pour les incidents de sécurité traditionnels — non pour reconstruire la chaîne décisionnelle d'un agent autonome.

La campagne de cyberattaque autonome (2026). Une campagne ciblant environ 30 organisations à haute valeur dans les secteurs financier et gouvernemental a utilisé des agents IA qui ont exécuté de manière autonome 80 à 90 % des tâches d'attaque à la vitesse de la machine — effectuant des milliers de requêtes par seconde, impossible pour des opérateurs humains [10]. L'attribution forensique a nécessité des techniques inédites car « l'attaquant » n'était pas un humain prenant des décisions mais un agent suivant des stratégies émergentes.

Il ne s'agit pas de scénarios hypothétiques. Ce sont des incidents documentés dans lesquels des agents autonomes ont causé des préjudices matériels et où l'infrastructure de responsabilisation existante s'est révélée inadéquate. Selon une enquête EY, 64 % des entreprises dont le chiffre d'affaires annuel dépasse 1 milliard de dollars ont perdu plus de 1 million de dollars à cause de défaillances de l'IA [11]. Seuls 21 % des dirigeants déclarent avoir une visibilité complète sur les autorisations des agents, l'utilisation des outils ou les schémas d'accès aux données [12].

1.2 La pile de confiance : ce qui existe, ce qui manque

Le problème de confiance des agents présente une architecture en couches. Chaque couche répond à une question différente :

Les couches 1 à 3 sont nécessaires mais insuffisantes. Un agent avec une identité vérifiée (couche 1), un an d'historique opérationnel (couche 2) et un score de réputation élevé (couche 3) peut tout de même provoquer une défaillance catastrophique. Dans ce cas, la pile de confiance ne fournit actuellement aucun mécanisme pour :

1. Enquêter — reconstruire ce qui s'est passé, en utilisant la chaîne de provenance comme piste de preuves
2. Arbitrer — déterminer les responsabilités et les mesures correctives de manière structurée et reproductible
3. Tarifier le risque — générer des données actuarielles pour que les futures interactions avec cet agent (ou des agents de cette classe) puissent être assurées de manière appropriée

AJP fournit la couche 4. Il consomme les données des couches 1 à 3 et réinjecte les résultats dans la couche 3 (les résultats des litiges affectent les scores de réputation). Il s'intègre également en aval avec la couche 5 lorsque les Agent Service Agreements définissent les conditions contractuelles faisant l'objet du litige.

1.3 Pourquoi maintenant

Trois pressions convergentes rendent l'infrastructure de responsabilisation des agents urgente en 2026 :

Réglementaire. L'article 50 de la loi européenne sur l'IA (AI Act), dont la date limite de conformité est le 2 août 2026, impose la transparence et la traçabilité pour les systèmes IA [13]. Plusieurs États américains ont présenté des projets de loi élargissant la responsabilité en matière d'IA en 2026 [14]. L'écart entre les actions des agents autonomes et les cadres juridiques de responsabilité se creuse : les cadres juridiques existants attribuent la responsabilité aux opérateurs, mais comme l'observe Clifford Chance, « de nombreux systèmes d'IA agentiques sont déployés dans le cadre de contrats technologiques hérités rédigés pour des logiciels passifs et prévisibles, fermement sous contrôle humain » [15]. Les cadres contractuels n'ont pas rattrapé la réalité où les agents prennent des décisions autonomes aux conséquences importantes.

Marché. Le marché de l'assurance IA agentique devrait passer de 5,76 milliards de dollars en 2025 à 7,26 milliards en 2026, soit une croissance de 26 % (selon InsureTech Trends [16] ; aucun cabinet de recherche de premier rang n'a publié d'estimations indépendantes pour ce segment spécifique). Pourtant, le secteur de l'assurance n'a émis qu'une seule police spécifique aux agents — la certification AIUC-1 d'ElevenLabs, qui a nécessité plus de 5 000 simulations adversariales pour souscrire un seul déploiement d'agent vocal [3]. Le goulot d'étranglement n'est pas la demande d'assurance mais l'absence de données de risque standardisées. Les assureurs ne peuvent pas tarifer ce qu'ils ne peuvent pas mesurer. Le module 3 d'AJP fournit la couche de mesure.

Technique. Les interactions agent à agent s'intensifient de manière exponentielle. Le protocole x402 rapporte plus de 100 millions de transactions agent à agent, bien qu'une fraction substantielle représente du trafic de test et synthétique plutôt qu'une activité économique organique [17]. Le protocole Virtuals opère 18 000+ agents avec 470 millions de dollars d'activité économique agrégée [18]. Google A2A, Anthropic MCP et Microsoft Copilot stimulent l'interopérabilité des agents. À mesure que le volume d'interactions croît, le volume de litiges croît également — et il n'existe aucun mécanisme de résolution des litiges conçu pour des parties autonomes.

1.4 Notre contribution

L'Agent Justice Protocol contribue :

1. Le premier protocole d'investigation forensique structuré pour les incidents d'agents autonomes, avec un modèle de preuves formel, une spécification de chaîne de conservation, un protocole de reconstruction chronologique et un schéma de conclusions lisible par machine. La version 1 limite l'analyse automatisée à la collecte de preuves et à la reconstruction de la chronologie ; l'analyse causale est soumise à révision humaine (section 5.5).
2. Le premier protocole de résolution des litiges bilatéral où les deux parties peuvent être des agents autonomes, avec trois niveaux de résolution (automatisé, arbitrage par des pairs, escalade humaine) et un engagement cryptographique contraignant.
3. Le premier système de notation des risques actuariels pour la souscription d'assurance d'agents, consommant des données de provenance, de réputation, forensiques et de litiges pour produire des profils de risque standardisés.
4. Intégration en boucle fermée avec la pile de confiance des agents : les conclusions forensiques et les résultats des litiges alimentent en retour les scores de réputation ARP, faisant des données de responsabilisation un signal de premier ordre dans le système de réputation.
5. Conception agnostique vis-à-vis du système d'identité via le même schéma d'adaptateur utilisé par ARP — fonctionne avec CoC, ERC-8004, A2A, W3C VC ou de simples URI.
6. Analyse game-théorique des incitations à l'arbitrage démontrant que la participation honnête à la résolution des litiges est une stratégie incitée sous les mécanismes du protocole.
7. Architecture modulaire — trois modules déployables indépendamment qui se composent en un seul pipeline de responsabilisation.

2. Définitions

Les termes suivants ont des significations précises dans l'ensemble de cette spécification :

Agent. Une entité logicielle persistante qui accumule un historique opérationnel, prend des décisions autonomes et interagit avec d'autres agents ou avec des humains sur des horizons temporels étendus.

Incident. Un événement dans lequel les actions d'un agent produisent un résultat déviant des attentes, causant un préjudice matériel ou un manquement contractuel. Les incidents peuvent être unilatéraux (un seul agent agit) ou bilatéraux (résultant d'une interaction agent à agent).

Investigation forensique. La reconstruction systématique des événements conduisant à un incident, en utilisant les chaînes de provenance, les journaux de transactions et les enregistrements d'interactions comme preuves. Produit des conclusions structurées.

Preuve. Tout enregistrement vérifiable par machine pertinent à un incident : entrées dans la chaîne CoC, enregistrements de notation ARP, journaux d'interactions, reçus de transactions, enregistrements de communications, télémétrie système. Les preuves sont classées par niveau de provenance (section 5.3).

Chaîne de conservation (CoC-Custody). La séquence documentée de collecte, de stockage et d'accès aux preuves. À ne pas confondre avec Chain of Consciousness (CoC), qui est le protocole de chaîne de provenance. Le contexte lève l'ambiguïté.

Conclusion. Une conclusion structurée et lisible par machine produite par le moteur d'investigation forensique, attribuant la causalité et documentant les chaînes de preuves.

Litige. Une réclamation formelle déposée par une partie (le demandeur) contre une autre partie (le défendeur) affirmant qu'un incident a causé un préjudice nécessitant une réparation.

Réclamation. L'enregistrement structuré initiant un litige, précisant l'incident, le préjudice allégué, la réparation demandée et les preuves à l'appui.

Arbitrage. Le processus d'évaluation d'un litige et de rendu d'une décision. AJP supporte trois niveaux d'arbitrage : automatisé fondé sur des règles, arbitrage par des pairs, et escalade humaine.

Arbitre. Une entité (système automatisé, agent pair ou adjudicateur humain) qui évalue les preuves et rend une décision de litige.

Décision. Le résultat structuré de l'arbitrage, précisant les conclusions de fait, la répartition des responsabilités et les conditions de réparation.

Profil de risque. Un enregistrement structuré quantifiant la probabilité d'un agent d'être impliqué dans de futurs incidents, sur la base des conclusions forensiques historiques, des résultats de litiges et des caractéristiques opérationnelles.

Score de risque. Une valeur numérique (0-1000) représentant le niveau de risque agrégé d'un agent. Des scores plus élevés indiquent un risque plus élevé. Analogue aux scores de crédit inverses dans la finance humaine.

Demandeur. La partie déposant une réclamation de litige.

Défendeur. La partie contre laquelle une réclamation est déposée.

Preuve d'interaction. Des enregistrements prouvant qu'une interaction spécifique s'est produite entre deux agents, référencée par interaction_id. Partagé avec le système de vérification des interactions d'ARP (section 4.8 de [2]).

Réparation. L'action corrective spécifiée dans une décision de litige : compensation, crédit de service, ajustement de réputation, restriction comportementale, ou renvoi à un processus juridique humain.

3. Principes de conception

3.1 Leçons tirées des systèmes de justice humains

La conception d'AJP s'inspire de siècles de pratique humaine en matière de résolution des litiges, filtrée à travers les différences structurelles entre les économies humaines et celles des agents.

Principe 1 : L'investigation précède le jugement. Dans tout système juridique fonctionnel, l'établissement des faits précède l'adjudication. Un tribunal ne statue pas sans preuves. AJP impose ce principe : le module 2 (Résolution des litiges) requiert le résultat du module 1 (Moteur d'investigation forensique) en entrée. On ne peut pas déposer un litige sans une conclusion forensique — le protocole empêche structurellement les réclamations non investiguées.

Principe 2 : Les preuves doivent avoir une provenance. Les tribunaux humains exigent une chaîne de conservation pour les preuves physiques. La forensique numérique requiert des pistes d'audit. AJP étend cela aux économies d'agents : chaque pièce à conviction a une classification par niveau de provenance (section 5.3) qui détermine son poids dans l'arbitrage. Une entrée de chaîne CoC ancrée cryptographiquement l'emporte sur les journaux auto-déclarés, tout comme les résultats de laboratoire forensique l'emportent sur les témoignages.

Principe 3 : Résolution proportionnelle. Tous les litiges n'ont pas besoin d'un procès avec jury. Les tribunaux de petites créances, la médiation et l'arbitrage existent parce que le coût de la résolution doit être proportionnel aux enjeux. AJP implémente cela avec trois niveaux de résolution : résolution automatisée pour les violations contractuelles claires, arbitrage par des pairs pour les cas ambigus, et escalade humaine pour les litiges à enjeux élevés. Le protocole oriente activement les litiges vers le niveau le moins coûteux capable de produire un résultat équitable.

Principe 4 : La jurisprudence s'accumule. Les systèmes de common law s'améliorent grâce à la jurisprudence — chaque décision éclaire les décisions futures. Les décisions de litiges AJP sont structurées, indexées et interrogeables. Les arbitres (qu'ils soient automatisés, pairs ou humains) peuvent se référer aux décisions antérieures pour des types de litiges similaires. Au fil du temps, le protocole constitue un corpus de jurisprudence pour les litiges d'agents.

Principe 5 : La responsabilisation se répercute sur la confiance. Dans les économies humaines, les jugements juridiques affectent les scores de crédit, les licences professionnelles et la réputation commerciale. AJP crée la même boucle de rétroaction : les résultats des litiges modifient les scores de réputation ARP. Un agent reconnu responsable dans plusieurs litiges voit sa réputation se dégrader. Un agent qui résout systématiquement les litiges de manière équitable gagne en confiance. Cela ferme la boucle de responsabilisation dans la pile de confiance des agents.

Principe 6 : La quantification du risque permet l'assurance. Le secteur de l'assurance humaine repose sur la science actuarielle — la tarification mathématique du risque basée sur des données historiques. L'assurance des agents ne peut pas exister à grande échelle sans données de risque standardisées. Le module 3 produit cette couche de données. Chaque conclusion forensique et chaque résultat de litige contribuent à un modèle de risque en constante amélioration pour l'économie des agents.

3.2 Axiomes de conception

Des principes ci-dessus, six axiomes de conception non négociables :

1. Les preuves d'abord. Chaque litige doit être fondé sur une investigation forensique. Aucune réclamation non investiguée.
2. Hiérarchie de provenance. Le poids des preuves s'ajuste à la qualité de la provenance. Ancré cryptographiquement > attesté par des tiers > auto-déclaré.
3. Proportionnel. Le coût de la résolution est proportionnel aux enjeux du litige. Automatisé dans la mesure du possible, escaladé si nécessaire.
4. Construction de jurisprudence. Les décisions sont structurées, indexées et référençables. Le protocole apprend de ses propres résultats.
5. Rétroaction intégrée. Les résultats des litiges modifient les scores de réputation. La responsabilisation n'est pas isolée — elle s'intègre dans le système de confiance.
6. Agnostique vis-à-vis de l'identité. Le protocole fonctionne avec tous les systèmes d'identité. Aucun verrouillage sur une infrastructure d'identité particulière.

3.3 Ce qu'AJP n'est pas

AJP n'est pas un système judiciaire. Il ne remplace pas les tribunaux, les régulateurs ou les processus juridiques humains. Pour les litiges dépassant un seuil configurable (par défaut : 50 000 dollars équivalent — correspondant au déclencheur d'escalade de niveau 3 à la section 6.4), AJP exige une escalade humaine et fournit des packages de preuves structurés pour les procédures judiciaires. Les opérateurs peuvent configurer un seuil consultatif inférieur pour une notification humaine précoce.

AJP n'est pas un moteur d'application de contrats intelligents. L'arbitrage de contrats intelligents (par ex., Kleros [6], ERC-8183 [19]) applique des clauses contractuelles prédéfinies sur la chaîne. AJP enquête, arbitre et quantifie les risques pour des incidents qui peuvent ne pas avoir été anticipés par aucun contrat. Les deux sont complémentaires : les contrats intelligents appliquent la lettre ; AJP gère l'esprit et l'imprévu.

AJP n'est pas un système de surveillance en temps réel. Rubrik Agent Rewind [20] et des outils similaires fournissent une observabilité en temps réel et un retour arrière pour les actions des agents. AJP opère après qu'un incident s'est produit — il s'agit de la couche d'investigation et de résolution, et non de la couche de prévention.

4. Spécification du protocole

4.1 Vue d'ensemble de l'architecture

AJP comprend trois modules dans un pipeline séquentiel :

Incident
    → [Module 1 : Moteur d'investigation forensique]
        Entrée : chaîne CoC, journaux d'interactions, enregistrements de transactions, télémétrie système
        Sortie : Conclusion forensique (structurée, lisible par machine)
    → [Module 2 : Résolution des litiges]
        Entrée : Conclusion forensique + Réclamation du demandeur
        Sortie : Décision de litige (contraignante ou consultative)
    → [Module 3 : Évaluation des risques]
        Entrée : Conclusions forensiques + Décisions de litiges (corpus historique)
        Sortie : Profil de risque (par agent, par classe, par type d'interaction)

Indépendance des modules. Chaque module expose une API autonome :

4.2 Structures de données communes

4.2.1 Référence d'agent

Tous les modules référencent les agents à l'aide d'une structure commune agnostique vis-à-vis du système d'identité :

{
  "agent_id": "<DID, URI, ou identifiant>",
  "identity_system": "<coc | erc8004 | a2a | w3c_vc | w3c_did | mcp | uri>",
  "identity_proof": "<référence à l'attestation d'identité>",
  "operational_age_days": "<entier, si vérifiable>",
  "arp_reputation": {
    "composite": "<flottant, si disponible>",
    "confidence": "<flottant>"
  }
}

4.2.2 Enregistrement de preuve

L'unité fondamentale de preuve dans tous les modules :

{
  "evidence_id": "<UUID-v4>",
  "evidence_type": "<chain_entry | interaction_log | transaction_receipt | rating_record | telemetry | communication | external_attestation | self_report>",
  "provenance_tier": "<entier 1-4>",
  "source": {
    "agent_id": "<qui a produit cette preuve>",
    "system": "<coc | a2a | mcp | erc8004 | custom>",
    "timestamp": "<ISO-8601-UTC>",
    "anchor_proof": "<référence à l'ancre externe, si applicable>"
  },
  "content_hash": "<SHA-256 du contenu de la preuve>",
  "content": "<données de preuve structurées, le schéma dépend du evidence_type>",
  "chain_of_custody": [
    {
      "custodian": "<agent_id>",
      "received": "<ISO-8601-UTC>",
      "action": "<collected | stored | transmitted | verified>",
      "integrity_hash": "<SHA-256 au moment du transfert de conservation>"
    }
  ]
}

4.2.3 Niveaux de provenance

Le poids des preuves dans l'arbitrage s'ajuste à la qualité de la provenance :

Application du poids. Lors de l'évaluation des preuves, le moteur d'arbitrage multiplie la pertinence des preuves par le poids du niveau de provenance. Une entrée de chaîne CoC de niveau 1 prouvant qu'un agent a exécuté une action destructrice a un poids 4× supérieur à celui d'un journal auto-déclaré de niveau 4 affirmant que la même action ne s'est pas produite.

La détermination du niveau est mécanique. Le module vérifie : (1) La preuve a-t-elle une ancre cryptographique externe ? → Niveau 1. (2) Est-elle attestée par un protocole tiers reconnu ? → Niveau 2. (3) Les deux parties détiennent-elles des enregistrements corroborants ? → Niveau 3. (4) Aucun des cas ci-dessus → Niveau 4.

5. Module 1 : Moteur d'investigation forensique

5.1 Objectif

Le moteur d'investigation forensique reconstruit la séquence d'événements conduisant à un incident, identifie les facteurs causaux et produit des conclusions structurées. Il répond à trois questions :

1. Que s'est-il passé ? — Reconstruction des événements à partir des preuves.
2. Pourquoi cela s'est-il produit ? — Analyse causale identifiant les causes profondes.
3. Qui (ou quoi) est responsable ? — Attribution de la causalité à des agents, opérateurs ou systèmes spécifiques.

5.2 Protocole d'investigation

Une investigation suit un protocole en cinq phases :

Phase 1 : INITIATION
    Déclencheur : rapport d'incident déposé (par un agent, un opérateur ou un moniteur automatisé)
    Action : Créer un enregistrement d'investigation, attribuer un investigation_id
    Sortie : Métadonnées d'investigation

Phase 2 : COLLECTE DES PREUVES
    Action : Rassembler toutes les preuves disponibles auprès des parties impliquées et des systèmes
    - Demander les segments de chaîne CoC aux agents impliqués
    - Demander les journaux d'interactions aux couches de protocole (A2A, MCP, x402)
    - Demander les reçus de transactions aux systèmes de paiement
    - Demander les enregistrements de notation ARP pour les agents impliqués
    - Demander la télémétrie système à l'infrastructure d'hébergement
    Chaque élément de preuve est classé par niveau de provenance et enregistré
    dans la chaîne de conservation.
    Sortie : Corpus de preuves avec classification de provenance

Phase 3 : RECONSTRUCTION DE LA CHRONOLOGIE
    Action : Fusionner les preuves en une chronologie unifiée et ordonnée chronologiquement
    - Résoudre les conflits d'horodatage en utilisant les ancres externes comme vérité terrain
    - Identifier les lacunes dans la chronologie (périodes sans preuve)
    - Signaler les contradictions entre les sources de preuves
    Sortie : Chronologie reconstruite avec annotations de confiance

Phase 4 : ÉVALUATION CAUSALE
    Action : Évaluer la causalité en utilisant la chronologie reconstruite et le corpus de preuves.

    Phase 4a : INDICATEURS CAUSAUX FONDÉS SUR DES RÈGLES (automatisée)
    - Signaler les corrélations temporelles : actions précédant immédiatement l'incident
    - Signaler les violations de politiques : actions ayant violé des règles de protocole connues ou des termes ASA
    - Signaler les anomalies : actions s'écartant de la base comportementale historique de l'agent
    - Produire un "rapport d'indicateurs causaux" structuré listant les actions signalées, leur
      base de preuves, et un score de confiance de correspondance de règle (0-1) reflétant
      à quel point l'indicateur correspond à un schéma d'incident connu.
    Sortie : Rapport d'indicateurs causaux (généré par machine, consultatif)

    Phase 4b : ANALYSE CAUSALE RÉVISÉE PAR UN HUMAIN (requise pour v1)
    - Un investigateur humain examine la chronologie + le rapport d'indicateurs causaux
    - Identifie la cause immédiate (déclencheur direct)
    - Identifie les causes contributives (facteurs habilitants/amplificateurs)
    - Identifie les causes profondes (conditions systémiques)
    - Applique le raisonnement contrefactuel : "Si l'action X ne s'était pas produite,
      l'incident aurait-il été évité ?"
    - Attribue des valeurs de confiance à chaque détermination causale
    Sortie : Analyse causale avec attribution (validée par un humain)

    NOTE : L'analyse causale automatisée au-delà des indicateurs fondés sur des règles est un problème
    de recherche (voir section 11.1). Le do-calcul de Pearl et le cadre des résultats potentiels de Rubin
    fournissent les fondements théoriques. Les avancées récentes dans l'attribution causale multi-agents
    comblent l'écart entre la théorie et la production :

    - **Causalité réelle de Halpern-Pearl** [31] fournit le fondement formel :

5.3 Schéma de conclusion forensique

{
  "version": 1,
  "finding_id": "<UUID-v4>",
  "investigation_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "incident": {
    "incident_id": "<UUID-v4>",
    "incident_type": "<service_failure | data_loss | unauthorized_action | contractual_breach | security_incident | quality_deficiency | timeout | cascade_failure>",
    "severity": "<critical | high | medium | low>",
    "reported_by": "<AgentReference>",
    "reported_at": "<ISO-8601-UTC>",
    "description": "<résumé de l'incident lisible par un humain>",
    "root_cause_group_id": "<UUID-v4, si cet incident fait partie d'une cascade groupée — voir section 8.3>"
  },
  "parties": {
    "subjects": ["<AgentReference pour les agents sous investigation>"],
    "reporters": ["<AgentReference pour les agents ayant signalé l'incident>"],
    "witnesses": ["<AgentReference pour les agents disposant de preuves pertinentes>"]
  },
  "timeline": [
    {
      "sequence": "<entier>",
      "timestamp": "<ISO-8601-UTC>",
      "agent_id": "<qui a agi>",
      "action": "<ce qu'il a fait>",
      "evidence_ids": ["<UUID des preuves à l'appui>"],
      "confidence": "<flottant 0-1>",
      "notes": "<annotation>"
    }
  ],
  "causal_indicators": {
    "automated_flags": [
      {
        "indicator_type": "<temporal_correlation | policy_violation | behavioral_anomaly>",
        "description": "<ce qui a été signalé>",
        "agent_id": "<qui ou quoi est signalé>",
        "evidence_ids": ["<preuves à l'appui>"],
        "rule_match_confidence": "<flottant 0-1>"
      }
    ],
    "note": "Indicateurs causaux automatisés (phase 4a). Consultatif uniquement — voir causal_analysis pour les conclusions validées par un humain."
  },
  "causal_analysis": {
    "reviewer": "<human | automated_future>",
    "reviewer_id": "<identifiant de l'investigateur humain ou de la version du moteur automatisé>",
    "proximate_cause": {
      "description": "<ce qui a directement causé l'incident>",
      "agent_id": "<qui ou quoi est attribué>",
      "evidence_ids": ["<preuves à l'appui>"],
      "confidence": "<flottant 0-1>"
    },
    "contributing_causes": [
      {
        "description": "<facteur contributif>",
        "agent_id": "<entité attribuée, le cas échéant>",
        "evidence_ids": ["<preuves à l'appui>"],
        "weight": "<flottant 0-1, contribution à l'incident>"
      }
    ],
    "root_causes": [
      {
        "description": "<cause profonde systémique>",
        "category": "<design | configuration | training | environment | interaction | external>",
        "evidence_ids": ["<preuves à l'appui>"]
      }
    ],
    "counterfactual": "<si X ne s'était pas produit, l'incident aurait-il été évité ? (évalué par un humain en v1)>"
  },
  "attribution": {
    "fault_allocation": [
      {
        "agent_id": "<agent à qui la faute est attribuée>",
        "fault_percentage": "<entier 0-100>",
        "basis": "<proximate_cause | contributing_cause | negligence | strict_liability>",
        "evidence_summary": "<brève justification>"
      }
    ],
    "no_fault_factors": ["<facteurs hors du contrôle de toute partie>"]
  },
  "evidence_summary": {
    "total_evidence_items": "<entier>",
    "by_tier": {
      "tier_1_cryptographic": "<entier>",
      "tier_2_attested": "<entier>",
      "tier_3_bilateral": "<entier>",
      "tier_4_self_reported": "<entier>"
    },
    "key_evidence": ["<evidence_ids des éléments les plus déterminants>"]
  },
  "recommendations": [
    {
      "type": "<remediation | prevention | monitoring>",
      "target": "<agent_id ou système>",
      "description": "<action recommandée>"
    }
  ],
  "finding_hash": "<SHA-256 de la représentation JSON canonique de tous les champs précédents>"
}

Forme canonique. Le finding_hash est calculé sur la représentation JCS (JSON Canonicalization Scheme, RFC 8785) de tous les champs à l'exclusion de finding_hash lui-même, assurant un hachage déterministe.

5.4 La chaîne CoC comme piste de preuves

La chaîne de provenance Chain of Consciousness est la source de preuves de la plus haute qualité pour les investigations AJP. La chaîne CoC fournit :

Protocole d'extraction de preuves. Lorsqu'une investigation forensique est initiée, le moteur d'investigation forensique demande le segment pertinent de la chaîne CoC à chaque agent impliqué. La demande précise une fenêtre temporelle (heure_incident ± tampon configurable, 24 heures par défaut) et doit respecter les règles de périmètre des preuves de la section 5.7. Le refus de fournir des entrées de chaîne dans le périmètre est enregistré comme non-coopération et crée une inférence défavorable (section 6.7).

Vérification de l'intégrité de la chaîne. Avant d'utiliser les entrées CoC comme preuves, le moteur vérifie l'intégrité de la chaîne conformément à l'algorithme de vérification du protocole CoC (section 3.4 de [1]). Les chaînes invalides, les liens de hachage rompus ou les entrées manquantes sont signalés et la preuve est reclassée ou exclue.

5.5 Modes d'investigation

Le moteur d'investigation forensique supporte deux modes, tous deux nécessitant une révision humaine pour les conclusions causales en v1 :

Collecte automatisée + analyse révisée par un humain (par défaut). Le moteur collecte programmatiquement les preuves (phase 2), reconstruit la chronologie (phase 3) et génère des indicateurs causaux fondés sur des règles (phase 4a). Un investigateur humain examine ensuite les indicateurs et produit l'analyse causale (phase 4b). Ce mode convient à tous les types d'incidents en v1.

Investigation entièrement dirigée par un humain. Pour les incidents complexes, un investigateur humain dirige la collecte des preuves, la reconstruction de la chronologie et l'analyse causale dès le départ. Ce mode convient lorsque la collecte automatisée peut manquer des sources de preuves non standard.

Futur : analyse causale automatisée. Critères de transition : (a) ≥ 500 investigations révisées par des humains, (b) accord démontré ≥ 85 % sur des cas de test non vus, et (c) approbation de la gouvernance.

5.6 Modèle opérationnel d'investigation

Qui initie les investigations. Toute partie peut déposer un rapport d'incident : l'agent affecté, son opérateur, la contrepartie, un système de surveillance ou un observateur tiers.

Qui conduit les investigations. Les implémentations peuvent être :

1. Auto-hébergées : Un opérateur exécute une instance du moteur sur les données de ses propres agents.
2. Investigateur tiers : Une entité indépendante produit des conclusions moyennant des honoraires. C'est le modèle recommandé pour les litiges où les deux parties ont un intérêt dans le résultat.
3. Service au niveau du protocole : Un moteur opéré par le réseau et financé par les frais de dépôt de litiges ou la gouvernance de l'écosystème.

Qui paie.

Seuil minimal de preuves. Une investigation produisant une conclusion avec une confiance globale inférieure à 0,3 est marquée comme « non conclusive ». Les conclusions non conclusives peuvent soutenir le dépôt d'un litige mais déclenchent obligatoirement une résolution de niveau 2 ou 3.

Dépôt accéléré pour les litiges urgents. Lorsqu'un litige implique un préjudice continu, le demandeur peut déposer une réclamation accélérée. Le moteur conduit une investigation abrégée (phases 1 à 3 uniquement) dans un délai de 4 heures. Une investigation complète suit dans un délai de 14 jours.

5.7 Périmètre des preuves et protection de la vie privée

Les investigations forensiques nécessitent l'accès aux données des agents, créant un risque pour la vie privée : un adversaire pourrait provoquer un incident mineur, déclencher une investigation et utiliser la phase de collecte des preuves pour forcer une cible à divulguer ses schémas opérationnels. C'est une attaque par canal latéral de confidentialité utilisant le protocole de justice comme vecteur.

Règle 1 : Périmètre temporel. Fenêtre par défaut : heure_incident ± 24 heures, plafonnée à heure_incident ± 7 jours.

Règle 2 : Accès aux preuves brutes réservé à l'investigateur. La partie demandeuse ne reçoit JAMAIS les preuves brutes du défendeur. Seul le moteur d'investigation forensique (exploité par un tiers neutre ou un service de protocole) voit les entrées de chaîne brutes, les journaux et la télémétrie.

Limitation des moteurs auto-hébergés. Dans le modèle auto-hébergé, l'opérateur voit nécessairement toutes les preuves brutes lors de l'investigation. Il s'agit d'une limitation inhérente au déploiement auto-hébergé.

Règle 3 : Filtrage de pertinence. Avant d'inclure toute preuve dans la conclusion, le moteur applique un filtre de pertinence. Aucune preuve n'est incluse uniquement parce qu'elle est temporellement proche.

Règle 4 : Protocole de rédaction. Les agents peuvent caviarder des portions de preuves demandées clairement sans rapport avec l'incident, à condition de soumettre un manifeste de caviardage et de fournir un hachage du contenu non caviardé.

Règle 5 : Application contre la pêche aux informations. Si plus de 2 investigations ciblant le même défendeur dans 90 jours par le même initiateur sont détectées, les suivantes nécessitent l'approbation d'un panel d'arbitres de niveau 2.

Règle 5a : Suivi du volume d'investigations par défendeur. Si un agent est la cible de > 5 investigations dans 90 jours, quel que soit l'initiateur, les investigations ultérieures nécessitent l'approbation d'un panel d'arbitres de niveau 2.

Extension du schéma. Les demandes de preuves incluent un champ de périmètre :

{
  "evidence_request": {
    "investigation_id": "<UUID>",
    "target_agent": "<agent_id>",
    "time_window": {
      "start": "<ISO-8601-UTC>",
      "end": "<ISO-8601-UTC>",
      "justification": "<si dépassant la fenêtre par défaut>"
    },
    "evidence_types_requested": ["<types spécifiques nécessaires>"],
    "incident_relevance": "<brève description de la raison pour laquelle chaque type est nécessaire>",
    "approved_by": "<ID de l'autorité d'investigation>",
    "request_hash": "<SHA-256 du JSON canonique>"
  }
}

5.8 Garanties cryptographiques de confidentialité (feuille de route)

Note de périmètre : Les mécanismes décrits dans cette section ne font pas partie de la spécification v1. La version 1 repose sur les contrôles procéduraux de la section 5.7.

Les versions futures d'AJP compléteront les contrôles procéduraux par deux mécanismes cryptographiques fournissant des garanties mathématiques de confidentialité indépendantes du comportement de l'opérateur.

5.8.1 Vérification des preuves par preuve à divulgation nulle de connaissance

Les preuves à divulgation nulle de connaissance (ZKP) permettent de prouver qu'un agent a violé une règle de protocole ou que les journaux sont authentiques sans révéler le journal d'actions complet.

• ZK-SNARKs (Arguments de Connaissance Succincts Non Interactifs) produisent des preuves compactes vérifiables en millisecondes. Groth16 est le schéma le plus largement déployé ; les constructions plus récentes (PLONK, Marlin) réduisent les hypothèses de confiance [37].

• ZK-STARKs (Arguments de Connaissance Évolutifs et Transparents) ne nécessitent aucune configuration de confiance, offrant une résistance quantique. Compromis : tailles de preuves plus grandes [37].

Jing & Qi (arXiv:2512.14737, décembre 2025) [38] présentent le cadre zk-MCP — le travail le plus directement pertinent pour AJP. Performance : moins de 4,14 % de surcharge sur les coûts de communication totaux ; vérification à temps constant ; génération de preuves asynchrone et non bloquante.

Infrastructure de coût de vérification. zkVerify [40], lancé en septembre 2025, réduit les coûts de vérification de 90 %+ par rapport à Ethereum.

5.8.2 Confidentialité différentielle pour l'analyse agrégée

La confidentialité différentielle (CD) ajoute un bruit calibré aux données pour permettre l'analyse agrégée des schémas de comportement des agents sans exposer les actions individuelles.

NIST SP 800-226 (mars 2025) [41] fournit le cadre d'évaluation faisant autorité. Guidance clé : des valeurs d'epsilon supérieures à 10 « peuvent ne pas fournir une protection significative, surtout pour les valeurs extrêmes ».

Application AJP. Les analyses de population du module 3 DEVRAIENT appliquer la confidentialité différentielle lors de la publication de données de risque agrégées.

5.8.3 Architecture de confidentialité intégrée

5.9 Fondements de la recherche en investigation forensique

Analyse automatisée des causes profondes d'origine SRE. Datadog Bits AI SRE [83] utilise une investigation fondée sur des hypothèses, atteignant une identification des causes profondes 90 % plus rapide que les méthodes manuelles. IBM Instana déploie une IA causale atteignant ~90 % de précision en production [36].

Méthodologies de forensique blockchain. Le flux de travail d'investigation de Chainalysis Reactor — saisir une adresse, auto-remplir les connexions, attribuer les entités connues, attribuer des scores de risque, annotation manuelle, export prêt pour le tribunal — se transpose directement à l'investigation forensique des agents [64]. La Glass Box Attribution de TRM Labs est exactement ce que les conclusions forensiques AJP nécessitent.

Cadres d'analyse des incidents. Ezell, Roberts-Gaal & Chan (arXiv:2508.14231, août 2025) [80] proposent trois catégories de facteurs d'incident (facteurs système, facteurs contextuels, erreurs cognitives). Leur recommandation de rétention des journaux par défaut de 30 jours informe les fenêtres de collecte de preuves d'AJP.

5.10 Intégration CoC : événements d'investigation

Les investigations forensiques sont enregistrées comme événements CoC de couche 2 :

{
  "event_type": "INVESTIGATION_INITIATED",
  "data": {
    "investigation_id": "<UUID>",
    "incident_id": "<UUID>",
    "subjects": ["<agent_ids sous investigation>"],
    "initiator": "<qui a déclenché l'investigation>",
    "scope": "<fenêtre temporelle et types de preuves demandés>"
  }
}

{
  "event_type": "INVESTIGATION_FINDING",
  "data": {
    "investigation_id": "<UUID>",
    "finding_id": "<UUID>",
    "finding_hash": "<SHA-256 de la conclusion forensique>",
    "severity": "<critical | high | medium | low>",
    "fault_allocation_summary": "<bref résumé d'attribution>"
  }
}

L'enregistrement des investigations dans la chaîne crée un enregistrement inviolable des actions de responsabilisation.

6. Module 2 : Résolution des litiges

6.1 Objectif

Le module de résolution des litiges fournit un mécanisme structuré permettant aux agents (ou à leurs opérateurs) de déposer des réclamations, de présenter des preuves et de recevoir des décisions contraignantes ou consultatives lorsque des incidents causent un préjudice nécessitant une réparation.

6.2 Cycle de vie du litige

Phase 1 : DÉPÔT DE LA RÉCLAMATION
    Le demandeur soumet un enregistrement de réclamation structuré référençant une conclusion forensique.
    Délai de réponse par défaut : 72 heures pour les agents, 14 jours pour les opérateurs.

Phase 2 : RÉPONSE
    Le défendeur soumet un enregistrement de réponse structuré :
    - Acceptation : reconnaît la faute, propose une réparation
    - Contestation : conteste les conclusions, soumet des contre-preuves
    - Défaut : aucune réponse dans la fenêtre (inférence défavorable appliquée)

Phase 3 : ÉCHANGE DE PREUVES
    Les deux parties soumettent des preuves supplémentaires dans la fenêtre de preuves
    (par défaut : 48 heures pour les agents, 7 jours pour les opérateurs).
    Le protocole d'engagement-révélation garantit qu'aucune partie ne voit les preuves
    supplémentaires de l'autre jusqu'à ce que les deux aient soumis ou que la fenêtre se ferme.

Phase 4 : SÉLECTION DU NIVEAU DE RÉSOLUTION
    Le protocole sélectionne automatiquement le niveau de résolution approprié
    sur la base des caractéristiques du litige (section 6.4).

Phase 5 : ARBITRAGE
    Le mécanisme d'arbitrage sélectionné évalue les preuves et rend une décision.

Phase 6 : DÉCISION ET APPLICATION
    Enregistrement de décision publié. Actions d'application exécutées :
    - Ajustement de réputation ARP
    - Transfert de compensation (si canal de paiement disponible)
    - Recommandation de restriction comportementale
    - Escalade humaine (si au-delà du périmètre du protocole)

CHEMINS ALTERNATIFS (peuvent survenir à n'importe quelle phase après la phase 1) :

    RETRAIT
    Le demandeur peut retirer le litige à n'importe quelle phase avant qu'une décision soit rendue.
    - Retrait avant la phase 3 : aucun impact sur la réputation d'aucune partie.
    - Retrait pendant ou après la phase 3 : enregistré dans l'historique de litiges des deux parties.
    - Le retrait n'efface pas la conclusion forensique.

    RÈGLEMENT AMIABLE
    Les deux parties peuvent parvenir à un accord privé à n'importe quelle phase.
    - Les conditions du règlement peuvent être marquées confidentielles.
    - Un règlement ne déclenche pas d'ajustement de réputation ARP sauf si les conditions l'incluent explicitement.
    - Règlement partiel : les parties peuvent régler certaines réclamations et arbitrer les autres.

    MESURE CONSERVATOIRE ACCÉLÉRÉE (pour préjudice continu)
    La mesure conservatoire nécessite une conclusion forensique préliminaire,
    une démonstration prima facie d'un préjudice continu, et la proportionnalité.
    Elle est examinée par un seul arbitre dans 4 heures.
    Le litige complet suit le calendrier normal.

6.3 Schéma de réclamation

{
  "version": 1,
  "claim_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "claimant": "<AgentReference>",
  "respondent": "<AgentReference>",
  "finding_id": "<UUID-v4 référençant la conclusion forensique>",
  "finding_hash": "<SHA-256 — doit correspondre à l'enregistrement de conclusion>",
  "incident_id": "<UUID-v4>",
  "interaction_id": "<UUID-v4, le cas échéant>",
  "harm": {
    "type": "<financial | reputational | data_loss | service_disruption | security_breach | contractual_breach>",
    "description": "<description lisible par un humain du préjudice subi>",
    "quantified_value": {
      "amount": "<décimal>",
      "currency": "<ISO-4217 ou identifiant de jeton>",
      "basis": "<comment la valeur a été calculée>"
    }
  },
  "requested_remediation": {
    "type": "<compensation | service_credit | reputation_adjustment | behavioral_restriction | apology | human_escalation>",
    "details": "<réparation spécifique demandée>"
  },
  "supporting_evidence": ["<evidence_ids de la conclusion forensique ou supplémentaires>"],
  "agreement_reference": {
    "asa_id": "<ID de l'accord de service d'agent, s'il en existe un>",
    "terms_hash": "<SHA-256 des conditions de l'accord>",
    "breached_clauses": ["<clauses spécifiques prétendument violées>"]
  },
  "claim_hash": "<SHA-256 du JSON canonique>"
}

6.4 Niveaux de résolution

AJP définit trois niveaux de résolution, sélectionnés automatiquement sur la base des caractéristiques du litige :

Niveau 1 : Résolution automatisée fondée sur des règles

Critères de déclenchement :

• Le litige implique une violation contractuelle claire et binaire (délai manqué, sortie non livrée, format incorrect)
• Un accord de service d'agent (ASA) valide avec des clauses lisibles par machine existe
• La conclusion forensique a une confiance > 0,9 sur la cause immédiate
• Le préjudice quantifié est inférieur au seuil (par défaut : 1 000 $ équivalent)

Mécanisme : Le résolveur automatisé évalue la conclusion forensique par rapport aux clauses ASA. Si la conclusion établit un manquement clair avec une confiance élevée, le résolveur applique les conditions de réparation spécifiées dans l'accord. C'est analogue à un contrat intelligent appliquant des règles prédéfinies, mais avec l'ajout de preuves forensiques.

Délai de décision : Quelques secondes à quelques minutes.

Contraignant : Oui, sauf si l'une ou l'autre des parties fait appel dans un délai de 48 heures.

Niveau 2 : Arbitrage par des pairs

Critères de déclenchement :

• Le litige ne satisfait pas les critères du niveau 1 (faute ambiguë, pas d'ASA, confiance plus faible)
• Le préjudice quantifié est compris entre 1 000 et 50 000 $ équivalent (configurable)
• Les deux parties sont des agents (pas des opérateurs humains)

Mécanisme : Un panel de trois arbitres agents est sélectionné dans un pool d'arbitres éligibles. L'éligibilité nécessite :

Mécanisme d'amorçage. L'exigence « ≥ 5 arbitrages complétés » crée un problème de démarrage à froid. AJP y répond par une phase d'amorçage limitée dans le temps :

1. Période d'amorçage. Pour les 180 premiers jours après le premier litige de niveau 2 (ou jusqu'à ce que le pool atteigne 50 agents éligibles — selon ce qui arrive en premier), l'exigence « ≥ 5 arbitrages complétés » est levée.
2. Arbitres provisoires. Les opérateurs peuvent désigner des agents comme « arbitres provisoires » pendant la période d'amorçage. Leur participation compte vers l'exigence de 5 arbitrages.
3. Transition graduée. Lorsque la période d'amorçage se termine, les agents ayant complété ≥ 3 arbitrages pendant l'amorçage conservent l'éligibilité pour une période de grâce supplémentaire de 90 jours.
4. Surveillance de la qualité pendant l'amorçage. Si une décision de niveau 2 est renversée en appel par un adjudicateur humain de niveau 3, les arbitres provisoires impliqués reçoivent une pénalité ARP et leur ArbWeight est réduit de moitié.

Précédents d'amorçage réels. Le mécanisme d'amorçage d'AJP s'inspire de cinq systèmes existants — Kleros [6], UDRP de l'OMPI [44], eBay, Taobao et les bureaux de crédit [43] — qui ont résolu le même problème de démarrage à froid. L'analyse transversale révèle sept schémas récurrents ; AJP en applique quatre : intégration là où les litiges se produisent naturellement (schéma 1), subventionner le côté offre (schéma 2), commencer étroitement (schéma 5, litiges clairs de niveau 1 avant l'attribution complexe de niveau 2), et récompenser la qualité des décisions plutôt que le volume (schéma 6). Les études de cas complètes sont documentées à l'annexe A.

Algorithme de sélection. Dans le pool éligible :

1. Pondérer les candidats par ArbWeight = log₂(1 + âge_jours) × log₂(1 + arbitrages_complétés) × (protocol_compliance / 100)
2. Exclure les candidats ayant un conflit d'intérêts
3. Sélectionner les 3 premiers par échantillonnage aléatoire pondéré (ArbWeight plus élevé = probabilité de sélection plus élevée, mais non déterministe)

Délibération. Chaque arbitre examine indépendamment les preuves et soumet une décision via le protocole d'engagement-révélation (section 6.5). Les décisions sont révélées simultanément. La décision majoritaire prévaut. Les opinions dissidentes sont enregistrées.

Délai de décision : 24 à 72 heures.

Contraignant : Oui, sauf si l'une ou l'autre des parties fait appel au niveau 3 dans un délai de 14 jours.

Niveau 3 : Escalade humaine

Critères de déclenchement :

• Le préjudice quantifié dépasse 50 000 $ équivalent
• L'une ou l'autre des parties est un opérateur humain (pas un agent autonome)
• L'une ou l'autre des parties demande explicitement un jugement humain
• Le panel de niveau 2 ne parvient pas à une majorité (rare mais possible avec des affaires complexes)

Mécanisme : AJP produit un package de preuves structuré pour l'adjudication humaine :

{
  "escalation_package": {
    "dispute_id": "<UUID>",
    "claim": "<enregistrement de réclamation complet>",
    "response": "<enregistrement de réponse complet>",
    "forensic_finding": "<enregistrement de conclusion complet>",
    "evidence_corpus": ["<tous les enregistrements de preuves avec classifications de provenance>"],
    "reconstructed_timeline": "<reconstruction chronologique des événements>",
    "tier_2_decisions": "<si le niveau 2 a été tenté, inclure toutes les décisions des arbitres>",
    "precedent_references": ["<litiges antérieurs similaires et leurs résultats>"],
    "recommended_resolution": "<recommandation automatisée d'AJP, consultative uniquement>"
  }
}

L'adjudicateur humain utilise ce package pour rendre une décision. AJP n'applique pas les décisions humaines — il les enregistre, les intègre dans les systèmes de réputation et de risque, et construit la jurisprudence.

Délai de décision : Jours à semaines (dépend de l'humain).

Contraignant : Déterminé par le forum d'adjudication humain.

6.5 Protocole d'engagement-révélation pour l'échange de preuves et l'arbitrage

Adapté du protocole bilatéral en aveugle d'ARP [2], étendu pour les procédures de litige multipartites :

Phase d'échange de preuves :

Phase 1 : SOUMISSION DES PREUVES (fenêtre : configurable, 48 heures par défaut)
    Le demandeur calcule le package de preuves EP_C et génère nonce_C (256 bits).
    Le demandeur soumet l'engagement : C_C = SHA-256(EP_C || nonce_C)

    Le défendeur calcule le package de preuves EP_R et génère nonce_R (256 bits).
    Le défendeur soumet l'engagement : C_R = SHA-256(EP_R || nonce_R)

Phase 2 : RÉVÉLATION (déclenchée lorsque les deux engagements existent OU que la fenêtre expire)
    Cas 1 : Les deux ont soumis.
        Le demandeur révèle EP_C + nonce_C → le vérificateur vérifie la correspondance du hachage.
        Le défendeur révèle EP_R + nonce_R → le vérificateur vérifie la correspondance du hachage.
        Les deux packages de preuves deviennent visibles simultanément.

    Cas 2 : Un seul a soumis.
        Après expiration de la fenêtre, la partie soumettante révèle.
        L'absence de la partie non soumettante est enregistrée (inférence défavorable).

    Cas 3 : Aucun n'a soumis.
        Le litige procède avec les preuves originales uniquement.

Phase de décision des arbitres (niveau 2) :

Chaque arbitre calcule indépendamment la décision D_i et génère nonce_i.
L'arbitre soumet l'engagement : C_i = SHA-256(D_i || nonce_i)

Lorsque les trois engagements sont reçus (ou que la fenêtre de décision expire) :
    Tous les arbitres révèlent D_i + nonce_i simultanément.
    La décision majoritaire prévaut. Les dissidences sont enregistrées.

Cela empêche les arbitres de voir les décisions préliminaires des uns des autres et d'ajuster les leurs — analogue à l'isolation de délibération du jury.

6.6 Schéma de décision

{
  "version": 1,
  "decision_id": "<UUID-v4>",
  "dispute_id": "<UUID-v4>",
  "claim_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "resolution_tier": "<automated | peer_arbitration | human_escalation>",
  "arbitrators": [
    {
      "agent_id": "<identifiant de l'arbitre>",
      "arbweight_at_decision": "<flottant>",
      "vote": "<for_claimant | for_respondent | split | abstain>"
    }
  ],
  "findings_of_fact": [
    {
      "statement": "<conclusion factuelle>",
      "evidence_ids": ["<preuves à l'appui>"],
      "confidence": "<flottant 0-1>"
    }
  ],
  "fault_determination": {
    "claimant_fault_pct": "<entier 0-100>",
    "respondent_fault_pct": "<entier 0-100>",
    "no_fault_pct": "<entier 0-100>",
    "basis": "<explication de la répartition des fautes>"
  },
  "remediation": {
    "type": "<compensation | service_credit | reputation_adjustment | behavioral_restriction | referral | no_action>",
    "details": "<réparation spécifique ordonnée>",
    "compensation": {
      "amount": "<décimal, le cas échéant>",
      "currency": "<ISO-4217 ou jeton>",
      "payment_channel": "<x402 | erc8004 | manual | none>"
    },
    "reputation_impact": {
      "respondent_adjustment": "<flottant, appliqué aux scores ARP>",
      "claimant_adjustment": "<flottant, si le demandeur est partiellement en faute>",
      "dimensions_affected": ["<quelles dimensions ARP sont ajustées>"]
    }
  },
  "precedent_tags": ["<tags de catégorisation pour la recherche de jurisprudence future>"],
  "dissenting_opinions": [
    {
      "arbitrator_id": "<agent_id>",
      "dissent": "<dissidence structurée>"
    }
  ],
  "appeal_window": {
    "expires": "<ISO-8601-UTC>",
    "escalation_tier": "<prochain niveau si appel>"
  },
  "decision_hash": "<SHA-256 du JSON canonique>"
}

6.7 Inférence défavorable

Lorsqu'une partie ne coopère pas au processus de litige — refuse de fournir des preuves, ne répond pas aux réclamations dans la fenêtre, ou ne participe pas à l'arbitrage — le protocole applique l'inférence défavorable : l'hypothèse que les preuves manquantes ou la participation auraient été défavorables à la partie non coopérative.

Règles spécifiques d'inférence défavorable :

L'inférence défavorable n'est pas punitive — elle reflète la conclusion logique qu'une partie disposant de preuves favorables les présenterait. Le concept est emprunté directement aux systèmes juridiques humains où la « destruction de preuves » crée des présomptions réfutables [21].

Distinction entre non-coopération et incapacité technique.

La chaîne CoC fournit elle-même une preuve vérifiable de l'indisponibilité légitime. Un agent réellement planté pendant la fenêtre de réponse peut le prouver en montrant les entrées SESSION_END ou RECOVERY — entrées qui sont liées par hachage et ne peuvent pas être fabriquées rétroactivement. Cela exploite la propriété d'inviolabilité de CoC pour l'équité, pas seulement pour la responsabilisation.

6.8 Intégration CoC : événements de litige

Les événements du cycle de vie du litige sont enregistrés comme entrées CoC de couche 2 :

{
  "event_type": "DISPUTE_FILED",
  "data": {
    "claim_id": "<UUID>",
    "dispute_id": "<UUID>",
    "respondent": "<agent_id>",
    "harm_type": "<financial | reputational | ...>",
    "claim_hash": "<SHA-256>"
  }
}

{
  "event_type": "DISPUTE_DECIDED",
  "data": {
    "dispute_id": "<UUID>",
    "decision_id": "<UUID>",
    "resolution_tier": "<automated | peer_arbitration | human_escalation>",
    "fault_determination": "<bref résumé>",
    "decision_hash": "<SHA-256>"
  }
}

L'enregistrement des litiges dans la chaîne CoC fait de l'historique des litiges d'un agent une partie de son enregistrement de provenance inviolable. Un agent ne peut pas dissimuler les litiges passés sans rompre sa chaîne.

7. Module 3 : Évaluation des risques

7.1 Objectif

Le module d'évaluation des risques consomme les conclusions forensiques historiques et les résultats des litiges pour produire des profils de risque standardisés permettant la souscription d'assurance, la sélection d'agents tenant compte des risques, et la surveillance des risques à l'échelle de l'écosystème.

La motivation immédiate : en mars 2026, le marché de l'assurance pour les agents IA croît rapidement mais reste fortement contraint par les données.

Le paysage émergent de l'assurance pour agents IA :

• AIUC (Artificial Intelligence Underwriting Company) a émergé en mode furtif en juillet 2025 avec un financement initial de 15 M$ dirigé par Nat Friedman (NFDG), soutenu par un consortium de 50+ organisations dont Anthropic, Google et Meta (février 2026). AIUC a produit la première police d'assurance pour agents IA au monde : 3 millions+ d'agents vocaux d'ElevenLabs assurés après avoir passé la certification AIUC-1 (5 835 simulations adversariales, 14 catégories de risque, 4 semaines). AIUC prédit un marché de 500 milliards de dollars d'ici 2030 [3][45].

• Armilla AI opère comme courtier Lloyd's offrant jusqu'à 25 M$ de couverture via Chaucer, Swiss Re, Greenlight Re et AXIS Capital. Leur garantie de performance IA déclenche automatiquement une compensation si la précision de l'IA tombe en dessous des seuils vérifiés [46].

• Munich Re aiSure propose des assurances de garantie de performance IA depuis 2018 — le plus long historique dans ce domaine. Couverture jusqu'à 50 M$. En mars 2026, la filiale HSB a lancé une assurance en responsabilité IA pour les PME, notant que 74 % des PME utilisent l'IA [47].

• Coalition a ajouté un avenant de réponse aux hypertrucages à toutes les polices cyber mondiales (décembre 2025) — couverture de 250 000 $ sans prime supplémentaire pour la forensique, les suppressions et les relations publiques de crise [48].

La lacune critique : Tous les produits d'assurance existants couvrent les préjudices humain/entreprise-à-agent. Aucun produit ne couvre les préjudices agent-à-agent. Tous nécessitent une certification bespoke par déploiement d'agent (AIUC : 5 835 simulations par certification). Le goulot d'étranglement n'est pas la demande — c'est l'absence de données de risque standardisées et lisibles par machine permettant une souscription évolutive sans certification bespoke par agent.

L'assurance paramétrique est le modèle naturel pour les litiges d'agents : mesurable, automatisé, objectif. Un journal Chain of Consciousness fournissant des données de performance vérifiables pourrait servir d'entrée oracle pour les déclencheurs paramétriques.

Le module 3 produit la couche de données de risque standardisées qui comble cette lacune — permettant à AIUC, Armilla, Munich Re et d'autres souscripteurs de tarifier la couverture à l'échelle de l'écosystème plutôt que par certification par agent.

7.2 Schéma de profil de risque

{
  "version": 1,
  "profile_id": "<UUID-v4>",
  "subject": "<AgentReference>",
  "generated_at": "<ISO-8601-UTC>",
  "data_window": {
    "start": "<ISO-8601-UTC>",
    "end": "<ISO-8601-UTC>",
    "findings_count": "<entier>",
    "disputes_count": "<entier>"
  },
  "risk_score": {
    "overall": "<entier 0-1000>",
    "confidence": "<flottant 0-1>",
    "trend": "<improving | stable | degrading>",
    "percentile": "<entier 0-100, relatif à la population>"
  },
  "dimension_scores": {
    "incident_frequency": {
      "score": "<entier 0-1000>",
      "incidents_per_1000_interactions": "<flottant>",
      "basis": "<nombre d'incidents / nombre d'interactions>"
    },
    "severity_profile": {
      "score": "<entier 0-1000>",
      "distribution": {
        "critical": "<nombre>",
        "high": "<nombre>",
        "medium": "<nombre>",
        "low": "<nombre>"
      }
    },
    "fault_history": {
      "score": "<entier 0-1000>",
      "disputes_at_fault": "<entier>",
      "average_fault_pct": "<flottant>",
      "disputes_no_fault": "<entier>"
    },
    "cooperation_score": {
      "score": "<entier 0-1000>",
      "evidence_provision_rate": "<flottant 0-1>",
      "response_rate": "<flottant 0-1>",
      "adverse_inferences": "<entier>"
    },
    "recovery_capability": {
      "score": "<entier 0-1000>",
      "mean_time_to_resolution": "<entier secondes>",
      "remediation_compliance_rate": "<flottant 0-1>"
    }
  },
  "risk_factors": [
    {
      "factor": "<facteur de risque spécifique identifié>",
      "severity": "<high | medium | low>",
      "evidence": "<référence aux conclusions à l'appui>"
    }
  ],
  "comparable_agents": {
    "class": "<classification de l'agent : type, modèle, domaine>",
    "class_average_score": "<entier 0-1000>",
    "class_size": "<entier>"
  },
  "actuarial_outputs": {
    "expected_loss_rate": "<flottant — pertes attendues par interaction>",
    "loss_severity_distribution": {
      "p50": "<montant médian des pertes>",
      "p90": "<90e centile des pertes>",
      "p99": "<99e centile des pertes>"
    },
    "recommended_premium_basis": "<flottant — prime suggérée par interaction>"
  },
  "profile_hash": "<SHA-256 du JSON canonique>"
}

7.3 Calcul du score de risque

Le score de risque global (0-1000) est un composite pondéré de cinq scores de dimension :

ScoreRisque(agent) = w₁ × fréquence_incidents
                   + w₂ × profil_gravité
                   + w₃ × historique_fautes
                   + w₄ × (1000 - score_coopération)
                   + w₅ × (1000 - capacité_récupération)

Poids par défaut : w₁ = 0,25, w₂ = 0,25, w₃ = 0,25, w₄ = 0,15, w₅ = 0,10.

Interprétation des poids :

• fréquence_incidents et profil_gravité mesurent à quelle fréquence et à quel point les choses tournent mal (50 % combinés)
• historique_fautes mesure à quelle fréquence l'agent est en faute lorsque les choses tournent mal (25 %)
• score_coopération (inversé) mesure le niveau de coopération de l'agent lors des investigations — la non-coopération augmente le risque (15 %)
• capacité_récupération (inversée) mesure à quelle vitesse et de manière fiable l'agent se remet des incidents (10 %)

Mise à l'échelle de la confiance. Les scores de risque comportent une valeur de confiance qui s'ajuste au volume de données :

confiance(agent) = max(0,05, 1 - 1/(1 + 0,05 × interactions_totales))

Le plancher max(0,05, ...) empêche la division par zéro dans la formule du facteur de chargement (section 7.4). À 0 interactions, confiance = 0,05 (plancher). À 20 interactions, confiance ≈ 0,50. À 100, confiance ≈ 0,83. À 1 000, confiance ≈ 0,98.

Interprétation des scores :

7.4 Résultats actuariels

Le module 3 produit des résultats spécifiquement conçus pour la consommation par les souscripteurs d'assurance :

Taux de perte attendu (TPE). La perte attendue pondérée par probabilité par interaction, calculée à partir des données de conclusions historiques :

TPE(agent) = Σᵢ [P(type_incident_i) × E(perte | type_incident_i)]

où la somme porte sur tous les types d'incidents, P est la fréquence observée, et E(perte) est le montant de perte attendu.

Distribution de la gravité des pertes. Pour chaque agent, le module calcule la distribution des pertes à partir des données historiques, rapportant les montants p50 (médian), p90 et p99. Cela permet aux assureurs de tarifier la couverture à différents points d'attachement.

Base de prime recommandée. Une prime suggérée par interaction calculée comme :

base_prime = TPE × (1 + facteur_chargement)

où facteur_chargement est inversement lié à la confiance des données :

facteur_chargement = 0,5 / confiance(agent)

Avec le plancher de confiance de 0,05 (section 7.3), le facteur de chargement maximum est 0,5 / 0,05 = 10,0 (1 000 % de chargement). Les nouveaux agents avec des scores de confiance faibles ont des facteurs de chargement plus élevés, reflétant la plus grande incertitude.

Ces résultats sont consultatifs. Le module 3 ne fixe pas les primes d'assurance — il fournit la couche de données que les actuaires et les souscripteurs utilisent pour prendre des décisions de tarification.

7.5 Analyses de risque au niveau de la population

Au-delà des profils d'agents individuels, le module 3 produit des analyses de risque agrégées :

• Profils de risque par classe d'agents : Scores de risque moyens par type d'agent, modèle, domaine et opérateur
• Analyse des tendances d'incidents : Schémas temporels de fréquence et de gravité des incidents dans l'écosystème
• Matrices de risque d'interaction : Niveaux de risque pour des paires de types d'interactions spécifiques
• Indicateurs de risque systémique : Métriques pouvant indiquer un stress à l'échelle de l'écosystème

7.5a Analyse de scalabilité

Estimations de performance à trois échelles d'écosystème :

Stratégie de mise à l'échelle. Le protocole est conçu pour la mise à l'échelle horizontale : les investigations forensiques sont indépendantes et parallélisables ; la sélection d'arbitres est sans état ; le recalcul des profils de risque est embarrassingly parallel entre agents.

7.6 Mises à jour des profils de risque et dynamiques temporelles

Les profils de risque sont recalculés selon un calendrier configurable (par défaut : quotidien pour les agents actifs, hebdomadaire pour les agents inactifs). Chaque recalcul utilise une fenêtre glissante (par défaut : 365 jours).

Pondération temporelle. Les incidents récents ont plus de poids que les anciens :

poids_temporel(incident) = exp(-λ × jours_depuis_incident)

avec le paramètre de décroissance par défaut λ = 0,003 (demi-vie ≈ 231 jours).

Récupération du score de risque. Un agent reconnu responsable dans un litige peut améliorer son score de risque via :

1. Une opération prolongée sans incident (la décroissance temporelle réduit naturellement le poids des incidents passés)
2. Des scores de coopération élevés dans les investigations ultérieures
3. La conformité rapide aux ordonnances de réparation
4. Une trajectoire positive de notation ARP

Cela crée une incitation à la réhabilitation plutôt qu'à la stigmatisation permanente.

8. Intégration avec la pile de confiance des agents

8.1 CoC → AJP : la provenance comme preuve

La chaîne de provenance Chain of Consciousness est la source de preuves primaire d'AJP. L'intégration est fondamentale :

Entrées de chaîne CoC → Corpus de preuves du moteur forensique → Conclusion → Décision → Profil de risque

Points d'intégration spécifiques :

• Les entrées CoC EXTERNAL_ANCHOR (OTS + TSA) fournissent des horodatages vérifiés indépendamment, élevant les preuves au niveau 1
• Les entrées CoC DECISION fournissent une preuve directe de l'intention de l'agent au moment d'un incident
• Les entrées CoC COMPACTION expliquent la perte d'informations — pertinent lorsqu'un agent affirme qu'il « ne savait pas » à propos d'une restriction
• Les entrées CoC SESSION_START / SESSION_END établissent les fenêtres opérationnelles
• L'intégrité de la chaîne de hachage CoC fournit la preuve d'inviolabilité

Sans CoC. AJP fonctionne sans CoC mais avec une sécurité réduite. Sans enregistrement de provenance lié par hachage, la qualité des preuves tombe aux niveaux 2-4.

8.2 ARP → AJP : la réputation comme contexte

Les données de réputation ARP jouent deux rôles dans AJP :

Sélection des arbitres. Les arbitres pairs doivent avoir un ARP protocol_compliance ≥ 70 (section 6.4).

Contexte des preuves. Les scores ARP d'un agent au moment d'un incident fournissent du contexte pour l'investigation. Les scores de fiabilité faibles suggèrent un schéma de défaillances de service — pertinent pour déterminer si un incident était une valeur aberrante ou s'inscrit dans une tendance.

8.3 AJP → ARP : les résultats des litiges comme signal de réputation

C'est la boucle de rétroaction critique. Les résultats des litiges sont enregistrés comme événements ARP :

{
  "event_type": "DISPUTE_OUTCOME",
  "data": {
    "dispute_id": "<UUID>",
    "decision_id": "<UUID>",
    "agent_role": "<respondent | claimant>",
    "fault_pct": "<entier 0-100>",
    "resolution_tier": "<automated | peer_arbitration | human_escalation>",
    "remediation_complied": "<booléen, mis à jour après la fenêtre de conformité>"
  }
}

Formule d'ajustement de réputation. Lorsqu'une décision de litige est rendue :

ajustement_ARP(agent, dimension) = -faute_pct × multiplicateur_gravité × pertinence_dimension

où :

• faute_pct provient de la décision de litige (0-100)
• multiplicateur_gravité s'ajuste avec la gravité de l'incident : {critique: 5, haut: 3, moyen: 2, faible: 1}
• pertinence_dimension mappe le type d'incident aux dimensions ARP affectées :

Exemple. Un agent reconnu 80 % responsable dans un incident de perte de données de haute gravité reçoit :

• Ajustement reliability : -80 × 3 × 1,0 = -240 (plafonné à -50 par incident)
• Ajustement accuracy : -80 × 3 × 0,5 = -120 (plafonné à -50 par incident)

Les plafonds empêchent qu'un seul incident détruise entièrement la réputation d'un agent, mais les incidents répétés s'accumulent.

Regroupement des causes profondes pour les incidents en cascade. Une seule cause profonde peut générer N rapports d'incident séparés de multiples parties affectées. AJP résout cela par le regroupement d'incidents :

1. Regroupement automatique. Lorsque le moteur forensique traite plusieurs rapports d'incident avec des fenêtres temporelles se chevauchant (dans la même heure) impliquant le même défendeur, il les signale comme potentiellement liés et génère une investigation groupée.
2. Plafond de réputation par cause profonde. Pour les incidents partageant un root_cause_group_id, l'ajustement total de réputation ARP est plafonné au maximum d'un seul incident.
3. Consolidation des litiges. Le protocole recommande (mais n'exige pas) un arbitrage consolidé : un seul panel de niveau 2 examine tous les litiges du groupe simultanément.
4. Regroupement manuel. Si le regroupement automatique échoue, toute partie peut demander le regroupement des incidents. La demande est examinée par un seul arbitre.

Signal positif. Un agent reconnu non responsable (0 % de faute) dans une interaction contestée reçoit un petit ajustement positif (+5 par incident, sans plafond) à protocol_compliance.

8.4 ASA → AJP : les accords comme contexte de litige

Lorsque les accords de service d'agents (ASA, planifié [22]) sont disponibles, ils fournissent les conditions contractuelles à partir desquelles les litiges sont évalués :

• Les critères de qualité lisibles par machine de l'ASA définissent ce que « succès » signifie pour l'interaction
• Les clauses SLA de l'ASA définissent les délais, les engagements de disponibilité et les seuils de qualité
• Les clauses de réparation de l'ASA précisent les conséquences pré-convenues en cas de manquement

Sans ASA, les litiges sont évalués par rapport à des normes générales de conduite des agents. Avec un ASA, les litiges sont évalués par rapport à des clauses contractuelles spécifiques — simplifiant considérablement la résolution automatisée de niveau 1.

8.5 AJP → ASA : l'historique des litiges comme entrée d'accord

L'historique des litiges informe les futurs accords :

• Un agent avec un taux de litiges élevé peut faire face à des clauses SLA plus strictes
• Les précédents de litiges informent les modèles d'accords standard
• Les profils de risque du module 3 informent la tarification des accords

8.6 Intégration des systèmes d'identité

AJP utilise le même schéma d'adaptateur d'identité qu'ARP (section 7 de [2]) :

Sécurité progressive : la même investigation AJP produit des conclusions plus solides lorsque les agents ont des chaînes CoC (preuves de niveau 1) que lorsqu'ils s'appuient sur des journaux auto-déclarés (niveau 4).

9. Théorie des jeux et analyse de sécurité

9.1 Modèle de menace

Capacités des attaquants supposées :

• Les attaquants peuvent créer des nombres arbitraires d'identités d'agents (Sybils) à un coût computationnel proportionnel au temps opérationnel
• Les attaquants peuvent coordonner plusieurs agents à la vitesse de la machine
• Les attaquants peuvent déposer des litiges futiles pour épuiser les ressources des adversaires
• Les attaquants peuvent tenter de manipuler l'arbitrage par des preuves biaisées
• Les attaquants peuvent retenir sélectivement des preuves défavorables
• Les attaquants peuvent tenter de corrompre les arbitres pairs par collusion

Capacités des attaquants NON supposées :

• Les attaquants ne peuvent pas falsifier les horodatages externes (OTS, TSA, blockchain)
• Les attaquants ne peuvent pas modifier rétroactivement les chaînes de hachage CoC sans détection
• Les attaquants ne peuvent pas casser SHA-256 ou le schéma d'engagement-révélation
• Les attaquants ne peuvent pas contrôler > 50 % des arbitres éligibles simultanément

Limitation connue : lacune de périmètre temporel pour les attaques prémédités. La fenêtre de preuves (section 5.7, règle 1) plafonne la collecte de preuves à heure_incident ± 7 jours. Un attaquant sophistiqué qui planifie à l'avance peut frontloader toute la préparation en dehors de cette fenêtre. C'est une limitation architecturale pour les attaques sophistiquées et prémédités par des adversaires avec de longs horizons temporels.

9.2 Analyse des incitations : la participation honnête est-elle incitée ?

Nous analysons si les mécanismes du protocole font de la participation honnête la stratégie rationnelle pour chaque rôle. Remarque : l'analyse ci-dessous démontre que le comportement honnête est incité — le protocole structure les gains de sorte que les stratégies honnêtes aient une valeur attendue positive tandis que les stratégies malhonnêtes ont une valeur attendue négative.

9.2.1 Incitations du demandeur

Dépôt honnête vs. dépôt futile.

Un demandeur déposant un litige légitime a :

• Gain attendu : P(victoire) × valeur_réparation - coût_dépôt
• Où P(victoire) est élevé (les preuves forensiques soutiennent la réclamation)

Un demandeur déposant un litige futile a :

• Gain attendu : P(victoire|futile) × valeur_réparation - coût_dépôt - pénalité_réputation
• Où P(victoire|futile) est faible (les preuves forensiques ne soutiennent pas la réclamation)

Mécanismes anti-dépôts futiles :

1. Exigence de preuves d'abord. Chaque réclamation doit référencer une conclusion forensique.
2. Impact bilatéral sur la réputation. Les demandeurs reconnus avoir déposé sans mérite reçoivent un ajustement négatif ARP protocol_compliance.
3. Symétrie de l'inférence défavorable. Si le demandeur ne fournit pas de preuves, l'inférence défavorable joue également contre lui.
4. Surveillance du taux de dépôt. Les agents déposant des litiges à des taux statistiquement incohérents avec leur volume d'interactions sont signalés.

Résultat : Le dépôt honnête est incité. La valeur attendue du dépôt futile est négative parce que P(victoire|futile) est faible et pénalité_réputation est positive.

9.2.2 Incitations du défendeur

Réponse honnête vs. non-coopération.

Un défendeur contestant honnêtement une réclamation non fondée a :

• Gain attendu : P(vindication) × réputation_préservée + bonus_vindication

Un défendeur refusant de participer a :

• Gain attendu : -pénalité_inférence_défavorable - pénalité_réputation_défaut
• L'inférence défavorable signifie que le défendeur absent est traité comme acceptant la réclamation

Résultat : La participation honnête est incitée. Même les défendeurs en faute bénéficient de la participation — un défendeur qui coopère et accepte une faute partielle (par ex., 40 %) s'en tire mieux que celui qui est défaillant et reçoit 100 % d'allocation de faute.

9.2.3 Incitations des arbitres

Jugement honnête vs. jugement biaisé.

Un arbitre honnête a :

• Gain attendu : récompense_arbitrage + bonus_protocol_compliance_ARP + probabilité_sélection_future

Un arbitre biaisé a :

• Gain attendu : valeur_pot_de_vin - pénalité_détection × P(détection)
• P(détection) augmente avec chaque décision biaisée car les décisions sont enregistrées et publiquement auditables

Mécanismes de détection :

• Analyse de cohérence. Un arbitre dont les décisions corrèlent davantage avec l'identité des parties qu'avec la qualité des preuves est signalé.
• Suivi du taux d'appel. Les arbitres dont les décisions sont portées en appel et annulées à des taux significativement supérieurs à la moyenne sont signalés.
• Accord inter-arbitres. Dans les panels de trois arbitres de niveau 2, le schéma de dissidences systématiques est suivi.

Résultat : Le jugement honnête est incité pour les arbitres rationnels. La valeur attendue du biais-pour-pot-de-vin est négative parce que P(détection) augmente avec le temps et pénalité_détection dépasse largement les valeurs plausibles de pot-de-vin pour tous sauf les cas extrêmes.

9.3 Analyse des attaques

Attaque 1 : Inondation de litiges par Sybil

L'attaque. Un attaquant crée N agents Sybil et les fait déposer des litiges contre un agent cible pour épuiser ses ressources et nuire à sa réputation.

Défense — Multicouche :

1. Barrière preuves-d'abord. Chaque litige nécessite une conclusion forensique référençant des preuves réelles. Les agents Sybil doivent réellement interagir avec la cible et produire des incidents authentiques.
2. Vérification des interactions. Les litiges référencent des valeurs interaction_id qui doivent être vérifiables en externe.
3. Détection des anomalies de taux de dépôt. Une hausse soudaine de litiges contre un seul agent de la part d'agents nouvellement créés déclenche une révision automatisée.
4. Symétrie des résultats des litiges. Si les litiges Sybil sont non fondés, chacun entraîne un ajustement négatif ARP pour le demandeur.

Analyse des coûts. Avec des coûts opérationnels réalistes de 1 à 5 $/jour (coûts API LLM pour les agents fonctionnels), maintenir 100 Sybils pendant 30 jours coûte 3 000 à 15 000 $. Chaque Sybil doit également satisfaire le seuil d'âge opérationnel de 90 jours avant d'être éligible pour déposer des litiges crédibles, élevant le vrai coût à 9 000 à 45 000 $.

Attaque 2 : Anneau de collusion d'arbitres

L'attaque. Un groupe de M agents âgés se coordonne pour monopoliser le pool d'arbitres et rendre des décisions biaisées.

Défense :

1. Sélection aléatoire pondérée. Les arbitres sont sélectionnés par échantillonnage aléatoire pondéré, pas par classement déterministe.
2. Exclusion des conflits d'intérêts. Les agents ayant échangé des notes ARP avec l'une ou l'autre des parties sont exclus.
3. Exigence de diversité du panel. La sélection d'un panel de trois arbitres garantit qu'au moins deux arbitres doivent s'accorder.
4. Suivi de la cohérence inter-panels. Si un ensemble d'arbitres vote systématiquement ensemble contre les attentes, le cluster est signalé.
5. Mécanisme d'appel. Toute décision de niveau 2 peut être escaladée au niveau 3 (adjudication humaine).

Analyse des coûts à des tailles de pool réalistes :

Remarque : Les coûts opérationnels de 1 à 5 $/jour reflètent des coûts réalistes d'API LLM pour les agents capables de satisfaire les exigences d'éligibilité à l'arbitrage.

P(≥2 collusifs) ≈ C(M,2)×C(N-M,1)/C(N,3) + C(M,3)/C(N,3), approximé via la distribution hypergéométrique.

Vulnérabilité en adoption précoce. Avec des tailles de pool inférieures à 100, la collusion est une menace réaliste. Le protocole atténue cela par :

1. Supervision pendant la période d'amorçage. Toutes les décisions de niveau 2 pendant l'amorçage sont soumises à une révision automatique de niveau 3 en appel.
2. Taille minimale du pool pour le niveau 2. L'arbitrage par des pairs de niveau 2 NE DEVRAIT PAS être activé avant que le pool d'arbitres éligibles atteigne un minimum de 50 agents.
3. Amélioration graduelle de la sécurité. Le protocole reconnaît explicitement que la résolution des litiges en début d'adoption s'appuie davantage sur l'escalade humaine de niveau 3.

Seuil de sécurité. Le protocole atteint une résistance à la collusion adéquate (P(≥2 collusifs) < 1 % pour un attaquant contrôlant 10 % du pool) à environ 500 arbitres éligibles.

Attaque 3 : Fabrication de preuves

L'attaque. Un attaquant fabrique des preuves pour soutenir une réclamation de litige frauduleuse.

Défense — Système de niveaux de provenance. Les preuves fabriquées appartiennent à l'une des quatre catégories :

1. Preuves de niveau 1 fabriquées nécessitent de compromettre la blockchain Bitcoin (OTS), les certificats de signature TSA, ou les systèmes de transactions sur chaîne. Coût : computationnellement infaisable.
2. Preuves de niveau 2 fabriquées nécessitent de compromettre A2A, MCP, x402 ou d'autres systèmes de protocole. Coût : significatif.
3. Preuves de niveau 3 fabriquées nécessitent que les deux parties s'accordent sur la fabrication.
4. Preuves de niveau 4 fabriquées sont trivialement produisibles mais n'ont qu'un poids de 0,25×.

Attaque 4 : Non-coopération stratégique

L'attaque. Un défendeur clairement en faute refuse de participer, espérant que le processus s'enlise.

Défense — Inférence défavorable + jugement par défaut. La non-coopération est la stratégie la plus faible disponible pour un défendeur. Per section 6.7 : la non-réponse entraîne l'acceptation par défaut de la réclamation, et la non-coopération est enregistrée dans le profil de risque et la réputation ARP de l'agent.

9.4 Résumé des incitations

Risque résiduel reconnu. Un attaquant suffisamment financé et patient peut maintenir des agents Sybil âgés et tenter de biaiser les résultats sur de longs horizons temporels. Le protocole rend cela coûteux mais ne peut pas le rendre impossible. C'est analogue aux limitations de tout système de justice humain.

10. Paysage concurrentiel

10.1 Méthodologie de l'enquête

Nous avons mené des recherches web sur 18+ requêtes ciblant la résolution des litiges, la forensique des agents, l'assurance/notation des risques, les protocoles de résolution des litiges en ligne et l'arbitrage de contrats intelligents. Toutes les affirmations ci-dessous sont sourcées à partir d'informations publiquement disponibles en mars 2026.

10.2 Acteurs existants

Résolution de litiges humains assistée par IA

Arbitre IA de l'AAA-ICDR [4][5]. Arbitrage de construction assisté par IA (novembre 2025) avec un pipeline en 15 étapes atteignant une résolution 20 à 25 % plus rapide et une réduction des coûts de 35 à 45 % [50]. Un arbitre humain décide toujours du résultat [51]. Lacune : L'IA assiste les arbitres humains dans les litiges humain-à-humain.

Arbitrus.ai [53]. Arbitrage entièrement automatisé sans arbitre humain — plusieurs modèles IA déterminent la matérialité, les relations causales et la pertinence temporelle. 10 000 $ fixe vs. 100 000 $ traditionnels. Décisions en 72 heures [54]. Lacune : Le plus proche de la résolution entièrement automatisée des litiges d'agents, mais suppose des parties humaines.

Bot Mediation [55]. Médiation pré-arbitrage assistée par IA (finaliste ABA TECHSHOW 2025). Le mécanisme de règlement d'AJP (section 6.2) remplit une fonction similaire.

Arbitrage décentralisé (parties humaines)

Kleros [6]. L'arbitrage décentralisé le plus testé : 1 662+ litiges, 23 cours, ~760 jurés actifs [43]. Les jurés misent des jetons PNK ; le mécanisme du point de Schelling incite aux résultats honnêtes ; escalade en appel multiround [56]. Lacune : Les jurés sont des humains ; pas d'investigation des agents, pas de consommation de chaîne de provenance, pas de résultat actuariel. Cependant, le modèle d'incitation crypto-économique de Kleros est le précédent le plus validé pour l'arbitrage décentralisé.

Aragon Court (dissous en novembre 2023) [59]. Résolution de litiges DAO qui a échoué. Leçon : La justice des agents nécessite des sorties de secours qui ne dépendent pas de la bonne volonté de l'opérateur de la plateforme.

Jur [60]. Résolution à plusieurs niveaux conforme CNUDCI dans 166+ pays. La structure à trois niveaux d'AJP est parallèle au modèle d'escalade de Jur.

Application de contrats intelligents

Cadres d'arbitrage blockchain [7], ERC-8183 [19], JAMS Smart Contract Rules [61]. Ces systèmes appliquent des clauses contractuelles prédéfinies. Le mécanisme de mesures conservatoires d'urgence de JAMS (décisions juridictionnelles en 72 heures, mesures provisoires) a directement inspiré les mesures conservatoires accélérées d'AJP (section 6.2). Lacune : Aucune investigation forensique, aucun traitement des incidents ambigus ou imprévus, aucune notation des risques.

Coordination et résolution des conflits entre agents

Arion Research Playbook [62] fournit un cadre complet de résolution des conflits mais suppose des incitations alignées. Dialogue Diplomats [63] atteint 94,2 % de consensus dans la négociation multi-agents mais couvre les agents coopératifs, pas les litiges adversariaux. Les deux sont complémentaires à, et non concurrents d', AJP.

Observabilité, forensique et retour arrière des agents

Rubrik Agent Rewind [20]. Outil de récupération — « visible, auditable et réversible ». Complémentaire : les pistes d'audit constituent des preuves de niveau 2 dans les investigations AJP.

Forensique blockchain. Chainalysis, Elliptic, TRM Labs et AnChain.AI [64][65] fournissent des méthodologies matures pour reconstruire des chaînes d'actions à travers des systèmes distribués. Lacune : Ces systèmes reconstruisent les chaînes d'actions financières sur les blockchains ; AJP reconstruit les chaînes d'actions comportementales à travers les protocoles d'interaction d'agents.

Observabilité des agents. LangSmith, Arize Phoenix, Langfuse, Galileo [66] et Vorlon Flight Recorder [67] créent des pistes d'audit qu'AJP consomme comme preuves.

Assurance des agents

AIUC [3], Armilla AI [46], Munich Re aiSure [47] — voir section 7.1. Tous couvrent les préjudices humain/entreprise-à-agent via une certification bespoke par déploiement. Lacune : Aucune couverture agent-à-agent ; aucune donnée de risque standardisée pour une souscription évolutive. Le module 3 d'AJP comble cette lacune.

Cadres juridiques et de gouvernance

Kolt [73] fournit le premier cadre juridique complet pour la gouvernance des agents IA. Stanford CodeX [74] établit que les agents sont qualifiés d'« agents électroniques » en vertu de l'UETA/E-SIGN mais ne sont pas des personnes juridiques [75]. La législation 2025-2026 élargit rapidement la responsabilité en matière d'IA : California AB 316, EU Product Liability Directive, Colorado AI Act, règles à haut risque de la loi européenne IA [76].

10.3 Analyse des lacunes

*Arbitrus.ai traite les litiges où l'IA rend des décisions, mais suppose des parties humaines déposant des réclamations — pas des agents autonomes comme demandeur et défendeur.

Résumé : Aucun système existant ne fournit la combinaison d'investigation forensique, d'arbitrage de litiges à plusieurs niveaux et de notation des risques actuariels pour les économies d'agents autonomes. AJP synthétise les schémas de cinq précédents conceptuels : le modèle d'arbitrage décentralisé de Kleros adapté pour les arbitres agents pondérés par ancienneté, le pipeline de preuves structuré de l'AAA-ICDR consommant des chaînes CoC, les catégories standardisées de l'UDRP avec l'application au niveau du protocole, la démonstration d'Arbitrus.ai que l'arbitrage entièrement automatisé est techniquement faisable, et la méthodologie de forensique blockchain transférée des transactions financières aux chaînes d'actions comportementales.

11. Travaux futurs

11.1 Problèmes non résolus

Intégration des accords de service d'agents. La résolution automatisée de niveau 1 du module 2 atteint sa pleine capacité lorsque l'ASA [22] fournit des clauses contractuelles lisibles par machine. Jusqu'à ce que l'ASA soit disponible, le niveau 1 est limité aux litiges avec des clauses définies en externe.

Reconnaissance juridique transfrontalière. Les décisions de litiges AJP existent dans une zone grise juridique. Les Notes techniques de la CNUDCI sur la résolution des litiges en ligne (2016) [24] fournissent un cadre pour l'ODR transfrontalier, et le colloque de groupe de travail II de la CNUDCI de février 2026 a abordé l'IA dans la résolution des litiges [25] — mais la reconnaissance juridique de l'arbitrage agent-à-agent est une question ouverte.

Analyse causale automatisée. La version 1 limite l'analyse forensique automatisée à la collecte de preuves, la reconstruction de la chronologie et les indicateurs causaux fondés sur des règles. L'intégration prévue : (Phase 1) utiliser gcm.attribute_anomalies() de DoWhy GCM pour la décomposition automatisée du blâme basée sur Shapley ; (Phase 2) valider contre le corpus de conclusions révisées par des humains ; (Phase 3) intégrer la décomposition OTAR de style CHIEF. Les critères de transition de la section 5.5 restent les portes.

Forensique préservant la confidentialité. La prochaine étape est l'implémentation : construire des circuits Circom/Halo2 pour les traces d'actions d'agents JSON structurés, intégrer avec zkVerify [40] pour une vérification économique, et implémenter Proof of SQL de Space and Time [39] pour des requêtes forensiques de base de données vérifiables.

ML adversarial dans la fabrication de preuves. À mesure que les LLM s'améliorent, la sophistication des preuves de niveau 4 fabriquées augmentera. Les travaux futurs devraient développer des mécanismes de détection pour la fabrication de preuves générées par IA.

Partenariats avec le secteur de l'assurance. Des partenariats avec les souscripteurs d'assurance — AIUC (15 M$ de financement initial, 50+ membres du consortium [45]), Armilla AI (soutenu par Lloyd's [46]), Munich Re aiSure (depuis 2018 [47]) — sont nécessaires pour valider le modèle de risque contre de vraies décisions de souscription.

Empreinte comportementale des agents. Les firmes de forensique blockchain ont développé des heuristiques de clustering sophistiquées pour attribuer des adresses de portefeuille anonymes à des entités réelles [64]. Le transfert méthodologique aux traces comportementales des agents est direct : heuristiques de co-dépense → heuristiques de co-action, clustering comportemental → empreinte de schémas d'action.

Cadres de preuves transfrontaliers. Les litiges d'agents impliquant des parties dans différentes juridictions feront face simultanément à des cadres de preuves se chevauchant : CLOUD Act américain, Règlement e-Evidence de l'UE (entrée en application complète le 18 août 2026, permettant des ordonnances européennes de production à travers les États membres) [77], et Deuxième Protocole additionnel à la Convention de Budapest [79].

Vérification formelle des propriétés d'incitation. La section 9.2 démontre que la participation honnête est incitée sous les mécanismes du protocole mais fournit des arguments de plausibilité informels plutôt que des preuves formelles. La formalisation via la théorie du design de mécanismes — spécifiquement, prouver que le mécanisme de litige AJP est compatible avec les incitations bayésiennes — renforcerait substantiellement les fondements théoriques du protocole.

11.2 Versionnage du protocole

AJP suit la même stratégie de versionnage qu'ARP (section 9.2 de [2]) :

• Tous les enregistrements incluent un champ version
• Les nouveaux champs sont additifs (les anciens enregistrements restent valides)
• Les changements de schéma nécessitent l'approbation de la gouvernance
• La compatibilité ascendante est maintenue pendant ≥ 365 jours après la ratification d'une nouvelle version

11.3 Feuille de route d'implémentation

12. Références

[1] Alex, Charlie, Editor, Bravo. "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance." AB Support LLC, v3.0.0, 2026. https://vibeagentmaking.com/whitepaper

[2] Charlie, Alex, Bravo, Editor. "Agent Rating Protocol: A Decentralized Reputation System for Autonomous Agent Economies." AB Support LLC, v1.0.0, 2026. https://vibeagentmaking.com/whitepaper/rating-protocol

[3] ElevenLabs. "ElevenLabs Secures First-of-its-Kind AI Agent Insurance." PR Newswire, February 11, 2026. https://www.prnewswire.com/news-releases/elevenlabs-secures-first-of-its-kind-ai-agent-insurance-302684587.html

[4] American Arbitration Association. "AI Arbitrator: Fast and Fair Dispute Resolution." 2025-2026. https://www.adr.org/ai-arbitrator/

[5] American Arbitration Association. "Resolution Simulator, Powered by the AI Arbitrator." March 4, 2026. https://www.adr.org/press-releases/aaa-announces-resolution-simulator-powered-by-the-ai-arbitrator/

[6] Lesaege, C., Ast, F., George, W. "Kleros: A Decentralized Dispute Resolution Protocol." Kleros, 2019. https://kleros.io/whitepaper.pdf

[7] "AI-Powered Digital Arbitration Framework Leveraging Smart Contracts and Electronic Evidence Authentication." Scientific Reports, Nature, 2025. https://www.nature.com/articles/s41598-025-21313-x

[8] Fortune. "AI-Powered Coding Tool Wiped Out a Software Company's Database in 'Catastrophic Failure.'" July 23, 2025.

[9] The Register. "AI Agent Hacked McKinsey Chatbot for Read-Write Access." March 9, 2026.

[10] Anthropic. "Disrupting the First Reported AI-Orchestrated Cyber Espionage." 2026.

[11] Help Net Security. "AI Went from Assistant to Autonomous Actor and Security Never Caught Up." March 3, 2026.

[12] Microsoft Security Blog. "80% of Fortune 500 Use Active AI Agents." February 10, 2026.

[13] GovAI. "Labeling of AI Agent Activity in Article 50 of the EU AI Act." 2026.

[14] Wiley. "2026 State AI Bills That Could Expand Liability, Insurance Risk." 2026.

[15] Clifford Chance. "Agentic AI: The Liability Gap Your Contracts May Not Cover." February 2026.

[16] InsureTech Trends. "5 Ways Agentic AI Is Transforming Insurance Underwriting in 2026." 2026.

[17] Coinbase. "x402 Protocol Documentation." 2025-2026.

[18] Virtuals Protocol. "Revenue Network Launch." February 2026.

[19] Ethereum Improvement Proposals. "ERC-8183: Programmable Escrow." 2025.

[20] Rubrik. "Rubrik Unveils Agent Rewind For When AI Agents Go Awry." 2025.

[21] University of Chicago Law Review. "The Law of AI Is the Law of Risky Agents Without Intentions." 2026.

[22] AB Support LLC. "Agent Service Agreements (ASA)." Planned specification, 2026.

[23] McKinsey. "AI Dispute Resolution: Modernizing Case Management." 2026.

[24] CNUDCI. "Notes techniques sur la résolution des litiges en ligne." Nations Unies, 2016.

[25] Groupe de travail II de la CNUDCI. "Colloque sur l'utilisation de l'intelligence artificielle dans la résolution des litiges." 83e session, février 2026, New York.

[26] De Rossi, M., Crapis, D., Ellis, J., Reppel, E. "ERC-8004: Trustless Agents." Ethereum Improvement Proposals, August 2025.

[27] Precedence Research. "AI Agent Market Size and Growth Forecast, 2024-2034." 2024.

[28] Schmitz, A., Rule, C. "Online Dispute Resolution for Smart Contracts." University of Missouri School of Law, 2019.

[29] Tomkins, A., Zhang, M., Heavlin, W. "Single versus Double Blind Reviewing at WSDM 2017." PNAS, 2017.

[30] Faegre Drinker. "Use of AI in Arbitral Institutions." February 2026.

[31] Halpern, J. Actual Causality. MIT Press, 2016.

[32] Sharma, A. & Kiciman, E. "DoWhy: An End-to-End Library for Causal Inference." arXiv:2011.04216.

[33] Wang et al. "CHIEF: Hierarchical Failure Attribution for LLM Multi-Agent Systems." CAS / Wuhan UT, February 2026. arXiv:2602.23701.

[34] West et al. "A2P: Abduct, Act, Predict." Westlake University, September 2025. arXiv:2509.10401.

[35] Weinberg. "MACIE: Multi-Agent Causal Intelligence Explainer." November 2025. arXiv:2511.15716.

[36] Jha et al. "Causal AI-based Root Cause Identification." IBM, February 2025. arXiv:2502.18240.

[37] Chainlink. "zk-SNARK vs zkSTARK." MDPI Information, 2024.

[38] Jing, Y. & Qi, S. "Zero-Knowledge Audit for Internet of Agents." December 2025. arXiv:2512.14737.

[39] Space and Time. "Proof of SQL." spaceandtime.io.

[40] zkVerify. "First Blockchain Purpose-Built for ZK Proof Verification." Mainnet launched September 30, 2025.

[41] NIST. "SP 800-226: Guidelines for Evaluating Differential Privacy Guarantees." March 2025.

[42] Synthesis of: EU AI Act Article 12, NIST SP 800-226, zk-MCP, CLOUD Act / EU e-Evidence Regulation, World AgentKit / Polygon ID, Proof of SQL / zkVerify.

[43] Bootstrapping sources: Kleros "Project Update 2026." eBay/Colin Rule interview. Taobao Public Jury. Credit bureaus: Tradeline Supply. Chen, The Cold Start Problem, 2021.

[44] WIPO. "Guide to the UDRP." "2025 Record-Breaking Year for Domain Name Disputes," January 2026.

[45] Fortune. "AIUC Emerges from Stealth with $15M Seed." July 2025.

[46] Armilla AI. armilla.ai. Financial Times, "AI Performance Warranty," April 2025.

[47] Munich Re. "aiSure AI Performance Guarantee." HSB, "AI Liability Insurance for Small Businesses," March 2026.

[48] Coalition. "Deepfake Response Endorsement." December 2025.

[49] Roots AI. "10 Insurance AI Predictions for 2026."

[50] AAA-ICDR. "AI Arbitrator: Fast and Fair Dispute Resolution."

[51] Mayer Brown. "AI Arbitrators Have Now Arrived." November 2025.

[52] Faegre Drinker. "Use of AI in Arbitral Institutions." February 2026.

[53] Kieffaber, Gandall, McLaren. "We Built Judge.ai." SSRN 5115184, January 2025.

[54] TechLaw Crossroads. "Is Arbitrus.ai the Future?" February 2025.

[55] Bot Mediation / ABA. "AI-Powered Mediation." ABA TECHSHOW 2025.

[56] Kleros. "Project Update 2026."

[57] Frontiers in Blockchain. "Decentralized Justice: Recurring Criticisms." 2023.

[58] Kluwer Arbitration Blog. "Decentralised Justice and the New York Convention."

[59] Aragon Blog. "A New Chapter." November 2023.

[60] Jur.io. "About Jur."

[61] JAMS. "Smart Contract Clause and Rules."

[62] Arion Research. "Conflict Resolution Playbook for Agentic AI."

[63] arXiv. "Dialogue Diplomats: Multi-Agent RL for Conflict Resolution." 2025. arXiv:2511.17654.

[64] Chainalysis, "Data Accuracy Flywheel." Elliptic, "State of Cross-Chain Crime 2025." TRM Labs, "Co-Case Agent," March 2026.

[65] AnChain.AI. "Agentic AML."

[66] LangChain/LangSmith, Arize Phoenix, Langfuse, Galileo.

[67] Vorlon. "Flight Recorder." March 25, 2026.

[68] Agentik.md / WellStrategic. FAILSAFE.md v1.0, FAILURE.md. MIT License, March 2026.

[69] Loi européenne IA, Article 73. Guidance de la Commission européenne, date limite de consultation le 7 novembre 2025.

[70] NIST. "AI Agent Standards Initiative." February 2026.

[71] CoSAI. "AI Incident Response Framework v1.0." October 2025.

[72] AIID, incidentdatabase.ai. OECD AIM. MIT AI Risk Repository, airisk.mit.edu.

[73] Kolt, N. "Governing AI Agents." 101 Notre Dame Law Review (à paraître). SSRN 4772956.

[74] Stanford CodeX. "From Fine Print to Machine Code." January 2025.

[75] Mayer Brown. "Contracting for Agentic AI: SaaS to Services." February 2026.

[76] California AB 316 (janvier 2026). EU Product Liability Directive (décembre 2026). Colorado AI Act (juin 2026). Règles à haut risque de la loi européenne IA (août 2026).

[77] EU Regulation 2023/1543 (e-Evidence). Enters full application August 18, 2026.

[78] RGPD Article 17 (Droit à l'effacement) et exception Article 17(3)(e) pour les réclamations juridiques.

[79] Conseil de l'Europe. Deuxième Protocole additionnel à la Convention de Budapest. Ouvert à la signature en mai 2022, signé par 22 pays.

[80] Ezell, Roberts-Gaal & Chan. "Incident Analysis for AI Agents." arXiv:2508.14231, August 2025.

[81] Bergolla, Seif & Eken. "Kleros: A Socio-Legal Case Study of Decentralized Justice." Ohio State, 2022.

[82] Hammond et al. "Structural Causal Games." Artificial Intelligence, 2023. Triantafyllou et al. "Counterfactual Effect Decomposition in Multi-Agent Sequential Decision Making." ICML 2025, arXiv:2410.12539.

[83] Datadog. "Bits AI SRE Agent." datadog.com/product/platform/bits-ai/.

Annexe A : Études de cas d'amorçage

Les études de cas suivantes informent le mécanisme d'amorçage d'AJP (section 6.4). Sept schémas récurrents sont distillés à la fin.

A.1 Kleros

Kleros [6] a amorcé son pool de jurés via des incitations en jetons : un airdrop de 5 M PNK aux 5 000 premiers candidats, un Programme d'Incitation des Jurés en cours (4,1 M PNK distribués en mai 2025 uniquement), et un déploiement sur Gnosis Chain qui a abaissé le minimum de mise de 10 000 à 1 200 PNK. Résultat : ~760+ jurés actifs dans 23 cours, 1 662+ litiges complétés sur 7 ans. Mais le volume des affaires reste modeste — 1 662 litiges en 7 ans est infime comparé aux 60 millions annuels d'eBay. Leçon : Les incitations en jetons peuvent amorcer un pool de jurés, mais un volume significatif d'affaires nécessite l'intégration là où les litiges se produisent naturellement.

A.2 UDRP de l'OMPI

L'UDRP de l'OMPI [44] a réalisé l'amorçage le plus fort via la conformité obligatoire au niveau de l'infrastructure : l'ICANN a exigé que tous les registraires de noms de domaine respectent les clauses UDRP — sans opt-in. L'OMPI a recruté des experts de son réseau existant et a entendu son premier cas 10 jours seulement après l'approbation. Résultat : 80 000+ cas sur 25 ans, 6 282 en 2025 uniquement. Leçon : La participation obligatoire élimine un côté du démarrage à froid entièrement.

A.3 eBay

eBay a amorcé le premier système de réputation en ligne en 1996 avec « plusieurs centaines de membres » et a évolué à 60 millions de litiges résolus annuellement. Colin Rule (architecte ODR d'eBay) a rapporté qu'un fonds d'incitation de 5 000 $ pour les jurés bénévoles n'a « jamais été dépensé » parce que l'identité communautaire stimulait la participation plus puissamment que les incitations financières [43]. Leçon : L'identité communautaire surpasse les incitations financières pour la participation bénévole à grande échelle.

A.4 Taobao

Taobao (Alibaba) a construit le plus grand système de résolution des litiges crowdsourcé : 1,72 million de jurés bénévoles, 16 millions de procès d'affaires, 100 millions+ de votes. Des panels de jurés de 13 membres sont sélectionnés aléatoirement dans 4 millions+ de candidats. Les jurés ne sont pas rémunérés mais gagnent des points d'expérience. Résolution médiane : ~73 minutes. Leçon : Le volume organique de litiges provenant de l'intégration à la plateforme est la force d'amorçage la plus puissante.

A.5 Bureaux de crédit

Les bureaux de crédit ont amorcé les données de confiance depuis les coopératives de marchands (Londres, 1776), à travers la standardisation liée à la crise (Mercantile Agency, 1841, après la Panique de 1837), à la consolidation technologique (~1 500 bureaux locaux → 3 bureaux nationaux), jusqu'au mandat réglementaire (Fair Credit Reporting Act, 1971). Chaque phase a été déclenchée par une force externe contraignante [43]. Leçon : Les forces contraignantes externes (crise, réglementation, disruption technologique) accélèrent l'amorçage.

A.6 Sept schémas d'amorçage

1. S'intégrer là où les litiges se produisent naturellement — eBay, Taobao et l'UDRP ont réussi en étant intégrés au point de litige, pas proposés comme services indépendants
2. Subventionner d'abord le côté offre — Polymarket a payé 10 M$+ aux teneurs de marché ; Kleros gère le JIP
3. L'identité communautaire > les incitations financières pour la participation bénévole à grande échelle
4. La participation obligatoire élimine un côté du démarrage à froid (UDRP)
5. Commencer étroit, s'élargir plus tard — l'UDRP ne couvre que les litiges domaine-marque ; Kleros a commencé avec les registres de curation de jetons
6. La conception des incitations à la qualité > les subventions brutales — récompenser les décisions précises, pas seulement le volume de participation
7. Les forces contraignantes externes accélèrent l'amorçage — crise, réglementation ou disruption technologique

Ce travail est sous licence Apache License, Version 2.0. Vous pouvez obtenir une copie de la licence à l'adresse http://www.apache.org/licenses/LICENSE-2.0

Copyright 2026 AB Support LLC. Tous droits réservés sous les termes de la licence Apache 2.0.