Gérer plusieurs organisations dans un même logiciel

Un même logiciel qui sert dix entreprises différentes, sans qu'aucune ne voie les données des neuf autres : c'est ce qu'on appelle un logiciel multi-organisations. Le sujet a l'air technique, il est d'abord contractuel : la façon dont votre outil sépare les données décide de ce que vous pouvez promettre à vos clients, de ce que vous paierez pour l'exploiter, et de ce qui se passera le jour où l'un d'eux voudra partir avec les siennes. Voici les trois architectures possibles et les quatre points à vérifier avant de choisir.

Plusieurs organisations, ce n'est pas plusieurs utilisateurs

Une organisation est un périmètre de données étanche ; un utilisateur est une personne qui accède à un périmètre. Confondre les deux est l'erreur la plus coûteuse du sujet, parce qu'elle ne se corrige presque jamais sans réécrire le logiciel.

Trois situations mènent au même besoin : un prestataire qui sert ses clients depuis un outil unique, un groupe qui pilote des filiales ou des marques distinctes, un réseau d'agences ou de franchisés. Les fonctions sont identiques d'une entité à l'autre, les données ne doivent jamais se croiser, et une seule personne du mauvais côté de la frontière suffit à créer un incident.

Un logiciel conçu pour une seule entreprise sait gérer des rôles et des droits. Il ne sait pas gérer une frontière. Ajouter cette frontière après coup impose de reprendre chaque écran, chaque requête, chaque export et chaque fichier déposé : c'est un chantier de refonte, pas une option qu'on active.

Les trois façons de séparer les données

Trois architectures existent, de la plus étanche à la plus économique :

• Une installation par organisation. Chaque organisation dispose de sa propre application et de sa propre base, sur son propre hébergement si le contrat l'exige. Rien ne peut fuiter d'un client vers un autre, puisque leurs données ne se rencontrent jamais. En contrepartie, mises à jour, sauvegardes et correctifs de sécurité se répètent autant de fois qu'il y a d'organisations.
• Une base par organisation, derrière une application unique. L'application est déployée et mise à jour une seule fois ; elle choisit la base à interroger selon l'organisation connectée. Les données restent physiquement séparées et l'exploitation reste supportable. Le point de vigilance se déplace vers le mécanisme d'aiguillage, qui décide seul à quelle base un utilisateur est envoyé.
• Une base partagée, avec cloisonnement logique. Toutes les organisations vivent dans les mêmes tables, chaque ligne portant l'identifiant de son organisation. C'est l'approche la plus économique et la plus répandue chez les éditeurs de logiciels en ligne. C'est aussi la seule où une ligne de code oubliée expose les données d'un client à un autre.

Ce que chaque approche protège, et ce qu'elle coûte :

La colonne des coûts se traduit en euros. La maintenance annuelle d'un logiciel sur mesure représente 15 à 20 % du coût initial : en installations dédiées, cette ligne se répète pour chaque organisation, et c'est souvent le poste oublié au moment du chiffrage. Le détail des paliers est dans notre article sur le budget d'un CRM sur mesure.

Le point faible du cloisonnement logique : la requête qui oublie le filtre

Dans une base partagée, la séparation ne tient qu'à une condition ajoutée à chaque lecture et à chaque écriture : si cette condition manque une seule fois, l'écran affiche les données d'une autre organisation.

Le scénario n'a rien d'exotique. On ajoute un écran de statistiques, la requête part sans le filtre par organisation, et le total affiché additionne tous les clients. La variante plus grave passe par l'adresse : un utilisateur remplace un numéro de dossier par un autre dans la barre de son navigateur et obtient une fiche qui ne lui appartient pas. Les standards de sécurité applicative appellent cela un contrôle d'accès défaillant, et c'est l'un des points que couvre notre approche de la sécurité dès la conception.

La parade n'est pas la vigilance, c'est l'architecture. Le filtre par organisation doit être imposé par une couche unique, traversée par toutes les requêtes, que le code métier ne peut ni oublier ni contourner. Posez la question telle quelle à votre éditeur ou à votre prestataire : si la réponse est « nos développeurs y font attention », vous avez votre réponse.

Les quatre points à vérifier avant de signer

Quel que soit le modèle retenu, quatre vérifications suffisent à savoir si le cloisonnement est réel :

1. Le filtre est appliqué par le serveur, pas par l'écran. Masquer un bouton n'empêche pas de lire une donnée : si un utilisateur change un identifiant dans l'adresse de son navigateur, la bonne réponse est un refus explicite, pas une page vide.
2. Les fichiers suivent la même règle que la base. Devis en PDF, photos de chantier, pièces jointes : ils vivent souvent en dehors de la base, dans un stockage où connaître l'adresse du fichier suffit à l'ouvrir. Un lien direct devinable ou partageable annule tout le cloisonnement de la base.
3. Les accès qui traversent les organisations sont nominatifs et tracés. Il en faut : le support, l'administrateur, parfois la direction du groupe. Ces comptes doivent être nommés, limités dans ce qu'ils peuvent voir, et laisser une trace consultable de ce qu'ils ont consulté. Un compte « admin » partagé par trois personnes ne trace rien.
4. On peut sauvegarder, restituer et supprimer une organisation seule. C'est la question qui fâche en base partagée. Le jour où un client part, où une filiale est cédée, ou où quelqu'un exerce son droit à l'effacement, il faut extraire ses données sans toucher à celles des autres. Exigez une démonstration : une restitution qui n'a jamais été testée n'existe pas.

Avez-vous vraiment besoin de multi-organisations ?

Non, si vos entités ne partagent ni utilisateurs, ni paramétrage, ni reporting consolidé. Dans ce cas, deux comptes distincts sur un outil du marché coûteront toujours moins cher qu'une architecture multi-organisations.

Le besoin devient réel quand trois conditions se rejoignent : le nombre d'entités augmente, les mêmes personnes travaillent sur plusieurs d'entre elles, et une vue consolidée devient nécessaire. À deux ou trois entités stables gérées par des équipes séparées, la complexité ajoutée ne se rembourse pas.

Chez Cloudyva, à Montpellier, un tiers des cadrages conclut qu'un outil du marché suffit. Sur ce sujet précis, la vérification est courte : beaucoup d'outils du marché gèrent déjà des espaces séparés par organisation, il reste à leur passer les quatre points ci-dessus. Si le doute persiste, notre grille de décision entre logiciel du marché et sur mesure s'applique telle quelle.

Peut-on changer d'architecture en cours de route ?

Oui, et un sens est nettement plus simple que l'autre : sortir une organisation d'une base partagée vers sa propre installation est une extraction, longue mais balisée. Regrouper des installations séparées dans une base commune est une fusion, et c'est autrement plus lourd : chaque installation a vécu sa vie, les identifiants se télescopent, les paramétrages ont divergé. Réconcilier tout cela coûte parfois plus cher que le développement initial, d'où la règle : l'architecture se tranche au cadrage, pas quand le dixième client arrive.

Un exemple pour finir : nous avons conçu et mis en production une plateforme de tickets qui applique ces principes, avec un espace par organisation et des accès de support tracés. Le détail est sur la page du logiciel de ticketing multi-organisations que nous éditons.

Vous devez arbitrer entre ces trois modèles pour votre propre outil ? Décrivez-nous qui utilise quoi, en quelques lignes : réponse sous 24 h, cadrage de 30 minutes offert, à Montpellier ou chez vous.