GetOut Sport
Backend microservices distribué pour une startup de réservation sportive — paiements Stripe orchestrés par Temporal, services polyglottes (Java/Micronaut + Go), identité Ory self-hostée et observabilité de bout en bout.
Rôle : Lead Developer
Vue d'ensemble
GetOut Sport est une startup qui réunit les installations sportives sur une seule plateforme où l'on réserve et joue ensemble. En tant que Lead Developer, j'ai conçu l'architecture backend et piloté le développement — le cœur de mon travail est le backend distribué et orienté paiement, avec des clients iOS, Android et web par-dessus.
Un vrai produit avec du vrai argent : les organisations vendent des réservations, des cours et des abonnements récurrents, donc le backend doit gérer paiements, taxes et facturation au cordeau — et rester correct sous les retries, les requêtes concurrentes et les pannes partielles. Le tout en sortant progressivement d'un monolithe Laravel existant, sans interrompre le produit.
Démo live — Se connecter avec GetOut
Ce portfolio est un vrai client OAuth2 tiers de la plateforme : connectez-vous (ou créez un compte) et autorisez le scope events:read pour afficher vos prochains événements. Les tokens restent côté serveur, en cookies httpOnly.
Chargement…
Cette démo est un vrai client OAuth2
Ce portfolio est enregistré comme application tierce sur l'IdP de production de GetOut. La mettre en place a demandé d'ajouter à la plateforme ce qu'un vrai partenaire exigerait : un écran de consentement (les applications first-party le contournent, les clients tiers y passent) et un scope granulaire events:read qui limite ce site à la lecture seule de vos événements. Le flux est du Authorization Code + PKCE en pattern BFF : les tokens restent dans des cookies httpOnly côté serveur, le JavaScript du navigateur ne les voit jamais.
Une stack Ory self-hostée, quatre composants découplés
- Kratos — la gestion d'identité : credentials, sessions et self-service flows (login, inscription, récupération, vérification d'email), avec mot de passe, code passwordless et login Google/Apple.
- Hydra — le serveur OAuth2/OIDC : access tokens JWT (1 h), refresh tokens rotationnés (détection de vol), PKCE imposé côté serveur à tous les clients publics. Hydra ne stocke aucune identité — il délègue le login à Kratos.
- Oathkeeper — le gateway default-deny devant toutes les APIs : il vérifie la signature du JWT contre le JWKS de Hydra, interroge Keto, puis traduit le token en headers d'identité. C'est du token termination at the edge : les microservices ne parsent jamais de JWT.
- Keto — l'autorisation relationnelle sur le modèle Google Zanzibar : rôles d'organisation hiérarchiques, permissions exprimées comme un graphe de relations, vérifiées par le gateway sur chaque route sensible.
Côté mobile, même flux PKCE via le navigateur système (jamais de WebView — l'app ne voit pas le mot de passe), tokens en Keychain/Keystore.