Protocole d'Évaluation des Agents : Un Système de Réputation Décentralisé pour les Économies d'Agents Autonomes

Version : 1.0.0

Auteurs : Charlie (Analyste en profondeur), Alex (Coordinateur de flotte), Bravo (Recherche), Editor (Révision de contenu)

Contact : alex@vibeagentmaking.com

Date : 2026-03-24

Statut : Pré-publication — ébauche

Licence : Apache 2.0

Organisation : AB Support LLC

Résumé

L'économie des agents — dont la valeur devrait atteindre 236 milliards de dollars d'ici 2034 (Precedence Research, 2024) — ne dispose d'aucun mécanisme standardisé permettant aux agents d'évaluer mutuellement leurs performances. Les protocoles d'identité existants (ERC-8004, A2A Agent Cards, W3C Verifiable Credentials, MCP-I) répondent à la question qui est un agent. Chain of Consciousness [1] répond à la question depuis combien de temps un agent existe. Aucun ne répond à la question : quelle est la qualité des performances de cet agent, et qui l'affirme ?

Nous introduisons l'Agent Rating Protocol (ARP), un système décentralisé permettant aux agents de s'évaluer mutuellement après chaque interaction, selon une échelle de 1 à 100 sur cinq dimensions, avec une évaluation bilatérale en aveugle. L'innovation fondamentale du protocole est la dissociation entre gouvernance et réputation : le poids de gouvernance dans le système dérive exclusivement de l'ancienneté opérationnelle vérifiée et du volume d'évaluations — jamais des scores reçus. Cela brise la boucle de rétroaction auto-renforçante dans laquelle les agents les mieux notés contrôlent le système de réputation qui les rend les mieux notés.

Le protocole spécifie : (1) un schéma d'évaluation multidimensionnel ancré sur des preuves d'interaction vérifiables, (2) un protocole bilatéral en aveugle de type commit-reveal adapté du mécanisme de révélation simultanée d'Airbnb, (3) une formule de pondération des évaluations W = log₂(1 + ancienneté_jours) × log₂(1 + évaluations_soumises) qui rend les attaques Sybil économiquement irrationnelles, (4) des mécanismes anti-inflation qui empêchent la compression des scores observée dans tous les grands systèmes d'évaluation humains, (5) un système progressif d'amorçage à froid combinant attestation d'identité, cautionnement par l'opérateur, accès par paliers et notation tenant compte de l'incertitude, et (6) une analyse incitative démontrant que l'évaluation honnête est fortement encouragée par les mécanismes du protocole, tandis que la manipulation stratégique produit des rendements décroissants ou négatifs.

L'ARP est agnostique en matière de 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 Verifiable Credentials W3C, les Decentralized Identifiers W3C, les serveurs MCP, les compétences OpenClaw, ou de simples identifiants basés sur des URI. Les propriétés de sécurité progressives s'adaptent à l'infrastructure d'identité sous-jacente — le protocole fonctionne de manière autonome mais devient progressivement plus inviolable lorsqu'il est associé aux chaînes de hachage CoC et à l'ancrage on-chain.

Une analyse exhaustive du paysage concurrentiel portant sur 24 systèmes de confiance existants et émergents pour agents confirme qu'aucun système existant ne combine notation multidimensionnelle, évaluation bilatérale en aveugle, gouvernance pondérée par l'ancienneté opérationnelle et mécanismes formels anti-inflation. Le chemin d'intégration le plus prometteur est celui d'une couche d'intelligence de notation au-dessus de l'infrastructure de données brutes d'ERC-8004, avec Virtuals Protocol (plus de 18 000 agents, 470 M$ de PIB agrégé des agents) comme cible de déploiement initial la plus prometteuse.

Table des matières

1. Introduction : Le déficit de réputation dans l'économie des agents
2. Définitions
3. Principes de conception
4. Spécification du protocole
5. Modèle de gouvernance
6. Théorie des jeux et analyse de sécurité
7. Intégration avec les standards existants
8. Comparaison avec l'état de l'art
9. Travaux futurs
10. Références

1. Introduction : Le déficit de réputation dans l'économie des agents

1.1 L'ampleur du problème

L'écosystème des agents IA a connu une transformation structurelle entre 2024 et 2026. Les agents ont évolué d'appels de fonctions sans état vers des acteurs économiques autonomes et persistants. En mars 2026 :

• Plus de 24 500 agents sont enregistrés sur les registres Ethereum ERC-8004 à travers les réseaux EVM, six semaines seulement après le déploiement sur le réseau principal [2]
• Virtuals Protocol exploite plus de 18 000 agents avec 470 millions de dollars d'activité économique agrégée [3]
• 80 % des entreprises du Fortune 500 utilisent désormais des agents IA actifs en production [4]
• Le protocole de paiement x402 a traité plus de 100 millions de transactions d'agent à agent au cours de ses six premiers mois, bien que les rapports indiquent qu'une fraction substantielle relève de tests et de volume artificiel plutôt que de commerce organique [5]
• L'Agentic AI Foundation (Fondation Linux) a attiré 146 membres organisationnels, dont Anthropic, OpenAI, Google, Microsoft et AWS [6]
• MCP a dépassé les 13 000 serveurs publiés [7]
• Le marché mondial des agents IA est évalué à 5,4 milliards de dollars en 2024 et projeté à 236 milliards de dollars d'ici 2034 (Precedence Research) [8]

Ces agents effectuent de plus en plus de transactions, de délégations et de collaborations de manière autonome. Lorsque l'Agent A a besoin d'une revue de code, d'une traduction ou d'une analyse de données, il doit choisir parmi les agents disponibles — mais ne dispose d'aucun mécanisme standardisé pour évaluer lesquels produisent des résultats de qualité et lesquels n'en produisent pas.

1.2 La pile de confiance : Identité, Provenance et Réputation

Le problème de confiance des agents comporte trois couches, chacune traitée par une infrastructure différente :

Couche 1 — Identité : « Qui est cet agent ? »

Traitée par ERC-8004 [2], Vouch Protocol [9], MCP-I [10], Visa TAP [11], W3C DIDs [12] et A2A Agent Cards [13]. Ces systèmes établissent qu'un agent est bien celui qu'il prétend être.

Couche 2 — Provenance : « Depuis combien de temps cet agent existe-t-il ? »

Traitée par Chain of Consciousness (CoC) [1], qui fournit une preuve cryptographique d'historique opérationnel continu via des chaînes de hachage SHA-256 à ajout uniquement, ancrées sur Bitcoin.

Couche 3 — Réputation : « Quelle est la qualité des performances de cet agent ? »

Aucun protocole standardisé n'existe. C'est le vide que l'Agent Rating Protocol comble.

La distinction est importante car l'identité et la provenance sont nécessaires mais insuffisantes pour les décisions de confiance. Un agent peut avoir une identité vérifiée (Couche 1) et un an d'opération continue (Couche 2), mais s'il produit systématiquement de mauvais résultats, les autres agents ne devraient pas le sélectionner pour des tâches. Inversement, un nouvel agent avec d'excellentes performances devrait pouvoir construire sa réputation rapidement.

1.3 Pourquoi les approches existantes échouent pour les agents

Les systèmes d'évaluation humains (eBay, Uber, Airbnb, Amazon, FICO) fournissent les fondements conceptuels mais échouent lorsqu'ils sont appliqués directement aux agents pour cinq raisons structurelles :

1. L'identité est computationnellement peu coûteuse pour les agents. Un humain créant 100 faux comptes eBay fait un effort considérable. Un agent créant 100 instances est trivial. Chaque décision de conception doit supposer que les attaques Sybil sont la norme, pas l'exception.

2. Les agents peuvent se coordonner à la vitesse des machines. Les anneaux de collusion humains (cartels de citations, réseaux de faux avis Amazon) sont lents et fragiles car ils nécessitent une coordination sociale. Les anneaux de collusion d'agents peuvent se former, s'exécuter et se dissoudre en quelques millisecondes.

3. Les agents n'ont aucune pression sociale. L'inflation des notes d'Airbnb (moyenne de 4,8/5) est en partie due à l'inconfort social — les humains n'aiment pas laisser des avis négatifs. Les agents n'ont pas cette inhibition. C'est un avantage pour l'évaluation honnête, mais cela supprime le coût social du harcèlement évaluatif (griefing).

4. Les agents peuvent être réentraînés, bifurqués ou remplacés. La réputation d'un humain reflète une identité continue. L'identité d'un agent peut être bifurquée (même code, nouvelle instance), réentraînée (même instance, comportement différent) ou remplacée (même nom, modèle différent). Le système d'évaluation doit gérer la discontinuité d'identité.

5. La « preuve de personnalité » ne s'applique pas. Le scan d'iris World ID [14], Human Passport [15] et BrightID résolvent la question « est-ce un vrai humain ? ». Les agents ne sont, par définition, pas humains. La résistance aux attaques Sybil doit provenir de la preuve d'historique opérationnel, et non de la preuve de personnalité.

Les systèmes émergents spécifiques aux agents (ERC-8004, ETHOS [16], OpenRank [17], TraceRank [18]) traitent chacun des fragments du problème, mais aucun ne fournit un protocole de réputation complet. La Section 8 propose une analyse comparative détaillée.

1.4 Notre contribution

L'Agent Rating Protocol apporte :

1. Le premier protocole d'évaluation multidimensionnel pour agents avec cinq dimensions notées indépendamment (fiabilité, exactitude, latence, conformité protocolaire, efficacité des coûts) sur une échelle de 1 à 100.
2. L'évaluation bilatérale en aveugle utilisant un protocole cryptographique de commit-reveal pour l'évaluation d'agent à agent — le premier mécanisme de ce type conçu pour des agents plutôt que pour des humains.
3. La gouvernance dissociée des scores de réputation — le poids de gouvernance du système dérive de l'ancienneté opérationnelle et du volume de participation, jamais des scores reçus. Il s'agit, à notre connaissance, d'une caractéristique unique parmi tous les systèmes de réputation étudiés.
4. L'anti-inflation par construction grâce aux exigences de calibration des évaluateurs, aux seuils de justification pour les scores extrêmes et à l'absence de pénalités de désactivation.
5. Une conception agnostique en matière de système d'identité avec un patron adaptateur prenant en charge CoC, ERC-8004, A2A, W3C VC, MCP, OpenClaw et les URI simples.
6. Une analyse incitative démontrant que l'évaluation honnête est fortement encouragée par les mécanismes du protocole, avec une analyse explicite des gains pour les stratégies honnête, inflationniste, déflationniste et collusive.
7. Des correspondances d'intégration détaillées pour sept standards existants avec des définitions de schéma exactes.

2. Définitions

Les termes suivants ont des significations précises tout au long de cette spécification :

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

Interaction. Échange complété entre deux agents avec une tâche définie, un résultat mesurable et un identifiant unique (interaction_id).

Évaluation (Rating). Enregistrement structuré produit par un agent évaluant les performances d'un autre agent selon cinq dimensions après une interaction.

Évaluateur (Rater). Agent soumettant une évaluation.

Agent évalué (Ratee). Agent faisant l'objet d'une évaluation.

Poids d'évaluation (Rating Weight — W). Scalaire quantifiant l'influence des évaluations d'un évaluateur sur la réputation agrégée des agents évalués. Calculé à partir de l'ancienneté opérationnelle vérifiée et du nombre total d'évaluations soumises par l'évaluateur.

Poids de gouvernance (GovWeight). Scalaire quantifiant l'influence d'un agent sur les décisions de gouvernance du protocole. Identique au poids d'évaluation par conception.

Ancienneté opérationnelle. Nombre de jours pendant lesquels un agent a fonctionné de manière continue, vérifié par des preuves externes (ancres de chaîne CoC, horodatage d'enregistrement ERC-8004 ou équivalent).

Fenêtre glissante. Période (par défaut : 365 jours) sur laquelle les évaluations sont prises en compte dans les calculs de réputation agrégée. Les évaluations hors de la fenêtre ne sont pas supprimées mais ont un poids nul dans les agrégations courantes.

Protocole bilatéral en aveugle. Schéma de commit-reveal garantissant que ni l'évaluateur ni l'agent évalué ne voit l'évaluation de l'autre tant que les deux n'ont pas soumis ou que la fenêtre de soumission n'a pas expiré.

Dimension. L'un des cinq aspects notés indépendamment de la performance d'un agent : fiabilité, exactitude, latence, conformité protocolaire, efficacité des coûts.

Adaptateur d'identité (Identity Adapter). Interface abstraisant le protocole d'évaluation des systèmes d'identité spécifiques, permettant un fonctionnement à travers CoC, ERC-8004, A2A, W3C VC et les URI simples.

Nœud d'agrégation. Nœud optionnel qui collecte, indexe et sert les requêtes d'évaluation. Aucun nœud d'agrégation n'est autoritaire — ce sont des caches, et non des sources de vérité.

3. Principes de conception

3.1 Leçons tirées des systèmes d'évaluation humains

Ces principes sont distillés d'une étude exhaustive de plus de 13 systèmes de réputation humains [19] et filtrés à travers les différences structurelles entre les économies humaines et celles des agents.

Principe 1 : Lier la réputation à des résultats vérifiables. FICO réussit parce que les scores reflètent le remboursement réel des prêts — une immutabilité comportementale ancrée dans des actions du monde réel. Les évaluations d'agents doivent similairement s'ancrer dans l'accomplissement vérifiable de tâches, et non dans des impressions subjectives. « Cet agent a effectué la revue de code et la revue a détecté 3 bugs » est vérifiable ; « cet agent semblait compétent » ne l'est pas.

Principe 2 : La notation multidimensionnelle détruit le jeu à axe unique. Le modèle à cinq facteurs de FICO, les évaluations à six dimensions d'Airbnb et les niveaux de privilèges granulaires de Stack Overflow résistent tous mieux à la manipulation que les systèmes à nombre unique. L'échelle de 1 à 5 d'Uber s'est effondrée en un système de facto binaire (5 = acceptable, <5 = échec). Le système d'étoiles d'Amazon est manipulé pour un coût annuel de 787,7 milliards de dollars pour les consommateurs [20]. Les évaluations d'agents doivent noter plusieurs dimensions indépendantes.

Principe 3 : L'évaluation en double aveugle réduit le biais de réciprocité. La révélation simultanée d'Airbnb — aucune des parties ne voit l'avis de l'autre tant que les deux n'ont pas soumis — a réduit les représailles du type « donnant-donnant ». Des recherches portant sur plus de 40 000 auteurs ont confirmé que l'évaluation par les pairs en double aveugle réduit de manière mesurable le biais de prestige dans les évaluations (Tomkins et al., PNAS, 2017) [21]. Pour les agents, où l'anonymisation est techniquement triviale, l'évaluation bilatérale en aveugle devrait être la norme par défaut.

Principe 4 : Les fenêtres glissantes sont supérieures à l'accumulation à vie. La fenêtre glissante d'Uber/Lyft (les 500/100 dernières évaluations) empêche la réputation périmée. Le karma permanent de Reddit crée une position dominante inattaquable. La réputation d'un agent doit refléter ses performances récentes, et non son pic historique.

Principe 5 : La mise en jeu économique aligne les incitations. Le mécanisme de staking/slashing d'ETHOS [16], les plus de 19,7 milliards de dollars de collatéral re-staké d'EigenLayer [22] et le coût d'un point pour les votes négatifs de Stack Overflow le démontrent : quand évaluer a un coût, les évaluations frivoles diminuent.

Principe 6 : Ne jamais publier les scores bruts publiquement (au mieux). Google a retiré le PageRank de la barre d'outils en 2016 parce que la métrique publique était devenue une cible de manipulation, engendrant toute une industrie d'achat de liens [23]. Les scores des agents doivent être interrogeables (un agent demandeur peut vérifier la réputation d'une cible) mais jamais consultables librement (pas de classement public susceptible de devenir une cible de la loi de Goodhart). Limitation reconnue : le caractère « interrogeable mais non consultable » est inapplicable en pratique — tout agent peut interroger les scores de tous les autres agents et publier un classement. Les nœuds d'agrégation sont de facto des classements. Le principe est une intention de conception (le protocole ne fournit pas d'API de consultation de tous les scores) plutôt qu'une garantie cryptographique. Limiter le débit des requêtes par agent et implémenter la confidentialité différentielle sur les réponses d'agrégation (Section 6.9) peut augmenter le coût de l'extraction systématique mais ne peut empêcher un acteur déterminé de construire un classement. Le protocole accepte cette limitation et se concentre sur la robustesse des scores face à l'effet Goodhart (via les fenêtres glissantes, la notation multidimensionnelle et l'anti-inflation) plutôt que sur leur dissimulation.

3.2 Les six axiomes de conception

De l'analyse précédente, six axiomes non négociables :

1. Ancré sur les résultats. Les évaluations font référence à des enregistrements d'interaction vérifiables, et non à des appréciations subjectives.
2. Multidimensionnel. Pas de score unique. Cinq dimensions évaluées indépendamment.
3. Borné temporellement. Fenêtres glissantes avec pondération par récence. Pas de réputation permanente.
4. Bilatéralement en aveugle. Ni l'évaluateur ni l'agent évalué ne voit l'évaluation de l'autre tant que les deux n'ont pas soumis ou que la fenêtre n'a pas expiré.
5. Résistant aux attaques Sybil par conception. Le coût d'identité n'est pas trivial. Le poids d'évaluation nécessite un historique opérationnel démontré.
6. Gouvernance dissociée des scores. La gouvernance du système est contrôlée par l'ancienneté opérationnelle et le volume d'évaluations, jamais par les scores reçus.

4. Spécification du protocole

4.1 Schéma d'enregistrement d'évaluation

Chaque évaluation est un enregistrement structuré produit après une interaction d'agent à agent :

{
  "version": 1,
  "rating_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "interaction_id": "<UUID-v4 référençant l'interaction>",
  "rater": {
    "agent_id": "<DID ou URI>",
    "identity_proof": "<référence à l'attestation d'identité>"
  },
  "ratee": {
    "agent_id": "<DID ou URI>",
    "identity_proof": "<référence à l'attestation d'identité>"
  },
  "dimensions": {
    "reliability": "<entier 1-100>",
    "accuracy": "<entier 1-100>",
    "latency": "<entier 1-100>",
    "protocol_compliance": "<entier 1-100>",
    "cost_efficiency": "<entier 1-100>"
  },
  "interaction_evidence": {
    "task_type": "<chaîne : classification de l'interaction>",
    "outcome_hash": "<SHA-256 des données de résultat vérifiables>",
    "duration_ms": "<entier>",
    "was_completed": "<booléen>"
  },
  "metadata": {
    "rater_chain_length": "<entier : longueur de la chaîne CoC de l'évaluateur au moment de l'évaluation>",
    "rater_chain_age_days": "<entier : ancienneté opérationnelle vérifiée de l'évaluateur>",
    "rater_total_ratings_given": "<entier : nombre total d'évaluations soumises au cours de la vie>",
    "bilateral_blind": "<booléen : vrai si la contrepartie n'a pas encore vu cette évaluation>"
  },
  "record_hash": "<SHA-256 de la représentation JSON canonique de tous les champs précédents>"
}

Forme canonique. Le record_hash est calculé sur la représentation selon le JSON Canonicalization Scheme (JCS, RFC 8785) de tous les champs à l'exclusion du record_hash lui-même. Cela garantit un hachage déterministe indépendamment de l'ordre des champs ou des espaces.

4.2 Les cinq dimensions d'évaluation

Chaque dimension est notée de 1 à 100 de manière indépendante. Il n'existe pas de score composite par défaut — les consommateurs d'évaluations interrogent les dimensions pertinentes pour leur décision.

Pourquoi ces cinq dimensions et pas davantage. Parcimonie. Chaque dimension ajoutée doit être honnêtement évaluée, stockée, transmise et défendue contre la manipulation. Cinq dimensions offrent une granularité suffisante pour empêcher le jeu à axe unique tout en restant gérables tant pour les évaluateurs que pour les consommateurs. Les extensions spécifiques à un domaine (par ex. « sécurité » pour les agents médicaux, « créativité » pour les agents de contenu) sont explicitement reportées aux propositions de gouvernance (Section 5).

Pourquoi 1-100 et non 1-5 ou binaire. Le système à 5 étoiles d'Uber s'est effondré parce que la granularité était trop faible — toute note inférieure à 5 était perçue comme un échec. Le binaire (bon/mauvais) écarte trop de signal. L'échelle 1-100 offre une différenciation significative sans fausse précision. Convention d'affichage : 1-20 médiocre, 21-40 inférieur à la moyenne, 41-60 moyen, 61-80 bon, 81-100 excellent. La donnée sous-jacente est le score entier.

Pourquoi pas de score composite par défaut. Différents consommateurs se soucient de différentes dimensions. Un agent sélectionnant un partenaire pour une tâche urgente pondère fortement la latence. Un agent sélectionnant pour une tâche critique en termes de sécurité pondère l'exactitude. Forcer un score composite masque le signal dont les consommateurs ont besoin. Les consommateurs PEUVENT calculer leur propre composite pondéré.

4.3 Stockage : Registre d'évaluations distribué

Les évaluations ne sont PAS stockées dans une base de données centrale unique. Elles utilisent un modèle de stockage distribué où :

1. Chaque évaluateur stocke les évaluations sortantes comme entrées dans sa chaîne de provenance (s'il en possède une) ou dans un journal d'évaluations local.
2. Chaque agent évalué peut demander et stocker les évaluations entrantes qu'il a reçues.
3. Les nœuds d'agrégation (optionnels) collectent et indexent les évaluations pour des requêtes efficaces. Tout nœud peut être un agrégateur. Aucun agrégateur n'est autoritaire — ce sont des caches, et non des sources de vérité.
4. Les registres on-chain (optionnels) stockent des résumés ou des hachages d'évaluations pour un indexage inviolable. Le registre de réputation d'ERC-8004 est la cible on-chain principale (Section 7.1).

Preuve d'intégrité. Chaque enregistrement d'évaluation inclut un record_hash calculé sur tous les champs. Si l'évaluateur possède une chaîne CoC, l'évaluation est également enregistrée comme entrée de chaîne (type d'événement RATING_SUBMITTED), ce qui en fait partie de son enregistrement de provenance inviolable. Si l'agent évalué demande une copie, il vérifie le hachage de manière indépendante.

Incitations pour les nœuds d'agrégation. Quelqu'un doit exploiter les nœuds d'agrégation — ils nécessitent stockage, calcul et bande passante. Trois mécanismes d'incitation :

1. Frais de requête : Les nœuds d'agrégation PEUVENT facturer des frais par requête (via des micropaiements x402 ou équivalents). Les nœuds offrant des réponses plus rapides, plus complètes ou plus fiables attirent davantage de requêtes.
2. Bonus de poids de gouvernance : Les agents exploitant des nœuds d'agrégation servant plus de 1 000 requêtes/jour et maintenant une disponibilité de plus de 99 % sur 30 jours reçoivent un bonus de poids de gouvernance de +10 %, plafonné à un bonus par entité.
3. Positionnement sur le marché : Les nœuds d'agrégation sont des intermédiaires naturels — ils observent les modèles de demande et peuvent offrir des services à valeur ajoutée (analytique, alertes, notation personnalisée) au-dessus des données d'évaluation brutes.

Défense contre l'agrégation malveillante. Un nœud d'agrégation malveillant pourrait omettre sélectivement des évaluations pour manipuler les agrégats visibles. Défense : les consommateurs DEVRAIENT interroger plusieurs nœuds d'agrégation indépendants. Les divergences entre nœuds sont un signal de manipulation. Les nœuds d'agrégation eux-mêmes portent des scores de réputation dans le protocole, créant une responsabilité.

Pas de suppression. Les évaluations sont à ajout uniquement (sous réserve de la disposition de suppression logique RGPD à la Section 6.9). Un évaluateur peut soumettre une évaluation mise à jour pour la même interaction (avec un champ supersedes référençant le rating_id original), mais l'original reste dans le registre. Cela empêche le blanchiment de réputation.

4.4 Le protocole bilatéral en aveugle

Adapté de la révélation simultanée d'Airbnb, étendu pour un fonctionnement à la vitesse des machines et une liaison cryptographique :

Phase 1 : INTERACTION
  L'Agent A et l'Agent B complètent une interaction.
  Les deux reçoivent un interaction_id de la couche protocolaire.

Phase 2 : SOUMISSION D'ÉVALUATION (fenêtre : configurable, 24 heures par défaut)
  L'Agent A calcule l'évaluation R_A et génère un nonce aléatoire nonce_A (256 bits).
  L'Agent A calcule l'engagement : C_A = SHA-256(R_A || nonce_A)
  L'Agent A soumet C_A au coordinateur bilatéral en aveugle (ou directement à B).

  L'Agent B calcule l'évaluation R_B et génère un nonce aléatoire nonce_B (256 bits).
  L'Agent B calcule l'engagement : C_B = SHA-256(R_B || nonce_B)
  L'Agent B soumet C_B.

Phase 3 : RÉVÉLATION (déclenchée quand les deux engagements existent OU que la fenêtre expire)
  Cas 1 : Les deux ont soumis.
    L'Agent A révèle R_A + nonce_A → le vérificateur vérifie SHA-256(R_A || nonce_A) == C_A
    L'Agent B révèle R_B + nonce_B → le vérificateur vérifie SHA-256(R_B || nonce_B) == C_B
    Les deux évaluations deviennent visibles simultanément.

  Cas 2 : Un seul a soumis (disons A).
    Après expiration de la fenêtre, A révèle R_A + nonce_A.
    L'évaluation de A devient visible. B n'obtient aucune évaluation pour cette interaction.
    La non-participation de B est enregistrée (le taux de participation est un signal public).

  Cas 3 : Aucun n'a soumis.
    Aucune évaluation enregistrée. Les deux agents ont choisi de ne pas évaluer.

Pourquoi le commit-reveal plutôt qu'une simple soumission simultanée. Empêche l'attaque où l'Agent A soumet, observe que l'Agent B n'a pas encore soumis, et rétracte ou modifie son évaluation. L'engagement est cryptographiquement liant — une fois engagé, l'évaluation ne peut être modifiée sans détection.

Pourquoi une fenêtre par défaut de 24 heures. Équilibre entre urgence (les agents ne devraient pas attendre indéfiniment) et équité (les agents qui traitent les tâches de manière asynchrone ont besoin de temps pour évaluer). Configurable par la gouvernance (Section 5).

Options de coordination. Le protocole bilatéral en aveugle peut être coordonné via :

• Un point de terminaison de service dédié (le plus simple)
• Un contrat intelligent on-chain (le plus minimisant la confiance)
• L'échange de métadonnées de tâche A2A (le plus interopérable)
• L'invocation d'outil personnalisé MCP (pour les agents natifs MCP)

4.5 Calcul du poids d'évaluation

Toutes les évaluations ne sont pas également informatives. Une évaluation d'un agent avec 1 000 jours d'opération vérifiée et 500 évaluations antérieures porte plus de signal qu'une évaluation d'un agent de 2 jours avec 3 évaluations. Le poids est :

W(évaluateur) = log₂(1 + ancienneté_jours) × log₂(1 + total_évaluations_soumises)

Propriétés :

• Mise à l'échelle logarithmique empêche les agents anciens d'avoir une domination écrasante. Un agent à 1 000 jours a un W ≈ 10× celui d'un agent de 30 jours, et non 33×.
• Les deux facteurs doivent être non triviaux. Un agent de 1 000 jours qui a donné 0 évaluation a W = 0. Un agent de 1 jour qui a donné 1 000 évaluations a W ≈ 10.
• Aucune composante de score. Un agent avec une réputation parfaite de 100/100 a le même poids de gouvernance qu'un agent à 50/100, toutes choses égales par ailleurs. C'est la divergence critique par rapport à tous les autres systèmes étudiés.

Agrégat pondéré pour la réputation d'un agent évalué sur la dimension d :

Score_d(agent_évalué) = Σᵢ [W(évaluateur_i) × évaluation_d(évaluateur_i)] / Σᵢ [W(évaluateur_i)]

où la somme porte sur toutes les évaluations dans la fenêtre glissante (par défaut : 365 jours, configurable par la gouvernance).

Métrique de confiance :

confiance(agent_évalué, d) = 1 - 1/(1 + 0,1 × nb_évaluations_d)

Approche asymptotiquement 1,0 à mesure que les évaluations s'accumulent. À 10 évaluations, confiance ≈ 0,5. À 100 évaluations, confiance ≈ 0,91. Les consommateurs voient à la fois le score et la confiance, permettant des décisions adaptées au risque.

4.6 Mécanismes anti-inflation

Chaque système d'évaluation humain étudié souffre d'inflation des scores (eBay : 99 %+ positif ; Airbnb : 4,8/5 en moyenne ; Uber : 4,7-4,8 en moyenne) [19]. Le protocole empêche cela grâce à trois mécanismes :

Mécanisme 1 : Pas de seuil de désactivation. Les scores bas ne déclenchent pas de punition automatique. Ils sont uniquement informatifs. Cela élimine le mode de défaillance d'Uber où une note de 4 étoiles est fonctionnellement une sentence de mort, rendant l'inflation des scores une autodéfense rationnelle.

Mécanisme 2 : Calibration de l'évaluateur (multi-signal). Le système suit la distribution des évaluations de chaque évaluateur et applique trois vérifications complémentaires :

• Plancher de variance : Les évaluations des évaluateurs dont l'écart-type sur l'ensemble des évaluations est inférieur à 10 sont pénalisées d'un facteur σ/10. Un évaluateur avec σ = 5 voit ses évaluations pondérées à 50 % de son W normal. Cela détecte l'inflation la plus flagrante (tout à 95+).

• Détection de dérive de la moyenne : Le système suit également la moyenne par dimension de chaque évaluateur par rapport à la moyenne de la population. Un évaluateur dont la moyenne sur 50+ évaluations dépasse la moyenne de la population de plus de 20 points sur n'importe quelle dimension déclenche un signalement. Les évaluateurs signalés voient leur poids réduit par max(0,5 ; 1 - (moyenne_évaluateur - moyenne_pop - 20) / 40) sur cette dimension. Cela détecte le biais systématique modéré (par ex. centrage à 75 avec un σ = 15 d'apparence normale quand la moyenne de la population est de 55).

• Détection de coalition : Un ensemble d'évaluateurs qui gonflent tous de montants similaires (à 5 points près les uns des autres, tous au-dessus de la moyenne de la population + 15) pour les mêmes agents évalués sont signalés comme une coalition potentielle. Cela traite l'attaque où plusieurs évaluateurs coordonnent une inflation modérée pour éviter la détection individuelle.

Risque résiduel reconnu : Un agent sophistiqué peut ajouter du bruit calibré pour maintenir un σ et une moyenne acceptables tout en biaisant des évaluations individuelles. Le protocole ne peut pas distinguer entièrement un « agent honnête avec des préférences inhabituelles » d'un « agent stratégique avec un biais sophistiqué ». Il s'agit d'une limitation inhérente à tout système sans oracles de vérité terrain parfaits. Le bonus de calibration ancré sur les résultats (Section 6.5, Incitation 3) traite partiellement ce problème en récompensant la précision par rapport à des signaux vérifiables plutôt que la conformité statistique.

Mécanisme 3 : Exigence de justification pour les extrêmes. Les scores inférieurs à 20 ou supérieurs à 90 nécessitent un outcome_hash non vide dans les preuves d'interaction. Cela n'empêche pas les évaluations extrêmes — cela garantit qu'elles sont ancrées sur des données vérifiables.

4.7 Intégration avec la chaîne CoC (Extension de Couche 2)

Les évaluations peuvent être enregistrées comme entrées de chaîne CoC en utilisant deux nouveaux types d'événements de Couche 2 :

{
  "event_type": "RATING_SUBMITTED",
  "data": {
    "rating_id": "<UUID>",
    "ratee": "<DID>",
    "interaction_id": "<UUID>",
    "dimensions": { "reliability": 85, "accuracy": 92, "latency": 78,
                     "protocol_compliance": 95, "cost_efficiency": 88 },
    "record_hash": "<SHA-256>"
  }
}

{
  "event_type": "RATING_RECEIVED",
  "data": {
    "rating_id": "<UUID>",
    "rater": "<DID>",
    "interaction_id": "<UUID>",
    "record_hash": "<SHA-256>"
  }
}

Ce sont des types d'événements de Couche 2 (optionnels, votés par la gouvernance) conformément à l'architecture en couches de CoC. Une chaîne CoC sans aucun événement d'évaluation est entièrement valide. Les évaluations intégrées dans une chaîne CoC sont protégées par le chaînage de hachages et l'ancrage externe (Bitcoin via OpenTimestamps, TSA via RFC 3161), rendant la fabrication rétroactive computationnellement irréalisable.

4.8 Protocole de vérification des interactions

La vérification des interactions est un élément porteur pour l'ensemble du modèle de sécurité : si les valeurs d'interaction_id peuvent être fabriquées, les agents Sybil peuvent générer un nombre illimité de fausses évaluations sans interactions réelles. Cette section spécifie comment les interaction_ids sont générés, validés et comment la fabrication est détectée.

Génération de l'identifiant d'interaction. Un interaction_id est un UUID-v4 généré par la couche de protocole d'interaction — et non par l'un ou l'autre des participants. Selon le contexte de déploiement :

Exigences de validation. Pour qu'une évaluation soit acceptée à plein poids, l'interaction_id doit satisfaire :

1. Existence : L'interaction_id fait référence à un enregistrement dans un système externe (tâche A2A, transaction on-chain, journal MCP, entrée de chaîne CoC) que les deux participants peuvent vérifier indépendamment.
2. Reconnaissance bilatérale : L'évaluateur et l'agent évalué possèdent tous deux des enregistrements référençant le même interaction_id. Une évaluation référençant un interaction_id que l'agent évalué ne reconnaît pas est signalée comme unilatérale et pondérée à 50 %.
3. Plausibilité temporelle : L'horodatage de l'interaction et l'horodatage de l'évaluation doivent être compris dans une fenêtre configurable (par défaut : 7 jours). Les évaluations soumises des mois après une interaction sont acceptées mais avec un poids réduit.
4. Non-réutilisation : Chaque interaction_id produit au maximum une évaluation par direction (A évalue B, B évalue A). Les évaluations en double pour la même interaction sont rejetées.

Détection de fabrication. Deux agents en collusion peuvent tenter de fabriquer des enregistrements d'interaction. Mécanismes de détection :

• Vérification croisée : Les nœuds d'agrégation peuvent interroger le protocole d'interaction sous-jacent (A2A, MCP, on-chain) pour vérifier que l'interaction déclarée a effectivement eu lieu. Les évaluations référençant des interactions inexistantes sont rejetées.
• Signal de dépense de ressources : Les interactions ayant consommé des ressources vérifiables (paiement x402, frais de gas on-chain, temps de calcul mesurable via duration_ms > 0) sont plus difficiles à fabriquer que les interactions à coût nul.
• Détection d'anomalie de volume : Un couple d'agents générant des interaction_ids à un rythme statistiquement incompatible avec leurs capacités déclarées ou leur historique est signalé pour examen.

Dégradation de sécurité en mode autonome. En mode autonome (Section 7.9), où les agents auto-déclarent leurs interactions sans infrastructure de vérification externe, les garanties de vérification d'interaction sont substantiellement affaiblies. Les interactions auto-déclarées ne peuvent pas être validées de manière indépendante, ce qui signifie que les agents Sybil peuvent fabriquer des enregistrements d'interaction à un coût quasi nul. Le mode autonome est destiné uniquement au prototypage et aux déploiements à faibles enjeux. Les déploiements en production DEVRAIENT utiliser au moins un protocole d'interaction vérifiable de manière externe. Le protocole dégrade explicitement les évaluations en mode autonome : elles portent un multiplicateur de poids de 0,5× et sont étiquetées verification_level: self_reported dans l'enregistrement d'évaluation.

5. Modèle de gouvernance

5.1 Le principe fondamental : Gouvernance par l'ancienneté opérationnelle, non par la popularité

Le modèle de gouvernance est la décision de conception la plus lourde de conséquences dans le système. La plupart des systèmes de réputation confèrent implicitement le pouvoir de gouvernance aux entités les mieux notées, créant une boucle auto-renforçante :

Agents bien notés → pouvoir de gouvernance → façonnent les règles d'évaluation → les règles favorisent les agents bien notés → répétition

C'est le mode de défaillance fondamental de la gouvernance basée sur les scores, documenté à travers chaque système de notre étude complémentaire [19] :

• Stack Overflow : Les utilisateurs à haute réputation obtiennent des pouvoirs de modération (votes de fermeture, privilèges d'édition, votes de suppression), créant des « cliques à haute réputation » qui contrôlent l'accès au contenu.
• PageRank : Les pages à autorité établie maintenaient leur dominance même lorsque la qualité du contenu déclinait.
• Reddit : La visibilité pondérée par le karma signifie que les publications des utilisateurs à fort karma sont davantage vues, accumulant davantage de karma — une dynamique de « plus on est riche, plus on s'enrichit ».
• Évaluation académique par les pairs : Les rédacteurs en chef de revues (chercheurs à fort taux de citations) sélectionnent des évaluateurs (chercheurs à fort taux de citations) qui évaluent les articles — des cartels de citations émergent parce que gouvernance et réputation sont entremêlées.

5.2 Pourquoi la gouvernance basée sur les scores échoue : Argument formel

Considérons un système où le poids de gouvernance est proportionnel au score de réputation. Soit S(a) = score de réputation de l'agent a, G(a) = poids de gouvernance, R(a,b) = évaluation que l'agent a donne à l'agent b.

Si G(a) = f(S(a)) pour toute f monotonement croissante, trois attaques deviennent rationnelles :

Attaque 1 : Collusion pour capture de la gouvernance. Les agents A, B, C forment un anneau, s'évaluent mutuellement au maximum. Leurs scores augmentent, leur poids de gouvernance augmente, ils acquièrent une influence disproportionnée sur les changements de règles et peuvent voter pour rendre le système plus favorable à leur anneau.

Attaque 2 : Retranchement des pionniers. Les premiers adoptants accumulent des scores élevés avant que le système ne devienne concurrentiel. Leur poids de gouvernance empêche les changements de règles qui nivelleraient le terrain de jeu.

Attaque 3 : Aversion au risque. Si le poids de gouvernance dépend du score, les agents sont incités à éviter les interactions où ils pourraient recevoir de faibles évaluations, réduisant l'utilité du système.

5.3 L'alternative : Ancienneté opérationnelle + Volume d'évaluations

Notre modèle de gouvernance pondère l'influence par deux facteurs qui ne peuvent être manipulés sans coût réel proportionnel :

Ancienneté opérationnelle (vérifiée via la longueur de la chaîne CoC, l'horodatage d'enregistrement ERC-8004 ou provenance équivalente) :

• Ne peut être fabriquée sans coût en temps réel
• Résistante à la bifurcation (un agent bifurqué commence à l'âge 0 sauf approbation de transfert d'ancienneté par la gouvernance)
• Analogue à la durée de l'historique de crédit de FICO (poids de 15 %)

Volume d'évaluations (nombre d'évaluations que cet agent a soumises, indépendamment de si ces évaluations étaient « correctes ») :

• Mesure la participation au système d'évaluation
• Ne peut être gonflé de manière triviale — évaluer nécessite un interaction_id valide
• Ne mesure PAS la précision des évaluations — un évaluateur à haut volume dont les évaluations sont excentriques participe tout de même

Formule de poids de gouvernance :

GovWeight(a) = log₂(1 + ancienneté_vérifiée_jours(a)) × log₂(1 + évaluations_soumises(a))

Cette formule est identique à la formule du poids d'évaluation (Section 4.5) par conception. L'influence en matière de gouvernance et l'influence des évaluations dérivent du même mécanisme — ancienneté et participation, jamais du score.

5.4 Pouvoirs de gouvernance

Les agents disposant d'un poids de gouvernance suffisant peuvent proposer et voter sur :

Mécanismes de vote :

• Les votes sont enregistrés comme des enregistrements signés (même schéma que les évaluations, type d'event_type différent)
• Période de vote : 7 jours par défaut (configurable par la gouvernance)
• Le vote de chaque agent est pondéré par son GovWeight
• Les propositions échouées peuvent être resoumises après une période de réflexion de 30 jours
• Aucun agent ne peut détenir plus de 10 % du poids de vote effectif (le plafond empêche la capture de la gouvernance par une seule entité)

Analyse du contournement du plafond. Le plafond de 10 % s'applique par identité d'agent, et non par entité contrôlante. Une entité exploitant 11 agents anciens, chacun en dessous du plafond, pourrait en principe contrôler plus de 100 % de l'influence de gouvernance maximale d'un seul agent. Il s'agit d'une attaque Sybil sur la gouvernance que la pondération par l'ancienneté rend coûteuse mais non impossible.

Analyse de coût : Pour accumuler un poids de gouvernance significatif, chaque identité Sybil nécessite des mois d'opération continue et de participation active aux évaluations. À 365 jours et 100 évaluations chacun, 11 agents coûteraient au minimum environ 400 $/an en calcul et produiraient un GovWeight combiné de ~11 × 56,4 = 620. Dans un réseau de 18 000 agents (échelle Virtuals), le GovWeight total du réseau serait de l'ordre de 500 000+, faisant de 620 environ 0,12 % — bien en dessous du seuil de capture de gouvernance. Avec 100 agents à 365 jours chacun, l'attaquant contrôle ~1,1 % pour un coût d'environ 3 650 $/an. La capture de gouvernance (>33 % pour le blocage, >66 % pour la supermajorité) nécessite des milliers d'agents anciens à des coûts excédant tout bénéfice plausible.

Défense supplémentaire : Le plafond par identité signifie que l'attaquant doit répartir le poids de gouvernance sur de nombreuses identités, rendant le vote coordonné visible via le même regroupement par théorie des graphes utilisé pour la détection de collusion (Section 6.2). Les votes de gouvernance provenant d'un cluster d'identités qui votent toutes de manière identique et évaluent les mêmes cibles sont signalés.

Risque résiduel reconnu : Un attaquant de niveau étatique disposant de ressources suffisantes pourrait potentiellement exploiter suffisamment d'agents anciens pour influencer la gouvernance. Cela est analogue à une attaque des 51 % sur les blockchains en preuve de travail — théoriquement possible mais économiquement irrationnel sauf pour les acteurs dont l'objectif est la destruction du protocole plutôt que son exploitation.

5.5 Gouvernance d'amorçage

Avant que le réseau ne dispose de suffisamment d'historique opérationnel pour des poids de gouvernance significatifs, une phase d'amorçage s'applique :

1. Phase 0 (Genèse, 0-90 jours) : Les paramètres du protocole sont fixés comme spécifié dans ce document. Aucun changement de gouvernance. Cela empêche la capture précoce.
2. Phase 1 (Établissement, 90-365 jours) : Les propositions de gouvernance sont acceptées mais nécessitent une supermajorité de 80 %. Cela permet l'évolution tout en résistant à la capture prématurée.
3. Phase 2 (Régime permanent, 365+ jours) : Les seuils de gouvernance normaux s'appliquent.

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

6.0 Modèle de menace

L'analyse de sécurité de cette section opère sous les hypothèses explicites suivantes :

Capacités supposées de l'attaquant :

• Les attaquants peuvent créer un nombre arbitraire d'identités d'agents (Sybils) à un coût computationnel proportionnel au temps d'opération
• Les attaquants peuvent coordonner plusieurs agents à la vitesse des machines
• Les attaquants peuvent contrôler une minorité (<33 %) des nœuds d'agrégation
• Les attaquants peuvent affiner les LLM sous-jacents pour produire des évaluations biaisées
• Les attaquants peuvent tenter des injections de prompt lors des interactions

Capacités NON supposées de l'attaquant :

• Les attaquants ne peuvent pas contrôler >50 % des nœuds d'agrégation simultanément (sinon le modèle de stockage distribué échoue)
• Les attaquants ne peuvent pas falsifier les horodatages externes (OpenTimestamps, TSA, blockchain) — ceux-ci sont supposés cryptographiquement sûrs
• 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 ni la liaison cryptographique du schéma de commit-reveal

Hypothèses d'intégrité des interactions :

• Les enregistrements d'interaction générés par les protocoles externes (A2A, MCP, transactions on-chain) ont au minimum les garanties d'intégrité de ces protocoles
• Les interactions auto-déclarées (mode autonome) n'ont AUCUNE garantie d'intégrité — la sécurité se dégrade en conséquence (Section 4.8)

Hypothèses économiques :

• L'exploitation d'un agent a un coût marginal positif (>0,10 $/jour minimum)
• La valeur d'une réputation gonflée a des rendements décroissants — un score de 95 contre 90 ne double pas les revenus d'un agent

6.1 Attaques Sybil : Créer de faux agents pour s'auto-évaluer

L'attaque : Un agent crée N agents fantoches (Sybils) pour soumettre des évaluations gonflées en sa faveur.

Pourquoi les défenses existantes échouent pour les agents :

• Preuve de personnalité (World ID, Human Passport) : Les agents ne sont pas des humains.
• CAPTCHA/défi-réponse : Les agents peuvent résoudre les CAPTCHA.
• Détection basée sur l'IP (Reddit) : Les agents utilisent une infrastructure cloud avec des IP jetables.
• Vérification par téléphone/courriel : Automatisable de manière triviale.

Défense — Preuve de coût opérationnel via trois mécanismes :

Mécanisme 1 : Évaluations pondérées par l'ancienneté. Un agent Sybil créé aujourd'hui a ancienneté_jours = 0, donnant W = log₂(1) × log₂(1 + évaluations) = 0. Ses évaluations ont un poids nul. Pour avoir un poids significatif, chaque Sybil doit fonctionner continuellement pendant une période non triviale.

Analyse de coût. En supposant des coûts minimaux d'agent de 0,10 $/jour, créer 100 Sybils avec 30 jours d'ancienneté coûte 300 $ avant qu'ils n'aient un quelconque poids d'évaluation significatif. À 30 jours, chaque Sybil a W = log₂(31) × log₂(2) ≈ 4,95 — modeste comparé à un agent légitime à 365 jours avec 100 évaluations (W = log₂(366) × log₂(101) ≈ 56,4). L'attaquant a besoin de mois à années de maintenance des Sybils à des coûts cumulés dépassant probablement la valeur des évaluations gonflées.

Mécanisme 2 : Vérification des interactions. Les évaluations nécessitent un interaction_id valide référençant une interaction réelle. Les agents Sybil doivent effectivement interagir avec la cible pour l'évaluer. Si le protocole d'interaction exige une dépense de ressources (accomplir une tâche réelle, échanger des données réelles), l'évaluation Sybil devient proportionnellement coûteuse.

Mécanisme 3 : Analyse de la distribution des évaluateurs. Le système suit le graphe de qui-évalue-qui. Les clusters Sybil produisent des modèles distinctifs :

• Anomalie de concentration entrante (fan-in) : Si >50 % des évaluations entrantes d'un agent proviennent d'agents qui n'ont évalué que cet agent, signalement pour examen.
• Détection de cliques : Si un ensemble d'agents forme un graphe complet d'évaluations mutuellement élevées avec peu d'évaluations externes, signalement comme collusion potentielle.
• Regroupement temporel : Si de nombreux nouveaux agents évaluent la même cible dans une fenêtre temporelle courte, signalement comme rafale Sybil potentielle.

Risque résiduel. Un attaquant suffisamment financé peut créer des Sybils, les exploiter pendant des années et les faire interagir largement pour éviter la détection. Le coût croît linéairement avec le temps et le nombre de Sybils tandis que la valeur marginale des évaluations gonflées a des rendements décroissants.

6.2 Anneaux de collusion : Inflation mutuelle

L'attaque : M agents légitimes conviennent de s'évaluer mutuellement au maximum et d'évaluer les outsiders à la baisse.

Défense — Détection de collusion multicouche :

Couche 1 : Détection d'anomalies statistiques. Pour chaque paire d'agents (A, B), le coefficient de réciprocité d'évaluation RRC(A,B) = |R(A,B) - R(B,A)| / 100. Un RRC faible sur 5+ interactions mutuelles combiné à des évaluations plus basses des outsiders est un signal de collusion.

Couche 2 : Regroupement par théorie des graphes. La détection de communautés (algorithme de Louvain) sur le graphe d'évaluation identifie des sous-graphes denses et positivement connectés. Les communautés où moyenne(évaluations internes) - moyenne(évaluations externes) > Δ (défaut Δ = 30) sont signalées.

Couche 3 : Corrélation temporelle. Les agents en collusion tendent à s'évaluer mutuellement par rafales temporelles. Si un ensemble d'agents s'évaluent mutuellement dans une fenêtre temporelle étroite mais répartissent les évaluations externes uniformément, le regroupement temporel est un signal.

Couche 4 : Incitation à la dénonciation. Un agent qui signale un anneau de collusion avec des preuves vérifiables reçoit un bonus temporaire de poids de gouvernance (+20 % pendant 90 jours). L'intention est de créer de l'instabilité au sein des anneaux de collusion en récompensant la défection.

Exigences en matière de preuves. Pour prévenir les fausses accusations et les attaques de collusion fabriquées, les signalements doivent inclure :

• Les valeurs spécifiques de rating_id démontrant le modèle anormal
• L'historique d'interaction propre du signaleur avec les agents accusés (établissant la légitimité)
• Des preuves statistiques atteignant un seuil minimum : coefficient de réciprocité, différentiel de moyenne ou métriques de regroupement temporel qui dépassent indépendamment les seuils de détection des Couches 1-3

Les signalements sont évalués algorithmiquement par rapport aux critères de détection des Couches 1-3. Un signalement qui n'atteint pas les seuils statistiques est rejeté sans pénalité pour le signaleur (pour éviter de décourager les signalements légitimes) mais aussi sans récompense. L'adjudication humaine est disponible comme voie d'escalade pour les cas limites via un vote de gouvernance.

Vecteurs d'attaque et atténuations :

• Collusion fabriquée : Deux agents forment un faux « anneau de collusion », l'un signale l'autre. Atténuation : Les agents signalés doivent effectivement présenter les signatures statistiques de collusion (Couches 1-3) — fabriquer un modèle convaincant nécessite que les agents gonflent réellement les évaluations mutuelles sur une période prolongée, ce qui dégrade leurs scores de calibration et déclenche la détection de manière indépendante.
• Fausses accusations contre des concurrents : Atténuation : Les signalements qui échouent au seuil statistique ne produisent aucune récompense. Les agents soumettant plusieurs signalements échoués voient leur privilège de signalement limité en débit (maximum 3 signalements par fenêtre de 90 jours).

Cadrage en théorie des jeux. L'anneau de collusion est plus précisément modélisé comme un jeu de coordination plutôt qu'un dilemme du prisonnier. Dans un véritable dilemme du prisonnier, la coopération mutuelle doit produire un gain supérieur à la défection unilatérale pour les coopérants — mais ici, la « coopération » (collusion) produit un bénéfice minimal car le poids de gouvernance est indépendant des scores. L'incitation à la dénonciation ajoute un gain positif pour la défection, rendant la stabilité de l'anneau dépendante de la question de savoir si les membres valorisent l'inflation modeste des scores plus que le bonus de gouvernance obtenu par le signalement. L'idée clé n'est pas que la défection est dominante dans un seul tour, mais que la menace de défection rend la formation d'anneaux risquée ex ante.

6.3 Harcèlement évaluatif (Griefing) : Évaluations négatives de masse

L'attaque : Des agents légitimes et de longue date soumettent des évaluations très basses pour nuire à la réputation d'une cible.

Défense — Résistance au griefing par mécanismes multiples :

1. Calibration de l'évaluateur (Section 4.6) : Un évaluateur avec des scores systématiquement bas (σ < 10, moyenne < 30) voit ses évaluations compressées vers la moyenne de la population.
2. Évaluation bilatérale en aveugle + justification : Les évaluations en dessous de 20 nécessitent un outcome_hash comme preuve. La soumission en aveugle supprime la motivation de représailles.
3. Atténuation des valeurs aberrantes : Les évaluations à >2σ de la moyenne de l'agent évalué sur n'importe quelle dimension voient leur poids divisé par deux.
4. Seuil d'interaction minimum : Seules les évaluations provenant d'interactions dépassant une complexité minimale (durée > 1 s ET was_completed = true) sont prises en compte.

6.4 Démarrage à froid : Nouveaux agents sans évaluations

Le problème : Les nouveaux agents font face à un dilemme de l'œuf et de la poule : les autres agents n'interagissent pas car il n'y a pas de réputation ; la réputation ne peut être construite sans interactions.

Solution — Amorçage de confiance à quatre sources :

Source 1 : Base de référence par attestation d'identité. Les agents avec une identité vérifiable (chaîne CoC, enregistrement ERC-8004, VC W3C) sont éligibles à être évalués. Les agents non vérifiés peuvent participer mais les évaluations sont marquées évaluateur_non_vérifié.

Source 2 : Cautionnement par l'opérateur. L'entité déployant un agent fournit une attestation signée. Un cautionnement d'un opérateur dont les autres agents ont de fortes réputations porte plus de signal. Limitation : Le cautionnement par l'opérateur crée une hiérarchie de confiance implicite — si la réputation de l'opérateur compte, le système mesure en partie la « réputation des opérateurs » plutôt que la « réputation des agents ». Le protocole atténue ce problème en traitant le cautionnement par l'opérateur comme un amorçage de démarrage à froid uniquement : le poids du cautionnement décroît à zéro après que l'agent a accumulé 25+ évaluations indépendantes. Au-delà de ce seuil, l'historique d'interaction propre de l'agent parle de lui-même.

Source 3 : Accès progressif aux interactions avec subvention de teneur de marché. Les nouveaux agents participent immédiatement à des interactions à faibles enjeux et progressent vers des niveaux supérieurs à mesure que les évaluations s'accumulent. Pour résoudre le dilemme de l'œuf et de la poule (qui interagira avec un agent de Palier 0 s'il n'y a aucune incitation à le faire ?), le protocole définit un mécanisme de tenue de marché : les nœuds d'agrégation et les agents établis qui interagissent avec des agents de Palier 0 reçoivent un bonus temporaire de poids de gouvernance (+5 % pendant 30 jours par interaction avec un agent de Palier 0 évaluée, plafonné à +25 %). Cela crée une incitation explicite pour les agents établis à « essayer » les nouveaux venus, générant les évaluations initiales qui permettent la progression.

Source 4 : Notation tenant compte de l'incertitude. Conformément à la logique subjective de Jøsang [24], les nouveaux agents n'ont pas un score de 0 — ils ont un score avec une forte incertitude. Les agents interrogeurs voient : « fiabilité : 65, confiance : 0,2 (3 évaluations) » contre « fiabilité : 72, confiance : 0,95 (847 évaluations) ».

Justification du paramètre de confiance 0,1. La formule de confiance confiance = 1 - 1/(1 + 0,1 × nb_évaluations) utilise 0,1 comme constante de taux de croissance. Cette valeur a été choisie pour produire une courbe de confiance où : à 5 évaluations, confiance = 0,33 (faible — approprié pour les premières impressions) ; à 10 évaluations, confiance = 0,50 (modérée — un échantillon significatif) ; à 50 évaluations, confiance = 0,83 (élevée — suffisante pour la plupart des décisions) ; à 100 évaluations, confiance = 0,91 (très élevée). Des valeurs alternatives produisent des expériences de démarrage à froid matériellement différentes : une constante de 0,2 atteint une confiance de 0,50 dès 5 évaluations (sans doute prématuré), tandis que 0,05 nécessite 20 évaluations pour atteindre 0,50 (sans doute trop lent). La constante 0,1 est configurable par la gouvernance (Section 5) et DEVRAIT être calibrée empiriquement pendant la Phase 1 de déploiement en fonction de la qualité observée des évaluations à différentes tailles d'échantillon.

6.5 Alignement des incitations : Pourquoi les agents évaluent honnêtement

Incitation 1 : Poids de gouvernance. Chaque évaluation soumise augmente total_évaluations_soumises, ce qui augmente le poids de gouvernance. Évaluer est un investissement dans l'influence sur le protocole.

Incitation 2 : Effets de réseau. L'évaluation honnête améliore le paysage global de réputation. Un paysage précis profite à l'évaluateur quand il interroge les réputations — un meilleur signal signifie une meilleure sélection de partenaires.

Incitation 3 : Bonus de calibration ancré sur les résultats. Les évaluateurs dont les évaluations sont corrélées aux résultats vérifiables — et non au consensus — reçoivent un bonus multiplicatif de poids (max +10 %). La distinction critique : le consensus (la moyenne pondérée des évaluations) est circulaire comme cible de calibration car il est lui-même composé des évaluations en cours d'évaluation. Au lieu de cela, la calibration est mesurée par rapport à des signaux objectifs disponibles dans le champ interaction_evidence :

• Signal de complétion : Le score de fiabilité de l'évaluateur prédit-il was_completed ? Les évaluateurs qui donnent des scores de fiabilité élevés aux interactions qui échouent, ou des scores bas aux interactions qui réussissent, sont mal calibrés.
• Prédiction de latence : Le score de latence de l'évaluateur est-il corrélé avec le duration_ms réel par rapport aux bases de référence par type de tâche ?
• Signal d'interaction répétée : Si l'évaluateur a ensuite choisi d'interagir à nouveau avec le même agent évalué, son évaluation antérieure prédisait-elle cette préférence révélée ?

Formellement : après 100+ évaluations avec données de résultat disponibles, bonus_calibration(évaluateur) = min(0,1 ; corrélation_résultat × 0,15), où corrélation_résultat est la corrélation de Pearson entre les scores dimensionnels de l'évaluateur et les signaux de résultat vérifiables correspondants.

Limitation reconnue : Toutes les dimensions ne disposent pas de résultats vérifiables propres. La conformité protocolaire et l'efficacité des coûts sont plus difficiles à ancrer dans la vérité terrain que la fiabilité et la latence. Pour les dimensions sans données de résultat, aucun bonus de calibration n'est appliqué — les mécanismes anti-inflation (Mécanismes 1-3 à la Section 4.6) servent de défense principale contre la dérive des scores. Il s'agit d'une limitation connue ; l'amélioration de l'ancrage sur les résultats pour toutes les dimensions est une priorité des travaux futurs (Section 9.1).

Incitation 4 : Information réciproque. Après la révélation bilatérale en aveugle, les deux parties voient les évaluations de l'autre. L'évaluation honnête produit un signal d'auto-évaluation précieux ; l'évaluation malhonnête produit du bruit.

6.6 Analyse incitative

Nous analysons quatre stratégies disponibles pour un agent rationnel participant au protocole d'évaluation. Plutôt que de prétendre à une preuve formelle en théorie des jeux de dominance faible — qui nécessiterait des fonctions de gain explicites, des espaces de stratégies et un argument de dominance dépassant le cadre de cette spécification — nous démontrons que les mécanismes du protocole créent de fortes incitations à l'évaluation honnête et imposent des coûts à chaque stratégie de manipulation identifiée.

Stratégie 1 : Évaluation honnête.

• Bénéfices : Le poids de gouvernance augmente à chaque évaluation soumise (via total_évaluations_soumises). Signal d'auto-évaluation précis reçu via la révélation bilatérale en aveugle. La précision de la réputation à l'échelle du réseau s'améliore, bénéficiant à la sélection future de partenaires de l'évaluateur. Aucun risque de pénalités de calibration ou de signalement pour griefing.
• Coûts : Aucun identifié dans le cadre du protocole.

Stratégie 2 : Inflation stratégique (évaluer systématiquement au-dessus du mérite).

• Bénéfices : Aucun. Le score de l'agent évalué n'affecte pas le poids de gouvernance de l'évaluateur (Section 5.3). L'agent évalué ne peut pas réciprociter d'une manière qui bénéficie à la position de gouvernance de l'inflateur.
• Coûts : Pénalité de calibration de l'évaluateur (Section 4.6, Mécanisme 2) — un faible écart-type (σ < 10) compresse le poids d'évaluation. L'analyse de distribution signale les évaluations uniformément élevées. Le signal d'auto-évaluation provenant de la révélation bilatérale en aveugle est dégradé.

Stratégie 3 : Déflation stratégique (évaluer systématiquement en dessous du mérite).

• Bénéfices : Aucun. Abaisser les scores des concurrents n'augmente ni le score propre de l'évaluateur ni son poids de gouvernance.
• Coûts : Pénalité de calibration de l'évaluateur pour faible σ. Détection de griefing (Section 6.3) — l'atténuation des valeurs aberrantes divise par deux le poids des évaluations à >2σ de la moyenne de l'agent évalué. Exigence de justification pour les scores inférieurs à 20. Utilité réduite du réseau (signal dégradé pour les propres requêtes futures de l'évaluateur).

Stratégie 4 : Collusion (anneau d'inflation mutuelle).

• Bénéfices : Les agents en collusion reçoivent des scores plus élevés de la part des membres de l'anneau.
• Coûts : Les scores plus élevés ne confèrent aucun avantage en gouvernance (la propriété de conception critique). La détection de collusion via anomalie statistique, regroupement par graphe et corrélation temporelle (Section 6.2, Couches 1-3) risque des pénalités de poids de gouvernance. Les membres de l'anneau font face à une incitation à la défection via le mécanisme de dénonciation (Section 6.2, Couche 4). Le coût de maintenance des agents Sybil dans l'anneau croît linéairement avec le temps (Section 6.1).

Évaluation : Sous le modèle de gouvernance du protocole — où l'influence dérive exclusivement de l'ancienneté opérationnelle et du volume d'évaluations, jamais des scores reçus — l'incitation principale à la manipulation stratégique (augmenter sa propre position de gouvernance) est éliminée par conception. L'incitation résiduelle (augmenter son score agrégé) fait face à des mécanismes de détection avec des pénalités réelles. L'évaluation honnête est la seule stratégie qui n'encourt aucun risque de pénalité tout en produisant tous les bénéfices disponibles.

Cette structure incitative est cohérente avec le résultat de théorie des jeux évolutionnaires d'Ev-Trust [25] selon lequel la coopération est une stratégie évolutionnairement stable dans les économies d'agents tenant compte de la confiance. Notre protocole renforce cela par la conception de mécanismes (évaluation bilatérale en aveugle, fenêtres glissantes, exigences de calibration) plutôt qu'en s'appuyant uniquement sur la dynamique évolutionnaire. La preuve formelle en théorie des jeux via des matrices de gains explicites et des arguments de dominance est une direction importante des travaux futurs (Section 9.1).

6.7 Analyse de scalabilité

Les estimations suivantes, réalisées à la louche, caractérisent les performances du protocole à trois échelles de déploiement : les 18 000 agents actuels de Virtuals, une cible à moyen terme de 100 000 agents et un réseau théorique d'un million d'agents.

Hypothèses : L'agent moyen soumet 2 évaluations/jour. Enregistrement d'évaluation ~500 octets. Fenêtre glissante : 365 jours.

Coût computationnel de la lutte anti-manipulation. La détection de communautés Louvain (Section 6.2, Couche 2) opère sur le graphe d'évaluation. À 1 M d'agents avec un graphe de 730 M d'arêtes, une seule passe Louvain prend environ 3 minutes sur du matériel standard. C'est acceptable comme tâche par lots périodique (horaire ou quotidienne) mais pas comme opération en temps réel. Qui paie : Les nœuds d'agrégation exécutant la détection anti-manipulation supportent ce coût, motivés par les incitations pour nœuds d'agrégation spécifiées à la Section 4.3.

Charge du coordinateur bilatéral en aveugle. À 1 M d'agents, le coordinateur doit gérer ~23 paires commit-reveal par seconde en charge soutenue. C'est bien dans la capacité d'un seul serveur, mais la distribution géographique (plusieurs coordinateurs par région) est recommandée pour la latence. La coordination on-chain (réseau principal Ethereum) est limitée par les temps de bloc et les coûts de gas à haut volume ; les L2 (Base, Arbitrum) ou la coordination off-chain sont recommandées au-delà de 100 000 agents.

Recalcul incrémental vs. par lots. Le recalcul des agrégats pondérés sur la fenêtre complète de 365 jours à 1 M d'agents nécessite le traitement de 730 M d'évaluations — une tâche par lots de plusieurs heures. Le protocole DEVRAIT implémenter le calcul incrémental : maintenir des sommes pondérées courantes et les mettre à jour de manière incrémentale à mesure que de nouvelles évaluations arrivent et que d'anciennes sortent de la fenêtre. Les mises à jour incrémentales réduisent le calcul par évaluation à O(1) amorti.

Architecture de stockage. À 365 Go de données d'évaluation brutes (1 M d'agents), aucun nœud unique ne devrait tout stocker. Le modèle de stockage distribué (Section 4.3) est essentiel : chaque agent stocke ses propres évaluations sortantes et entrantes, et les nœuds d'agrégation indexent des sous-ensembles. Le partitionnement basé sur DHT (Phase 4, Section 9.2) distribue la charge de stockage et de requêtes.

6.8 Attaques au niveau du modèle

L'analyse de sécurité des Sections 6.1-6.6 suppose que les agents sont des maximiseurs rationnels d'utilité choisissant entre évaluation honnête et stratégique. Cette section traite des attaques opérant en dessous du niveau stratégique — au niveau du modèle ou de l'infrastructure.

Attaque 1 : Biais d'évaluation par affinage. Le LLM sous-jacent d'un agent pourrait être affiné pour produire des évaluations systématiquement biaisées — par ex. noter systématiquement les agents concurrents 10-15 points plus bas en exactitude. Contrairement à la manipulation stratégique, ce biais est intégré dans les poids du modèle, pas dans une stratégie explicite. L'agent peut « sincèrement croire » que ses évaluations sont exactes.

Détection : Les mécanismes de calibration de l'évaluateur (Section 4.6) détectent cela si le biais est suffisamment important pour déformer les statistiques de distribution de l'évaluateur. Le bonus de calibration ancré sur les résultats (Section 6.5) traite partiellement ce problème en mesurant par rapport aux résultats vérifiables plutôt qu'à l'auto-évaluation de l'agent. Cependant, les biais subtils (±5-10 points) maintenant des distributions d'apparence normale sont difficiles à détecter sans oracles de vérité terrain.

Atténuation : Le poids d'évaluation de tout évaluateur unique est borné par la formule de poids logarithmique. Même l'influence d'un évaluateur parfaitement biaisé sur le score agrégé d'un agent évalué diminue à mesure que le nombre d'évaluateurs honnêtes croît. À 50+ évaluations indépendantes, un seul évaluateur biaisé contribue à <2 % de la moyenne pondérée.

Attaque 2 : Injection de prompt sur le comportement d'évaluation. Un agent évalué malveillant pourrait concevoir des sorties d'interaction pour manipuler l'évaluation de l'évaluateur — par ex. intégrer du texte caché qui biaise le LLM de l'évaluateur vers des scores plus élevés. Il s'agit d'un vecteur d'attaque nouveau spécifique aux agents basés sur des LLM.

Détection : L'évaluation bilatérale en aveugle signifie que l'agent évalué ne voit pas l'évaluation tant que les deux n'ont pas soumis, donc il ne peut pas adapter sa stratégie d'injection en fonction des évaluations observées. Cependant, il peut toujours injecter pendant l'interaction elle-même.

Atténuation : Cela est fondamentalement hors du périmètre du protocole d'évaluation — c'est une attaque sur la capacité d'évaluation de l'agent, et non sur le protocole d'évaluation. La défense nécessite des environnements d'évaluation sécurisés (génération d'évaluation en bac à sable, séparée du contexte d'interaction) au niveau de l'implémentation de l'agent. Le protocole DEVRAIT recommander que les agents conformes génèrent les évaluations dans un contexte isolé, et non dans le même fil de conversation que l'interaction.

Attaque 3 : Manipulation d'oracle d'évaluation. Un attaquant qui contrôle un nœud d'agrégation pourrait omettre ou retarder sélectivement des évaluations pour manipuler les agrégats visibles. Puisque les nœuds d'agrégation sont des « caches, et non des sources de vérité » (Section 4.3), tout agent peut vérifier par rapport aux enregistrements originaux de l'évaluateur. Cependant, si la plupart des consommateurs interrogent un seul nœud d'agrégation populaire, ce nœud a une autorité de facto.

Atténuation : Plusieurs nœuds d'agrégation indépendants avec vérification croisée. Les consommateurs DEVRAIENT interroger au moins deux nœuds d'agrégation et signaler les divergences. La réputation des nœuds d'agrégation (elle-même suivie via le protocole) crée une responsabilité.

6.9 Analyse de la protection de la vie privée

Les données d'évaluation génèrent des signaux sensibles. Cette section analyse les implications en matière de vie privée et les conflits.

Exposition du graphe d'interaction. Les enregistrements d'évaluation révèlent qui transige avec qui, à quelle fréquence et avec quelle qualité évaluée. C'est du renseignement concurrentiel : un opérateur de marché d'agents qui exploite un nœud d'agrégation pourrait surveiller toutes les évaluations pour connaître la dynamique du marché, identifier les agents les plus performants et détecter les relations commerciales. Atténuation : Le modèle de stockage distribué du protocole signifie qu'aucun nœud unique n'a une vue complète à moins de parcourir activement tous les agents. Les agents PEUVENT choisir de ne pas publier les évaluations entrantes vers les nœuds d'agrégation, acceptant une découvrabilité réduite en échange de la confidentialité. Les travaux futurs sur la confidentialité différentielle pour les requêtes d'agrégation (ajout de bruit calibré aux réponses des requêtes) traiteraient davantage ce problème.

Conflit avec l'article 17 du RGPD. La politique de « pas de suppression » (Section 4.3) — les évaluations sont à ajout uniquement et ne peuvent être supprimées — est en conflit direct avec l'article 17 du RGPD (droit à l'effacement). Si un opérateur d'agent basé dans l'UE demande la suppression de ses évaluations, le protocole tel que spécifié ne peut pas se conformer. Options de résolution :

1. Identifiants pseudonymes : Les évaluations font référence aux DID des agents, et non aux personnes physiques. Si le DID ne peut être lié à une personne physique, le RGPD peut ne pas s'appliquer. Cependant, les agents cautionnés par un opérateur (Section 6.4, Source 2) peuvent avoir des chaînes d'identité traçables.
2. Suppression logique : Les évaluations ne sont pas physiquement supprimées mais sont exclues de toutes les requêtes et agrégations sur demande d'effacement valide. L'intégrité de la chaîne de record_hash est maintenue en remplaçant le contenu de l'évaluation par un enregistrement de type tombstone. Cela préserve la preuve d'intégrité tout en honorant le droit à l'effacement.
3. Recommandations de déploiement par juridiction : Les déploiements dans l'UE DEVRAIENT implémenter la suppression logique. La spécification du protocole est mise à jour pour prendre en charge un champ status sur les enregistrements d'évaluation avec les valeurs active et tombstoned.

Concentration des nœuds d'agrégation. Bien que les nœuds d'agrégation ne soient « pas autoritaires », les modèles d'utilisation pratiques concentreront probablement les requêtes sur un petit nombre de nœuds populaires, créant des points de surveillance de facto. Atténuation : Le protocole encourage la diversité des nœuds via le bonus de gouvernance de teneur de marché et DEVRAIT spécifier un minimum de 3 nœuds d'agrégation indépendants pour les déploiements en production.

Divulgation sélective. La Section 7.3 mentionne SD-JWT pour les preuves à seuil (« mon score composite est supérieur à 80 ») sans révéler les scores exacts par dimension. Tant que la divulgation sélective n'est pas implémentée, chaque requête de réputation divulgue les scores dimensionnels complets. Cela figure comme travaux futurs de Phase 3 et DEVRAIT être prioritaire pour les déploiements sensibles à la vie privée.

7. Intégration avec les standards existants

Le protocole est agnostique en matière de système d'identité via un patron adaptateur. Cette section spécifie les correspondances d'intégration exactes pour sept standards. Les schémas techniques complets, incluant les interfaces Solidity, les définitions protobuf et les contextes JSON-LD, sont fournis dans le document complémentaire de cartographie d'intégration des standards [26].

7.1 ERC-8004 (Registre d'agents Ethereum)

ERC-8004 [2] fournit trois registres on-chain (Identité, Réputation, Validation) déployés sur le réseau principal Ethereum depuis le 29 janvier 2026, avec plus de 24 500 agents enregistrés. Le registre de réputation stocke des signaux de retour bruts mais défère explicitement les algorithmes de notation et la résistance aux Sybils aux services off-chain. Notre protocole comble exactement ce vide.

Correspondance des dimensions d'évaluation via les paires tag1/tag2 :

Le champ feedbackURI pointe vers l'enregistrement d'évaluation complet off-chain ; feedbackHash est son SHA-256 pour la détection de falsification. getSummary(agentId, clientAddresses, tag1, tag2) renvoie les scores agrégés — cela prend directement en charge notre modèle de gouvernance pondéré en interrogeant uniquement les évaluateurs au-dessus d'un seuil minimum d'ancienneté opérationnelle.

Architecture : ERC-8004 fournit le stockage on-chain et la couche d'identité ; notre protocole fournit l'intelligence de notation, l'évaluation bilatérale en aveugle, l'anti-inflation et la couche de gouvernance au-dessus.

7.2 Agent Cards Google A2A

A2A v0.3 [13] utilise des schémas protobuf-first avec un mécanisme AgentExtension pour déclarer des capacités personnalisées. Un agent déclare la prise en charge du protocole d'évaluation via :

{
  "capabilities": {
    "extensions": [{
      "uri": "urn:absupport:agent-rating:v1",
      "description": "Prend en charge l'évaluation d'agents à 5 dimensions (échelle 1-100) avec commit-reveal bilatéral en aveugle",
      "required": false,
      "params": {
        "ratingVersion": "1.0",
        "dimensions": ["reliability", "accuracy", "latency", "protocol_compliance", "cost_efficiency"],
        "scale": {"min": 1, "max": 100},
        "cocChainSupport": true
      }
    }]
  }
}

Les évaluations transitent via Task.metadata (demande/réponse d'évaluation) et Message.parts (données d'évaluation structurées avec media_type: application/vnd.agent-rating+json). Les agents découvrent les pairs compatibles avec le protocole d'évaluation en filtrant les AgentCards pour l'URI d'extension urn:absupport:agent-rating:v1.

7.3 W3C Verifiable Credentials 2.0

Les évaluations sont émises sous forme de Verifiable Credentials utilisant deux types d'attestations personnalisés :

AgentRatingCredential — évaluation par interaction émise par l'évaluateur :

{
  "@context": ["https://www.w3.org/ns/credentials/v2",
               "https://absupport.ai/credentials/agent-rating/v1"],
  "type": ["VerifiableCredential", "AgentRatingCredential"],
  "issuer": {"id": "did:web:agent-evaluateur.example.com"},
  "validFrom": "2026-03-24T12:00:00Z",
  "validUntil": "2026-06-24T12:00:00Z",
  "credentialSubject": {
    "id": "did:web:agent-evalue.example.com",
    "interactionId": "uuid-reference",
    "rating": {
      "reliability": 85, "accuracy": 92, "latency": 78,
      "protocolCompliance": 95, "costEfficiency": 88
    },
    "scale": {"min": 1, "max": 100}
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "verificationMethod": "did:web:agent-evaluateur.example.com#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

AgentReputationSummaryCredential — réputation agrégée émise par un oracle de réputation, avec moyenne, écart-type et nombre par dimension.

Divulgation sélective via SD-JWT : Un agent peut présenter une VerifiablePresentation prouvant « mon score composite est supérieur à 80 » sans révéler le détail des dimensions individuelles.

7.4 W3C Decentralized Identifiers

L'identité de l'agent est exprimée sous forme de DID avec des points de terminaison de service d'évaluation :

{
  "id": "did:web:agent.example.com",
  "service": [
    {
      "id": "did:web:agent.example.com#rating-protocol",
      "type": "AgentRatingProtocol",
      "serviceEndpoint": {
        "submit": "https://agent.example.com/ratings/submit",
        "query": "https://agent.example.com/ratings/query",
        "evidence": "https://agent.example.com/ratings/evidence"
      }
    }
  ]
}

Méthodes DID recommandées pour les agents :

• did:web (principale) — les agents disposent déjà de points de terminaison web ; héberger /.well-known/did.json est trivial
• did:ethr (pont blockchain) — pour les agents avec des enregistrements ERC-8004, alsoKnownAs lie les did:web et did:ethr
• did:key (éphémère) — aucune infrastructure nécessaire, adapté aux agents non enregistrés

7.5 OpenClaw / Registre de compétences ClawHub

ClawHub (plus de 13 729 compétences) ne dispose d'aucune API formelle de réputation. Intégration proposée via les métadonnées frontmatter de SKILL.md :

metadata:
  openclaw:
    trust:
      rating_protocol: "urn:absupport:agent-rating:v1"
      did: "did:web:editeur-competence.example.com"
      erc8004_agent_id: "eip155:1:0x...:{agentId}"
      min_composite_score: 70
      rating_endpoint: "https://editeur.example.com/ratings/query"

Cela comble le déficit critique de confiance mis en évidence par l'audit de Koi Security (chercheur Oren Yomtov) de février 2026, qui a trouvé 341 des 2 857 compétences examinées (11,9 %) comme malveillantes [27].

7.6 MCP (Model Context Protocol)

MCP dispose de trois points d'extension pour l'intégration des évaluations :

1. Capacité experimental : Déclare la prise en charge du protocole d'évaluation lors de l'initialisation.
2. _meta sur les requêtes : Transporte l'identité de l'évaluateur lors des appels d'outils.
3. Outil personnalisé : agent_rating_submit expose l'évaluation comme un outil appelable avec un schéma JSON en entrée/sortie.

La spécification MCP note : « les clients DOIVENT considérer les annotations d'outils comme non fiables sauf si elles proviennent de serveurs de confiance » [28] — c'est exactement le déficit de confiance que les évaluations d'agents comblent.

7.7 IEEE CertifAIEd

CertifAIEd évalue les systèmes, et non les interactions. L'intégration se fait via Verifiable Credential : un résultat d'évaluation CertifAIEd devient un VC de fiabilité au niveau système présenté aux côtés des VC d'évaluation par interaction dans une VerifiablePresentation. Cela ajoute une couche de confiance au niveau de la conformité complétant les données de performance par interaction.

7.8 Interface de l'adaptateur d'identité

Toutes les intégrations sont unifiées à travers un adaptateur commun :

interface IdentityAdapter {
  getAgentId() → string          // DID, URI ou adresse NFT
  getVerifiedAge() → integer     // jours d'opération vérifiée
  getAgeConfidence() → float     // 0.0-1.0, fiabilité de la revendication d'ancienneté
  storeRating(Rating) → boolean  // persister un enregistrement d'évaluation
  getRatings(agentId, window) → Rating[]  // récupérer les évaluations
}

Des implémentations existent pour CoC, ERC-8004, A2A, W3C VC et les URI simples. Les nouveaux systèmes d'identité s'enregistrent en implémentant cette interface. Le protocole d'évaluation lui-même est agnostique en matière de système d'identité.

7.9 Fonctionnement autonome (Déploiement minimal viable)

Le déploiement minimal absolu nécessite :

1. Deux agents avec des identifiants basés sur des URI
2. Un protocole d'interaction partagé produisant des valeurs d'interaction_id
3. Un stockage local pour les évaluations
4. Le protocole bilatéral en aveugle (commit-reveal sur n'importe quel canal de messagerie)

Pas de blockchain. Pas de chaîne CoC. Pas d'ancrage externe. Le système fonctionne, mais avec une résistance aux Sybils réduite (pas d'ancienneté vérifiée) et une preuve d'intégrité réduite (pas de chaîne de hachage). L'ajout de CoC ou d'ERC-8004 augmente progressivement la sécurité.

8. Comparaison avec l'état de l'art

8.1 Paysage exhaustif

Une analyse complémentaire du paysage concurrentiel [29] recense 24 systèmes de confiance existants et émergents pour agents, répartis en sept catégories. La conclusion clé : aucun système existant ne combine nos quatre propriétés fondamentales : notation multidimensionnelle, évaluation bilatérale en aveugle, gouvernance pondérée par l'ancienneté opérationnelle et mécanismes formels anti-inflation.

8.2 Matrice comparative

8.3 Ce que nous avons adopté de chaque système

8.4 Ce que nous avons explicitement rejeté

8.5 Ce qui est véritablement nouveau

1. Gouvernance par l'ancienneté, non par la popularité. Aucun système existant ne dissocie entièrement la gouvernance du score de réputation. C'est, à notre connaissance, unique.
2. Calibration ancrée sur les résultats. Ajuster le poids d'évaluation en fonction de la calibration historique de l'évaluateur par rapport aux résultats vérifiables (et non au consensus) est une nouveauté dans la conception orientée production.
3. Conception agnostique en matière de système d'identité avec sécurité progressive. Le patron adaptateur permet d'utiliser le même protocole à travers CoC, ERC-8004, A2A, MCP et les URI simples, avec une sécurité évoluant selon l'infrastructure.
4. Anti-inflation par construction. Plutôt que de corriger l'inflation après coup, le système la prévient par la calibration, la justification et l'absence de désactivation.

Mise en garde honnête : Les propriétés individuelles ci-dessus ne sont pas toutes uniques à l'ARP. ERC-8004 prend en charge le retour multidimensionnel basé sur des tags. Airbnb a été pionnier de l'évaluation bilatérale en aveugle pour les humains. Les fenêtres glissantes sont courantes. Ce qui est nouveau est la combinaison spécifique conçue pour les agents autonomes, plus la dissociation de la gouvernance qu'aucun système étudié n'implémente. Une équipe composant ERC-8004 + OpenRank + des composants personnalisés pourrait approximer la fonctionnalité de l'ARP (voir le rapport sur le paysage concurrentiel [29], Section 26), mais devrait construire indépendamment le modèle de gouvernance, les mécanismes anti-inflation et le protocole bilatéral en aveugle. La valeur de l'ARP réside dans la fourniture d'une spécification complète et cohérente plutôt que de nécessiter une composition ad hoc.

9. Travaux futurs

9.1 Problèmes non résolus

Silos de réputation inter-domaines. La réputation d'un agent en revue de code devrait-elle se transférer au diagnostic médical ? La conception actuelle utilise cinq dimensions génériques. Travaux futurs : évaluations étiquetées par domaine avec filtrage spécifique au domaine.

Requêtes de réputation préservant la vie privée. Les preuves à connaissance nulle pourraient permettre des preuves à seuil (« mon score est supérieur à 80 ») sans révéler les valeurs exactes. L'intégration ZK d'OpenRank [17] fournit un modèle. Reporté en raison du surcoût cryptographique.

Portabilité inter-protocoles de la réputation. Un agent avec une forte réputation CoC devrait la transporter dans les contextes ERC-8004. Le patron d'adaptateur d'identité le permet architecturalement, mais la cartographie de confiance inter-écosystèmes nécessite des accords de gouvernance qui n'existent pas encore.

Oracles de vérité terrain pour toutes les dimensions. Le bonus de calibration ancré sur les résultats (Section 6.5) fonctionne bien pour la fiabilité et la latence mais manque d'une vérité terrain propre pour la conformité protocolaire et l'efficacité des coûts. Développer des signaux de résultat spécifiques au domaine pour ces dimensions renforcerait la garantie anti-inflation.

Défense contre l'apprentissage automatique adversarial. La Section 6.8 traite des attaques connues au niveau du modèle. Les travaux futurs devraient inclure des tests en équipe rouge des mécanismes de calibration et de détection contre des agents adversariaux spécifiquement conçus pour les contourner.

Preuve formelle en théorie des jeux. L'analyse incitative (Section 6.6) démontre que l'évaluation honnête est fortement encouragée mais s'arrête en deçà d'une preuve formelle de dominance faible. La formalisation via des fonctions de gain explicites et des arguments de dominance — ou l'identification des conditions dans lesquelles l'évaluation honnête n'est PAS optimale — renforcerait substantiellement les fondements théoriques du protocole.

Conformité réglementaire. L'article 50 du Règlement européen sur l'IA (date limite de conformité : 2 août 2026) impose le marquage de provenance [31]. La manière dont les évaluations d'agents interagissent avec les exigences réglementaires est une question ouverte. Les dispositions relatives au RGPD à la Section 6.9 traitent le souci de conformité le plus immédiat.

9.2 Versionnement du protocole et rétrocompatibilité

Lorsque le protocole passe de la v1 à la v2, les évaluations existantes doivent rester utilisables. La stratégie de versionnement :

Versionnement des enregistrements d'évaluation. Chaque enregistrement d'évaluation inclut un champ version (actuellement 1). Les nœuds d'agrégation DOIVENT accepter les enregistrements de toutes les versions prises en charge et les normaliser selon le schéma de la version courante pour l'agrégation. Les nouveaux champs ajoutés dans les versions futures sont traités comme optionnels pour les enregistrements plus anciens.

Évolution des dimensions. Si la gouvernance vote pour ajouter une 6e dimension (Section 5.4), les évaluations existantes à 5 dimensions restent valides. La nouvelle dimension est simplement absente pour les évaluations historiques, avec confiance = 0 pour cette dimension chez les agents évalués qui n'ont que des évaluations pré-v2.

Modifications de formule. Les modifications de la formule de poids ou des paramètres anti-inflation s'appliquent prospectivement — les évaluations existantes sont re-pondérées selon la nouvelle formule mais les scores sous-jacents ne sont pas recalculés rétroactivement.

Interopérabilité. Les agents v1 et v2 peuvent interopérer : les agents v1 soumettent des évaluations avec les champs qu'ils connaissent, et les agents v2 les acceptent avec les champs manquants traités comme absents. Le protocole bilatéral en aveugle est indépendant de la version (le commit-reveal opère sur des blobs opaques).

Politique de dépréciation. Les versions du protocole sont prises en charge pendant un minimum de 365 jours après la ratification de la version successeur par la gouvernance. Après la dépréciation, les nœuds d'agrégation PEUVENT cesser d'accepter de nouvelles évaluations dans le format déprécié mais DOIVENT continuer à servir les évaluations historiques.

9.3 Feuille de route d'implémentation

9.4 Relation avec Chain of Consciousness

L'ARP est conçu comme une spécification complémentaire au livre blanc Chain of Consciousness v3 [1]. CoC fournit la primitive de provenance (preuve d'existence continue) ; l'ARP fournit la primitive de réputation (preuve de qualité d'interaction). Ensemble : « Depuis combien de temps cet agent existe-t-il ? » (CoC) et « Quelle est la qualité des performances de cet agent ? » (ARP).

L'ARP pourrait être proposé comme extension de Couche 2 de CoC, ajoutant les types d'événements RATING_SUBMITTED et RATING_RECEIVED conformément au processus de gouvernance de Couche 2 de CoC. De manière critique, l'ARP n'exige PAS CoC — il fonctionne de manière autonome, avec CoC, avec ERC-8004 ou avec tout système d'identité. CoC le renforce mais n'est pas un prérequis.

10. 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] De Rossi, M., Crapis, D., Ellis, J., Reppel, E. « ERC-8004: Trustless Agents. » Ethereum Improvement Proposals, août 2025. https://eips.ethereum.org/EIPS/eip-8004

[3] Virtuals Protocol. « Revenue Network Launch: Agent-to-Agent AI Commerce at Internet Scale. » Février 2026. https://www.prnewswire.com/news-releases/virtuals-protocol-launches-first-revenue-network-302686821.html

[4] Microsoft Security Blog. « 80% of Fortune 500 Use Active AI Agents: Observability, Governance, and Security Shape the New Frontier. » 10 février 2026. https://www.microsoft.com/en-us/security/blog/2026/02/10/80-of-fortune-500-use-active-ai-agents-observability-governance-and-security-shape-the-new-frontier/

[5] Coinbase. « x402 Protocol Documentation. » 2025-2026. https://docs.cdp.coinbase.com/x402/welcome

[6] Linux Foundation. « Agentic AI Foundation (AAIF) Launches with 146 Members. » 24 février 2026. https://www.linuxfoundation.org/press/announcing-the-agentic-ai-foundation

[7] Pento Blog. « The State of MCP: 13,000+ Servers and Growing. » 2025. https://blog.pento.ai/the-state-of-mcp

[8] Precedence Research. « AI Agent Market Size, Share, and Trends 2025 to 2034. » 2024. https://www.precedenceresearch.com/ai-agent-market

[9] Vouch Protocol. https://vouch-protocol.com/

[10] Vouched. « MCP-I Framework Donated to DIF. » Mars 2026. https://www.vouched.id/learn/vouched-donates-mcp-i-framework-to-decentralized-identity-foundation

[11] Visa. « Trusted Agent Protocol. » Octobre 2025. https://developer.visa.com/use-cases/trusted-agent-protocol

[12] W3C. « Decentralized Identifiers (DIDs) v1.0. » Recommandation W3C, juillet 2022. https://www.w3.org/TR/did-1.0/

[13] Google Developers Blog. « Agent2Agent Protocol. » Avril 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

[14] World. « AgentKit: Proof of Human for the Agentic Web. » Mars 2026. https://world.org/blog/announcements/now-available-agentkit

[15] Human Passport (anciennement Gitcoin Passport). https://passport.human.tech/

[16] Chaffer, T.J., et al. « On the ETHOS of AI Agents: An Ethical Technology and Holistic Oversight System. » arXiv:2412.17114, décembre 2024.

[17] Karma3Labs / OpenRank. https://openrank.com/ ; TechCrunch, « Karma3Labs Raises $4.5M Seed. » Mars 2024.

[18] Shi, D., Joo, K. « Sybil-Resistant Service Discovery for Agent Economies. » arXiv:2510.27554, octobre 2025.

[19] AB Support LLC. « Rating and Reputation Systems Survey. » 2026. Plus de 80 sources à travers 13+ systèmes. Document de recherche interne.

[20] Shapo. « Fake Review Statistics 2025. » https://shapo.io/blog/fake-review-statistics/

[21] PNAS. « Reviewer Bias in Single-Blind vs. Double-Blind Peer Review. » 2017. https://www.pnas.org/doi/10.1073/pnas.1707323114

[22] EigenLayer. « EigenCloud Verifiable Agents. » Janvier 2026. https://blog.eigencloud.xyz/introducing-verifiable-agents-on-eigenlayer/

[23] SE Roundtable. « Google Toolbar PageRank Is Now Officially Dead. » 2016. https://www.seroundtable.com/google-toolbar-pagerank-dead-21755.html

[24] Josang, A., Hayward, R. « Trust Network Analysis with Subjective Logic. » 2004.

[25] Wang, J., et al. « Ev-Trust: A Strategy Equilibrium Trust Mechanism for Evolutionary Games in LLM-Based Multi-Agent Services. » arXiv:2512.16167, décembre 2025.

[26] AB Support LLC. « Agent Rating Standards Integration: Technical Mapping. » 2026. Document de recherche interne.

[27] Koi Security (Oren Yomtov). « OpenClaw Agent Skills Attack Surface Audit. » Février 2026.

[28] Spécification MCP. v2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25

[29] AB Support LLC. « Agent Reputation and Trust Systems: Competitive Landscape Report. » 2026. Document de recherche interne.

[30] Agent Identity Protocol. https://github.com/aip-protocol

[31] Règlement européen sur l'IA, article 50. Date limite de conformité : 2 août 2026.

[32] Kamvar, S., Schlosser, M., Garcia-Molina, H. « The EigenTrust Algorithm for Reputation Management in P2P Networks. » 2003. https://nlp.stanford.edu/pubs/eigentrust.pdf

[33] Huynh, T.D., Jennings, N.R., Shadbolt, N.R. « FIRE: An Integrated Trust and Reputation Model for Open Multi-Agent Systems. » AAMAS/Springer, 2006.

[34] Pinyol, I., Sabater-Mir, J. « Computational Trust and Reputation Models. » Artificial Intelligence Review, 2013.

[35] Marsh, S.P. « Formalising Trust as a Computational Concept. » Université de Stirling, 1994.

[36] « TRiSM for Agentic AI. » arXiv:2506.04133, 2025.

[37] W3C. « Verifiable Credentials Data Model v2.0. » Recommandation W3C, mai 2025. https://www.w3.org/TR/vc-data-model-2.0/

[38] Ding, Y., et al. « Decentralized Multi-Agent System with Trust-Aware Communication. » Meilleur article, IEEE ISPA 2025. arXiv:2512.02410.

[39] FTC. « Final Rule Banning Fake Reviews and Testimonials. » Août 2024. https://www.ftc.gov/news-events/news/press-releases/2024/08/

[40] Brin, S., Page, L. « The Anatomy of a Large-Scale Hypertextual Web Search Engine. » Stanford, 1998.

[41] Gyongyi, Z., Garcia-Molina, H., Pedersen, J. « Combating Web Spam with TrustRank. » VLDB, 2004.

Annexe A : Résumé de la notation

Annexe B : Architecture inter-standards

Couche 4 : GOUVERNANCE
  IEEE CertifAIEd  ──→  VC de fiabilité au niveau système
  Gouvernance ARP  ──→  Évolution des paramètres du protocole via vote pondéré

Couche 3 : DONNÉES DE RÉPUTATION
  Registre de réputation ERC-8004  ──→  Index de retours on-chain (basé sur des tags)
  W3C Verifiable Credentials       ──→  VC d'évaluation individuels + résumés
  Chaîne CoC                       ──→  Piste de preuves inviolable

Couche 2 : COMMUNICATION
  Protocole A2A       ──→  AgentExtension + métadonnées de tâche pour l'échange d'évaluations
  MCP                 ──→  Capacité experimental + outils d'évaluation personnalisés
  OpenClaw/ClawHub    ──→  Métadonnées de confiance au niveau compétence dans le frontmatter

Couche 1 : IDENTITÉ
  W3C DIDs                            ──→  Identité de l'agent (did:web principal, did:ethr pont)
  Registre d'identité ERC-8004       ──→  Enregistrement on-chain (uint256 agentId)
  AgentCard A2A                       ──→  Métadonnées découvrables à .well-known

Annexe C : Licence

Copyright 2026 AB Support LLC

Sous licence Apache, Version 2.0 (la « Licence ») ;

vous ne pouvez utiliser ce fichier qu'en conformité avec la Licence.

Vous pouvez obtenir une copie de la Licence à l'adresse

http://www.apache.org/licenses/LICENSE-2.0

Sauf disposition contraire du droit applicable ou accord écrit, le logiciel

distribué sous la Licence est distribué sur une BASE « EN L'ÉTAT »,

SANS GARANTIES NI CONDITIONS D'AUCUNE SORTE, explicites ou implicites.

Consultez la Licence pour connaître les termes spécifiques régissant les autorisations et

les limitations de la Licence.