Data Act vs RGPD : différences, interactions et hiérarchie

Le Data Act organise plusieurs droits et obligations concernant l’accès et l’utilisation des données ; le RGPD protège les personnes physiques lors du traitement de leurs données personnelles. Les deux textes peuvent s’appliquer au même flux. La règle pratique est de qualifier chaque opération, chaque acteur et chaque catégorie de données.

L’Art. 1(5) du Data Act maintient les règles de protection des données et prévoit leur priorité en cas de conflit. Il ne suffit donc pas qu’une entreprise soit utilisatrice d’un produit connecté pour qu’elle obtienne sans autre examen les données de toutes les personnes qui l’ont utilisé. Source : règlement (UE) 2023/2854.

Comparer les périmètres sans réduire le Data Act à l’IoT

Le Data Act ne concerne pas toutes les données de toute entreprise : son Art. 1(2) distingue le champ de ses chapitres. Les règles cloud, contractuelles ou relatives aux besoins exceptionnels du secteur public ne se réduisent pas à l’origine IoT des données. Le guide Data Act présente ces volets.

Distinguer les trois principales demandes

Une personne peut demander l’accès à ses données personnelles au titre de l’Art. 15 du RGPD. L’Art. 20 prévoit une portabilité pour certaines données qu’elle a fournies, lorsque le traitement automatisé repose sur le consentement ou un contrat. Ces deux droits n’ont pas exactement le même périmètre. Source : RGPD, chapitre III.

Un utilisateur de produit connecté peut également exercer les droits des Art. 4 et 5 du Data Act. Enfin, un client cloud peut organiser une sortie selon le chapitre VI. Une demande d’entreprise visant l’export d’un logiciel ne devient pas une demande individuelle de portabilité RGPD parce que le fichier contient des noms.

Orientez chaque demande vers la procédure appropriée, en conservant la possibilité qu’une même lettre invoque plusieurs droits. Le guide d’accès aux données IoT précise les informations utiles pour ce cas.

Un même fichier, trois réponses différentes

Supposons qu’un dossier contienne des identifiants de véhicules, des diagnostics et des noms de conducteurs. Trois courriers peuvent concerner ce dossier sans demander la même chose.

Le premier vient d’une conductrice : « Je souhaite connaître les données que vous traitez sur moi. » Il relève de l’accès RGPD. La réponse porte aussi sur les informations de l’Art. 15, dont les finalités et destinataires, et pas seulement sur un fichier exporté. La présence de données de collègues appelle une conciliation de leurs droits, pas un refus automatique de toute réponse.

Le deuxième vient de l’entreprise locataire : « Transmettez les données techniques de ces véhicules au réparateur que nous désignons. » La qualité d’utilisateur, les données visées et le destinataire s’examinent sous le Data Act. Les données personnelles incluses restent soumises au contrôle RGPD. Le réparateur ne reçoit pas nécessairement le dossier complet que la conductrice pourrait obtenir au titre de son propre accès.

Le troisième vient de cette entreprise quittant son fournisseur de logiciel de gestion de flotte. Si le service relève du chapitre VI, l’export et le changement s’analysent dans ce cadre. Les données exportables et actifs numériques ne sont pas limités aux informations personnelles « fournies » par une personne au sens de l’Art. 20. Le projet doit aussi assurer la continuité des habilitations et du traitement licite chez le nouveau prestataire.

Le service chargé des demandes conserve donc leur fondement, leur auteur et leur objet. Il ne transforme pas les trois courriers en un ticket uniforme intitulé « portabilité ». Cela évite de répondre à la conductrice uniquement par un devis de migration ou de transmettre au réparateur toutes les pièces personnelles disponibles.

Examiner la base légale par opération

Le considérant 7 du Data Act distingue plusieurs situations. Il ne crée pas de base pour la collecte ou la génération initiale de données personnelles par le détenteur. Lorsque l’utilisateur n’est pas la personne concernée, il ne crée pas non plus de base permettant de lui donner accès ou de transmettre les données à un tiers. L’Art. 4(12) exige alors un fondement valable au titre de l’Art. 6 du RGPD et, si nécessaire, les conditions supplémentaires de l’Art. 9 et d’ePrivacy. Source : considérant 7 et Art. 4(12).

Évitez donc deux automatismes : inscrire « obligation légale Data Act » pour tous les flux, ou affirmer que le Data Act ne peut jamais fonder aucune obligation de mise à disposition. Analysez séparément la collecte, la communication demandée et la réutilisation par le destinataire. La base légale RGPD doit correspondre à l’opération et aux personnes concernées.

Lire précisément la réserve du considérant 7

La phrase « le Data Act oblige à partager » doit être complétée par « avec qui et pour quelle opération ? ». Le considérant 7 envisage l’obligation de mise à disposition demandée par l’utilisateur tout en excluant une base générale de collecte. Il énonce ensuite expressément la réserve lorsque cet utilisateur n’est pas la personne concernée. L’Art. 5(7) reprend cette exigence de fondement pour la mise à disposition du tiers.

Un contrat commercial entre le fabricant et l’entreprise ne devient pas, du seul fait de sa signature, le contrat auquel chaque conducteur serait partie au sens de l’Art. 6(1)(b). De même, faire signer une demande Data Act à un dirigeant ne vaut pas consentement des salariés dont les données figurent dans le fichier.

L’intérêt légitime peut être examiné lorsqu’il correspond effectivement au traitement envisagé, avec sa nécessité et la mise en balance des droits. Il ne suffit pas d’écrire « maintenance » dans un registre pour rendre nécessaire une transmission de tous les déplacements individuels. Si aucun fondement valable n’est établi pour le flux personnel demandé, le responsable ne l’ouvre pas en attendant une régularisation ultérieure. Il étudie le périmètre licite ou une autre modalité répondant au besoin sans contourner les garanties.

Exemple : une flotte utilisée par plusieurs conducteurs

La société qui loue les véhicules peut être utilisatrice au sens du Data Act. Les conducteurs restent les personnes concernées pour les données permettant de les identifier. Le prestataire qui reçoit un flux de diagnostic ne doit pas obtenir automatiquement tous les trajets individualisés si le service ne le nécessite pas.

Identifiez les données réellement utiles, la période, le rôle du destinataire et le fondement du partage. Une séparation des données ou une anonymisation effective peut aider ; une simple pseudonymisation ne fait pas disparaître le RGPD. Le propriétaire de l’objet, le titulaire du compte et la personne concernée peuvent être trois acteurs différents.

Poursuivons l’exemple avec une demande hypothétique de diagnostic d’un défaut moteur. Le réparateur demande les codes d’erreur, les mesures associées et les horodatages. Le détenteur propose aussi l’historique GPS et la table d’affectation des conducteurs, car son export standard les contient. Leur disponibilité ne démontre pas leur nécessité pour cette réparation.

Le dossier de partage peut alors retenir les décisions suivantes :

Cette dernière ligne est décisive : retirer les noms ne suffit pas à annoncer un fichier anonyme. Dans l’entreprise, le rapprochement avec le planning peut permettre d’identifier une conductrice. Le destinataire, les moyens de rapprochement raisonnablement utilisables et le contexte doivent être examinés. Le dossier conserve les garanties RGPD tant qu’une anonymisation effective n’est pas établie.

La décision est donc un partage réduit aux données nécessaires, après validation de son fondement et des rôles ; ce n’est pas une autorisation générale d’extraire tous les historiques. Si l’outil impose un export indivisible, une extraction séparée ou un autre moyen de transmission doit être organisé. Le blocage technique ne crée pas la base légale manquante. Inversement, il ne justifie pas d’abandonner sans examen toute réponse à une demande légitime.

Préserver les droits et la sécurité

Les principes de finalité, minimisation, durée et sécurité restent applicables. Les rôles déterminent les accords requis : Art. 28 du RGPD pour la sous-traitance, Art. 26 lorsque les conditions de responsabilité conjointe sont réunies. Ne qualifiez pas tout destinataire de sous-traitant par commodité. Sources : RGPD, chapitres II et IV, responsabilités.

L’effacement s’analyse selon l’Art. 17, y compris ses exceptions. La primauté du RGPD ne signifie pas que toute demande entraîne automatiquement une suppression ; elle ne justifie pas davantage une conservation indéfinie destinée à anticiper d’hypothétiques demandes Data Act. La checklist de double conformité transforme ces contrôles en décision documentée.

Le contrat décrit ce que le destinataire fait réellement. Un prestataire agissant uniquement sur instructions peut relever de l’Art. 28 ; s’il détermine un objectif propre de réutilisation, cette opération appelle une qualification distincte. La dénomination « tiers » dans le Data Act ne tranche aucune de ces deux situations à elle seule.

Enfin, séparez les délais. L’Art. 12(3) du RGPD prévoit une réponse sans tarder et en principe dans le mois, avec une prolongation encadrée. Les Art. 4(1) et 5(1) du Data Act exigent une mise à disposition sans retard injustifié : ce n’est pas une autorisation uniforme d’attendre un mois. Lorsqu’une demande comporte plusieurs fondements, le dossier suit chacun d’eux et explique les réponses ou limites propres à chaque volet. Sources : RGPD, Art. 12(3), Data Act, Art. 4(1) et 5(1).

Ce qu’il faut retenir

Le Data Act ne remplace ni les qualifications RGPD ni l’analyse de licéité. Distinguez les demandes, les opérations et les personnes. Le contrôle doit porter sur le flux concret avant l’ouverture d’un accès ou la transmission d’un fichier.

FAQ

Une entreprise est-elle une personne concernée au sens du RGPD ?

Non. Elle peut être utilisatrice Data Act, mais les droits individuels RGPD appartiennent aux personnes physiques concernées.

Les données non personnelles relèvent-elles du RGPD ?

Pas en tant que telles. Vérifiez toutefois qu’elles ne permettent pas d’identifier une personne, directement ou indirectement, notamment par rapprochement.

Le Data Act autorise-t-il à ignorer un refus de consentement ?

Non. Il faut examiner le traitement et son fondement réel. La demande d’un utilisateur commercial ne remplace pas automatiquement les conditions applicables aux données d’une autre personne.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

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