Par Renato Cudicio, MBA, Président de Glocal Robotics
Comme beaucoup d’entre vous, je passe une partie de mes semaines sur LinkedIn et sur YouTube. Et depuis quelques mois, un même spectacle y revient en boucle : des chiens robots qui enchaînent les saltos, des humanoïdes qui dansent, des plateformes à roues qui slaloment entre des cônes — le tout présenté, avec un sérieux parfois désarmant, comme la prochaine génération de « robots de sécurité ».
Que ces machines soient impressionnantes sur le plan technique, je n’en disconviens pas. Qu’une pirouette arrière ait le moindre rapport avec la protection d’un port, d’une centrale ou d’un site militaire, permettez-moi d’en douter.
Je voudrais donc, poliment, pousser un léger coup de gueule. Non pas contre la robotique — c’est mon métier et j’y crois profondément — mais contre une confusion qui s’installe et qui, sur des sites sensibles, peut coûter cher : celle qui consiste à croire que commercialiser un robot et le maîtriser sont la même chose.
Au fond, qu’est-ce qu’un robot de sécurité?
Vu de l’extérieur, un robot de sécurité, c’est quatre roues ou des chenilles, des caméras, un LiDAR, une antenne et un ordinateur. On est tenté de le ranger dans la même case qu’un chariot autonome ou qu’un robot de nettoyage. C’est une erreur de perception.
Un robot de sécurité est un système informatique sophistiqué, connecté, doté de capteurs, qui voit, écoute, cartographie, analyse, communique et… se déplace. Pour un robot de manutention, l’origine et la maîtrise de la technologie ont surtout des conséquences commerciales ou opérationnelles. Pour un robot chargé de surveiller une usine, un port, une infrastructure énergétique ou une installation stratégique, elles deviennent une question de cybersécurité, de confidentialité, de continuité d’activité et, potentiellement, de souveraineté.
Car ce que collecte et traite une telle machine n’a rien d’anodin : des images précises de l’intérieur et de l’extérieur d’un site, des cartes détaillées des installations, des coordonnées GPS, des itinéraires et des horaires de ronde, des habitudes opérationnelles, des points d’accès, la présence ou l’absence de personnel, leur visage, des événements de sécurité, de la télémétrie, parfois de l’audio, et jusqu’à des informations sur l’architecture réseau du client.
Autrement dit, un robot de sécurité peut constituer une cartographie précise et continuellement mise à jour d’un site sensible. La bonne question n’est donc plus seulement : « Est-ce que le robot fonctionne bien? » Elle devient : « Que devient l’information qu’il collecte, quels composants y ont accès, et qui contrôle réellement le système? »
Le vrai risque n’est pas toujours celui qu’on imagine
On parle beaucoup, dans ce contexte, de « cheval de Troie » : la crainte d’une puce cachée qui espionnerait à l’insu de tous. Soyons précis, car c’est un sujet où l’approximation dessert tout le monde.
Le Centre canadien pour la cybersécurité estime d’ailleurs qu’il est peu probable, à court terme, qu’un cheval de Troie strictement matériel devienne un vecteur d’attaque majeur. En revanche, il définit très clairement ce qu’est une compromission de la chaîne d’approvisionnement matérielle : un ajout ou une modification de composants destiné à créer une porte dérobée, laquelle peut ensuite servir à installer un accès à distance, à exfiltrer des données ou à dégrader l’équipement par une commande à distance. Et il ajoute une précision essentielle : lorsqu’un produit physique devient un vecteur d’infection, il sert le plus souvent de véhicule à une menace logicielle.
Cette nuance déplace la question au bon endroit. Le vrai enjeu n’est presque jamais une puce mystérieuse soudée en secret. C’est beaucoup plus banal, et beaucoup plus difficile à voir : qui contrôle le logiciel, le micrologiciel, les communications et les mises à jour qui circulent à l’intérieur de cette machine connectée?
Se méfier des prix anormalement bas — et des démonstrations spectaculaires
Il faut aussi dire un mot des tarifs. Une plateforme bardée de caméras, de LiDAR, de calcul embarqué et de modèles d’intelligence artificielle représente un coût de conception et de fabrication considérable. Lorsqu’un tel robot est proposé à un prix étonnamment bas, ce n’est pas de la magie industrielle. C’est que quelqu’un, quelque part, absorbe la différence — et il est légitime de se demander pourquoi, et en échange de quoi.
Un prix anormalement bas pour une machine aussi capable n’est pas seulement une bonne affaire. C’est un signal. Il mérite qu’on demande qui a réellement conçu la plateforme, qui en maîtrise les couches essentielles, et ce que le fournisseur qui appose son logo est réellement en mesure de garantir. Une démonstration de saltos ne répond à aucune de ces questions.
Première exigence : savoir précisément ce qu’il y a dans la machine
Un véritable fabricant doit pouvoir répondre, pour chaque composant critique, à des questions simples : qui le fabrique, dans quel pays, sous quelle référence exacte, avec quel micrologiciel, quelles interfaces, quelles communications il peut initier, comment il se met à jour, quelles données il peut enregistrer et de quelles dépendances externes il relève.
On connaît, côté logiciel, la notion de SBOM — la nomenclature des composants logiciels (Software Bill of Materials). Il faut lui adjoindre son équivalent matériel, le HBOM (Hardware Bill of Materials). Sans cette traçabilité, on ne sait tout simplement pas de quoi le robot est fait.
Ce n’est pas une préoccupation théorique. Le Centre canadien pour la cybersécurité recommande explicitement de se prémunir contre la production non autorisée, la contrefaçon, la modification et l’insertion de code malveillant ou de porte dérobée tout au long du cycle de vie d’un système.
Deuxième exigence : savoir exactement ce que fait le logiciel
C’est le cœur du sujet. Je distingue quatre couches logicielles, et il faut savoir, pour chacune, qui la maîtrise.
La navigation : l’autopilote, les trajectoires, l’évitement d’obstacles, la localisation, les commandes moteurs, les comportements de sécurité. Si le vendeur n’a pas accès à ces couches, il dépend d’un tiers pour corriger la moindre vulnérabilité ou modifier le moindre comportement.
La perception et l’intelligence artificielle : les flux vidéo, les modèles, la reconnaissance des objets, le traitement thermique, les métadonnées produites, et les données utilisées pour entraîner ou améliorer les modèles. Une question suffit à révéler beaucoup : l’analyse est-elle réalisée localement, ou certaines images quittent-elles le robot?
Les communications : quelles adresses la machine contacte-t-elle? Appels sortants, serveurs de télémétrie, API, services infonuagiques, mises à jour automatiques, DNS, VPN, 4G/5G, Wi-Fi, réseau maillé, satellite. Le principe est simple : un système de sécurité ne devrait contenir aucune communication que son exploitant ne peut ni identifier, ni auditer, ni désactiver.
Les mises à jour : c’est le point le plus souvent oublié. Une machine peut être irréprochable le jour de son installation et le devenir beaucoup moins six mois plus tard. Le rapport de 2021 de l’ENISA (PDF – 4,8 Meg) sur les attaques de la chaîne d’approvisionnement est éclairant à cet égard : dans les cas étudiés, environ 66 % des attaques visaient le code du fournisseur, les mécanismes légitimes de mise à jour servant précisément à distribuer du code malveillant. La souveraineté d’un système ne se mesure donc pas seulement au logiciel qui y est installé aujourd’hui, mais à celui qui pourra y être installé demain.
La « boîte noire » : le concept à ne jamais perdre de vue
Un intégrateur peut connaître très bien son robot tout en ne maîtrisant pas certaines briques. On voit souvent des assemblages de ce type : plateforme assemblée par A → contrôleur fourni par B → caméra intelligente de C → module 4G de D → micrologiciel propriétaire de E → environnement infonuagique exploité par F.
À la fin de cette chaîne, qui maîtrise réellement la donnée? C’est ici qu’il faut distinguer deux postures que le vocabulaire commercial confond volontiers.
- L’intégration : « J’achète une plateforme existante et j’y ajoute mes équipements. »
- La maîtrise technologique : « Je connais l’architecture complète et je peux choisir, retirer, modifier ou remplacer chacune des briques critiques. »
La différence n’est pas sémantique. Elle décide de ce qu’un fournisseur est réellement en mesure de garantir.
La chaîne de confiance
De ce constat découle une idée que je crois centrale : celle de chaîne de confiance. Elle va des composants électroniques au micrologiciel, puis au système d’exploitation, à la navigation, à l’intelligence artificielle, aux communications, au commandement et contrôle, au stockage et, enfin, aux mises à jour.
La règle est implacable : la cybersécurité d’un robot ne peut jamais être supérieure à celle du maillon que son fabricant maîtrise le moins. Rappelons-nous qu’une chaîne d’approvisionnement est un ensemble de relations de confiance, et qu’une compromission chez un fournisseur peut permettre d’atteindre son client dès que l’équipement se connecte au réseau.
Où vivent les données — et quel droit s’y applique
Il faut ensuite distinguer, très concrètement, cinq choses : où la donnée est produite (dans le robot), où elle est analysée (en périphérie, sur un serveur local ou dans l’infonuagique), où elle est stockée, où elle transite, et — c’est le point décisif — qui, juridiquement, peut y accéder.
C’est là que la souveraineté cesse d’être un slogan pour devenir une question de droit. Dans plusieurs juridictions, un État peut contraindre une entreprise relevant de sa loi à coopérer avec ses services de renseignement, indépendamment des intentions de cette entreprise. Le débat n’est donc pas « tel pays est bon, tel autre est mauvais ». Le raisonnement pertinent est le suivant : dans quelle juridiction se trouvent mes fournisseurs, et quelles obligations légales peuvent leur être imposées à mon insu?
La souveraineté opérationnelle : fonctionner sans dépendre de personne
La vraie autonomie d’un robot ne se résume pas à sa capacité à se déplacer seul. C’est aussi sa capacité à remplir sa mission sans dépendre en permanence d’une infrastructure que son utilisateur ne contrôle pas.
Un robot de sécurité devrait pouvoir assurer ses fonctions essentielles sans connexion Internet, sans infonuagique étranger, sans authentification auprès d’un serveur distant, sans licence à distance indispensable à sa navigation et sans lien permanent avec le fabricant. Un système qui cesse de fonctionner parce qu’un serveur situé à l’autre bout du monde ne répond plus n’est pas un système souverain. C’est un service loué.
La capacité de substitution : la résilience industrielle
Passons de la cybersécurité à la souveraineté industrielle. Que se passe-t-il si une frontière se ferme, si un fabricant abandonne un produit, si une tension géopolitique surgit, si une licence d’exportation disparaît, si une pièce devient introuvable ou si un logiciel n’est plus supporté?
Un fabricant local capable de qualifier plusieurs fournisseurs, de remplacer un composant, d’adapter mécaniquement la machine, de modifier le micrologiciel et de recompiler ses logiciels dispose d’une résilience sans commune mesure avec celle d’un distributeur dépendant d’un unique fabricant d’origine. Dans ce cadre, on ne peut que recommander de diversifier les sources d’approvisionnement et de prévoir plusieurs fournisseurs pour les composants de remplacement. Un fabricant maîtrise son produit lorsqu’il peut changer un composant critique sans changer de robot.
Le contexte canadien de 2026 — et le même enjeu en Europe
Ce raisonnement n’a rien d’abstrait, et l’actualité réglementaire canadienne le confirme. En avril 2026, le gouvernement du Canada a introduit le premier niveau du Programme canadien pour la certification en cybersécurité (PCCC), dont les exigences s’appliquent à certains contrats de défense depuis l’été 2026, les niveaux supérieurs — soumis à une certification par des tiers accrédités — devant suivre par la suite. Ottawa l’écrit sans détour : les chaînes d’approvisionnement canadiennes de défense sont de plus en plus ciblées par des activités cybermalveillantes, et la sécurité des fournisseurs est désormais une composante de la sécurité nationale.
La tendance stratégique du pays va donc vers des systèmes, des fournisseurs et des chaînes d’approvisionnement dont le niveau de confiance peut être démontré. Et il serait faux de croire que c’est une préoccupation strictement canadienne : l’Europe suit exactement la même trajectoire, portée par les travaux de l’ENISA, la directive NIS2 et un débat de plus en plus explicite sur la souveraineté technologique et industrielle. Les mots changent d’un continent à l’autre; la logique, elle, est identique.
Les douze questions à poser avant d’acheter
Voici, résumées, les questions que tout responsable de la sécurité devrait poser à un fournisseur — et les raisons pour lesquelles elles comptent.
| Question à poser au fournisseur | Pourquoi c’est important |
| Qui conçoit la plateforme? | Identifier le véritable fabricant d’origine |
| Qui maîtrise le logiciel de navigation? | Contrôler les comportements du robot |
| Qui développe l’intelligence artificielle? | Maîtriser le traitement des données |
| Où les images sont-elles analysées? | Éviter les transferts non désirés |
| Le robot fonctionne-t-il sans Internet? | Garantir la souveraineté opérationnelle |
| Peut-on identifier tous les flux réseau sortants? | Détecter les communications non autorisées |
| Qui signe les mises à jour? | Sécuriser la chaîne logicielle |
| Existe-t-il une nomenclature logicielle (SBOM)? | Connaître les dépendances logicielles |
| Les composants critiques sont-ils traçables? | Sécuriser le matériel |
| Peut-on remplacer un composant critique? | Éviter la dépendance à un fournisseur unique |
| Où les données sont-elles stockées? | Assurer la souveraineté des données |
| Qui possède le code source? | Garantir la capacité d’évolution et de correction |
Si l’on ne devait en retenir qu’une : avant d’acheter un robot de sécurité, demandez qui l’a réellement construit.
Ce que cela signifie pour Glocal Robotics
C’est précisément pour ces raisons que Glocal Robotics a choisi de rester maître de l’architecture du THALAMUS plutôt que de se contenter d’habiller une plateforme conçue par un tiers. Concrètement, cela s’organise autour de six maîtrises.
La maîtrise mécanique : l’architecture physique, l’intégration des capteurs, la propulsion et l’alimentation. La maîtrise électronique : le choix et la qualification des principaux composants. La maîtrise de la navigation : l’autopilote, la localisation, les trajectoires et les comportements. La maîtrise de la perception et de l’IA : le traitement des capteurs et les fonctions de détection. La maîtrise des communications : la possibilité de choisir plusieurs technologies et de fonctionner dans différentes architectures réseau. La maîtrise du commandement, du contrôle et des données : la maîtrise de l’endroit où les données circulent, sont traitées et sont conservées.
C’est aussi dans cette logique que Glocal Robotics se conforme déjà aux critères du niveau 1 du PCCC et travaille à l’obtention du niveau 2. Non pour cocher une case, mais parce que ces exigences décrivent, en langage réglementaire, ce que nous considérons depuis le départ comme la bonne manière de construire une machine de sécurité.
Une précision, car elle m’importe. Je ne prétends pas que « les robots venus de tel pays envoient leurs données à l’étranger » : affirmer cela sans preuve technique précise sur un produit donné serait malhonnête. Je dis autre chose, de plus défendable. Lorsqu’un fournisseur commercialise une plateforme conçue par un fabricant tiers, il devrait être capable de démontrer qu’il maîtrise l’ensemble des composants, des micrologiciels, des flux de données et des mécanismes de mise à jour qui composent le système. Peut-il réellement le garantir s’il n’a ni conçu la machine, ni accès à ses couches technologiques essentielles? Je laisse chacun tirer sa propre conclusion.
La véritable question
Si cet article devait laisser quatre mots, ce seraient ceux-ci.
Traçabilité : savoir exactement de quoi le robot est fait. Maîtrise : pouvoir comprendre, modifier et sécuriser le matériel comme le logiciel. Souveraineté : contrôler les données, les communications, les fournisseurs et les dépendances. Résilience : pouvoir continuer à exploiter et à faire évoluer la machine quelles que soient les circonstances géopolitiques ou commerciales.
En matière de robotique de sécurité, la question n’est plus seulement de savoir où un robot est assemblé, ni de savoir combien de saltos il sait faire. La véritable question est de savoir qui maîtrise ce qu’il voit, ce qu’il comprend, ce qu’il transmet et ce qu’il est capable de faire.
Ce n’est pas « canadien » contre « chinois ». C’est une technologie maîtrisée et traçable contre une technologie dont certaines couches restent des boîtes noires. Sur un site industriel, une infrastructure critique ou une installation de défense, c’est cette distinction-là — bien davantage que le seul argument du « fabriqué localement » — qui devrait guider la décision.