Le meilleur CIAM auto-hébergé pour les créateurs de SaaS B2B

Si vous avez consulté les tarifs de certaines plateformes CIAM en SaaS, vous avez sans doute remarqué à quel point elles deviennent chères et vous avez probablement envisagé une solution auto-hébergée.

Cet article porte sur les quatre plateformes CIAM auto-hébergées qu'une petite équipe SaaS B2B peut réellement exploiter sans que cela devienne un second emploi à plein temps : ZITADEL, FusionAuth, Logto et Ory Hydra. Elles n'ont pas toutes la même forme, et celle qui vous conviendra dépend moins d'une liste de fonctionnalités que du type de produit B2B que vous construisez. Je les ai fait tourner côte à côte sur un seul VPS pendant une semaine pour préparer cette comparaison, et ce qui suit est la version que j'enverrais à un fondateur qui me contacte en DM au sujet du CIAM.

Une précision d'emblée : il s'agit du CIAM en tant que fonctionnalité produit, pas du SSO interne pour votre propre équipe.

La version courte

Quatre plateformes CIAM auto-hébergées, une ligne chacune :

• ZITADEL si vous voulez le multi-tenancy et les organisations B2B prêts à l'emploi.
• FusionAuth si vous voulez une interface d'administration soignée et un historique de versions long et prévisible.
• Logto si vous voulez l'expérience développeur la plus propre dès le premier jour.
• Ory Hydra si vous travaillez au niveau du protocole et voulez le moteur OAuth 2.0, pas une application de connexion clés en main.

En résumé : ZITADEL est le pari initial le plus sûr pour un SaaS B2B classique, et le reste de l'article détaille ce raisonnement.

Pourquoi le CIAM n'est pas la même décision que le SSO interne

Si le SSO de votre équipe interne tombe, les dégâts restent généralement circonscrits. Vos ingénieurs perdent peut-être l'accès à Grafana ou à un autre outil interne pendant une heure. Si le CIAM tombe, vos clients payants ne peuvent plus se connecter au produit du tout. La question passe alors de « quel outil d'authentification est pratique pour notre équipe ? » à « à quel système d'authentification peut-on faire confiance en tant que partie du produit ? »

Le CIAM, ce type d'infrastructure d'identité dont un SaaS B2B a besoin, requiert aussi des primitives que beaucoup d'outils de SSO interne ne mettent pas en avant. Votre client n'est pas un utilisateur unique ; c'est une organisation (un tenant) avec ses propres utilisateurs, rôles, identité visuelle et, éventuellement, sa propre connexion SAML vers un IdP d'entreprise. Vous n'authentifiez pas seulement des personnes ; vous isolez les utilisateurs d'une entreprise de ceux d'une autre au sein du même produit. C'est cette forme B2B que les quatre outils ci-dessous visent, chacun à sa manière. Keycloak dispose désormais d'Organizations de premier ordre, donc l'écarter comme réservé au SSO interne serait dépassé ; j'explique son absence dans la FAQ.

Le triangle construire / acheter / auto-héberger prend aussi une autre allure ici. Écrire OAuth de zéro est une erreur évitable. Vous livrez un produit SaaS, pas un fournisseur d'identité. Acheter du managé (Auth0, Clerk, WorkOS) est le bon choix quand votre équipe n'a aucune capacité ops et un budget raisonnable. Je ne conseillerais jamais à une startup de deux personnes d'auto-héberger l'authentification dès le premier jour. L'auto-hébergement devient rationnel quand la tarification au MAU du CIAM managé dépasse le coût de l'infrastructure plus le temps d'ingénierie récurrent, ou quand vous avez besoin d'un contrôle direct du déploiement et du plan de données. Dans les équipes avec lesquelles j'ai travaillé, ce point arrive généralement entre « nous avons un vrai produit » et « nous avons une vraie fonction customer success ».

Si vous cherchez du SSO pour vos propres applications plutôt que pour celles de vos clients, c'est une autre comparaison que celle-ci. Passons à nos recommandations.

Les quatre outils, un par un

J'ai retenu ces quatre-là parce qu'ils sont suffisamment orientés CIAM pour être évalués comme infrastructure produit, et pas seulement comme SSO interne. ZITADEL, FusionAuth, Logto et Ory offrent tous une vraie voie d'auto-hébergement et assez de traction pour être pris au sérieux. Les options réduites à une bibliothèque, celles orientées SSO interne et les moins matures sont mieux traitées dans la FAQ.

ZITADEL

ZITADEL est une plateforme d'identité d'origine suisse écrite en Go, avec une architecture event-sourced et un backend PostgreSQL. Au 27 juillet 2026, sa dernière version publiée sur GitHub est la the 4.16 series, current as of July 2026. ZITADEL est passé d'Apache 2.0 à AGPL-3.0 à partir de la v3 ; pour un usage SaaS classique, l'impact pratique est généralement moins effrayant qu'il n'y paraît, et je détaille cela dans la FAQ.

Ce qui distingue ZITADEL pour le SaaS B2B : les organisations et le multi-tenancy sont des primitives de premier ordre, et non des fonctionnalités que vous composez à partir d'objets génériques. Vous créez une Organization, elle obtient ses propres utilisateurs, politiques, identité visuelle et paramètres d'accès, et vous pouvez lui accorder des projets pour que ses administrateurs gèrent les attributions de rôles de leurs propres utilisateurs. Vous n'avez pas à inventer la notion de « tenant » par-dessus des utilisateurs génériques. Vous partez de là.

L'expérience développeur est API-first, avec les API de ressources REST v2 actuelles, plus un accès gRPC et REST aux services v1 historiques. Des SDK officiels et communautaires couvrent les stacks serveur courantes. La console d'administration est fonctionnelle, mais plus sobre que celle de FusionAuth.

Mon avis : Si vous construisez un SaaS B2B et que vous savez que vous aurez des tenants, ZITADEL est mon point de départ. Parmi les options auto-hébergées, c'est celle qui est le plus explicitement pensée pour le problème du login B2B.

FusionAuth

FusionAuth est une plateforme américaine d'Inversoft, LLC (une LLC du Delaware, opérant sous le nom FusionAuth) présente depuis plus longtemps que les trois autres, et cela se voit, dans le bon sens. L'interface d'administration paraît nettement plus travaillée, la documentation est mature et le rythme des versions est régulier plutôt qu'effréné. Si vous avez déjà hérité d'une intégration d'authentification vieille de quatre ans en remerciant en silence l'ingénieur précédent d'avoir choisi l'option ennuyeuse, FusionAuth est la version du CIAM qui mérite ce remerciement.

C'est la licence qui fait trébucher : FusionAuth Community est gratuit à auto-héberger, mais le produit principal n'est pas open source. Le produit est régi par la licence propre à FusionAuth, et ses limites comptent si vous prévoyez de redistribuer, d'intégrer, de renommer, de revendre ou d'héberger FusionAuth pour vos propres clients. La version Community auto-hébergée couvre le cas d'usage central du SaaS B2B ; les offres payantes ajoutent des fonctionnalités comme le SAML initié par l'IdP, la MFA avancée et les thèmes propres à une application, tandis que SCIM, Tenant Manager et les politiques MFA au niveau applicatif relèvent d'Enterprise.

Côté forme B2B : FusionAuth modélise des tenants et des applications, mais l'abstraction relève de « l'authentification conteneurisée par tenant » plutôt que des « organisations B2B comme objet de domaine ». Ça marche (j'ai livré des produits dessus), mais le multi-tenancy ressemble davantage à une primitive d'isolation qu'à un modèle B2B de premier ordre. Les SDK officiels et bibliothèques clientes sont nombreux :

• Angular
• React
• Vue
• iOS
• Android
• Go
• Java
• .NET
• PHP
• Python
• Ruby
• TypeScript

Les bibliothèques côté serveur sont de fins clients d'API. La console d'administration est comparativement plus facile à confier à une personne ops non ingénieure que les autres.

Mon avis : Si votre équipe valorise le soin apporté à l'interface et un historique long et prévisible plus que des primitives nativement B2B, prenez FusionAuth. C'est le choix le plus « ennuyeux » de la liste, et c'est un compliment.

Logto

Logto est le plus récent des quatre, développé par Silverhand Inc. et sous licence MPL-2.0, et c'est celui qui soigne le plus visiblement son tableau de bord. La mise en route du premier jour est relativement rapide. Vous provisionnez, vous parcourez l'assistant, et vous avez un fournisseur OIDC fonctionnel avec une interface de connexion par défaut correcte en une quinzaine de minutes (je l'ai chronométré la semaine où j'ai fait tourner les quatre en parallèle). Ses guides de démarrage officiels couvrent les frameworks et stacks serveur modernes, donc si votre stack est « Next.js + Postgres + autre chose », vous serez en terrain connu.

Sa réponse B2B s'appelle Logto Organizations. Il couvre les primitives B2B essentielles : appartenance à une organisation, rôles limités à l'organisation, invitations de membres, provisionnement just-in-time et intégration SSO d'entreprise. Le modèle d'organisation est plus récent que celui de ZITADEL, donc je testerais tout flux SAML, SCIM ou de fédération inhabituel auprès de vos clients cibles avant de vous engager.

Le compromis, c'est la maturité : Logto est l'option la plus récente ici. La feuille de route avance vite, ce qui est formidable quand une fonctionnalité dont vous avez besoin arrive, et inconfortable quand c'est un changement cassant. Si votre SaaS B2B se situe du côté simple du spectre multi-tenant (un petit nombre d'organisations et pas d'exigences de fédération exotiques), l'expérience développeur de Logto rend le reste de la décision plus facile.

Mon avis : Si vous voulez le premier jour le plus rapide et que vos besoins B2B restent relativement simples, prenez Logto.

Ory Hydra (et la stack Ory)

Ory Hydra est le serveur OAuth 2.0 / OpenID Connect de l'écosystème Ory, sous licence Apache-2.0. La stack Ory complète associe Hydra à Ory Kratos (identité et gestion des utilisateurs, connexion en libre-service, inscription, MFA et récupération de compte), Ory Keto (un serveur d'autorisation de type Zanzibar servant de point de décision de politique) et Ory Oathkeeper (un proxy d'identité et d'accès qui authentifie, autorise et transforme les requêtes HTTP entrantes). Vous assemblez ce dont vous avez besoin. Tout est écrit en Go et les API sont propres.

Le hic (et ce n'est pas un défaut ; c'est un atout pour la bonne équipe), c'est que Hydra est le moteur, pas l'application. Par conception, Hydra se connecte à une application de connexion et de consentement distincte que vous fournissez. Si vous voulez un écran de connexion prêt à l'emploi, ce n'est pas l'outil qu'il vous faut. Si vous construisez quelque chose où le flux d'authentification fait partie du produit (une plateforme pour développeurs, un portail B2B sur mesure ou un produit API-first avec un onboarding spécifique), l'absence d'interface imposée est exactement ce que vous voulez.

L'histoire B2B est composable plutôt que clés en main. Vous pouvez modéliser le multi-tenancy en câblant des schémas Kratos et des relations Keto à votre propre couche organisation, et ça fonctionne, mais c'est vous qui câblez. Le coût, c'est plus de plomberie ; le bénéfice, c'est le contrôle sur l'expérience. La documentation d'Ory couvre la surface protocolaire en profondeur, mais le modèle composable suppose que vous êtes à l'aise pour prendre vous-même des décisions au niveau du protocole. Si « audience claim » ou « PKCE » ne vous évoque rien, commencez par l'un des trois autres.

Mon avis : Si vous construisez quelque chose au niveau du protocole (passerelle d'authentification, flux sur mesure, plateforme pour développeurs) et que les applications standard vous semblent contraignantes, Ory est la bonne réponse. Pour un SaaS B2B classique qui veut un login opérationnel aujourd'hui, non.

Comparatif en un coup d'œil

Voici le résumé des quatre outils en un seul tableau, utile pour une deuxième lecture, pas en remplacement des profils ci-dessus.

Par lequel commencer ?

Quatre scénarios courts qui couvrent la plupart des équipes avec qui j'en discuterais.

Vous construisez un SaaS B2B et vous savez que vous aurez des tenants. Commencez par ZITADEL. Les primitives de multi-tenancy et d'organisation sont conçues exactement pour cela, la surface d'API est complète et vous passerez moins de temps à inventer le modèle de tenant qu'avec n'importe lequel des trois autres. Le passage à l'AGPL mérite une revue juridique, mais un déploiement non modifié et intégré séparément est généralement un cas d'usage SaaS sans complication.

Vous voulez l'interface d'administration soignée et une plateforme stable et prévisible. FusionAuth. L'offre Community couvre les besoins essentiels de beaucoup d'équipes ; prévoyez du temps pour lire attentivement la licence et la matrice de fonctionnalités. Des fonctions comme le SAML initié par l'IdP, la MFA avancée et les thèmes propres à une application exigent une offre payante, tandis que SCIM, Tenant Manager et les politiques MFA au niveau applicatif relèvent d'Enterprise.

Vos besoins B2B sont simples aujourd'hui et vous voulez le premier jour le plus rapide. Logto. Son expérience développeur au premier jour a été la plus rapide dans mon test comparatif. Acceptez que vous pariez sur un écosystème plus jeune, et réexaminez le choix si vos besoins évoluent vers des cas limites de fédération que vous n'avez pas testés.

Vous construisez quelque chose où les flux d'authentification font partie de l'expérience produit. Ory Hydra (avec Kratos, et Keto si vous avez besoin de permissions). Vous écrirez plus de code. Vous aurez plus de contrôle. Si ce compromis ne vous paraît pas évident, vous n'êtes pas le public d'Ory. Choisissez l'un des trois autres.

Si deux de ces descriptions vous correspondent, prenez ZITADEL par défaut. C'est celui qui convient le plus largement et celui que je confierais à une petite équipe fondatrice sans poser beaucoup de questions supplémentaires.

Ce que l'auto-hébergement vous coûte (côté exploitation)

Voici la partie la moins romantique de l'article.

Votre rigueur de sauvegarde PostgreSQL devient désormais une chose dont votre activité dépend. Sur ces déploiements, l'état d'identité que vous devez protéger peut inclure les enregistrements utilisateurs, les identifiants hachés, les secrets MFA, les identifiants clients OAuth et les données de session. Perdez cet état et vos clients risquent de ne plus pouvoir se connecter. Mettez en place des sauvegardes automatiques avant l'inscription de votre premier vrai utilisateur, testez la restauration et placez la santé des sauvegardes dans le même canal d'alerte que la disponibilité de votre application.

Le rythme des versions évolue avec le temps. ZITADEL v4.16.1 est sortie le 17 juillet 2026 après plusieurs versions en juin, et chaque projet ici maintient sa propre cadence et sa propre politique de compatibilité. Traitez cette cadence comme un sujet de maintenance, pas comme un raccourci pour juger la qualité. Lisez les notes de version avant de lancer docker compose pull, et planifiez une fenêtre de correctifs récurrente. Sauter les mises à jour du fournisseur d'identité pendant des mois peut vous laisser en retard sur les correctifs de sécurité et de compatibilité lors de votre premier vrai audit.

Les banalités qui vous rattrapent toujours : le renouvellement des certificats TLS (utilisez un reverse proxy avec Let's Encrypt, automatisez les renouvellements et alertez en cas d'échec), la configuration du serveur d'envoi pour les e-mails de vérification et les réinitialisations de mot de passe (SES, SendGrid, Postmark : choisissez-en un et configurez correctement SPF/DKIM/DMARC, sinon vos e-mails de réinitialisation finiront en spam), la rotation des identifiants clients OAuth quand un ingénieur s'en va, et la limitation de débit sur les points d'entrée de connexion pour qu'une attaque par credential stuffing ne sature pas votre CPU.

Astuce : si vous utilisez un Postgres managé, ne supposez pas que l'utilisateur de base de données d'exécution peut aussi initialiser le schéma. Créez à l'avance la base et l'utilisateur, accordez les droits de propriété ou d'installation requis, et lancez la première configuration avec les identifiants attendus par chaque outil. Sinon, votre premier lancement peut échouer sur une erreur de permission de base de données peu explicite et vous perdrez une heure à chercher au mauvais endroit.

Ce que la voie de l'auto-hébergement vous fait économiser en dollars, elle vous le fait payer en responsabilité. Après l'installation, prévoyez quelques heures d'ingénierie par mois pour maintenir la couche d'identité en bonne santé. Les équipes qui n'allouent aucun temps découvrent généralement le coût plus tard : pendant une panne, sur un cas limite SAML bizarre, ou lors de leur premier audit de sécurité.

Où les déployer

Un VPS Linux exécutant Docker Compose peut être un point de départ sensé pour l'évaluation et des charges modestes, mais le dimensionnement en production et la haute disponibilité dépendent du trafic, des exigences de sécurité et de votre tolérance aux interruptions. Voici comment se positionnent les options de déploiement courantes :

• Hébergement mutualisé ne peut en exécuter aucun. Ils ont besoin d'un stockage persistant, de ports personnalisés, d'un accès root pour le moteur de conteneurs et d'un vrai backend de base de données. PostgreSQL est la voie par défaut pour la plupart de cette liste, mais ce n'est pas littéralement la seule base prise en charge par chaque outil.
• Kubernetes peut exécuter les quatre, mais la prise en charge officielle est inégale. ZITADEL, FusionAuth, et Ory publient des charts Helm officiels, tandis que la documentation d'auto-hébergement de Logto se concentre sur le déploiement Docker et VM. Pour un petit SaaS B2B qui n'a pas atteint le point où Kubernetes se rentabilise ailleurs, c'est généralement de la sur-ingénierie. Sortez-le quand le reste de votre infrastructure y est déjà.
• Le bare metal convient si vous y êtes déjà. La plupart des équipes SaaS B2B n'y sont pas.

Pour un petit pilote mononœud, je partirais sur 4 GB de RAM, 2 vCPU et 60 GB de stockage NVMe, puis je ferais un test de charge sur le vrai flux de connexion. C'est une base de planification, pas un minimum de production universel. Les applications sont relativement légères, mais PostgreSQL a besoin de mémoire et le hachage des mots de passe a besoin de marge CPU. Les recommandations de production de ZITADEL conseillent de rendre quatre cœurs CPU disponibles pour les pics de hachage de mots de passe.

Une fois le produit réel et le trafic soutenu, redimensionnez à partir de mesures. Un stockage rapide aide la latence de PostgreSQL, tandis que la marge CPU compte pendant le hachage concurrent des mots de passe. Surveillez la mémoire, les E/S de base de données, la latence de connexion et la saturation CPU au lieu de supposer qu'une seule ressource compte le plus.

Faire tourner du CIAM en production signifie que sa disponibilité est désormais votre problème. Nous exploitons des instances VPS Linux Cloudzy pour ce type de charge, avec du stockage NVMe et un SLA de disponibilité de 99,95 % sur la plateforme sous-jacente. Cloudzy propose aussi un VPS ZITADEL en un clic si vous préférez éviter le script de provisionnement initial ; les trois autres fournissent des images de conteneur officielles pour une installation à base de Docker. Pour une vue managériale de la place du contrôle d'accès dans votre posture de sécurité globale, le guide des bonnes pratiques IAM l'aborde du point de vue des politiques.

Foire aux questions

La licence AGPL de ZITADEL affecte-t-elle mon SaaS ?

Généralement non pour un déploiement non modifié et intégré séparément, mais ceci n'est pas un conseil juridique. Les obligations AGPL de ZITADEL portent sur ZITADEL lui-même. Si vous modifiez ZITADEL et exploitez cette version modifiée en tant que service réseau, la licence peut exiger que vous proposiez le code source correspondant sous AGPL. La position publiée de ZITADEL est que le simple fait d'utiliser une instance non modifiée comme service d'identité de votre SaaS n'oblige pas, à lui seul, à placer votre application distincte sous AGPL. Lisez l'annonce de licence de ZITADEL et demandez un conseil juridique si vous modifiez, redistribuez, intégrez ou proposez le logiciel à des tiers. Une licence commerciale existe également.

Pourquoi Keycloak et Authentik ne figurent-ils pas dans cette liste ?

Keycloak et Authentik sont d'excellents outils d'identité auto-hébergés (je les utilise), mais exclure Keycloak au motif qu'il n'aurait pas d'organisations B2B serait faux aujourd'hui : les versions actuelles de Keycloak incluent Organizations, les groupes d'organisation et des contrôles d'administration déléguée. Je l'ai laissé de côté parce que cette comparaison se concentre sur quatre options offrant un chemin plus direct pour un SaaS B2B de petite équipe ; Keycloak mérite sa propre évaluation quand l'exploitation JVM, la profondeur de l'écosystème et la souplesse au niveau des realms comptent. Authentik reste plus adapté au SSO interne et aux applications internes qu'à une modélisation de tenants native au produit.

L'auto-hébergement revient-il moins cher qu'Auth0 ?

À faible nombre de MAU, souvent non. Vos heures d'ingénierie coûtent plus cher que la facture Auth0 au palier startup débutante. L'auto-hébergement devient économiquement gagnant à l'échelle où la tarification au MAU du CIAM managé dépasse le coût combiné d'un petit VPS et des quelques heures d'ingénierie mensuelles que vous y consacrerez. Le point d'équilibre exact dépend du coût horaire de votre équipe, de votre courbe de croissance des MAU et du besoin ou non de fonctionnalités entreprise qui vous poussent vers les paliers plus chers d'Auth0. Considérez les économies comme réelles, mais pas immédiates.

Quelle est la taille de VPS minimale pour un CIAM en production ?

Pour un petit pilote mononœud, 4 GB de RAM, 2 vCPU et du stockage NVMe constituent un point de départ raisonnable, pas une garantie de production. Dimensionnez à partir de l'empreinte de votre base, de la charge de connexions simultanées, du coût du hachage de mots de passe et de votre objectif de disponibilité. Les recommandations de production de ZITADEL conseillent de disposer de quatre cœurs CPU pour les pics de hachage ; les autres outils et profils de trafic exigent leurs propres tests de charge.

Puis-je migrer plus tard d'un CIAM managé vers de l'auto-hébergé ?

Oui, mais planifiez-le comme un vrai projet. Les réinitialisations de mot de passe ne sont pas inévitables : l'exportabilité et les formats de hachage pris en charge varient, et certaines cibles prennent en charge la migration d'utilisateurs en masse ou just-in-time tandis que d'autres imposent une réinitialisation. Les facteurs MFA, les clients OAuth, les sessions actives, l'état de vérification des e-mails et les correspondances de tenants ou de rôles demandent un traitement à part. Si vous soupçonnez déjà que vous auto-hébergerez plus tard, notez ces contraintes d'export et de migration avant de choisir le fournisseur managé.