Définir l’organisation de référence
Précisez ce qu’est un client dans votre modèle : entreprise, établissement ou équipe. Une personne peut-elle appartenir à plusieurs organisations ? Qui peut l’inviter ou la retirer ? Ces questions influencent les accès, les abonnements et les écrans. Les régler tardivement oblige souvent à reprendre des règles disséminées dans l’application.
Porter le contexte jusqu’aux requêtes
La séparation ne repose pas sur un filtre visuel. Les lectures et écritures doivent vérifier l’organisation autorisée côté serveur. Les recherches, exports, fichiers et tâches en arrière-plan font partie du même périmètre. Un écran principal correct ne compense pas un export qui mélange les données de plusieurs clients.
Tester avec deux organisations
Créez deux jeux de données clairement distincts et plusieurs utilisateurs. Vérifiez qu’un identifiant appartenant à l’autre organisation ne permet ni lecture ni modification. Testez aussi les changements d’organisation dans une session et les liens reçus par e-mail. Ces scénarios rendent les frontières observables et préviennent les suppositions optimistes.
Préparer l’exploitation
Le support peut avoir besoin d’intervenir sur un compte client. Cette capacité doit être limitée, justifiée et traçable. Pensez aussi à l’export, à la suppression et aux sauvegardes par organisation selon les engagements du produit. Les choix d’architecture se discutent en fonction de ces besoins, des volumes et du niveau d’isolation attendu.
Dessinez la relation entre utilisateur, organisation et projet, puis vérifiez chaque accès avec deux clients fictifs distincts.