CRA et objets connectés : sécurité, classement, support
CRA et IoT : délimitez le produit, classez ses fonctions et préparez les mises à jour. Une méthode pour les fabricants d’objets connectés.
- Délimiter le produit avant de le classer
- Sécurité de l’objet : partir de scénarios d’usage
- Une classe ne se déduit pas du mot « industriel »
- Prévoir une assistance réaliste
- Organiser les vulnérabilités avant l’incident
- Préparer un lancement vérifiable
- Relier chaque fonction aux éléments qui la rendent possible
- Arbitrer les contraintes matérielles avant la fabrication
- Cas fictif : préparer la réception d’un équipement
- Prévoir les changements pendant la vie du produit
- Ce qu’il faut retenir
- FAQ
Un objet connecté associe souvent matériel, micrologiciel, application et fonctions distantes. Pour préparer sa conformité CRA, le fabricant doit comprendre ce système et prévoir sa sécurité après la vente. Un composant limité en mémoire ou une dépendance cloud ne dispense pas d’analyser le risque : ces contraintes doivent être traitées dès la conception.
Délimiter le produit avant de le classer
L’Art. 2(1) et les définitions de l’article 3 du règlement (UE) 2024/2847 couvrent les produits concernés par une connexion prévue ou raisonnablement prévisible, directe ou indirecte, logique ou physique, à un dispositif ou réseau.
Pour chaque référence, décrivez le matériel, le logiciel embarqué, les applications fournies et les fonctions dépendantes d’un traitement distant. L’Art. 3(2) vise le logiciel distant conçu par le fabricant ou sous sa responsabilité, dont l’absence empêcherait l’une des fonctions du produit. Il faut aussi examiner les exclusions, notamment les produits relevant des règlements sur les dispositifs médicaux.
Le guide du champ CRA permet de qualifier ensuite fabricant, importateur et distributeur. Une entreprise qui commercialise sous sa marque ne peut se limiter à demander au fournisseur du micrologiciel s’il est « conforme ».
Sécurité de l’objet : partir de scénarios d’usage
L’annexe I, partie I, pose une sécurité proportionnée aux risques et détaille les exigences applicables sur la base de l’évaluation. Voici une traduction opérationnelle proposée pour un projet IoT :
| Situation à examiner | Question de conception | Preuve utile |
|---|---|---|
| Première installation | Qui peut prendre le contrôle et avec quels paramètres ? | Parcours d’activation et vérification des accès |
| Fonctionnement normal | Quelles interfaces et données sont nécessaires ? | Cartographie des flux et justification des interfaces |
| Mise à jour | Comment éviter une modification non autorisée ? | Mécanisme de distribution et contrôles d’intégrité |
| Perte de connexion ou panne | Quelles fonctions doivent rester disponibles ou sûres ? | Analyse des conséquences et résultats de vérification |
| Revente ou fin d’utilisation | Comment supprimer données et paramètres ? | Instructions et vérification de la remise à zéro |
Le CRA ne prescrit pas universellement un protocole nommé TLS 1.3, un composant cryptographique donné ou une architecture unique. Il faut choisir les mesures adaptées et démontrer leur efficacité. Une limitation matérielle connue doit être intégrée à l’arbitrage produit, sans promesse technique impossible à tenir.
Une classe ne se déduit pas du mot « industriel »
L’annexe III classe notamment les routeurs et systèmes d’exploitation en classe I, les pare-feu et certains systèmes de virtualisation en classe II. Certains produits domestiques de sécurité, jouets avec fonctionnalités précises et produits portables sont également visés.
Il n’existe pas de règle générale plaçant tout capteur industriel, toute passerelle IoT ou tout routeur professionnel en classe II. De même, tout objet connecté destiné à une infrastructure sensible n’est pas automatiquement un produit critique de l’annexe IV.
Le règlement d’exécution (UE) 2025/2392 précise les descriptions techniques et le rôle de la fonctionnalité de base. Utilisez le guide de classification CRA pour documenter la décision avant de choisir une procédure d’évaluation.
Prévoir une assistance réaliste
L’Art. 13(8) exige une période d’assistance reflétant la durée d’utilisation prévue. Le plancher est de cinq ans, sauf si cette utilisation est prévue pour moins de cinq ans. Une durée attendue supérieure demande une justification cohérente ; cinq ans ne constituent pas un plafond automatique.
Pour un équipement installé durablement, examinez les composants tiers, l’accès physique, les mécanismes de mise à jour et la continuité des équipes. La politique de support CRA doit aussi distinguer nouveaux correctifs, disponibilité des correctifs déjà diffusés et conservation du dossier.
Organiser les vulnérabilités avant l’incident
Identifiez les composants et versions réellement livrés, leurs fournisseurs et les moyens de joindre les utilisateurs. L’annexe I, partie II demande notamment une nomenclature logicielle, des examens réguliers efficaces, une correction sans retard et une distribution sécurisée.
La gratuité des correctifs disponibles comporte une exception précise pour certains produits sur mesure destinés à des utilisateurs professionnels ; elle ne disparaît pas pour toute vente B2B. La séparation des mises à jour de sécurité et de fonctionnalité est exigée lorsqu’elle est techniquement possible.
Le processus de gestion des vulnérabilités CRA doit couvrir les versions en assistance. Les signalements de l’article 14 sont déjà applicables depuis le 11 septembre 2026 ; ils ne doivent pas attendre l’application générale du 11 décembre 2027.
Préparer un lancement vérifiable
Constituez un dossier par produit ou famille justifiée : périmètre, classification, risques, preuves des mesures, modalités d’assistance et documents remis à l’utilisateur. Avant lancement, confrontez ce dossier à un exemplaire ou une version réellement livrée.
La documentation technique CRA doit refléter ces décisions. Un audit isolé, une déclaration du fournisseur ou une liste de bonnes pratiques sans preuve ne suffit pas à démontrer l’ensemble des exigences.
Relier chaque fonction aux éléments qui la rendent possible
Pour un objet connecté, une simple liste de composants ne montre pas toutes les dépendances. Décrivez les fonctions promises à l’utilisateur, puis les éléments nécessaires à chacune : capteur, micrologiciel, application, compte, service distant ou intervention d’un installateur. Notez ce qui continue à fonctionner lorsque l’un de ces éléments devient indisponible.
Cette représentation sert à deux analyses distinctes. La première qualifie le produit et les traitements distants au regard du texte. La seconde évalue les conséquences d’une défaillance ou d’un accès indu. Un élément peut nécessiter une attention opérationnelle sans que sa présence suffise à déterminer la catégorie juridique du produit.
Pour les fonctions distantes, retrouvez qui a conçu et développé le logiciel, sous quelle responsabilité et pour quel usage. Un contrat d’hébergement et un contrat de développement ne décrivent pas la même intervention. Conservez la justification de la qualification, surtout lorsqu’une fonction évolue après la commercialisation. Le nom commercial « cloud » ne remplace pas cette lecture des faits.
Arbitrer les contraintes matérielles avant la fabrication
La capacité de mettre à jour dépend de choix qui deviennent coûteux à modifier après la livraison. Examinez l’espace disponible, les conditions d’alimentation, les interruptions possibles et la manière de retrouver un état utilisable après un échec. Décrivez le comportement attendu et les éléments qui permettront de le vérifier. Le CRA fixe des exigences de résultat adaptées au risque ; il ne transforme pas cette liste de questions en architecture obligatoire.
La même analyse vaut pour les accès de maintenance. Qui peut intervenir, avec quel moyen d’authentification et pendant combien de temps ? Un accès prévu pour l’installateur peut devenir inutile après la mise en service. Organisez son retrait ou son encadrement selon le besoin réel, et vérifiez que les instructions correspondent aux possibilités du produit.
Les choix doivent aussi tenir compte des utilisateurs. Une mise à jour exigeant une opération physique difficile, une connexion rare ou l’intervention exclusive d’un technicien demande une organisation cohérente. La documentation ne doit pas annoncer un mécanisme automatique si l’installation dépend en réalité d’une action qui n’est jamais expliquée.
Cas fictif : préparer la réception d’un équipement
Le fabricant fictif Ajonc prépare un capteur destiné à surveiller la température d’un local. Le produit enregistre une mesure, transmet une alerte et propose une consultation à distance. Il comprend un micrologiciel et une application ; les responsabilités de développement du service distant restent à confirmer dans le dossier.
La fiche de réception proposée pourrait être organisée ainsi :
| Point à examiner | Élément attendu pour décider |
|---|---|
| Qualification du produit | Description des fonctions et analyse des dépendances distantes |
| Installation | Identification de l’utilisateur habilité et sort de l’accès installateur |
| Rupture de connexion | Comportement expliqué de la mesure, de l’alerte et de la consultation |
| Mise à jour interrompue | Conditions de reprise et résultat de la vérification prévue |
| Changement de propriétaire | Sort des données, paramètres et droits de l’ancien utilisateur |
| Assistance | Durée motivée, composants suivis et responsable des corrections |
Aucun résultat d’essai ni classement CRA n’est supposé dans cet exemple. La présence d’un composant réseau ne transforme pas automatiquement le capteur en routeur. Il faut décrire sa fonctionnalité de base et la confronter aux catégories applicables. De même, l’inconnue contractuelle sur le service distant doit rester visible jusqu’à sa résolution.
Prévoir les changements pendant la vie du produit
Une version livrée doit pouvoir être rapprochée des composants utilisés et des décisions qui la concernent. Si deux séries matérielles emploient des composants différents, vérifiez quelles conséquences cette différence a pour les vulnérabilités, les correctifs et les instructions. Un nom de gamme identique ne démontre pas une configuration identique.
Préparez le circuit de décision lorsqu’un fournisseur cesse le support d’un composant. Il faut examiner les versions concernées, les solutions disponibles et les conséquences sur l’assistance promise. Une fin de support tierce ne permet pas de considérer automatiquement toutes les obligations du fabricant comme terminées. Les contraintes connues doivent alimenter le choix des composants et la justification de la période d’assistance.
Lorsqu’une nouvelle fonction est envisagée, vérifiez également si elle modifie les accès, les données, les dépendances ou les risques. Conservez le lien entre l’analyse mise à jour, la décision de livraison et les éléments remis aux utilisateurs. Le simple numéro de version ne résout pas la qualification d’une modification ni ses conséquences réglementaires.
Enfin, organisez le changement d’utilisateur et la fin d’utilisation. Les possibilités de suppression et de transfert sécurisé prévues par l’annexe I doivent être examinées dans le contexte du produit. Expliquez ce qui concerne l’objet, l’application et les services associés, sans promettre qu’une réinitialisation locale efface nécessairement toutes les copies distantes. Cette préparation rend la réception et le suivi du produit vérifiables ; elle ne décrit aucun contrôle effectivement exécuté.
Ce qu’il faut retenir
- Délimitez l’ensemble matériel, logiciel et fonctions distantes du produit.
- Choisissez les mesures selon les risques et les contraintes réelles.
- L’usage industriel ne détermine pas automatiquement la classe CRA.
- Prévoyez assistance, mises à jour et communication dès la conception.
FAQ
Un objet qui n’accède pas directement à internet peut-il être couvert ?
Oui. Le règlement vise aussi les connexions indirectes à un dispositif ou réseau. Il faut analyser l’usage prévu et raisonnablement prévisible.
Tous les objets de santé relèvent-ils du CRA ?
Non. Les produits relevant des règlements 2017/745 ou 2017/746 font notamment l’objet d’une exclusion. La qualification réglementaire du produit doit précéder le classement CRA.
Un capteur industriel est-il toujours de classe II ?
Non. La classe dépend de la fonctionnalité de base et des catégories définies par les textes. L’environnement industriel influence l’analyse des risques sans créer à lui seul cette classification.
Recevez nos analyses conformité dans la newsletter.
Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la conformité numérique.