Construire un SaaS multitenant avec Django : guide complet

Pourquoi opter pour une architecture multitenant ?

Dans un SaaS, plusieurs clients utilisent la même application. L’architecture multitenant permet à chacun de conserver ses données et configurations isolées, tout en mutualisant l’infrastructure et le code.

Avantages clés

1. Réduction des coûts

   • Un seul serveur, une seule base de code, moins de maintenance.

   • Pas besoin de déployer une instance par client.

2. Mises à jour centralisées

   • Toute modification dans le code profite automatiquement à tous les clients.

   • Exemple : ajouter un nouveau champ à un modèle ou améliorer l’interface utilisateur.

3. Scalabilité simplifiée

   • Ajouter un nouveau client devient un processus automatisable (création de schéma, tables et sous-domaine).

4. Uniformité fonctionnelle

   • Tous les clients utilisent la même version de l’application, simplifiant support et suivi des bugs.

Défis à anticiper

1. Isolation des données

   • Chaque client doit accéder uniquement à ses données.

   • Risque : si la logique n’est pas correcte, un client pourrait voir les informations d’un autre.

2. Sécurité

   • Authentification stricte et permissions fines sont nécessaires.

   • Les endpoints doivent vérifier le tenant courant.

3. Personnalisation

   • Difficulté à adapter l’application pour certains clients sans affecter les autres.

   • Ex. : un client peut vouloir un logo ou thème spécifique.

4. Migrations et maintenance

   • Les modifications de base doivent être planifiées pour éviter d’impacter tous les tenants.

   • Les sauvegardes et restaurations doivent être tenant-aware.

Approches multitenant avec Django

Django permet de gérer le multitenant via deux grandes stratégies :

1. Schéma unique (tables partagées)

2. Schéma par tenant (isolé, recommandé pour B2B)

1️⃣ Schéma unique : tables partagées

Dans cette approche, tous les clients partagent la même base et les mêmes tables. Chaque ligne est associée à un tenant_id pour identifier le propriétaire des données.

Exemple concret : gestion d’utilisateurs et factures

from django.db import models

class Tenant(models.Model):
    name = models.CharField(max_length=100)

class User(models.Model):
    tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE)
    email = models.EmailField(unique=True)
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)

class Invoice(models.Model):
    tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE)
    client_name = models.CharField(max_length=100)
    amount = models.DecimalField(max_digits=10, decimal_places=2)
    created_on = models.DateTimeField(auto_now_add=True)

Points importants :

• ForeignKey vers Tenant permet de filtrer facilement les données.

• Toute requête doit être filtrée par tenant :

invoices = Invoice.objects.filter(tenant=current_tenant)

Avantages :

• Mise en place simple

• Optimisée pour les petits clients et un grand nombre d’utilisateurs

Inconvénients :

• Isolation des données moins forte → risque de fuite si les filtres sont oubliés

• Migrations globales pour tous les tenants → plus risquées

Schéma conceptuel :

Table tenants
| id | name       |
|----|-----------|
| 1  | Client A  |
| 2  | Client B  |

Table users
| id | tenant_id | email        |
|----|-----------|--------------|
| 1  | 1         | a@mail.com   |
| 2  | 2         | b@mail.com   |

Table invoices
| id | tenant_id | client_name | amount |
|----|-----------|------------|--------|
| 1  | 1         | Alpha      | 100    |
| 2  | 2         | Beta       | 200    |

2️⃣ Schéma par tenant : approche isolée (recommandée pour B2B)

Chaque client possède son propre schéma dans PostgreSQL. Les tables sont identiques, mais séparées. Cela permet une isolation complète des données et des migrations indépendantes.

Mise en place avec django-tenants

Installer la bibliothèque :

pip install django-tenants

Définir les modèles tenants :

# models.py
from django_tenants.models import TenantMixin, DomainMixin
from django.db import models

class Client(TenantMixin):
    name = models.CharField(max_length=100)
    paid_until = models.DateField()
    on_trial = models.BooleanField(default=True)
    created_on = models.DateField(auto_now_add=True)

class Domain(DomainMixin):
    pass

Explication :

• TenantMixin : chaque instance crée un schéma isolé

• DomainMixin : relie un sous-domaine au tenant

• Exemple : client1.mondomaine.com → schéma client1

Middleware automatique

django-tenants fournit un middleware qui :

1. Récupère le sous-domaine de la requête

2. Sélectionne le schéma correspondant

3. Redirige toutes les requêtes ORM vers ce schéma

Exemple d’utilisation : modèles isolés

# models.py dans un schéma tenant
from django.db import models

class Invoice(models.Model):
    client_name = models.CharField(max_length=100)
    amount = models.DecimalField(max_digits=10, decimal_places=2)
    created_on = models.DateTimeField(auto_now_add=True)

Chaque tenant aura ses propres Invoice sans interférence avec les autres tenants.

Schéma conceptuel :

Schema client1:
Table invoices
| id | client_name | amount |
|----|------------|--------|
| 1  | Alpha      | 100    |

Schema client2:
Table invoices
| id | client_name | amount |
|----|------------|--------|
| 1  | Beta       | 200    |

Dashboard multitenant Django

Un mini-dashboard permet à chaque client de voir uniquement ses données.

# views.py
from django.shortcuts import render
from .models import Invoice

def dashboard(request):
    invoices = Invoice.objects.all()  # middleware filtre automatiquement le tenant
    total = invoices.aggregate(models.Sum('amount'))['amount__sum'] or 0
    return render(request, 'dashboard.html', {'invoices': invoices, 'total': total})

<!-- dashboard.html -->
<h1>Tableau de bord</h1>
<p>Total factures : {{ total }} €</p>
<table>
    <thead>
        <tr>
            <th>Client</th>
            <th>Montant</th>
            <th>Date</th>
        </tr>
    </thead>
    <tbody>
        {% for invoice in invoices %}
        <tr>
            <td>{{ invoice.client_name }}</td>
            <td>{{ invoice.amount }}</td>
            <td>{{ invoice.created_on|date:"d/m/Y" }}</td>
        </tr>
        {% endfor %}
    </tbody>
</table>

Avantages :

• Chaque tenant voit seulement ses données

• Intégration simple avec django-tenants

• Extensible pour graphiques, filtres et rapports

Bonnes pratiques détaillées

1. Filtrer toutes les données par tenant : même avec des schémas isolés, ajoutez des vérifications côté code.

2. Automatiser la création des tenants : lors de l’inscription, créer le schéma, les tables et le sous-domaine.

3. Centraliser les mises à jour du code : la logique métier reste partagée, seule la structure des données varie.

4. Surveiller l’usage des ressources : CPU, mémoire et espace disque par tenant.

5. Tester les migrations sur un environnement staging tenant avant production.

6. Sauvegardes tenant-aware : backups séparés par schéma ou par client pour faciliter la restauration.

7. Logging et monitoring : chaque requête doit inclure le tenant pour traçabilité.

Ah ! Je comprends mieux maintenant : tu cherches des exemples de logiciels ou plateformes réels très connus qui fonctionnent en multitenant, un peu comme Facebook ou YouTube, pour illustrer concrètement le concept.

Voici une liste de cas réels :

 Exemples célèbres de logiciels SaaS ou plateformes multitenant

Points communs

1. Une seule base de code
   Tous ces services utilisent le même code pour tous les clients, ce qui simplifie la maintenance et les mises à jour.

2. Isolation des données
   Chaque tenant (utilisateur, entreprise ou workspace) ne voit que ses propres données grâce à des filtres, schémas séparés ou permissions.

3. Scalabilité
   L’ajout de nouveaux tenants (utilisateurs, organisations) est rapide, sans déployer de nouvelles instances.

4. SaaS typique
   Ce modèle est utilisé pour pratiquement toutes les grandes plateformes SaaS ou services en ligne à grande échelle.

💡 Remarque :
Même si Facebook ou YouTube ne sont pas strictement “multitenant” au sens classique de SaaS avec des schémas séparés pour chaque client, leur architecture mutualise l’infrastructure tout en isolant les données de chaque utilisateur, ce qui correspond au concept multitenant appliqué à très grande échelle.

Conclusion

• Schéma unique : idéal pour les petits clients, simplicité et rapidité de mise en place.

• Schéma par tenant : recommandé pour B2B, sécurité, isolation et conformité.

Avec Django et django-tenants, vous pouvez construire un SaaS multitenant robuste, évolutif et sécurisé, capable de gérer de nombreux clients tout en centralisant le code et la maintenance.