Architecture multi-tenant SaaS expliquée

Chez FIVE SARL, nous avons fait le choix stratégique de l'architecture multi-tenant pour toutes nos plateformes SaaS. Ce choix nous permet de servir des dizaines d'organisations avec une seule infrastructure, tout en maintenant une isolation parfaite entre clients. Voici comment ça marche, et pourquoi c'est devenu la norme.

Single-tenant vs Multi-tenant : le match

Dans une architecture single-tenant, chaque client a sa propre instance dédiée : sa propre base de données, son propre serveur, ses propres fichiers de configuration. C'est simple à comprendre, isolation parfaite, mais coûteux à maintenir : 100 clients = 100 instances à mettre à jour, monitorer, sauvegarder.

En multi-tenant, plusieurs clients (tenants) partagent la même infrastructure logicielle, mais leurs données et configurations sont isolées par un mécanisme logique. Une seule mise à jour bénéficie à tous. Une seule infrastructure à gérer.

Les 3 modèles d'isolation des données

Modèle 1 — Database par tenant

Chaque tenant a sa propre base de données. Isolation maximale, idéal pour les secteurs régulés (santé, banque). Inconvénient : la maintenance se complique au-delà de 50 tenants. Cas d'usage : plateforme bancaire, dossier médical, données ultra-sensibles.

Modèle 2 — Schema par tenant

Une seule base de données, mais chaque tenant a son schéma dédié. Bon compromis isolation/coût. Cas d'usage : SaaS B2B avec 10-100 clients enterprise.

Modèle 3 — Shared schema avec identifiant tenant

Tous les tenants partagent la même base et les mêmes tables. Une colonne d'identifiant distingue les enregistrements. Économique mais exige une rigueur extrême dans le code. Cas d'usage : SaaS B2B/B2C avec milliers de tenants.

Les 5 défis du multi-tenant (et nos solutions)

1. Sécurité et isolation

Le cauchemar : un tenant qui voit les données d'un autre. Notre approche : défense en profondeur. Filtre obligatoire à plusieurs niveaux + sécurité au niveau base + tests d'intégration vérifiant l'isolation à chaque déploiement.

2. Performance "noisy neighbor"

Un tenant qui consomme 90% des ressources peut dégrader l'expérience des autres. Solution : quotas dynamiques + rate limiting + monitoring par tenant. Des algorithmes de machine learning détectent automatiquement les comportements anormaux.

3. Migrations de schéma

Modifier la structure de la base sans bloquer les milliers de tenants ? Migrations backward-compatible, déploiement progressif avec feature flags, rollback automatique en cas de problème.

4. Backups et restauration sélective

Si un tenant veut restaurer ses données d'hier, il ne faut pas affecter les autres. Solution : backups logiques par tenant + Point-in-Time Recovery ciblé.

5. Customisation sans casser le standard

Le piège : forker le code pour un client important. Notre règle stricte : tout est configurable, rien n'est forké. Si une personnalisation est légitime, elle devient une fonctionnalité standard.

"L'architecture multi-tenant nous a permis de passer de 5 à 50 clients sans recruter une seule personne supplémentaire en infrastructure. Le levier opérationnel est exceptionnel."

Notre verdict

Pour 95% des projets SaaS B2B en Afrique, le multi-tenant avec schema-per-tenant est le sweet spot : isolation suffisante pour les régulations locales, économies d'infrastructure significatives, mises à jour centralisées. C'est ce que nous déployons par défaut chez FIVE SARL.