Clerk vs Firebase Auth : composants soignés ou écosystème Google ?

Deux philosophies, un seul problème

Clerk et Firebase Auth résolvent le même problème en surface : connecter les utilisateurs, gérer les sessions, s'occuper du cycle de vie des comptes. Mais ils viennent de deux mondes différents, et ça change tout sur l'expérience au quotidien.

Clerk est un produit d'auth dédié. Il existe parce que l'UX d'authentification est difficile à bien faire, et que la plupart des fondateurs préféreraient ne pas passer trois semaines à construire des flows de reset de mot de passe, des écrans de vérification d'email et des pages d'enrollment MFA. Clerk fait tout ça pour qu'on puisse se concentrer sur le produit.

Firebase Auth est une feature dans une plateforme. Il existe parce que si on utilise déjà Firebase pour sa base de données, son hosting, son storage et ses functions, obliger à brancher un vendor d'auth séparé serait pénible. L'auth fait partie du package deal.

La vraie question n'est pas lequel a plus de features. C'est : est-ce qu'on veut la meilleure expérience d'auth possible, ou est-ce qu'on veut une auth qui s'intègre naturellement dans une plateforme qu'on utilise déjà ?

Ce que Clerk fait bien

La feature phare de Clerk, ce sont ses composants UI, et ils méritent leur réputation.

<SignIn />, <SignUp />, <UserButton />, <UserProfile /> : des composants React drop-in qui gèrent toute la surface d'auth. Ils sont soignés dès l'install. Ils couvrent les edge cases sur lesquels toute équipe qui build son auth from scratch se plante : sessions expirées, flows de vérification d'email, enrollment MFA, feedback de robustesse du mot de passe, états d'erreur, spinners de chargement. Pour un builder solo qui ne veut pas câbler des formulaires d'auth à la main, ces composants font gagner des semaines.

Au-delà des composants prêts à l'emploi, Clerk Elements propose des primitives non stylisées et composables pour les équipes qui veulent le contrôle total sur le look tout en gardant la logique d'auth de Clerk en dessous. C'est important parce que la plupart des produits finissent par dépasser l'apparence par défaut, et avoir une échappatoire propre vers un UI custom sans réécrire la logique d'auth, ça a de la valeur.

Organizations est la feature multi-tenant de Clerk. Chaque organisation a sa gestion de membres, son contrôle d'accès basé sur les rôles, ses invitations et ses permissions configurables. Pour un SaaS B2B qui a besoin d'isolation type workspace, ça évite de construire soi-même une infra multi-tenancy, ce qui est facilement un projet de plusieurs mois si on part de zéro.

L'intégration Next.js est là où Clerk se sent le plus à l'aise. Le package @clerk/nextjs fournit du middleware pour protéger les routes, des hooks pour accéder à l'état utilisateur dans les client components, et des helpers côté serveur pour les API routes et les server components. Si on build sur Next.js, la DX est vraiment fluide. Clerk a aussi un support first-class pour Remix, Astro et d'autres frameworks modernes. Ce ne sont pas des adapters bricolés après coup.

La gestion de sessions est un autre point fort. Clerk gère le multi-session (utilisateurs connectés à plusieurs comptes en même temps), la gestion de devices et la révocation de sessions. Le dashboard donne une vraie visibilité sur les sessions actives de sa base utilisateurs, ce qui compte quand un client signale un problème de login à 23h.

Le système de webhooks est complet. Utilisateur créé, session démarrée, membership d'organisation modifiée : il y a des événements pour la plupart des moments du cycle de vie auth. Ça rend la synchronisation de l'état d'auth avec sa propre base de données directe, que ce soit pour déclencher des flows d'onboarding ou mettre à jour des systèmes externes quand les utilisateurs changent.

Ce que Firebase Auth fait bien

Le plus gros avantage de Firebase Auth n'est pas une feature spécifique. C'est l'intégration avec le reste.

Si on est déjà sur Firebase, l'auth est juste là. Les security rules Firestore peuvent référencer request.auth.uid directement. Les Cloud Functions peuvent lire le contexte d'auth depuis la requête. Le hosting, le storage et la base de données font tous partie du même projet, gérés depuis la même console, facturés sur la même facture. Il n'y a pas de frontière vendor à combler.

Ça compte plus que les comparaisons feature par feature ne le laissent penser. Chaque frontière vendor dans sa stack introduit un problème de synchronisation, une surface de debug et une ligne de facturation. Firebase Auth élimine une de ces frontières si on est déjà dans l'écosystème.

La couverture de providers est solide. Email et mot de passe, numéro de téléphone, Google, Apple, Facebook, GitHub, Twitter, Microsoft, Yahoo et auth anonyme sont tous supportés out of the box. L'auth custom avec son propre système de tokens est aussi disponible. Pour le social login, Firebase Auth couvre le set standard dont la plupart des produits ont besoin.

Le mobile, c'est là où Firebase Auth surpasse vraiment Clerk. Les SDK iOS et Android sont matures et bien documentés. Les flows de vérification par numéro de téléphone marchent bien sur mobile. Si on build une app Flutter ou React Native, les SDK mobile de Firebase Auth ont des années de battle-testing derrière eux. Clerk est web-first ; Firebase Auth couvre le web et le mobile avec le même investissement.

Firebase Identity Platform est l'upgrade payant qui ajoute des features enterprise : multi-factor authentication, blocking functions (logique custom qui tourne avant le sign-in ou sign-up), providers enterprise SAML et OIDC, multi-tenancy et audit logging. Ces features ne sont pas disponibles dans le tier gratuit de Firebase Auth. Si les besoins grandissent au-delà des bases, Identity Platform est le chemin, même si ça vient avec un pricing plus complexe.

L'auth anonyme est une feature vraiment utile que Clerk n'a pas. Elle permet aux utilisateurs d'interagir avec l'app avant de créer un compte, puis de lier leur session anonyme à un vrai compte plus tard. Pour les produits avec un flow essaye-avant-de-t'inscrire, c'est un avantage UX concret.

Les composants UI : la différence au quotidien

C'est là que l'écart pratique entre les deux outils est le plus large.

Clerk donne des composants. On drop <SignIn /> dans une page et on a un formulaire de connexion complet avec boutons sociaux, input email, champ mot de passe, gestion d'erreurs, états de chargement et prompts MFA. On drop <UserButton /> dans le header et on a un menu avatar avec déconnexion, gestion de compte et switch d'organisation. Le temps entre "j'ai besoin d'auth" et "l'auth marche et a l'air pro" est remarquablement court.

Firebase Auth donne des fonctions. On appelle signInWithEmailAndPassword() et on récupère un credential ou une erreur. On appelle signInWithPopup() et une fenêtre de provider s'ouvre. On construit chaque input, chaque message d'erreur, chaque spinner soi-même.

FirebaseUI existe comme solution prête à l'emploi, et ça couvre les bases : flows sign-in email, téléphone et social. Mais ça n'a pas suivi les attentes de design modernes. Les composants font daté à côté de ceux de Clerk, et les customiser au-delà du theming superficiel devient vite pénible. La plupart des équipes finissent par construire un UI d'auth custom par-dessus le SDK de Firebase Auth de toute façon, ce qui veut dire que le gain de temps s'évapore.

Pour un builder solo qui veut que l'auth ait de la gueule dès le jour un sans toucher au CSS des formulaires de login, Clerk gagne cette comparaison sans discussion.

Le pricing : ce qu'on va vraiment payer

Clerk propose un tier gratuit couvrant 10 000 utilisateurs actifs mensuels. C'est suffisant pour le développement, le beta testing et un lancement early. Le plan Pro à $25/mo ajoute les domaines custom, la suppression du branding, les allowlists et blocklists. Au-delà du tier Pro, le pricing scale par MAU sur une échelle dégressive. Le modèle est clair : on sait ce qu'on paie.

Firebase Auth sur le plan gratuit Spark est généreux pour l'authentification basique. Il n'y a pas de cap MAU strict pour les méthodes de sign-in standard. Mais voilà le piège : les features avancées vivent derrière l'upgrade Identity Platform. Multi-factor authentication, blocking functions, providers SAML, multi-tenancy et audit logging nécessitent tous Identity Platform, qui facture par MAU (environ $0.0055 par MAU pour l'auth téléphone, avec des taux différents pour les autres méthodes). Le pricing peut devenir complexe dès qu'on commence à mixer les méthodes de vérification et les features avancées.

Pour un fondateur qui surveille son burn rate, les deux options démarrent gratuitement. Le pricing de Clerk est plus prévisible en scalant. Celui de Firebase Auth reste cheap pour l'usage basique mais peut surprendre quand on a besoin des features Identity Platform ou de la vérification téléphone à gros volume.

Si on paie déjà pour des services Firebase (Firestore, Hosting, Functions), ajouter Firebase Auth ne coûte rien de plus pour l'usage basique. Ajouter Clerk par-dessus Firebase veut dire payer deux vendors pour quelque chose que la plateforme inclut déjà. Ce calcul compte pour un projet indé.

Intégration framework : web vs everywhere

Clerk est purpose-built pour la stack web moderne. Next.js a l'intégration la plus profonde : middleware pour la protection de routes, helpers auth() pour les server components, hooks useUser() pour les client components, et des patterns propres pour l'authentification des API routes. Le setup prend des minutes, pas des heures.

Clerk supporte aussi Remix, Astro, React Router, Expo et React plain avec des packages maintenus. Ce ne sont pas des wrappers communautaires : c'est officiel et documenté.

Firebase Auth est framework-agnostic au sens le plus littéral. Ça marche avec tout parce que c'est un SDK JavaScript (ou un SDK natif pour le mobile). Mais "ça marche avec" et "ça s'intègre profondément avec" sont deux choses différentes. Avec Firebase Auth dans une app Next.js, on doit gérer l'auth côté serveur soi-même. Il n'y a pas de middleware intégré. On doit vérifier les ID tokens manuellement sur le serveur, gérer les sessions cookie pour le SSR, et câbler l'état d'auth entre client et server components par ses propres moyens.

Pour un projet Next.js ou Remix, l'écart de DX est réel. Clerk donne de la plomberie d'auth qui comprend le framework. Firebase Auth donne des primitives d'auth qu'on câble dans le framework.

Pour les projets mobile, l'histoire s'inverse. Firebase Auth a des SDK iOS, Android et Flutter matures et bien documentés. Clerk a un SDK Expo pour React Native, mais le mobile chez Firebase Auth a des années d'avance en maturité.

Gestion des utilisateurs : les dashboards comparés

Le dashboard de Clerk est focalisé et rapide. On peut chercher des utilisateurs, inspecter leurs sessions, parcourir les organisations, voir l'historique de login et gérer les rôles. Comme Clerk ne fait que de l'auth, le dashboard n'est pas encombré de services sans rapport. Quand un utilisateur signale un problème de login, retrouver son record et comprendre ce qui s'est passé est rapide.

La Firebase Console gère l'auth comme une section parmi d'autres. On peut voir les utilisateurs, filtrer par provider, désactiver des comptes et reset des mots de passe. Ça marche. Mais c'est pas la star du show : c'est un onglet dans une console qui gère aussi la base de données, le storage, les functions, le hosting et les analytics. L'interface de gestion utilisateurs est fonctionnelle plutôt que soignée.

Pour les opérations d'auth au quotidien -- chercher un utilisateur précis, vérifier ses sessions récentes, comprendre pourquoi un sign-in a échoué -- le dashboard dédié de Clerk est nettement meilleur.

Social login et MFA

Les deux plateformes supportent les providers sociaux dont la plupart des produits ont besoin : Google, Apple, GitHub, Facebook, Twitter et Microsoft. Clerk ajoute quelques extras comme Discord, Twitch, LinkedIn et Notion. Firebase Auth a un set solide mais ajouter des providers OAuth custom demande plus de configuration.

Pour le multi-factor authentication, Clerk inclut le TOTP (apps authenticator) et le MFA par SMS sur ses plans standard. Firebase Auth nécessite l'upgrade vers le tier Identity Platform pour le MFA, ce qui veut dire un coût supplémentaire. Si le MFA est un requirement pour le produit, Clerk l'inclut par défaut tandis que Firebase Auth le gate derrière un paywall.

Les deux plateformes supportent les flows passwordless. Clerk propose les magic links et les one-time codes par email. Firebase Auth supporte le sign-in par email link et le phone OTP. Les implémentations sont comparables.

Vendor lock-in : parlons franchement

Aucun des deux outils ne rend la migration facile, et quiconque dit le contraire vend quelque chose.

Le modèle de composants et l'API de Clerk sont propriétaires. Si on quitte Clerk, on réécrit ses pages de sign-in, on arrache les wrappers de providers, on remplace la gestion de sessions et on reconstruit les flows de profil utilisateur. La commodité de <SignIn /> est réelle, mais la dépendance aussi.

Firebase Auth utilise des protocoles standard en dessous (OAuth 2.0, OpenID Connect), mais la surface SDK est Firebase-specific. Le code appelle signInWithPopup(provider), pas une librairie OAuth générique. Les security rules référencent request.auth. Les Cloud Functions lisent context.auth. Partir veut dire réécrire l'intégration auth à travers toute la stack.

La différence pratique : la dépendance de Firebase Auth s'étend dans la couche données (security rules) et les fonctions serverless, ce qui veut dire que la surface de migration est plus large. La dépendance de Clerk est concentrée dans la couche UI d'auth et le middleware.

Dans les deux cas, les hashes de mots de passe peuvent ou non être exportables. À prévoir si la portabilité compte. Voir aussi : Supabase vs Firebase pour un comparatif plus large du lock-in entre ces écosystèmes.

Quand choisir Clerk

• On veut des composants UI d'auth soignés qui marchent tout de suite sans construire de formulaires from scratch.
• On build sur Next.js, Remix ou Astro et on veut l'intégration framework la plus serrée possible.
• Le produit a besoin de features d'organisation ou de workspace avec gestion de membres et contrôle d'accès par rôles.
• On veut un dashboard de gestion utilisateurs rapide et focalisé sur les opérations d'auth.
• Le time to value compte et on veut l'auth shippée cette semaine, pas ce mois-ci.
• On build un produit web-first et le mobile n'est pas la plateforme principale.
• On veut le MFA inclus sans payer pour un tier premium.

Quand choisir Firebase Auth

• On utilise déjà Firebase pour sa base de données, son hosting ou d'autres services backend.
• On build un produit mobile-first et on a besoin de SDK iOS, Android ou Flutter matures.
• On veut l'auth anonyme pour que les utilisateurs puissent essayer le produit avant de créer un compte.
• On préfère un seul vendor et une seule console pour tout le backend.
• Les besoins d'auth sont standard et on n'a pas besoin de composants prêts à l'emploi soignés.
• On veut une auth profondément intégrée aux security rules Firestore et aux Cloud Functions.
• Le budget est serré et on veut une auth gratuite sans cap MAU sur les features basiques.

Verdict

Clerk est le meilleur produit d'auth pour les apps web modernes. Les composants sont meilleurs. Le dashboard est meilleur. L'intégration framework pour Next.js et Remix est meilleure. Si le produit vit sur le web et qu'on veut une auth qui a l'air professionnelle dès le jour un, Clerk justifie son prix.

Mais si on build sur Firebase, le calcul change. Firebase Auth est déjà là, déjà connecté aux security rules et aux functions, et déjà gratuit pour l'usage basique. Ajouter Clerk par-dessus Firebase introduit une frontière vendor, une couche de synchronisation et une facture séparée pour quelque chose que la plateforme gère déjà.

Notre recommandation : si on est sur Firebase et que les besoins d'auth sont standard, utiliser Firebase Auth et investir le temps qu'on aurait passé sur la sync de webhooks dans le produit. Si on build un SaaS web-first et qu'on veut la meilleure expérience d'auth disponible -- surtout sur Next.js -- Clerk vaut le coût et la dépendance vendor. Et si on n'est engagé dans aucun des deux écosystèmes, Clerk donne un point de départ plus soigné pour les apps web tandis que Firebase Auth offre un play plateforme plus large.

D'autres options d'auth en tête ? Voir Clerk vs Auth0 pour le comparatif avec un autre provider d'auth dédié, ou Clerk vs Supabase Auth pour l'angle Supabase.