Robots industriels et cobots : produits importants du CRA ?
Résumé
Ce guide suit une version fictive d'un cobot, de la classification jusqu'à la délimitation du périmètre produit, en passant par l'évaluation des risques, le SBOM, la signature de version, le signalement des vulnérabilités et le transfert entre opérateurs économiques. La même structure s'applique à un bras à 6 axes, à une cellule collaborative ou à un contrôleur de robot vendu avec vision optionnelle et services de cloud de flotte.
- La voie standard est le point de départ. Les robots industriels et cobots ne figurent pas aujourd'hui dans les listes CRA des produits importants ou critiques. Traitez comme une classification à part toute offre dans laquelle des fonctions de pare-feu, de gestion de réseau ou de contrôleur résistant aux altérations dominent.
- Commencez par la note de périmètre. Nommez la variante exacte : bras, armoire de commande, console de programmation, options de bus de terrain, environnement d'exécution, connecteur de flotte ou cloud, utilisation prévue, éléments numériques fournis, période d'assistance et raison de la voie choisie.
- Cybersécurité et sécurité des machines se recoupent dès 2027. ISO 10218-1:2025 ajoute des exigences de cybersécurité lorsqu'elles touchent à la sécurité du robot, et le règlement Machines s'applique à partir du 20 janvier 2027. Le dossier CRA et le dossier de sécurité partagent des preuves sur ces points.
- L'assistance a besoin d'une date crédible. La période d'assistance est d'au moins cinq ans, sauf si la durée d'utilisation prévue est inférieure. Beaucoup de robots fonctionnent bien plus longtemps en usine, donc le dossier doit nommer une fenêtre que le fabricant peut tenir et communiquer la date de fin d'assistance avant l'achat.
- La gestion des vulnérabilités est un modèle opérationnel. Le dossier doit nommer qui reçoit les alertes, qui approuve les fenêtres de maintenance, qui peut effectuer un retour arrière sur une mise à jour et comment les avertissements résiduels restent visibles.
- Le transfert est aussi une preuve. Le fabricant conserve le dossier du produit ; l'intégrateur conserve le dossier de la cellule finale lorsqu'elle sort sous son nom ; l'opérateur exploite la cellule. Chaque transfert est documenté, pas poussé de façon informelle vers le client.
Comment classer une version de robot industriel ou cobot ?
Commencez par l'offre, pas par le bras. Un bras à 6 axes vendu à un intégrateur et le même bras vendu comme cellule cobot complète à un petit atelier sont deux produits CRA distincts. La voie dépend de ce que le client achète, du contrôleur et de la console de programmation livrés, et de savoir si le fabricant fournit aussi le cloud de flotte, la configuration de sécurité et la voie de mise à jour OTA.
La figure fixe la voie. La matrice fixe la note de périmètre : une fois la variante choisie, voici les lignes de preuves que le fabricant devrait pouvoir remplir pour cette variante précise.
Vente comme composant ; l'intégrateur construit la cellule.
Bras, contrôleur, console de programmation, environnement d'exécution, options de bus de terrain, mises à jour signées, processus de gestion des vulnérabilités et manuel destiné à l'intégrateur.
Autorité d'écriture de la station d'ingénierie, emplacement de récupération, exposition du bus de terrain, suivi des avis fournisseurs et rotation des identifiants au retrait de la cellule.
Bras collaboratif à force limitée, configuration prête à l'emploi, vision optionnelle et cloud de flotte.
Bras, contrôleur, console de programmation, configuration de sécurité, capteur de vision, environnement d'exécution, connecteur de cloud de flotte et service OTA.
Mode collaboratif, rôle de l'opérateur dans l'espace partagé, autorité du cloud de flotte, comptes de la console et voie de firmware de sécurité signé.
Revente au sein d'une ligne d'emballage ou d'une machine de procédé sous le marquage CE de l'intégrateur.
Le fabricant du robot conserve dans son dossier le bras, le contrôleur, la console de programmation et le logiciel fourni. La machine finale dispose de son propre dossier sous le marquage CE de l'intégrateur.
Avis fournisseurs sur RT OS, bus de terrain et vision ; cohérence des déclarations de conformité du fournisseur ; exposition pendant l'intégration ; articulation de l'assistance avec le fabricant de la machine.
Qu'est-ce qui entre dans le périmètre du produit robot ?
Pour un robot ou un cobot, le périmètre ne coïncide pas toujours avec la barrière de la cellule. Il coïncide avec ce que le fabricant fournit et maintient : bras, armoire de commande, firmware, environnement d'exécution, console de programmation, mises à jour signées, connecteur cloud et documentation utilisateur. Ce que le client ou l'intégrateur apporte reste par défaut hors périmètre, sauf si le fabricant le livre dans le cadre de l'offre.
Quelle voie d'évaluation de la conformité s'applique ?
Les robots industriels et cobots ne figurent pas aujourd'hui dans les listes CRA des produits importants ou critiques, donc la voie standard est l'hypothèse de planification. Le fabricant peut choisir le contrôle interne, l'examen UE de type suivi de la conformité au type, l'assurance qualité complète ou un schéma européen de certification de cybersécurité applicable. Le choix ne dépend pas de l'application de normes harmonisées.
La condition de « normes pleinement appliquées » relève de la voie de repli pour les produits importants, pas de la voie par défaut. Si une mise à jour future ajoutait un sous-produit de robot ou cobot à cette liste et que les normes ou schémas disponibles ne couvraient pas les exigences essentielles concernées, le fabricant aurait besoin d'une voie d'évaluation par tierce partie pour la partie non couverte. La liste n'inclut pas les robots aujourd'hui.
Le règlement Machines 2023/1230 s'applique à partir du 20 janvier 2027 et inclut des exigences de sécurité qui se recoupent avec les preuves cyber, en particulier la protection contre la corruption et la fiabilité des systèmes de commande. Traitez le dossier CRA et le dossier de sécurité de la machine comme deux fils d'un même classeur produit.
Quels contrôles d'architecture appartiennent au dossier du robot ?
Le dossier doit expliquer comment le fabricant maîtrise les points où une commande numérique peut changer le mouvement, la configuration de sécurité ou l'état de mise à jour.
| Point d'architecture | Ce qui est vérifié | Preuve minimale |
|---|---|---|
| Contrôleur et CPU de mouvement | Qui peut écrire la logique, les paramètres et le firmware | Modèle d'autorité, signature de firmware, journal des modifications |
| Console de programmation | Quels rôles peuvent déplacer le robot, charger un programme ou changer de mode | Matrice de rôles, preuve d'identifiants, audit de session |
| Bus de terrain | Quel trafic peut affecter le cycle de mouvement | Liste de protocoles, règles de segmentation, test de trames anormales |
| Cloud de flotte | Quelle autorité distante existe sur les mises à jour et la télémétrie | Carte des points de connexion, certificats, fenêtre de maintenance, retour arrière |
| Service local | Comment USB, récupération et tunnels temporaires sont maîtrisés | Mode service, journal d'intervention, test de fermeture automatique |
Comment construire l'évaluation des risques du robot ?
Quel produit évaluons-nous ?
L'exemple utilise une cellule cobot complète vendue à une PME : bras à force limitée, contrôleur, console de programmation, configuration de sécurité préparée, vision optionnelle, connecteur de cloud de flotte, mises à jour signées et documentation utilisateur. Il n'évalue pas une ligne complète d'usine ni une cellule conçue par un intégrateur, sauf aux points de transfert.
| Décision de périmètre | Choix de l'exemple | Pourquoi cela importe |
|---|---|---|
| Variante | Cellule cobot complète | Le fabricant conserve le dossier produit complet |
| Périmètre numérique | Contrôleur, console, firmware, vision, cloud, OTA | C'est ce qui peut changer le mouvement, la configuration ou la disponibilité |
| Client | PME exploitante | Moins d'équipe sécurité interne, plus de dépendance au fabricant |
| Intégrateur | Peut installer, mais ne réétiquette pas le produit | Le transfert existe, mais ne déplace pas automatiquement le dossier |
Avant d'écrire le tableau de menaces, testez les trois voies qui décident souvent du risque du robot : chargement de programme et autorité de la console, frontière entre sécurité fonctionnelle et cybersécurité, et transfert à l'intégrateur. La figure transforme l'exemple en questions d'ingénierie, pas en liste générique de menaces.
Comment la surface d'attaque change-t-elle entre un robot enclos et un cobot ?
| Surface | Robot industriel enclos | Cobot à force limitée |
|---|---|---|
| Proximité humaine | Exclue par barrière, rideau ou verrouillage | Continue ; la surveillance de force, vitesse ou séparation fait partie du dossier de sécurité |
| Accès à la console | Normalement à l'intérieur de la cellule verrouillée | Espace partagé, souvent avec rôle actif de l'opérateur |
| Entrée de vision | Optionnelle et localisée | Fréquente, parfois centrale pour la sécurité et l'exploitation |
| Téléopération | Moins fréquente | De plus en plus fréquente sur certaines gammes |
| Acteur le plus probable | Service, ingénierie ou intégrateur | Opérateur, station distante ou mauvais usage de rôle partagé |
Quels actifs protéger ?
| Actif | Pourquoi cela importe | Exemple de preuve |
|---|---|---|
| Autorité de mouvement | Change la trajectoire, la vitesse ou le mode | Matrice de rôles, preuve de session, verrouillage de mode |
| Firmware de sécurité | Affecte arrêt, vitesse, séparation et verrouillages | Signature, revue conjointe sécurité fonctionnelle/cyber |
| Programmes de robot | Peuvent introduire des mouvements non sûrs ou des interruptions | Validation par l'analyseur, contrôle d'origine, journal de chargement |
| Identifiants de la console | Permettent des changements locaux en production | Rotation initiale, expiration, audit opérateur |
| Connecteur cloud | Peut distribuer avis, mises à jour ou tunnels | Certificats, liste de points de connexion, test de retour arrière |
| Composants logiciels | RT OS, vision, bus de terrain et bibliothèques ont des vulnérabilités | SBOM, suivi d'avis, décision de correctif |
Où se situent les principales frontières de confiance ?
| Frontière | Recoupement | Question de risque |
|---|---|---|
| Fabricant vers intégrateur | Manuel, paquet importateur, configuration de sécurité et avis | Que livre-t-on et qu'est-ce qui reste hors périmètre ? |
| Intégrateur vers opérateur | Cellule installée, rôles, fenêtres de maintenance | Qui peut changer le mouvement après la livraison ? |
| Station d'ingénierie vers contrôleur | Projet, programme, firmware, paramètres | Quelle preuve empêche une écriture hors session ? |
| Cloud vers flotte | Avis, mises à jour, certificats, tunnels | Quelle autorité distante existe et comment la révoque-t-on ? |
| Fournisseur vers fabricant | Composants, bibliothèques, firmware tiers | Comment détecte-t-on un avis qui affecte le robot ? |
Quelles menaces évaluer en premier ?
| ID | Menace | Actif affecté | Frontière |
|---|---|---|---|
| R1 | Un compte usine ou intégrateur reste actif après la livraison | Autorité de mouvement | Intégrateur vers opérateur |
| R2 | Un paquet de firmware ancien est accepté pendant la récupération | Intégrité de firmware | Service local |
| R3 | Le cloud de flotte ouvre un tunnel hors fenêtre de maintenance | Autorité distante | Cloud vers flotte |
| R4 | Un projet manipulé change la logique de vitesse ou séparation | Sécurité collaborative | Station d'ingénierie |
| R5 | Un certificat expiré bloque avis ou mises à jour | Disponibilité | Cloud |
| R6 | L'opérateur ne reçoit pas une alerte de vulnérabilité à temps | Gestion des vulnérabilités | Fabricant vers opérateur |
| R7 | Un fournisseur publie un avis affectant le RT OS ou la vision et il n'est pas détecté | Composants | Fournisseur vers fabricant |
| R8 | Une trame de bus de terrain provoque une panne du CPU de mouvement ou une surcharge de cycle | Disponibilité de mouvement | Bus de terrain |
| R9 | Une image USB de récupération est appliquée sans audit | Intégrité de firmware | Support de service |
| R10 | Un paquet de diagnostic expose noms de programme, certificats ou réseau | Données de service | Portail de support |
| R11 | Une vulnérabilité dans RT OS, bus de terrain ou vision n'est pas détectée pendant l'assistance | Composants de firmware | Avis fournisseurs |
| R12 | Un transfert de client laisse active la station d'ingénierie précédente | Identifiants | Mise hors service |
| R13 | L'analyseur de l'environnement d'exécution échoue ou exécute du contenu non sûr depuis un projet malformé | Intégrité des outils | Import de projet |
| R14 | L'intégrateur combine le bras avec un automate de sécurité tiers sans preuves en vigueur | Conformité fournisseur | Transfert de cellule |
Comment hiérarchiser les risques initiaux ?
Utilisez une échelle de décision. Tous les risques ne nécessitent pas la même réponse.
| Résultat résiduel | Pourquoi il subsiste | Preuve opérationnelle |
|---|---|---|
| Correctif long terme | Un composant fournisseur n'a pas encore de correctif | Avis composant, atténuation temporaire, date de revue |
| Changement côté client | L'opérateur veut intégrer sa propre station | Note de périmètre, note de portée, instruction de support |
| Calendrier du correctif | L'usine a besoin d'une fenêtre et de validation | Avis avec impact machine, atténuation, retour arrière |
| Accès physique de service | Armoires, consoles et stations sont accessibles en maintenance | Restrictions du mode service, échantillon d'audit, verrouillage du débogage |
Quels contrôles de conception changent le risque ?
| Contrôle | Ce qu'il réduit | Preuve |
|---|---|---|
| Firmware signé avec rejet de version antérieure | Paquets anciens ou manipulés | Journal de test de mise à jour, empreinte, résultat de rejet |
| Identifiants par appareil et rotation initiale | Comptes usine partagés | Journal d'approvisionnement, preuve de premier démarrage |
| Rôles séparés pour opérateur, maintenance et ingénierie | Changements de mouvement hors rôle | Matrice d'autorisation et audit |
| Fenêtres de maintenance pour cloud et tunnels | Autorité distante ouverte | Journal de fenêtre, fermeture automatique, retour arrière |
| SBOM et suivi fournisseur | Avis qui n'atteignent pas l'équipe | SBOM, sources d'avis, décision de classification |
Quel risque résiduel subsiste après les contrôles ?
Après application des contrôles, le fabricant doit nommer ce qui subsiste et pourquoi. Dans cet exemple, le risque de vulnérabilité fournisseur persiste parce que le robot dépend de RT OS, vision et bus de terrain tiers. Le risque n'est pas accepté dans l'abstrait : il est lié au suivi d'avis, à la signature de paquets, aux fenêtres de maintenance, à la communication avec les intégrateurs et aux tests correctifs. L'atténuation documentée doit montrer que le processus existe avant le démarrage de la production.
Comment doivent circuler les avis du cloud de flotte ?
L'évaluation précédente vit dans une armoire de robot. Le routage des avis vit dans des centaines de robots. Lorsque le cloud de flotte du fabricant dessert plusieurs intégrateurs et usines, la question n'est pas seulement de savoir si le cloud est sûr. La question est qui reçoit une alerte de vulnérabilité en 24 h et qui approuve la fenêtre de mise à jour de chaque site.
| Topologie de flotte | Qui se trouve entre le fabricant et l'utilisateur final | Ce qui change dans le dossier |
|---|---|---|
| Exploitant mono-site, direct depuis le fabricant | Fabricant → exploitant | L'avis atteint l'équipe de maintenance de l'exploitant ; un canal peut suffire |
| Exploitant multi-sites avec ingénierie centrale | Fabricant → ingénierie centrale → usines | Le dossier doit consigner le contact central pour que l'avis ne se perde pas dans une boîte locale |
| Flotte gérée par OEM | Fabricant → opérations OEM → exploitants finaux | L'OEM relaie les avis à impact machine, mais le fabricant a besoin d'une voie vers les utilisateurs concernés |
| Flotte gérée par intégrateur | Fabricant → intégrateur → PME utilisatrices | L'avis du fabricant alimente le processus propre de l'intégrateur lorsque celui-ci vend sous sa marque |
| Flotte de flottes | Cloud du fabricant ↔ cloud OEM ↔ cloud d'intégrateur ↔ exploitant | Documentez quelle chaîne est contractuelle et laquelle couvre la notification réglementaire et les utilisateurs |
Trace de version. Une carte de routage du cloud de flotte doit nommer, pour chaque intégrateur et exploitant de la liste, le contact d'alerte 24 h, le responsable de la fenêtre de maintenance, l'autorité de retour arrière et les avis résiduels ouverts.
Quelles barrières de validation se ferment avant la publication ?
Évitez une barrière générique de « sécurité revue ». Utilisez un inventaire de barrières avec mode de défaillance, contrôle et preuve pour chaque décision susceptible de bloquer l'expédition.
| Barrière | Défaillance qui bloque | Preuve |
|---|---|---|
| Verrouillage de la variante | Ce qui est vendu n'est pas clair | Note de périmètre et voie |
| Autorité de mouvement | Un mauvais rôle peut changer la trajectoire ou le mode | Test négatif et audit |
| Firmware de sécurité | La mise à jour altère la logique de sécurité sans revue | Revue conjointe et test signé |
| Bus de terrain | Des trames anormales affectent le cycle ou la disponibilité | Test de bus et segmentation |
| Cloud et OTA | Le cloud conserve une autorité indéfinie | Fenêtre, certificats, retour arrière |
| Documentation | Contact, assistance ou instructions manquants | Index du dossier et paquet importateur |
Qui prend en charge le développement du robot du concept à l'assistance ?
Utilisez un couloir de responsabilité. Chaque phase a un responsable principal, un registre tenu à jour et une barrière de revue. La version n'est pas clôturée tant que chaque phase ne laisse pas de trace.
Quels enregistrements de preuves figurent dans le dossier ?
La liste suivante est une vue auditée. Elle fige l'identité du produit, les contrôles de sécurité et les obligations après-vente. Chaque ligne doit pointer vers un registre tenu à jour, pas vers un dossier de captures éparses.
| Enregistrement de preuves | Ce qu'il capture pour un robot industriel ou cobot |
|---|---|
| Identité du produit | Modèle de bras, charge utile, portée, armoire de commande, console de programmation, branche de firmware, environnement d'exécution, capteur de vision, options de bus, assistance matériel |
| Utilisation prévue | Fonctionnement collaboratif ou enclos, charge utile, application, mode opérateur, modèle d'usage et variante |
| Dossier de cyber-résilience | Voie de classification, périmètres, liste de menaces, contrôles de confiance et décisions résiduelles |
| Inventaire des composants | CPU de mouvement, RT OS, pile de bus de terrain, pile esclave EtherCAT, firmware de sécurité, environnement d'exécution, bibliothèques, module de vision |
| Configuration sécurisée par défaut | Pas de secret partagé, comptes uniques, blocage de version antérieure, OPC UA sécurisé par défaut, service après mise en service |
| Mécanisme de mise à jour | Firmware signé, retour arrière, carte d'impact machine, contact client et preuves cloud |
| Gestion des vulnérabilités | Politique de divulgation, contact unique, flux de classification, suivi des avis composants et intégrateurs |
| Instructions utilisateur | Mise en service sûre, gestion des rôles, retrait, fenêtres de mise à jour, limites de service |
| Traçabilité et contact | Type, lot ou série, données du fabricant, date de fin d'assistance et contact pour les vulnérabilités |
Qu'est-ce qui entre dans un SBOM de robot ?
Le CRA exige un SBOM lisible par machine qui identifie les composants et couvre au moins les dépendances de premier niveau, mais ne fixe pas encore un format unique. En attendant que la Commission précise davantage, les fabricants choisissent souvent CycloneDX ou SPDX. Les indications transversales se trouvent dans le guide SBOM ; cette section couvre l'arbre propre au robot.
Une version de robot livre généralement plusieurs éléments numériques avec des cycles de mise à jour séparés, pas un binaire unique. Deux modèles répondent au minimum : un SBOM produit avec sections par élément, ou un SBOM par élément numérique fourni mis à jour à chaque version. L'un ou l'autre convient si le SBOM est lisible par machine et couvre les dépendances de premier niveau.
Trace SBOM : un SBOM lisible par machine en CycloneDX ou SPDX qui couvre au moins les dépendances de premier niveau. Pour les robots, c'est généralement un SBOM produit avec sections par élément, ou un SBOM par élément numérique fourni. Les dépendances transitives plus profondes sont recommandées lorsque le système de compilation peut les produire.
Que vérifie la signature de version ?
Avant que le robot ne soit mis sur le marché de l'UE, la signature doit clôturer les quatre mêmes enregistrements des questions Q1 à Q4. L'inventaire ne vit pas dans les preuves abstraites ci-dessus. Ce tableau ne concerne que les quatre décisions qui bloquent la version.
Signature de version : quatre enregistrements qui bloquent la sortie
- Q1 Note de classification. Pourquoi le produit est classé ainsi : utilisation prévue, contexte de vente, éléments numériques livrés et voie standard choisie.
- Q2 Inventaire des éléments livrés. Ce qui est exactement expédié : bras, contrôleur, console de programmation, vision, firmware, cloud, bibliothèques, manuels et variantes.
- Q3 Paquet de test sécurisé par défaut. Identifiants par appareil, profil OPC UA, rejet de version antérieure, verrouillage du débogage et mode service.
- Q4 Processus de gestion des vulnérabilités. Contact public, politique de divulgation, classification, suivi des composants, intégrateurs et préparation aux notifications.
Vérifications préalables : les quatre enregistrements doivent être trouvables en moins d'une minute ; les dossiers doivent être liés à la branche de firmware et à la ligne de base fournisseurs ; un responsable nommé doit exister pour les alertes 24 h et 72 h.
Barrière de signature : si un enregistrement manque, la version n'est pas signée.
Trace de déclaration : utilisez le guide principal de déclaration UE de conformité pour le modèle et les champs requis. Dans une version de robot, l'identité du produit doit fixer bras, armoire de commande, console de programmation, branche de firmware, options fournies et référence à la période d'assistance. Si la même déclaration couvre aussi la législation Machines, nommez cette voie et maintenez le dossier technique du robot et le dossier de sécurité de la machine alignés.
Comment transférer le robot à l'importateur, au distributeur, à l'intégrateur et à l'opérateur ?
Le dossier doit rendre vérifiable le transfert du fabricant à l'importateur, au distributeur, à l'intégrateur en tant que fabricant de machine et à l'utilisateur final. Sur les robots et cobots, le point faible n'est généralement pas seulement le marquage CE. C'est plutôt de savoir si l'expédition, le manuel, le cloud de flotte, le service OTA et le transfert à l'intégrateur correspondent toujours à la version évaluée.
Transfert d'opérateurs économiques : rôles, vérifications et régimes connexes
- 01 Fabricant. Maintient le paquet de version : déclaration, marquage CE, index du dossier, fenêtre d'assistance et contact pour les vulnérabilités.
- 02 Importateur. Vérifie le paquet, le marquage CE, l'index, la date d'assistance et le contact. Suspend l'expédition en cas de doute sur la traçabilité, les identifiants, le compte cloud ou le canal de mise à jour.
- 03 Distributeur. Revoit le marquage CE visible, les documents fournis, la traçabilité de l'exploitant, l'assistance et les affirmations de mise à jour. Suspend la vente si l'annonce masque les opérateurs, exagère l'assistance ou contredit la déclaration.
- 04 Intégrateur. Combine le bras avec la sécurité, la vision et la logique de la cellule. Si la cellule sort sous son nom, l'intégrateur devient fabricant de la cellule.
- 05 Exploitant. Reçoit les avis, applique les mises à jour dans les fenêtres de maintenance et signale les problèmes. Il n'est pas fabricant.
Vérification A : mandataire et notification hors UE. Le mandat du mandataire est optionnel. Les fabricants sans établissement principal dans l'Union utilisent la cascade du point de notification pour choisir le CSIRT coordinateur.
Vérification B : nouveaux fabricants. Un importateur ou distributeur qui vend sous son propre nom, ou qui modifie substantiellement le robot, devient fabricant de cette offre. D'autres tiers ne franchissent cette ligne que lorsque leur changement est substantiel.
Régimes connexes : règlement Machines à partir du 20 janvier 2027, ISO 10218-1:2025, NIS2 pour les opérateurs d'infrastructures critiques et règlement IA pour les applications avec IA.
Les lignes suivantes sont la version courte : que vérifier, quand suspendre et quand le robot nécessite une nouvelle analyse de rôle. Le détail transversal des rôles est dans qui doit se conformer au CRA.
Acceptation par l'importateur
Vérifiez la déclaration, le contrôle du marquage CE, l'index du dossier, la période d'assistance, le contact pour les vulnérabilités, l'identité de l'importateur et le manuel dans la langue de destination. Suspendez si le paquet, la traçabilité, le modèle d'identifiants de la console, le compte cloud ou le canal de mise à jour soulèvent des doutes.
Diligence du distributeur
Vérifiez le marquage CE visible, les documents fournis, la traçabilité de l'exploitant, l'assistance et les affirmations de mise à jour. Suspendez si l'offre masque les opérateurs, exagère l'assistance, contredit la déclaration ou continue d'être vendue après la divulgation d'une vulnérabilité connue.
Intégrateur en tant que fabricant de machine
Un intégrateur qui combine le bras avec la sécurité, la vision et la logique de cellule devient fabricant de la machine lorsque la cellule sort sous son nom. Le fabricant du robot reste fabricant du composant pour le bras, le contrôleur et le logiciel fourni.
Importateur ou distributeur sous marque propre
Un importateur ou distributeur qui met le robot sur le marché de l'Union sous son propre nom ou sa propre marque devient fabricant de cette offre. Il en va de même s'il modifie substantiellement un robot déjà commercialisé : firmware avec marque propre, nouvelle identité de console, nouveau cloud de flotte, nouveau canal de mise à jour, nouvelle configuration de sécurité ou nouvelle utilisation prévue.
Autre revendeur après modification substantielle
Un tiers qui n'est ni fabricant, ni importateur, ni distributeur ne devient fabricant que s'il modifie substantiellement le robot avant de le mettre à disposition. Le rôle s'applique à la partie concernée, ou au produit complet si le changement affecte la cybersécurité globale.
Mandataire et notification hors UE
Le fabricant peut désigner un mandataire par mandat écrit ; c'est une option, pas une obligation liée au fait d'être hors UE. La sélection du point de notification est déclenchée par un autre fait : ne pas avoir d'établissement principal dans l'Union. La cascade du CRA commence par le mandataire, suit par l'importateur, puis le distributeur et enfin la plus grande base d'utilisateurs.
Régimes connexes
Maintenez des évaluations séparées pour le règlement Machines, ISO 10218-1:2025, NIS2 et le règlement IA. Ils peuvent partager des preuves, mais ne remplacent pas le dossier CRA.
Questions fréquentes
Les robots industriels et cobots sont-ils importants ou critiques au titre du CRA ?
Pas par catégorie de robot. Les robots industriels et cobots ne figurent pas aujourd'hui dans les listes CRA des produits importants ou critiques. L'hypothèse de travail est la voie par défaut. La voie ne change que si une fonction listée domine, par exemple un robot vendu principalement comme pare-feu, système de gestion de réseau ou contrôleur résistant aux altérations. Il n'existe pas de catégorie « robot » qui force automatiquement la voie critique.
Un bras robotisé à 6 axes a-t-il besoin d'un organisme notifié ?
Pas du fait d'être un bras robotisé. Sur la voie par défaut, le fabricant peut utiliser le contrôle interne, l'examen UE de type suivi de la conformité au type, l'assurance qualité complète ou un schéma européen de certification applicable. L'organisme notifié n'intervient que sur les voies qui l'exigent. La condition de normes pleinement appliquées relève de la voie de repli pour les produits importants de classe I, pas de la voie par défaut.
Le règlement Machines couvre-t-il déjà la partie cyber ?
Il en couvre une partie, pas la totalité. Le règlement Machines inclut des exigences de sécurité liées à la corruption des systèmes de commande et à la fiabilité du contrôle. Le CRA ajoute la couche de cyber-résilience : posture de sécurité, processus de vulnérabilités, assistance, SBOM et documentation technique. Traitez-les comme deux dossiers connectés.
Qui est fabricant lorsqu'un intégrateur construit la cellule ?
Si l'intégrateur vend la cellule finale sous son nom, l'intégrateur est fabricant de cette cellule. Le fabricant du robot conserve son dossier pour le bras, le contrôleur et le logiciel qu'il fournit. Si l'intégrateur ne fait qu'installer une cellule sous la marque du fabricant, documentez le transfert et les limites, mais n'inventez pas un changement de rôle qui n'existe pas.
Un cobot destiné aux ateliers PME relève-t-il de la même catégorie qu'un robot enclos ?
Oui, si aucune fonction listée ne domine l'offre. La différence est dans l'évaluation des risques, pas dans la catégorie CRA initiale. Le cobot a généralement plus d'exposition humaine, plus de rôles partagés et plus de dépendance au fabricant pour les avis, l'assistance et les mises à jour.
Que se passe-t-il si le robot inclut vision, IA ou téléopération distante ?
Cela ne change pas automatiquement la catégorie CRA. Cela change le périmètre et la liste de menaces. La vision ajoute caméras, SDK et modèles ; la téléopération ajoute l'autorité distante ; l'IA peut activer une analyse au titre du règlement IA si elle dépasse ses seuils. Chaque élément doit apparaître dans la note de périmètre et dans le SBOM.
Le cloud de flotte change-t-il le périmètre du produit ?
Oui, lorsque le cloud est fourni par le fabricant et qu'il est nécessaire pour les avis, mises à jour, certificats, télémétrie ou tunnels. Dans ce cas, le connecteur cloud et son autorité font partie du dossier du fabricant. Si le cloud appartient au client ou à l'intégrateur, documentez le transfert et les limites.
Que doit inclure une évaluation des risques CRA pour un robot ?
Elle doit couvrir le mouvement, le firmware de sécurité, la console de programmation, la station d'ingénierie, le bus de terrain, le cloud, le service local, les composants fournisseurs, la mise hors service et le signalement des vulnérabilités. La question n'est pas seulement de savoir s'il y a du chiffrement. La question est qui peut changer le mouvement, la configuration de sécurité ou la disponibilité.
Quel niveau de détail nécessite le modèle de menaces ?
Suffisamment pour étayer les décisions de version. Une phrase générique sur l'« accès non autorisé » ne suffit pas. Une entrée utile nomme l'actif, la frontière, le mode de défaillance, le contrôle, le test et la décision résiduelle : par exemple, « un paquet de firmware ancien est accepté pendant la récupération ; cela est atténué par signature et rejet de version antérieure ; cela est testé en mode récupération ».
Quels risques évaluer en premier ?
Commencez par ceux qui changent le mouvement ou la sécurité : identifiants usine, mises à jour de firmware, autorité du cloud, chargement de programmes, rôles de la console et bus de terrain. Couvrez ensuite la disponibilité, les données de service, les avis fournisseurs et la mise hors service.
Quel est un bon exemple d'entrée de risque ?
« Un projet de robot malformé provoque une panne de l'analyseur ou charge une trajectoire non validée depuis la station d'ingénierie. Actif : autorité de mouvement. Frontière : station d'ingénierie vers contrôleur. Contrôle : validation de format, signature du projet, rôle d'ingénierie et test négatif. Preuve : rapport de l'analyseur, journal de rejet et audit de session. »
Quand l'évaluation des risques doit-elle être mise à jour ?
Mettez-la à jour quand l'état publié change : nouveau modèle de comptes de la console, nouveau bus de terrain, changement de cloud, firmware de sécurité, environnement d'exécution, module de vision, débogage ou mise hors service. La date au plus tôt compte : les obligations de notification commencent le 11 septembre 2026, avant l'application complète du CRA le 11 décembre 2027. L'évaluation, la politique de divulgation et le contact unique doivent fonctionner avant cette date.
Quelle est la première preuve qu'un fabricant de robots doit créer ?
La note de périmètre. Elle nomme le produit exact, ce qui est livré, ce qui est hors périmètre, ce que le client intègre, ce que le fabricant maintient et quelle voie de conformité est utilisée. Sans cet enregistrement, le SBOM, l'évaluation des risques et le transfert à l'intégrateur restent flottants.
Que se passe-t-il si une vulnérabilité est découverte après la publication ?
Le fabricant doit agir immédiatement lorsque le produit ou les processus ne sont pas conformes : correction, retrait ou rappel du produit lorsque c'est approprié. En pratique, le dossier doit être prêt pour la séquence de notification : alerte 24 h pour une vulnérabilité activement exploitée, notification 72 h, rapport final lorsque la mesure corrective ou d'atténuation est disponible, et avis aux utilisateurs. Sur les robots, la correction est généralement une mise à jour signée avec une note d'impact machine et une proposition de fenêtre de maintenance ; le rappel reste pour les cas qui ne peuvent pas être mis à jour en toute sécurité sur le terrain.