Droit RGPD en cours : changer d'outil sans le perdre
Préserver une demande RGPD pendant une migration : délais, identifiants, recherches et transmission entre les deux outils.
- Garder la date de réception et le même responsable
- Photographier l’état de la demande, sans dupliquer le client
- Le dossier M-52 : quarante-huit tickets et douze pièces
- Vérifier le contenu qui suit, celui qui reste et celui qui change
- Reporter les corrections intervenues après l’export
- Traduire les restrictions quand aucun champ ne correspond
- Coordonner la sortie du prestataire sans bloquer la recherche
- Clore sur un rapprochement et une remise effective
- Ce qu’il faut retenir
- FAQ
Une migration ne remet pas le délai d’une demande RGPD à zéro et ne réduit pas son périmètre aux données visibles dans le nouvel outil. Il faut conserver le dossier de demande, relier les anciens identifiants aux nouveaux et rechercher les éléments restés dans l’environnement sortant ou dans les archives utiles. Une bascule réussie pour l’activité peut rester incomplète pour les droits d’une personne.
La continuité se prépare avant la fermeture des accès. Le responsable du dossier doit savoir qui termine la recherche, où se trouvent les pièces et quelles décisions intervenues pendant la migration doivent être appliquées dans la cible.
Garder la date de réception et le même responsable
L’Art. 12(3) du RGPD impose de fournir des informations sur les mesures prises dans les meilleurs délais et, en tout état de cause, dans un délai d’un mois à compter de la réception. Une prolongation de deux mois est possible lorsque nécessaire compte tenu de la complexité et du nombre de demandes ; elle doit être annoncée et motivée dans le premier mois.
Une migration ne crée pas de suspension autonome. Le temps passé entre services, outils ou prestataires fait partie de votre organisation. Il n’autorise pas à dater la demande du jour où le nouveau logiciel l’a importée.
Attribuez un responsable du dossier et un suppléant jusqu’à sa clôture effective. Ils peuvent changer pendant le projet, mais la transmission doit être explicite. La fonction qui tient le registre des demandes ne doit pas dépendre d’un compte supprimé à la bascule.
Si le périmètre présente une difficulté réelle, examinez les conditions de prolongation à temps. « Nous avons changé d’outil » n’est pas une justification suffisante par elle-même. Une décision de ne pas donner suite appelle aussi l’information et les motifs prévus à l’Art. 12(4).
Photographier l’état de la demande, sans dupliquer le client
Avant l’export, dressez une fiche de continuité : date de réception, droits exercés, échéance, identifiants connus, sources à rechercher, actions accomplies et points ouverts. Elle doit permettre au repreneur de poursuivre le travail ; ce n’est pas une nouvelle base contenant toutes les données du client.
Séparez les états « recherché », « trouvé », « vérifié » et « remis ». Un export réalisé ne signifie pas que les droits des tiers ont été examinés ni que la copie a été transmise à la personne. Une réponse préparée mais restée dans l’ancien outil ne constitue pas une réponse envoyée.
La méthode de recherche par anciens identifiants est utile lorsque le numéro de client change. Conservez les correspondances nécessaires et leur origine : un rapprochement sur le seul nom peut confondre deux personnes ou manquer un compte créé sous une ancienne adresse.
Le dossier M-52 : quarante-huit tickets et douze pièces
L’exemple M-52 est fictif. Le service client d’Atelier Orme reçoit le 28 septembre 2026 une demande d’accès aux données liées à des interventions. La personne est identifiée dans l’ancien outil par C-842. La bascule vers le nouveau logiciel est prévue le 6 octobre ; son identifiant cible sera N-127.
La recherche préparatoire retrouve quarante-huit tickets et douze pièces jointes entrant dans le périmètre. La personne demande aussi, le 2 octobre, la rectification de son adresse de contact. L’export initial a déjà été produit le 1er octobre.
L’échéance ordinaire de la demande d’accès reste le 28 octobre. L’équipe ne la remplace pas par le 6 novembre au motif que le ticket est créé dans la cible le 6 octobre. La demande de rectification du 2 octobre doit également être traitée dans les meilleurs délais, selon l’Art. 16 ; elle n’attend pas nécessairement l’envoi de la copie d’accès.
Le responsable renseigne cette fiche avant la bascule :
| Point de continuité | État de M-52 | Action ou décision |
|---|---|---|
| Réception de l’accès | 28 septembre, message conservé | Échéance ordinaire maintenue au 28 octobre |
| Identité dans les outils | C-842 devient N-127 | Correspondance vérifiée et conservée dans la fiche |
| Tickets | 48 retrouvés dans l’ancien outil | Rapprocher les références, pas seulement le total |
| Pièces jointes | 12 attendues, dont 9 prévues à l’import | Récupérer les 3 autres par le circuit d’archives identifié |
| Adresse actuelle | Correction reçue après l’export | Appliquer la rectification dans la cible avant utilisation |
| Réponse | Non encore constituée ni remise | Maintenir le dossier ouvert avec un responsable nommé |
Ce tableau contient des faits et des décisions. Une simple case « migration OK » ferait disparaître les deux enjeux de M-52 : les trois pièces non importées et la correction intervenue après l’extraction.
Vérifier le contenu qui suit, celui qui reste et celui qui change
Comparez les références et les liens entre objets. Quarante-huit lignes dans chaque outil peuvent cacher un doublon et une omission. Une pièce présente dans l’archive mais rattachée au mauvais ticket ne répond pas correctement à la recherche.
Examinez aussi le sens des champs. Un statut converti de « clos » à « archivé », une date arrondie ou un commentaire tronqué peut modifier la compréhension du dossier. Conservez le dictionnaire de conversion utile à la réponse, sans remettre à la personne un export technique incompréhensible.
L’Art. 15(1) et (3) prévoit l’accès aux données et leur copie, avec les informations requises ; l’Art. 12(1) exige une présentation intelligible. La migration ne permet pas de remplacer les données encore disponibles par une synthèse approximative. Les droits et libertés des tiers restent à examiner selon l’Art. 15(4). RGPD, information et accès.
Dans M-52, l’équipe retrouve les trois pièces restantes dans l’archive sortante, vérifie leur rattachement et les examine avec les neuf autres. Elle documente ce rapprochement. Si une pièce manque encore, elle indique la recherche inachevée ; elle ne transforme pas l’absence dans la cible en preuve que le document n’a jamais existé.
Reporter les corrections intervenues après l’export
La date d’extraction crée une frontière technique, pas juridique. Enregistrez les rectifications, oppositions, limitations et effacements intervenus après cette date, puis vérifiez leur effet dans la cible. Ce relevé doit indiquer l’objet et l’opération, pas seulement le nom de la personne.
Dans M-52, l’ancienne adresse figure encore dans le fichier du 1er octobre. Le responsable de migration ajoute la correction du 2 octobre à la reprise complémentaire et vérifie que N-127 utilise la bonne adresse pour les futurs échanges. Un contrôle du fichier avant import ne suffit pas : le résultat doit être constaté dans la cible et dans ses envois préparés.
Les documents historiques posent une autre question. Une facture ancienne peut conserver l’adresse qui était exacte lors de son émission ; elle ne doit pas être réécrite comme si la nouvelle adresse y figurait depuis l’origine. La valeur de contact courante et la donnée historique répondent à des fonctions distinctes. Les Art. 5(1)(d) et 16 doivent être appliqués en tenant compte de ces finalités. RGPD, exactitude.
Le guide de la rectification des bases dérivées aide à suivre les copies et les réimports. Dans l’exemple, la reprise est terminée lorsque la correction a effectivement remplacé l’ancienne valeur de contact, sans altérer les documents historiques exacts.
Traduire les restrictions quand aucun champ ne correspond
Un nouveau logiciel peut ne pas posséder le même indicateur que l’ancien. Cela ne fait pas disparaître une limitation décidée au titre de l’Art. 18 ni une opposition à la prospection de l’Art. 21(2) et (3).
Il faut définir l’effet attendu : empêcher une utilisation, retirer une sélection, suspendre un traitement ou restreindre l’accès. Un commentaire « ne pas utiliser » n’est pas suffisant si une tâche automatique ignore ce commentaire. La limitation technique du traitement doit être traduite dans les parcours concernés.
Si la cible ne peut pas faire respecter la restriction, ne mettez pas les données à disposition de l’usage incompatible. Un périmètre séparé ou un report de l’import peut être nécessaire. Conservez alors les éléments nécessaires à la continuité du droit, avec un accès approprié ; ne supprimez pas aveuglément ce que la personne demande précisément de préserver.
Coordonner la sortie du prestataire sans bloquer la recherche
L’Art. 28(3)(e) prévoit l’assistance du sous-traitant pour répondre aux demandes. L’Art. 28(3)(g) organise, au choix du responsable, la restitution ou l’effacement à la fin des services, avec suppression des copies sauf obligation légale de conservation. Ces obligations doivent être articulées dans le calendrier réel. RGPD, sous-traitance.
Identifiez avant la fermeture du compte les recherches attendues, le contact compétent et le moyen de récupérer les données nécessaires. La disponibilité d’un export de base ne démontre pas que les pièces jointes ou les historiques sont inclus.
Une demande en cours n’autorise pas à conserver indéfiniment toute la base chez l’ancien fournisseur. Déterminez le périmètre utile, le fondement et la durée de sa conservation, ainsi que la solution de sortie. Dans M-52, une copie maîtrisée des éléments nécessaires peut permettre de fermer les accès ordinaires sans perdre le dossier de droits ; cette possibilité doit être vérifiée, pas présumée.
Clore sur un rapprochement et une remise effective
Le 20 octobre, dans notre hypothèse, le responsable dispose des quarante-huit tickets, des douze pièces examinées et des informations complémentaires requises par l’Art. 15. La correspondance des identifiants et la rectification sont documentées. Il prépare la copie en distinguant données courantes et historiques, puis la remet par un canal adapté.
Cette date est un choix du scénario, pas un délai légal de vingt jours. Une copie volumineuse sécurisée et indexée doit rester réellement accessible à son destinataire. Le journal indique le contenu remis, sa date, son canal et les éventuelles limites expliquées.
Après la remise, la copie de migration et le dossier de preuve de la réponse ont leurs propres règles de conservation. N’ajoutez pas automatiquement un double complet des tickets dans le registre des demandes. Conservez ce qui permet de justifier le traitement du droit, avec les durées et les habilitations nécessaires.
Ce qu’il faut retenir
- Gardez la réception initiale, l’échéance et un responsable jusqu’à la clôture.
- Rapprochez les données des deux outils, leurs identifiants et les archives utiles.
- Appliquez dans la cible les décisions intervenues après l’export.
- La clôture suppose une réponse effective et un périmètre vérifié, pas seulement un import réussi.
FAQ
Peut-on demander à la personne de recommencer dans le nouvel outil ?
Le changement d’outil ne le justifie pas à lui seul. Reprenez le dossier reçu et son historique. Une précision réellement nécessaire peut être demandée sans effacer artificiellement la première réception.
Faut-il conserver tous les journaux de migration ?
Non par principe. Identifiez les traces nécessaires pour expliquer les transformations, les anomalies et les opérations sur le dossier concerné. Les autres journaux suivent leurs finalités et durées propres.
Qui répond lorsque les deux prestataires se renvoient le dossier ?
Le responsable du traitement garde la maîtrise de la réponse. Son coordinateur adresse à chacun une instruction précise et suit les recherches manquantes ; le désaccord entre fournisseurs ne transfère pas cette charge à la personne.
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.