L'enjeu : la conversion, et un écart dans Medusa
Medusa s'est imposé comme le moteur e-commerce open source de référence pour les boutiques sur mesure, et son intérêt business est simple à résumer : le code vous appartient, aucune commission ne s'ajoute sur vos ventes, et la plateforme se plie à votre métier plutôt que l'inverse. On a détaillé ce comparatif dans notre article Shopify vs Medusa.
Sur l'authentification en revanche, Medusa v2 s'en tient volontairement au minimum : la connexion par email et mot de passe. Pas de connexion Google ou Apple, pas de liens magiques envoyés par email qui connectent en un clic, pas de passkeys par empreinte ou reconnaissance faciale. Ce n'est pas un défaut de conception, Medusa se concentre sur le commerce et laisse l'authentification avancée à des outils spécialisés. Mais l'écart est là, et il se paie deux fois : en comptes non créés côté boutique, et en développement sur mesure côté projet, à refaire à chaque fois, dans l'un des domaines où le code artisanal est le plus risqué.
Ce qu'on a construit
Pour combler cet écart, on a développé un plugin open source qui relie Medusa v2 à Better Auth, la référence de l'authentification dans l'écosystème TypeScript. Il est né d'un vrai projet e-commerce qu'on prépare pour la production, il est publié sous licence MIT sur npm, référencé dans l'écosystème de plugins Medusa, et d'autres développeurs l'ont déjà adopté dans leurs propres boutiques.
Concrètement, le plugin apporte à n'importe quelle boutique Medusa v2 :
- La connexion sociale via huit fournisseurs, Google, Apple, Facebook, Microsoft, Discord, TikTok, X et GitHub, activables chacun avec deux variables d'environnement, boutons et icônes inclus.
- Les liens magiques, les passkeys et la double authentification, via l'écosystème de plugins Better Auth.
- Un widget de connexion pour le tableau de bord d'administration, avec les boutons sociaux au-dessus du formulaire classique.
- Une commande de migration pour les déploiements en production, idempotente, à lancer à chaque mise en ligne sans risque.
- La normalisation des emails clients, pour rendre les comptes en double impossibles.
Et surtout, il apporte tout ça sans rien casser. C'est le choix d'architecture qui a tout structuré.
Un pont, pas un remplacement
Le plugin ne remplace pas l'authentification de Medusa, il la complète. Better Auth tourne à l'intérieur du serveur Medusa, avec ses tables rangées dans la même base Postgres sous le préfixe ba_. Il gère le flux de connexion moderne, puis un provider d'authentification Medusa dédié valide la session et laisse Medusa émettre son propre jeton natif, celui d'un client ou celui d'un administrateur. Le storefront, l'admin et les routes protégées continuent de fonctionner avec l'authentification standard de Medusa, sans une ligne modifiée. Le modèle natif reste la source de vérité.
Autre conséquence de ce choix : aucun coût permanent en performance. Better Auth n'intervient qu'au moment du login. Ensuite, les clients naviguent avec leur jeton Medusa natif, et le plugin sort du chemin.
Un back office verrouillé
Une connexion sociale ne peut jamais créer un compte administrateur. Une identité Google ne peut être rattachée qu'à un administrateur déjà existant, invité normalement dans Medusa, et uniquement si le fournisseur a vérifié l'adresse email. Sans cette règle stricte, un login social mal configuré deviendrait une porte d'entrée sur les coulisses de la boutique. On l'a rendue non négociable.
Des comptes clients en double impossibles
Sans garde-fou, un client qui écrit son email avec une majuscule un jour et en minuscules le lendemain se retrouve avec deux comptes distincts : historique de commandes éclaté, confusion au support, statistiques faussées. Le plugin normalise les emails à la source, tout en respectant la façon dont Medusa sépare les commandes passées en invité des comptes clients. Aucune fusion automatique sur la seule base d'un email : le rattachement passe par le flux de transfert de commande de Medusa, qui exige une preuve de possession de la boîte mail.
Pensé pour la production, documenté avec ses limites
La documentation du plugin couvre ce qui casse habituellement une mise en ligne : la limitation de débit à passer sur un stockage partagé derrière un load balancer, les cookies à configurer entre le domaine de la boutique et celui de l'API, le nettoyage périodique des sessions expirées, la surveillance des connexions Postgres. Elle assume aussi les limites connues, versions vérifiées, cas particuliers selon le gestionnaire de paquets, points encore en chantier. Un composant d'authentification qui cache ses limites est un composant auquel on ne peut pas faire confiance.
Ce que ça change pour un projet e-commerce
L'équation se lit à deux niveaux. Medusa d'abord : une boutique dont vous possédez le code, sans commission prélevée sur vos ventes, et qui reproduit vos règles métier au lieu de vous imposer les siennes. Ce plugin ensuite, qui lève ce qui était l'une des vraies réserves face aux plateformes clés en main : la connexion moderne, celle qui réduit la friction à l'inscription et protège la conversion, n'est plus un chantier à ouvrir sur votre budget. C'est une brique existante à poser, dont les pièges de mise en production sont déjà identifiés et traités. L'écart de confort avec une solution propriétaire se referme, les avantages structurels de l'open source restent.
Chez Nualt, c'est notre façon de travailler : construire nos boutiques sur Medusa, et quand une pièce manque, la fabriquer proprement et la rendre à l'écosystème plutôt que de la garder dans un tiroir. Que d'autres développeurs aient lu le code et choisi de l'installer est la validation la plus honnête qui soit.
