Keycloak en production : On-Prem, IaaS, Marketplace, PaaS ou SaaS

Quelle complexité êtes-vous vraiment prêt à assumer ?

Vous avez choisi Keycloak. Bon choix. Maintenant la vraie question : qui va le maintenir en production ?

Déployer Keycloak, c'est l'affaire d'un week-end. L'opérer en production, c'est un travail à plein temps.

Derrière chaque instance Keycloak en production, il y a une base de données qui nécessite du connection pooling et du failover. Une couche de cache qui doit rester synchronisée entre les nœuds. Des mises à jour qui touchent le schéma de base de données et cassent des extensions que vous aviez oubliées. Une supervision qui va bien au-delà de "est-ce que le conteneur répond ?" jusqu'à "pourquoi la JVM vient-elle de consommer 4 Go de heap un samedi à 3h du matin ?"

La façon dont vous déployez Keycloak détermine qui dans votre équipe devra gérer tout ça. Et la taille de cette équipe change plus que vous ne l'imaginez.

On-Prem : vous prenez tout en charge

Le Keycloak on-prem, c'est la propriété totale de la stack. Du rack à la configuration des realms, tout vous appartient.

Ce que vous devez gérer :

• Provisionner et maintenir des serveurs physiques ou virtuels
• Mettre en place et gérer une base de données de production (PostgreSQL, MySQL...)
• Configurer le connection pooling, les sauvegardes, le failover
• Déployer et tuner Infinispan / JGroups pour le clustering et le cache
• Gérer les certificats TLS, les load balancers, les reverse proxies
• Planifier et exécuter les mises à jour de version Keycloak, et les migrations de base de données qui vont avec
• Gérer les thèmes personnalisés, les SPIs et les extensions
• Surveiller tout : métriques JVM, performances de la base, taux de hit du cache, erreurs HTTP, logs
• Planification de la capacité et scaling

Le profil d'équipe requis :

Des ingénieurs infrastructure. Un DBA. Au minimum une personne qui connaît les internals de Keycloak suffisamment bien pour déboguer un rolling upgrade raté à 2h du matin. Et un DevOps/SRE pour maintenir le tout. Ce n'est pas un projet annexe, c'est une équipe dédiée.

Quand choisir ce modèle :

Si vous disposez déjà d'une équipe infrastructure, d'un DBA et de personnes qui connaissent Keycloak sur le bout des doigts — l'on-prem fonctionne. Point. Ces équipes existent dans les grandes organisations, et si vous en avez construite une, il n'y a aucune raison de la remettre en question. L'on-prem fait également sens quand les régulateurs exigent un contrôle physique de votre infrastructure, ou quand vous avez besoin d'un niveau de personnalisation que seule la propriété totale de la stack 

peut offrir.

IaaS (AWS, Exoscale, GCP...) : le hardware disparaît, les ops restent

Passer à l'IaaS enlève le hardware de vos mains. Vous obtenez des VMs ou du Kubernetes managé, des bases de données managées (RDS, Cloud SQL, etc.) et des load balancers managés. Le cloud gère la couche physique. Keycloak, lui, reste votre problème.

Ce que vous devez gérer :

• Choisir et configurer des VMs ou des clusters Kubernetes
• Déployer Keycloak (Helm charts, Docker Compose, ECS tasks...)
• Configurer la base de données managée (sizing, sauvegardes, limites de connexions, failover)
• Mettre en place et tuner le clustering Infinispan entre les nœuds
• Gérer les mises à jour Keycloak et les migrations de base de données
• Construire et maintenir les extensions et thèmes personnalisés
• Mettre en place la supervision et les alertes pour les métriques spécifiques à Keycloak
• Gérer les politiques de scaling et la haute disponibilité

Le profil d'équipe requis :

Personne ne monte plus de serveurs, mais vous avez toujours besoin de personnes qui comprennent le côté opérationnel de Keycloak en profondeur. Que se passe-t-il avec les sessions Infinispan pendant un rolling upgrade ? Comment le connection pool se comporte-t-il quand votre base de données managée atteint le maximum de connexions ? Comment migrer de Keycloak 24 à 26 sans bloquer la moitié de vos utilisateurs ?

Vous avez besoin d'un spécialiste infrastructure Keycloak — quelqu'un qui connaît le produit depuis les JVM flags et la configuration Quarkus, pas seulement depuis la console d'administration.

Quand choisir ce modèle :

Si votre équipe vit déjà dans AWS, GCP ou Exoscale et sait opérer des services dans cet environnement, c'est un choix naturel. Vous utilisez les briques de base du cloud — bases de données managées, load balancers, supervision — et votre équipe comble les lacunes spécifiques à Keycloak. La question est simple : avez-vous, ou voulez-vous construire, une équipe capable d'assumer les opérations Keycloak sur le long terme ?

Cloud Marketplace (Exoscale, AWS Marketplace...) : un clic pour déployer, des mois de maintenance

Certains cloud providers proposent Keycloak sous forme d'image dans leur marketplace. Exoscale, par exemple, vous permet de lancer une instance en quelques minutes. Le premier jour se passe sans accroc.

Le trentième jour, c'est une autre histoire.

Le provider déploie. Vous maintenez. L'image marketplace ne se met pas à jour automatiquement. Le cloud provider ne va pas upgrader Keycloak pour vous, exécuter les migrations de base de données, tuner le cache, ni expliquer pourquoi votre thème personnalisé a cassé après une montée de version.

Ce que vous devez gérer :

• Les upgrades Keycloak et les migrations de version
• La gestion de la base de données, les sauvegardes, le tuning des connexions
• La configuration Infinispan / cache quand vous passez au-delà d'un nœud unique
• La gestion des extensions et des thèmes à travers les mises à jour
• La supervision, les correctifs de sécurité et la gestion des incidents
• La mise en place de la haute disponibilité si vous avez besoin de plus d'une instance

Ce que le provider gère :

• La VM initiale et le déploiement
• L'infrastructure de base (réseau, stockage, compute)
• Parfois une option de base de données managée en complément

Le profil d'équipe requis :

Voilà le piège : le déploiement en un clic crée une illusion de simplicité. C'est simple — le premier jour. Au trentième, quand une nouvelle version de Keycloak sort et que votre environnement de staging ne démarre plus après la migration, vous réalisez que vous avez besoin d'un expert Keycloak comme dans le cas de l'IaaS. Vous avez juste gagné du temps sur la configuration initiale.

Quand choisir ce modèle :

Si vous êtes déjà sur ce cloud provider et que vous avez besoin de Keycloak rapidement pour un POC ou une charge de travail modeste, le marketplace est un bon point de départ. C'est également valable si votre équipe est prête à prendre en charge les opérations dès le deuxième jour. Mais entrez dans cette voie les yeux ouverts : le clic unique, c'est pour le déploiement, pas pour la gestion.

PaaS (Clever Cloud, Railway...) : moins d'infrastructure, même complexité Keycloak

Un PaaS enlève une couche supplémentaire. Plus de VMs, plus de Kubernetes. Vous poussez votre application, la plateforme gère le déploiement, le scaling et souvent la base de données.

L'infrastructure se simplifie. Pas Keycloak.

Ce que vous devez gérer :

• Configurer Keycloak pour l'environnement et les contraintes de la plateforme
• Gérer le connection pooling et le sizing de la base de données — même avec des DBs managées, Keycloak a des besoins spécifiques
• Gérer les upgrades Keycloak — le PaaS ne le fera pas pour vous
• Gérer la configuration Infinispan / cache pour les setups multi-nœuds
• Déployer et maintenir les extensions, SPIs personnalisés, thèmes
• Comprendre le comportement de clustering de Keycloak dans l'environnement PaaS
• Surveiller la santé et les performances spécifiques à Keycloak

Le profil d'équipe requis :

La charge de l'infrastructure est plus légère. L'exigence d'expertise Keycloak est quasi-identique à celle de l'IaaS. La plateforme exécute vos conteneurs et votre base de données. Elle ne sait pas que Keycloak 25 a changé le format de sérialisation Infinispan, ni que votre SPI personnalisé va casser après l'upgrade. Quelqu'un dans votre équipe doit le savoir. Cette personne reste un spécialiste Keycloak.

La question qu'ils devront se poser, encore et encore : "C'est un problème lié à Keycloak ou un problème lié à la plateforme ?"

Quand choisir ce modèle :

Si votre équipe utilise déjà Clever Cloud, Railway ou un autre PaaS et qu'elle y est à l'aise, déployer Keycloak dessus est une option naturelle. La plateforme prend en charge une vraie partie du travail opérationnel, et votre équipe peut concentrer son énergie sur les aspects spécifiques à Keycloak. Si vous avez, ou êtes prêt à construire, cette expertise Keycloak, c'est un choix solide.

SaaS (Cloud-IAM) : concentrez-vous sur l'IAM, nous gérons le reste

C'est là que le modèle change fondamentalement.

En SaaS, vous ne déployez pas Keycloak. Vous ouvrez un dashboard, créez un realm, configurez un client OIDC pour votre application et mettez en place le login flow. Le temps de finir votre café, vos utilisateurs peuvent s'authentifier. Vous n'avez jamais touché une base de données. Vous n'avez jamais pensé à Infinispan. Vous n'en aviez pas besoin.

Ce que nous gérons :

• Provisionnement de la base de données, pooling, sauvegardes, failover
• Clustering Infinispan et gestion du cache
• Upgrades et migrations de version Keycloak (zéro downtime)
• Gestion des extensions et compatibilité
• Haute disponibilité et scaling
• Supervision, alertes et gestion des incidents
• Correctifs de sécurité
• TLS, DNS, load balancing

Ce sur quoi vous vous concentrez :

• Configurer vos realms, clients et flows d'authentification
• Mettre en place la fédération d'identité (SAML, OIDC, social logins)
• Définir les politiques d'autorisation et les rôles
• Intégrer vos applications avec Keycloak
• Gérer les utilisateurs et les accès

Le profil d'équipe requis :

Un spécialiste IAM. Quelqu'un qui comprend la gestion des identités et des accès — pas quelqu'un qui sait tuner une JVM ou migrer un cache Infinispan.

Nous avons construit Cloud-IAM pour qu'un développeur ou un architecte puisse configurer ses besoins en identité sans devenir expert des internals de Keycloak au préalable. Vous n'avez pas besoin d'une équipe IAM dédiée. Vous avez besoin de quelqu'un qui comprend ce que vos flows d'authentification doivent faire.

La vraie comparaison : ce qui change à chaque niveau

Regardez la dernière ligne. C'est la seule qui devrait retenir votre attention. C'est tout l'enjeu.

Ce n'est pas une question d'infrastructure — c'est une question d'équipe

Voici ce que faire tourner Keycloak en production coûte vraiment. Pas la facture cloud. Le coût humain.

Un Keycloak self-managed, c'est trouver et garder des personnes qui comprennent :

• Comment les connection pools de PostgreSQL interagissent avec le pool interne de Keycloak — et ce qui se passe quand les deux pensent gérer les connexions inactives
• Ce qui se passe avec les sessions distribuées quand un nœud Infinispan quitte le cluster
• Comment effectuer un rolling upgrade de Keycloak 24 à 26 sans bloquer des utilisateurs en cours de session
• Comment les SPIs et providers personnalisés se comportent après une montée de version majeure — spoiler : pas toujours bien
• Pourquoi votre JVM consomme 4 Go de heap un dimanche matin quand personne ne se connecte

Ce sont de vrais problèmes. Trouver des personnes capables de les résoudre est coûteux. Les retenir, encore plus.

Avec Cloud-IAM, vous n'avez pas besoin de cette équipe. Pas parce que les problèmes disparaissent — ils ne disparaissent pas. Nous les traitons chaque jour. C'est notre métier. Votre métier, c'est de construire votre produit.

Ce dont personne ne parle : l'expertise

Il existe un coût plus subtil à l'auto-gestion de Keycloak qui n'apparaît pas dans les organigrammes. Il s'agit de la direction.

Les équipes on-prem sont réactives. Ce ne sont pas des équipes Keycloak — ce sont des équipes infrastructure qui gèrent aussi Keycloak. Personne ne se lève en pensant à comment améliorer vos flows d'authentification. Ils se lèvent parce que quelque chose a cassé. Keycloak est l'un des quarante services qu'ils maintiennent, et il ne reçoit de l'attention que quand il l'exige. Personne n'a pour mission de demander : "Est-ce qu'on utilise vraiment Keycloak bien, ou est-ce qu'on le maintient juste en vie ?"

Aller solo sur Keycloak sans accompagnement, c'est brutal. La documentation est exhaustive mais immense. La surface de configuration est vaste. 

Sans quelqu'un qui a déjà résolu les mêmes problèmes sur des centaines de déploiements, vous repartez de zéro à chaque fois.

L'IaaS et le PaaS aggravent les choses. La responsabilité est partagée entre votre équipe et le provider, et personne ne possède la vue d'ensemble. Ce problème de session timeout, c'est un problème de configuration Keycloak, un problème de pooling de base de données, ou une bizarrerie réseau de la plateforme ? Quand trois parties se partagent la responsabilité, la réponse est toujours 

"pas mon périmètre."

Le SaaS change fondamentalement la dynamique.

Un provider SaaS ne se contente pas d'héberger votre logiciel. Il a un objectif — un point de vue sur ce que le produit doit faire pour vous. Chez Cloud-IAM, le nôtre est simple : rendre l'IAM open-source accessible. Cet objectif unique façonne tout ce que nous construisons, chaque interaction avec nos clients, chaque décision sur ce qu'il faut automatiser.

Et cet objectif nous donne quelque chose que les setups self-managed ne peuvent pas reproduire : la reconnaissance de patterns à travers des centaines de déploiements. Nous savons quelles configurations posent problème à grande échelle. Nous savons quels flows d'authentification fonctionnent pour quels secteurs. Nous savons quand la configuration d'un client se dirige vers un mur qu'il n'a pas encore vu — parce que nous l'avons vu des dizaines de fois avant.

Quand vous vous gérez vous-même, vous êtes la première personne à rencontrer votre combinaison spécifique de problèmes. Quand vous utilisez un SaaS spécialisé, vous bénéficiez de l'expérience de chaque client qui est passé avant vous.

"Mais je perds le contrôle"

Objection légitime. Répondons-y directement.

Avec Cloud-IAM, vous gardez le contrôle total sur tout ce qui compte pour votre application :

• Vos realms, clients et flows — entièrement configurables, comme avec un Keycloak self-hosted
• Vos données — c'est votre instance, vos données, votre configuration
• Vos intégrations — protocoles OIDC/SAML standards, pas de vendor lock-in
• Vos extensions — les thèmes et providers personnalisés sont supportés

Ce que vous abandonnez, c'est la charge opérationnelle. Les alertes à 2h du matin. Les week-ends de mise à jour. Les sessions de débogage Infinispan. Ce n'est pas perdre le contrôle — c'est choisir où votre équipe investit son énergie.

Quelle équipe avez-vous ?

C'est la question qui devrait guider votre décision. Pas "quel est le meilleur modèle de déploiement ?" mais "quel est le meilleur modèle pour l'équipe que j'ai aujourd'hui ?"

Vous avez déjà une équipe Keycloak ? Vous avez le choix. Si votre équipe peut opérer Keycloak en production — upgrades, migrations, cache tuning — déployez-le où ça fait sens. On-prem, IaaS, PaaS, marketplace. Cette expertise est un vrai atout.

Vous avez une équipe plateforme sur un cloud ou PaaS spécifique ? Déployez Keycloak là-bas. Vos ingénieurs connaissent déjà la plateforme, 

les lacunes à combler sont uniquement du côté Keycloak.

Vous n'avez ni l'un ni l'autre — et vous ne voulez pas le construire ? C'est là que Cloud-IAM s'applique. Et c'est la situation de la plupart des équipes.

Cloud-IAM a le plus de sens quand :

• Vous voulez Keycloak sans construire une équipe ops Keycloak
• Votre équipe comprend l'IAM mais pas l'infrastructure Keycloak
• Vous êtes une startup qui a besoin d'un IAM enterprise-grade sans headcount enterprise
• Vous êtes une organisation plus grande qui veut arrêter de dépenser des cycles d'ingénierie sur l'infrastructure d'identité
• Vous avez vécu un upgrade Keycloak qui a mal tourné et ne voulez plus jamais revivre ça
• Vous préférez mettre votre budget engineering dans votre produit plutôt que dans le maintien en vie de Keycloak

En résumé

Le passage de l'on-prem au SaaS ne porte pas sur la localisation de vos serveurs. Il porte sur qui a besoin de savoir quoi.

• On-prem : vous avez besoin d'ingénieurs infrastructure, base de données ET Keycloak
• IaaS : vous avez toujours besoin de spécialistes infrastructure Keycloak
• Marketplace : le premier jour est facile. Au trentième, vous avez toujours besoin de spécialistes infrastructure Keycloak
• PaaS : la plateforme aide sur les ops. L'expertise Keycloak reste votre responsabilité
• SaaS (Cloud-IAM) : vous avez besoin de quelqu'un qui comprend l'IAM. Ce peut être un développeur

Nous avons construit Cloud-IAM pour que votre équipe puisse se concentrer sur la création d'expériences d'authentification de qualité plutôt que sur le débogage de cluster splits Infinispan à 3h du matin.

Vos utilisateurs ne se soucient pas de la façon dont Keycloak est hébergé. Ils veulent juste que la connexion fonctionne.