Du monolithe aux microservices : Quand et comment externaliser l’identité et l’authentification

Pourquoi (et comment) j’ai externalisé l’identité et l’authentification

Ce retour d'experience complete mon positionnement d'expert identite OIDC et microservices pour les equipes qui doivent faire evoluer un existant sans casser la production.

Quand “ça marche” n’est plus suffisant

Au départ, tout est simple : une seule application, un backend monolithique, et une base de données centrale.

L’authentification fait naturellement partie du cœur applicatif : une table users, quelques rôles, une gestion de session maison. Rien d’extraordinaire, et surtout, rien qui pose problème.

Mais ce type d’équilibre ne dure jamais très longtemps. À mesure que le produit grandit, il commence à exister à travers plusieurs applications : une nouvelle interface web, une application mobile, des outils internes (back-office, support, administration), puis progressivement des briques métier indépendantes.

Le monolithe, jusque-là seul maître à bord, doit désormais devenir un fournisseur de services. L’authentification, autrefois simple détail interne, devient soudain un sujet transverse.

Où se connecte-t-on ?
Qui gère les droits ?
Chaque application doit-elle maintenir ses propres identités et ses propres sessions ?

Si la réponse est non à cette dernière question, alors une question structurante apparaît :

Le monolithe doit-il devenir le point central de l’identité ?

Très vite, les enjeux s’imposent :

permettre à toutes les applications de partager un même système d’identité
éviter de réimplémenter la sécurité à chaque nouveau service
faire évoluer l’existant sans tout réécrire

Ce que “passer en microservices” veut vraiment dire

Le faux débat : “microservices ou pas”

À ce stade, la tentation est forte de répondre : microservices. Mais l’objectif réel n’est pas “microservices partout”.
L’objectif, c’est :

créer des frontières claires
stabiliser les interfaces
éviter de casser la production
continuer à livrer du produit

Le découpage n’est pas une fin en soi, c’est un moyen de reprendre le contrôle.

Une trajectoire réaliste

Dans la majorité des organisations, la trajectoire ressemble à ceci :

Court terme : le monolithe devient un API Provider (system of record)
Moyen terme : certaines capacités métier sont extraites vers des services dédiés
Long terme : le monolithe se réduit… ou disparaît progressivement

Autrement dit : on ne détruit pas le monolithe, on l’ouvre.

Le vrai risque quand on ouvre le monolithe

Dès que le monolithe est consommé par autre chose que lui-même, le risque numéro un n’est plus la performance, c’est la sécurité et la gouvernance.
Très vite, il faut gérer :

des tokens via OAuth2 et OpenID Connect
plusieurs types de clients (web, mobile, outils internes)
des rôles et permissions cohérentes
des logs d’audit : qui a fait quoi, quand

C’est là que l’authentification devient un vrai sujet d’architecture.

Découpler sans douleur : Strangler Fig et extraction par capacités

Pour extraire sans tout réécrire, le pattern le plus robuste reste le Strangler Fig Pattern.
Le principe :

le monolithe reste en production
un nouveau service est construit autour d’une capacité métier
le trafic est redirigé progressivement
l’ancien bout est éteint quand tout est stable

On extrait par domaine fonctionnel, pas par couche technique.

Pourquoi l’identité devient centrale

L’identité est différente des autres capacités, elle touche :

tous les fronts
le mobile
les outils internes
les services extraits

C’est un point de passage obligatoire. C’est pourquoi l’externalisation de l’identité est souvent :

une excellente première extraction
mais rarement la toute première chose à faire

Quand externaliser l’auth et l’identité

Les bons déclencheurs

Externaliser devient pertinent dès que l’un de ces signaux apparaît :

plusieurs clients à supporter (web + mobile)
besoin d’une identité unifiée (SSO, MFA)
début de découpage métier
volonté d’éviter que chaque service réimplémente sa propre sécurité

Quand ce n’est pas encore le moment

Si :

un seul front consomme l’application
aucune extraction n’est prévue à moyen terme
l’auth est stable et peu complexe

Alors externaliser trop tôt ajoute souvent plus de complexité que de valeur.

Stratégie clé : une nouvelle identité pour les nouveaux consommateurs

Plutôt que migrer tout le legacy d’un coup :

Mettre en place les nouveaux composants Auth & Identité
Faire passer les nouveaux consommateurs sur cette pile
Laisser l’existant vivre temporairement

Pendant ce temps, le monolithe devient progressivement un resource server :

validation des anciens tokens legacy + des nouveaux access tokens JWT émis par l’IdP
consommation des claims d’identité
maintien partiel des tables legacy si nécessaire

Le point le plus délicat : la migration des utilisateurs

Migration “au fil de l’eau”

Les comptes restent dans le monolithe au départ. À la première connexion via la nouvelle pile :

le compte est migré ou lié (mapping entre l'id legacy et l'id de l’IdP)
puis basculé définitivement

Avantages :

pas de migration massive
rollback possible
risque opérationnel faible

Le bon ordre d’implémentation

Avec le recul, cet ordre est très efficace :

Clarifier le modèle d’identité (user, admin, tenant)
Mettre en place OAuth2 / OIDC
Externaliser les flows self-service
Basculer un seul canal (web ou mobile)
Faire du monolithe un resource server
Retirer progressivement l’ancien auth

Chaque étape est mesurable, réversible et testable.

Conclusion - L’identité comme fondation

Externaliser l’identité n’est pas un simple refactoring technique.

C’est :

poser une fondation durable
simplifier les futures extractions
rendre l’architecture plus lisible
préparer l’intégration d’autres applications

L’identité n’est pas le premier microservice à écrire.
C’est souvent le premier à penser sérieusement.