Architecture multitenant

Une application web peut être déployée de deux façons fondamentalement différentes.

La première — l'architecture single-tenant — consiste à déployer une instance distincte du logiciel pour chaque client. Chaque client a ses propres serveurs, sa propre base de données, son propre environnement. C'est le modèle d'un logiciel installé sur un poste, ou d'un hébergement dédié par client. Il offre une isolation maximale, mais à un coût d'infrastructure et de maintenance prohibitif à l'échelle.

La seconde — l'architecture multitenant — consiste à faire tourner une seule instance du logiciel pour l'ensemble des clients. Tous partagent la même infrastructure, le même code, les mêmes ressources serveur. Ce qui les sépare, c'est un identifiant logique — le tenant_id — injecté à chaque couche : base de données, stockage fichiers, sessions, emails. L'isolation n'est pas physique, elle est architecturale. Elle est garantie non pas par des serveurs séparés, mais par des contraintes inscrites dans le code lui-même.

C'est le modèle qui permet à Shopify d'héberger plusieurs millions de boutiques sur la même infrastructure, à Notion de servir plusieurs millions de workspaces, ou à Salesforce de gérer les données CRM d'entreprises du monde entier — sans qu'aucune ne voie jamais les données d'une autre.

Mecanix360 est construit sur ce modèle. Chaque garage est un tenant. Son site, ses clients, ses véhicules, ses documents financiers — tout est isolé par contrainte structurelle, pas par politique de contrôle d'accès. Il est impossible, au niveau de l'architecture, qu'un garage accède aux données d'un autre.

Le corollaire de ce modèle est aussi son avantage opérationnel le plus décisif : une mise à jour du produit — qu'elle soit fonctionnelle ou réglementaire — est déployée une seule fois et bénéficie instantanément à tous les garages. Quand la réforme de la facturation électronique entre en vigueur, tous les garages Mecanix360 sont conformes le même jour, sans aucune action de leur part.