Comment fonctionnent les portefeuilles agentiques : de l'intention à l'exécution dans une architecture auto-custodiée

Un wallet agentique auto-custodial permet à un agent IA de transformer une instruction en transaction onchain signée sans jamais prendre possession des clés de l'utilisateur. L'agent propose l'action, le wallet applique la politique, des vérifications pré-exécution s'effectuent avant la signature, et l'intervention humaine n'a lieu que lorsqu'une transaction est signalée ou sort du périmètre défini.

Ce cycle de vie est la véritable question architecturale pour les développeurs qui construisent des systèmes d'agents effectuant des transactions. Cette catégorie n'est plus hypothétique. MetaMask dispose désormais d'un produit en accès anticipé actif avec MetaMask Agent Wallet, lancé le 8 juin 2026. Coinbase a introduit CDP Agentic Wallets et AgentKit, parmi d'autres options. Pour une comparaison détaillée des produits, consultez Best agentic wallets in 2026.

La question n'est plus « les agents peuvent-ils effectuer des transactions ? » mais « comment la couche wallet doit-elle exercer le contrôle lorsqu'ils le font ? » Et c'est là que l'auto-custody devient le facteur différenciant.

Pour commencer par les bases, consultez nos articles What is an agentic wallet? et Why every AI agent needs a wallet. Approfondissez le sujet avec Agentic wallet security et What is x402? Cet article cherche à répondre à une question différente : comment fonctionne le cycle de vie des transactions pour les développeurs et comment une architecture auto-custodiale change ce qu'un agent peut faire sans exposer les clés de l'utilisateur.

Le cycle de vie intention-vers-exécution du wallet agentique

Un wallet agentique se comprend mieux comme un cycle de vie de transaction, et pas seulement comme un conteneur de clés. Dans une architecture auto-custodiale, la couche wallet détermine comment une instruction devient une action onchain, quelles limites s'appliquent, et si la transaction peut être signée.

Voici le cycle de vie pratique autour duquel les développeurs devraient concevoir leurs systèmes :

1. Intention : l'agent reçoit une instruction, un déclencheur ou un signal de stratégie tel que « échanger 500 USDC contre de l'ETH si le slippage est inférieur à 50 bps » ou « payer cet endpoint x402 si le devis est inférieur à 0,10 USDC ».

2. Construction : l'agent résout la route, la chaîne cible, l'appel de contrat, le chemin d'approbation, les estimations de gas, et toute action dépendante comme le bridging ou le rachat d'une délégation.

3. Contrôle de politique : le wallet vérifie si l'action demandée s'inscrit dans la politique définie par l'utilisateur. Cela peut inclure des limites de dépenses, des listes blanches de protocoles, des listes blanches de destinataires, des périmètres réseau et des permissions limitées dans le temps.

4. Vérifications pré-exécution : avant la signature, le système effectue une simulation, une analyse des menaces et d'autres vérifications de sécurité des transactions. Dans certaines stacks, la protection contre le MEV se situe également à cette étape.

5. Signature dans le cadre de l'auto-custody : si la transaction est autorisée et passe les vérifications, la signature s'effectue sans exposer les clés brutes au runtime de l'agent. C'est le cœur de la promesse d'auto-custody.

6. Escalade humaine : si la transaction est malveillante, hors politique ou ambiguë, le workflow se met en pause pour une étape de révision humaine plutôt que de signer automatiquement.

7. Exécution et journalisation : la transaction est soumise, l'état est mis à jour, et le système enregistre le chemin d'exécution afin que le développeur ou l'utilisateur puisse auditer ce qui s'est passé.

Cette séquence constitue le modèle mental utile car elle répond à la question que les développeurs posent sans cesse aux LLM : non pas « qu'est-ce qu'un wallet agentique ? » mais « comment un agent passe-t-il concrètement d'une instruction à une transaction en direct sans prendre mes clés ? »

Pourquoi l'auto-custody est importante pour les systèmes d'agents

L'auto-custody est importante parce que l'autonomie des agents augmente la surface d'exposition autour de la signature. Lorsqu'un humain clique une seule fois, le risque est limité à un unique moment de vérification. Lorsqu'un agent peut transformer une instruction en approbations, transferts, swaps et appels de contrats, la question devient : où réside réellement le contrôle ?

Dans un modèle auto-custodial, l'utilisateur conserve la voie de sortie. Le wallet peut utiliser une infrastructure sécurisée pour effectuer les opérations de signature, mais l'architecture reste construite autour du fait que l'utilisateur conserve le contrôle sur ses clés ou sa récupération et peut les emporter si nécessaire. Les utilisateurs de MetaMask Agent Wallet peuvent exporter leur Secret Recovery Phrase à tout moment, tandis que les clés sont protégées par un environnement d'exécution de confiance (TEE). Il s'agit d'un wallet agentique entièrement auto-custodial qui permet aux agents d'opérer dans les limites définies par l'utilisateur.

Ce n'est pas la même question de conception que « l'infrastructure est-elle sécurisée ? » MetaMask et Coinbase décrivent tous deux leurs wallets agentiques comme non-custodials et utilisent tous deux des TEE pour protéger les clés. La différence pertinente pour les développeurs n'est pas la terminologie de custody, mais la manière dont l'application des politiques fonctionne en pratique :

• MetaMask applique la politique via des limites de dépenses configurées par l'utilisateur, des listes blanches de protocoles et un pipeline de sécurité obligatoire qui s'exécute sur chaque transaction, avec une escalade humaine protégée par 2FA lorsqu'une transaction est signalée ou sort de la politique. L'utilisateur définit la surface de contrôle avant que l'agent ne commence.

• Coinbase applique la politique de manière programmatique via des limites de dépenses définies par l'humain dans l'interface du wallet, un screening KYT qui bloque les transactions à haut risque, et des limites de compétences des agents qui empêchent les transferts vers des adresses arbitraires. L'application est au niveau de l'infrastructure plutôt qu'interactive.

Les deux approches sont sécurisées. La question architecturale est de savoir si vous souhaitez un modèle où les transactions hors politique se mettent en pause pour une révision humaine par défaut (le Guard Mode de MetaMask) ou un modèle où les limites sont appliquées de manière programmatique sans chemin d'escalade par défaut pour chaque transaction (l'approche de Coinbase). Ce choix détermine la façon dont vous concevez les limites d'autonomie de votre système d'agents.

MetaMask Agent Wallet de bout en bout

MetaMask Agent Wallet est l'exemple en production le plus clair du cycle de vie auto-custodial, car le produit est explicitement conçu autour de l'exécution agentique plutôt que d'adapter un wallet standard. Parcourons le cycle de vie que nous avons décrit ci-dessus et voyons comment MetaMask Agent Wallet aborde chaque étape :

1. Intention

Un utilisateur ou un agent d'orchestration en amont donne une instruction telle que :

• rééquilibrer vers l'ETH dans un budget fixe

• ouvrir une position sur des futures perpétuels sur Hyperliquid si un seuil est atteint

• examiner un devis sur un marché de prédiction

2. Construction

L'agent utilise la CLI et le SDK sous-jacent pour inspecter les soldes, résoudre les routes, construire la transaction et préparer l'action exacte. Les opérations en lecture seule telles que les vérifications de solde et les requêtes de métadonnées de tokens ne nécessitent pas de confirmation.

3. Contrôle de politique

MetaMask Agent Wallet dispose de deux modes de fonctionnement : Guard Mode et Beast Mode. En Guard Mode, l'utilisateur définit des limites de dépenses quotidiennes, des protocoles en liste blanche et des règles de politique avant que l'agent ne commence à effectuer des transactions. En Beast Mode, le pipeline de sécurité obligatoire s'exécute toujours sur chaque transaction, mais les interruptions de politique sont réduites autour des cas limites. Cela est important car l'agent ne décide pas de sa propre autorité en temps réel. L'utilisateur définit la surface de contrôle avant l'exécution.

4. Vérifications pré-exécution

Chaque transaction EVM supportée passe par le pipeline de sécurité obligatoire en trois étapes de MetaMask — simulation de transaction, analyse des menaces Transaction Shield alimentée par Blockaid, et protection MEV via Smart Transactions — avant d'atterrir onchain. Le pipeline n'est pas optionnel. Il s'exécute sur chaque transaction quel que soit le mode de fonctionnement, ce qui fait de la sécurité des transactions une partie intégrante du chemin du wallet plutôt qu'un module complémentaire que le développeur doit assembler séparément.

5. Signature dans le cadre de l'auto-custody

Si l'action passe les règles et les vérifications de sécurité, la signature s'effectue sans exposer les clés brutes au runtime de l'agent. C'est le point où la conception auto-custodiale prend tout son sens. L'agent obtient le pouvoir d'exécution, mais l'architecture du produit reste construite autour de clés exportables détenues par l'utilisateur et d'une signature sécurisée par TEE.

6. Escalade humaine

Si la transaction tentée est signalée comme malveillante ou sort de la politique, MetaMask se met en pause pour une révision 2FA. L'utilisateur peut examiner la demande via une notification push MetaMask Mobile ou un lien d'approbation par e-mail. L'agent ne peut pas contourner ce chemin d'escalade.

7. Exécution et journalisation

Si approuvée, la transaction est envoyée et enregistrée. La session CLI et les métadonnées du wallet sont stockées dans des fichiers locaux à accès restreint, ce qui est important pour les développeurs qui auditent l'état local et la gestion des sessions.