Acheter un robot mobile directement auprès d’un constructeur chinois, sans passer par un intégrateur européen, oblige l’industriel à prendre en charge davantage de vérifications.
Au-delà des performances et du prix, il doit examiner les flux de données, les accès distants, les mises à jour et les conditions de maintenance. Car un robot connecté devient aussi une composante du système informatique industriel.
Prenons le cas d’une entreprise française qui achète des robots mobiles directement auprès d’un constructeur chinois pour équiper son usine ou son entrepôt. Elle compare leur charge utile, leur autonomie, leur précision de navigation et leur prix. Mais avant de connecter ces machines au réseau du site, elle doit également comprendre leur architecture numérique.
Les robots peuvent-ils fonctionner sans connexion au cloud du fabricant ? Les cartes du site, les images et les données de diagnostic restent-elles dans l’entreprise ? Qui peut accéder aux machines à distance, depuis quels pays et avec quelles autorisations ? Comment les mises à jour sont-elles validées ?
Sans intégrateur européen, l’entreprise doit organiser elle-même ces vérifications ou les confier à un spécialiste. La présence d’un intégrateur ne garantit toutefois pas, à elle seule, la cybersécurité : son périmètre d’intervention, ses compétences et ses responsabilités doivent être explicitement définis.
Pour identifier des fabricants, intégrateurs et spécialistes du secteur, les industriels peuvent consulter l’annuaire professionnel de la robotique. Les compétences précises du prestataire en cybersécurité industrielle doivent néanmoins être vérifiées avant toute intervention.
La nationalité chinoise du constructeur ne constitue pas en soi une vulnérabilité. En revanche, l’absence de documentation, l’opacité des communications ou l’impossibilité de révoquer un accès distant sont des critères concrets à examiner avant l’achat.
Pour l’industriel, la question est simple : après l’installation, qui maîtrise les robots, leurs données et leurs connexions ?
Une surface d’attaque qui dépasse le robot
Un AMR, ou robot mobile autonome, fonctionne rarement seul. Selon son architecture, il communique avec un serveur de gestion de flotte, une interface de supervision, un système de gestion d’entrepôt et des services de maintenance. Le périmètre à examiner comprend donc aussi les postes d’administration, les équipements réseau et les interfaces logicielles.
Le NIST rappelle que les systèmes OT, les technologies qui surveillent ou commandent des processus physiques, présentent des contraintes spécifiques de disponibilité, de fiabilité et de sécurité. Une compromission informatique doit être évaluée pour ses conséquences sur l’exploitation.
Prenons un scénario hypothétique : un compte de maintenance compromis donne accès au gestionnaire de flotte. Selon les permissions accordées, un attaquant pourrait consulter des informations, modifier des missions ou interrompre le service.
Cela ne signifie pas qu’il pourrait automatiquement neutraliser les protections physiques des robots. Mais une flotte immobilisée peut déjà perturber l’approvisionnement d’une ligne de production.
L’évaluation doit ainsi couvrir la confidentialité des données, l’intégrité des configurations, la disponibilité du service et les possibilités de propagation vers d’autres systèmes.
Savoir quelles données quittent le site
Selon les capteurs et les fonctions activées, un robot peut produire des cartes de l’usine, des images, des journaux de mission et des informations de diagnostic. Toutes ces données ne quittent pas nécessairement le site. Le fournisseur doit préciser lesquelles sont traitées localement et lesquelles sont transmises.
Pour chaque communication externe, l’acheteur devrait connaître la destination, la finalité, le contenu transmis et les conditions d’activation. Il faut également identifier les prestataires concernés, les durées de conservation et les conséquences d’une désactivation du service.
Le chiffrement protège les données pendant leur transport. Il ne répond pas, à lui seul, aux questions relatives à leur utilisation ou aux personnes qui peuvent les consulter à destination.
La pièce à demander est une matrice des flux, indiquant les sources, les destinations, les ports, les protocoles et les usages. Cette documentation devrait être confrontée aux communications réellement observées pendant un pilote, notamment lors d’une mise à jour ou d’une intervention du support.
Un flux vers un serveur extérieur n’est pas automatiquement suspect. Un flux inexpliqué ou impossible à maîtriser appelle, en revanche, une investigation.
Encadrer la télémaintenance
La maintenance à distance peut réduire le temps de diagnostic. Elle devient un point sensible lorsqu’un accès reste ouvert en permanence, utilise un compte partagé ou échappe à la visibilité de l’exploitant.
Pour un projet robotique, Robot Magazine recommande des comptes nominatifs, une authentification multifacteur sur le point d’entrée de télémaintenance et des droits limités aux opérations nécessaires.
Les sessions devraient être autorisées pour une durée définie et laisser des traces exploitables. L’entreprise doit pouvoir identifier l’intervenant, connaître les systèmes accessibles et révoquer l’accès.
Un VPN sécurise un canal de communication. Il ne garantit pas que les permissions de l’utilisateur sont adaptées ni que son accès est suffisamment restreint.
Dans le cas d’un achat direct, ces modalités doivent être négociées avec le constructeur avant le déploiement. Il faut notamment préciser qui autorise les interventions et qui conserve les journaux d’accès.
Isoler les robots sans bloquer leur fonctionnement
Placer les robots sur un VLAN dédié constitue un premier niveau de séparation. Encore faut-il filtrer les échanges entre ce réseau, le serveur de flotte et les autres applications de l’entreprise.
L’approche recommandée consiste à identifier les communications nécessaires au fonctionnement, puis à n’autoriser que celles-ci. Les interfaces d’administration doivent être accessibles depuis des postes ou des points d’entrée maîtrisés.
La segmentation doit être vérifiée dans les faits : une règle trop permissive entre réseaux peut annuler le bénéfice apparent de leur séparation.
Le pilote doit aussi tester les dépendances du système. Que se passe-t-il lorsque le cloud devient inaccessible, lorsque la connexion Wi-Fi est perdue ou lorsque le serveur de flotte redémarre ?
Les réponses doivent préciser les fonctions maintenues, l’état adopté par les robots et les conditions de reprise. Ces comportements doivent être compatibles avec les exigences de sécurité et de continuité du site.
ROS 2 ne dispense pas de vérifier la configuration
Pour les équipements utilisant ROS 2, le nom du middleware ne constitue pas une garantie de cybersécurité. Les travaux consacrés à SROS2 présentent des outils et une méthode pour sécuriser les communications et les graphes ROS 2, tout en soulignant les difficultés de mise en œuvre.
L’acheteur doit demander quelles protections sont réellement déployées : authentification des participants, permissions de communication, chiffrement et gestion des certificats.
Il faut également examiner le comportement du système lorsqu’un certificat expire ou qu’une configuration de sécurité est invalide.
Cette analyse ne remplace pas l’examen du système d’exploitation, des interfaces web, des API et des composants tiers. La sécurité doit être évaluée sur la configuration effectivement livrée.
Prévoir les mises à jour pendant toute la durée d’exploitation
L’entreprise doit comprendre comment le robot vérifie l’origine et l’intégrité d’une mise à jour, qui peut la déclencher et comment son installation est tracée.
La signature d’un paquet contribue à protéger contre une modification non autorisée. Elle ne garantit pas que la nouvelle version est exempte de vulnérabilités ou compatible avec toutes les configurations du site.
Le processus devrait prévoir une validation préalable, une fenêtre d’intervention et une procédure de récupération. Une restauration éventuelle doit rester maîtrisée pour éviter de réintroduire une version vulnérable.
La durée du support logiciel mérite une attention particulière. Pour une machine destinée à fonctionner dix ans, le contrat devrait préciser l’échéance de maintenance, les conditions de correction des vulnérabilités et les solutions proposées en fin de support.
Il faut également anticiper la dépendance au fournisseur : l’entreprise peut-elle sauvegarder ses configurations, récupérer ses données et poursuivre certaines opérations si un service distant disparaît ?
Distinguer cybersécurité et sécurité physique
L’analyse cyber doit examiner les interfaces entre commande, supervision et fonctions de sécurité. Quelles configurations sont modifiables à distance ?
Quelles protections subsistent en cas de perte ou de compromission des communications ?
Un test d’intrusion ne remplace pas la validation des fonctions de sécurité. Inversement, la présence de dispositifs de protection physique ne démontre pas que les accès informatiques et les données sont maîtrisés.
Les essais susceptibles de provoquer un mouvement, un arrêt ou une dégradation doivent être préparés avec le constructeur et réalisés dans un environnement contrôlé.
L’objectif est de vérifier les conséquences possibles d’un incident sans mettre les personnes ni l’installation en danger.
Le calendrier européen doit être anticipé
Le Cyber Resilience Act introduit des exigences de cybersécurité pour les produits comportant des éléments numériques entrant dans son champ d’application.
Ses principales obligations s’appliqueront le 11 décembre 2027. Les obligations de signalement des vulnérabilités activement exploitées et des incidents graves s’appliquent depuis le 11 septembre 2026.
Pour un achat robotique destiné à un site français, il faut demander au fournisseur comment il prépare la conformité du produit concerné. Une déclaration générale de préparation au CRA ne remplace ni la documentation technique ni l’évaluation de l’installation.
Les preuves à demander avant de signer
Pour un achat direct sans intégrateur européen, l’industriel devrait obtenir au minimum :
- Un schéma d’architecture et une matrice des flux de communication.
- Une description des données collectées, de leur destination et de leur conservation.
- Des règles documentées d’autorisation et de révocation des accès distants.
- Une procédure de mise à jour, de sauvegarde et de restauration.
- Des engagements précis sur la durée et les conditions du support logiciel.
- Un contact de signalement des vulnérabilités et un processus de correction.
- Des essais documentés de perte de connexion et de reprise du service.
- Lorsqu’un audit est fourni, un rapport précisant les versions testées, le périmètre, les limites et la vérification des corrections.
La décision d’achat doit reposer sur ces éléments vérifiables. Un prix attractif ne suffit pas : le coût total d’un projet robotique doit également intégrer la connexion au réseau, les contrôles de cybersécurité, l’accompagnement technique, les mises à jour et la maintenance. Ces dépenses peuvent réduire fortement l’avantage financier initial d’un achat direct.
FAQ – Cybersécurité des robots mobiles achetés directement auprès d’un constructeur chinois
2. Quelles données d’un AMR peuvent être transmises à l’extérieur de l’entreprise ?
Un robot mobile peut produire des cartes de l’usine, des images, des journaux de mission et des données de diagnostic. L’acheteur doit savoir précisément quelles informations restent localement, lesquelles quittent le site, vers quelle destination et pour quelle finalité. Une matrice des flux de communication constitue un document particulièrement utile pour cette vérification.
3. Comment sécuriser la télémaintenance d’un robot industriel ?
Les accès à distance devraient reposer sur des comptes nominatifs, une authentification multifacteur et des droits limités aux opérations nécessaires. Les sessions doivent également pouvoir être autorisées pour une durée déterminée, tracées et révoquées par l’entreprise. Un VPN sécurise la communication, mais ne suffit pas à garantir que les droits accordés sont appropriés.
4. Faut-il isoler les robots mobiles du reste du réseau industriel ?
La mise en place d’un VLAN dédié constitue un premier niveau de séparation, mais elle ne suffit pas à elle seule. Les communications entre les robots, le gestionnaire de flotte et les autres applications doivent être filtrées afin de n’autoriser que les échanges réellement nécessaires au fonctionnement du système.
5. ROS 2 garantit-il la cybersécurité d’un robot ?
Non. L’utilisation de ROS 2 ne constitue pas en elle-même une garantie de sécurité. L’entreprise doit vérifier les protections réellement configurées, notamment l’authentification, les permissions de communication, le chiffrement et la gestion des certificats, ainsi que la sécurité du système d’exploitation, des API et des autres composants.
6. Pourquoi faut-il examiner la politique de mises à jour avant l’achat d’un robot ?
Un robot industriel peut rester en service pendant de nombreuses années. Il est donc essentiel de connaître la durée du support logiciel, les procédures de correction des vulnérabilités, les mécanismes de sauvegarde et de restauration ainsi que les conséquences d'une éventuelle disparition d’un service distant.
7. Quels documents demander au constructeur avant de signer ?
Pour un achat direct sans intégrateur européen, l’entreprise devrait notamment demander un schéma d’architecture, une matrice des flux, la description des données collectées, les règles d’accès distant, les procédures de mise à jour et de restauration, les engagements de support et le processus de traitement des vulnérabilités. Les essais de perte de connexion et de reprise du service devraient également être documentés.
