Authlete — SRE OAuth/OIDC pour des banques japonaises
J'ai opéré et industrialisé les déploiements d'Authlete sur trois modèles de delivery — on-prem, SaaS isolé, SaaS partagé — pour des clients bancaires japonais.
- GCP
- Kubernetes
- Helm
- Terraform
- GitLab-CI
- Java
- JUnit
- Ruby
- OAuth 2.0
- OpenID Connect
Contexte
Authlete vend de l’authentification OAuth 2.0 et OpenID Connect à des banques, principalement japonaises. Trois modèles de delivery cohabitent : on-premise (le client héberge), SaaS isolé (une instance dédiée par client) et SaaS partagé. Chaque modèle a ses contraintes de sécurité, de réseau et de compliance.
L’enjeu : industrialiser ces trois modèles avec un seul socle de templates, garder les versions legacy supportables aussi longtemps que les clients en ont besoin, et tenir la barre de conformité OAuth / OIDC à chaque release.
Mon rôle
SRE & DevOps. J’ai owned les templates de déploiement, les pipelines CI/CD multi-versions, et l’opération SaaS sur GCP.
Ce que j’ai construit
- Déploiements SaaS sur GCP opérés au quotidien
- Templates Kubernetes avec Helm + Terraform, conçus pour être cloud-agnostiques afin de servir aussi les clients on-prem sans embranchement majeur de code
- Pipelines GitLab-CI capables de builder et tester chaque version legacy du service en parallèle, parce qu’on ne peut pas demander à un client bancaire de migrer du jour au lendemain
- Suite de tests Java JUnit : unitaires + intégration
- Suite de tests Ruby : end-to-end + performance
- Tests de conformité OAuth 2.0 / OpenID Connect intégrés au pipeline, parce qu’un service d’auth qui dérive de la spec n’est plus un service d’auth
- Réduction massive du temps entre “un dev pousse un correctif” et “le correctif tourne en SaaS chez les clients”
Le point dur : tenir la matrice (modèle de delivery × version supportée × cloud cible) sans la transformer en dette de configuration ingérable.
Résultats
Productivité dev fortement augmentée : les changements traversent la chaîne de tests automatisée au lieu d’attendre des cycles de QA manuelle. La même base de templates dessert SaaS et on-prem, ce qui réduit la charge cognitive de l’équipe SRE.