Il y a quelques mois, un ami développeur m'a dit : "Je dois refaire toute mon app de zéro parce que j'ai 3 clients qui veulent chacun leur propre espace". Cette phrase m'a fait mal au cœur, parce que j'ai déjà vécu exactement la même situation. Aujourd'hui, j'aimerais vous épargner cette douleur en vous parlant d'un concept fondamental qu'on découvre souvent trop tard : le tenancy.

🏠 Tenancy : imaginez un immeuble d'appartements

Le problème de base

Vous développez une superbe application de gestion. Tout va bien, un client est ravi. Puis arrive un deuxième client qui veut la même chose. Mais attention : il ne doit surtout pas voir les données du premier client !

Comment faire ? C'est exactement le problème que résout le tenancy.

L'analogie de l'immeuble

Le tenancy, c'est comme gérer un immeuble :

Chaque "tenant" (locataire) = chaque client de votre application L'immeuble = votre application

La question devient : comment organiser cet immeuble ?

🏢 Deux façons de construire votre "immeuble numérique"

Option 1 : Une villa par client (Single-tenant)

Imaginez que chaque client ait sa propre villa complète :

• Sa propre adresse (son propre serveur)
• Sa propre électricité (sa propre base de données)
• Ses propres meubles (sa propre version de l'app)

En informatique : Chaque client a sa propre installation complète de votre application.

Exemple concret :

• Client A utilise clienta.votreapp.com
• Client B utilise clientb.votreapp.com
• Deux serveurs séparés, deux bases de données séparées

Option 2 : Un immeuble avec des appartements (Multi-tenant)

Ici, tous vos clients habitent le même immeuble, mais chacun a son appartement privé avec sa propre clé :

• Même adresse générale (même serveur)
• Électricité partagée (même base de données)
• Mais appartements totalement séparés (données isolées)

En informatique : Tous vos clients utilisent la même installation, mais voient uniquement leurs propres données.

Exemple concret :

• Tout le monde utilise votreapp.com
• Même serveur, même base de données
• Mais quand Client A se connecte, il ne voit que ses données
• Client B ne voit que les siennes

🎯 Dans quels cas utiliser chaque approche ?

Quand choisir la "villa" (Single-tenant) ?

Pour vos gros clients exigeants :

• Les banques, hôpitaux, grandes entreprises
• Ceux qui ont des règles de sécurité très strictes
• Ceux qui veulent personnaliser votre app à fond
• Ceux qui ont beaucoup d'argent (villa = plus cher !)

Mon exemple : J'ai travaillé sur une app pour des cabinets d'avocats. Chacun voulait ses propres règles métier, ses propres champs, sa propre sécurité renforcée. Impossible de faire autrement qu'en single-tenant !

Quand choisir l'"immeuble" (Multi-tenant) ?

Pour la plupart des autres cas :

• Startups qui veulent grandir vite
• PME avec des besoins standards
• Applications SaaS grand public
• Quand vous voulez des coûts maîtrisés

Mon exemple : Une plateforme de réservation pour restaurants. Même logique pour tous : créer des réservations, gérer les tables, envoyer des confirmations. Seules les données changent entre chaque restaurant.

⚖️ Les vrais avantages et inconvénients

La villa (Single-tenant)

👍 Ce qui est génial :

• Sécurité totale : impossible qu'un client voie les données d'un autre
• Sur-mesure facile : chaque client peut avoir sa version personnalisée
• Performances garanties : un client gourmand n'impacte pas les autres

👎 Ce qui fait mal :

• Prix explosif : un serveur par client = facture serveur × nombre de clients
• Maintenance horrible : une mise à jour = la faire sur 50 serveurs différents
• Lenteur de croissance : nouveau client = installer toute une nouvelle infrastructure

L'immeuble (Multi-tenant)

👍 Ce qui est génial :

• Économies énormes : un seul serveur pour tous les clients
• Maintenance simple : une mise à jour = tous les clients en profitent
• Croissance rapide : nouveau client = juste une nouvelle ligne en base

👎 Ce qui peut poser problème :

• Risque de fuite : une erreur de code = Client A pourrait voir les données de Client B
• Performances partagées : si Client A fait planter l'app, tout le monde est impacté
• Moins de flexibilité : difficile de faire du sur-mesure

🚨 L'erreur qui coûte cher (que j'ai faite aussi)

"On va commencer simple, on verra plus tard pour séparer"

C'est le piège classique ! Beaucoup de développeurs pensent :

1. Je commence avec un seul client (pas de tenancy)
2. Quand j'aurai plus de clients, je transformerai en multi-tenant
3. Si ça marche bien, je migrerai vers du single-tenant

ERREUR !

Transformer une app normale en multi-tenant, c'est comme transformer une maison en immeuble : il faut tout casser et reconstruire.

Ma règle d'or : Réfléchissez au tenancy avant la première ligne de code, pas après.

🛠️ Un exemple ultra-simple avec Laravel

Pour vous donner une idée concrète, voici comment je structure une app multi-tenant basique. L'idée : tout tourne autour d'une table companies et chaque donnée est liée à une company.

La structure de base

php
Copier
// Une table companies
Schema::create('companies', function (Blueprint $table) {
    $table->id();
    $table->string('name');     // "Restaurant Le Gourmet"  
    $table->string('slug');     // "le-gourmet"
    $table->timestamps();
});

// Les utilisateurs appartiennent à une company
Schema::create('users', function (Blueprint $table) {
    $table->id();
    $table->foreignId('company_id')->constrained(); // ← LA clé magique
    $table->string('name');
    $table->string('email');
    $table->timestamps();
});

// Les données métier aussi
Schema::create('reservations', function (Blueprint $table) {
    $table->id();
    $table->foreignId('company_id')->constrained(); // ← Encore elle !
    $table->string('customer_name');
    $table->datetime('reservation_date');
    $table->timestamps();
});

Le modèle magique

php
Copier
// app/Models/Reservation.php
class Reservation extends Model 
{
    protected $fillable = ['customer_name', 'reservation_date', 'company_id'];
    
    // LA fonction magique qui change tout
    protected static function booted()
    {
        // Quand on récupère des réservations, ne prendre que celles de MA company
        static::addGlobalScope('company', function (Builder $builder) {
            if (auth()->check()) {
                $builder->where('company_id', auth()->user()->company_id);
            }
        });
        
        // Quand on crée une réservation, l'assigner automatiquement à MA company
        static::creating(function ($model) {
            if (auth()->check() && !$model->company_id) {
                $model->company_id = auth()->user()->company_id;
            }
        });
    }
}

Comment ça marche dans le contrôleur

php
Copier
// app/Http/Controllers/ReservationController.php
class ReservationController extends Controller
{
    public function index()
    {
        // Cette ligne récupère AUTOMATIQUEMENT seulement les réservations 
        // de la company de l'utilisateur connecté !
        $reservations = Reservation::all();
        
        return view('reservations.index', compact('reservations'));
    }
    
    public function store(Request $request)
    {
        // Cette réservation sera AUTOMATIQUEMENT assignée à la bonne company
        Reservation::create([
            'customer_name' => $request->customer_name,
            'reservation_date' => $request->reservation_date
            // Pas besoin de préciser company_id, c'est automatique !
        ]);
        
        return redirect()->back();
    }
}

La magie : Grâce au GlobalScope, impossible d'oublier le filtrage par company. Votre code reste simple, mais vos données restent isolées !

🎓 Ce qu'il faut retenir

Les 3 règles d'or du tenancy

1. Décidez AVANT de coder : single ou multi-tenant dès le début
2. Si vous hésitez, partez sur du multi-tenant simple : plus facile à transformer en single-tenant que l'inverse
3. Pensez isolation : chaque donnée doit être rattachée à un tenant

Mes recommendations selon votre situation

Vous débutez un SaaS : Multi-tenant avec l'approche company_id

Vous avez 1-3 gros clients : Single-tenant peut se justifier

Vous ne savez pas encore : Multi-tenant simple, vous verrez après

🔮 La suite du voyage

Ce qu'on a vu aujourd'hui, c'est la base absolue du tenancy. Dans un prochain article, je vous montrerai des techniques plus avancées :

• Comment gérer les sous-domaines (client1.votreapp.com)
• Les bases de données complètement séparées par tenant
• La gestion des migrations automatiques
• Les pièges à éviter en production

Mais pour l'instant, vous avez déjà de quoi construire votre première app multi-tenant proprement !

📚 Pour approfondir

Documentation Laravel

• Eloquent Global Scopes - Pour comprendre la magie du filtrage automatique
• Database Relationships - Relations entre companies et autres modèles

Packages recommandés (pour plus tard)

• spatie/laravel-multitenancy - Quand vous voudrez aller plus loin

Ressources générales

• Multi-Tenant Architecture Patterns - Concepts généraux

---

Le tenancy, c'est un concept fondamental qu'il vaut mieux comprendre tôt dans sa carrière de développeur. Une fois qu'on a saisi les bases, on voit les applications différemment - et surtout, on évite les refonte complètes !

Cet article fait partie de ma série sur l'architecture web moderne. Retrouvez mes autres réflexions techniques sur mon blog.