RGPD et vos données : comment Zeuslock reste conforme

À quoi sert ce document

Cette page s'adresse à celles et ceux qui valident Zeuslock avant son déploiement à l'échelle de l'organisation : le Délégué à la protection des données (DPO), les équipes sécurité et conformité, la revue juridique externe. Elle décrit, de manière concrète et vérifiable, la façon dont Zeuslock traite les données à caractère personnel au titre du Règlement général sur la protection des données (RGPD) et des régimes nationaux équivalents. Les articles précis du RGPD sont cités quand c'est utile, et les chemins UI sont donnés quand une affirmation est opérationnellement vérifiable.

Flux de données : où se fait l'analyse, ce qui quitte le poste

Le fait le plus important pour une revue de conformité est le suivant : la détection s'exécute côté client. Quand une collaboratrice ou un collaborateur rédige un prompt dans ChatGPT, Claude, Gemini, Copilot ou tout autre outil d'IA pris en charge, l'analyse se déroule dans l'extension de navigateur ou l'agent desktop, sur le poste local. Le texte original du prompt n'est jamais transmis à Zeuslock en fonctionnement normal.

Ce n'est qu'au moment où un détecteur déclenche — c'est-à-dire quand une donnée sensible est effectivement identifiée — qu'un événement anonymisé est envoyé aux serveurs Zeuslock. Cet événement décrit l'incident ; il ne contient pas le contenu sensible original. La donnée source ne quitte pas le poste.

Ce choix d'architecture est délibéré. Il signifie que Zeuslock n'est pas, au sens du RGPD, une plateforme d'interception de contenu pour l'activité courante : il n'y a rien à intercepter centralement, puisque l'inspection est locale. La plateforme centrale ne voit que des résumés rédigés.

Ce qui est stocké centralement, et ce qui ne l'est pas

La matrice ci-dessous décrit, par catégorie, ce que Zeuslock héberge — ou pas — pour un incident donné.

L'aperçu rédigé est le seul champ qui dérive du contenu du prompt. Les sous-chaînes sensibles sont remplacées sur le poste, par le même anonymiseur que celui qui protège le prompt, avant que l'aperçu ne soit construit.

Base légale et rôles

Au titre du RGPD, tout traitement de données à caractère personnel doit reposer sur une base légale. Pour le déploiement de Zeuslock chez un client, cette base est l'intérêt légitime de l'article 6(1)(f) : l'employeur a un intérêt légitime à détecter et empêcher l'exfiltration de données confidentielles et personnelles vers des services d'IA tiers, et le traitement se limite à ce qui est nécessaire à cette finalité. Une note d'analyse de la balance des intérêts est mise à disposition sur demande, conformément à la pratique recommandée par la CNIL.

Les rôles sont sans ambiguïté. L'organisation cliente est le responsable de traitement pour les événements d'usage générés par ses collaborateurs. Zeuslock est sous-traitant au sens de l'article 28, agissant sur instructions documentées du responsable. Un accord de traitement (DPA) standard, fondé sur les Clauses Contractuelles Types lorsque pertinent, est fourni sur demande et signé avant tout passage en production pour le client qui en fait la demande.

Sous-traitants ultérieurs

Zeuslock recourt au nombre minimum de sous-traitants nécessaires au service. La liste ci-dessous est exhaustive pour le traitement des données personnelles.

Il n'y a aucun sous-traitant exclusivement états-unien dans le chemin des données personnelles. Toute modification de cette liste est notifiée aux DPO clients au moins 30 jours avant sa prise d'effet, conformément au DPA standard.

Résidence des données

Par défaut, les données client résident sur AWS Paris (eu-west-3), avec des sauvegardes froides répliquées sur AWS Francfort (eu-central-1) à des fins de reprise après sinistre. Les deux régions sont sous juridiction de l'Union européenne.

L'Édition Souveraine épingle le tenant d'un client à une région unique sans réplication hors de cette région. Pour les organisations dont la politique ou le régulateur exige que les données ne quittent jamais un périmètre réseau défini — fréquent dans certaines fonctions du secteur public, dans la défense ou pour certaines institutions financières sous DORA — Zeuslock propose en outre un déploiement on-premise dans lequel le plan de contrôle s'exécute entièrement dans l'infrastructure du client.

Durées de conservation

La rétention par défaut est de 13 mois pour les incidents. Le choix est délibéré : assez long pour couvrir un cycle d'audit annuel et les investigations qui s'étalent, assez court pour rester défendable au titre de la minimisation. La valeur est configurable par tenant entre un minimum de 30 jours et un maximum de 7 ans lorsqu'une obligation réglementaire l'impose explicitement.

Les journaux d'audit administratifs sont conservés 7 ans, en cohérence avec les obligations probatoires courantes. Les durées effectives sont reprises dans l'annexe du DPA livré avec chaque contrat.

Droits des personnes concernées

Le responsable de traitement étant le client, les demandes de personnes concernées sont traitées par les administrateurs du client, Zeuslock fournissant l'outillage. Tous les droits prévus aux articles 15 à 22 du RGPD sont supportés opérationnellement.

• Droit d'accès (art. 15). Un administrateur exporte l'historique complet d'incidents d'une personne depuis Operator Console → Utilisateurs → [utilisateur] → Exporter. L'export est un bundle CSV + JSON structuré, directement remettable à la personne.
• Droit à l'effacement (art. 17). Depuis le même écran, l'administrateur déclenche une suppression définitive. La suppression est propagée au stockage principal et aux sauvegardes sous 24 heures, et tracée elle-même dans le journal d'audit.
• Droit de rectification (art. 16). Les métadonnées identifiantes (groupe, rôle) sont modifiables en temps réel, le plus souvent via la synchronisation SCIM depuis l'IdP ; une surcharge manuelle est possible dans la même UI.
• Droit à la limitation et d'opposition (art. 18, 21). Des utilisateurs précis peuvent être exclus du monitoring au niveau de la politique, sans supprimer leur compte.
• Droit à la portabilité (art. 20). L'export ci-dessus est dans des formats machine-lisibles et peut être réimporté dans un autre système.

Chiffrement

Toutes les données en transit sont protégées par TLS 1.3, HSTS activé sur les domaines exposés aux clients et certificate pinning dans l'agent desktop. Au repos, les données sont chiffrées en AES-256 via AWS KMS. L'Édition Souveraine prend en charge les clés gérées par le client (BYOK) sur votre propre AWS KMS : la révocation est sous le contrôle du client.

Piste d'audit et redevabilité

Chaque action administrative — consultation d'un incident, modification d'une politique, export de l'historique d'un utilisateur, suppression — est enregistrée dans un journal d'audit immuable avec acteur, horodatage, cible et résultat. Ce journal est lui-même accessible depuis l'Operator Console et exportable pour inclusion dans les audits du client.

Accompagnement AIPD

Pour les déploiements qui déclenchent une Analyse d'Impact relative à la Protection des Données au titre de l'article 35 du RGPD, Zeuslock fournit un modèle d'AIPD téléchargeable, pré-rempli avec les flux de données, sous-traitants, durées et mesures de mitigation décrits sur cette page. Il s'agit d'un point de départ que votre DPO complète et adapte, et non d'un substitut à l'analyse elle-même.

Notification de violation

Zeuslock s'engage contractuellement à notifier le client dans les 24 heures suivant la confirmation d'une violation de données personnelles affectant son tenant. La notification indique la nature de la violation, les catégories et le nombre approximatif de personnes concernées, les conséquences probables et les mesures prises ou proposées. Cette fenêtre se loge à l'intérieur du délai de 72 heures dont dispose ensuite le client pour notifier la CNIL au titre de l'article 33.