EOA vs smart account : les différences qui comptent
Si vous avez utilisé un portefeuille crypto, vous avez utilisé un compte. Mais tous les comptes sur Ethereum ne sont pas identiques. Il en existe deux types fondamentalement différents, et cette différence façonne presque tout dans le comportement de votre portefeuille : comment vous signez, qui peut autoriser un paiement, comment vous récupérez l'accès, qui paie les frais et dans quel token.
Cet article passe en revue les deux types de comptes — le externally owned account (EOA) et le smart account — et les compare selon les axes qu'un utilisateur en auto-conservation ressent réellement au quotidien. C'est le deuxième article de notre série sur l'account abstraction ; si vous n'avez pas lu L'account abstraction à partir des principes premiers, c'est un bon point de départ. Ici, nous nous concentrons spécifiquement sur la distinction entre EOA et smart account.
Qu'est-ce qu'un EOA ?
Un externally owned account est le compte d'origine d'Ethereum. Il est défini par exactement une paire de clés secp256k1 : une clé privée et la clé publique qui en dérive. L'adresse que vous voyez — la chaîne 0x... — dérive de cette clé publique. Quiconque détient la clé privée contrôle le compte, point final.
Cette unique clé fait tout le travail. Elle signe chaque transaction avec une signature ECDSA. Aucun code n'est attaché au compte, aucune règle, aucune condition. La seule question que pose le réseau lorsqu'une transaction arrive est : « Cette signature est-elle valide pour cette adresse ? » Si oui, la transaction s'exécute.
La plupart des portefeuilles d'extension de navigateur que vous avez rencontrés — le modèle à clé unique façon MetaMask — créent des EOA. Une phrase de récupération dérive la clé, la clé contrôle le compte, et protéger cette phrase de récupération constitue tout le modèle de sécurité. C'est simple, bien compris et cela fonctionne depuis une décennie. C'est aussi rigide : une clé, un signataire, un schéma de signature, et si cette clé fuite, le compte est perdu.
Qu'est-ce qu'un smart account ?
Un smart account est un compte de contrat : un compte dont le comportement est défini par du code déployé plutôt que par une clé unique. Au lieu de « cette unique signature ECDSA est-elle valide », le compte exécute sa propre logique de validation pour décider d'accepter ou non une opération. Cette logique est programmable.
Comme les règles vivent dans le code, un smart account peut exiger deux signatures au lieu d'une, accepter des schémas de signature autres que le simple ECDSA, imposer des limites de dépense ou définir un chemin de récupération — tout ce que son contrat précise. Les portefeuilles à contrat intelligent façon Safe sont un exemple bien connu de ce modèle. Sur Ethereum et d'autres chaînes EVM, la norme qui permet à ces comptes de se comporter comme des comptes de première classe sans modifier le protocole est ERC-4337.
Contrôle : une clé contre des règles personnalisées
C'est la différence majeure. Un EOA a exactement une règle gravée dans le protocole : une signature ECDSA valide d'une clé autorise tout. Il n'y a aucun moyen d'ajouter un deuxième approbateur obligatoire ni de dire « les montants au-dessus de ce seuil nécessitent une confirmation supplémentaire ». La clé est le compte.
Un smart account décide par lui-même. Il peut exiger un quorum multisig, restreindre certaines actions ou superposer des clés de session. SSP s'en sert pour offrir un 2-of-2 multisig : une clé réside dans l'extension de navigateur SSP Wallet, la seconde dans l'application mobile SSP Key, et la logique de validation du compte exige l'approbation des deux avant d'accepter une transaction quelconque. Une extension de navigateur ayant fuité ne peut pas à elle seule déplacer des fonds, car le contrat n'acceptera tout simplement pas une autorisation à clé unique.
Récupération : ce qui se passe quand une clé est perdue
Avec un EOA, la clé est le compte. Perdez la phrase de récupération et le compte est irrécupérable ; laissez-la fuiter et un attaquant a le contrôle total. Il n'existe aucun recours intégré car il n'y a aucune logique à invoquer — seule cette unique clé compte.
Un smart account peut définir la récupération dans le cadre de ses règles. Parce que la validation est programmable, un contrat peut spécifier des chemins d'autorisation alternatifs, des parties de récupération désignées ou une rotation de clés à délai temporel. Le modèle précis de SSP est un 2-of-2 : perdre l'accès à l'un ou l'autre appareil ne livre pas vos fonds à un attaquant, car les deux signatures sont toujours requises. L'effet pratique est qu'aucun appareil isolé n'est un point de défaillance unique.
Qui paie le gas, et dans quel token
Un EOA paie ses propres transactions, et il les paie dans la monnaie native de la chaîne. Pour déplacer un token ERC-20 sur Ethereum, l'EOA a tout de même besoin d'ETH pour couvrir le gas. Si votre compte détient des tokens mais pas d'ETH, vous êtes bloqué — une expérience courante et frustrante pour les débutants.
Un smart account peut rompre ce lien. Sous ERC-4337, un composant appelé paymaster peut parrainer le gas d'une opération ou accepter le paiement dans un token autre que la monnaie native. Les frais peuvent être pris en charge par un tiers ou réglés dans le même token que vous déplacez déjà. Nous traitons cela en détail dans Parrainage du gas et paymasters expliqués ; le point ici est que « qui paie, et avec quoi » cesse d'être figé.
Regrouper plusieurs actions
Avec un EOA, chaque transaction est une opération distincte, signée individuellement. Le schéma classique de l'ERC-20 — approuver qu'un contrat dépense vos tokens, puis appeler le contrat — fait deux transactions, deux signatures, deux paiements de gas, à la suite.
Un smart account peut regrouper plusieurs actions en une seule opération qui réussit entièrement ou échoue entièrement. Approuver et échanger devient une seule étape. C'est en partie du confort et en partie de la sécurité : il n'existe pas d'état à moitié achevé où vous auriez accordé une approbation mais où l'action suivante n'aurait jamais eu lieu.
Schémas de signature
Un EOA vérifie une seule chose : une signature ECDSA sur secp256k1. C'est le seul schéma que le protocole vérifie pour les externally owned accounts, et il ne peut pas être changé.
Un smart account vérifie tout ce que son code est écrit pour vérifier. Il peut contrôler plusieurs signatures, des courbes exotiques ou des signatures agrégées. Les comptes EVM de SSP vérifient une signature agrégée Schnorr : les deux signatures partielles de l'extension de navigateur et de l'application mobile se combinent — façon MuSig2 sur secp256k1 — en une unique signature on-chain que le contrat valide. La chaîne voit une signature ; le modèle de sécurité derrière elle, ce sont deux approbateurs indépendants. C'est une chose qu'un EOA, par structure, ne peut pas faire.
Déploiement et adresses
Un EOA existe dès l'instant où une clé existe. Générez une paire de clés hors ligne et l'adresse correspondante est déjà valide ; cela ne coûte rien et ne touche aucun contrat. Le compte est, tout simplement.
Un smart account est un contrat, il doit donc être déployé on-chain avant de pouvoir héberger un comportement défini par du code. En pratique, les portefeuilles ERC-4337 utilisent une adresse déterministe et contrefactuelle : l'adresse est calculée à l'avance à partir des paramètres du compte, de sorte qu'elle peut recevoir des fonds avant que le contrat ne soit réellement déployé, et le déploiement a lieu lors de la première utilisation. Vous pouvez partager votre adresse et être payé avant qu'une quelconque transaction de déploiement n'aboutisse.
Coût : le compromis honnête
La programmabilité n'est pas gratuite. Parce qu'un smart account exécute une logique de validation dans un contrat, ses opérations coûtent un peu plus de gas qu'un simple transfert d'EOA, qui est à peu près aussi bon marché que peuvent l'être les transactions Ethereum. Déployer le compte la première fois a aussi un coût ponctuel.
Pour la plupart des utilisateurs en auto-conservation, c'est un prix raisonnable en échange d'une sécurité à deux clés, d'options de récupération, du regroupement et d'un gas flexible. Mais c'est une vraie différence, et il vaut la peine de la nommer clairement plutôt que de l'éluder.
Ce qu'utilise SSP, et quand chaque modèle a du sens
Pour le dire directement : SSP utilise un smart account via ERC-4337 pour offrir son 2-of-2 multisig sur les chaînes EVM — Ethereum, Polygon, Base, BNB Smart Chain et Avalanche. Le contrat exige une signature agrégée Schnorr construite à partir de vos deux appareils, et l'implémentation EVM de SSP a été auditée par Halborn en 2025. Pour voir comment les pièces s'emboîtent, lisez l'architecture d'account abstraction de SSP, et pour le détail propre à la chaîne, voyez Ethereum dans SSP.
Alors, quand chaque modèle a-t-il du sens ? Un EOA est le compte le plus simple possible : le gas le moins cher, une existence instantanée, aucun déploiement. Pour une configuration mono-utilisateur à clé unique où la simplicité prime, il est parfaitement utilisable. Un smart account a du sens quand vous voulez des propriétés qu'une clé unique ne peut pas vous offrir — plusieurs approbateurs obligatoires, une logique de récupération, le regroupement, un gas parrainé ou libellé en token. Le compromis, c'est un gas un peu plus élevé et la notion de déploiement.
Pour un portefeuille en auto-conservation dont la prémisse même est qu'aucune clé isolée ne devrait être un point de défaillance unique, le smart account est le choix naturel. C'est pourquoi SSP est bâti sur l'un d'eux. Pour approfondir le modèle de comptes d'Ethereum lui-même, la documentation sur les comptes Ethereum est la référence faisant autorité, et la spécification ERC-4337 est la norme qui rend les smart accounts pratiques aujourd'hui.
