Référence d’application. Il s’agit d’une architecture illustrative et d’une liste de contrôle du périmètre, et non d’un projet client vérifié ou d’un déploiement mesuré. Les technologies, le périmètre d’intégration et les éléments livrés sont définis d’un commun accord pour le cahier des charges réel.
Scénario et contraintes
Un produit destiné à servir de nombreuses organisations clientes depuis un seul déploiement. La décision qui détermine tout est le modèle d’isolation : tables partagées avec une colonne de locataire, un schéma par locataire ou une base de données par locataire. Choisir par défaut plutôt que délibérément constitue l’erreur la plus coûteuse dans cette catégorie, car le modifier ultérieurement implique de migrer les données des clients en production.
Architecture
Couches et responsabilités
| Couche | Technologie | Responsabilité |
|---|---|---|
| Web | Next.js (SSR pour le marketing et le SEO, SPA après connexion) | Les pages publiques bénéficient d’un rendu côté serveur pour leur visibilité dans les moteurs de recherche ; le produit authentifié n’en a pas besoin et reste une application côté client. |
| API | Go + Gin, locataire déterminé pour chaque requête | Le contexte du locataire est déterminé à partir du sous-domaine ou du jeton avant l’exécution de tout gestionnaire, puis transmis à chaque requête. |
| Stockage | PostgreSQL, schéma partagé avec filtrage des lignes par locataire | Une base de données avec un tenant_id dans chaque table appartenant à un locataire, imposé au niveau du dépôt et, lorsque cela est pris en charge, par la sécurité au niveau des lignes comme seconde ligne de défense. |
| Cache | Redis, clés préfixées par locataire | Sessions, limites de débit et configuration fréquemment utilisée. Le préfixage des clés empêche la collision classique de clés de cache qui expose les données d’un locataire à un autre. |
| Facturation | Stripe ou une passerelle régionale | L’état de l’abonnement est répliqué localement afin que les vérifications des droits ne dépendent jamais d’un appel en temps réel au prestataire de paiement. |
| Tâches | Travailleurs de file d’attente avec contexte du locataire | Travaux planifiés et asynchrones ; le contexte du locataire accompagne la charge utile de la tâche au lieu d’être déduit au moment de son exécution. |
Modèle de données
Les tableaux ci-dessous portent les règles dont dépend tout le reste. Les définir incorrectement transforme une démonstration fonctionnelle en un système impossible à étendre.
Entités principales
| Entité | Champs clés, relations et règles |
|---|---|
| tenant | Enregistrement d’organisation avec formule, statut, région et indicateurs de fonctionnalités. Chaque table appartenant à un locataire contient tenant_id, et aucune requête ne peut l’omettre. |
| user / membership | Un utilisateur peut appartenir à plusieurs locataires avec un rôle différent dans chacun ; l’identité est donc globale tandis que l’autorisation est propre à chaque adhésion. Modéliser l’utilisateur et l’adhésion dans une seule table rend ultérieurement impossible la prise en charge de plusieurs organisations. |
| role / permission | Autorisations accordées aux rôles, rôles attribués par adhésion, et chaque vérification effectuée dans le serveur. Masquer des éléments dans l’interface est une présentation, jamais un mécanisme d’application des règles. |
| subscription / entitlement | Formule, sièges, période et droits dérivés. L’accès aux fonctionnalités lit le droit local ; une panne du prestataire de paiement n’empêche donc pas les clients d’accéder au produit. |
| audit_log | Acteur, locataire, action, cible et charge utile avant/après. Permet les revues de sécurité et l’analyse des incidents ; définissez les exigences de conservation, d’accès et d’audit avant l’implémentation. |
| tenant_config | Paramètres propres au locataire, image de marque et remplacements de fonctionnalités, résolus selon une priorité documentée par rapport aux valeurs par défaut de la formule. |
Interfaces clés
Points de terminaison portant les règles métier
| Point de terminaison | Objectif et remarques sur la concurrence |
|---|---|
| POST /api/v1/auth/login | Authentifie l’identité, puis renvoie les adhésions de locataire disponibles ; le locataire est sélectionné explicitement plutôt que deviné à partir de la dernière session. |
| GET /api/v1/{resource} | Chaque lecture limitée à un locataire passe par un dépôt qui injecte tenant_id. Le filtrage est centralisé afin qu’aucun gestionnaire ne puisse l’oublier — c’est la source la plus courante de fuites entre locataires. |
| POST /api/v1/webhooks/billing | Webhook du prestataire de paiement, idempotent sur l’identifiant de l’événement, mettant à jour localement l’état de l’abonnement et des droits. |
| POST /api/v1/tenants/{id}/invite | Processus d’invitation créant une adhésion avec un rôle, limité en débit par locataire afin d’empêcher les abus d’invitation. |
| GET /api/v1/audit | Requête d’audit limitée au locataire avec pagination, proposée aux administrateurs du locataire comme réponse de conformité en libre-service. |
Décisions techniques
- Schéma partagé avec tenant_id, choisi délibérément. C’est l’option la moins coûteuse à exploiter et à migrer, et elle convient à la plupart des produits. Lorsqu’un contrat client exige une séparation physique, la même base de code peut être exécutée dans un déploiement dédié — cette possibilité est conçue dès le départ plutôt que découverte pendant une négociation commerciale.
- Filtrage par locataire imposé dans une couche de dépôt unique. Compter sur le fait que chaque développeur se souvienne d’ajouter une clause WHERE est la manière dont surviennent les fuites entre locataires. La centralisation rend difficile l’écriture accidentelle d’une requête non sécurisée.
- Droits répliqués localement. Vérifier le prestataire de paiement à chaque requête ajoute de la latence et une dépendance forte. La réplication locale signifie qu’une panne du prestataire dégrade les opérations de facturation, et non le produit lui-même.
- Journal d’audit dès la première version. Reconstituer l’historique d’audit est impossible. Confirmez les exigences d’audit de l’acheteur et conservez l’historique convenu dès la première version.
- SSR uniquement pour les pages publiques. Les pages marketing et de documentation ont besoin d’une visibilité dans les moteurs de recherche ; le produit authentifié n’en a pas besoin, et lui imposer le SSR ajoute un coût sans retour.
Objectifs de conception hypothétiques
Les chiffres ci-dessous sont des exemples hypothétiques de planification de capacité, et non des résultats client mesurés, une recommandation de dimensionnement validée ou un SLA. Définissez des objectifs d’acceptation propres au projet après avoir déterminé la charge, les appareils, les données, le matériel et les dépendances tierces ; vérifiez-les au moyen d’un pilote et de tests de charge avant de vous engager sur un objectif de production.
Objectifs de capacité et de performance
| Objectif | Valeur et hypothèse |
|---|---|
| Latence de l’API | p95 inférieur à 250 ms pour les lectures limitées à un locataire avec des index composites corrects commençant par tenant_id. |
| Isolation des locataires | Exiger une suite automatisée qui tente un accès entre locataires sur chaque point de terminaison et fait échouer la compilation en cas d’accès non autorisé. L’implémentation doit réussir ces vérifications ; cette référence ne constitue pas la preuve qu’un test de sécurité a été effectué. |
| Provisionnement | Nouveau locataire provisionné en quelques secondes, puisqu’il s’agit d’une ligne et d’un enregistrement de configuration plutôt que d’un travail d’infrastructure. |
| Mise à l’échelle | Dimensionné pour quelques milliers de locataires sur une instance PostgreSQL ; au-delà, la trajectoire prévoit d’abord des réplicas en lecture, puis le partitionnement par locataire, planifié mais non construit prématurément. |
Contenu de la livraison
- Code source du frontend Next.js, du backend Go et du panneau d’administration dans votre dépôt
- Schéma de base de données avec filtrage par locataire, index et tables d’audit documentés, ainsi que l’historique des migrations
- Suite de tests d’isolation entre locataires exécutable dans votre CI
- Intégration de la facturation, gestion des webhooks et documentation des droits
- Notes de déploiement pour Docker et Nginx, configuration de l’environnement, procédure de sauvegarde et de restauration
Planifier ce projet pour votre entreprise
Les modules ci-dessus constituent un point de départ, et non une offre figée. Nous réduisons généralement la première version à un flux opérationnel central et un flux d’administration, puis nous l’étendons lorsque l’utilisation réelle montre où se trouvent effectivement la charge et les cas particuliers. Envoyez un cahier des charges ciblé et nous le comparerons à cette architecture pour vous indiquer les éléments dont vous n’avez pas encore besoin.