En avril 2026, BundleBear recense plus de 1,07 milliard de UserOperations ERC-4337 et 56,7 millions de comptes intelligents ayant effectué au moins une transaction sur Ethereum et les principales solutions de couche 2. Ce n’est plus un phénomène marginal. Le compte externe contrôlé par une seule clé secp256k1, avec lequel Ethereum a été lancé en 2015, est contourné à grande échelle. Les chiffres on-chain rejoignent désormais un constat plus discret, au niveau du protocole : le compte lui-même est devenu programmable.

Voici la première partie d’une série en cinq volets consacrée aux comptes intelligents. L’objectif est précis et essentiel : expliquer ce qu’est réellement un EOA, ce qu’est réellement un compte intelligent et pourquoi le choix entre un compte intelligent et un EOA n’est plus une préférence d’interface, mais un choix structurel qui détermine la manière dont votre auto-conservation est assurée.

Ce qu’est réellement un EOA du point de vue du protocole

Le Yellow Paper d’Ethereum définit deux types de comptes : les comptes externes contrôlés par un utilisateur et les comptes de contrat. La seule différence entre eux au niveau de l’état est le champ codeHash. Pour un EOA, codeHash correspond au hachage de la chaîne vide. Pour un compte de contrat, il pointe vers du bytecode EVM exécutable. C’est toute la différence au niveau du protocole.

Un EOA n’est donc pas un « portefeuille » au sens propre. C’est une adresse dérivée des 20 derniers octets de keccak256(public key), dont la paire de clés est fixée à la courbe secp256k1. MetaMask, Ledger et Zelcore sont des interfaces qui stockent la clé. Ce ne sont pas le compte. Si vous ne connaissez pas encore le mécanisme sous-jacent, notre guide sur les clés publiques et privées et la dérivation d’une adresse l’explique de bout en bout.

Jusqu’à l’arrivée d’ERC-4337 en 2023, chaque transaction sur Ethereum devait provenir d’un EOA, et le protocole imposait une seule règle de validation : une signature secp256k1 valide portant sur le hachage de la transaction. Détenir un solde, signer une signature ECDSA pour chaque transaction et payer les frais de gas en ETH depuis le même compte : voilà tout ce qu’un EOA peut faire. Rien de plus.

Les limites structurelles qui comptent pour les utilisateurs

Il ne s’agit pas de simples défauts d’interface. Ces limites structurelles sont à l’origine de la plupart des pertes liées à l’auto-conservation que nous constatons encore en 2026.

Un point de défaillance unique. Une seule clé privée contrôle tout. Si vous la perdez, vous perdez le compte. Si elle est divulguée, vous perdez les fonds, de façon irréversible. Le protocole ne prévoit aucun mécanisme de récupération. C’est précisément pourquoi une phrase de récupération unique constitue le principal point de défaillance de l’auto-conservation.
Une seule courbe. secp256k1 est inscrite en dur. Impossible d’utiliser une clé d’accès (P-256), une clé Ed25519, BLS ou un schéma post-quantique.
Aucune multisignature native. Sur Ethereum, tous les dispositifs « multisig », du Gnosis Multisig d’origine à Safe, sont des contrats appelés par un EOA. L’EOA lui-même ne peut jamais exiger deux signatures.
Aucun regroupement d’actions. Un EOA effectue une seule action par transaction. Approuver un token puis l’échanger nécessite deux transactions signées, deux confirmations et deux paiements de gas.
Aucune politique de dépense. Le protocole ne sait pas exprimer des règles telles que « cette clé peut dépenser jusqu’à 500 $ par jour » ou « cette clé ne peut appeler qu’Uniswap ».
Le gas doit être payé en ETH par le compte qui effectue l’action. Aucun paiement sponsorisé ni paiement natif en USDC n’est prévu.

C’est le cadre dans lequel chaque utilisateur d’Ethereum a été contraint pendant une décennie.

Ce qu’est réellement un compte intelligent

Au sens littéral du protocole, un compte intelligent est un compte de contrat : une adresse dont le champ codeHash pointe vers du bytecode. Celui-ci définit, dans le code, les règles selon lesquelles le compte accepte une action.

Alors que la règle de validation d’un EOA se limite à une vérification secp256k1 fixe, celle d’un compte intelligent est définie par le contrat. Elle peut exiger une multisignature 2 sur 3, une signature par clé d’accès vérifiée sur la courbe secp256r1, une clé attestée par un portefeuille matériel, un délai de verrouillage, une limite quotidienne, une cible d’appel autorisée ou toute combinaison de ces éléments. Les comptes de contrats intelligents valident les signatures selon la norme EIP-1271 plutôt qu’au moyen d’une vérification secp256k1 fixe imposée par le protocole, ce qui permet justement d’utiliser d’autres schémas de signature.

Comme ces règles sont inscrites dans le code, elles peuvent être mises à niveau, combinées et révoquées. Les comptes intelligents existent sur Ethereum depuis 2018 (Safe en est l’exemple de référence). Il leur manquait un moyen de devenir la norme, ainsi qu’un moyen d’envoyer des transactions sans qu’un EOA doive d’abord payer le gas. ERC-4337 et EIP-7702 ont comblé cette lacune.

Comment nous en sommes arrivés là : bref historique de l’abstraction des comptes

L’idée d’unifier les EOA et les contrats remonte aux débuts d’Ethereum. L’EIP-86 de Vitalik, rédigée en 2016, en fut la première proposition détaillée. Il a fallu cinq tentatives pour aboutir aux normes déployées aujourd’hui.

EIP-2938 (septembre 2020) proposait une abstraction des comptes au niveau du protocole. La proposition a été abandonnée, car elle était trop invasive et qu’Ethereum était alors en pleine transition vers la preuve d’enjeu.
EIP-3074 (octobre 2020) introduisait les opcodes AUTH et AUTHCALL, permettant à un EOA de déléguer son pouvoir à un contrat invocateur. Elle a été retirée en raison de préoccupations de sécurité, puis remplacée.
ERC-4337 a été déployée sur le réseau principal d’Ethereum le 1 March 2023. Elle fonctionne uniquement au niveau applicatif, sans hard fork, et achemine des pseudo-transactions appelées UserOperations via un mempool distinct, un Bundler et un contrat EntryPoint singleton.
EIP-7702 a été déployée avec la mise à niveau Pectra le 7 May 2025. Elle introduit le type de transaction 0x04, dans lequel un EOA signe un tuple d’autorisation (chain_id, address, nonce, y_parity, r, s) qui associe le compte à du code de contrat délégué au moyen de l’indicateur 0xef0100 || address. L’EOA se comporte temporairement comme un compte intelligent, sans migration des fonds.
ERC-6900 standardise l’architecture modulaire de plug-ins qui permet aux comptes intelligents de combiner des modules de validation, d’exécution et des hooks.

À retenir : l’abstraction des comptes n’est plus une expérience. C’est une norme déployée et stratifiée, avec une voie ERC-4337 bien définie pour les nouveaux comptes intelligents et une voie EIP-7702 qui permet à chaque EOA existant de l’adopter.

Les cinq capacités qu’ajoute un compte intelligent

Si un EOA se résume à « une clé, une signature, une transaction », un compte intelligent en est le sur-ensemble strict.

Validation programmable. N’importe quel schéma de signature (clé d’accès, P-256, HSM matériel), quorum (2 sur 3, 3 sur 5) ou condition (hauteur de bloc, prix fourni par un oracle). C’est le compte qui définit ce qui constitue une autorisation.
Regroupement atomique. Approuver, échanger et déposer en une seule action signée. Soit toutes les opérations sont exécutées, soit aucune ne l’est. Cela met directement fin aux solutions de contournement liées aux approbations en attente et au modèle multisig dans Zelcore, que les utilisateurs ont dû gérer manuellement.
Abstraction du gas grâce aux paymasters. Un contrat tiers paie le gas au nom de l’utilisateur, ou celui-ci paie en USDC, USDT ou dans tout token ERC-20 accepté par le paymaster. Pour approfondir les liens entre le gas, les approbations et les mécanismes de la DeFi, commencez par l’article sur les fondamentaux de la DeFi.
Clés de session. Des clés de signature limitées à certaines autorisations, à une durée déterminée et à une application précise. « Cette clé peut dépenser jusqu’à 100 USDC sur Uniswap pendant les prochaines 24 heures. » Les conséquences de la compromission d’une clé de session sont limitées par les règles définies, et non par la taille du compte.
Récupération. Récupération sociale, matérielle ou avec délai de verrouillage. Le compte peut être récupéré sans la clé de signature d’origine, ce qui permet enfin de ne plus dépendre d’une phrase de récupération unique susceptible de constituer un point de défaillance.

Pourquoi c’est désormais essentiel à l’auto-conservation

La courbe d’adoption ne fait plus débat. L’EIP-7702 a cumulé plus de 11,000 autorisations au cours de sa première semaine après Pectra et dépassé les 25,000 portefeuilles peu après, avec OKX et MetaMask en tête. Les chiffres cumulés de BundleBear (1.07B UserOps, 56.7M comptes intelligents) complètent le tableau.

Ce qui change réellement, c’est le modèle de menace. Avec un EOA, la tâche de l’utilisateur consiste à « protéger sa phrase de récupération pour toujours, ne jamais signer de transaction malveillante, ne jamais se faire piéger par hameçonnage et ne jamais réutiliser le mauvais appareil ». Les humains échouent manifestement à accomplir cette tâche. Avec un compte intelligent, la tâche de l’utilisateur consiste à « configurer une fois un quorum de récupération et une politique de dépenses ». Le code peut faire respecter cette règle.

Un compte intelligent ne remplace pas un portefeuille matériel. Il permet à un portefeuille matériel d’en faire davantage et, en réalité, limite le rôle qu’un portefeuille matériel joue encore pour un compte intelligent à son usage le plus décisif : signer les opérations maîtresses de grande valeur et peu fréquentes, tandis que les clés de session gèrent les opérations quotidiennes.

La suite de cette série

Cette partie posait le cadre. La suite de la série entre dans le vif du sujet opérationnel.

Partie 2 détaille la pile ERC-4337 : UserOperations, Bundlers, EntryPoint, Paymasters et les points de défaillance de chacun.
Partie 3 examine en détail la délégation EIP-7702 : le tuple d’autorisation, l’indicateur 0xef0100 et les considérations de sécurité liées au fait de pointer son EOA vers le code d’un tiers.
Partie 4 compare les principales implémentations de comptes intelligents (Coinbase Smart Wallet, Safe, Argent, Ambire) et leurs paramètres par défaut réels.
Partie 5 conclut sur le plan opérationnel : comment configurer la récupération, les clés de session et la politique de dépenses d’un compte réel sans renoncer à l’auto-conservation.

La phrase à retenir pour la partie 2 : un EOA est une clé associée à une adresse ; un compte intelligent est un contrat qui détermine ce que sa clé est autorisée à faire.