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
• L'org cible (dont le contenu a été lu)
• L'org lectrice (typiquement le vendor)
• L'utilisateur qui a déclenché la lecture
• Le tool par lequel la lecture est passée
• Le type d'entité (vocabulaire fermé : context pour une conversation, scenario pour un benchmark)
• L'ID de l'entité lue (et l'exchange précis quand la lecture cible un tour unique)

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, dans Paramètres de l'organisation → Confidentialité (section Journal des accès) ou via :

GET /api/admin/me/supervisor-reads

La route retourne les lectures en ordre chronologique décroissant (jusqu'à 1 000 entrées par appel).

Aucun accès cross-org sur l'audit : le vendor ne voit jamais les logs d'audit du client.

Droit à l'effacement (article 17)

L'architecture rend l'effacement exécutable proprement : toutes les données d'une organisation sont rattachées à son org_id (tables métier, dossiers de fichiers, secrets), ce qui permet un effacement ciblé — un utilisateur précis, une conversation précise, ou l'organisation entière — sans toucher au reste.

Les demandes d'effacement (article 17) se traitent avec notre support : écrivez à contact@betool.fr depuis un compte administrateur de l'organisation concernée.

Opt-in & opt-out lecture cross-tenant

Par défaut, l'opt-in lecture cross-tenant est à FALSE. Un administrateur de l'organisation peut l'activer — et le révoquer à tout moment — dans Paramètres de l'organisation → Confidentialité.

• Désactivé — 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 (le support structurel reste possible).
• Activé — le superviseur peut lire les conversations de l'org pour diagnostiquer, chaque accès étant audité et consultable par l'org.

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

Le site marketing (betool.ai) mesure son audience avec Google Analytics 4, en Consent Mode v2 :

• Par défaut, tous les consentements Google (mesure, publicité) sont à refusé : le script Google Analytics n'est pas chargé et aucun cookie analytique n'est déposé.
• Le script n'est chargé, et la mesure activée, qu'après votre acceptation explicite de la mesure d'audience dans la bannière.
• Vous pouvez retirer ce consentement à tout moment (Gérer les cookies, en pied de page) : la mesure repasse alors à refusé.

Les consentements publicitaires restent refusés : le site ne fait pas de ciblage publicitaire.