Audit RGPD & journal d'accès
betool est conçu pour répondre aux exigences du RGPD sans bricolage : chaque accès au contenu utilisateur par un agent appartenant à une autre organisation est journalisé, et chaque organisation peut consulter son propre journal.
Le journal d'accès
Une table dédiée enregistre, pour chaque accès cross-tenant :
- L'horodatage (microseconde près)
- L'org cible (dont le contenu a été lu)
- L'org lectrice (typiquement le vendor)
- Le rôle / agent / utilisateur qui a lu
- Le type d'entité (vocabulaire fermé :
exchange_text,knowledge_chunk,audio_segment…) - L'ID de l'entité
- Le contexte d'usage (mission, ticket, proposition)
Le vocabulaire d'entité est fermé côté base (CHECK constraint) et fermé côté code (whitelist applicative). Ajouter un type = nouvelle migration + maj whitelist. Pas d'entrée surprise.
Droit d'accès (article 15)
Chaque organisation peut consulter SES propres logs d'accès via :
GET /api/admin/me/content-reads
Filtres disponibles : période, type d'entité, ID d'entité, identité lectrice. Export CSV / Excel pour partage à un délégué à la protection des données.
Aucun accès cross-org sur l'audit : le vendor ne voit jamais les logs d'audit du client.
Droit à l'effacement (article 17)
Trois niveaux d'effacement supportés :
- Effacement utilisateur — un end-user demande l'effacement de ses données dans une organisation cliente. L'organisation déclenche l'effacement via l'admin ou l'API admin.
- Effacement organisation — une organisation quitte betool. Toutes ses ressources sont supprimées : tables filtrées par
org_id, dossier fichiers, secrets purgés. Délai contractuel par défaut : 30 jours pour rétractation, puis purge irréversible. - Effacement légal — sur ordonnance, suppression d'éléments précis sans toucher au reste. Logué dans l'audit avec référence à la base légale.
Opt-in & opt-out lecture cross-tenant
Par défaut, l'opt-in lecture cross-tenant est à FALSE. Une organisation peut l'activer dans Administration → Confidentialité → Lecture cross-tenant.
Trois modes :
- Refus complet — par défaut. Le vendor ne peut accéder à aucun contenu de cette org. Conséquence : pas de support cross-org possible sur ce qui touche au contenu (l'archi reste, les flags métier oui).
- Opt-in temporaire — autorisation pour une fenêtre de temps, révocable.
- Opt-in permanent — pour les clients qui veulent un support proactif (rare en banque, courant en SaaS standard).
Le vendor ne peut PAS activer cet opt-in pour le compte du client. C'est un test fondamental : si le vendor peut toggle sans action client, l'architecture est cassée.
Garde-fou destructive ops
Toute opération qui détruit ou remplace du contenu (DELETE, REPLACE-IN-PLACE) est refusée au validateur si l'org cible n'a pas activé l'opt-in lecture. Raison : sans visibility, l'opérateur propose à l'aveugle un payload qui écraserait l'existant.
Refus en cascade si audit indisponible
Si la base de données d'audit est indisponible (incident infra), toute lecture cross-tenant est refusée. Politique stricte : pas de lecture sans trace.
Conséquence côté code : un caller qui catch une exception doit re-raiser l'erreur d'audit avant tout traitement métier. C'est un invariant testé par le benchmark de sécurité.
Cookies de consentement
Côté site marketing et widget chat, seuls les cookies strictement nécessaires sont déposés. Aucun cookie analytique tiers sans bannière de consentement conforme.