Sécurité et données.
Cette page décrit ce qui protège les données de vos participants et de vos clients : l’isolation entre organisations, les rôles, les secrets, les droits des personnes, les durées de conservation et la conduite en cas d’incident.
Isolation en trois couches
Chacun de vos clients a sa propre organisation, et la base de données elle-même refuse qu’une donnée passe de l’une à l’autre.
- Chaque table possédée par un client porte l’identifiant de son organisation
- Des clés étrangères composites rendent une ligne inter-clients structurellement impossible
- La sécurité au niveau des lignes s’applique à chaque requête, y compris celles de l’assistant
Rôles et portée
Cinq rôles en échelle, une portée par événement, et des fonctionnalités qu’on accorde ou qu’on retire à une personne précise.
- Propriétaire, administrateur, éditeur, accueil, lecteur
- Un contact client ne voit que son événement, en lecture s’il le faut
- Ce qu’un rôle ne voit pas à l’écran lui est aussi refusé par la base
- Double authentification pour les membres, qu’un administrateur peut rendre obligatoire dans toute l’organisation
- Connexion des participants réglée par événement : méthodes admises, domaines d’email autorisés, connexion d’entreprise (SSO)
Secrets et clés
Les clés qui donnent accès à tout restent sur le serveur, jamais dans un navigateur.
- La clé de service ne sort jamais du serveur ; les écritures anonymes passent par des fonctions contrôlées
- Les jetons de partage et d’invitation sont aléatoires, longs, révocables
- Les jetons MCP ne sont gardés qu’en empreinte : perdu, un jeton se recrée, il ne se retrouve pas
- Tout transite chiffré : les pages et l’API ne se servent qu’en HTTPS, imposé aux navigateurs par HSTS ; les clés d’API des fournisseurs d’IA sont chiffrées en base (AES-256-GCM)
- L’assistant et la traduction passent par le fournisseur d’IA que votre organisation a choisi, avec sa clé : sans lui, rien ne part vers un modèle
Droits des personnes
Un participant exerce ses droits seul, sans écrire à personne.
- Accès, rectification, effacement et portabilité depuis son compte
- Retrait du Meeting en un clic, consentement avant les scripts de l’organisateur
- Désabonnement en un clic dans chaque campagne
Durées de conservation
Chaque événement a sa durée de conservation, et une purge quotidienne l’applique.
- Une durée décidée par l’organisateur, événement par événement
- Un préavis trente jours avant la purge, puis l’anonymisation
- Un registre des traitements versionné avec le code
Incidents
Les erreurs sont journalisées et suivies, et une procédure écrite couvre les violations de données.
- Journal d’incidents par cause, avec le déploiement d’origine
- Santé de la base et de l’hébergeur sur un écran d’exploitation
- Procédure de violation de données : couper, notifier, documenter
Qui fait quoi, et où.
La même liste que dans les documents légaux, tirée d’un seul fichier versionné : chaque modification y est datée.
| Prestataire | Rôle | Région |
|---|---|---|
| Supabase | Base de données, authentification et stockage des fichiers. | Royaume-Uni (Londres) - décision d’adéquation |
| Vercel | Hébergement de l’application et des sites publics. | États-Unis et Union européenne |
| Resend | Envoi des emails transactionnels et des campagnes. | États-Unis |
| Cloudflare | Protection anti-robot du formulaire d’inscription (Turnstile), diffusion vidéo du direct et des rediffusions (Stream), relais des visioconférences du Studio et du Meeting (TURN et STUN). | États-Unis |
| OpenStreetMap Foundation (Nominatim) | Géocodage de la carte des participants : ne reçoit qu’un nom de lieu - « ville, pays » - sur un geste de l’organisateur, jamais une adresse ni une personne. | Royaume-Uni (Londres) - décision d’adéquation |
L’application est hébergée par Vercel Inc..
Les documents, à lire et à signer.
La politique de confidentialité, les conditions, les mentions légales et la liste des sous-traitants sont publiées. Le contrat de sous-traitance vous est envoyé à la demande, et les données personnelles ont leur propre adresse.