Data Act et API : concevoir un accès utilisable

Le Data Act impose des résultats d’accès aux données ; il ne prescrit pas une API REST à chaque fabricant. Le choix technique dépend du produit, des données et des exigences applicables. Une API peut être adaptée aux échanges réguliers, tandis qu’un accès local ou un export peut répondre à d’autres situations.

L’Art. 3(1) concerne la conception accessible ; les Art. 4(1) et 5(1) précisent les conditions de mise à disposition. Pour certains services cloud, l’Art. 30(2) impose spécifiquement des interfaces ouvertes gratuites. Ces régimes ne doivent pas être confondus. Source : Data Act.

Traduire l’obligation en critères d’acceptation

Cette grille est une méthode de travail. Elle n’érige pas un protocole particulier en obligation légale. La fiche interopérabilité Data Act détaille les différences entre formats courants et normes harmonisées.

Concevoir une autorisation suffisamment précise

L’accès doit distinguer le compte client, le produit, la période et le destinataire autorisé. Un jeton donnant accès à toute une flotte peut divulguer les données d’utilisateurs non concernés. Préparez une procédure de révocation lorsque l’habilitation ou le mandat prend fin. Cela ne permet pas de supprimer indistinctement tout droit d’accès à des données historiques : vérifiez séparément le périmètre auquel l’utilisateur peut encore prétendre.

L’Art. 4(5) limite les informations exigées pour vérifier la qualité d’utilisateur ainsi que les informations conservées sur l’accès aux nécessités de la demande, de la sécurité et de la maintenance. L’Art. 5(4) prévoit une règle comparable pour le tiers. Journaliser utilement ne signifie donc pas conserver indéfiniment toutes les requêtes et tous leurs contenus. Source : Art. 4(5) et 5(4).

Rédiger une spécification d’accès, pas seulement une URL

Prenons une situation de conception hypothétique. Une PME loue deux compresseurs, C17 et C18. Elle demande au détenteur de communiquer leurs mesures de fonctionnement à un mainteneur indépendant pour préparer une intervention. La demande vise les trente derniers jours, les codes d’erreur et les métadonnées nécessaires à leur compréhension. Les équipements et données sont supposés relever du chapitre II ; le dossier doit confirmer cette qualification avant le développement.

La PME utilisatrice n’a pas besoin de devenir propriétaire des machines. En revanche, une facture de maintenance ne prouve pas, à elle seule, que le réparateur a reçu une demande de partage valable. Le détenteur vérifie la qualité de l’utilisateur et le mandat du destinataire sans réclamer un dossier disproportionné. Source : Art. 2(12), 4(5) et 5(1)/(4) du Data Act.

Voici une proposition de spécification renseignée pour cette situation. Les identifiants et choix techniques sont illustratifs, sans décrire un produit existant ni un test réalisé.

Ce document relie la demande juridique à ce que le serveur autorise réellement. Le logiciel ne doit pas déduire que « connaît le numéro de machine » signifie « peut lire ses données ». Une vérification côté serveur porte sur chaque ressource demandée, y compris lorsqu’une requête contient plusieurs machines. Masquer un bouton dans l’interface ne protège pas une adresse d’accès encore utilisable directement.

Le mandat ne dispense pas le tiers de ses obligations. Les données reçues doivent être traitées aux fins et selon les conditions convenues avec l’utilisateur, avec les règles de suppression prévues par l’Art. 6(1). Le mainteneur ne reçoit donc pas un droit indifférencié de réutilisation. La durée du jeton technique et celle de conservation des données déjà reçues sont deux décisions séparées.

Documenter les erreurs, les volumes et les versions

Décrivez les paramètres, la pagination, les erreurs, les limites de débit et les dates de changement. Un export qui ne renvoie que les premières lignes sans l’indiquer peut donner une fausse impression d’exhaustivité. Les limites opérationnelles doivent être compatibles avec les conditions d’accès applicables.

Pour chaque restriction, documentez le risque ou la contrainte observée et le moyen de demander un accès adapté. Une formule générale « sécurité » ne justifie pas toute réduction d’accès. Les secrets d’affaires suivent leurs propres conditions aux Art. 4(6) à (8) et 5(9) à (11).

Donner un sens vérifiable à « export complet »

Dans cette même spécification, supposons que le jeu d’essai contient 240 mesures pour la période autorisée et que la réponse est limitée à 100 mesures par page. La réception attendue comprend trois pages : 100, 100 puis 40 mesures. Recevoir une première réponse réussie ne suffit donc pas à prononcer la réception du flux.

Le destinataire doit savoir comment demander la suite et distinguer une fin normale d’une interruption. Il rapproche les identifiants, recherche les doublons et contrôle les bornes temporelles. Si une nouvelle mesure arrive pendant la lecture, la documentation doit expliquer si elle appartient au périmètre de cette extraction ou à la suivante. Un curseur de pagination, une borne de capture ou un mécanisme équivalent peuvent répondre à ce besoin ; le règlement n’impose pas ici une solution informatique unique.

Il faut aussi distinguer « aucune mesure produite », « mesure non disponible » et « accès refusé ». Retourner une liste vide pour les trois situations rend le diagnostic impossible. La documentation décrit le sens de chaque réponse sans révéler au demandeur non autorisé l’existence ou les caractéristiques des machines d’un autre client. L’objectif est un comportement compréhensible et sûr, pas un code d’erreur prétendument prescrit par le Data Act.

Séparer le flux de l’utilisateur et celui du tiers

Le tiers doit disposer du mandat ou de la demande permettant la transmission et respecter les finalités convenues. Ne partagez pas simplement les identifiants administrateur du client avec son prestataire de maintenance. Créez un accès limité, traçable et révocable.

L’accès de l’utilisateur est sans frais selon l’Art. 4(1) ; la transmission prévue à l’Art. 5(1) est sans frais pour lui. Les rapports financiers avec le destinataire professionnel suivent les Art. 8 et 9. Il serait inexact d’en déduire que toute intégration personnalisée est nécessairement gratuite ou, à l’inverse, de facturer l’accès légal sous couvert d’un abonnement API. Le guide d’accès aux données IoT décrit le parcours de demande.

Intégrer le contrôle RGPD au périmètre de réponse

La présence d’une API ne résout pas la licéité du partage. Lorsque l’utilisateur n’est pas la personne concernée, l’Art. 4(12) exige notamment un fondement valable pour les données personnelles. Identifiez les données de tiers avant de définir la réponse, et vérifiez les finalités ainsi que les habilitations.

Le guide Data Act et RGPD permet de traiter ces questions avec le DPO. Une pseudonymisation peut réduire certains risques sans faire disparaître automatiquement le caractère personnel des données.

Tester un parcours complet

Testez une demande autorisée, une demande portant sur un autre produit, un mandat expiré, un export volumineux et une révocation. Vérifiez aussi que la documentation permet au destinataire de comprendre les données sans connaissance interne du fabricant.

Dans le dossier des compresseurs, la réception exige des résultats précis : les trois pages restituent les 240 mesures attendues du jeu d’essai ; C19 reste inaccessible ; un accès expiré ou révoqué ne délivre plus de données ; les unités et codes sont compris à partir de la documentation fournie. Ces résultats sont des critères à vérifier, pas des constats de tests déjà effectués.

La révocation mérite un contrôle complet : fermer le compte de l’interface ne suffit pas si un jeton secondaire ou un lien de téléchargement reste utilisable. Recensez les voies d’accès ouvertes et définissez comment leur fermeture sera vérifiée. Un export déjà remis au mainteneur n’est pas rappelé magiquement par la révocation : son traitement ultérieur relève aussi des engagements convenus et des règles applicables.

Si une autorisation fuit vers une autre machine, le périmètre concerné ne doit pas être ouvert en production. Corrigez la règle d’accès, examinez les éventuelles communications déjà survenues et rejouez les parcours autorisés et interdits. Si le défaut porte sur la complétude, conservez une réserve explicite : ne présentez pas un flux partiel comme la réalisation du droit. Une solution d’accès alternative doit elle-même satisfaire les exigences applicables ; une capture d’écran illisible n’est pas une réponse de secours suffisante.

Pour les nouvelles conceptions visées par l’Art. 3(1), l’Art. 50 retient la mise sur le marché après le 12 septembre 2026. Les obligations des fabricants IoT doivent intégrer cette vérification au dossier produit.

Ce qu’il faut retenir

Choisissez le moyen d’accès à partir des obligations et du besoin réel. L’API doit rendre les données utilisables par un destinataire habilité, sans ouvrir des accès excessifs. Documentez les limites et vérifiez le parcours complet.

FAQ

Une API est-elle toujours obligatoire ?

Non pour les produits connectés en général. Les modalités doivent satisfaire les conditions applicables. Certains services cloud relèvent d’une obligation spécifique d’interfaces ouvertes.

Un format CSV est-il automatiquement conforme ?

Non. Il faut aussi vérifier le périmètre, la complétude, les métadonnées, la sécurité et les conditions de mise à disposition. Le nom du format ne prouve pas tout.

Peut-on imposer une authentification ?

Oui, l’accès doit être sécurisé. Les vérifications doivent rester nécessaires et proportionnées, sans demander des informations excessives ni neutraliser les droits.

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.