Isoler le fournisseur
Les choix Keycloak devaient rester à la frontière technique plutôt que se diffuser dans les cas d'usage métier.
Étude de cas
Plateforme d'authentification : rendre l'intégration Keycloak maintenable
Une plateforme d'authentification critique devait être structurée autour de Keycloak sans laisser le fournisseur, le framework ou les intégrations contaminer tout le modèle applicatif.
La mission a combiné architecture logicielle, design backend, architecture hexagonale, bootstrapping monorepo et standards de delivery pour poser une base que les équipes puissent maintenir.
Contexte
Une plateforme sensible, pas un simple connecteur
L'authentification concentre des contraintes de sécurité, d'intégration, de gouvernance et d'évolutivité. Keycloak était un composant central, mais il ne devait pas devenir le modèle interne de toute la plateforme.
Contraintes principales
Rendre les couches utiles
L'architecture hexagonale devait clarifier les responsabilités, pas ajouter des dossiers abstraits sans effet sur la maintenance.
Bootstraper la delivery
Repo, standards, CI/CD et conventions devaient soutenir les prochains incréments au lieu de rester une documentation parallèle.
Décisions
Les décisions qui ont protégé la maintenabilité
Le sujet était moins le pattern en lui-même que la capacité à garder une plateforme critique compréhensible quand les intégrations évoluent.
- 01
Keycloak comme adapter
Les intégrations autour de Keycloak ont été ramenées à des adapters explicites, au lieu de laisser l'outil définir les cas d'usage.
- 02
Ports et use cases lisibles
Les responsabilités applicatives ont été séparées des détails d'infrastructure pour rendre les tests et les changements plus sûrs.
- 03
Monorepo comme support de delivery
La structure du repo, les conventions et les standards ont été alignés avec les boundaries plutôt qu'avec une organisation technique arbitraire.
- 04
Niveau d'abstraction proportionné
Les abstractions ont été introduites là où elles protégeaient un vrai point de volatilité : fournisseur, intégration, tests ou modèle applicatif.
Delivery
Architecture et implémentation dans le même mouvement
Le rôle a combiné cadrage, design backend, contribution engineering et standards de delivery. Les décisions devaient être visibles dans le code, pas seulement dans les diagrammes.
Cadrage des boundaries
Les frontières entre cas d'usage, adapters, fournisseur d'identité et infrastructure ont été clarifiées.
Socle monorepo
La structure de delivery a été posée pour faciliter l'évolution par les équipes qui reprennent la plateforme.
Transmission
Les patterns ont été expliqués par le code et par les conventions afin d'éviter un transfert purement théorique.
Impact
Ce que l'équipe récupère
Sur une plateforme d'identité, la valeur vient de la clarté des frontières et de la confiance à changer les intégrations sans casser le coeur applicatif.
- Boundaries
- Séparation plus nette entre cas d'usage, infrastructure et fournisseur d'identité.
- Keycloak
- Intégration plus contenue, avec moins de dépendance diffuse au fournisseur.
- Delivery
- Monorepo et standards alignés avec la structure applicative.
- Maintenance
- Base plus lisible pour les équipes chargées de poursuivre le produit.
Stack
Technologies et sujets couverts
Le cas renforce surtout l'angle architecture : identity, adapters, boundaries, monorepo et maintenabilité long terme.
Leçon
Un fournisseur critique ne doit pas devenir votre architecture.
Keycloak peut être un excellent composant, mais la plateforme reste plus durable quand le modèle applicatif garde ses propres frontières.