Droit d'accès : retrouver les anciens identifiants

Pour répondre complètement à un droit d’accès, recherchez les données sous les identifiants actuels et historiques pertinents, puis vérifiez chaque rapprochement. Une recherche sur l’adresse électronique actuelle ne suffit pas si les anciennes commandes utilisent un autre compte. À l’inverse, un nom identique ou une adresse réattribuée ne permet pas d’ajouter automatiquement un dossier à la copie.

Le livrable utile est un plan de recherche exécuté : quels identifiants ont été retenus, dans quels systèmes, avec quels résultats et quelles difficultés résolues. Voici une méthode adaptée à une PME dont les outils ont changé.

Chercher les données de la personne, pas seulement son compte actuel

Le droit d’accès concerne les données personnelles faisant l’objet d’un traitement, avec les informations prévues par l’Art. 15(1) et leur copie selon l’Art. 15(3). Il ne se limite pas à ce que l’interface du compte récent permet d’exporter. Le responsable doit aussi faciliter l’exercice du droit, conformément à l’Art. 12(2). Source : RGPD, Art. 12 et 15.

Une facture archivée, une demande de support fermée ou une note conservée dans un ancien logiciel peuvent rester dans le périmètre. Leur présence doit être vérifiée ; le terme « archive » ne signifie pas que les données ont cessé d’être traitées.

Cela ne commande pas de recréer des données effectivement supprimées ni de collecter toutes les anciennes coordonnées d’un client. L’Art. 11(1) n’impose pas d’ajouter des informations uniquement pour identifier une personne lorsque les finalités du traitement ne nécessitent pas cette identification. L’Art. 11(2) prévoit toutefois le cas où elle fournit des informations permettant son identification pour exercer ses droits. Source : Art. 11.

Le guide de l’Art. 15 du RGPD présente l’ensemble de la réponse. Ici, nous préparons la recherche qui doit l’alimenter sans attribuer à tort des données à quelqu’un.

Séparer le contrôle d’identité et le rapprochement technique

Ces deux opérations répondent à des questions différentes. Le contrôle d’identité vérifie que la demande provient de la personne concernée. Le rapprochement technique détermine quels dossiers lui appartiennent dans vos systèmes.

Une demande reçue depuis un espace client authentifié peut apporter des éléments utiles au premier contrôle sans résoudre la correspondance avec un ancien compte. Inversement, connaître une ancienne référence de commande ne démontre pas toujours, à elle seule, l’identité de celui qui la présente.

En cas de doute raisonnable, l’Art. 12(6) autorise les informations supplémentaires nécessaires pour confirmer l’identité. Il ne crée pas une obligation de demander une pièce d’identité à chaque demandeur. Adaptez le contrôle proportionné de l’identité au risque et aux moyens déjà disponibles.

Le pilote peut ensuite demander un renseignement de recherche ciblé : « Vos commandes antérieures à la migration peuvent utiliser une autre référence. Si vous disposez d’un ancien numéro de commande, il permettra de compléter la recherche. » Expliquez son utilité ; ne faites pas de cette aide une condition systématique lorsque vous détenez déjà la correspondance.

Cas complet : une cliente, deux comptes, une adresse réattribuée

Exemple hypothétique. Une PME française commercialisant du matériel de jardin reçoit, le 2 septembre, une demande d’accès de Mme Laurent depuis son compte authentifié. La cliente demande l’ensemble de ses données et précise avoir changé d’adresse électronique lors de son départ d’une entreprise.

Le logiciel actuel la connaît sous le numéro 1702. Il affiche quatre commandes. L’ancien outil, remplacé l’année précédente, utilisait le numéro 842. Le support conserve ce dernier numéro dans ses tickets. L’ancienne adresse professionnelle est désormais utilisée par une autre personne.

Une exportation immédiate du compte 1702 oublierait une partie de l’historique. Une recherche indistincte sur l’ancienne adresse risquerait, elle, de mélanger les commandes de la cliente avec celles du nouveau titulaire. Le référent ouvre donc un plan de recherche et désigne un correspondant pour chaque application.

La table de migration rattache 842 à 1702. L’équipe vérifie cette relation dans les éléments déjà détenus, notamment les références de commandes et la période de migration. Elle n’ajoute pas des dossiers uniquement parce qu’ils portent le nom Laurent.

Une table d’identifiants avec un degré de confirmation

Dans cet exemple, le pilote constitue le tableau suivant. Les adresses complètes restent dans le dossier de travail protégé ; le compte rendu diffusé aux responsables n’a pas besoin de toutes les reproduire.

Distinguez les correspondances confirmées des pistes. Une piste peut servir à rechercher, mais ne doit pas automatiquement servir à communiquer. Si elle reste ambiguë, le propriétaire métier examine les éléments pertinents avant de donner son accord à l’extraction.

Cette distinction est particulièrement utile après une fusion de comptes, un changement de nom ou une migration comportant des erreurs. Ne corrigez pas ces erreurs par une fusion improvisée pour gagner du temps sur la demande d’accès.

Cartographier les systèmes réellement susceptibles de contenir les données

Le registre des activités de traitement fournit un point de départ : ventes, support, facturation, recouvrement éventuel. Complétez-le par la liste des applications, leurs archives et les copies identifiées dans les échanges métier.

Chaque propriétaire précise ce que sa recherche couvre. « Support consulté » est trop vague si les tickets archivés ne figurent pas dans la recherche ordinaire. « Historique des tickets, y compris fermés, interrogé sur 842 et 1702 » permet de comprendre le contrôle effectué.

Le prestataire qui héberge un outil peut devoir fournir une extraction ou une assistance. Le contrat de sous-traitance prévoit l’aide à l’exercice des droits selon l’Art. 28(3)(e), compte tenu de la nature du traitement. Source : RGPD, Art. 28(3)(e). Une fonction absente de l’interface ne clôt pas la question des données encore conservées.

Pour des sauvegardes ou un système ancien difficilement accessible, identifiez le contenu, l’existence d’une copie consultable ailleurs et les moyens disponibles. Ne concluez ni « tout restaurer immédiatement », ni « les sauvegardes sont toujours exclues ». Faites arbitrer la méthode par les responsables compétents en préservant la sécurité et la complétude de la réponse.

Le plan exécuté : résultats, preuves et décisions

Voici le résultat du cas fictif après les recherches des correspondants métier et informatique :

Les chiffres de ce tableau sont des données de scénario, pas une norme de contrôle. Le pilote peut expliquer pourquoi la réponse comporte douze commandes alors que le portail n’en affichait que quatre. Il peut également montrer pourquoi trois résultats portant la même adresse n’ont pas été remis.

Le rapprochement ne se termine pas au comptage. Vérifiez les pièces jointes, les données déduites et les commentaires pertinents. Une liste de douze références ne remplace pas la copie des données traitées dans les commandes et les autres activités.

Que faire lorsqu’une recherche échoue ?

Une absence de résultat peut avoir plusieurs causes. Le correspondant doit choisir une description vérifiable plutôt que cocher simplement « aucune donnée ».

Mauvais critère ou périmètre incomplet. Le support ne trouve rien avec 1702. La recherche est reprise avec 842 et les tickets archivés. Les six résultats apparaissent : le premier résultat nul ne prouvait aucune suppression.

Correspondance incertaine. Une ancienne facture porte le même nom, sans lien de compte confirmé. Elle reste à examiner. Le pilote demande un élément ciblé si nécessaire, sans envoyer d’abord le document pour que la personne dise s’il lui appartient.

Donnée réellement supprimée. L’équipe dispose d’éléments cohérents sur l’effacement d’un ancien ensemble. Elle distingue cette situation d’une panne de recherche et ne prétend pas fournir une donnée qu’elle ne traite plus. La justification ne consiste pas seulement en une capture affichant zéro résultat.

Accès technique indisponible. Le correspondant contacte l’administrateur ou le fournisseur, consigne le système concerné et suit la résolution. L’impossibilité temporaire d’ouvrir l’archive ne permet pas d’annoncer que l’organisme ne possède aucune donnée ancienne.

L’Art. 12(3) impose une réponse sans tarder et au plus tard dans un mois. La prolongation possible de deux mois tient à la complexité et au nombre de demandes ; elle doit être motivée et annoncée dans le premier mois. Une demande de précision ou un ticket chez l’éditeur ne crée pas automatiquement un nouveau délai. Source : Art. 12(3).

Constituer une réponse compréhensible, sans mélange de personnes

Avant l’envoi, le pilote rapproche les résultats du plan. Un propriétaire sans réponse représente un point ouvert, pas une recherche négative. Il vérifie aussi les doublons : deux copies identiques n’appellent pas nécessairement deux fichiers, mais une version comportant un commentaire supplémentaire ne doit pas disparaître lors du tri.

Les données des tiers font l’objet d’un examen distinct. Le guide sur l’occultation des informations concernant autrui permet de préparer la copie sans effacer les éléments nécessaires à sa compréhension.

Dans notre cas, la lettre peut préciser que les données ont été regroupées sous les identifiants 1702 et 842, ce dernier correspondant à l’ancien outil. Il n’est pas nécessaire d’exposer les données du nouveau titulaire de l’adresse pour expliquer la recherche. Le modèle de réponse au droit d’accès complète la présentation avec les autres informations exigées.

Si une limite persiste, décrivez-la honnêtement et faites examiner sa conséquence juridique. Ne présentez pas une livraison partielle comme une réponse exhaustive. En cas de refus, l’Art. 12(4) prévoit l’information sur les motifs et les voies de recours.

Garder une preuve utile sans créer un fichier parallèle permanent

Conservez le plan exécuté, les validations de correspondance et la trace de la réponse selon une durée justifiée. Limitez l’accès au dossier de traitement de la demande. Il n’est pas nécessaire de recopier toutes les données dans chaque tableau de suivi.

Après clôture, faites corriger les défauts qui ont compliqué la recherche : table de migration manquante, tickets non indexés ou propriétaire d’archive inconnu. Une correspondance utile au cycle de vie des dossiers peut être documentée sans créer un identifiant universel réunissant toutes les activités de l’entreprise.

Ce qu’il faut retenir

• Exploitez les correspondances historiques pertinentes déjà disponibles.
• Un identifiant utilisé pour chercher n’est pas automatiquement une preuve d’appartenance.
• Distinguez absence de résultat, donnée supprimée et système inaccessible.
• La réponse se valide sur la couverture des traitements et la justesse des rapprochements.

FAQ

Faut-il demander toutes les anciennes adresses ?

Non. Commencez par les éléments détenus et les systèmes pertinents. Un renseignement supplémentaire doit avoir une utilité expliquée ; demander une liste exhaustive par principe reporte inutilement le travail sur la personne.

Une migration réussie garantit-elle la recherche complète ?

Non. Certaines pièces, notes ou références du support peuvent ne pas avoir été reprises. Vérifiez le périmètre réellement migré et ce qui subsiste dans les outils antérieurs.

Peut-on envoyer les données à l’ancienne adresse retrouvée ?

Pas sans vérifier qu’elle constitue encore un canal approprié pour la personne. Une ancienne adresse peut être réattribuée ; la recherche historique ne vaut pas validation du destinataire actuel.

Recevez nos analyses pratiques sur la conformité RGPD dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.