EU Data Act : Ce que cela signifie pour les architectes IoT

L'EU Data Act (règlement (UE) 2023/2854) donne à l'utilisateur d'un produit connecté un droit légal sur les données que ce produit génère, ainsi que le droit de les partager, sur demande, avec un tiers de son choix. Pour un exploitant de flotte utilisant vos passerelles, cela signifie que les relevés, les compteurs d'heures de marche et les journaux d'événements issus de la machine lui appartiennent : il peut y accéder et les déplacer. Pour l'OEM ou l'intégrateur qui a construit le système, cela signifie que le chemin de données que vous avez conçu est désormais une surface de conformité, et plus seulement un sujet d'ingénierie.

Les obligations qui comptent pour les architectes sont concrètes : les données doivent être à la disposition de l'utilisateur, lorsque c'est techniquement possible, directement et en temps réel ; elles doivent pouvoir être partagées avec un tiers dans un format courant et lisible par machine ; et le passage à un nouveau fournisseur de service ne peut être bloqué ni par contrat ni par conception. Si votre seul moyen d'extraire un an de télémétrie CAN bus est un export CSV qu'un fournisseur exécute pour vous chaque trimestre, vous ne satisfaites pas cette exigence.

Le champ d'application est plus étroit que ne le laissent croire les titres, et bien le cerner vous évite de surconstruire. Le Data Act couvre les données générées par l'utilisation d'un produit connecté et de son service associé : relevés de capteurs, positions GPS, comptages de rotation de tambour, compteurs d'heures, codes de défaut, le flux de diagnostic qu'une machine émet en fonctionnement normal. Il ne livre pas vos algorithmes propriétaires, vos modèles d'enrichissement ni les données que vous dérivez en aval grâce à un investissement substantiel. Les données brutes et légèrement traitées de l'équipement sont incluses ; votre propriété intellectuelle analytique ne l'est pas.

L'utilisateur est celui qui possède, loue ou prend en crédit-bail le produit, pas nécessairement la partie qui l'a fabriqué. Sur une grue en location ou un camion malaxeur financé, l'exploitant qui fait tourner l'actif peut exiger l'accès même si l'OEM y a installé la télémétrie. Les architectes qui supposaient que le fabricant du boîtier contrôlait aussi les données issues du boîtier doivent revoir cette hypothèse, car le règlement ne la partage pas.

"À la disposition de l'utilisateur, lorsque c'est techniquement possible, directement et en temps réel" : c'est la ligne sur laquelle la télémétrie en stack fermé bute. Si les données de l'équipement n'arrivent que dans un cloud propriétaire et que l'utilisateur les voit via un portail contrôlé par le fournisseur, l'accès direct en temps réel est quelque chose qu'il faut demander, et c'est précisément cette demande que le Data Act rend inutile.

L'architecture qui satisfait cette exigence est celle vers laquelle une bonne ingénierie edge mène déjà. Terminez les protocoles sur une passerelle ouverte : J1939 sur la transmission, Modbus sur une pompe auxiliaire, OPC-UA sur un automate de ligne. Normalisez sur l'équipement et publiez via MQTT avec mise en tampon store-and-forward, afin qu'une liaison coupée ne fasse pas perdre de données. De là, le même flux peut se ramifier vers votre plateforme et vers un point de terminaison appartenant à l'utilisateur sans seconde intégration. L'accès en temps réel cesse d'être une requête au fournisseur et devient un abonnement à un topic que l'utilisateur détient déjà.

Les dispositions de changement de fournisseur du Data Act visent droit le lock-in. Un utilisateur peut migrer vers un autre fournisseur, et le fournisseur en place doit soutenir cette migration, dans un format structuré, courant et lisible par machine, sans frais punitifs et dans des délais de préavis définis. Le test pratique est simple : si votre client signait demain avec un concurrent, quelle part de ses données, de son historique et de sa configuration d'équipement pourrait-il emporter, et à quelle vitesse ?

Concevez pour cette réponse dès le départ. Conservez la télémétrie dans un stockage de séries temporelles ouvert (PostgreSQL avec TimescaleDB plutôt qu'une table cloud fermée que vous ne pouvez pas exporter à grande échelle). Définissez explicitement le format d'échange : du JSON horodaté ou un schéma documenté sur MQTT, pas un binaire opaque que seul votre décodeur comprend. Versionnez la configuration des équipements dans git, pour que le comportement d'une passerelle soit reproductible par quiconque détient le dépôt. Rien de tout cela n'est exotique. C'est la différence entre la portabilité comme clause que vous respectez et une migration que vous pouvez réellement mener.

Les équipes qui dépenseront le moins pour le Data Act sont celles dont les systèmes étaient déjà ouverts. Quand la passerelle exécute un Linux que vous contrôlez, que le broker est Mosquitto, que le stockage vous appartient et que le code source est versionné dans git et remis, l'essentiel des exigences du règlement est déjà satisfait comme effet secondaire de la manière dont le système a été bâti. L'accès, la portabilité et une sortie propre ne sont pas des ajouts a posteriori : c'est ce qu'un stack edge ouvert fait par défaut.

Les plateformes fermées inversent cela. Chaque droit que le Data Act accorde à l'utilisateur devient une demande de fonctionnalité adressée à un fournisseur qui a un intérêt commercial à la ralentir, souvent facturée par équipement ou par export. Le règlement constitue, de fait, une échéance sur une décision que beaucoup d'architectes différaient : la couche de données de terrain est-elle quelque chose que vous possédez ou quelque chose que vous louez ? Concevoir dès maintenant pour l'accès utilisateur et la portabilité coûte moins cher que d'y être contraint plus tard sur un stack propriétaire, et cela vous laisse une architecture qui est meilleure pour ses propres mérites.