Plateforme multi-tenant : landing et branding par client

Le multi-tenant ne se limite pas à la base de données

Parler de « multi-tenant », pour beaucoup d'éditeurs, ça se limite à cloisonner des bases de données. C'est nécessaire, mais très insuffisant. Quand un franchisé, un cabinet comptable ou un revendeur utilise votre plateforme pour servir ses propres clients, il veut que l'expérience porte son nom, pas le vôtre. Sa landing. Son logo. Ses couleurs. Idéalement, son domaine.

Quand le multi-tenant devient stratégique

• Les franchises — chaque point de vente ou cabinet local veut sa propre vitrine, tout en partageant les outils du réseau.
• Les réseaux de partenaires — cabinets comptables, agences, consultants qui revendent votre solution. Leur argument commercial est la personnalisation.
• Les revendeurs API — intégrateurs qui embarquent votre backend dans leur propre produit et ne veulent pas que « Powered by X » apparaisse à tout bout de champ.

Header et shell personnalisés

Les composants TenantHeader et TenantShell consomment la configuration du tenant courant au moment du rendu. Logo, nom affiché, liens de navigation, éléments de droite (contact, espace client) — tout est paramétrable sans toucher au code.

Landing page dédiée

Un moteur de landing permet de composer une page d'accueil à partir de blocs réutilisables (hero, features, témoignages, tarifs, FAQ, call-to-action). Le rendu est dynamique : la même URL publique affiche la landing du tenant détecté via le sous-domaine ou le chemin.

Couleurs, typographie, logo

Les variables CSS sont pilotées par la configuration du tenant. Un changement dans l'interface admin se répercute immédiatement sur le rendu — pas de build, pas de redeploiement.

Domaine et sous-domaine

Deux modes disponibles :

• Sous-chemin — plateforme.fr/mon-partenaire, mise en place instantanée.
• Domaine dédié — mon-partenaire.fr, configuration DNS + certificat géré automatiquement par notre couche edge.

API de branding en self-service

Le tenant ne doit pas nous appeler pour modifier son logo. Une API REST lui permet de lire et mettre à jour sa configuration :

• GET /api/tenant/branding
• PUT /api/tenant/branding (logo, couleurs, metadata SEO)
• GET /api/tenant/landing
• PUT /api/tenant/landing (blocs de la landing)

L'interface admin utilise elle-même cette API — donc le tenant a exactement le même niveau de contrôle que nos opérateurs.

Sécurité et isolation

Trois couches complémentaires :

• Isolation logique en base — toutes les entités sensibles (clients, factures, contrats, utilisateurs) portent un tenantId obligatoire, vérifié dans chaque requête.
• Scoping des sessions — un utilisateur connecté sur un tenant ne voit que les données de ce tenant, jamais celles d'un autre.
• Journalisation — chaque action est loggée avec le tenant concerné.

Cas d'usage déjà en production

• Un cabinet comptable en Wallonie — son propre sous-domaine, sa charte, ses factures envoyées à son nom alors que la plateforme est la nôtre.
• Un réseau de consultants — landing dédiée par consultant, rôles et permissions scopés, tableau de bord global côté réseau.
• Un intégrateur API — revend le produit en ajoutant ses propres CGV et son support. Nous restons invisibles.

Pour qui ?

Si vous pilotez un réseau, une franchise ou un programme revendeur, et que vous envisagez de « construire votre portail vous-même », posez-vous la question : combien de temps, combien d'euros, combien de personnes ? Notre brique multi-tenant offre la même promesse en quelques heures de configuration.