Wallets et intégrations Web3 : des connexions et des signatures que vos utilisateurs comprennent avant de décider.
Une application demande, le portefeuille présente, l'utilisateur décide.
Connexion, authentification, signatures et autorisations : nous intégrons les portefeuilles à vos applications pour que chaque demande soit claire, et que la décision reste à l'utilisateur.
Illustration en six étapes. 1. L'application fictive Lumen prépare une demande pour ouvrir son espace membre. 2. La demande est identifiée : une signature de message pour s'authentifier, sans transaction, sans frais, sans autorisation sur les actifs. 3. Le portefeuille reçoit la demande. 4. Il présente le site, le compte, le type de demande, sa conséquence et ce qu'il faut vérifier. 5. L'utilisateur décide de signer ; il aurait pu refuser. 6. L'application vérifie la signature et ouvre la session, sans autre conséquence.
La demande de signature, en six étapes
Ce qu'une intégration wallet permet, selon ce que votre application doit faire.
Une intégration wallet relie votre application aux portefeuilles de vos utilisateurs. Son périmètre dépend de ce que l'application doit leur demander : nous le définissons avec vous, rien n'est inclus d'office.
Connexion d'un portefeuille à l'application, et choix du compte partagé.
Authentification par signature lorsque le mécanisme retenu le permet.
Demandes de signature compréhensibles un texte lisible, un objet précis, le bon moment.
Préparation et soumission d'opérations en lien avec vos smart contracts.
Changements de compte ou de réseau détectés et expliqués.
États et erreurs refus, portefeuille absent, réseau non pris en charge.
Autorisations demandées limite, portée, révision.
Intégration à vos services comptes, droits, journal des actions.
Chaque élément se décide projet par projet ; certains ne sont pas utiles à votre application. Le portefeuille d'un investisseur dans l'immobilier n'appelle pas les mêmes demandes que celui d'un client du luxe.
Connecter, signer, autoriser : quatre demandes, quatre conséquences.
Dans un portefeuille, ces demandes se ressemblent : une fenêtre, un texte, deux boutons. Leurs conséquences n'ont rien à voir.
Connecter
- Ce qu'elle permet
- À l'application : voir, selon le mécanisme, l'adresse publique du compte choisi et le réseau sélectionné ; présenter ensuite d'autres demandes.
- Ce qu'elle ne permet pas
- Signer à la place de l'utilisateur, déplacer ses actifs, accéder à ses clés, prouver son identité civile.
- Sur la blockchain ?
- Non.
Signer un message
- Ce qu'elle permet
- Prouver le contrôle d'un compte, pour un objet précis : un site, une connexion, une demande unique.
- Ce qu'elle ne permet pas
- Dans un mécanisme bien conçu : aucune transaction, aucuns frais, aucune autorisation. Toutes les signatures de message ne sont pas anodines : un contenu illisible ou trop large peut servir ailleurs.
- Sur la blockchain ?
- Non.
Signer une transaction
- Ce qu'elle permet
- Autoriser une opération précise, telle qu'elle est affichée : destinataire, montant, frais.
- Ce qu'elle ne permet pas
- Toute autre opération. La signature n'est pas la confirmation : le réseau doit encore inclure la transaction.
- Sur la blockchain ?
- Oui, une fois la transaction incluse par le réseau.
Autoriser un contrat
- Ce qu'elle permet
- Dans certains standards et réseaux : permettre à un contrat d'agir sur un actif, dans une limite, plus tard et sans nouvelle signature.
- Ce qu'elle ne permet pas
- Agir sur d'autres actifs, au-delà de la limite, ou pour un autre contrat, lorsque le standard le prévoit ainsi.
- Sur la blockchain ?
- Oui : l'autorisation est elle-même une transaction.
Le nom et le logo d'une application ne prouvent rien : seuls le domaine, le compte et le contenu de la demande permettent de décider.
Toutes les demandes ne se valent pas : sachez ce que vous accordez, et ce que vous gardez.
Quatre demandes qu'un portefeuille peut afficher de façon semblable, aux conséquences très différentes. Choisissez-en une, puis acceptez ou refusez. Simulation fictive : aucun portefeuille, aucune clé, aucune transaction réels.
Portéece que la demande permet
- voir (portée de cette demande)
- prouver
- agir une fois
- permettre plus tard
Échelle pédagogique, propre à ces exemples : ce n'est pas un classement du risque. Une signature de message peut avoir des effets importants ; la portée réelle dépend du contenu et du mécanisme utilisé.
L'application demande : afficher votre compte et vous proposer ses fonctions Web3.
Se connecter à un site
- Site
- lumen.example
- Compte proposé
- Compte principal
- Partagé
- selon le portefeuille et le mécanisme : en général l'adresse publique du compte et le réseau sélectionné
- Frais
- aucuns
Le nom et le logo affichés ne prouvent rien : vérifiez le domaine, le compte et le contenu.
Ce que vous accordez
- voir l'adresse publique du compte choisi
- connaître le réseau sélectionné
- vous présenter ensuite d'autres demandes
Ce que vous n'accordez pas
- signer à votre place
- déplacer vos actifs
- accéder à vos clés
- prouver votre identité civile
Si vous vous connectez
Connexion établie
L'application affiche votre compte. Toute action ultérieure passera par une nouvelle demande, que vous pourrez refuser.
Reste sous votre contrôle
Le compte partagé ; la déconnexion du site, depuis le portefeuille ou l'application.
Ce qui peut persister ensuite
La connexion peut rester mémorisée par le portefeuille jusqu'à ce que vous la retiriez. Elle ne donne aucun droit sur vos actifs.
Les quatre demandes, et ce que chacune accorde :
Connexion
L'application demande : afficher votre compte et vous proposer ses fonctions Web3.
- Ce que vous accordez : voir l'adresse publique du compte choisi ; connaître le réseau sélectionné ; vous présenter ensuite d'autres demandes.
- Ce que vous n'accordez pas : signer à votre place ; déplacer vos actifs ; accéder à vos clés ; prouver votre identité civile.
- Si vous vous connectez : Connexion établie. L'application affiche votre compte. Toute action ultérieure passera par une nouvelle demande, que vous pourrez refuser.
- Si vous refusez : Aucune connexion. Aucune information n'est transmise à l'application. Les fonctions qui ne demandent pas de portefeuille restent disponibles.
- Ce qui peut persister ensuite : La connexion peut rester mémorisée par le portefeuille jusqu'à ce que vous la retiriez. Elle ne donne aucun droit sur vos actifs.
Signature de message
L'application demande : vérifier que vous contrôlez ce compte, pour ouvrir une session.
- Ce que vous accordez : une preuve que vous contrôlez ce compte, pour ce site et cette connexion.
- Ce que vous n'accordez pas : aucune transaction ; aucuns frais ; aucune autorisation sur vos actifs ; aucune preuve de votre identité civile.
- Si vous signez : Session ouverte. L'application vérifie la signature et ouvre une session. Rien n'est enregistré sur la blockchain.
- Si vous refusez : Pas de session. Rien n'est signé. Aucune autre conséquence : la demande pourra être présentée à nouveau.
- Ce qui peut persister ensuite : La session dure selon les règles de l'application. Bien conçue, la signature ne vaut que pour ce site et cette demande.
Signature de transaction
L'application demande : réserver un atelier : transférer 12 LUM, un jeton fictif, au contrat de réservation.
- Ce que vous accordez : l'accord pour cette opération précise, telle qu'elle est affichée.
- Ce que vous n'accordez pas : toute autre opération ; une confirmation : le réseau doit encore inclure la transaction.
- Si vous signez : Signée, pas encore confirmée. La transaction est soumise au réseau. Elle n'est pas encore confirmée : l'application suit son état jusqu'au résultat.
- Si vous refusez : Rien n'est envoyé. Aucune signature, aucune transaction, aucuns frais. La réservation n'est pas faite.
- Ce qui peut persister ensuite : Une fois confirmée, l'opération est définitive : se déconnecter ne l'annule pas.
Autorisation à un contrat
L'application demande : permettre au contrat de la place de marché de prélever vos jetons LUM lors de vos prochains achats.
- Ce que vous accordez : au contrat affiché, le droit de déplacer jusqu'à 200 LUM de ce compte ; sans vous redemander, tant que l'autorisation reste active.
- Ce que vous n'accordez pas : d'autres actifs que le jeton LUM ; au-delà de la limite affichée ; à un autre contrat que celui affiché.
- Si vous autorisez : Autorisation demandée. L'autorisation est elle-même une transaction : signée, soumise, puis confirmée. Une fois active, le contrat pourra agir dans la limite, plus tard, sans nouvelle signature.
- Si vous refusez : Aucune autorisation. Les achats qui en dépendent ne sont pas possibles. Rien d'autre ne change.
- Ce qui peut persister ensuite : L'autorisation reste active après la déconnexion du site : se déconnecter ne la retire pas. La réduire ou la révoquer demande une nouvelle transaction.
Contenu illisible : Le portefeuille ne peut pas afficher ce que vous signeriez. Ne signez pas sans comprendre. Selon son contenu, ce message pourrait servir à autre chose qu'à une connexion. Une intégration bien conçue ne demande pas ce type de signature.
Échelle pédagogique, propre à ces exemples : ce n'est pas un classement du risque. Une signature de message peut avoir des effets importants ; la portée réelle dépend du contenu et du mécanisme utilisé.
Autorisations, refus et révocations : ce qui reste actif après un clic.
Certaines demandes s'arrêtent au clic. D'autres laissent une permission active, que l'utilisateur doit pouvoir retrouver et retirer.
Ce qui persiste
Une connexion mémorisée, une session ouverte, et surtout une autorisation accordée à un contrat sur un actif, par exemple un jeton issu de la tokenisation d'actifs : elle reste active jusqu'à modification ou révocation, même après la déconnexion du site.
Réviser ou révoquer
Selon le mécanisme, réduire ou retirer une autorisation demande une nouvelle transaction : aucune révocation n'est automatique. Nous prévoyons dans l'application où la retrouver et comment la retirer ; les droits d'administration relèvent de la sécurité et de la gouvernance.
Refuser
Un refus ne crée ni signature, ni transaction, ni autorisation. L'application l'explique et propose la suite, une autre fonction ou plus tard, sans message d'erreur.
Nous évitons de demander des autorisations sans limite quand une limite suffit, et nous l'expliquons quand ce n'est pas possible.
Intégrer un portefeuille à votre application, sans promettre ce qu'il ne fait pas.
Il n'existe pas de compatibilité universelle. Nous choisissons avec vous les portefeuilles et les réseaux à prendre en charge, d'après vos utilisateurs.
Types de portefeuilles
Extension de navigateur, application mobile, portefeuille matériel : chaque type a ses parcours et ses limites. Des comptes intégrés à l'application, créés sans portefeuille préalable, sont une autre possibilité : ils déplacent la responsabilité de la garde et de la récupération des clés, et peuvent relever d'obligations réglementaires. Nous étudions avec vous s'ils conviennent, et avec quelles technologies. Si le portefeuille se connecte à votre propre application iOS ou Android, son parcours se conçoit avec le développement de l'application mobile.
Réseaux et changements
Le réseau attendu est indiqué ; un changement de compte ou de réseau est détecté et expliqué, sans perte de contexte. Les échanges entre réseaux relèvent de l'interopérabilité.
Vos services
Comptes applicatifs, droits, journal des actions : la signature authentifie un compte, l'application décide des droits.
Vos contrats
Les demandes de transaction et d'autorisation sont construites à partir des contrats, issus de la conception des smart contracts. La suite du parcours, attente et confirmation, relève de l'expérience d'une application décentralisée.
Notre démarche, de l'inventaire des demandes aux tests sur réseau de test.
Chaque étape répond à une question : que demande-t-on à l'utilisateur, et comment le comprend-il ?
Inventaire des demandes
Ce que l'application devra demander, et pourquoi.
Choix des portefeuilles et des réseaux
D'après vos utilisateurs et vos contrats.
Rédaction des demandes
Textes lisibles, limites, moments.
Intégration
Connexion, signatures, autorisations, erreurs.
Tests sur réseau de test
Refus, changements de compte, portefeuilles absents, autorisations et révocations.
Mise en ligne et évolutions
Vérification et suivi des évolutions des portefeuilles, selon le périmètre convenu.
Questions fréquentes
Ce que l'on nous demande avant d'intégrer un portefeuille à une application.
Quelle différence entre connecter un wallet et signer une transaction ?
Connecter permet à l'application de voir l'adresse publique du compte choisi et le réseau utilisé ; cela ne lui donne aucun droit sur vos actifs. Signer une transaction autorise une opération précise, telle qu'elle est affichée, qui sera ensuite soumise au réseau. Entre les deux, une signature de message peut prouver le contrôle d'un compte sans créer de transaction.
Quelles informations une application obtient-elle quand on connecte son wallet ?
En général, l'adresse publique du compte partagé et le réseau sélectionné, selon le portefeuille et le mécanisme ; les opérations déjà inscrites sur la blockchain pour cette adresse sont, elles, publiques. Elle n'obtient ni les clés, ni le droit de signer ou de déplacer des actifs : chaque action passe par une nouvelle demande, que l'utilisateur peut refuser.
Peut-on authentifier un utilisateur avec son wallet ?
Oui, lorsque le mécanisme retenu le permet : l'utilisateur signe un message lisible, propre au site et à la connexion, que l'application vérifie. Cette signature prouve le contrôle d'un compte ; elle ne dit rien de l'identité civile de la personne, et les droits dans l'application restent gérés par l'application.
Une autorisation donnée à un smart contract peut-elle rester active ?
Oui, selon le standard utilisé : l'autorisation reste valable jusqu'à sa modification ou sa révocation, même après la déconnexion du site. La réduire ou la retirer demande une nouvelle transaction ; rien ne la révoque automatiquement. C'est pourquoi nous limitons les autorisations demandées et prévoyons, dans l'application, où les retrouver.
Que se passe-t-il lorsqu'un utilisateur refuse une signature ?
Rien n'est signé, rien n'est envoyé, aucuns frais ne sont dus. L'application l'explique sans message d'erreur et propose la suite : une autre fonction, ou la même demande plus tard. Le suivi des transactions envoyées relève de l'expérience d'une application décentralisée.
Comment choisir les wallets et réseaux à intégrer ?
À partir de vos utilisateurs, de vos contrats et des réseaux retenus pour le projet. Aucune intégration n'est compatible avec tous les portefeuilles : nous définissons une liste prise en charge, testée sur réseau de test, et le comportement prévu pour les autres. Le choix du réseau lui-même relève de l'architecture blockchain.
Avant d'intégrer un portefeuille, nous cadrons chaque demande, pour une intégration Web3 qui inspire confiance.
Ce que nous examinons avec vous · huit points
- Utilisateurs visésQui se connecte, et avec quelle habitude des portefeuilles ?à cadrer
- Types de portefeuillesExtension de navigateur, application mobile, portefeuille matériel, compte intégré : lesquels prendre en charge ?à cadrer
- Réseaux concernésSur quels réseaux l'application agit-elle, et que faire si l'utilisateur en change ?à cadrer
- Connexion et identitéUne connexion suffit-elle, ou faut-il authentifier par signature ?à cadrer
- Messages et transactionsQue signe-t-on, à quel moment, avec quel texte lisible ?à cadrer
- Permissions et autorisationsQuelles autorisations demander, avec quelle limite, et comment les réviser ?à cadrer
- Erreurs et refusQue dit l'application après un refus, un changement de compte, un portefeuille absent ?à cadrer
- Sécurité et évolutionsQui vérifie les demandes, et comment l'intégration suit-elle l'évolution des portefeuilles ?à cadrer
Ce que nous ne faisons pas sans vous
- décider des permissions demandées à vos utilisateurs
- imposer un mode de conservation des clés privées
- supposer qu'un type de portefeuille convient à tous vos utilisateurs
Une bonne intégration commence comme une bonne demande : claire, limitée, compréhensible.
Le cadrage définit les demandes, les informations présentées, les décisions laissées à l'utilisateur et les contraintes de l'intégration, avant la première ligne de code. Il sert de base au développement, aux tests sur réseau de test et aux échanges avec vos équipes.
Étudions votre intégration walletUn premier échange suffit pour situer votre projet : décrivez vos utilisateurs et ce qu'ils devront signer.