Une instance, plusieurs entreprises : ce que le cloisonnement change
Une application de gestion commence presque toujours par servir une seule entreprise. Puis une deuxième la veut, et la question se pose : une seconde installation, ou la même pour tout le monde ?
La réponse n'est pas idéologique. Mais elle ne se rattrape pas.
Deux installations : simple, et cher
Chaque entreprise a son serveur, sa base, sa version. Le cloisonnement est total et ne repose sur aucune ligne de code — c'est son mérite, et il est réel.
Le coût apparaît à la troisième. Une correction se déploie trois fois. Trois bases à migrer, trois jeux de sauvegardes à vérifier, trois certificats à renouveler. À la dixième, la moitié du temps passe en exploitation, et les versions divergent parce qu'un déploiement a échoué sans que personne ne le remarque.
Une installation partagée : peu cher, et exigeant
Une application, une base, une opération pour tout le monde. Les migrations se jouent une fois, la supervision regarde un seul endroit.
En contrepartie, le cloisonnement devient une propriété du code, et il n'a pas droit à l'erreur. Une requête qui oublie de filtrer sur l'entreprise ne provoque pas d'erreur : elle renvoie simplement les données du voisin. Et elle passe la recette sans encombre, puisqu'en recette il n'y a souvent qu'une entreprise.
Ce qui rend le partage tenable
Le filtre ne doit pas dépendre de qui écrit la requête. Une convention d'équipe — « pensez à ajouter la condition » — tient tant que l'équipe ne change pas. Ce qui tient vraiment, c'est un mécanisme qui applique le filtre sans qu'on le demande, de sorte qu'oublier devienne impossible plutôt que déconseillé.
L'appartenance est portée par la donnée, pas par l'écran. Filtrer à l'affichage laisse l'accès ouvert à qui devine une adresse. Le contrôle appartient à la couche qui lit les données.
Les identifiants ne se devinent pas. Des numéros séquentiels partagés entre entreprises rendent l'énumération triviale : il suffit de retirer un au numéro affiché pour tomber sur la facture d'une autre société. Le contrôle d'appartenance doit être le seul rempart — mais autant ne pas fournir la carte.
Un test vérifie le cloisonnement lui-même. Deux entreprises, des données dans chacune, et l'assurance que la première ne voit rien de la seconde. Ce test-là ne teste pas une fonctionnalité : il teste que la promesse commerciale tient.
Comment nous tranchons
Nous partons sur une installation partagée quand plusieurs entités sont prévues dès le départ, ou quand elles appartiennent au même groupe. Le surcoût de conception est modeste s'il est payé au premier jour ; il devient une reprise de fond s'il est payé après.
Nous partons sur des installations séparées quand les entreprises sont étrangères l'une à l'autre et que leurs exigences réglementaires ou d'hébergement diffèrent — ou, tout simplement, quand le client veut ses données sur sa machine, ce qui est une demande parfaitement légitime.
Ce qui ne marche pas, c'est de commencer sans décider : ajouter le cloisonnement à une application qui ne l'a jamais eu suppose de reprendre chaque requête, chaque écran et chaque export. C'est là qu'on découvre combien il y en avait.