Choisir l'authentification pour un nouveau SaaS en 2026 : Clerk, Auth.js, Supabase Auth, Better Auth, et quand auto-héberger

L'authentification est la partie la moins excitante de la construction d'un produit SaaS. Puis elle casse, et c'est la seule chose qui compte. Ou le nombre d'utilisateurs franchit un seuil, la facture mensuelle bondit, et une décision prise par quelqu'un en un après-midi devient une migration de six mois.

Nous prenons cette décision sur des projets clients régulièrement, et la réponse honnête est qu'il n'y a pas de choix unique correct. Il y a un bon choix pour une stack donnée, un profil de croissance donné, un ensemble donné d'exigences enterprise, et une tolérance donnée au vendor lock-in. Ce post expose comment nous y réfléchissons : les cinq vraies options en 2026, ce que chacune fait bien et mal, les calculs de coût à l'échelle, et la logique de décision que nous utilisons réellement.

Il est écrit pour le fondateur technique ou l'équipe produit qui choisit l'authentification pour un nouveau build, ou qui pèse si la décision d'authentification prise tôt est encore la bonne.

Les cinq options

En 2026, cinq approches couvrent presque chaque projet SaaS.

Clerk est une plateforme d'authentification managée construite pour les apps React et Next.js modernes. Vous déposez des composants pré-construits, branchez des variables d'environnement, et avez une authentification fonctionnelle, incluant social login, magic links, passkeys, MFA et gestion d'organisations, en bien moins d'une heure.

Auth.js (anciennement NextAuth, rebaptisé avec la v5) est la bibliothèque open-source auto-hébergée qui domine les exemples open-source. Elle est gratuite, intégrée au framework, et vous donne un contrôle total, au prix de construire les morceaux qu'elle n'inclut pas.

Supabase Auth est l'authentification intégrée à la plateforme Supabase. Si vous utilisez déjà Supabase pour votre base de données Postgres, l'authentification est incluse, et elle s'intègre au niveau de la base via le Row Level Security.

Better Auth est la bibliothèque open-source plus récente, auto-hébergée, agnostique au framework, qui a gagné une traction significative à travers 2025 et 2026. Elle livre du 2FA, des passkeys, des organisations et du RBAC intégrés, les morceaux qu'Auth.js vous fait construire vous-même.

Build sur mesure : construire le sien sur des primitives. Rarement le bon choix, mais il y a un ensemble étroit de cas où ça l'est, et il vaut la peine de savoir où est la ligne.

Ce que chacune fait bien et mal

Clerk

La plus forte expérience développeur de la catégorie. Le composant pré-construit <SignIn /> inclut email/mot de passe, social OAuth, magic links, passkeys, MFA et CAPTCHA sans UI custom. La gestion d'organisations et d'équipes, la fonctionnalité multi-tenant dont la plupart du SaaS B2B a besoin, est first-class. Pour un SaaS Next.js qui veut une authentification fonctionnelle aujourd'hui et qui valorise le temps d'ingénierie sur le coût, Clerk est difficile à battre sur la vitesse.

Les arbitrages sont le coût à l'échelle et le lock-in. Clerk facture par utilisateur actif au-dessus de son palier gratuit, et une app grand public à forte croissance peut voir la facture mensuelle grimper vite. Clerk stocke les données utilisateur sur son infrastructure, donc migrer ailleurs plus tard signifie exporter les utilisateurs et réimplémenter les flux. Et il n'y a pas d'option d'auto-hébergement, ce qui l'exclut pour les exigences on-premises ou air-gapped. Clerk a revu ses prix en février 2026 et le palier gratuit est plus généreux qu'avant, ce qui adoucit la préoccupation de coût en phase précoce, mais les calculs à l'échelle méritent quand même un regard avant de s'engager.

Auth.js

Gratuit pour toujours en tant que bibliothèque, le plus gros écosystème, et un contrôle total. Si vous voulez posséder chaque partie du flux d'authentification et que vous avez la capacité d'ingénierie pour le construire et le maintenir, Auth.js vous donne cela. La v5 a ajouté le support du runtime Edge et une meilleure intégration des server actions.

Le coût est les morceaux qu'elle n'inclut pas. Il n'y a pas de 2FA intégré, pas de passkeys intégrés, pas d'organisations intégrées, pas de RBAC intégré. Vous implémentez tout cela vous-même ou mobilisez des bibliothèques supplémentaires. "Gratuit" est réel pour la bibliothèque et trompeur pour le total : le temps d'un développeur senior à construire une UI d'authentification custom, gérer les cas limites, brancher la vérification email, et maintenir tout cela a un vrai coût. Pour un fondateur solo, ce temps est souvent mieux dépensé sur le produit.

Supabase Auth

Si vous êtes déjà sur Supabase pour votre base de données, c'est proche d'un défaut. L'authentification est incluse dans une plateforme que vous payez déjà, et l'intégration Row Level Security est réellement élégante : vous écrivez une policy une fois, comme restreindre les lignes à celles où l'ID utilisateur correspond à l'utilisateur authentifié, et la base applique l'autorisation sur chaque requête. Pas de middleware, pas de vérification de permission par endpoint. Le palier gratuit est le plus généreux des options managées, couvrant confortablement la plupart des MVP.

Les pièges : utiliser Supabase Auth sans le reste de Supabase défait le but, c'est étroitement couplé à la plateforme. Les composants UI pré-construits sont basiques, bien en deçà du poli de Clerk. Et le SSO enterprise est limité ; Supabase supporte les connexions OIDC mais manque de la configuration SAML profonde et de la gestion des fournisseurs d'identité enterprise que conclure des deals B2B enterprise demande souvent.

Better Auth

Le vrai nouveau prétendant. Better Auth est agnostique au framework, s'intègre à n'importe quelle base de données via les adaptateurs Drizzle ou Prisma, et livre les fonctionnalités qu'Auth.js vous fait construire : 2FA, passkeys, organisations, RBAC. Elle est open-source et auto-hébergée, donc pas de facture vendeur par utilisateur et pas de lock-in des données vendeur. Vos seuls coûts sont la base de données et le fournisseur d'email que vous payez déjà.

L'arbitrage est qu'elle est plus récente. L'écosystème, le volume d'exemples, la profondeur des réponses communautaires pour les cas limites obscurs, est plus petit qu'Auth.js ou les plateformes managées, même s'il a grandi vite. Pour une équipe à l'aise avec l'auto-hébergement de l'authentification et qui veut des fonctionnalités modernes sans facture par utilisateur, Better Auth est un choix 2026 solide d'une manière qu'il ne l'était pas il y a deux ans.

Build sur mesure

Construisez le vôtre seulement quand l'authentification est réellement votre différenciateur produit principal, que vous avez une équipe sécurité avec une vraie profondeur, que vous avez des exigences qu'aucune plateforme ne couvre, et que vous avez une tolérance de timeline de plus de 12 mois. Pour tous les autres, l'authentification custom est une manière de passer un trimestre à reconstruire quelque chose qui existe, et de prendre la responsabilité sécurité de faire la gestion de session, la gestion des tokens, le stockage des mots de passe et la récupération de compte exactement bien. Les conséquences sécurité de rater l'un de ceux-là sont sévères. La barre pour "construisez-le vous-même" est haute et la plupart des projets ne la franchissent pas.

Les calculs de coût à l'échelle

La décision se résume souvent à ce qui se passe après les premiers milliers d'utilisateurs, voici donc la forme de la chose.

Les plateformes managées facturent par utilisateur actif au-dessus d'un palier gratuit. Le palier gratuit de Clerk est devenu plus généreux en février 2026, ce qui couvre la phase critique de croissance précoce, mais au-dessus le coût par utilisateur est réel, et pour une app grand public à forte croissance, la facture à des centaines de milliers d'utilisateurs est une ligne significative. Supabase Auth est essentiellement gratuit jusqu'à un grand nombre d'utilisateurs et très bon marché au-dessus, parce qu'il est groupé avec la plateforme de base de données, ce qui est pourquoi "êtes-vous déjà sur Supabase" est une question si décisive.

Les bibliothèques auto-hébergées, Auth.js et Better Auth, ne coûtent rien pour la bibliothèque elle-même. Vos vrais coûts sont la base de données (que vous avez de toute façon) et un fournisseur d'email pour les emails de vérification et de magic-link, à peu près un coût mensuel bas et fixe peu importe le nombre d'utilisateurs. Le coût caché est le temps d'ingénierie : construire les morceaux manquants, gérer les cas limites, le maintenir. Pour Auth.js ce coût caché est plus grand parce qu'il y a plus de morceaux manquants. Pour Better Auth il est plus petit parce que les fonctionnalités modernes sont intégrées.

Le pattern : les plateformes managées échangent de l'argent contre du temps d'ingénierie et de la vitesse. Les bibliothèques auto-hébergées échangent du temps d'ingénierie contre de l'argent et du contrôle. Il n'y a pas d'échange universellement correct ; il y a un échange correct pour votre sensibilité au coût et votre capacité d'ingénierie spécifiques.

La logique de décision que nous utilisons

Quand nous cadrons l'authentification pour un SaaS client, nous déroulons cela dans l'ordre.

Êtes-vous déjà sur Supabase ? Si oui, Supabase Auth est le défaut sauf si une exigence spécifique, particulièrement le SSO SAML enterprise, l'exclut. L'intégration RLS à elle seule le justifie. N'adoptez pas toute la stack Supabase juste pour l'authentification, mais si vous y êtes déjà, utilisez-la.

Avez-vous besoin du SSO enterprise bientôt ? Si vous êtes un SaaS B2B qui attend des clients enterprise qui exigeront le SSO SAML et le provisioning SCIM, cette exigence rétrécit le champ vite. Clerk gère la gestion d'organisations et les fonctionnalités enterprise en first-class. Auth0 (le standard enterprise de longue date, plus que ce que nous avons couvert ci-dessus) est construit exactement pour cela. Le SSO enterprise de Supabase Auth est limité. Better Auth et Auth.js peuvent le faire mais vous construisez plus. Si le SSO enterprise est sur la roadmap proche, pondérez cela fortement.

La vitesse de mise en production est-elle la priorité ? Si vous avez besoin d'une authentification fonctionnelle cette semaine et que vous valorisez le temps d'ingénierie sur le coût, Clerk vous y mène le plus vite, avec les meilleurs composants pré-construits de la catégorie. C'est le bon choix pour beaucoup de produits en phase précoce qui ont besoin de valider l'idée, pas le système d'authentification.

Voulez-vous éviter une facture par utilisateur et posséder la stack ? Si vous êtes à l'aise avec l'auto-hébergement et que vous voulez des fonctionnalités modernes, 2FA, passkeys, organisations, RBAC, sans facture vendeur par utilisateur, Better Auth est la réponse 2026 solide. Auth.js si votre équipe veut spécifiquement le plus gros écosystème et accepte de construire les morceaux manquants.

L'authentification est-elle votre produit réel ? Seulement alors le build sur mesure entre dans la conversation, et même alors, scrutez fort.

Pour la plupart des nouveaux projets SaaS clients en 2026, le résultat réaliste est Supabase Auth (si déjà sur Supabase), Clerk (si la vitesse et les fonctionnalités enterprise comptent et que les calculs de coût fonctionnent), ou Better Auth (si posséder la stack et éviter la facture par utilisateur comptent plus). Auth.js reste un bon choix pour les équipes qui le veulent. Le build sur mesure est rare et délibéré.

Ce vers quoi les outils de codage IA penchent par défaut, et pourquoi cela compte

Une ride spécifique à 2026 : si vous échafaudez avec des outils de codage IA, la solution d'authentification que l'IA génère au premier passage devient souvent celle que vous livrez. Et le défaut n'est pas une recommandation ; c'est ce qui est apparu le plus dans les données d'entraînement.

Les outils qui échafaudent des apps full-stack autour d'un backend spécifique tendent à brancher l'authentification de ce backend, donc un échafaudeur orienté Supabase produit Supabase Auth, parce que l'architecture le suppose. Les assistants de code généraux penchent vers Auth.js parce qu'il domine les exemples open-source. Clerk apparaît rarement comme génération par défaut parce qu'il a besoin d'un compte et de clés API avant que le code fonctionne, donc vous devez le choisir délibérément.

Le point à retenir : ne laissez pas le défaut de l'IA prendre cette décision pour vous. Le défaut reflète la fréquence dans les données d'entraînement, pas votre stack, votre profil de croissance, ou vos exigences enterprise. Décidez l'approche d'authentification d'abord, puis faites implémenter par l'outil celle que vous avez choisie.

Une note sur le build plus large

L'authentification est une décision dans une architecture SaaS plus large, et elle devrait être prise dans le contexte des autres, la base de données, le framework, le modèle d'hébergement, l'approche multi-tenant. Nous avons écrit sur la version en phase précoce de cela dans notre post MVP SaaS. Le choix d'authentification se propage : Supabase Auth implique la plateforme Supabase, Clerk implique une posture de services managés, Better Auth implique que vous êtes à l'aise avec l'auto-hébergement d'infrastructure. Choisissez l'authentification en isolation et vous pouvez finir par vous battre avec le reste de la stack.

FAQ

Quelle est la réponse correcte la plus courante en 2026 ?

Il n'y en a pas une, ce qui est la réponse honnête, mais les résultats les plus courants sur lesquels nous atterrissons sont Supabase Auth quand le projet est déjà sur Supabase, et Clerk quand la vitesse et les fonctionnalités enterprise comptent et que la projection de coût est acceptable. Better Auth est devenu une vraie troisième réponse courante d'une manière qu'il ne l'était pas plus tôt.

Auth.js est-il dépassé maintenant que Better Auth existe ?

Non. Auth.js est mature, a le plus gros écosystème, et la v5 l'a modernisé. L'avantage de Better Auth est que les fonctionnalités modernes (2FA, passkeys, organisations, RBAC) sont intégrées plutôt qu'assemblées. Si votre équipe valorise spécifiquement le plus gros écosystème et accepte de construire ces morceaux, Auth.js est encore un choix raisonnable.

À quel point le vendor lock-in compte-t-il réellement ?

Il compte le plus pour les plateformes managées qui stockent les données utilisateur sur leur infrastructure, comme Clerk. Migrer signifie exporter les utilisateurs et réimplémenter les flux, ce qui n'est pas trivial mais pas catastrophique. Les options auto-hébergées (Auth.js, Better Auth) ont beaucoup moins de lock-in parce que les données utilisateur sont dans votre propre base. Pesez-le selon la probabilité que vous changiez, qui pour la plupart des produits est "pas très, mais pas jamais".

Ai-je besoin des passkeys en 2026 ?

Les passkeys sont devenus mainstream et toutes les options majeures les supportent désormais, les plateformes managées nativement, Better Auth intégré, Auth.js avec du travail supplémentaire. Ils sont de plus en plus attendus plutôt qu'optionnels, surtout pour les acheteurs B2B soucieux de sécurité. Si votre approche d'authentification supporte les passkeys avec peu d'effort supplémentaire, activez-les.

Quand un build d'authentification sur mesure a-t-il réellement du sens ?

Quand l'authentification est réellement votre différenciateur produit principal, que vous avez une équipe sécurité avec une vraie profondeur, que vous avez des exigences qu'aucune plateforme ne satisfait, et que vous pouvez tolérer une timeline de plus de 12 mois. C'est une intersection étroite. Pour l'écrasante majorité des produits SaaS, l'authentification custom est reconstruire un problème résolu et en prendre la responsabilité sécurité.

Puis-je changer de fournisseur d'authentification plus tard si je me trompe ?

Oui, mais c'est une vraie migration, pas un changement de config, surtout en quittant une plateforme managée qui détient vos données utilisateur. Le coût de changer est exactement pourquoi la décision initiale mérite plus qu'un après-midi. C'est récupérable, mais c'est le genre de récupérable dont vous préféreriez ne pas avoir besoin.

Pour aller plus loin

Si vous démarrez un build SaaS et que vous voulez la décision d'authentification prise correctement dans le contexte de toute l'architecture, contactez-nous. Nous cadrons l'authentification aux côtés des choix de base de données, framework, hébergement et multi-tenant, parce que la décider en isolation est comment les stacks finissent par se battre elles-mêmes. Vous pouvez en savoir plus sur notre travail de développement SaaS et applications web, et si votre build a besoin de connecter l'authentification ou les données utilisateur à d'autres systèmes, notre service d'intégration API et systèmes couvre ce côté.

Pour l'image plus large de la phase précoce, notre guide MVP SaaS couvre comment la décision d'authentification s'inscrit dans le reste du premier build.