Architecture multi-tenant au Maroc : isoler les clients sans multiplier les systèmes
Découvrez comment concevoir une architecture SaaS multi-tenant qui isole les données, maîtrise les accès et reste exploitable à mesure que le produit évolue.
L’architecture multi-tenant au Maroc permet à un même produit SaaS de servir plusieurs entreprises tout en conservant des frontières claires entre leurs utilisateurs, leurs données et leurs opérations. Le véritable enjeu n’est pas seulement de partager une infrastructure : il consiste à décider précisément ce qui peut être mutualisé, ce qui doit être isolé et comment prouver que chaque requête reste dans le bon contexte client.
Cette discipline concerne autant la conception du produit que le cloud, la sécurité et l’exploitation. Elle complète une démarche de développement web et mobile et une architecture Cloud & DevOps pensées pour évoluer sans créer une pile technique distincte pour chaque nouveau compte.
Qu’est-ce qu’une architecture multi-tenant au Maroc ?
Un tenant représente généralement une organisation cliente et regroupe ses utilisateurs, ses règles, ses données et parfois sa configuration. Dans une solution multi-tenant, plusieurs tenants partagent certains composants. Ce partage peut concerner l’application, les services, les bases de données ou l’infrastructure, mais il n’oblige pas à tout mutualiser. Le guide de Microsoft sur les solutions SaaS multi-tenant distingue clairement le modèle commercial SaaS du choix architectural de la multitenance.
Le bon modèle dépend donc du niveau d’isolation attendu, des contraintes réglementaires, des volumes, de la fréquence des changements et de la capacité de l’équipe à exploiter la plateforme. Une application B2B peut, par exemple, partager son plan de contrôle tout en isolant les données de certains clients dans des bases dédiées.
Choisir entre mutualisation, silo et modèle hybride
Trois approches structurent la plupart des décisions. Dans un modèle mutualisé, les tenants partagent l’application et une partie importante des ressources. Ce choix simplifie les mises à jour et favorise une exploitation homogène, mais exige une isolation logique rigoureuse. Dans un modèle en silo, un tenant dispose de ressources dédiées ; l’isolation est plus visible, au prix d’un provisionnement et d’une maintenance plus lourds. Un modèle hybride combine les deux selon le profil du client ou la sensibilité de la charge.
La décision ne doit pas être globale. Elle peut varier par couche : calcul partagé, données dédiées, files de messages segmentées et stockage organisé par tenant. Les modèles de tenancy présentés par Azure insistent justement sur le niveau d’isolation à choisir pour chaque composant. L’objectif est d’éviter deux extrêmes : une mutualisation aveugle qui augmente le risque, ou une duplication systématique qui ralentit le produit.
Faire du contexte tenant une règle de sécurité
Le tenant ne doit jamais être accepté comme une simple valeur envoyée par l’interface. Le contexte doit être dérivé d’une identité vérifiée, associé à l’appartenance réelle de l’utilisateur et contrôlé côté serveur à chaque opération sensible. Les requêtes, les clés de cache, les objets stockés, les tâches asynchrones et les journaux doivent tous porter ce contexte de façon cohérente.
La fiche de sécurité multi-tenant de l’OWASP recommande notamment de lier le contexte tenant à une identité validée et de ne pas traiter un identifiant reçu comme une preuve d’autorisation. Cette exigence rejoint les bonnes pratiques d’une intégration API sécurisée : chaque endpoint doit appliquer une autorisation explicite, y compris lorsque l’appel est interne.
Isoler les données sans perdre l’exploitabilité
Le stockage peut prendre plusieurs formes : base partagée avec colonne de tenant, schéma distinct, base dédiée ou combinaison de ces modèles. Quel que soit le choix, les contraintes doivent exister dans le code et, lorsque la technologie le permet, au niveau de la base. Les migrations, sauvegardes, restaurations et exports doivent respecter les mêmes frontières.
Il faut également préparer les opérations quotidiennes. Les métriques, traces et journaux doivent pouvoir être filtrés par tenant sans exposer d’informations confidentielles. Les quotas et limites empêchent un client très actif de dégrader l’expérience des autres. AWS rappelle dans son SaaS Lens que l’isolation doit traverser toutes les couches et que l’observation par tenant est essentielle pour diagnostiquer une plateforme partagée.
Prévoir le cycle de vie complet d’un tenant
Une architecture solide décrit l’onboarding, la configuration, la suspension, l’export et la suppression. Ces parcours doivent être automatisables, traçables et idempotents. Un tenant nouvellement créé ne doit pas dépendre d’une intervention manuelle difficile à reproduire ; un tenant supprimé ne doit pas laisser de données orphelines dans un cache, un moteur de recherche ou un stockage secondaire.
La même logique s’applique aux personnalisations. Plutôt que de maintenir des branches de code par client, mieux vaut utiliser des paramètres, des permissions et des fonctionnalités activables. Cette discipline protège la cadence de livraison et facilite une gouvernance cohérente du produit.
Tester l’isolation avant chaque mise en production
Les tests doivent chercher activement les erreurs de frontière : un utilisateur du tenant A peut-il lire, modifier ou deviner une ressource du tenant B ? Une tâche asynchrone conserve-t-elle le bon contexte ? Un cache peut-il renvoyer une réponse issue d’un autre client ? Une restauration ciblée respecte-t-elle le périmètre demandé ? Ces scénarios doivent faire partie de la non-régression, pas d’un audit ponctuel.
Il faut aussi tester la contention. Une charge importante sur un tenant ne doit pas bloquer les autres. La stratégie peut combiner quotas, limitation de débit, files séparées ou capacité dédiée pour certains profils. Le choix reste lié aux engagements de service et au modèle économique, pas à une recette unique.
Une trajectoire pragmatique pour les équipes marocaines
- Définir le tenant et les données qui lui appartiennent.
- Cartographier les couches : identité, API, calcul, données, stockage, cache, messages et observabilité.
- Choisir l’isolation par composant selon le risque et l’exploitation attendue.
- Centraliser l’autorisation et propager un contexte tenant vérifié.
- Automatiser le cycle de vie et écrire des tests de fuite inter-tenant.
- Observer et limiter l’usage par tenant avant d’ouvrir à grande échelle.
Kanteek peut accompagner ce cadrage par une mission de conseil et stratégie, puis traduire les choix en architecture, en contrôles d’accès et en pratiques d’exploitation. Une architecture multi-tenant réussie ne se résume pas à partager une base : elle rend l’isolation explicite, testable et durable à mesure que le produit grandit.