Un robot humanoïde moderne ne se résume pas à une mécanique capable de marcher et de saisir des objets. Il utilise des caméras, des microphones, des capteurs d’effort, des logiciels d’intelligence artificielle et souvent une connexion à des services distants. Cette richesse fonctionnelle lui permet d’apprendre, de recevoir des missions et de coopérer avec des personnes. Elle crée aussi une surface d’attaque inhabituelle.

Le risque ne relève pas uniquement de la science-fiction. Une faille informatique peut affecter la confidentialité des données, interrompre une activité ou modifier le comportement d’une machine physique. La cybersécurité d’un humanoïde doit donc protéger à la fois l’information et le monde réel dans lequel le robot se déplace.

Pourquoi un humanoïde est-il une cible particulière ?

Un ordinateur compromis peut divulguer des fichiers ou devenir indisponible. Un humanoïde piraté pourrait, en plus, effectuer un geste non prévu. Ses moteurs lui donnent la capacité de déplacer une charge, d’ouvrir une porte ou d’approcher une personne. Le lien entre logiciel et mouvement transforme ainsi un incident numérique en risque matériel.

La complexité augmente le nombre de points à protéger. Le robot possède un système d’exploitation, des applications, des modèles d’intelligence artificielle, des interfaces de maintenance et plusieurs moyens de communication. Des équipements périphériques peuvent s’y ajouter : station de recharge, console de supervision, réseau de l’usine ou service dans le cloud.

Une faiblesse ne se trouve pas nécessairement dans le robot lui-même. Un compte administrateur mal protégé, un serveur de mise à jour compromis ou un ordinateur de maintenance infecté peuvent devenir des voies d’accès indirectes. La sécurité doit donc couvrir tout l’écosystème et toute la durée de vie de la machine.

Des capteurs qui recueillent des informations sensibles

Pour comprendre son environnement, l’humanoïde observe en permanence. Ses caméras peuvent enregistrer des visages, des écrans, des documents ou l’organisation d’un lieu. Ses microphones peuvent capter des conversations. Les journaux techniques révèlent parfois les horaires, les déplacements ou les habitudes de travail.

Le premier enjeu consiste à limiter la collecte. Toutes les données perçues n’ont pas besoin d’être conservées ni envoyées vers un serveur distant. Un traitement local peut réduire l’exposition, à condition que le calcul embarqué soit lui-même correctement protégé. Les informations conservées doivent être chiffrées, accessibles aux seules personnes autorisées et supprimées lorsqu’elles ne sont plus nécessaires.

Cette transparence est particulièrement importante dans un domicile, un établissement de soins ou un espace partagé. Les personnes présentes devraient savoir quels capteurs fonctionnent, quelles données sont mémorisées et dans quelles circonstances un opérateur peut accéder à distance au robot.

La prise de contrôle n’est pas le seul scénario

L’image la plus spectaculaire serait celle d’un pirate commandant directement les bras ou les jambes de la machine. Une architecture sérieuse doit précisément empêcher qu’une instruction reçue par le réseau se transforme sans vérification en mouvement dangereux. Des limites matérielles et logicielles doivent rester actives, même si une couche supérieure du système est défaillante.

D’autres attaques, moins visibles, peuvent toutefois suffire à perturber le service. Un attaquant pourrait bloquer les mises à jour, désactiver un capteur, voler des identifiants, falsifier une mission ou provoquer des arrêts répétés. Dans une usine, l’indisponibilité de plusieurs robots au même moment peut désorganiser une chaîne sans qu’aucun mouvement spectaculaire ne se produise.

Les fonctions d’intelligence artificielle introduisent aussi des menaces spécifiques. Des données d’apprentissage altérées peuvent dégrader un modèle. Des entrées soigneusement conçues peuvent tromper un système de perception. La protection classique des comptes et des réseaux reste indispensable, mais elle doit être complétée par des tests portant sur les modèles, les données et les situations inhabituelles.

Séparer l’intelligence de la sécurité immédiate

Un principe essentiel consiste à ne pas confier toutes les décisions à un même logiciel. Le modèle qui interprète une consigne peut proposer une action, mais une couche de contrôle indépendante doit vérifier les vitesses, les efforts, les zones interdites et la proximité des personnes. Un ordre incohérent doit être refusé avant d’atteindre les moteurs.

Les fonctions d’arrêt et de limitation doivent continuer à fonctionner lorsque la connexion est perdue ou que le système intelligent produit une réponse imprévue. Le robot doit pouvoir rejoindre un état sûr : s’immobiliser sans lâcher une charge dangereusement, réduire sa puissance ou demander une intervention humaine.

Cette séparation ne garantit pas l’absence totale d’incident. Elle évite cependant qu’une seule faille donne immédiatement accès à toutes les capacités physiques. Elle facilite également les tests, car chaque niveau peut être évalué avec des responsabilités clairement définies.

Des mises à jour nécessaires, mais contrôlées

Un humanoïde déployé pendant plusieurs années rencontrera de nouvelles vulnérabilités. Il doit donc pouvoir recevoir des correctifs. La mise à jour constitue pourtant elle-même une opération sensible : si son origine n’est pas vérifiée, elle peut servir à installer un logiciel malveillant sur toute une flotte.

Les paquets doivent être signés, leur intégrité contrôlée et leur déploiement testé avant une diffusion générale. Une entreprise peut commencer par quelques machines, surveiller leur comportement puis étendre progressivement l’installation. Un mécanisme de retour à la version précédente est utile lorsqu’une mise à jour légitime provoque une anomalie.

Le constructeur doit annoncer une durée de support réaliste et organiser la réception des signalements de vulnérabilités. L’utilisateur, de son côté, doit connaître l’état de chaque robot et éviter qu’une machine ancienne reste connectée avec un logiciel qui ne reçoit plus de correctifs.

Protéger une flotte dans l’entreprise

La première mesure pratique est l’inventaire : modèle, version logicielle, composants, comptes autorisés et connexions utilisées. Il devient impossible de corriger rapidement une faille si l’organisation ignore quelles machines sont concernées.

Le réseau des robots devrait être séparé des postes bureautiques et des services qui n’ont aucune raison de communiquer avec eux. Chaque flux doit correspondre à un besoin identifié. Les accès de maintenance exigent une authentification forte, des droits limités et une traçabilité permettant de savoir qui a modifié quoi.

Les journaux d’événements peuvent aider à détecter un comportement anormal : connexion depuis un emplacement inattendu, changement de configuration, multiplication des échecs ou mission lancée à une heure inhabituelle. Leur surveillance doit être associée à une procédure concrète. Qui peut arrêter la flotte ? Comment isoler un robot ? Comment maintenir l’activité en mode dégradé ?

Le cadre européen renforce la sécurité dès la conception

Le règlement européen sur la cyberrésilience établit des exigences horizontales pour les produits comportant des éléments numériques. Selon la configuration et l’usage du robot, son fabricant devra intégrer la cybersécurité dans la conception, gérer les vulnérabilités et fournir des mises à jour pendant la période de support applicable.

Cette évolution est importante, car la protection ne peut pas reposer uniquement sur l’acheteur final. Un utilisateur ne peut pas corriger seul un micrologiciel fermé, vérifier tous les composants ou prolonger un support abandonné. Le constructeur, l’intégrateur et l’exploitant doivent partager des informations précises sur les dépendances, les correctifs et les conditions d’utilisation sûre.

Les questions à poser avant un déploiement

Avant d’acheter un humanoïde, une entreprise devrait demander où les données sont traitées et stockées, combien de temps elles sont conservées et qui peut y accéder. Elle doit connaître la durée prévue des mises à jour, la procédure de signalement d’une faille et les conséquences d’une coupure de connexion.

Il faut également vérifier si les commandes distantes peuvent atteindre directement les actionneurs, si les fonctions de sécurité sont indépendantes et si le robot dispose d’un mode de fonctionnement dégradé. Un test d’intrusion est utile, mais il ne remplace ni une architecture robuste ni la surveillance continue après la mise en service.

La confiance devra être démontrée

Plus un humanoïde devient autonome et proche des personnes, plus sa cybersécurité participe à sa sécurité générale. Une machine agile mais impossible à mettre à jour, opaque sur ses données ou dépendante d’un accès distant mal contrôlé ne peut pas être considérée comme prête pour un usage durable.

La bonne approche ne consiste pas à renoncer aux robots connectés. Elle consiste à prévoir les attaques, limiter leurs effets et conserver une maîtrise humaine. Les futurs humanoïdes seront jugés sur leur capacité à accomplir une tâche, mais aussi sur leur aptitude à rester prévisibles lorsqu’un réseau, un logiciel ou un modèle d’intelligence artificielle ne se comporte plus comme prévu.