Capteurs, mesures environnementales, données de fonctionnement… Un objet connecté produit des informations tout au long de son utilisation. La façon dont elles sont collectées, stockées et transmises dépend largement des choix effectués lors du développement du produit.
Avec le Data Act européen, l’accès à ces données prend une place plus importante. Pour les entreprises qui développent des équipements IoT, des machines connectées ou des systèmes électroniques intelligents, cette question doit être anticipée dès la conception électronique du produit.
Data Act : que change le 12 septembre 2026 ?
Le Data Act s’applique dans l’Union européenne depuis le 12 septembre 2025. Une nouvelle obligation est entrée en application le 12 septembre 2026 pour les produits connectés et les services connexes mis sur le marché après cette date : ils doivent être conçus de manière à faciliter l’accès de l’utilisateur aux données couvertes par le règlement.
Ces données doivent pouvoir être mises à sa disposition de façon simple et sécurisée, sans frais pour l’exercice de son droit d’accès, dans un format complet, structuré, couramment utilisé et lisible par machine. Lorsque cela est pertinent et techniquement possible, l’accès doit pouvoir être direct depuis le produit.
Cette obligation concerne l’accès aux données. Elle ne signifie pas que tous les services associés doivent devenir gratuits : un fabricant peut continuer à proposer des fonctionnalités à valeur ajoutée, comme une plateforme de visualisation, des analyses ou des alertes.
Pourquoi la conception électronique est-elle directement concernée ?
Une donnée affichée dans une application suit d’abord une chaîne technique. Un capteur réalise une mesure ; l’électronique embarquée l’acquiert et la traite ; le produit la conserve, l’utilise localement ou la transmet à un autre système.
Les décisions prises à ce stade influencent donc les possibilités d’accès aux données. Quelle mémoire prévoir ? À quelle fréquence effectuer les mesures ? Faut-il les stocker dans l’équipement ou les envoyer vers un serveur ? Quelle technologie de communication convient à l’usage du produit ?
Les réponses ne seront pas les mêmes pour une machine industrielle alimentée en permanence et pour un capteur autonome qui doit fonctionner plusieurs années sur batterie. Une transmission fréquente, par exemple, peut faciliter la récupération des données, mais elle a aussi des conséquences sur la consommation énergétique et le choix des composants.
Le Data Act n’impose pas un protocole de communication particulier. Il conduit en revanche à réfléchir suffisamment tôt à la manière dont les données concernées pourront être récupérées et utilisées.
Quelles données d’un produit connecté faut-il prendre en compte ?
Selon l’équipement, les données concernées peuvent inclure des mesures de température, de pression, de débit, de position ou de vitesse, ainsi que certaines informations liées à son fonctionnement. Les métadonnées nécessaires pour comprendre et utiliser ces informations entrent également dans la réflexion.
Il faut toutefois distinguer ces données de celles qui résultent d’un traitement plus poussé, comme certaines informations enrichies, inférées ou dérivées, qui ne relèvent pas nécessairement des mêmes obligations.
Le Data Act n’oblige pas non plus un fabricant à collecter et à stocker toutes les données qu’un composant serait techniquement capable de produire. L’enjeu est d’identifier les données que l’architecture du produit prévoit effectivement de stocker ou de transmettre, puis de déterminer comment les rendre accessibles lorsque le règlement l’exige.
Cette distinction évite de surdimensionner inutilement le produit. Elle demande en revanche une vision claire des données dès les premières étapes du projet.
Cinq points à anticiper dans le cahier des charges
1. Définir les données utiles. Avant d’ajouter des capteurs, il faut préciser ce que le produit doit mesurer et dans quel but. Chaque donnée supplémentaire peut nécessiter de l’acquisition, du traitement, du stockage ou une transmission, avec un impact possible sur le coût et la consommation énergétique.
2. Prévoir leur stockage et leur durée de conservation. Une mesure peut être utilisée immédiatement puis supprimée, conservée temporairement dans l’équipement ou envoyée vers une infrastructure distante. Ces scénarios n’impliquent ni la même capacité mémoire ni la même architecture.
3. Organiser leur récupération. Une donnée présente dans un microcontrôleur n’est pas automatiquement exploitable par l’utilisateur. Liaison filaire, Bluetooth, Wi-Fi, réseau cellulaire ou passerelle : le moyen de communication doit être choisi selon les usages et les contraintes du produit.
4. Sécuriser l’accès. Rendre une donnée accessible ne revient pas à l’ouvrir à tout le monde. L’authentification, la gestion des droits et la protection des communications doivent être envisagées avec le hardware, le firmware et les services numériques associés.
5. Garder une capacité d’évolution. Un produit peut recevoir de nouvelles fonctionnalités ou des mises à jour après sa mise sur le marché. Une mémoire insuffisante ou une architecture de communication trop limitée peuvent compliquer ces évolutions.
Intégrer ces questions au cahier des charges d’un projet de conception électronique permet de prendre des décisions cohérentes avant le prototypage. À l’inverse, ajouter tardivement une interface de communication, augmenter le stockage ou changer de microcontrôleur peut imposer de revoir le schéma électronique, puis avoir des conséquences sur les tests, la certification et l’industrialisation.
Du capteur au service numérique : penser le produit dans son ensemble
Dans un objet connecté, l’électronique, le firmware, la communication et les services numériques sont liés. L’architecture doit répondre à la fonction physique du produit, mais aussi à ses besoins de sécurité, d’autonomie, de fiabilité et d’accès aux données.
Chez SYMES, nous accompagnons les projets électroniques depuis la définition du besoin et du cahier des charges jusqu’au prototypage et à l’industrialisation. Pour les produits connectés, cette approche permet d’intégrer tôt les questions de communication, de traitement et d’exploitation des données, afin de construire une solution adaptée aux usages du produit.
