J'ai recommandé Azure AD. La direction client a imposé Keycloak. Voici le bilan honnête.

Image générée avec Nano Banana

Vous refondez une plateforme digitale. Nouvelle stack, migration cloud, changement d’outil de BI. Parmi les dizaines de décisions à prendre, il y en a une qui semble secondaire — et qui va pourtant vous engager pour les cinq prochaines années : comment gérer l’authentification.

Le client avait déjà un Keycloak en production. Azure AD était aussi dans le SI. Avec mon responsable Cloud, j’ai recommandé Azure AD. La direction Cloud du client a imposé Keycloak. Le résultat technique a été bon. Le bilan économique est plus nuancé.

Ce n’est pas une histoire où le consultant avait tort et le client raison. C’est une histoire où chacun voyait une partie des coûts — et où personne n’avait la vision complète.

Voici ce que ça m’a appris.

Ma vraie préoccupation : le forfait, pas les technos

Je connaissais Keycloak. Je connaissais Azure AD. J’avais pratiqué les deux sur des projets différents. Ma préférence initiale n’était pas une question de technologie — c’était une question de contexte projet.

La mission était au forfait. Un nombre de jours défini, un périmètre à tenir. Dans ce type de cadrage, chaque chantier supplémentaire est un risque sur les délais. Déployer et configurer Keycloak de zéro, dans un projet qui refondait simultanément la stack, l’hébergement et la BI, c’était ajouter un chantier IAM complet à une liste déjà longue.

L’architecte cloud référent du projet partageait cette lecture. Sa recommandation Azure AD reposait sur la même logique : Azure AD était déjà dans le SI, le provisioning était quasi nul, et on pouvait se concentrer sur les migrations critiques. Ce n’était pas un arbitrage technique — c’était un arbitrage de risque projet.

La direction Cloud du client a tranché autrement. Pas pour des raisons fonctionnelles, mais pour des raisons de gouvernance : Keycloak était déjà dans leur référentiel, l’équipe avait une compétence dessus, et ils ne voulaient pas d’une dépendance supplémentaire envers Microsoft. C’est une logique légitime — mais c’est une décision qui s’est prise au-dessus de l’équipe projet, sans en voir toutes les implications opérationnelles.

Ce que “mettre Keycloak en production” implique vraiment

Keycloak est un excellent outil d’Identity and Access Management. Open source, maintenu par Red Hat, il supporte SAML2, OIDC, le multi-tenant par realms, les flows d’authentification personnalisés. Sur le papier, c’est le choix évident pour qui veut garder le contrôle.

Mettre un Keycloak en production, ce n’est pas installer un conteneur Docker et passer à autre chose.

Voici ce que ça implique concrètement :

• Configurer les realms : paramètres de sécurité, politiques de mot de passe, durée des sessions, tokens.
• Choisir et implémenter les protocoles : SAML2, OIDC, ou les deux selon les partenaires. Chaque protocole a ses subtilités d’intégration.
• Provisionner l’infrastructure cloud : compute, base de données, réseau, certificats TLS, backups, haute disponibilité.
• Monitorer et maintenir : alerting, logs, montées de version, patches de sécurité.
• Disposer des compétences : quelqu’un dans l’équipe doit comprendre Keycloak en profondeur — pas juste l’installer, mais le déboguer à 2h du matin quand un IdP ne répond plus.

Mais deux coûts passent souvent sous le radar.

Le thème personnalisé

Nous avons modifié le parcours de connexion : l’utilisateur saisit d’abord son email, et Keycloak détermine automatiquement s’il doit afficher le champ mot de passe ou rediriger vers l’IdP de son entreprise. Ce flow non standard — nécessaire pour notre cas d’usage — rendait impossible l’utilisation du thème Keycloak par défaut.

Il a fallu développer un thème complet aux couleurs du projet : écran de connexion, mot de passe oublié, email de réinitialisation, pages d’erreur. C’est un chantier front-end qui ne figure dans aucun sizing initial d’un projet Keycloak — parce que quand on l’estime, on n’a pas encore finalisé le flow d’auth.

L’onboarding des fournisseurs, un par un

Chaque nouveau partenaire ou client qui s’intègre en SSO nécessite une réunion de cadrage dédiée : établir le pont entre leur SI et Keycloak, valider les métadonnées SAML ou les endpoints OIDC, tester la fédération. Ces réunions sont courtes — mais elles existent, elles mobilisent du temps des deux côtés, et elles se répètent à chaque nouveau fournisseur.

Avec une solution comme Azure AD External Identities ou Okta, cette intégration est souvent plus standardisée, avec des guides d’intégration prêts à l’emploi et une interface de configuration qui réduit les allers-retours. Le coût par fournisseur est plus faible.

Instance dédiée ou realm partagé : le multiplicateur invisible

Sur ce projet, le client avait déjà un Keycloak en production pour d’autres applications. Plutôt que de créer un realm supplémentaire dans l’instance existante, il a choisi de déployer une instance dédiée — pour des raisons de séparation des responsabilités.

C’est un choix raisonné. Mais c’est un choix qui a un prix.

Les arguments pour l’instance dédiée sont solides : isolation totale de l’infrastructure et des données, blast radius limité en cas d’incident, autonomie de l’équipe projet sur son cycle de vie. Les arguments pour le realm partagé le sont aussi : une seule infrastructure à maintenir, mutualisation des politiques de sécurité, coûts cloud maîtrisés.

Le coût réel de la séparation, c’est la multiplication : chaque instance supplémentaire, c’est sa propre infrastructure cloud à provisionner, son propre monitoring à configurer, ses propres montées de version à planifier. Chaque bonne raison d’ajouter une instance multiplie le TCO.

Là où Keycloak avait un atout que j’avais sous-pondéré

J’avais correctement évalué la charge opérationnelle de Keycloak. Ce que j’avais sous-estimé : la valeur de sa flexibilité dans un contexte de migration.

Le problème hérité du legacy

Le projet consistait à remplacer une plateforme existante. Dès les ateliers de cadrage, les utilisateurs avaient remonté des pain points majeurs liés à l’authentification :

• Rotation des mots de passe obligatoire tous les X jours.
• À chaque rotation, envoi d’un code temporaire par email.
• Chez certains clients, les politiques de sécurité réseau ou les proxies bloquaient ou retardaient la réception de cet email — rendant le code temporaire caduque avant même d’arriver.
• Résultat : des utilisateurs bloqués régulièrement, du support en cascade, de la frustration.

La solution : deux modèles d’auth dans un même realm

Keycloak permettait de faire cohabiter deux modèles d’authentification dans un même realm :

• Comptes locaux (email + mot de passe) pour les utilisateurs migrés depuis le legacy — continuité d’expérience, sans big bang.
• Comptes SSO (SAML2 ou OIDC) pour les nouveaux clients, ou pour ceux dont le service IT pouvait configurer la fédération rapidement.

Cette cohabitation permettait une migration progressive : on embarque les utilisateurs existants sans friction, et on propose le SSO aux nouveaux. Chaque client migre à son rythme, selon la maturité de son service IT.

Azure AD peut offrir cette flexibilité — via Azure AD B2C ou External Identities — mais le coût est significativement plus élevé. Quand le besoin fonctionnel est spécifique, Keycloak offre une souplesse que les solutions SaaS facturent cher ou ne proposent qu’en mode enterprise.

Ce qui s’est passé en réalité

Deux choix techniques ont rendu la migration viable.

Le plugin Home IDP Discovery : l’écran de connexion est scindé en deux étapes. L’utilisateur saisit son email. Keycloak détecte automatiquement le mode d’authentification associé. S’il s’agit d’un compte local, le champ mot de passe s’affiche. S’il s’agit d’un compte SSO, l’utilisateur est redirigé de manière transparente vers le gestionnaire d’identité de son entreprise. Pas de choix à faire, pas de confusion. (C’est ce flow qui a nécessité le thème personnalisé.)

La réconciliation automatique par email : quand un client active le SSO, ses utilisateurs existants — qui avaient jusque-là un compte local — sont automatiquement rattachés à leur compte SSO via une réconciliation sur l’adresse email. Pas de migration manuelle, pas de double compte.

Aujourd’hui, la plateforme compte 5 Identity Providers intégrés, plusieurs centaines d’utilisateurs professionnels, et un ratio de 70% de comptes SSO contre 30% de comptes locaux. La migration progressive a fonctionné.

Le bilan TCO honnête

C’est là que le bilan dépasse la question technique.

Azure AD aurait coûté plus cher en licences — c’est prévisible, budgétable, et documenté. Keycloak coûte zéro en licences — mais les coûts sont ailleurs, et ils ont tendance à grossir dans la durée.

Le thème personnalisé, c’est du développement front-end non prévu. L’onboarding des fournisseurs, c’est du temps consultant à chaque nouveau partenaire. L’infrastructure dédiée, c’est du cloud et du monitoring à maintenir. Et la TMA — le coût de maintien en condition opérationnelle sur la durée — est structurellement plus élevée avec Keycloak qu’avec une solution managée.

Le choix Keycloak a déplacé le coût : moins de licence, plus de TMA. Ce n’est pas irrationnel — selon la trajectoire du projet, ce déplacement peut même être avantageux. Mais il faut le voir. Trop souvent, le coût de licence est visible dans les comparatifs et le coût de TMA ne l’est pas — parce qu’il se dilue dans les équipes, sur plusieurs trimestres, sans ligne budgétaire dédiée.

La matrice de décision

Après avoir pratiqué Keycloak, Azure AD, Okta, JumpCloud et Reachfive sur différents projets, voici les critères qui, selon moi, doivent guider le choix.

Le Build (Keycloak) a du sens quand :

• Vous avez une équipe IAM dédiée en interne, avec une gouvernance claire.
• Vous avez un besoin de personnalisation forte — flows d’authentification non standard, cohabitation de modèles d’auth.
• Vous avez des contraintes de souveraineté ou d’hébergement des données.
• Votre volume d’utilisateurs rend le pricing SaaS prohibitif.
• Vous maîtrisez la stratégie multi-tenant : des realms, pas des instances.
• Vous devez migrer progressivement des utilisateurs depuis un legacy, avec cohabitation de modèles d’authentification.
• Votre projet n’est pas au forfait — ou vous avez des marges claires pour absorber les chantiers transverses.

Le Buy (Azure AD, Okta, JumpCloud) a du sens quand :

• Un IAM est déjà en place dans le SI — le coût d’adoption est quasi nul.
• Vous n’avez pas l’équipe pour maintenir un Keycloak en production sur la durée.
• Le time-to-market est critique, ou vous êtes en contexte de refactoring lourd.
• Vous avez besoin d’un écosystème d’intégrations prêt à l’emploi.
• Vous voulez déléguer le monitoring, l’alerting et la gestion des IdP.
• Votre migration legacy est simple ou inexistante.
• Vous optimisez la prédictibilité des coûts sur la durée — TMA prévisible plutôt que licence fixe.

Le critère discriminant si vous êtes dans les deux colonnes : posez cette question à l’équipe — qui maintient l’IAM dans 18 mois, et est-ce que cette personne sait ce que ça implique ? Si la réponse est floue, le Buy est probablement plus sûr, quelle que soit la flexibilité technique en jeu.

Et parfois, c’est les deux : un CIAM en SaaS pour le B2C, un Keycloak en self-hosted pour le workforce. Ou un Keycloak comme broker de fédération devant un Azure AD. Le monde réel ne rentre pas toujours dans une case.

Ce que je retiens

Quatre questions que je pose systématiquement avant tout choix IAM — et que je n’aurais pas toutes posées à l’époque.

Quelle est la complexité de votre chemin de migration ? Si vous avez un legacy avec des utilisateurs existants et des partenaires hétérogènes, la flexibilité technique n’est pas un luxe — c’est une nécessité fonctionnelle. Ce critère doit peser autant que la charge opérationnelle.

Qui maintient l’IAM dans 18 mois ? Pas “qui peut le faire”, mais qui va concrètement le faire, en plus de quoi, avec quel niveau de priorité. Le coût le plus dangereux est celui qu’on ne voit pas : le temps de l’ingénieur qui fait le run Keycloak en marge de son travail quotidien n’apparaît dans aucun budget — jusqu’au jour où il part.

Votre projet absorbe-t-il les chantiers transverses ? Un flow d’auth non standard implique un thème custom. Une migration hybride implique de l’onboarding fournisseur. Si votre enveloppe projet ne prévoit pas ces lignes, elles seront absorbées par d’autres — en heures non facturées, en délais dépassés, ou en dette technique.

Quel coût préférez-vous tracer ? Licence ou TMA — les deux existent, les deux ont un impact réel. La différence, c’est que la licence apparaît dans les comparatifs et la TMA dans les bilans trimestriels. Décidez lequel vous êtes le mieux équipé pour piloter.

Le choix IAM engage pour 3 à 5 ans minimum. Il mérite une conversation d’architecture — pas un ticket dans le backlog.

Conclusion

Build vs Buy n’est pas un faux débat. C’est le mauvais niveau d’abstraction.

La vraie question, c’est : quelle complexité êtes-vous en mesure d’internaliser, et laquelle avez-vous intérêt à déléguer ?

La complexité opérationnelle — infrastructure, monitoring, montées de version, thème, onboarding fournisseurs — le Buy l’absorbe bien. La complexité fonctionnelle — migration hybride, cohabitation de modèles d’auth, contraintes de souveraineté — le Build la gère mieux.

Posez la question dans cet ordre. Et avant de poser la question technique, posez la question de contexte : votre projet est-il en mesure d’absorber les coûts cachés du Build — pas seulement en termes de budget, mais en termes de temps, de compétences disponibles, et de risque calendaire ?

Le choix d’outil suivra naturellement.

Guillaume P. — Engineering Manager | Cloud · Security · Identity