Data Act et objet connecté : recetter l’accès aux données

Le Data Act impose de penser l’accès aux données d’un objet connecté avant sa mise sur le marché. Pour les produits connectés et services connexes commercialisés après le 12 septembre 2026, l’obligation de conception de l’article 3, paragraphe 1, devient applicable : les données du produit et du service connexe, avec les métadonnées nécessaires à leur interprétation, doivent être accessibles par défaut de manière simple, sûre, gratuite, complète, structurée et lisible par machine.

Il ne suffit donc pas d’ajouter un bouton « Exporter ». L’entreprise doit savoir quelles données existent, qui peut les demander, où elles sont disponibles, dans quel format et à quelle fréquence, puis articuler cet accès avec le RGPD, les secrets d’affaires et la sécurité du produit. Le livrable utile est une recette de bout en bout, exécutée sur des comptes et appareils fictifs avant le lancement.

Quels produits et quelles données le Data Act vise-t-il ?

Le règlement européen sur les données définit le produit connecté comme un bien qui obtient, génère ou recueille des données sur son utilisation ou son environnement et qui peut les communiquer. Une machine industrielle, un véhicule, un équipement énergétique, un appareil de santé grand public ou un objet domestique peuvent entrer dans cette définition. Un service connexe est un service numérique lié au produit dont l’absence empêcherait une ou plusieurs fonctions, ou qui ajoute ensuite des fonctions au produit.

Le chapitre II vise les données générées par l’utilisation du produit ou du service connexe, qu’elles soient personnelles ou non personnelles. La Commission européenne précise que les données brutes et prétraitées facilement disponibles entrent dans ce périmètre, avec les métadonnées utiles. Le contenu lui-même, ainsi que les informations déduites ou dérivées par un traitement complexe, n’y entrent pas automatiquement.

Cette frontière doit être traduite dans le modèle de données. Une température mesurée, un cycle d’usage, un événement de maintenance ou la position d’un capteur ne se confondent pas avec un score prédictif, un diagnostic propriétaire ou le contenu créé par l’utilisateur. Une colonne « dans le périmètre » sans justification ne suffit pas : chaque famille doit être reliée à sa source, à son niveau de traitement et à la personne capable d’expliquer la décision.

Que change précisément le 12 septembre 2026 ?

Le Data Act s’applique dans son ensemble depuis le 12 septembre 2025. Son article 50 prévoit toutefois que l’obligation de conception de l’article 3, paragraphe 1, s’applique aux produits connectés et services connexes mis sur le marché après le 12 septembre 2026.

Lorsque cela est pertinent et techniquement possible, l’utilisateur doit pouvoir accéder directement aux données depuis le produit. Sinon, le détenteur doit rendre les données facilement disponibles sans retard injustifié, gratuitement, dans la même qualité que celle dont il dispose et, si possible, au moyen d’une demande électronique simple. L’accès peut devoir être continu et en temps réel lorsqu’une telle fréquence est prévue et disponible.

Avant le contrat, l’utilisateur doit recevoir des informations compréhensibles sur la nature, le format et le volume estimé des données, leur génération éventuelle en continu et en temps réel, leur stockage, la durée de conservation et les moyens d’accès, de récupération ou d’effacement. Il doit également savoir qui détient les données, à quelles fins cette entreprise compte les utiliser et comment demander leur partage à un tiers.

Cette échéance n’interdit pas un lancement. Elle oblige à traiter la donnée comme une fonction du produit : architecture, information précontractuelle, authentification, format, support, journalisation et repli doivent raconter la même histoire.

La matrice Zence : une ligne par flux réellement disponible

Construisez la matrice à partir d’un appareil et d’un compte de test, pas à partir d’une promesse marketing. Une même mesure peut emprunter le Bluetooth, l’application, une API et un entrepôt cloud ; chaque surface produit une disponibilité et un risque différents.

Donnée	Utilisateur légitime	Canal d’accès	Format	Fréquence	Base RGPD si nécessaire	Exception ou protection	Preuve de recette
mesure brute du capteur	propriétaire ou locataire qualifié	export local ou API	CSV ou JSON documenté	à la demande ou continu	à qualifier selon la personne et la finalité	sécurité du produit	export horodaté et schéma de champs
état de fonctionnement	utilisateur du produit	application et API	JSON	quasi temps réel	minimisation si identifiant personnel	secret identifié champ par champ	comparaison appareil, API et écran
événement de maintenance	utilisateur et réparateur mandaté	portail de partage	CSV avec métadonnées	à la demande	mandat et base à vérifier	droits du tiers et durée d’accès	invitation, révocation et journal
localisation de l’appareil	personne concernée ou utilisateur autorisé	API sécurisée	GeoJSON ou JSON	selon l’usage annoncé	base de l’article 6 et information	risque pour les droits et la sécurité	test de rôle, précision et suppression
score calculé propriétaire	à qualifier	hors export ou restitution distincte	documentation de décision	ponctuel	dépend des données sources	donnée dérivée, secret possible	justification écrite du périmètre

Cette matrice n’est pas un modèle juridique universel. Elle révèle les décisions qui doivent être validées. Si une case « format » reste vide, l’équipe ne peut pas tester la portabilité. Si la base RGPD est remplacée par « Data Act », elle masque une erreur : le règlement sur les données ne crée pas à lui seul une base légale pour transmettre les données personnelles d’une personne à un utilisateur qui n’est pas cette personne.

Accès direct, API ou export : choisir sans créer une impasse

L’accès direct convient lorsque l’appareil peut exposer les données pertinentes de façon sûre et compréhensible. Il réduit la dépendance au fabricant, mais demande une interface stable, une authentification proportionnée et une documentation utilisable. Un port local incompréhensible ou un fichier binaire sans dictionnaire ne satisfait pas l’objectif.

Une API permet un accès fréquent, le partage avec un tiers choisi et une gestion fine des droits. Elle devient toutefois une fonction exploitée : disponibilité, quotas, versions, révocation, journalisation et support doivent être prévus. L’authentification ne doit pas recueillir plus d’informations que nécessaire pour vérifier la qualité d’utilisateur, et les journaux d’accès doivent eux aussi rester proportionnés.

Un export à la demande peut suffire pour des données peu fréquentes. Il faut alors tester le délai, l’exhaustivité, les fuseaux horaires, les unités, les valeurs nulles, les identifiants et les métadonnées. Une archive reçue trois semaines plus tard, impossible à relier au produit ou aux horodatages, révèle une fonction incomplète.

Le choix peut combiner ces voies : données récentes en accès direct, historique en API, archive complète sur demande. L’important est d’annoncer clairement la disponibilité réelle et de prouver que les trois sorties restent cohérentes.

Huit scénarios de recette avant la commercialisation

Exécutez les tests avec des données fictives représentatives, puis conservez le résultat, la version du produit et le responsable de la décision.

1. Premier appairage. Un nouvel utilisateur identifie les données générées, les formats, les fréquences et les conditions d’accès avant d’accepter le service.
2. Accès direct nominal. Il récupère une série connue depuis l’appareil ou l’application ; valeurs, unités, horodatages et métadonnées correspondent à la référence.
3. Export historique. Une demande couvre une période avec changement d’heure, données absentes et remplacement du capteur ; l’archive explique chaque rupture sans inventer de valeur.
4. Partage avec un tiers. L’utilisateur autorise un réparateur fictif, limite les données et la durée, puis révoque l’accès sans couper son propre usage.
5. Compte partagé. Plusieurs personnes utilisent le produit. Le parcours distingue l’utilisateur qui demande les données des personnes concernées et bloque une transmission sans base valable.
6. Secret d’affaires identifié. Le détenteur nomme précisément les données concernées, applique les mesures proportionnées convenues et conserve la motivation. Une étiquette générale « confidentiel » ne ferme pas tout l’export.
7. Risque grave pour la sécurité. Le test documente le scénario concret, l’exigence de sécurité touchée, les mesures alternatives et l’escalade compétente avant toute restriction d’accès.
8. Fin de relation. L’utilisateur récupère ce qui lui revient, révoque les tiers, comprend les durées de conservation et vérifie le comportement après suppression du compte ou transfert du produit.

Chaque scénario reçoit un statut simple : passé avec preuve, bloqué avec responsable et date, ou non applicable avec justification. Testez aussi le repli. Si l’API tombe, l’utilisateur doit savoir si une voie différée existe ; si le produit change de propriétaire, l’ancien accès ne doit pas survivre silencieusement.

Comment articuler Data Act, RGPD, sécurité et secrets d’affaires ?

La CNIL rappelle qu’en cas de conflit, les règles de protection des données personnelles prévalent. Lorsque l’utilisateur n’est pas la personne concernée, le détenteur ne communique des données personnelles que si une base juridique valable existe au titre de l’article 6 du RGPD et si les autres conditions applicables sont remplies. Le produit doit donc savoir séparer les flux, réduire les champs ou recueillir une autorisation appropriée au lieu d’exporter tout le compte.

Les secrets d’affaires ne constituent pas non plus un interrupteur global. Le règlement prévoit leur identification et des mesures techniques ou organisationnelles proportionnées convenues avec l’utilisateur. Dans certaines circonstances exceptionnelles, un détenteur peut suspendre ou refuser le partage s’il démontre un risque de préjudice économique grave et irréparable ; la motivation et les notifications prévues doivent alors être documentées.

Une restriction pour raison de sécurité demande elle aussi un cas étroit. L’article 4 permet de limiter ou refuser l’accès lorsque celui-ci risque de compromettre les exigences de sécurité du produit et d’entraîner des effets négatifs graves sur la santé, la sûreté ou la sécurité des personnes. Une préférence d’architecture ou la peur abstraite d’une copie ne suffisent pas à démontrer ce risque.

Enfin, le chapitre II prévoit une exemption pour les données générées par des produits ou services connexes fabriqués ou conçus par une micro ou petite entreprise, sous conditions et avec des exceptions liées notamment aux entreprises partenaires, liées ou aux relations de sous-traitance. Il faut qualifier cette situation avec prudence : la taille ne doit pas devenir un drapeau codé en dur qui dispense d’examiner le contrat, le groupe et le fabricant réel.

Exemple fictif : un capteur de maintenance industrielle

Imaginons un capteur fictif qui mesure vibration, température et cycles d’une machine. L’application affiche un état, tandis que le cloud conserve l’historique et calcule un indicateur de maintenance. L’entreprise cliente veut transmettre les mesures à son mainteneur indépendant.

La recette commence par trois séries connues injectées dans le capteur. Elle compare la lecture locale, l’API et l’archive mensuelle. Elle vérifie que les unités et fuseaux horaires sont constants, que l’indicateur calculé est distingué des mesures sources et que le mainteneur ne voit que les machines sélectionnées. Après révocation, son jeton échoue immédiatement tandis que l’historique du client reste disponible.

Le dossier contient le schéma de données, l’information avant contrat, la preuve d’authentification, les sorties comparées, le test de révocation et la décision sur l’indicateur dérivé. Il ne conclut pas à la conformité juridique du fabricant. Il prouve que les personnes compétentes peuvent examiner un système réel plutôt qu’une promesse.

Commencer par une preuve complète, pas par un portail

Le premier livrable peut tenir dans une matrice renseignée, un jeu de données fictif, un export lisible et deux tests : partage à un tiers, puis révocation. Cette preuve révèle si le blocage vient du firmware, de l’application, du cloud, des identités, du contrat ou de la qualification juridique.

Le guide sur le Cyber Resilience Act aide à traiter séparément le cycle de vie cyber du produit. Le test de réversibilité cloud et SaaS reste consacré au changement de fournisseur, non aux données générées par l’usage d’un objet. Pour cadrer rôles, interfaces et critères, le modèle de cahier des charges Zence permet de transformer la matrice en exigences vérifiables.

Zence conçoit des logiciels métier sur mesure qui relient appareils, données, droits et exploitation. Pour préparer une mise sur le marché après septembre 2026, faites recetter le parcours d’accès aux données. La qualification du produit, de l’entreprise, des données et des bases juridiques reste à valider avec les professionnels compétents.

Sources officielles

• EUR-Lex — Règlement (UE) 2023/2854 sur des règles harmonisées concernant l’équité de l’accès aux données et de l’utilisation des données, notamment les articles 2 à 4, 7 et 50.
• Commission européenne — Data Act explained, périmètre des données, accès, partage et articulation avec les données personnelles.
• CNIL — Le Data Act, un nouveau cadre européen pour le partage et l’utilisation des données, publié le 22 décembre 2025.