Interopérabilité : exigences techniques Data Act
Interopérabilité des données sous le Data Act : exigences techniques, normes, API ouvertes et spécifications communes.
L’interopérabilité Data Act ne se résume pas au choix d’un format JSON ou d’une API REST. Les obligations varient selon qu’il s’agit de l’accès à un produit connecté, d’un service cloud ou d’un participant à un espace de données. Un format techniquement ouvert ne suffit pas si son destinataire ignore les unités, les identifiants ou les restrictions d’utilisation.
Le travail utile consiste à relier chaque exigence juridique à une preuve technique : documentation, export, contrôle d’accès ou essai de réception. Source : Art. 3 à 5, 30 et 33 à 35 du Data Act.
Choisir le régime correspondant à l’activité
| Situation | Référence | Vérification principale |
|---|---|---|
| Accès aux données d’un produit connecté | Art. 3 à 5 | Données et métadonnées accessibles dans les conditions prévues |
| Changement d’un service cloud | Art. 30 | Obligations adaptées au type de service |
| Utilisation simultanée de plusieurs clouds | Art. 34 | Exigences applicables à cette utilisation et régime distinct des frais |
| Offre de données à d’autres participants d’un espace | Art. 33 | Description des ensembles, structures et moyens d’accès |
L’Art. 33(1) vise les participants aux espaces de données qui proposent des données ou services de données à d’autres participants. Il ne transforme pas toutes les entreprises possédant une base de données en opérateurs soumis à ce même régime. Les fabricants IoT doivent commencer par les obligations relatives à leurs produits.
Documenter le sens des données
Pour les acteurs visés par l’Art. 33, la documentation porte notamment sur le contenu, les restrictions d’utilisation, les licences, la collecte, la qualité et l’incertitude. Les structures, formats, vocabulaires et classifications doivent être décrits de manière cohérente et publiquement accessible dans les conditions du texte. Source : Art. 33(1)(a) et (b).
Préparez un dictionnaire comprenant le nom du champ, son type, sa signification, son unité, sa fréquence de mise à jour et les valeurs particulières. Pour une mesure de température, précisez l’unité et le statut d’étalonnage ; pour un horodatage, le fuseau et la précision. Présentez ces éléments comme une méthode de mise en œuvre, pas comme une liste de champs universellement imposée par le règlement.
Exemple commenté : rendre une mesure interprétable
Imaginons un participant à un espace de données industriel qui propose des relevés de température à des destinataires autorisés. L’exemple est fictif ; les nombres servent à expliquer une convention d’échange, pas à fixer une norme métrologique ou à annoncer un essai réalisé.
Trois enregistrements portent respectivement les valeurs brutes 200, 0 et une absence de valeur. La première erreur serait de considérer qu’ils représentent 200 °C, 0 °C et 0 °C. Pour cette interface hypothétique, le fournisseur a choisi des dixièmes de degré : 200 représente 20 °C ; 0 représente bien 0 °C ; l’absence reste une mesure manquante.
| Élément documenté | Convention retenue dans cet exemple | Conséquence pour le destinataire |
|---|---|---|
| Identifiant | Association stable du capteur et de l’instant de mesure | Repérer les doublons sans confondre deux capteurs |
| Valeur brute | Entier exprimé en dixièmes de degré Celsius | Diviser par dix pour obtenir la valeur affichée |
| Valeur absente | Absence de mesure, distincte de l’entier 0 | Exclure d’un calcul de moyenne et signaler le manque |
| Horodatage | Instant de mesure exprimé en UTC | Ne pas le confondre avec l’heure de réception |
| Qualité | Statut séparé : exploitable ou à contrôler | Ne pas utiliser automatiquement une mesure signalée à contrôler |
| Incertitude | Information distincte, documentée si connue | Une incertitude non fournie ne signifie pas une mesure exacte |
Pour les trois enregistrements annoncés, la moyenne des deux mesures disponibles est donc (20 + 0) / 2 = 10 °C. Remplacer l’absence par zéro donnerait (20 + 0 + 0) / 3, soit environ 6,67 °C : le fichier serait techniquement accepté, mais son interprétation serait fausse. La documentation doit aussi préciser si une moyenne portant sur seulement deux valeurs répond au besoin du destinataire ; ce calcul ne rend pas le jeu complet.
La convention est une décision d’ingénierie. Le rattachement juridique réside dans l’obligation de suffisamment décrire les données, leur qualité, leur incertitude et leurs structures pour les acteurs visés à l’Art. 33(1). Le règlement ne prescrit ni l’unité de stockage choisie ici ni ces libellés de qualité.
Décrire l’interface et ses limites
L’Art. 33(1)(c) prévoit une description suffisante des moyens techniques, de leurs conditions d’utilisation et de leur qualité de service pour permettre les échanges automatisés dans les conditions définies. Il cite les API comme exemple. Il ne prescrit pas REST, GraphQL ou un langage particulier à tous les acteurs.
Documentez les habilitations, la pagination, les volumes, les erreurs, les changements de version et les modalités de révocation. Distinguez les quotas nécessaires à la sécurité de ceux qui rendraient l’accès inutilisable. La fiche API et Data Act aide à transformer cette documentation en parcours d’accès.
Pour l’exemple des températures, la documentation précise aussi si un appel renvoie toutes les mesures ou une seule page, et comment obtenir la suivante. Sans cette indication, un destinataire peut traiter les premières lignes comme un export complet. Une réponse vide doit être distinguée d’un accès refusé, d’un capteur sans mesure et d’une période inexistante.
Publier la description d’une interface n’impose pas de publier ses secrets d’authentification. Les droits de lecture sont accordés aux destinataires autorisés, pour les ensembles prévus, et peuvent être retirés selon les règles applicables. La documentation décrit ce fonctionnement ; elle ne remplace pas la décision juridique autorisant le partage.
Cloud : distinguer équivalence et compatibilité
L’Art. 30(1) impose aux services d’infrastructure qu’il définit des mesures raisonnables facilitant l’équivalence fonctionnelle. Pour les autres services, l’Art. 30(2) organise la mise à disposition gratuite d’interfaces ouvertes facilitant le changement. L’Art. 30(5) prévoit un export structuré, couramment utilisé et lisible par machine en cas de changement vers un service du même type, en l’absence des spécifications ou normes concernées dans le répertoire prévu.
Aucun de ces mécanismes ne garantit que deux applications différentes auront les mêmes fonctions. L’Art. 30(6) préserve notamment certaines limites liées aux nouvelles technologies, aux actifs protégés et à la sécurité. Un projet de portabilité cloud doit donc tester les données et les fonctions réellement nécessaires.
L’utilisation simultanée de clouds relève aussi de l’Art. 34. Son paragraphe 2 prévoit un régime spécifique des frais de transfert limité aux coûts de sortie occasionnés. Il ne faut pas lui appliquer automatiquement une promesse de gratuité issue du seul changement de fournisseur.
Ne pas confondre standard courant et norme harmonisée
Un standard largement employé peut être un bon choix d’ingénierie. Cela ne lui confère pas automatiquement le statut de norme harmonisée du Data Act. Pour la présomption de conformité de l’Art. 33(3), vérifiez la référence publiée au Journal officiel et les exigences effectivement couvertes.
Le règlement distingue les normes harmonisées, les spécifications communes adoptées par actes d’exécution et certains pouvoirs d’actes délégués précisant les exigences. Les Art. 30(3) et 35(8) organisent aussi le mécanisme de référence et de délai pour le cloud. Conservez la référence exacte et sa date au lieu d’écrire « conforme aux standards européens » sans preuve.
L’acheteur peut demander une démonstration documentaire précise : référence de la norme invoquée, publication officielle, version appliquée et exigences couvertes. Si le fournisseur remet seulement le nom d’un format, la conclusion est « format identifié, présomption de conformité non démontrée ». Ce constat n’établit pas à lui seul une non-conformité : il signifie que cette preuve particulière manque et que les exigences doivent être justifiées autrement.
Faire un essai de bout en bout
Donnez à une équipe destinataire autorisée un jeu représentatif et la seule documentation prévue pour les clients. Vérifiez si elle sait récupérer les données, interpréter les unités, reconstruire les relations et traiter une erreur. Consignez ce qui manque avant de conclure que l’interface est exploitable.
Pour les relevés de température, le destinataire doit restituer 20 °C, 0 °C et « mesure absente », conserver le bon instant et retrouver la totalité des pages. Le responsable du jeu contrôle la correspondance avec les données de départ ; le responsable du système destinataire explique les transformations. Si le destinataire transforme l’absence en zéro, la règle d’import doit être corrigée avant d’utiliser ces mesures pour une décision opérationnelle. Ajouter une note dans un compte rendu sans changer ce traitement ne résout pas le problème.
Une évolution doit être traitée de la même manière. Si la version suivante exprime directement les degrés, conserver un nom de champ identique sans signaler ce changement produirait une division erronée par dix. Le dossier indique la version, la date d’effet, les destinataires informés et les jeux de contrôle concernés. Le fournisseur et le destinataire organisent la transition afin que les anciennes données restent interprétables ; il ne suffit pas de remplacer la documentation en ligne.
Les données personnelles exigent en plus une base légale, des habilitations et des garanties appropriées. L’ouverture technique ne signifie pas l’ouverture publique des données. Le guide Data Act et RGPD traite cette articulation.
Enfin, un identifiant de machine peut devenir une donnée personnelle si les informations disponibles permettent de le rattacher à un opérateur. Ne concluez pas à l’anonymat sur la seule absence d’un nom dans le fichier. Décrivez l’accès autorisé, les réutilisations et la durée pertinente ; la documentation publique peut rester limitée au schéma et à des exemples fictifs. L’Art. 1(5) du Data Act préserve le droit de la protection des données, dont les principes de finalité et de minimisation.
Ce qu’il faut retenir
L’interopérabilité exige un périmètre juridique correct, une documentation du sens des données et un essai avec le destinataire. Une API ou un format courant est un moyen ; sa présence ne prouve pas à elle seule la conformité.
FAQ
Le Data Act impose-t-il JSON ou REST ?
Non. Le règlement fixe des exigences selon les situations, sans imposer universellement ce format ou cette architecture. Vérifiez les textes et références applicables à votre service.
Faut-il publier les données pour rendre les structures accessibles ?
Non. La documentation des structures et les droits d’accès aux données sont deux sujets différents. Les données restent soumises aux restrictions légitimes et au RGPD lorsqu’il s’applique.
Un export qui s’ouvre dans un tableur suffit-il ?
Pas nécessairement. Le destinataire doit pouvoir comprendre et exploiter le périmètre concerné. Les identifiants, métadonnées et relations peuvent être indispensables.
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.