Assaliz
Une plateforme multi-tenant pour écoles, associations étudiantes et opérations campus. J’ai piloté l’architecture plateforme et l’implémentation backend sur l’identité, les permissions, les intégrations et les contrôles de production.
Le code source est privé. Cette étude de cas se concentre sur les frontières système, les contraintes de production et les choix d’implémentation discutables sans exposer de détails sensibles.
- Modèle produit
- SaaS B2B2C multi-tenant
- Type de client
- Écoles & associations étudiantes
- Période
- 2025 — juillet 2026
- Mon rôle
- Lead engineer & architecte plateforme
- Contexte
- Produit commercial privé
- Périmètre
- Architecture · backend · intégration · opérations
01
Surfaces produit
Surfaces produit
Des surfaces distinctes rendaient visibles les responsabilités école, association et campus avant même de regarder l’architecture.
Dashboard admin école
Administration à portée école, gouvernance des accès et supervision opérationnelle.
Espace association
Opérations associatives, paiements, événements et gestion des membres.
Parcours identité campus
Connexion Microsoft, réconciliation des appartenances campus et cycle de session.
02
Problème et contraintes
Problème et contraintes
Assaliz n’était pas un simple portail scolaire. La plateforme devait servir écoles, associations étudiantes et usagers du campus tout en préservant des responsabilités distinctes, des frontières tenant et de l’auditabilité. Les traiter comme de simples utilisateurs aurait rendu permissions, responsabilité et traitement des incidents ambigus.
Acteurs différents, autorités différentes
Administrateurs école, associations et usagers campus ne pouvaient pas partager une couche de permissions plate sans brouiller qui gouverne quoi.
Identité externe, autorisation locale
Microsoft pouvait authentifier les utilisateurs, mais l’accès à portée école et la révocation devaient rester contrôlés par la plateforme.
Plateforme commune, workflows distincts
Paiements, appartenances, domaines, messages et événements dépendent du même contexte tenant sans relever d’une seule surface produit.
Traçabilité opérationnelle
Les actions administratives et les changements côté intégration devaient rester inspectables en production.
03
Mon périmètre exact
Mon périmètre exact
J’ai conçu
- Les frontières tenant et métier entre écoles, campus, associations, appartenances et rôles.
- Le modèle d’identité séparant l’authentification Microsoft de l’autorisation locale.
- Les frontières de session, CSRF et refresh token pour les accès navigateur.
- Les frontières d’intégration autour de la synchro annuaire, des paiements et des services opérationnels.
J’ai implémenté
- Les domaines backend FastAPI et les règles d’autorisation à portée école.
- La connexion Microsoft Entra, la réconciliation Graph des membres et les parcours d’identité campus.
- L’accès par cookies, la rotation du refresh et la validation CSRF associée.
- Les contrôles d’audit, de traçage et de sécurité production autour des requêtes et actions administratives.
J’ai collaboré sur
- Les contrats API partagés utilisés par les surfaces admin, association et campus.
- L’alignement entre les comportements frontend par audience et les règles backend.
- Les choix de déploiement opérationnel autour de l’identité, des paiements et de la configuration tenant.
03
Objectifs
Objectifs
Produit
Donner à chaque public une application dédiée tout en conservant une plateforme et un modèle de données communs.
Identité
Connecter la connexion Microsoft et la synchronisation d’annuaire sans transformer l’annuaire externe en base d’autorisation.
Transactions
Prendre en charge la configuration des paiements associatifs et les opérations financières sous gouvernance de l’école.
Exploitation
Rendre traçables en production les requêtes, actions administratives, jobs asynchrones et erreurs d’intégration.
04
Architecture système
Architecture système
Admin · Association · Campus · Landing
FastAPI · services métier · rôles
PostgreSQL · Redis · stockage objet
Microsoft Graph · paiements · wallets
Les surfaces produit propres à chaque audience sont restées séparées, tandis qu’un backend et un modèle métier partagés imposaient des règles cohérentes et limitaient la duplication.
Stack technique
Surfaces produit
Next.js 16 · React 19 · TypeScript · TanStack Query · Tailwind CSS
Backend
FastAPI · SQLAlchemy · Pydantic · OpenAPI
Données & runtime
PostgreSQL · Redis · Cloudflare R2 · Background workers
Frontières d’intégration
Microsoft Entra ID · Microsoft Graph · Stripe Connect · HelloAsso · Bridge
05
Modèle métier
Modèle métier
Le modèle de données rend la propriété organisationnelle explicite. Les écoles gouvernent les campus, les campus relient utilisateurs et associations via des appartenances, et les opérations financières ou événementielles s’attachent au bon contexte institutionnel plutôt qu’à des utilisateurs génériques.
École
Frontière tenant principale, propriétaire des règles et périmètre opérationnel.
Campus
Contexte d’exécution pour les domaines, les appartenances et les règles d’identité locales.
Association
Entité opérationnelle pour événements, paiements, activités et configuration financière.
Utilisateur et appartenance
Compte local plus relation campus ou association, rôle et état d’accès.
Rôle et portée des permissions
L’autorisation reste à portée école même lorsque l’identité vient d’un annuaire externe.
Compte de paiement et transaction
Les opérations financières associatives restent rattachées à la bonne frontière de gouvernance.
06
Modèle d’états
Modèle d’états
Le cycle d’identité réconcilie une appartenance d’annuaire externe, un rôle campus local et une session révocable indépendamment.
Détecté dans l’annuaire
Un membre de groupe Graph correspond à un domaine campus autorisé.
Appartenance réconciliée
Le compte local et l’appartenance campus sont créés ou mis à jour.
Session active
Les cookies access, refresh et CSRF associé représentent la session authentifiée.
Session renouvelée
La rotation du refresh renouvelle l’accès tout en conservant le contrôle de révocation.
Transitions alternatives
Retrait de l’annuaire
Une appartenance SSO obsolète est désactivée pendant la réconciliation.
Déconnexion ou refresh invalide
La session est révoquée et une nouvelle authentification est requise.
Microsoft gérait l’authentification, mais la plateforme conservait le contrôle local de l’autorisation afin que la révocation et les permissions à portée école restent déterministes.
07
Défis d’ingénierie
Défis d’ingénierie
Identité externe sans autorisation externe
Microsoft porte l’authentification et l’annuaire, mais les permissions produit doivent rester locales, révocables, auditables et limitées à l’école.
Séparer les applications de connexion, synchronisation annuaire et calendrier ; relier les identités fournisseur aux utilisateurs locaux ; réconcilier les appartenances école et persister les rôles dans la plateforme.
La plateforme accepte un délai de synchronisation et doit exploiter des jobs de réconciliation, mais l’autorisation reste déterministe si Microsoft est indisponible.
Si l’annuaire externe devient la base d’autorisation, la révocation, l’auditabilité et les exceptions propres à l’école deviennent fragiles.
Quatre produits sans quatre plateformes
Administrateurs, associations et usagers campus ont besoin de navigations et permissions différentes, mais des contrats et fondations UI dupliqués auraient divergé.
Utiliser des applications Next.js séparées dans un workspace pnpm, des packages UI partagés et des types API générés au-dessus d’un backend métier commun.
La coordination du dépôt et les tests inter-applications sont plus lourds qu’avec un frontend unique, en échange de frontières d’audience visibles.
Si tous les publics partagent une seule surface indifférenciée, responsabilités et contrôles d’accès dérivent vers des conditionnels fragiles.
Sessions navigateur sur sous-domaines tenant
L’authentification cookie traverse des hôtes propres aux écoles et des callbacks OAuth, tandis que les requêtes mutatives doivent résister au CSRF et au rejeu de tokens.
Utiliser des cookies access courts, des refresh tokens persistés et révocables, leur rotation, une validation CSRF associée, des règles CORS strictes et des cookies sécurisés en production.
Le client navigateur et la configuration des callbacks sont plus complexes que des bearer tokens en stockage local, mais l’exposition des tokens est réduite.
Si l’auth navigateur repose sur une gestion permissive des tokens, les callbacks inter-tenant et les requêtes mutatives deviennent plus difficiles à sécuriser et révoquer.
08
Modes d’échec & mitigation
Modes d’échec & mitigation
Synchronisation Graph interrompue en cours de réconciliation
La réconciliation des appartenances reste idempotente et la désactivation des comptes SSO obsolètes est appliquée en sécurité plutôt qu’en supposant qu’une synchro partielle a abouti.
Refresh token invalide ou expiré
La session est révoquée explicitement et le navigateur doit se réauthentifier au lieu de dériver silencieusement vers un état ambigu.
Tentative d’accès inter-tenant
La résolution tenant intervient avant les opérations protégées et les contrôles d’autorisation à portée école sont imposés à la frontière backend.
Panne fournisseur ou dépendance dégradée
L’autorisation locale et l’état tenant persisté restent déterministes même si le fournisseur externe est lent ou indisponible.
Action administrative nécessitant une traçabilité
Des request IDs structurés et des journaux d’audit conservent qui a modifié quoi, dans quel contexte école et via quelle surface.
09
Décisions techniques
Décisions techniques
Surfaces séparées, plateforme partagée
Quatre applications gardent chaque audience focalisée tout en partageant contrats, tooling et backend central.
La synchronisation comme cycle de vie
Les groupes Graph sont paginés, filtrés par domaines autorisés puis réconciliés avec les membres locaux, jusqu’à la désactivation sécurisée des comptes SSO obsolètes.
Sécurité de session à la frontière
Les cookies HttpOnly access et refresh réduisent l’exposition des tokens ; un cookie CSRF associé protège les requêtes mutatives.
10
Sécurité & exploitation
Sécurité & exploitation
Contrôle des abus d’authentification
Les blocages progressifs utilisent Redis lorsqu’il est disponible et exposent un état dégradé lors du fallback mémoire.
Configuration fail-closed
Le démarrage en production refuse les secrets applicatifs ou backoffice faibles au lieu d’accepter silencieusement les valeurs par défaut.
Tests de non-régression sécurité
Des contrôles automatisés couvrent les headers de sécurité, le mode cookie-auth des requêtes et le rendu HTML non sécurisé.
Traçabilité
Les logs structurés masquent les champs sensibles, ajoutent des request IDs et journalisent les actions admin par école sans bloquer les requêtes.
- Pagination Graph et réconciliation déterministe des membres.
- Révocation explicite des sessions et cycle de vie des refresh tokens.
- Traçabilité des décisions sécurité et déploiement.
11
Résultat livré
Résultat livré
Résultats d’implémentation — aucune métrique commerciale non vérifiée.
Un modèle tenant
Écoles, campus et associations partagent des règles de responsabilité explicites plutôt qu’un comportement implicite basé sur l’hôte.
Intégrations remplaçables
Identité, calendrier, stockage, banque et paiements restent derrière des frontières de configuration et de service.
Opérations observables
Requêtes, mutations administratives et jobs de livraison disposent de signaux opérationnels et comportements de retry explicites.
Système de livraison partagé
Quatre applications propres à leurs publics peuvent évoluer sur un contrat API et une base de composants partagés.
Ce que j’en retiens
“Les systèmes multi-tenant deviennent plus lisibles quand les frontières d’audience sont visibles dans les interfaces comme dans le modèle métier.”