Alternatives à Clerk pour les fondateurs indie qui refusent de payer l'auth au MAU

Pourquoi les fondateurs cherchent des alternatives à Clerk

Clerk a cloué l'expérience développeur. On installe le package, on wrappe son app dans <ClerkProvider>, on drop <SignIn /> et <UserButton />, et on a de l'auth. Social login, email/password, MFA, gestion des organisations — ça fonctionne out of the box avec Next.js, React et d'autres frameworks. Pour shipper un MVP rapidement, Clerk est difficile à battre.

Les frictions commencent quand les chiffres grimpent.

La tarification au MAU scale contre vous. Clerk facture 0,02 $ par utilisateur actif mensuel au-delà de 10 000 sur le plan Pro. Ca semble dérisoire jusqu'à ce qu'on sorte la calculette. À 25 000 MAU, la facture d'auth est de 325 $/mois. À 50 000 MAU, c'est 825 $/mois. À 100 000 MAU, on paie 1 825 $/mois juste pour l'authentification. Pour un SaaS bootstrapé où une bonne partie de ces MAU sont peut-être sur un plan gratuit et ne vous rapportent rien, c'est un vrai problème pour vos unit economics.

Comparez ça à Supabase Auth (gratuit pour 50 000 MAU), Firebase Auth (gratuit pour l'auth email/password illimitée), ou Lucia (gratuit pour toujours parce que c'est une librairie open source). L'écart de prix est énorme à grande échelle.

L'approche centrée composants crée du couplage. Les composants <SignIn />, <SignUp />, <UserProfile /> et <UserButton /> de Clerk sont pratiques, mais ils embarquent l'UI de Clerk dans votre app. Envie de personnaliser le flow de login au-delà de ce que l'API d'apparence de Clerk permet ? On se bat contre l'abstraction. Envie de changer de provider d'auth plus tard ? On arrache des composants UI, pas juste un swap de client API.

Le vendor lock-in est bien réel. Les données utilisateurs — profils, hash de mots de passe, connexions OAuth, appartenances aux organisations — vivent sur l'infrastructure de Clerk. Les hash de mots de passe ne sont pas exportables. Si on décide de partir, les utilisateurs doivent réinitialiser leur mot de passe. Ce n'est pas une migration en douceur.

Ces compromis sont acceptables pour beaucoup de projets. Mais si on construit un produit qu'on prévoit de faire tourner pendant des années et de scaler à des dizaines de milliers d'utilisateurs, ça vaut le coup de comprendre ce qui existe d'autre.

Comment on a évalué ces alternatives

On a examiné chaque option à travers le prisme d'un développeur solo ou d'une petite équipe qui construit un SaaS :

• Effort d'intégration : Combien de temps entre zéro et une auth fonctionnelle dans une app Next.js ?
• Pricing à grande échelle : Combien coûte l'auth à 1 000, 10 000 et 50 000 MAU ?
• Personnalisation : Peut-on contrôler totalement l'UI de login et les flows d'auth ?
• Portabilité des données : Si on part, à quel point la migration est douloureuse ?
• Prêt pour la production : C'est battle-tested ou encore brut de décoffrage ?

L'auth, c'est le genre de truc qu'on n'a pas envie de reconstruire. Choisir la bonne solution tôt épargne des semaines de galère de migration plus tard.

Analyse détaillée : ce que chaque alternative fait de mieux

Auth0 — le mastodonte enterprise

Auth0 (désormais propriété d'Okta) est la plateforme d'identité la plus établie de cette liste. Elle supporte tous les flows d'auth imaginables — email/password, social login, magic links passwordless, SAML SSO pour les clients enterprise, tokens machine-to-machine pour les API, et authentification multi-facteurs avec plusieurs méthodes.

La richesse fonctionnelle est à la fois la force et la malédiction d'Auth0. Le dashboard est massif. La documentation couvre chaque cas limite mais devient écrasante quand on veut juste ajouter un login Google à son app Next.js. L'écosystème de SDK est complet, mais la surface de configuration est large. Pour un dev solo, Auth0 donne l'impression d'amener un semi-remorque sur une piste de karting.

Le plan gratuit est faussement généreux — 25 000 MAU sans frais. Mais il limite à 2 connexions sociales (par exemple Google et GitHub — envie d'Apple aussi ? Sortez le portefeuille), pas de domaines personnalisés, des action triggers limités et pas de support des organisations. Dès qu'on a besoin de fonctionnalités au-delà du social login de base, on saute au plan Essentials à 35 $/mois ou Professional à 240 $/mois.

Là où Auth0 brille vraiment, c'est la vente enterprise. Si votre SaaS doit proposer du SAML SSO pour que les clients corporates utilisent leur identity provider Okta ou Azure AD, Auth0 gère ça nativement. Clerk le supporte aussi sur leur plan Enterprise, mais Auth0 a une décennie d'expérience en identité enterprise.

La DX pour les cas simples s'est améliorée mais reste en retrait par rapport à Clerk. L'Universal Login d'Auth0 (page de login hébergée) fonctionne bien mais est moins customisable que les composants embarqués de Clerk. Le SDK React est fonctionnel mais pas aussi élégant. Le setup prend plus de temps, la configuration a plus de pièces mobiles.

Quand choisir Auth0 : Votre SaaS vend à des entreprises qui exigent le SAML SSO, la conformité SOC2 ou des fonctionnalités d'identité avancées. Pour la plupart des projets indie, Auth0 est bien plus que nécessaire.

Supabase Auth — l'auth qui vient gratis avec votre base de données

Si on utilise déjà Supabase pour sa base de données, leur module d'auth est le choix évident. Il est inclus dans chaque plan Supabase sans surcoût, supporte 50 000 MAU sur le plan gratuit, et s'intègre en profondeur avec les policies Postgres Row Level Security pour le contrôle d'accès aux données.

Supabase Auth supporte email/password, magic links, OTP par téléphone et plus de 20 providers OAuth. L'état de l'auth se lie directement à la base de données via les policies RLS — on peut écrire du SQL comme auth.uid() = user_id pour restreindre l'accès aux lignes. Pas besoin d'une couche d'autorisation séparée. Pour les apps data-heavy où auth et accès aux données sont intimement liés, cette intégration est vraiment puissante.

Le compromis par rapport à Clerk, c'est l'UI. Supabase fournit @supabase/auth-ui-react avec des composants de login pré-construits, mais ils sont basiques. Ils font le job mais n'ont pas le côté léché des composants Clerk. On finira probablement par construire des formulaires de login custom, ce qui signifie plus de code mais aussi plus de contrôle sur l'expérience.

L'argument pricing, c'est là que Supabase Auth gagne pour les fondateurs indie. Sur le plan gratuit, on a 50 000 MAU. Sur le plan Pro à 25 $/mois, il n'y a toujours aucun frais au MAU pour l'auth — on paie pour la base de données et le stockage, et l'auth est incluse. Comparez ça aux 825 $/mois de Clerk à 50 000 MAU. Cette différence de 800 $/mois va directement allonger votre runway.

Le point négatif, c'est que Supabase Auth est fortement couplé à l'écosystème Supabase. L'utiliser en standalone sans la base Supabase est techniquement possible mais bancal. Si on veut juste de l'auth et rien d'autre, Supabase Auth n'est pas le bon choix.

Quand choisir Supabase Auth : On est déjà sur Supabase ou on prévoit de l'utiliser pour sa base de données. L'auth est essentiellement gratuite et l'intégration Postgres est excellente.

Firebase Auth — de l'auth gratuite et illimitée qui scale vraiment

Firebase Auth est le choix qu'on sous-estime dans cette liste pour une raison simple : l'authentification email/password et téléphone est gratuite à n'importe quelle échelle. Pas "gratuit jusqu'à 10 000 utilisateurs." Gratuit. Point. Google gère l'infrastructure, le scaling et la sécurité, et on ne paie pas par utilisateur.

Le hic, c'est que la "Firebase Auth gratuite" couvre les bases — email/password, téléphone, auth anonyme et une poignée de providers sociaux. Si on a besoin de MFA, de blocking functions (logique custom pendant l'auth), de SAML SSO ou de plus de providers sociaux, on upgrade vers Firebase Authentication avec Identity Platform. Ca ajoute 0,0055 $ par MAU au-delà de 50 000 — toujours drastiquement moins cher que les 0,02 $ par MAU de Clerk.

Pour les développeurs mobile, Firebase Auth est sans doute la meilleure option de cette liste. Les SDK Flutter, iOS et Android sont matures, gèrent les scénarios offline avec élégance et s'intègrent parfaitement au reste de Firebase. Le SDK web est fonctionnel mais moins ergonomique que les composants React de Clerk ou Auth.js dans un projet Next.js.

La DX pour Next.js est le point faible. Firebase Auth a été conçu mobile-first, et ça se voit. L'auth côté serveur en Next.js nécessite le Firebase Admin SDK et la gestion manuelle des session cookies. Il n'y a pas de composants React pré-construits comparables au <SignIn /> de Clerk. On écrit ses propres formulaires et on gère l'état de l'auth soi-même.

Le vendor lock-in s'applique ici aussi. Les tokens Firebase Auth sont spécifiques à Firebase. Migrer signifie ré-implémenter l'auth entièrement. Mais au moins Firebase est soutenu par Google — le risque que le service disparaisse est faible.

Quand choisir Firebase Auth : On construit une app mobile, on a besoin d'auth pas chère à grande échelle, ou on veut de l'auth email/password gratuite et illimitée sans se soucier des limites de MAU.

Lucia Auth — posséder son auth de A à Z

Lucia adopte une approche fondamentalement différente. Ce n'est pas un service. Ce n'est pas une plateforme. C'est une librairie TypeScript qui implémente l'authentification session-based. On l'installe, on configure l'adaptateur de base de données, et on construit les flows d'auth soi-même.

Concrètement, ça veut dire qu'on écrit le formulaire de login, le formulaire d'inscription, le flow de vérification email, le flow de reset de mot de passe et le handler de callback OAuth. Lucia fournit la gestion de sessions, le handling des cookies et l'abstraction base de données. La logique d'auth vit dans le codebase, les sessions sont stockées dans la base de données, et aucun service tiers n'est impliqué.

Pour les devs qui maîtrisent les fondamentaux de la sécurité web — hashing de mots de passe, protection CSRF, rate limiting, stockage sécurisé de sessions — Lucia est libérateur. On contrôle chaque aspect de l'expérience d'auth. L'UI de login correspond parfaitement au design system parce que c'est nous qui l'avons construite. Pas de mises à jour de SDK qui cassent le flow d'auth. Pas de vendor qui peut poser problème.

Le coût est zéro. Pas "plan gratuit" zéro où on finit par payer. Réellement zéro. Lucia est open source. Les coûts d'auth se résument au coût de la base de données, qui pour la plupart des projets indie est effectivement nul.

Le vrai coût, c'est le temps. Construire la vérification email, le reset de mot de passe, l'intégration OAuth et le MFA from scratch prend des jours ou des semaines selon les besoins. Clerk donne tout ça en un après-midi. Ce trade-off de temps compte quand on essaie de shipper vite et de valider une idée.

Lucia est aussi une librairie maintenue par un petit nombre de développeurs. La communauté est active, mais elle n'est pas soutenue par une entreprise avec une équipe de support. Si on tombe sur un edge case, on lit le code source et les issues GitHub, on ne file pas un ticket de support.

Quand choisir Lucia : On veut zéro dépendance fournisseur, zéro coût récurrent et un contrôle total sur l'implémentation de l'auth. Idéal pour les développeurs à l'aise avec la sécurité web.

Auth.js (NextAuth.js) — le standard communautaire pour Next.js

Auth.js — encore largement connu sous le nom NextAuth.js — est la solution d'auth open source la plus populaire de l'écosystème Next.js. Elle se concentre sur l'OAuth et l'authentification session-based, rendant trivial l'ajout d'un "Se connecter avec Google" ou "Se connecter avec GitHub" à son app.

Le setup pour l'OAuth est remarquablement simple. On configure ses providers, on ajoute la route API, on wrappe son app, et on a du social login. Auth.js vient avec 80+ providers intégrés, donc que les utilisateurs se connectent via Google, GitHub, Discord, Slack ou des dizaines d'autres, il y a un provider prêt à l'emploi.

Auth.js s'intègre bien avec l'App Router Next.js, le middleware et les server components. On peut protéger des routes, accéder aux données de session côté serveur et vérifier l'état de l'auth dans le middleware. Le modèle mental est simple — les sessions sont stockées côté serveur (en base via des adaptateurs ou en JWT), et on y accède à travers le framework.

Les aspérités se trouvent dans la configuration. Auth.js a beaucoup d'options, et les interactions entre elles ne sont pas toujours évidentes. JWT vs sessions en base de données, fonctions de callback, configuration des adaptateurs et quirks spécifiques aux providers peuvent bouffer du temps. La transition de NextAuth.js v4 à v5 (Auth.js) a introduit des breaking changes qui ont frustré la communauté. La documentation s'améliore mais a encore des trous pour les cas d'usage avancés.

Comme Lucia, Auth.js ne fournit pas d'UI pré-construite. On construit les formulaires de login soi-même. Ca donne du contrôle sur le design mais signifie plus de code comparé aux composants drop-in de Clerk.

Pour le cas d'usage courant "j'ai besoin de social login dans mon app Next.js et je ne veux pas payer", Auth.js est le choix par défaut. C'est gratuit, open source, et c'est la plus grande communauté de l'espace auth Next.js.

Quand choisir Auth.js : On a besoin de social login OAuth dans une app Next.js et on veut une solution communautaire gratuite et bien supportée.

Kinde — le concurrent direct de Clerk avec un pricing plus doux

Kinde est l'alternative la plus directe à Clerk de cette liste. DX similaire : composants pré-construits, pages de login hébergées, dashboard de gestion utilisateurs et bonne intégration Next.js. Mais avec un modèle de tarification plus indulgent à grande échelle.

Le plan gratuit couvre 10 500 MAU — légèrement plus que les 10 000 de Clerk. Le plan Pro est à 25 $/mois. Kinde inclut aussi des feature flags dans chaque plan, ce qui est un bonus appréciable — pas besoin d'un service séparé comme LaunchDarkly ou PostHog pour du feature gating basique.

Les flows d'auth supportent email/password, social login, passwordless, MFA et gestion des organisations pour le SaaS B2B. La DX est soignée — pas encore tout à fait au niveau Clerk, mais ça s'en rapproche et ça s'améliore vite.

Là où Kinde se distingue, c'est dans son approche des fonctionnalités B2B. La gestion des organisations, le contrôle d'accès basé sur les rôles et l'auth multi-tenant sont disponibles plus tôt dans les tiers de pricing comparé à Clerk, où certaines de ces fonctionnalités sont verrouillées derrière des plans supérieurs.

Le point faible, c'est la maturité de l'écosystème. Kinde est plus récent que Clerk, ce qui signifie moins de tutoriels communautaires, moins d'exemples d'intégrations et un pool plus restreint de développeurs qui ont rencontré et résolu des problèmes spécifiques. La documentation est correcte mais pas aussi complète. Si on tombe sur un edge case inhabituel, il n'y aura peut-être pas de réponse Stack Overflow qui attend.

Kinde fait aussi encore évoluer son produit. Les features sortent vite, ce qui est bien, mais ça implique aussi des breaking changes occasionnels et des étapes de migration. Pour une app en production, c'est un compromis à peser.

Quand choisir Kinde : On veut une expérience d'auth managée similaire à Clerk mais avec un meilleur pricing, des feature flags inclus et un accès anticipé aux fonctionnalités B2B.

Comparatif des coûts : l'auth à grande échelle

Voici ce que l'authentification coûte à différentes échelles, en se concentrant sur les chiffres qui comptent pour un SaaS bootstrapé :

À 1 000 MAU (SaaS early-stage) :

Toutes les options de cette liste sont gratuites à cette échelle. Clerk Free, Auth0 Free, Supabase Free, Firebase Free, Kinde Free, Lucia, Auth.js — zéro euro. On choisit sur la DX, pas sur le prix.

À 10 000 MAU (traction en cours) :

Toujours gratuit sur la plupart des plateformes. Clerk Free couvre jusqu'à 10 000. Auth0 Free couvre 25 000. Supabase couvre 50 000. Firebase est illimité. Kinde couvre 10 500. Lucia et Auth.js sont toujours gratuits. Le seul déclencheur de coût à cette échelle, c'est si on a besoin des fonctionnalités Clerk Pro (domaines personnalisés, allowlists), qui démarrent à 25 $/mois.

À 50 000 MAU (un vrai business) :

C'est là que les tarifs divergent radicalement. Clerk Pro : environ 825 $/mois. Auth0 : dépend du plan, mais probablement 240-500+ $/mois. Supabase : 25 $/mois (auth incluse). Firebase Auth : gratuit pour le basique, environ 220 $/mois sur Identity Platform. Kinde Pro : 25 $/mois + dépassement. Lucia et Auth.js : 0 $.

Ces 800 $/mois de différence entre Clerk et Supabase Auth paient beaucoup d'infrastructure — ou vont directement raccourcir le chemin vers votre seuil de rentabilité.

Le spectre build-vs-buy pour l'auth

L'auth n'est pas un choix binaire entre "utiliser un service" et "construire from scratch." C'est un spectre :

1. Service managé complet (Clerk, Kinde, Auth0) : Auth drop-in avec UI pré-construite, gestion utilisateurs et infrastructure hébergée. Le plus rapide à implémenter, le plus cher à grande échelle, le plus de vendor lock-in.

2. Auth incluse dans le backend (Supabase Auth, Firebase Auth) : Auth bundlée avec la plateforme backend. Bon rapport qualité-prix si on utilise déjà la plateforme. Moins de flexibilité en standalone.

3. Librairie intégrée au framework (Auth.js) : Librairie open source conçue pour le framework. Gratuite, supportée par la communauté, gère bien l'OAuth. On construit l'UI, elle gère la logique.

4. Librairie d'auth bas niveau (Lucia) : Abstraction minimale sur les sessions et la base de données. Contrôle maximum, responsabilité maximum. On construit tout, on possède tout.

Où on se place dépend des priorités. Si le time to value compte le plus et qu'on a besoin de valider vite, les services managés gagnent. Si le coût long terme et la portabilité comptent davantage, les librairies open source sont de meilleurs paris.

Pour la plupart des fondateurs indie, le sweet spot est quelque part au milieu. Auth.js ou Lucia pour les projets où on a le temps. Supabase Auth ou Kinde pour les projets où on veut de l'auth managée sans le pricing de Clerk. Clerk lui-même pour les projets où la DX léchée justifie le coût au MAU.

Quand rester sur Clerk

Clerk reste le bon choix dans des situations spécifiques :

• On est en pré-revenu et sous 10 000 utilisateurs. Le plan gratuit couvre tout, et la DX est la meilleure du marché.
• SaaS B2B avec gestion des organisations. Les fonctionnalités multi-tenant de Clerk sont matures et bien documentées.
• On privilégie la vitesse de livraison avant tout. Les composants pré-construits font gagner des jours de développement par rapport au fait de coder l'auth soi-même.
• Le revenu par utilisateur est assez élevé. Si chaque utilisateur paie 50+ $/mois, les 0,02 $ par MAU de Clerk sont une erreur d'arrondi.
• Next.js est le framework et on veut l'intégration la plus fluide. Le SDK Next.js de Clerk est l'intégration d'auth la plus soignée pour ce framework.

La tarification au MAU n'est un problème que quand les MAU dépassent significativement les utilisateurs payants. Si on a un bon taux de conversion et que la plupart des utilisateurs actifs sont des clients payants, le coût de Clerk est proportionnel au revenu. Si on a un large plan gratuit avec des milliers d'utilisateurs non-payants, le pricing de Clerk joue contre nous.

Conseils de migration pour quitter Clerk

Partir de Clerk est faisable mais demande de la planification. Voici le chemin concret :

1. Exporter les données utilisateurs d'abord. Utiliser l'API Backend de Clerk pour exporter les profils utilisateurs, adresses email, metadata et appartenances aux organisations. Faire ça avant de toucher à quoi que ce soit. Les hash de mots de passe ne sont pas exportables — il faut prévoir des resets de mots de passe.

2. Mettre en place le nouveau système d'auth en parallèle. Déployer le nouveau provider d'auth à côté de Clerk. Router les nouvelles inscriptions vers le nouveau système pendant que les utilisateurs existants continuent d'utiliser Clerk.

3. Gérer le problème du reset de mot de passe. Puisqu'on ne peut pas exporter les hash de mots de passe, les utilisateurs avec un login email/password devront définir un nouveau mot de passe. Envoyer un email "nous avons amélioré notre système de connexion" avec un lien de reset. Présenter ça comme une amélioration de sécurité, pas comme une perturbation. Les utilisateurs connectés via social login (Google, GitHub) peuvent se ré-authentifier sans accroc puisque l'identité est chez le provider OAuth.

4. Migrer les connexions OAuth. Les utilisateurs en social login n'ont rien à réinitialiser, mais il faut stocker les nouvelles données de session et de profil du provider OAuth dans le nouveau système d'auth. Tester chaque provider individuellement.

5. Mettre à jour l'UI. Remplacer les composants <SignIn />, <UserButton /> et <UserProfile /> de Clerk par ses propres formulaires ou les composants du nouveau provider. C'est la partie la plus fastidieuse — chercher dans le codebase toutes les utilisations de composants et hooks Clerk.

6. Faire tourner les deux systèmes en parallèle pendant au moins deux semaines. Garder Clerk actif pendant la transition. Monitorer les taux d'erreur, les échecs de connexion et les plaintes utilisateurs. Ne décommissionner Clerk qu'après être sûr que le nouveau système gère chaque edge case.

7. Mettre à jour les webhooks. Si on utilise les webhooks Clerk pour les événements utilisateurs (créé, mis à jour, supprimé), reconfigurer ces événements depuis le nouveau provider d'auth. Le format du payload sera différent.

Compter 2-4 semaines pour un projet de taille moyenne. Le plus gros risque est le churn utilisateur pendant la vague de reset de mots de passe, donc communiquer clairement et rendre le processus aussi fluide que possible.