- Les tentatives pour faire de Web Monetization, qui diffuse automatiquement des micro-paiements dans le navigateur, une norme du Web et une fonctionnalité intégrée aux navigateurs plutôt qu’une extension se poursuivent, mais les barrières à l’usage restent élevées
- Par le passé, Coil a relié une extension de navigateur à un portefeuille en ligne pour concrétiser cette idée au plus près de la réalité, en envoyant automatiquement des micro-paiements aux sites portant une balise
<link rel="monetization">
- Après Coil, une dynamique similaire s’est poursuivie avec la combinaison de l’extension Interledger et des portefeuilles GateHub·Chimoney, et le fait que des expérimentations natives de Web Monetization au niveau du code Chromium soient en cours semble constituer un progrès technique
- Mais dans l’usage réel, des problèmes critiques d’UX et de restrictions régionales apparaissent, comme la confusion sur le format d’adresse de portefeuille chez GateHub, l’impossibilité de déposer des USD, l’absence de prise en charge des États-Unis et du Royaume-Uni par Interledger, ou encore l’absence de support Web chez Chimoney (application native uniquement)
- L’article estime qu’avant de poursuivre les expérimentations développeur, la standardisation et l’intégration aux navigateurs, il faut d’abord simplifier les étapes clés comme le choix du portefeuille, son alimentation et la configuration de l’adresse jusqu’à un niveau « ultra simple et ultra fiable » comparable à Apple Pay, et considère qu’à ce stade l’objectif reste encore lointain
Le concept de Web Monetization comme standard du Web
- Web Monetization vise un modèle de revenus où le navigateur connecte automatiquement un portefeuille en ligne aux sites Web pour streamer des micro-paiements
- Le site expose via une balise
<meta> ou <link> une clé publique (identifiant du portefeuille) pointant vers son portefeuille en ligne
- L’utilisateur dépose une certaine somme dans l’extension du navigateur, qui distribue automatiquement l’argent aux sites visités contenant cette balise
- L’auteur explique avoir été séduit autrefois par cette idée via Coil, appréciant l’expérience consistant à laisser couler un micro-soutien lors d’une simple visite, avec le sentiment de dire : « merci d’avoir créé ce site »
- Des fonctions de contrôle de base, comme une liste noire, existaient aussi ; sans être exactement équivalent à Brave Rewards, cela fonctionnait comme un système de récompense de concept proche
- Mais ce que l’auteur préférait dans Coil n’était pas tant le business lui-même que le fait d’entrevoir des étapes concrètes pour en faire un standard du Web et une fonction native du navigateur
- Si cela devenait une fonction de base fonctionnant dans tous les navigateurs sans extension, l’expérience de paiement sur le Web dans son ensemble pourrait être transformée
Le potentiel des micro-paiements intégrés au navigateur
- Quatre avantages sont attendus si Web Monetization est intégré nativement au navigateur
- L’usage pourrait devenir extrêmement simple
- La sécurité pourrait être fortement améliorée
- Des modèles d’abonnement et de premium avec anonymat renforcé deviendraient possibles
- Cela pourrait contribuer à la normalisation des paiements autres que par carte de crédit
- Du point de vue de l’utilisabilité, l’auteur estime que cela pourrait raccourcir le parcours de paiement autant, voire davantage, qu’Apple Pay
- De la même manière qu’Apple Pay a réduit de plus de moitié les étapes du paiement, un portefeuille natif standardisé dans le navigateur pourrait offrir une expérience similaire sur toutes les plateformes
- Côté sécurité, l’intérêt serait de supprimer le schéma où l’on saisit directement son numéro de carte sur les sites Web
- Au lieu d’une architecture actuelle où il faut « simplement faire confiance » à la manière dont les sites transmettent et stockent ces données, l’auteur préfère un modèle où le navigateur gère lui-même les informations de paiement
- Sur le plan de l’anonymat, il deviendrait possible pour un site de proposer un abonnement ou des fonctions premium sans jamais connaître l’e-mail de l’utilisateur
- Sans collecte d’adresse e-mail, un site pourrait proposer la suppression de la publicité, un compte Pro ou des téléchargements de meilleure qualité ; l’auteur y voit la possibilité d’une expérience payante sans spam
- Pour les moyens de paiement, un portefeuille en ligne peut relier compte bancaire, carte de crédit, cryptomonnaies et autres sources, ce qui permettrait de casser l’hypothèse selon laquelle « la base, c’est la carte bancaire »
- Quel que soit la devise ou le moyen utilisé, le Web pourrait fonctionner avec une couche d’abstraction où il suffit de savoir « qu’il y a de l’argent dans le portefeuille »
Après Coil : extension Interledger et code natif dans Chromium
- Après l’arrêt de Coil, le relais a été transmis à Interledger, et la dynamique consistant à continuer de pousser Web Monetization sur cette base se poursuit
- À la place de l’extension Coil, c’est désormais l’extension de navigateur Interledger qui est proposée ; elle vérifie si la page contient un portefeuille de monetization et traite automatiquement le paiement
- Elle utilise un format comme
<link rel="monetization" href="https://ilp.gatehub.net/150644339/usd" />, et l’extension reconnaît le portefeuille du site à partir de ce lien
- Elle est conçue pour faire transiter en continu une monnaie virtuelle depuis le portefeuille de l’utilisateur connecté à l’extension vers le portefeuille Web Monetization ciblé par ce lien
- Le point le plus encourageant dans les explications de Thomas Steiner est que du code pour une Web Monetization native existe déjà dans Chromium
- Ce code a été implémenté par Igalia et financé par l’Interledger Foundation, et l’on en est actuellement au stade de l’attente d’un partage des résultats de l’expérimentation
- Le simple fait que cela soit allé jusqu’au code du moteur de navigateur montre que Web Monetization a dépassé le stade de la simple idée pour progresser, dans une certaine mesure, comme candidat à la standardisation
UX du portefeuille et restrictions régionales : retour d’expérience avec GateHub, Interledger et Chimoney
- En essayant directement les trois portefeuilles pris en charge par l’extension Interledger (Interledger, GateHub, Chimoney), l’auteur met en lumière les problèmes de la phase actuelle
- En s’inspirant de l’exemple utilisé par Thomas, il a d’abord choisi GateHub, qui prend en charge l’USD
- Le processus de vérification du compte a été un peu laborieux, au point d’exiger plusieurs renvois, mais la création du compte a finalement réussi
- Problème n°1 : chez GateHub, le format d’adresse de portefeuille affiché n’est pas compatible avec l’extension du navigateur
- GateHub fournit un simple nombre comme « Wallet Address », mais l’extension ne le reconnaît pas comme adresse valide
- En pratique, l’utilisateur se retrouve donc dans une situation où il a bien un portefeuille, mais ne peut pas le connecter à l’extension, faute de guide clair sur le format d’adresse
- Problème n°2 : il n’existe aucun moyen d’alimenter un portefeuille en USD dans GateHub
- Même en essayant les différentes options de dépôt visibles à l’écran, toutes renvoyaient un message d’impossibilité, rendant impossible le dépôt effectif de dollars
- Quelqu’un possédant déjà des cryptomonnaies ailleurs pourrait peut-être contourner le problème, mais pour un utilisateur lambda, cela donne inévitablement l’impression d’un portefeuille inutilisable en pratique
- Les autres portefeuilles montrent des limites comparables
- Le portefeuille Interledger affichait un message indiquant que les États-Unis n’étaient pas pris en charge, ce qui empêchait tout usage réel
- Via un autre lien, l’auteur a aussi trouvé la mention selon laquelle il n’existe pas vraiment de fournisseur de portefeuille adapté au Royaume-Uni, si bien que les utilisateurs britanniques disposent eux aussi de très peu d’options
- Chimoney, limité à des applications natives comme iOS, n’a pas paru attrayant à l’auteur, qui accorde de l’importance à une approche et une ergonomie centrées sur le Web
- Au final, dans l’état actuel, l’expérience réelle de Web Monetization est « pour l’instant proche d’un échec total »
- Thomas a bien réussi à le faire fonctionner, donc ce n’est pas absolument impossible, mais pour un utilisateur ordinaire, le parcours reste bien trop ardu
Les défis restants avant la standardisation et l’intégration au navigateur
- Pour que Web Monetization s’impose réellement, il faut avant même les développeurs et la standardisation, lisser l’expérience utilisateur à un degré extrême
- L’auteur estime que la création du portefeuille, la configuration de l’adresse et son alimentation doivent atteindre un niveau « utilisable immédiatement dès l’installation initiale » comparable à Apple Pay
- Une fois ce niveau atteint, il serait naturel que les développeurs construisent dessus des expériences et services intéressants, puis que la standardisation et l’intégration au navigateur suivent ensuite
- Aujourd’hui, cet ordre n’est pas correctement en place, si bien que les utilisateurs butent sans cesse dès les étapes de base, entre disponibilité des portefeuilles, régulations locales, format d’adresse et support du Web
- L’auteur désigne en particulier comme obstacle majeur le fait que, sur de grands marchés comme les États-Unis et le Royaume-Uni, il y ait très peu de portefeuilles réellement utilisables, ou seulement de manière limitée
- C’est pourquoi, malgré l’avancée représentée par l’intégration de code natif dans Chromium, l’auteur estime qu’on n’a pas encore le sentiment que Web Monetization soit proche en tant que fonctionnalité réellement intégrée au navigateur
- Il insiste de nouveau sur le fait qu’avant les documents de standardisation et les flags de navigateur, il faut d’abord une « voie aboutie que n’importe qui peut utiliser facilement »
Précisions et alternatives évoquées dans les commentaires
- Dans les commentaires, Thomas Steiner a apporté des explications supplémentaires sur le format d’adresse de portefeuille et le parcours de dépôt liés à GateHub
- L’adresse du portefeuille doit être au format
https://ilp.gatehub.net/숫자/통화코드, et dans le cas de l’auteur, il a donné l’exemple concret de https://ilp.gatehub.net/150644339/usd comme adresse correcte
- Il souligne que le site Web de GateHub affiche correctement ce format, alors que l’application ne donne que le nombre, ce qui crée de la confusion
- Concernant le problème de dépôt, il précise que les moyens d’alimentation disponibles varient selon la région
- De son côté, en Europe, il peut alimenter son portefeuille par virement bancaire, Google Pay et d’autres moyens ; en EUR, il existe aussi diverses options comme la carte ou SEPA
- Dans l’UE, GateHub basé sur un portefeuille Interledger constitue une option réellement utilisable, et il est même possible d’obtenir une MasterCard physique, même si cela n’aide pas directement les utilisateurs américains
- Un autre commentaire souligne que les implémentations actuelles de Web Monetization sont centralisées, et que les transactions peuvent donc être limitées par les réglementations KYC/AML
- Comme alternative, il ne propose pas l’ensemble du champ des cryptomonnaies, mais la combinaison de Bitcoin et du Lightning Network, en évoquant la possibilité d’une infrastructure de paiement totalement décentralisée et auto-hébergée
- Il présente les spécifications et bibliothèques WebLN pour utiliser Lightning sur le Web, en citant comme exemples d’usage le login anonyme, les micro-paiements ou l’auto-hébergement
- Dans l’ensemble, les commentaires montrent que la disponibilité des portefeuilles, la régulation et les problèmes de centralisation constituent la partie la plus délicate de l’écosystème Web Monetization, et que des discussions sur des alternatives régionales et techniques sont déjà en cours
Aucun commentaire pour le moment.