Pourquoi chaque agent IA a besoin d'un wallet

Un agent peut produire une recommandation sans jamais toucher à l'argent. L'exécution, c'est une autre affaire. Dès qu'un agent paie pour des données, achète de la puissance de calcul, rééquilibre une position ou règle une transaction onchain, il a besoin d'un endroit pour détenir de la valeur, autoriser son mouvement et imposer des limites avant que les fonds ne bougent. Cet endroit, c'est un wallet — et c'est l'une des raisons pour lesquelles MetaMask Agent Wallet et AgentKit de Coinbase ont tous deux été lancés en 2026 pour donner plus de pouvoir aux agents et à une nouvelle économie numérique. Coinbase a également contribué à populariser le protocole de paiement x402, que de nombreux agents utilisent désormais pour payer des API, de la puissance de calcul et des données.

La question de savoir si un agent en cours d'exécution a besoin d'un wallet est réglée. Ce qui mérite encore d'être posé, c'est où se situe le contrôle pendant que l'agent l'utilise : l'utilisateur conserve-t-il une clé exportable et définit-il directement les limites de l'agent, ou le chemin d'exécution de l'agent reste-t-il lié à l'infrastructure d'un fournisseur aussi longtemps qu'il tourne ? MetaMask Agent Wallet adopte la première approche : un wallet self-custodial avec des garde-fous programmables, conçu spécifiquement pour les agents qui agissent.

Pour les bases, consultez What is an agentic wallet, puis plongez dans l'architecture technique avec How AI agents transact without touching your keys. Pour une comparaison, voir Best agentic wallets in 2026. Cet article explique pourquoi la couche wallet est désormais incontournable pour tout agent qui agit, et pourquoi la garde détermine dans quelle mesure l'autonomie de cet agent est réelle.

Le passage des agents qui conseillent aux agents qui agissent

Un agent qui ne produit que du texte n'a aucun besoin de toucher à l'argent. Son résultat est une suggestion qu'un humain doit encore exécuter. C'est la forme par défaut de la plupart des agents déployés à ce jour, et c'est aussi leur plafond : un agent qui ne peut que conseiller nécessite encore un humain dans la boucle pour chaque étape financière, ce qui limite la quantité de travail qu'il peut réellement accomplir.

Les agents en cours de développement aujourd'hui sont différents. Ils surveillent une position DeFi et la rééquilibrent directement. Ils cherchent de la puissance de calcul ou des données auprès de plusieurs fournisseurs et paient celui qui est le moins cher à ce moment-là. Ils exécutent une transaction au lieu de la décrire. Chacune de ces actions requiert la même capacité sous-jacente : la possibilité de détenir de la valeur et de la déplacer onchain, à la vitesse à laquelle l'agent opère, sans attendre qu'une personne déverrouille l'étape suivante.

Cette capacité ne vient pas d'un modèle de langage. Elle vient d'un wallet. Le raisonnement d'un agent peut être arbitrairement bon, mais sans moyen de détenir et d'autoriser le mouvement de fonds, il reste un moteur de recommandation. Le wallet est ce qui transforme une décision en action — c'est pourquoi cette catégorie est passée d'une curiosité pour développeurs à une ligne de produits chez MetaMask, Coinbase, Cobo et OKX en l'espace de quelques mois.

Ce dont un agent a réellement besoin pour transacter

Pour agir plutôt que conseiller, un agent a besoin de trois choses : un solde sur lequel il peut puiser, un moyen de payer ce qu'il consomme au fil de l'exécution, et un moyen d'exécuter des transactions onchain sans qu'un humain confirme chaque étape individuellement.

La deuxième exigence est plus récente qu'il n'y paraît. Les logiciels ont toujours payé pour l'infrastructure, mais généralement via une facture gérée par un humain, un abonnement ou une carte enregistrée — pas un paiement que l'agent lui-même initie en cours de tâche. Les agents qui appellent des API payantes, achètent de l'inférence auprès d'un autre modèle ou récupèrent des données sous licence doivent régler ce coût en ligne. x402 comble ce manque : un protocole ouvert, construit sur le code de statut HTTP 402 « Payment Required », qui permet à un serveur de demander un paiement et à un client de le régler dans le même échange, sans création de compte ni approbation humaine en cours de flux. MetaMask Agent Wallet prend actuellement en charge x402 côté acheteur, de sorte qu'un agent peut payer un endpoint protégé par x402 directement depuis son wallet. x402 est distinct du wallet lui-même : il définit comment un paiement est tarifé et réglé, pas qui détient les clés ni ce que l'agent est autorisé à dépenser. Le wallet reste maître de cette question.

Ensemble, c'est ce que les gens entendent par commerce agentique ou paiements machine-à-machine : des logiciels qui paient d'autres logiciels, à la vitesse à laquelle le code s'exécute, pour des services qui nécessitaient autrefois un humain avec une carte de crédit. Rien de tout cela ne fonctionne sans un wallet en dessous.

La question de la garde

Une fois établi qu'un agent en action a besoin d'un wallet, la question la plus utile est de savoir qui le contrôle. Trois modèles sont visibles sur le marché aujourd'hui, à différents stades de disponibilité, et ils répondent différemment à cette question.

Le vocabulaire lié à la garde varie selon les acteurs, et les fournisseurs décrivent leurs propres modèles de manière assez fidèle. Coinbase qualifie ses Agentic Wallets de wallets non-custodiaux sécurisés dans un environnement d'exécution de confiance (TEE), associés à des limites de dépenses programmables et à un screening KYT. OKX décrit son Agentic Wallet de la même façon : des clés gérées dans un TEE et jamais exposées au modèle. Cobo positionne son Agentic Wallet autour du fractionnement de clés basé sur MPC et d'un moteur de politique appliqué par Pact, conçu pour « l'automatisation de niveau entreprise avec un contrôle de politique granulaire ». Ce sont tous des modèles de sécurité légitimes, et MetaMask Agent Wallet utilise également une infrastructure adossée à un TEE pour protéger la signature. La distinction qui compte pour cet article est plus étroite que « TEE vs. pas de TEE » : c'est de savoir si l'utilisateur détient une clé exportable et un chemin de sortie, ou si l'exécution de l'agent reste liée à un wallet opéré par un fournisseur aussi longtemps que l'agent tourne.

C'est le principe de la self-custody appliqué à un nouveau type d'utilisateur. L'infrastructure opérée par un fournisseur peut être genuinement sécurisée, mais elle reste partie intégrante du chemin de confiance pour chaque transaction effectuée par l'agent aussi longtemps qu'il tourne dessus : cette infrastructure peut geler, limiter ou modifier ses conditions, quelle que soit la bonne volonté du fournisseur. Une conception self-custodiale permet à l'utilisateur de conserver le chemin d'export ou de récupération et de définir directement les limites de l'agent, plutôt que de dépendre uniquement d'un compte détenu par un fournisseur. Pour un agent agissant de manière autonome au nom de quelqu'un, c'est la distinction qui détermine si son autonomie accompagne l'utilisateur ou reste bornée par l'environnement d'exécution d'un fournisseur.

L'autonomie sans imprudence : des garde-fous programmables

La self-custody seule n'est pas une réponse complète. Un wallet self-custodial sans limites permettrait à un agent de faire tout ce que le solde de l'utilisateur autorise, ce qui constitue son propre type de risque. La vraie réponse associe la self-custody à des garde-fous programmables définis à l'avance : plafonds de dépenses, protocoles en liste blanche, limites de session, limites par transaction, et un journal de chaque action effectuée par l'agent et de sa raison.

Les garde-fous sont ce qui permet d'accorder à un agent une autorité permanente plutôt que d'approuver chaque transaction manuellement. Un plafond de dépenses limite les pertes d'une mauvaise transaction sans mettre le compte en danger. Une liste blanche de protocoles limite l'agent aux contrats déjà vérifiés par l'utilisateur. Les plafonds de session et par transaction limitent les dégâts qu'un prompt compromis ou une réponse malveillante peut causer, et un journal auditables permet de reconstituer chaque action après coup. Rien de tout cela n'implique de renoncer à l'autonomie — cela définit plutôt les limites dans lesquelles l'autonomie opère.

En pratique, cela se traduit aujourd'hui par deux modes de fonctionnement : un mode par défaut, conservateur, qui applique des limites de dépenses quotidiennes et des listes blanches de protocoles définies lors de la configuration, et qui marque une pause pour une approbation à deux facteurs sur tout ce qui sort de ces règles ou est signalé par le scan de menaces ; et un second mode optionnel qui donne à l'agent plus de latitude sur les cas limites de politique, tout en bloquant les transactions franchement malveillantes. Dans MetaMask Agent Wallet, ces modes portent respectivement les noms de Guard Mode et Beast Mode. Dans tous les cas, les garde-fous sont définis par l'utilisateur avant que l'agent ne démarre, et non négociés par l'agent au moment de l'action.

MetaMask Agent Wallet : la self-custody conçue pour les agents

MetaMask Agent Wallet est un wallet self-custodial conçu spécifiquement pour les agents IA, et son choix de conception fondamental est que l'utilisateur, et non MetaMask, détient les clés. Le wallet permet à un agent d'exécuter des swaps, des contrats à terme perpétuels, des marchés de prédiction, du staking et de la fourniture de liquidités sur les chaînes EVM et Hyperliquid, le tout depuis un seul wallet self-custodial.

Chaque transaction EVM prise en charge passe par un pipeline de sécurité avant d'atterrir onchain : simulation de transaction, scan de menaces alimenté par Blockaid via Transaction Shield, et protection MEV via Smart Transactions. Ce pipeline s'exécute quel que soit le mode de fonctionnement choisi par l'utilisateur : le Guard Mode par défaut, qui exige une approbation à deux facteurs pour tout ce qui dépasse les limites de dépenses ou la liste blanche de protocoles de l'utilisateur, ou le Beast Mode, qui donne à l'agent plus de marge sur les cas limites de politique tout en bloquant les transactions malveillantes et en les soumettant à une révision 2FA. Les clés sont protégées par un environnement d'exécution de confiance tout en restant exportables par l'utilisateur à tout moment, et les transactions éligibles qui passent le pipeline bénéficient d'une couverture Transaction Protection allant jusqu'à 10 000 $ par mois, sous réserve d'éligibilité, de limites et de conditions.

MetaMask Agent Wallet est actuellement en mode CLI-first et conçu pour s'intégrer aux frameworks d'agents, notamment Claude Code, Codex, OpenClaw, Hermes, OpenCode et Cursor. Il est disponible dès aujourd'hui via un programme d'accès anticipé, avec une disponibilité générale prochainement. Pour une présentation complète du parcours d'une transaction depuis l'instruction jusqu'à l'exécution dans cette architecture, voir How AI agents transact without touching your keys.

Ce que cela signifie pour les développeurs qui construisent des essaims d'agents

Le cas des essaims est celui où la question de la garde se complexifie. Un seul agent avec une clé détenue par un fournisseur représente un seul point de confiance. Un essaim d'une douzaine d'agents, chacun transactant de manière indépendante, multiplie cette exposition — et s'ils partagent un seul wallet détenu par un fournisseur, un seul agent compromis ou incident d'infrastructure peut affecter l'ensemble de l'essaim en même temps.

Une architecture self-custodiale offre à un développeur deux façons de contenir ce rayon d'explosion. Chaque agent peut disposer de son propre wallet dédié avec ses propres limites de dépenses, pour l'isolation et la piste d'audit les plus nettes. Ou un seul wallet utilisateur peut accorder à chaque agent une permission déléguée et délimitée — actif, montant, durée et contraintes définis à l'avance — de sorte que le capital n'a pas à être réparti entre des wallets séparément financés. De nombreux systèmes en production utilisent les deux : un wallet financé pour l'exécution générale, et des délégations délimitées pour des tâches plus ciblées et récurrentes, comme le paiement de données ou de puissance de calcul via x402. Dans les deux cas, c'est l'utilisateur, et non un tiers, qui reste la source de vérité sur ce que tout agent de l'essaim peut faire — et le coût d'une erreur de garde reste borné par la politique propre de l'utilisateur plutôt que par l'infrastructure d'un fournisseur.