Un seul endroit décide de ce que chacun peut voir
Une organisation, ses espaces, ses rôles, ses permissions nominatives et ses clés d’API n’ont pas à être gouvernés à cinq endroits différents. Missivia les compose en une autorisation unique, calculée à chaque appel, du côté du serveur — quel que soit le client qui appelle, console web, script ou intégration.
Entités, espaces et adhésions
Un espace est un périmètre de données, pas un onglet : ce qu’il contient n’est visible d’aucun autre.
Une organisation regroupe des espaces — un par périmètre de données : une marque, une filiale, un environnement. Une personne accède à un espace par une adhésion, qui porte son rôle dans cet espace : la même personne peut être éditrice ici et simple lectrice ailleurs.
L’espace concerné par un appel n’est jamais transmis par l’appelant : il est déduit du jeton d’authentification, et toute requête à la base passe par une couche d’accès qui l’impose. Une ressource qui appartient à un autre espace est introuvable, pas interdite — et chaque type de ressource fait l’objet d’un test d’isolation automatisé, exécuté à chaque intégration.
Ce qu’un espace porte en propre
- Ses contacts, ses listes, ses segments et son registre de consentements.
- Ses templates, ses fragments, ses fichiers et ses pages publiques.
- Ses parcours, ses campagnes et ses messages de service.
- Ses domaines expéditeurs, ses quotas d’envoi et ses seuils de retour.
- Ses durées de conservation, ses clés d’API et ses abonnements aux webhooks.
Comment une autorisation est calculée
Cinq éléments, dans cet ordre, à chaque appel. Rien n’est décidé par l’interface qui appelle.
- 1
Espace
L’appel est rattaché à un espace, déduit du jeton. Il ne peut pas en désigner un autre.
- 2
Rôle
L’adhésion apporte un rôle, c’est-à-dire un jeu de capacités hérité en bloc — pas une case à cocher par écran.
- 3
Permissions nominatives
Elles s’ajoutent au rôle, une par une, et sont accordées à une personne désignée : l’accès aux champs sensibles en est une.
- 4
Classe de la clé
Chaque clé d’API porte une classe qui plafonne l’ensemble : ce qu’elle n’atteint pas, aucun rôle ne le lui rend.
- 5
Décision
Une matrice unique tranche, côté serveur, et écrit sa décision au journal d’audit — y compris les refus.
Des droits hérités, cumulatifs et plafonnés
- Hérités. Un rôle est un jeu de capacités cohérent, pas une liste d’exceptions. On change le rôle d’une adhésion ; on ne retouche pas trente cases.
- Cumulatifs. Une permission nominative — l’accès aux champs sensibles, par exemple — s’ajoute au rôle sans le remplacer. Elle se donne et se retire séparément, et son attribution est datée et journalisée.
- Plafonnés. La classe de la clé d’API borne le résultat. Une clé destinée à l’exploitation technique n’atteint pas une fiche de contact, même munie d’un rôle qui le permettrait : la capacité est stockée, elle n’est simplement pas exercée. Créer une clé avec une capacité hors de sa classe est refusé, avec la liste des capacités rejetées.
- Vérifiables. Un appel dédié renvoie ce que la clé peut effectivement faire : l’intersection de ce qu’elle porte et de ce que sa classe autorise.
- Séparation technique / données. Les rôles d’exploitation de la plateforme conduisent les séries et administrent la technique ; aucun ne lit une fiche, un événement nominatif, un message ou un export nominatif.
- Aucune prise d’identité. Un rôle de plateforme ne peut pas emprunter le compte d’un utilisateur du client, ni « voir comme » lui.
- Refus indistincts. Un accès qui n’est pas accordé répond « introuvable », jamais « interdit » : l’existence d’un accès aux personnes n’est pas observable de l’extérieur.
- Chaque accès est journalisé, et un export par personne concernée restitue tout ce qui a été fait sur elle, par qui et quand.
Pourquoi une interface doit demander ce qu’elle peut faire
Une console qui construit sa navigation sur les capacités demandées à la création d’une clé affiche des écrans qui répondront « introuvable ». Missivia expose donc l’autorisation effective — l’intersection des capacités de la clé et du plafond de sa classe — et c’est sur cette réponse que la navigation se construit. Ce que l’écran propose est ce que le serveur accordera.
Le même principe vaut pour l’acteur humain : les actions menées depuis une interface d’administration sont rattachées à la personne qui les a déclenchées, par un en-tête signé, en plus de la clé employée. Cet en-tête n’accorde aucun droit ; il nomme, il n’autorise pas.
La matrice, en clair
Ce que chaque rôle atteint, écrit une fois et appliqué partout.
| Ce qui est demandé | Administrateur des données | Éditeur | Lecteur | Opération | Administration technique |
|---|---|---|---|---|---|
| Fiches, historiques, exports nominatifs | Oui | Oui | Lecture | — | — |
| Champs sensibles d’une fiche | Sur permission nominative, et journalisé | — | — | ||
| Consentements et droits des personnes | Oui | Oui | Lecture | — | — |
| Listes, segments, parcours, campagnes | Oui | Oui | Lecture | Oui | — |
| Templates, fichiers, pages publiques, webhooks | Oui | Oui | Lecture | Oui | Oui |
| Statistiques | Valeurs exactes | Valeurs exactes | Valeurs exactes | Agrégats, sous seuil masqués | Agrégats, sous seuil masqués |
| Durées de conservation, export complet, suppression définitive | Oui | — | — | — | — |
| Clés, domaines, intégrations, santé des traitements | Oui | — | — | — | Oui |
| Journal d’audit | Avec les identités | Avec les identités | Avec les identités | Sans les identités | Sans les identités |
La restriction est publiée dans le contrat de l’API, opération par opération : elle est lisible avant d’être éprouvée, et un contrôle automatisé échoue si une opération servant des données personnelles est ajoutée sans être couverte.
Comment lire cette matrice
- « Lecture » signifie consultation sans modification.
- « — » signifie que l’opération n’existe pas pour ce rôle : l’appel répond « introuvable ».
- Les trois premières colonnes sont des rôles du client, responsable de traitement ; les deux dernières, des rôles d’exploitation de la plateforme.
- « Agrégats, sous seuil masqués » : un compteur portant sur moins de vingt personnes est masqué, ainsi que les taux qui s’en déduiraient. Un petit effectif désigne des individus.
- Une permission nominative ne déplace jamais une colonne : elle ouvre une ligne, pour une personne désignée, et chaque lecture qu’elle autorise est journalisée.
Utilisateurs, clés et sessions
Deux manières d’entrer — une personne authentifiée, ou une clé d’API — et une seule manière d’être autorisé.
- Double authentification obligatoire pour tous, sans exception de rôle ; authentification unique par le fournisseur d’identité du client possible.
- Une clé d’API porte des capacités explicites, une classe, et rien d’implicite : le secret n’est jamais restitué après sa création, la révocation est immédiate.
- Restriction possible par adresse IP ou par plage, et limitation des échecs d’authentification par origine.
- Les clés de test et les clés de production sont distinctes et visiblement préfixées ; une clé de test n’envoie rien vers l’extérieur.
- Toute création, modification et révocation de clé est écrite au journal d’audit, avec l’acteur humain lorsqu’il y en a un.
Moindre privilège, en pratique
- Une intégration qui ne fait qu’ingérer des contacts reçoit l’écriture des contacts, rien d’autre : ni templates, ni exports, ni statistiques.
- Une clé d’exploitation technique administre domaines, quotas et santé des traitements ; elle ne lit aucune fiche, aucun message, aucun export nominatif.
- Une clé destinée à la conduite des envois pilote listes, parcours et campagnes, et ne voit des statistiques que des agrégats, masqués sous le seuil.
- Une capacité demandée hors de la classe de la clé n’est pas silencieusement ignorée : la création est refusée, et la réponse nomme les capacités rejetées.