Data Act et RGPD : checklist de double conformité

Pour partager les données d’un produit connecté, il faut décider quelles données peuvent sortir, vers qui, pour quoi faire et avec quelles garanties. Le droit d’accès du Data Act ne dispense pas de justifier les traitements de données personnelles. Une case « contrat signé » ne répond donc pas à toutes ces questions.

La checklist ci-dessous sert à constituer un dossier commun au produit, au juridique, à la sécurité et au DPO. Elle concerne le partage des données de produits connectés avec un tiers, principalement au titre du chapitre II. Les différences entre Data Act et RGPD permettent de qualifier les autres situations.

L’Art. 1(5) du Data Act maintient les règles de protection des données personnelles et leur priorité en cas de conflit. Son considérant 7 précise qu’il ne crée pas de fondement juridique pour leur collecte ou leur génération. Cette première distinction évite de régulariser après coup un historique constitué sans justification. Source : règlement 2023/2854.

Ouvrir une fiche pour un flux précis

Inscrivez dans la fiche le produit, l’utilisateur, le détenteur des données, le tiers destinataire, les dates demandées et le service attendu. « Toutes les données de nos machines » est trop imprécis pour préparer les habilitations et rechercher les personnes concernées.

Identifiez ensuite les données relatives au produit, celles d’un service connexe et les métadonnées nécessaires à leur compréhension. La notion de données facilement accessibles vise celles que le détenteur obtient ou peut obtenir légalement sans effort disproportionné dépassant une simple opération. Elle ne signifie pas qu’il doit créer toute analyse imaginable. Source : Data Act, Art. 2(12) à (17).

Le dossier doit aussi justifier l’application du chapitre II : les exceptions de l’Art. 7 concernent notamment certaines petites entreprises et certaines situations transitoires d’entreprises moyennes, avec leurs conditions. La seule mention « PME » ne suffit pas pour conclure.

Enfin, distinguez les échéances. Le règlement s’applique depuis le 12 septembre 2025 ; l’obligation de conception de l’Art. 3(1) vise les produits et services connexes mis sur le marché après le 12 septembre 2026. Un équipement plus ancien ne permet donc pas de reporter indistinctement tous les droits d’accès. Le guide des obligations des fabricants IoT développe ce contrôle. Source : Data Act, Art. 7 et 50.

Exemple rempli : le dossier D14

Prenons un dossier entièrement fictif. Une entreprise possède quatre installations frigorifiques connectées, F1 à F4. Elle demande que les données du 1er au 20 septembre soient transmises à un mainteneur pour diagnostiquer des variations de température. Le diagnostic doit porter sur les équipements, sans évaluer individuellement les salariés.

Dans cette hypothèse, le service juridique a établi que les installations et données demandées relèvent du chapitre II et qu’aucune exception de l’Art. 7 ne s’applique. L’entreprise justifie sa qualité d’utilisateur et désigne le mainteneur. Celui-ci reçoit les informations pour cette mission, sans projet de réutilisation propre.

L’inventaire initial comprend températures, horodatages, codes d’erreur, identifiants des installations, identifiants d’opérateurs et commentaires libres. L’équipe métier explique pourquoi les quatre premières catégories sont nécessaires au diagnostic. Elle retire de la demande les identifiants d’opérateurs et les commentaires : ces champs n’apportent rien à l’analyse recherchée.

Ce retrait ne rend pas automatiquement le fichier anonyme. Les heures d’intervention peuvent encore être rapprochées d’un planning détenu par l’entreprise. Le dossier conserve donc la qualification de données personnelles pour les informations permettant ce rapprochement. Voici une synthèse de décision utilisable, dont les responsabilités constituent une proposition d’organisation.

La ligne « licéité » reste ouverte tant que son analyse n’est pas terminée. Six lignes renseignées sur sept ne donnent pas une autorisation de transmettre.

Documenter la base légale de chaque opération

Lorsque l’utilisateur n’est pas la personne dont les données sont demandées, les Art. 4(12) et 5(7) exigent un fondement valable au titre de l’Art. 6 du RGPD et, si nécessaire, le respect de l’Art. 9 et des règles ePrivacy. Dans D14, la société utilisatrice n’est pas les salariés identifiables dans les enregistrements. Source : Data Act.

Le contrat commercial conclu avec cette société ne permet pas, à lui seul, d’invoquer l’Art. 6(1)(b) pour les données de ses salariés : ils ne sont pas parties à ce contrat. Écrire « obligation légale Data Act » sur toute la chaîne ne résout pas davantage la collecte initiale et les usages ultérieurs.

Dans notre exemple, l’entreprise peut examiner l’intérêt légitime de maintenance : intérêt réel, nécessité des données retenues, effets sur les opérateurs et garanties. L’analyse doit notamment expliquer pourquoi un relevé moins détaillé ne permettrait pas le diagnostic et pourquoi les informations ne servent pas à surveiller les performances individuelles. Si elle ne permet pas de justifier le traitement, la ligne reste non validée ; il faut réduire ou revoir le flux, sans fabriquer un consentement de façade. Source : RGPD, Art. 6(1)(f).

Le détenteur examine également la licéité de sa communication. Une conclusion de l’entreprise destinataire ne le dispense pas de ses propres obligations. La qualification du mainteneur dépend de ses activités réelles : ses éventuelles finalités autonomes doivent être analysées séparément. L’accord de sous-traitance couvre les opérations effectuées pour le compte de l’entreprise, conformément à l’Art. 28. Source : RGPD, chapitre IV.

Exiger une réception technique interprétable

Un transfert réussi ne se résume pas à recevoir un fichier. Pour D14, l’équipe de réception doit pouvoir interpréter chaque mesure : unité de température, fuseau horaire, signification des codes et identification des installations. Une colonne « valeur » sans unité ne suffit pas.

La recette proposée comprend quatre résultats attendus : les données autorisées sont accessibles ; celles d’une cinquième installation ne le sont pas ; les champs exclus n’apparaissent pas dans l’export ni ses fichiers annexes ; la révocation du compte interdit un nouvel accès. Le guide des API et du Data Act détaille cette préparation.

Conservez le périmètre contrôlé, la date, la configuration et les résultats observés. Les résultats décrits ici sont des exigences de réception, aucun essai réel n’est allégué. Si un contrôle échoue, l’ouverture du flux concerné attend une correction et un nouveau contrôle. Une extraction limitée peut constituer une solution si elle répond effectivement à la demande et aux exigences applicables ; elle ne doit pas servir à contourner un droit à des données plus complètes.

L’Art. 5(1) prévoit notamment une mise à disposition sans retard injustifié, sécurisée et accompagnée des métadonnées pertinentes. Une validation interne ne crée pas un délai supplémentaire libre. Les informations conservées sur l’accès sont elles-mêmes limitées par l’Art. 5(4). Ne journalisez pas tous les contenus « au cas où ». Source : Data Act.

Préparer l’information, l’utilisation et la sortie

Les informations Data Act fournies avant le contrat, selon l’Art. 3(2) ou (3), concernent notamment les données, leur accès et le service. Elles ne remplacent pas l’information RGPD des personnes concernées. Dans D14, celle-ci doit correspondre au diagnostic réellement organisé, à ses destinataires, à sa base légale et aux droits applicables. Source : RGPD, Art. 13 et 14.

Le tiers ne reçoit pas un droit général d’exploiter l’historique. L’Art. 6 du Data Act encadre ses finalités et lui impose d’effacer les données devenues inutiles à la finalité convenue, sous réserve de l’exception prévue pour des données non personnelles. Le profilage est interdit sauf nécessité pour le service demandé ; cette exception ne dispense pas du RGPD. Source : Data Act, Art. 6.

La fiche D14 doit ainsi distinguer fermeture de l’accès, suppression des extractions de travail et conservation éventuelle du rapport. Pour ce dernier, précisez ce qui doit rester, pourquoi et pendant combien de temps ; retirez les informations personnelles inutiles. La durée du contrat ne justifie pas mécaniquement toutes les copies.

Avant lancement, examinez aussi le risque nécessitant une analyse d’impact, les éventuels transferts hors EEE et le traitement des demandes de droits. L’AIPD dépend des conditions de l’Art. 35, notamment du risque élevé, et n’est pas automatique pour chaque partage. Le plan d’action Data Act aide à attribuer les actions aux équipes.

Signer une décision limitée au périmètre démontré

Le responsable de traitement conserve une conclusion motivée, avec l’avis du DPO lorsqu’il intervient. Pour D14, la formulation peut être : « Ouverture du diagnostic F1–F4 après validation de la licéité, signature de l’accord applicable et réception des contrôles d’accès. Aucun usage d’évaluation individuelle ni élargissement à d’autres installations n’est couvert. »

Cette rédaction constitue une instruction interne partielle, pas une clause contractuelle complète. Chaque condition doit ensuite recevoir sa preuve et sa date de réalisation. Une condition inconnue ne devient pas satisfaite par l’absence de réponse du fournisseur.

Enfin, séparez anomalie technique et refus juridique. Si des secrets d’affaires sont invoqués, les données concernées et les garanties doivent être identifiées. Les mécanismes de suspension et de refus des Art. 5(9) à (12) ont leurs propres conditions, motivations et notifications. Le mot « confidentiel » ne justifie pas de bloquer tout le dossier.

Ce qu’il faut retenir

La checklist produit une décision sur un flux défini. Elle relie les données nécessaires, les personnes concernées, la licéité, les rôles, les accès et la clôture. Chaque point non résolu doit conserver son statut ; aucune moyenne de cases cochées ne remplace une condition juridique manquante.

FAQ

Une demande d’effacement impose-t-elle de supprimer toutes les preuves ?

Non. Appliquez les motifs et exceptions de l’Art. 17 du RGPD. Distinguez les données de travail devenues inutiles d’une preuve nécessaire à une obligation ou à un litige, avec accès et conservation justifiés.

Le mainteneur peut-il conserver les données pour améliorer son offre ?

Cette finalité n’est pas incluse automatiquement dans le diagnostic convenu. Elle nécessite une analyse distincte du Data Act et du RGPD ; le simple changement de nom du fichier ne l’autorise pas.

Toute anomalie déclenche-t-elle une notification sous 72 heures ?

Non. Qualifiez d’abord l’éventuelle violation de données personnelles. L’Art. 33(1) prévoit une notification sans retard injustifié, si possible sous 72 heures, sauf risque improbable ; le sous-traitant alerte sans retard injustifié selon l’Art. 33(2).

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.