Captures d'écran et données personnelles dans les bases de connaissances
Les bases de connaissances internes — Confluence, Notion, SharePoint, GitBook — accumulent un type de problème lié aux données personnelles que les outils de conformité standard ne détectent pas : des données clients embarquées dans des captures d'écran utilisées pour documenter les processus.
Ce scénario se répète dans des milliers d'équipes support et opérations.
Un agent support découvre une configuration de compte inhabituelle. Il prend une capture d'écran de la page du compte client pour documenter le problème. La capture affiche le nom du client dans l'en-tête de l'interface, son e-mail dans les paramètres du compte et les détails de son abonnement.
L'article est publié dans la base de connaissances interne. Cent cinquante agents support peuvent désormais le consulter. Douze prestataires du helpdesk externe aussi. L'article est utile. Il explique comment gérer ce cas particulier. Tout agent qui rencontre cette configuration à l'avenir le consultera.
Trois ans plus tard, la base de connaissances contient 847 articles de ce type. Chacun comporte des captures d'écran de comptes clients. Les clients figurant sur ces captures n'ont pas consenti à cette utilisation secondaire de leurs données. La plupart ignorent que leurs données y sont stockées.
Ce n'est pas un problème mineur. Il s'aggrave à chaque nouvel article.
Risques RGPD : pourquoi c'est sérieux
L'analyse RGPD des captures d'écran dans les bases de connaissances est directe.
Minimisation des données (Article 5(1)(c)) : Les données personnelles doivent être « adéquates, pertinentes et limitées à ce qui est nécessaire. » Un article sur la configuration d'un compte n'a pas besoin du vrai nom et de l'adresse e-mail du client. Une capture floutée sert l'objectif tout aussi bien. Inclure des données clients réelles n'est pas nécessaire.
Limitation des finalités (Article 5(1)(b)) : Des données collectées pour un usage — le service client — ne peuvent pas être réutilisées pour un autre usage — la documentation interne — sans base juridique. Les données de compte ont été collectées pour la prestation de service, pas pour des articles internes. Ce sont deux finalités distinctes. Utiliser les mêmes données pour les deux exige une base légale que la plupart des équipes n'ont pas établie.
Contrôle des accès (Article 5(1)(f) et Article 32) : Des mesures techniques appropriées doivent protéger les données personnelles. Des captures d'écran de comptes clients dans un outil accessible à 150 agents et prestataires — y compris ceux n'ayant pas accès au système de comptes — représentent un accès trop large.
Droit à l'effacement (Article 17) : Toute personne demandant l'effacement de ses données a le droit d'obtenir leur suppression « dans les meilleurs délais. » Si ses données figurent dans 23 articles comme captures intégrées, la demande implique de retrouver et de mettre à jour les 23 articles. C'est difficile sans système. Notre guide sur le droit à l'effacement RGPD détaille les étapes.
Ce ne sont pas des interprétations marginales. Ce sont des applications directes du texte réglementaire à une pratique courante.
Le contournement des contrôles d'accès
Le problème de conformité le plus grave lié aux captures d'écran Confluence est le contournement des contrôles d'accès.
Les équipes support utilisent le contrôle d'accès basé sur les rôles (RBAC) pour limiter l'accès aux systèmes de comptes clients. Les agents de niveau 1 voient les informations basiques. Les agents de niveau 2 voient les données de facturation et techniques. Les responsables voient le profil complet.
Quand un agent de niveau 2 crée un article avec une capture d'écran du compte client complet, cette capture devient visible pour tous les utilisateurs de l'outil. Les agents de niveau 1 qui ne devraient pas voir les données de facturation peuvent désormais y accéder. Les prestataires sans accès système aussi. Les nouveaux collaborateurs en formation aussi.
La capture contourne les contrôles RBAC du système de comptes clients. Les données personnelles que le RBAC devait protéger sont désormais accessibles à tous.
Ce n'est pas un risque théorique. C'est le résultat normal du processus de documentation. La capture reste là sans date d'expiration, sans journal d'accès et sans piste d'audit.
Mesures correctives pratiques
Pour les équipes qui découvrent ce problème lors d'un audit RGPD :
Correction rétroactive :
- Identifier toutes les pages de la base de connaissances avec des pièces jointes images
- Appliquer la détection de données personnelles sur chaque pièce jointe
- Examiner les images signalées : les détections à forte confiance vont dans la file de révision
- Pour chaque image signalée : remplacer par une version assainie ou restreindre l'accès à la page
- Consigner les actions dans le registre RGPD
L'ampleur du travail rétroactif dépend de la taille de la base. Pour une base de connaissances de trois ans dans une équipe support de 50 personnes, le nombre d'images peut atteindre les milliers. Le traitement par lots rend cela faisable. La révision humaine des images signalées est le principal goulot d'étranglement.
Contrôles prospectifs :
- Former tout le personnel support à assainir les captures avant publication
- Fournir des outils : outils d'annotation de captures qui floutent les noms clients avant collage
- Ajouter une étape de révision : un responsable vérifie les articles avant publication, en cherchant spécifiquement les données clients dans les images
- Effectuer un scan trimestriel de toutes les pièces jointes Confluence
Contrôle minimal : Une liste de contrôle à la publication : « Supprimer ou flouter tous les noms, e-mails et identifiants de compte dans les captures avant publication. » Simple, non automatisé, mais crée un contrôle documenté. Pour les petites équipes, c'est le point de départ.
Notre vue d'ensemble de la conformité RGPD fournit le cadre juridique général. Pour comprendre pourquoi les approches uniquement basées sur des listes de contrôle s'effondrent à grande échelle, voir pourquoi une politique sans contrôles techniques échoue.
Pourquoi le problème s'aggrave avec le temps
Sans contrôles systématiques, l'exposition aux données personnelles dans la base de connaissances se cumule.
Volume : Chaque nouvel article avec une capture client augmente l'exposition totale. Plus l'équipe support grandit et la base s'étend, plus les données personnelles accumulées augmentent. Les propriétés qui rendent ces outils utiles — facilité de publication, permanence, accès large — sont précisément ce qui aggrave le problème.
Articles oubliés : Les articles sur d'anciens cas qui ne surviennent plus restent accessibles. Ils contiennent des données de clients ayant depuis déposé des demandes d'effacement. Personne ne pense à vérifier un article mis à jour pour la dernière fois en 2022.
Diffusion inter-équipes : Les bases de connaissances deviennent souvent transversales. Un article support avec des captures clients peut être partagé avec l'équipe produit, l'équipe technique ou des prestataires externes pour contextualiser une demande de fonctionnalité ou un rapport de bug. Chaque partage élargit l'audience des données personnelles.
Accumulation des demandes d'effacement : Plus les données clients s'accumulent dans la base, plus le traitement des demandes d'effacement devient complexe. Sans système, il n'y a pas de moyen fiable de confirmer que toutes les occurrences des données d'une personne ont été trouvées et supprimées.
Les données personnelles dans les bases de connaissances sont plus faciles à prévenir qu'à corriger. Des contrôles mis en place maintenant évitent le problème de correction qui s'aggrave. Chaque article publié sans capture assainie est une tâche corrective reportée à plus tard.