SAAS B2B : ORGANISATIONS, DROITS ET VÉRIFICATIONS
Édition du 2 octobre 2026

Scénario fictif non exécuté. Cette matrice est un plan de vérification, pas la preuve d’un isolement effectif ni un audit de sécurité. Les règles sont des choix d’exemple à adapter à votre produit.

DEUX ENTREPRISES ET LEURS MEMBRES
Rivage : Léa propriétaire ; Sami membre ; Inès lectrice.
Atelier Nord : Malik propriétaire ; Inès administratrice.
Inès possède une identité et deux appartenances. Son rôle dépend de l’organisation.
Dossier R : collecte d’images de Rivage, données fictives reconnaissables.
Dossier N : notes de visite d’Atelier Nord, données fictives différentes.
Les dossiers appartiennent à l’organisation, pas au seul compte qui les a créés.

MATRICE DES DROITS CHOISIE POUR L’EXEMPLE
Lecteur : lire les dossiers de son organisation ; pas de modification, invitation, export global ni suppression.
Membre : lire, créer et modifier les dossiers de son organisation ; pas de gestion d’équipe ni d’export global.
Administrateur : mêmes droits métier, plus invitations et gestion des rôles lecteur/membre ; pas de transfert ou suppression de l’organisation.
Propriétaire : droits d’administration, transfert explicite et fermeture selon procédure définie.
Export global : propriétaire uniquement dans cet exemple.
Suppression d’un dossier : propriétaire uniquement dans cet exemple, avec confirmation.
Historique : lecteur/membre voient les actions métier utiles de leur organisation ; gestion d’équipe réservée aux rôles habilités.
Aucun rôle dans Atelier Nord ne donne de droit supplémentaire chez Rivage.

PARCOURS COMPLET ATTENDU
1. Léa crée Rivage. Elle voit qu’elle en devient propriétaire.
2. Elle invite Sami avec une adresse de test contrôlée et le rôle membre.
3. L’invitation reste en attente avant acceptation.
4. Sami accepte avec l’identité attendue, puis voit Rivage et les dossiers autorisés.
5. Léa invite Inès comme lectrice ; Malik l’invite comme administratrice d’Atelier Nord.
6. Inès change d’espace : dossiers, recherches et actions suivent le bon contexte.
7. Léa change Sami en lecteur : il ne peut plus modifier, même depuis une ancienne page.
8. Léa retire son appartenance à Rivage : les anciens liens et accès aux fichiers sont refusés ; les dossiers de Rivage restent présents.
9. Pour l’essai de transfert, préparer à nouveau un membre admissible selon votre procédure. Léa confirme la destination et le nouveau rôle qu’elle conserve.
10. Le nouveau propriétaire peut gérer l’espace ; le dernier propriétaire ne peut pas être retiré sans solution prévue.

CAS DE REFUS ET CAS LIMITES
- Invitation acceptée par un autre compte : appliquer la règle d’identité, aucun accès implicite.
- Invitation expirée ou révoquée : refus et possibilité de demander une nouvelle invitation.
- Lien déjà accepté : pas de doublon ni rétablissement d’un ancien rôle.
- Inès chez Rivage : pas de pouvoir d’administration hérité d’Atelier Nord.
- Sami révoqué : ancien lien, fichier joint et action préparée auparavant refusés.
- Deux onglets dans deux organisations : aucune donnée enregistrée dans le mauvais espace.
- Recherche, notifications, récents et exports : pas de fuite entre organisations.
- Transfert vers un non-membre ou une invitation en attente : comportement explicitement défini, aucun espace orphelin.
- Deux espaces de même nom : pas de fusion automatique.
- Retrait local : pas de suppression automatique des autres appartenances.

FICHE DE RÉSULTAT À DUPLIQUER
Date et version :
Compte fictif :
Organisation active :
Rôle et appartenance :
Action, donnée et chemin utilisé :
Résultat attendu :
Résultat observé : NON EXÉCUTÉ par défaut.
Preuve conservée sans données sensibles :
Correction nécessaire :
Nouvelle vérification :

À ADAPTER AVANT CONSTRUCTION
Vos organisations, objets et propriétaires métier :
Vos rôles avec actions exactes :
Règles d’invitation et d’identité :
Règles de changement de rôle et révocation :
Transfert et récupération de propriété :
Parcours de fermeture et sort des données :
Chemins d’accès à contrôler au-delà de l’interface :
Responsable de la vérification de l’implémentation :