WalletConnect est un protocole de messagerie qui transporte des messages chiffrés entre une dApp et un wallet, permettant à la dApp de demander des signatures sans jamais toucher votre clé privée. Scanner son QR code crée un pairing ; approuver la proposition de session de la dApp crée ensuite une session qui liste les chaînes et les méthodes qu'elle peut solliciter — la permission de demander, pas la permission d'agir ; chaque mouvement d'actifs exige toujours votre signature. Se déconnecter met fin à la session localement, mais ne révoque pas les approbations de token onchain. Sur WATS, les sessions sont approuvées dans l'application mobile WATS.
Ce qu'est réellement WalletConnect (et ce qu'il n'est pas)
WalletConnect est un protocole de messagerie. Son unique rôle est de transporter des messages entre une dApp et un wallet, afin que les deux puissent dialoguer sans que la dApp ne touche jamais votre clé privée. Quand un site affiche un QR code et propose de connecter votre wallet, ce code est généralement une invitation de pairing WalletConnect.
Ce n'est ni un wallet, ni un dépositaire, ni une blockchain : il ne détient aucun fonds et ne signe rien. Ce n'est pas non plus une extension de navigateur, laquelle injecte un provider directement dans la page. On le connaît surtout pour le cas multi-appareils — en 2026, c'est encore la façon la plus courante pour un wallet mobile de dialoguer avec une dApp desktop — mais il est tout autant la voie standard sur un seul appareil, avec un deep link qui envoie une dApp ouverte dans le navigateur mobile vers l'application wallet du même téléphone.
Ce qui se passe quand vous scannez ce QR code
Le QR code encode une URI de pairing : un identifiant de topic, un identifiant de protocole relais et une clé symétrique. Cette clé est transmise telle quelle plutôt que dérivée par le wallet — c'est pourquoi une URI de pairing divulguée ou capturée en capture d'écran est sensible. Les deux parties échangent ensuite des messages chiffrés sur le topic de pairing.
Le pairing n'est que la poignée de main. La session qui transporte chaque demande de signature s'exécute sur un topic distinct, sous sa propre clé que la dApp et le wallet négocient directement via un échange X25519 étendu avec HKDF. La clé de pairing protège les messages de niveau pairing, jamais vos demandes de transaction.
Le relais est la partie que l'on comprend mal : il ne route que du texte chiffré et des métadonnées, et ne peut ni lire les payloads, ni les altérer, ni signer à votre place. S'il tombe, votre session cesse de fonctionner, mais vos fonds restent intacts — vos clés n'ont jamais quitté votre appareil. La dApp envoie ensuite une proposition de session et votre wallet l'affiche sous forme d'écran d'approbation ; tout ce qui suit dépend de ce que vous approuvez. Le déroulé pas à pas se trouve dans notre guide sur comment connecter un wallet à une dApp.
Sessions, namespaces et permissions : ce qu'une dApp peut demander
Une proposition de session est structurée, pas libre. Elle liste des namespaces : les chaînes, les méthodes et les événements que la dApp souhaite — Ethereum mainnet, un L2 ou Solana ; signature de transactions et signatures de données typées ; événements chain-changed et accounts-changed.
Attention au sens : la dApp demande des chaînes, des méthodes et des événements, tandis que les comptes eux-mêmes sont sélectionnés dans votre wallet et renvoyés dans l'approbation. La distinction de la v2 compte aussi. Les namespaces required fonctionnent en tout ou rien — satisfaits intégralement, sinon la proposition est rejetée d'emblée — mais en 2026 c'est la voie héritée, dépréciée et déconseillée au profit des namespaces optional, qu'un wallet peut approuver partiellement. Un bon wallet vous montre les deux, pour que vous sachiez ce qui est négociable.
Approuver une session fait deux choses : cela partage vos adresses publiques pour les chaînes approuvées, et cela accorde à la dApp la permission d'envoyer des demandes pour les méthodes approuvées. La permission de demander n'est pas la permission d'agir.
Demandes de signature : pourquoi une connexion n'est pas une approbation
Une fois la session établie, chaque action significative arrive sous forme de demande distincte que vous devez approuver explicitement : un swap devient une demande de transaction, une connexion une demande de signature de message, une mise en vente sur une marketplace une signature de données typées.
C'est la frontière de sécurité qui compte. Une dApp connectée ne peut pas déplacer vos actifs en silence : cela exige une signature, et une signature exige votre appareil et votre approbation. Ce qu'elle peut faire, c'est présenter une demande trompeuse dont les conséquences ne sautent pas aux yeux à l'écran.
Deux catégories méritent une méfiance particulière : l'approbation de token, qui accorde à un contrat la permission durable de dépenser un token bien après la fin de la session, et la signature offchain — celle qui ne coûte pas de gas — qui peut autoriser un ordre ou un permit qu'un contrat exploitera plus tard. Ni l'une ni l'autre n'a l'air spectaculaire.
Là où WalletConnect déraille : sessions dormantes, faux QR codes et signature à l'aveugle
Sessions dormantes. Les sessions ont une expiration, mais on accumule des dizaines de connexions actives vers des sites utilisés une seule fois. Chacune est un canal qui peut pousser une demande vers votre wallet à tout moment — autant de surface supplémentaire pour une approbation mal lue.
QR codes falsifiés ou substitués. Un attaquant qui contrôle une page — un domaine sosie, un frontend détourné — peut afficher son URI de pairing à la place de la vraie. Vous vous connectez avec succès… à lui. C'est le piège décrit dans notre analyse du fonctionnement des wallet drainers : la connexion réussit, et les dégâts arrivent dans la demande de signature qui suit.
Signature à l'aveugle. Si votre wallet ne parvient pas à décoder une demande et affiche des données brutes à la place, vous faites confiance à la description que le site donne de sa propre transaction. Voyez-y une raison de vous arrêter, pas une formalité.
Comment examiner et révoquer les sessions actives (et pourquoi les approbations sont séparées)
Tout wallet compatible WalletConnect tient une liste des sessions actives, généralement sous « connexions » ou « applications connectées ». Lisez-la comme un inventaire : chaque entrée nomme la dApp ainsi que les chaînes et les comptes qu'elle peut voir.
Se déconnecter ne coûte rien : votre wallet publie un message de suppression de session via le relais et retire la session de son propre état — pas de transaction, pas de gas, aucune trace onchain. Considérez toutefois cette fermeture comme « au mieux » : si le pair est hors ligne ou le relais injoignable, la dApp peut continuer à considérer la session comme active jusqu'à la livraison du message ou l'expiration.
Le point qui piège tout le monde : déconnecter une session ne révoque pas une approbation de token. Les permissions de session vivent dans l'état local de votre wallet ; les approbations de token vivent onchain, accordées par une transaction que vous avez signée. Clôturer la session stoppe les nouvelles demandes mais laisse l'allowance intacte — la révoquer est une étape onchain distincte, détaillée dans notre tutoriel sur la révocation des approbations de token. Faites les deux.
Comment WATS gère les connexions aux dApps
Sur WATS, les sessions WalletConnect sont prises en charge par l'application mobile WATS : elle scanne le QR code et affiche chaque proposition et chaque demande de signature pour approbation sur votre téléphone. La conservation fonctionne de la même manière sur tous les produits WATS, y compris le WATS Hot Wallet — vous détenez vos clés et WATS ne détient jamais de clé, si bien qu'aucune dApp connectée ne peut déplacer des fonds sans votre signature.
Ce qui change, c'est la couche de frais. Chaque action — transferts, swaps, staking — est facturée dans un seul token, ATS, à la place du gas natif de la chaîne : sur EVM via un paymaster ERC-4337, sur Solana et TON via un mécanisme équivalent de fee-payer/relayer. Comme ATS est un OFT LayerZero, un seul solde couvre les trois écosystèmes. Les ATS collectés sont brûlés depuis 100 000 000 vers un plancher de 30 000 000. WATS est le premier et le seul wallet à combiner des frais en un seul token ERC-4337 + OFT, prélevés à la place du gas natif, avec ce burn.
Foire aux questions
Connecter un wallet via WalletConnect donne-t-il à une dApp accès à mes fonds ?
Non. Une session permet à une dApp de voir vos adresses publiques pour les chaînes approuvées et de vous envoyer des demandes. Toute action qui déplace des actifs exige une signature que vous approuvez sur votre propre appareil : une simple connexion ne peut donc rien dépenser. Sur WATS, ces propositions et ces demandes de signature sont affichées pour approbation dans l'application mobile WATS, et comme WATS ne détient jamais de clé, aucune dApp connectée ne peut déplacer des fonds sans votre signature.
Déconnecter une session WalletConnect révoque-t-il les approbations de token ?
Non, ce sont deux choses distinctes. Une session vit dans l'état local de votre wallet et se termine sans aucun gas dès que vous la déconnectez depuis ce dernier. Une approbation de token vit dans le contrat du token onchain et reste active tant que vous n'envoyez pas une transaction de révocation.
Le serveur relais WalletConnect peut-il lire mes transactions ou voler mes clés ?
Non. Dans WalletConnect v2, la session qui transporte vos demandes de transaction et de signature est chiffrée sous une clé que la dApp et votre wallet négocient directement entre eux via un échange X25519 — cette clé n'est jamais exposée au relais. La clé symétrique transportée dans l'URI de pairing ne protège que les messages de niveau pairing. Le relais achemine du texte chiffré et des métadonnées, et votre clé privée ne quitte jamais votre wallet à aucun moment du processus.