Introduction à la norme ERC-8004 pour des agents d’IA sans confiance

Nous vivons à l’ère de l’intelligence artificielle, cela ne fait aucun doute pour personne. On peut débattre sur le fait que les chiffres soient gonflés, que les attentes soient irréalistes, ou même sur le fait que nous soyons en train de construire quelque chose de bon ou non avec ces technologies, mais on ne peut pas nier que quelque chose de grand se passe. L’un des types d’applications IA les plus puissants à l’heure actuelle est celui des agents IA, dont j’ai déjà parlé et montré comment les programmer dans un autre tutoriel sur ce site. Avec eux, vous pouvez exécuter des tâches hautement spécialisées grâce à un entraînement préalable, à des outils personnalisés et même à des données personnalisées (avec le RAG – Retrieval-Augmented Generation).

Une voie qui se dessine pour les Agents IA est celle de l’autonomie complète. D’accord, vous pouvez ordonner à un agent d’organiser une réunion pour vous avec une personne afin de la interviewer pour un poste, par exemple. Mais un agent autonome va au-delà de cela : à partir d’une description de poste, il pourrait chercher des candidats, trier les CV, programmer des entretiens et même les réaliser et choisir le meilleur candidat. Il pourrait même avoir besoin de l’aide d’autres agents pour accomplir tout cela, comme un agent spécialisé dans les entretiens techniques, un autre dans le filtrage de CV, etc. Ou bien trouver ou créer un autre agent pour occuper le poste.

Un autre jour, Vitalik Buterin, le créateur d’Ethereum, a déclaré lors d’un événement que la blockchain est l’écosystème naturel pour que les Agents IA interagissent, précisément parce qu’elle dispose d’une économie et de relations programmables. Après tout, lorsque des agents interagissent entre eux, ils auront besoin de réaliser des transactions, et nous savons que les billets physiques, les cartes de crédit ou même les comptes bancaires ne sont pas des options pratiques et sûres pour que les agents les utilisent, n’est-ce pas ? Vous confieriez le numéro de votre carte + le code de sécurité à OpenClaw ou à un autre agent pour gérer vos paiements ? Et même si vous faisiez confiance, l’usage non contrôlé agent x agent attirerait sûrement l’attention des systèmes antifraude et les coûts par transaction seraient très élevés avec cette solution.

La solution à ce problème passe par les crypto-monnaies. Étant donné que les protocoles DeFi sont programmable et ne nécessitent pas de KYC (une autre barrière pour les agents autonomes), il devient bien plus simple de proposer des interfaces financières conviviales pour que les AI Agents puissent effectuer des transactions entre eux et un véritable écosystème de possibilités sûres, auditées et pratiques pour rendre ce futur “agentique” possible.

Mais la grande question demeure: comment un agent va-t-il s’assurer qu’il peut payer le service d’un autre agent en toute sécurité ? Qu’il va réellement exécuter le service avec qualité ? Dans le monde réel, lorsque nous contractons un service, nous recherchons des recommandations, des systèmes d’évaluation et d’autres mécanismes fragmentés. L’idée de l/ERC-8004 est justement d’utiliser la blockchain pour créer cette couche de confiance A2A (Agent à Agent). En résumé, l’ERC-8004, développée en partenariat par Ethereum, Google, Coinbase et MetaMask, définit une norme EVM pour l’enregistrement, la réputation et la validation d’agents IA dit “trustless” (sans intermédiaire centralisé qui accorde la confiance aux agents), dans le meilleur esprit du web3 même.

Dans cet article et dans les prochains, nous explorerons un peu l’ERC-8004 pour comprendre comment elle propose de résoudre les problèmes évoqués ci-dessus. Pour une meilleure compréhension de cette série, il est utile que vous soyez déjà familiarisé avec l’ERC-721, l’ERC-20, IPFS et les Agents IA, sujets que j’ai abordés dans d’autres tutoriels.

Si vous préférez, vous pouvez regarder la vidéo ci-dessous plutôt que de lire.

La ERC-8004 repose sur trois piliers, à savoir :

– Enregistrement d’identité
– Enregistrement de réputation
– Enregistrement de validation

Ensemble, les trois enregistrements forment une couche de confiance sans besoin d’une figure centralisatrice telle qu’une banque ou un auditeur, avec de multiples bénéfices de sécurité qui seront évoqués plus loin.

Enregistrement d’Identité

Comprenez par “enregistrement” un contrat intelligent qui fonctionne comme une collection d’un ou de plusieurs agents uniques, comme un catalogue. Chaque registre doit être créé sur la blockchain en utilisant le format des collections NFT : ERC-721, tandis que les agents eux-mêmes constituent les NFTs de cette collection. Cela garantit que les agents ont des propriétaires, qu’ils sont uniques et qu’ils peuvent être transférés, tout en bénéficiant du support de tout l’écosystème existant pour les NFT, comme les portefeuilles et les places de marché.

Ci-dessous, je détaillerai les points principaux, en laissant de côté certains éléments optionnels. Comme il s’agit encore d’une EIP (proposition) et non d’une ERC finale, de nombreuses choses peuvent changer et il n’est pas utile de s’attacher à des détails optionnels.

Métadonnées

Les métadonnées des agents sont obligatoires (en suivant l’extension ERC721URIStorage) et doivent pointer vers un fichier externe (généralement IPFS lorsque hors chaîne) ou une chaîne base64 (lorsqu’en chaîne), ainsi qu’une fonction setAgentURI (ou équivalent) pour modifier cette information (discutable). Le standard pour eux est défini dans la propre ERC et reproduit ci-dessous, en se rappelant que comme elle est en draft à la date où j’écris cet article, cela peut changer.

{
  "type": "https://eips.ethereum.org/EIPS/eip-8004#registration-v1",
  "name": "myAgentName",
  "description": "A natural language description of the Agent, which MAY include what it does, how it works, pricing, and interaction methods",
  "image": "https://example.com/agentimage.png",
  "services": [
   {
      "name": "web",
      "endpoint": "https://web.agentxyz.com/"
    },
    {
      "name": "A2A",
      "endpoint": "https://agent.example/.well-known/agent-card.json",
      "version": "0.3.0"
    },
    {
      "name": "MCP",
      "endpoint": "https://mcp.agent.eth/",
      "version": "2025-06-18"
    },
    {
      "name": "OASF",
      "endpoint": "ipfs://{cid}",
      "version": "0.8", // https://github.com/agntcy/oasf/tree/v0.8.0
      "skills": [], // OPTIONAL
      "domains": [] // OPTIONAL
    },
    {
      "name": "ENS",
      "endpoint": "vitalik.eth",
      "version": "v1"
    },
    {
      "name": "DID",
      "endpoint": "did:method:foobar",
      "version": "v1"
    },
    {
      "name": "email",
      "endpoint": "[email protected]"
    }
  ],
  "x402Support": false,
  "active": true,
  "registrations": [
    {
      "agentId": 22,
      "agentRegistry": "{namespace}:{chainId}:{identityRegistry}" // e.g. eip155:1:0x742...
    }
  ],
  "supportedTrust": [
    "reputation",
    "crypto-economic",
    "tee-attestation"
  ]
}

Si vous voyez ce bloc, vous remarquerez les éléments suivants dans ces métadonnées :

– type, name, description et image sont des propriétés qui existaient déjà dans l’ERC-721, il suffit de les remplir comme d’habitude ;
– services : la liste des services que cet agent peut offrir. Notez que chaque type de service possède des caractéristiques propres, qui ont du sens dans ce contexte et qu’il n’est pas nécessaire d’expliquer ici ;
– x402Support : soutien au protocole de paiement HTTP-native créé par Coinbase, quelque chose de complémentaire à l’ERC8004 ;
– registrations : ici figure l’agentId (tokenId) et le agentRegistry (format détaillé ci-dessous) ;
– supportedTrust : nous en parlerons plus loin.

Le format du champ agentRegistry est le suivant :

L’intention est que le namespace représente la famille du Chain ID, et que, pour les blockchains EVM, cela soit défini par l’EIP-155. Ensuite vient le Chain ID du réseau et, enfin, l’adresse de la collection NFT sur la blockchain. Par exemple : eip155:1:0x742 pour un registre EVM, la blockchain ETH et l’adresse de la collection NFT 0x742. Pour identifier un agent, on utilise ce agentRegistry en combinaison avec agentId, qui correspond tout simplement au tokenId de la NFT.

Le portefeuille de l’agent est, par défaut, le même que celui du propriétaire. Il existe des propositions pour des fonctions de gestion de cette information.

Mint

Pour mintier de nouveaux agents dans votre registre, trois variations pour une nouvelle fonction register ont été proposées, en recevant toujours le agentId minté en retour, et la plus importante est celle ci-dessous, qui reçoit l’URI des métadonnées :

function register(string agentURI) external returns (uint256 agentId)

Deux événements doivent être émis lorsque cette fonction est appelée :

– Transfer, standard ERC-721 ;
– Registered, nouveau, comme ci-dessous

event Registered(uint256 indexed agentId, string agentURI, address indexed owner)

Et ainsi nous obtenons la spécification minimale complète pour l’enregistrement d’identité des agents sur la blockchain, conformément au standard ERC-8004. Ci-dessous, un exemple d’implémentation, en utilisant comme base l’ERC721 d’OpenZeppelin :

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.34;
 
// OpenZeppelin imports
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC721/IERC721.sol";
 
contract IdentityRegistry is ERC721URIStorage, Ownable {
    uint256 private _nextId;
    mapping(uint256 => bool) private _active;
 
    event Registered(
        uint256 indexed agentId,
        string agentURI,
        address indexed owner
    );
 
    constructor()
        ERC721("ERC8004 Agent Identity", "AGENT")
        Ownable(msg.sender)
    {}
 
    function register(
        string calldata agentURI
    ) external onlyOwner returns (uint256 agentId) {
        agentId = _nextId++;
 
        _safeMint(msg.sender, agentId);
        _setTokenURI(agentId, agentURI);
 
        _active[agentId] = true;
 
        emit Registered(agentId, agentURI, msg.sender);
    }
 
    function resolve(
        uint256 agentId
    )
        external
        view
        returns (address owner, string memory metadataURI, bool active)
    {
        require(_ownerOf(agentId) != address(0), "Agent does not exist");
 
        return (ownerOf(agentId), tokenURI(agentId), _active[agentId]);
    }
 
    function deactivate(uint256 agentId) external onlyOwner {
        _active[agentId] = false;
    }
 
    function exists(uint256 agentId) external view returns (bool) {
        return _ownerOf(agentId) != address(0);
    }
 
    function approve(address, uint256) public pure override(ERC721, IERC721) {
        revert("Soulbound: approvals disabled");
    }
 
    function setApprovalForAll(
        address,
        bool
    ) public pure override(ERC721, IERC721) {
        revert("Soulbound: approvals disabled");
    }
 
    function transferFrom(
        address from,
        address to,
        uint256 tokenId
    ) public override(ERC721, IERC721) {
        revert("Soulbound: transfers disabled");
    }
 
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId,
        bytes memory data
    ) public override(ERC721, IERC721) {
        revert("Soulbound: transfers disabled");
    }
}

Notez que j’ai inclus un contrôle sur l’état actif de l’agent, quelque chose d’au-delà de la spécification mais implicite dans le texte. Il en va de même pour la fonction resolve, qui sert à faciliter les flux d’obtention de données dans les dapps. J’ai aussi supposé que le propriétaire des NFTs mintés via register est toujours le même que celui de la collection et je n’ai pas mis en œuvre le mécanisme pour changer agentWallet ; ces NFTs seront considérés comme des soulbound tokens (intransferables), d’où les overrides et les reversions dans les fonctions finales.