Article 20 RGPD : organiser la portabilité

Un client souhaite récupérer ses données pour changer de service. Lui envoyer une capture de son compte ne suffit pas nécessairement. L’article 20 du RGPD prévoit, sous certaines conditions, un format structuré, couramment utilisé et lisible par machine, ainsi qu’une transmission directe lorsque celle-ci est techniquement possible.

Vérifier les conditions de l’article 20

L’Art. 20(1) du RGPD concerne les données personnelles relatives au demandeur qu’il a fournies, lorsque le traitement repose sur le consentement visé aux Art. 6(1)(a) ou 9(2)(a), ou sur le contrat visé à l’Art. 6(1)(b), et qu’il est effectué à l’aide de procédés automatisés.

Ne déduisez pas la base légale de la seule présence d’un contrat. Dans un même dossier, certaines opérations peuvent relever d’une obligation légale et d’autres de l’exécution du contrat. Vérifiez la base légale de chaque finalité avant de définir le périmètre.

L’Art. 20(3) exclut le traitement nécessaire à une mission d’intérêt public ou à l’exercice de l’autorité publique. Un dossier exclusivement manuel n’entre pas dans la condition d’automatisation. Une saisie manuelle dans une application, en revanche, ne rend pas le traitement exclusivement manuel.

Distinguer données fournies, observées et inférées

Les lignes directrices WP242 rev.01 du G29, révisées le 5 avril 2017, interprètent les données fournies comme comprenant les éléments déclarés et certaines données observées lors de l’utilisation du service. Les résultats inférés par l’organisme, tels qu’un score calculé, ne relèvent pas de cette catégorie. Une donnée enregistrée automatiquement n’est donc pas exclue au seul motif qu’elle n’a pas été saisie dans un formulaire.

Le guide sur les données observées et inférées aide à préparer cette classification champ par champ. Une exclusion de la portabilité ne signifie pas automatiquement exclusion du droit d’accès.

Cas pratique : restituer un historique de locations

Exemple hypothétique. Réserve Jeux propose un abonnement de location de jeux de société à des particuliers. Le 8 septembre, Nora demande depuis son espace authentifié ses informations de compte, ses locations et les listes de jeux qu’elle a créées. Elle veut les réutiliser dans son propre outil, sans résilier immédiatement son abonnement. La demande ne comporte pas de transmission à un autre organisme.

La personne chargée des droits identifie les traitements concernés : fourniture du service contractuel et gestion des choix enregistrés. Les données sont traitées dans l’application. L’Art. 20(1) s’applique donc aux éléments fournis par Nora dans ce périmètre. L’équipe n’exige ni le nom d’un concurrent ni l’achat d’une option « export professionnel ».

Elle établit le dossier suivant. Les données et volumes sont inventés pour montrer une méthode ; ils ne proviennent pas d’un service réel.

Cette dernière distinction évite un raccourci fréquent : la présence d’un montant sur une facture ne transforme pas tout l’historique contractuel en archive exclusivement légale. L’équipe doit pouvoir expliquer quelle opération et quelle base justifient une exclusion. Elle ne peut pas retirer toutes les dates de location sous prétexte qu’elles apparaissent aussi en comptabilité.

Produire un fichier réellement exploitable

Le texte ne prescrit pas une extension unique. Un CSV convient souvent à un tableau ; JSON peut préserver des ensembles imbriqués. Le choix doit permettre la réutilisation effective des données. Une série de captures ou un document conçu uniquement pour la lecture humaine risque de ne pas satisfaire cette exigence.

Avant remise, vérifiez la présence des intitulés de colonnes, l’encodage des caractères, le format des dates, les unités, les relations entre fichiers et la lisibilité des valeurs codées. Ces vérifications sont des recommandations opérationnelles, sans constituer un schéma réglementaire imposé.

Pour Nora, l’équipe retient des fichiers CSV encodés en UTF-8 et une courte notice. Voici un extrait fictif du fichier des locations, après vérification :

location_id,jeu_id,titre,date_reservation,date_retour_effectif,etat
L008,J014,Le Jardin partagé,2026-08-02,2026-08-18,retourne
L009,J027,Les Trois Navigateurs,2026-09-01,,en_cours

Le dictionnaire livré précise que les dates suivent l’ordre année-mois-jour et qu’une case vide dans date_retour_effectif signifie ici « retour non encore enregistré ». location_id identifie une location ; jeu_id permet de la relier aux listes personnelles. Les valeurs retourne et en_cours sont explicites. Ce choix technique est celui du scénario, pas un format imposé par le RGPD.

Le contrôle ne consiste pas à constater qu’un fichier s’ouvre. La chargée des droits rapproche les douze locations attendues des douze lignes obtenues, hors en-tête. Elle vérifie également les six jeux de la liste et les deux notes. Les noms de jeux restent lisibles, les accents sont conservés et chaque note renvoie au bon jeu. Cette vérification porte sur la fidélité de l’extraction ; elle ne crée pas une obligation de reconstituer des données déjà supprimées conformément aux durées applicables.

Quand le premier export perd une partie de l’historique

Dans le cas fictif, la première extraction ne contient que dix locations : elle écarte deux jeux retirés du catalogue courant. Le traitement d’export rapprochait les locations de ce seul catalogue et éliminait les références manquantes. Nora aurait reçu un fichier valide sur le plan technique, mais incomplet.

La chargée des droits bloque cette remise et fait corriger la sélection. Le technicien conserve les locations concernées et reprend leur titre enregistré dans l’historique, sans inventer une valeur absente. Il génère une nouvelle version ; la chargée des droits recompte les lignes et contrôle ces deux dossiers. Le fichier précédent est retiré de l’espace de remise pour éviter un téléchargement accidentel.

Le dossier de réponse consigne « extraction initiale : dix lignes ; cause : filtre sur catalogue courant ; extraction corrigée : douze lignes ; contrôle des deux références effectué ». Aucun export incomplet n’ayant été remis dans cet exemple, il n’est pas nécessaire d’annoncer à Nora une correction après envoi. Si elle l’avait déjà reçu, il faudrait lui expliquer l’omission et fournir la version corrigée, sans considérer le premier envoi comme une clôture suffisante.

Sécuriser la transmission et protéger les tiers

L’Art. 20(2) ouvre la transmission directe à un autre responsable lorsque c’est techniquement possible. Il ne crée pas une obligation générale d’adopter des systèmes compatibles avec tous les services. Vérifiez cependant les moyens disponibles avant d’opposer une impossibilité.

L’Art. 20(4) protège les droits et libertés des tiers. Les lignes directrices WP242, pages 13–15, expliquent que des données concernant plusieurs personnes ne doivent pas être automatiquement exclues : un historique d’échanges peut aussi concerner le demandeur. Le destinataire doit encadrer l’usage des données des correspondants ; la portabilité ne lui donne pas une autorisation générale de prospecter ces personnes.

Vérifiez l’identité, l’organisme destinataire choisi et le canal. Les précautions de remise sécurisée d’une copie volumineuse sont utiles aussi pour l’export portable. La portabilité ne justifie pas un lien public permanent.

Répondre, puis clôturer sans confusion avec l’effacement

Les Art. 12(3) et 12(4) imposent une réponse dans les meilleurs délais, au plus tard un mois après réception. Une prolongation de deux mois est possible si la complexité ou le nombre de demandes la rend nécessaire ; ses motifs doivent être annoncés dans le premier mois. En cas de refus total ou partiel, indiquez le motif et les voies de réclamation et de recours.

La gratuité de l’Art. 12(5) ne se limite pas à la première demande. Des frais raisonnables ou un refus supposent une demande manifestement infondée ou excessive, dont l’organisme doit démontrer le caractère.

L’Art. 20(3) préserve le droit à l’effacement : la portabilité ne supprime pas automatiquement les données à la source. Les durées normales continuent toutefois de s’appliquer ; il ne faut pas attendre une demande d’effacement pour supprimer des données dont la conservation n’est plus justifiée.

Dans le scénario, les fichiers corrigés sont mis à disposition de Nora le 15 septembre dans son espace authentifié. Le message décrit les ensembles remis, le mode de lecture et l’exclusion de l’indice calculé, avec les possibilités de réclamation auprès de la CNIL et de recours juridictionnel pour cette exclusion. Il rappelle que l’abonnement reste actif. Une difficulté d’ouverture est prise en charge, sans obliger Nora à formuler une nouvelle demande juridique.

Conservez la qualification du périmètre, la liste des fichiers, le format, la date de remise et les éventuelles difficultés. Si la personne demande aussi une copie plus large ou des explications sur le traitement, appliquez séparément la procédure de droit d’accès.

Ce qu’il faut retenir

• Vérifiez les conditions de base légale et d’automatisation pour chaque traitement.
• Distinguez les données fournies et observées des résultats inférés.
• Préparez un export exploitable et une remise sécurisée.
• Traitez les droits des tiers, l’accès et l’effacement sans refus automatique ni confusion.

FAQ

Un PDF suffit-il pour la portabilité ?

Un document uniquement destiné à la lecture humaine peut être insuffisant. Le critère porte sur la structure et la réutilisation par machine, pas seulement sur le fait de fournir un fichier électronique.

Faut-il un concurrent pour exercer ce droit ?

Non. La personne peut recevoir ses données pour les conserver ou les réutiliser elle-même. La transmission directe à un autre organisme constitue une possibilité supplémentaire lorsqu’elle est techniquement réalisable.

Les données d’un correspondant doivent-elles toujours être retirées ?

Non. Certaines données concernent à la fois le demandeur et son correspondant. Évaluez les droits des tiers et les usages prévus au lieu de retirer indistinctement toutes les interactions.

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.