
L’utilité humaine : le portefeuille agissant et la prochaine décennie des portefeuilles
TechFlow SélectionTechFlow Sélection

L’utilité humaine : le portefeuille agissant et la prochaine décennie des portefeuilles
En 1984, Apple a tué l’interface en ligne de commande avec une souris. En 2026, les agents tuent la souris.
Rédigé par Lacie Zhang, chercheuse chez Bitget Wallet

En 1984, Apple (Macintosh) a éliminé l’interface en ligne de commande à l’aide d’une souris. En 2026, les agents sont en train d’éliminer la souris.
Ce n’est pas une métaphore. Google, Amazon, NVIDIA, Visa, Microsoft et Alibaba — des entreprises ayant investi des milliards de dollars dans le perfectionnement des interfaces graphiques — contournent délibérément aujourd’hui les interfaces GUI au profit des interfaces CLI, API et natives aux agents. La logique est simple : la croissance de zéro à un repose sur l’humain, mais le prochain groupe d’utilisateurs dix fois plus important ne regardera plus l’écran.
Mais ce que tout le monde évite de mentionner est le suivant : lorsque l’utilisateur d’un logiciel passe de l’humain à l’agent, l’humain doit-il encore être présent ?
Dès 1950, Norbert Wiener, fondateur de la cybernétique, avait déjà mis en garde contre ce risque : dès lors que l’humain perd sa capacité à observer et à intervenir, la boucle de rétroaction se rompt et le système échappe à tout contrôle. Ce que OpenAI désigne aujourd’hui sous le terme d’« Harness Engineering » est essentiellement une reformulation de cette même idée.
Plus de soixante-dix ans plus tard, le « portefeuille agentic » (Agentic Wallet) fait face à une version cryptographique de ce problème. Fenêtres de confirmation, demandes de signature, processus d’approbation, sauvegarde de la phrase mnémonique, vérifications multiples… Pendant dix ans, les portefeuilles cryptographiques ont mis en place des mécanismes de sécurité visant tous à répondre à une seule question : « Cette opération est-elle bien autorisée par vous-même ? » Or, les agents rendent obsolète ce mécanisme d’interaction humaine : exiger une validation manuelle pour chaque transaction empêche tout exécution continue, instantanée et automatisée ; tandis qu’accorder sans restriction le contrôle total de la clé privée à un agent expose l’humain à des risques inacceptables.
La réponse ne réside pas dans l’un ou l’autre extrême. L’autonomie totale constitue certes le récit le plus séduisant de l’ère des agents, mais l’avertissement de Wiener demeure pleinement valable. Nous considérons que le portefeuille agentic doit servir deux types d’acteurs simultanément : d’une part, offrir à l’humain la capacité de définir des règles, exercer un contrôle des risques et intervenir dans la gouvernance ; d’autre part, accorder à l’agent des droits d’exécution limités, lui permettant de réaliser des opérations sur chaîne de manière autonome, mais strictement dans les limites préétablies. Autrement dit, le portefeuille doit évoluer d’un simple conteneur d’actifs et outil de signature destiné à l’humain vers un système complet de gestion des autorisations et d’exécution, où l’humain définit les limites et où l’agent agit à l’intérieur de ces limites.
À quoi devrait ressembler un tel système ? C’est précisément la question à laquelle cet article entend répondre.
I. Une autre guerre des portefeuilles, au-delà du « Fat Wallet »
Dans son rapport intitulé Fat Wallet Thesis, Delphi Digital avançait une analyse percutante : à mesure que les protocoles et les couches applicatives se standardisent de plus en plus, la valeur s’accumulera au niveau du portefeuille, car celui-ci est le plus proche de l’utilisateur, détient les canaux de distribution et le flux d’ordres, et les utilisateurs y resteront durablement en raison de leur attachement à une interface familière, à leurs actifs accumulés et aux coûts de migration.
Mais les agents ne suivent pas cette logique. En tant qu’exécutants mécaniques « sans émotion », ils ne s’attarderont pas dans un portefeuille donné pour des raisons de familiarité avec l’interface, de préférence de marque ou d’habitude d’utilisation. Ils chercheront continuellement la combinaison d’infrastructures offrant le coût le plus bas, la latence la plus faible et l’exécution la plus fiable. À mesure que des standards tels que l’ERC-8004 se généralisent, la couche d’identité et de réputation des agents pourrait également migrer entre différents systèmes, ce qui signifie que l’effet de verrouillage des portefeuilles sur les agents est naturellement plus faible que leur effet de verrouillage sur les humains.
Cela ne signifie pas pour autant que la valeur des portefeuilles disparaît, mais plutôt que la localisation de cette valeur change. Dans des scénarios simples d’utilisation personnelle, les agents affaiblissent les moats traditionnels des portefeuilles fondés sur l’interface, les habitudes et les points d’entrée ; en revanche, dans des déploiements organisationnels plus complexes, une fois qu’une entreprise configure pour toute une « flotte d’agents » des règles stratégiques, des processus d’approbation, des paramètres de gestion des risques et un système d’audit, le coût de migration ne provient plus de l’expérience utilisateur frontale, mais de la reconstruction complète de toute la configuration relative aux autorisations, à la gouvernance et à l’exploitation.
Ainsi, le portefeuille agentic répond à une autre question, distincte de celle du « Fat Wallet » : le « Fat Wallet » lutte pour contrôler l’entrée utilisateur, tandis que le portefeuille agentic lutte pour contrôler les fonds dès lors que les logiciels commencent à les gérer directement.
Si l’on retrace l’évolution des portefeuilles, on constate que chaque changement de forme produit correspond, en réalité, à un changement dans l’objet de confiance de l’utilisateur :
- Les portefeuilles basés sur une phrase mnémonique exigent que l’utilisateur se fasse confiance à lui-même.
- Les portefeuilles à contrat intelligent exigent que l’utilisateur fasse confiance au code.
- Les portefeuilles intégrés exigent que l’utilisateur fasse confiance au fournisseur de services.
- Avec le portefeuille agentic, l’utilisateur doit faire confiance à un système de contrôle composé conjointement de permissions, de politiques et de mécanismes de gouvernance.
L’objectif de ce système n’est pas de laisser les logiciels prendre le contrôle des fonds, mais de leur permettre d’agir dans le cadre d’une délégation limitée, tout en conservant à l’humain le pouvoir de décision final. C’est pourquoi le cœur du portefeuille agentic ne réside pas simplement dans le fait de « permettre aux agents d’utiliser un portefeuille », mais dans le fait de « permettre aux agents de gérer des fonds appartenant à des utilisateurs humains, dans des conditions contraintes, traçables et interventionnelles ».

II. Les limites du portefeuille, le point de départ de l’agent
Les portefeuilles actuels fonctionnent toujours correctement dans les scénarios pour lesquels ils ont été conçus, mais le problème est que de plus en plus d’usages pilotés par des agents dépassent désormais ces limites initiales.
Scénario 1 : L’agent de trading doit agir rapidement, mais « être capable d’exécuter » ne signifie pas « être autorisé à exécuter »
Un agent de gestion de portefeuille surveille en continu la liquidité interchaînes. Dès qu’une opportunité se présente, il doit exécuter la transaction en quelques secondes. La logique de contrôle classique des portefeuilles consiste à ouvrir l’application, examiner la transaction, puis cliquer sur « confirmer ». Une fois cette séquence achevée, la fenêtre d’opportunité est souvent déjà fermée.
Sur le plan technique, l’agent est déjà capable d’appeler la fonction « swap », de générer les données calldata et de transférer des fonds via un pont. Le problème réside cependant dans le fait que la capacité ne signifie pas l’autorisation. Le fait qu’un agent puisse lancer une transaction ne signifie pas qu’il doive être librement autorisé à disposer des fonds.
Le rôle du portefeuille agentic est justement de séparer ces deux aspects : l’agent peut agir immédiatement, mais uniquement dans le cadre de règles prédéfinies — par exemple, uniquement sur des actifs approuvés, soumis à un budget journalier, contraints par une limite de glissement, et automatiquement suspendus en cas de conditions de marché anormales. Les « compétences » (Skills) définissent ce que l’agent « peut faire », tandis que le portefeuille encadre ce qu’il « est autorisé à faire ».
Scénario 2 : L’agent de paiement doit dépenser de l’argent, mais ne doit pas disposer d’un contrôle total sur les fonds
Un agent de paiement s’occupe automatiquement du règlement des factures d’API, des abonnements SaaS et des paiements aux fournisseurs. Dans l’architecture actuelle des portefeuilles, il n’a généralement que deux choix : soit attendre une validation manuelle pour chaque paiement, soit détenir directement une clé privée dotée d’un pouvoir de signature illimité. Le premier choix est non évolutif, le second trop risqué.
Le portefeuille agentic propose une délégation limitée : il peut uniquement payer des marchands figurant sur une liste blanche, utiliser uniquement des actifs spécifiés, effectuer des paiements dans la limite d’un budget quotidien, et toutes ses dépenses sont entièrement enregistrées.
Scénario 3 : Plusieurs agents doivent disposer de permissions isolées entre eux, tout en partageant un budget commun
Un même acteur peut exécuter simultanément plusieurs agents : un pour le trading, un pour les paiements, un pour l’audit. Bien qu’il soit possible, avec les portefeuilles actuels, de créer plusieurs sous-comptes, la coordination centralisée des autorisations, la définition d’un plafond budgétaire global, l’application de contraintes stratégiques transversales aux agents et la constitution d’une chaîne d’audit unifiée ne constituent pas des capacités natives des portefeuilles existants.
Dans le modèle du portefeuille agentic, ces aspects sont traités comme des problématiques prioritaires de conception : chaque agent dispose de permissions indépendantes et clairement délimitées ; parallèlement, une couche stratégique unifiée contrôle l’exposition globale aux risques, impose des limites de fréquence transversales aux agents et gère le budget partagé, tout en générant des enregistrements d’audit cohérents.
Tous ces scénarios convergent vers une même conclusion : la gestion des clés privées reste la base de la sécurité des portefeuilles, mais permettre à un agent d’y accéder directement constitue, dans n’importe quel scénario, une source de risque inacceptable. Toutefois, maîtriser uniquement la clé privée ne suffit plus. Lorsque l’opérateur passe de l’humain à l’agent, le portefeuille doit aussi répondre à une deuxième question : qui est autorisé à agir, dans quelles conditions, à quel montant, sur quels actifs et envers quels destinataires ? La gestion des clés privées constitue la première ligne de défense ; la gestion des limites d’autorisation des opérateurs non humains constitue la deuxième ligne de défense, nouvelle et spécifique à l’ère des agents.
III. L’autonomie bornée : la philosophie de conception du portefeuille agentic
L’industrie en est encore à ses premières explorations du portefeuille agentic, et aucune solution véritablement mature n’existe encore. Toutefois, comme mentionné dans l’introduction, le portefeuille agentic, tel que défini dans cet article, est un système de contrôle des fonds reliant la gouvernance humaine à l’exécution par les agents : l’humain fixe les limites, l’agent agit à l’intérieur de ces limites, et le portefeuille garantit que cette relation contraignante reste toujours exécutable, traçable et interventionnelle.
Par ailleurs, selon le degré d’autorisation accordé à l’agent, le portefeuille agentic pourrait servir quatre configurations distinctes :
- Type contrôlé par l’humain : l’agent fournit des conseils et une assistance, chaque opération devant toujours être confirmée par un humain. Ce mode améliore l’efficacité interactive, mais ne modifie pas la logique de contrôle des fonds.
- Type hybride : l’agent gère les opérations courantes — recherche, obtention de devis, rappels ou exécutions à faible risque — tandis que l’intervention humaine diminue, bien que les cas limites (transferts de fonds, appels de contrat ou branches anormales) requièrent toujours une validation humaine.
- Type à autonomie bornée : l’agent agit de façon autonome dans le cadre de règles, de plafonds et de voies de recours clairement définies. L’humain passe ainsi du rôle d’approbateur transactionnel à celui de concepteur de règles. Le portefeuille agentic décrit dans cet article vise principalement ce type.
- Type entièrement autonome : l’agent jouit d’une souveraineté économique quasi complète, capable de mobiliser des fonds et d’en assumer les conséquences, sans limite prédéfinie. Ce modèle est théoriquement valide, mais demeure loin d’être mature sur les plans de la sécurité, de la gouvernance, de l’imputabilité et de la conformité réglementaire, et se situe aujourd’hui presque exclusivement au stade expérimental.
Pour référence, Stripe, dans sa lettre annuelle 2025, classe le commerce agentic en cinq niveaux : L1 correspond à la suppression des formulaires web (« Eliminating web forms »), L2 à la recherche descriptive (« Descriptive search »), L3 à la mémoire persistante (« Persistence »), L4 à la délégation d’autorité (« Delegation »), L5 à l’achat anticipé (« Anticipation ») ; et précise explicitement que l’industrie dans son ensemble « oscille encore aux confins des niveaux L1 et L2 ».
De ce point de vue, la demande la plus forte du marché concerne actuellement les scénarios contrôlés par l’humain et hybrides, tandis que l’autonomie bornée représente la vraie frontière actuelle, ainsi que la première forme de production réellement opérationnelle où les agents commencent à gérer des fonds.
La mise en œuvre de cette vision nécessite une architecture en quatre couches :
- Couche compte : création, pour chaque agent, d’un conteneur économique indépendant et isolé — par exemple via un EOA, un compte à contrat intelligent, un portefeuille serveur ou un environnement TEE. Le système doit appliquer des règles différenciées à chaque agent.
- Couche autorisations : définition des limites du comportement de l’agent — plafonds de dépense, actifs pouvant être manipulés, contrats pouvant être interfacés, fenêtres temporelles d’exécution, logique d’action en cas de dépassement de seuil. Il s’agit de la couche centrale de toute l’architecture.
- Couche exécution : interface conçue pour les agents, non pour les clics humains. Les opérations d’envoi, de paiement, de swap, de pont, de rééquilibrage, de liquidation et de règlement doivent être abstraites en primitives directement appelables par programme.
- Couche gouvernance : elle doit fournir des journaux, des simulations, des traces d’audit, des alertes, un interrupteur de suspension, un droit de veto humain et des mécanismes de restauration. Cette couche détermine si le portefeuille agentic peut véritablement entrer en production.

Au-dessus de cette architecture en quatre couches, quatre capacités fondamentales soutiennent le fonctionnement du système :
- Compétences (Skills) : modules normalisés d’opérations sur chaîne. L’agent peut accomplir des transactions, des paiements ou des transferts interchaînes comme s’il appelait une fonction, sans avoir besoin de composer lui-même les données calldata sous-jacentes. Les Skills résolvent le problème d’abstraction des capacités — « Que peut faire l’agent ? »
- Politiques (Policies) + KYA / KYT : le moteur de politiques procède à une vérification règlementaire pour chaque opération, transformant les limites définies par l’humain en contraintes exécutables par la machine ; les mécanismes KYA / KYT identifient l’origine, l’identité, le contexte de risque et l’historique d’exécution de l’agent. Le premier encadre le comportement, le second identifie l’opérateur ; ensemble, ils garantissent que chaque mouvement de fonds reste strictement contenu dans les limites prédéfinies.
- Clés de session (Session Key) : mécanisme sécurisé de délégation temporaire, limitée en montant et en portée. L’agent reçoit une autorisation temporaire et circonscrite, et non la clé privée complète. Cette autorisation expire automatiquement à échéance, sans nécessiter de révocation manuelle : « permettre à l’agent d’obtenir une qualification à l’exécution sans jamais entrer en contact avec la clé privée complète ».
- Audit et notifications : système complet de journaux traçables et d’alertes en temps réel. Chaque opération est réversible, chaque anomalie déclenche une alerte, et chaque agent peut être suspendu à tout moment.

Aujourd’hui, nous contrôlons généralement la logique comportementale des agents via des instructions, mais l’orchestration des tâches ne signifie pas la contrainte des fonds. Un agent peut encore mal interpréter une situation, s’en écarter ou subir une attaque ou une pollution malveillante d’entrées externes. La couche portefeuille joue ici un rôle essentiel : elle formalise à l’avance, sous forme de règles système, des questions critiques liées aux autorisations financières — « Peut-on mobiliser des fonds ? Combien ? Sur quels actifs ? Avec quels contreparties ? Comment arrêter l’opération en cas d’anomalie ? ». Même si l’agent dévie, les actions financières effectives demeurent strictement limitées aux limites prédéfinies.
IV. État actuel du portefeuille agentic : quatre voies et quatre lacunes
En examinant les solutions existantes de portefeuille agentic, nous avons identifié quatre cas d’étude représentatifs. Tous ont déjà résolu la question de « comment permettre à un agent d’accéder au système financier », mais aucun n’a encore répondu à la question cruciale : « Comment permettre à un agent d’utiliser des fonds de façon sûre dans des environnements interchaînes et réellement complexes ? »

Coinbase, Safe, Privy et Polygon ont chacun apporté des réponses viables, respectivement au niveau de l’infrastructure, de la gouvernance, des autorisations et de l’identité. Ce qui reste à accomplir, c’est l’intégration de ces capacités locales en un système de contrôle unifié, capable de fonctionner interchaînes, de migrer entre environnements et de rester valide même dans des scénarios adverses complexes. Les blocages actuels du portefeuille agentic se concentrent principalement autour de quatre lacunes :
Première lacune : l’identité et la réputation ne sont pas transportables.
Il est possible de construire un système d’identité et de réputation pour les agents sur chaîne, mais aucune infrastructure de crédit universelle, interchaînes, inter-portefeuilles et inter-environnements n’existe encore. L’historique et la réputation accumulées par un agent dans un écosystème donné ne peuvent pas être naturellement transférées à un autre écosystème.
Deuxième lacune : la couche stratégique manque d’un standard unifié.
Coinbase utilise des limites de dépense, Safe des modules sur chaîne, Privy un moteur de politiques, et Polygon des portefeuilles à portée de session. L’industrie reconnaît largement que la couche d’autorisations est centrale, mais aucun standard portable, composable et réutilisable à travers les produits n’a encore été établi.
Troisième lacune : la sécurité en environnement adversaire reste largement vide.
L’injection de prompts, la contamination d’outils, les compétences malveillantes et les entrées externes corrompues ne sont pas résolues automatiquement par les audits traditionnels de contrats intelligents. Le véritable défi nouveau de l’ère des agents est le suivant : lorsque le processus décisionnel du modèle est déformé par des entrées malveillantes, comment le portefeuille peut-il identifier, intervenir et bloquer le risque ?
Quatrième lacune : la couverture interchaînes est encore très insuffisante.
La plupart des solutions actuelles dépendent d’une seule chaîne ou d’un nombre limité de chaînes, alors que les activités économiques des agents ne se cantonneront pas durablement à un seul écosystème. Un portefeuille agentic véritablement mature devra faire face aux défis posés par le multichaîne, les multiples environnements d’exécution et la cohérence des autorisations transversales.

V. Sous la surface : le portefeuille agentic dans sa prochaine décennie
Aujourd’hui, la conception du portefeuille agentic met l’accent sur l’octroi à l’humain d’un contrôle fin sur l’agent. Dans la plupart des implémentations, le rôle du portefeuille s’apparente davantage à celui d’un signataire passif : l’agent appelle une compétence (Skill), celle-ci génère une transaction, et le portefeuille procède à la signature en arrière-plan, suivie immédiatement de l’exécution sur chaîne.
Mais si les agents commencent vraiment à gérer des fonds, se contenter de signer à la dernière étape est manifestement insuffisant. Une approche plus rationnelle consiste à placer la prise de décision sur les autorisations avant l’exécution : après qu’un agent a appelé une compétence, sa demande entre d’abord dans le « plan politique » (Policy Plane) interne du portefeuille, et l’exécution n’est autorisée que si elle réussit la vérification politique.
Le « Wallet Policy Plane » s’inspire de la distinction classique, en architecture système, entre le plan de contrôle (Control Plane) et le plan de données (Data Plane). Il s’intercale entre le comportement de l’agent et l’exécution sur chaîne, intégrant en une seule instance décisionnelle le moteur de politiques, les vérifications KYT/KYA, la validation des clés de session, l’évaluation des risques et le traitement des anomalies.

Cette approche n’est pas nouvelle : l’architecture de paiement de Stripe suit une logique similaire. Les développeurs appellent une API simple, mais avant que les fonds ne bougent réellement, Stripe a déjà mené en arrière-plan l’identification des risques, les vérifications règlementaires et le traitement de conformité. Le portefeuille agentic doit faire exactement la même chose : offrir à l’extérieur une interface d’exécution propre, et à l’intérieur, déployer un moteur de politiques préalable pour trancher les questions d’autorisation.
L’urgence vient du fait que la surface d’attaque créée par l’injection de prompts, la contamination d’outils et les compétences malveillantes s’étend rapidement, tandis que les infrastructures de sécurité côté portefeuille n’ont pas su suivre ce rythme. Le « Wallet Policy Plane », standardisé, n’est pas encore devenu une primitive fondamentale et universellement adoptée par l’industrie.
Cependant, le Policy Plane lui-même ne constituera pas non plus l’état final. À mesure que les systèmes d’identité et de réputation des agents mûriront, la logique d’autorisation évoluera d’un modèle fondé sur des règles statiques vers un modèle fondé sur une confiance dynamique. Aujourd’hui, on se fie à des limites prédéfinies, à des plafonds, à des listes blanches et à des voies de recours humaines ; demain, les historiques de transactions sur chaîne, les traces comportementales et les données de crédibilité inter-écosystèmes constitueront progressivement une base vérifiable de réputation des agents, et de plus en plus de décisions d’autorisation seront prises sur la base de l’identité, de l’historique et des performances réelles.
Lorsque les agents commenceront à interagir économiquement entre eux à la vitesse des machines, les mécanismes de contrôle devront être intégrés dès la conception du système. Le rôle du portefeuille évoluera également : dans sa phase initiale, il agit comme un gardien, chargé d’empêcher tout dépassement des limites ; dans sa phase mature, il devient davantage une infrastructure, chargée de permettre aux entités de confiance de se connecter aux comptes, aux autorisations et aux systèmes de règlement avec un frottement minimal.
Pendant la dernière décennie, le champ de bataille des portefeuilles était l’entrée visible à l’écran. Pour la prochaine décennie, ce champ de bataille se situera dans la couche de contrôle invisible aux yeux de l’utilisateur.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News











