Identité et sessions
Inscription avec vérification, login, refresh, MFA, OAuth Google et sessions par appareil. Limites de tentatives et révocation en direct.
Laboratoire
La plateforme où je mets à l’épreuve une vraie architecture
Le hub de services distribués : un noyau qui résout le socle commun —identité, abonnements, encaissements et support— et des tools indépendantes qui s’y branchent.
ARCHITECTURE
Authentification centrale, services simples
Le core concentre l'authentification : il signe les justificatifs et chaque service les vérifie de son côté, avec le même standard que Google et Microsoft utilisent pour connecter leurs services. L'utilisateur se connecte une seule fois, la sécurité se durcit en un seul endroit et une API nouvelle démarre sans refaire le login.
MODULES DU CORE
Ce que résout le core
Six modules que le noyau apporte déjà : identité, argent, tâches de fond, notifications, panneau et sécurité.
Wallet et encaissements
Livre de comptes immuable par utilisateur : les tools déplacent l’argent par la saga reserve/settle/credit, sans jamais écrire la base.
Tâches de fond
Files asynchrones qui s'étendent horizontalement par réplicas, avec tentatives, DLQ et webhooks signés.
Notifications
Email, SMS, WhatsApp et push web, avec newsletter, campagnes et avis in-app : modèles par canal et par langue pour éditer la communication.
Espace utilisateur
Profil, portefeuille, achats, paiements, sessions et avis dans un même panneau au sein du noyau : les tools réutilisent ses composants au lieu d’en monter un chacune.
Sentinel
Un système de sécurité central isolé qui agrège la télémétrie, détecte les attaques distribuées et propage la denylist, avec analyse de comportement et évaluation du risque.
PIÈCES
Ce que chaque décision implique
Quatre décisions soutiennent le système, et chacune laisse une conséquence concrète dès qu’il y a plus d’un produit en jeu.
Le socle commun se règle une fois
Un changement dans le noyau —le login, une règle de sécurité, un encaissement— se déploie une fois et sert à tous les produits.
Ajouter une tool ne touche pas les autres
Une tool nouvelle, c’est un dossier de plus —app, client d’API et API à elle— : elle se déploie seule, sans toucher le noyau ni celles qui tournent déjà.
Les données ne se mélangent pas
Chaque service a sa base et son cache : un changement de schéma ou une suppression restent de son côté et n’atteignent pas les autres.
Une recette pour toutes
Les trois couches —app, client d’API et API serverless— sont les mêmes partout : monter la tool suivante, c’est copier la structure, pas la redécider.
ÉQUIPES AVEC AGENDA
SaaS de réservation en ligne
Le SaaS de réservation de la plateforme : chaque équipe publie son propre site avec son slug, ses services et son calendrier, et n'importe qui réserve sans créer de compte. Le calendrier du professionnel se synchronise dans les deux sens —un engagement déjà pris ailleurs bloque le créneau ici— et son agenda est unique dans toutes les équipes dont il fait partie : deux rendez-vous ne se chevauchent jamais, même entre équipes.
Le parcours d'une requête
- Le site de l'équipeChaque équipe publie sa landing sur son propre slug et la compose section par section ; le plan de l'équipe décide combien de membres entrent et quelles variantes du site sont activées.
- Service, jour et heureLe visiteur choisit un service, un professionnel et un jour ; le calendrier ne propose que les créneaux libres et le blocage tient pendant qu'il termine.
- La réservationL'API écrit le rendez-vous contre un index unique par professionnel et créneau : deux demandes à la même heure ne s'écrasent pas, même en course, et un même professionnel n'est jamais à deux endroits, même sur plusieurs équipes.
- Le calendrier partagéLe rendez-vous entre dans la Calendar API de la plateforme : chaque tool écrit sa couche et le calendrier complet de l'utilisateur se compose à la lecture, avec ce que chaque membre a le droit de voir. Un professionnel occupé dans une autre tool apparaît occupé ici.
- L'aller-retour avec GoogleLa Calendar API est la seule pièce qui parle à Google Calendar, et elle synchronise dans les deux sens : un engagement déjà pris par le professionnel bloque le créneau sur le site, et le rendez-vous confirmé apparaît dans son calendrier.
- Le rappelLe noyau planifie la tâche 24 heures avant et revient avec l'appel signé : le rappel part sans que la tool garde un processus en attente.
- L'équipe confirmeLa personne à l'accueil se connecte avec son compte du noyau et son rôle d'équipe, confirme la réservation et la voit sur le calendrier.
- Hors de la requêteLa réservation est déjà confirmée : la télémétrie et l'événement de sécurité partent en arrière-plan et le sentinel central les croise avec le reste de la plateforme.
Sa propre API serverless, sa base et son cache : du noyau elle prend l'identité, la tâche de rappel et le sentinel, et le calendrier ne vit pas ici —chaque mutation est publiée dans la Calendar API de la plateforme, qui est celle qui synchronise avec Google—.
ENTREPRISES DE MAINTENANCE
Système de maintenance d'ascenseurs
Le système des entreprises qui entretiennent des ascenseurs : copropriétés, immeubles et appareils avec leur fiche technique, visites que le technicien clôture depuis son téléphone —le rapport remplace le groupe WhatsApp— et entretiens qui reviennent mois après mois sans que personne les ressaisisse. Les rôles se composent permission par permission et le plan fixe le nombre d'immeubles, d'appareils, de membres et de récurrences.
Le parcours d'une requête
- Le technicien, sur placeIl ouvre l'app depuis son téléphone avec son compte du noyau : l'API vérifie le jeton contre le JWKS, sans interroger le noyau à chaque requête.
- La fiche de l'appareilCopropriété, immeuble et ascenseur, avec sa fiche technique et son historique : la visite commence en sachant ce qui a été fait la dernière fois.
- La visite et le rapportLe technicien saisit ce qui a été fait et joint le rapport depuis le lieu ; cela reste dans l'historique de l'appareil et dans le mois qui lui revient.
- Le mois qui revientL'entretien se répète mois après mois : le noyau réveille la tâche et revient vers la tool avec la signature, sans que personne ait à y penser.
- La copropriété regardeL'administration se connecte avec son propre rôle et voit les immeubles, les appareils et ce qui arrive à échéance : les permissions appartiennent à la tool, pas au noyau, et le plan fixe le nombre d'immeubles, d'appareils, de membres et de récurrences.
- Hors de la requêteCe qui ne peut pas coûter une seconde au technicien part en arrière-plan : les rejets et les événements de sécurité vont au sentinel central, qui les croise avec le reste de la plateforme.
Elle tourne avec sa propre base et son propre cache : du noyau elle prend l'identité, l'horloge qui réveille les récurrences du mois et le sentinel.
ÉQUIPES DATA
Tableaux de bord sur votre propre feuille
Le service d'analyse : l'utilisateur connecte sa feuille Google Sheets et construit tableaux de bord et rapports par-dessus —les données ne sont ni migrées ni dupliquées : le calcul se fait à la volée et seule la configuration est conservée—. Le jeton de cette connexion est chiffré en AES-256-GCM et ne ressort jamais, et le fournisseur de feuilles vit derrière un port : ajouter Excel ne touche pas au contrat.
Le parcours d'une requête
- La sessionL'utilisateur se connecte avec son compte du noyau et l'API vérifie le jeton sur-le-champ contre le JWKS : aucun appel d'identité par requête.
- La feuille connectéeGoogle Sheets ou Excel entre par OAuth ; la feuille n'est ni migrée ni copiée, elle est lue là où elle est.
- Le jeton chiffréLe jeton de cette connexion reste chiffré (AES-256-GCM) et ne ressort jamais : sans la clé de chiffrement, l'API échoue en fermant.
- Le tableau de bordGraphiques et tableaux sur la feuille ; ce qui est conservé c'est la configuration du tableau, pas une copie des données.
- Le calcul à la voléeQuand le tableau s'ouvre, l'API redemande la feuille et agrège à ce moment-là : le chiffre affiché est celui de la feuille d'aujourd'hui.
- Hors de la requêteLa télémétrie et les événements de sécurité partent en arrière-plan pour le sentinel central ; l'analyse ne les attend pas.
Des six modules du noyau il en utilise deux : l'identité pour la session et le sentinel pour les événements. Tout le reste —la feuille, le jeton chiffré et les tableaux de bord— est à lui.
Envie de le voir en action ?
Le code n'est pas encore public, mais je peux le parcourir avec vous : demandez une démo et je vous montre le core, les tools, la saga du wallet et le sentinel de l'intérieur.
Demander une démo →