Les robots humanoïdes arrivent avec des composants adaptés aux entreprises — Wi-Fi, caméras, puissance de calcul embarquée et mises à jour logicielles par voie hertzienne — mais ils se comportent moins comme des appareils informatiques traditionnels que comme des systèmes de technologies opérationnelles (OT). Ils interagissent avec le monde physique, fonctionnent sous de strictes contraintes de latence et peuvent causer de graves dommages en cas de problème.
Cette convergence n’est plus théorique. Les robots humanoïdes modernes sont capables de se déplacer dans leur environnement, de manipuler des objets et d’exécuter des tâches après avoir reçu des instructions de haut niveau de la part d’agents logiciels ou d’opérateurs humains.
Pour les équipes de sécurité, cela signifie qu’une nouvelle catégorie de terminaux cyberphysiques fait son entrée dans les environnements d’entreprise.
Si ces systèmes cessent de fonctionner — en raison de bogues, d’une mauvaise configuration ou d’une compromission — les conséquences peuvent dépasser la perte de données et affecter la sécurité physique ainsi que la continuité des opérations.
Cette évolution met en évidence une différence essentielle entre les robots humanoïdes et les terminaux d’entreprise traditionnels.
| Facteur de sécurité | Terminal traditionnel | Robot humanoïde |
|---|---|---|
| Environnement | Systèmes numériques | Environnement physique |
| Modèle de sécurité | Sécurité des terminaux informatiques | Sécurité OT + IA |
| Impact d’une défaillance | Perte de données | Sécurité + perturbation des opérations |
| Couche de contrôle | Utilisateur / application | Systèmes d’agents + autonomie |
| Surface d’attaque | Réseau et logiciels | Capteurs, autonomie, agents d’IA |
| Cadres de sécurité | Cadres informatiques | Gouvernance OT + IA |
- Première étape : traiter les humanoïdes comme des systèmes OT
- Deuxième étape : reconnaître la couche des agents comme une nouvelle frontière de privilèges
- Cartographier les risques liés aux robots agents sur l’OWASP Top 10 des LLM
- Les cadres de gouvernance restent applicables
- Les incidents cyber peuvent devenir des incidents de sécurité physique
- Mesures de sécurité de base pour les déploiements robotiques
- Que doivent inclure les exigences de sécurité en robotique
- En résumé
Première étape : traiter les humanoïdes comme des systèmes OT
Les équipes de sécurité doivent commencer par classer les robots humanoïdes parmi les appareils de technologies opérationnelles plutôt que parmi les terminaux traditionnels.
Les recommandations de NIST sur la sécurité des technologies opérationnelles définissent les OT comme des systèmes programmables qui interagissent avec l’environnement physique tout en exigeant des garanties de fiabilité, de sécurité et de performance. Les robots mobiles correspondent à cette définition.
De même, les normes ISA/IEC 62443 portent sur les exigences de sécurité applicables aux systèmes d’automatisation et de contrôle industriels (IACS). À mesure que les robots commencent à effectuer des tâches dans des usines, des entrepôts et des installations logistiques, ils deviennent de fait des composants mobiles au sein de ces environnements de contrôle.
Cette distinction est importante, car bon nombre des outils traditionnels de sécurité des terminaux partent du principe que les systèmes peuvent tolérer les analyses, l’application de correctifs ou les délais — des hypothèses qui ne tiennent pas dans les environnements où la disponibilité et la sécurité physique sont essentielles.
Deuxième étape : reconnaître la couche des agents comme une nouvelle frontière de privilèges
Les architectures robotiques modernes s’appuient de plus en plus sur des systèmes d’autonomie en couches.
Au niveau le plus bas, les systèmes de contrôle en temps réel gèrent les moteurs, l’équilibre et les mouvements physiques. Au-dessus se trouve une couche de « compétences » responsable de capacités distinctes, comme ouvrir des portes ou saisir des objets.
Une troisième couche — souvent appelée couche des agents ou de planification — orchestre les tâches à partir d’instructions de haut niveau ou de données provenant de l’environnement.
Dans certains déploiements, cette couche des agents peut s’exécuter sur des serveurs locaux au sein d’une installation plutôt que directement sur le robot.
Du point de vue de la sécurité, cela introduit une nouvelle frontière de privilèges :
- Couche de contrôle : exécute les mouvements physiques (impact élevé)
- Couche de compétences : assure des capacités distinctes
- Agent couche : détermine les actions à exécuter (fort effet de levier)
Si des attaquants influencent la couche des agents — ou les outils et modèles sur lesquels elle s’appuie — ils peuvent être capables de déclencher des actions légitimes du robot à des fins malveillantes.
Autrement dit, le robot peut se comporter exactement comme prévu, mais dans le mauvais contexte.
Cette architecture en couches crée plusieurs points de contact de sécurité où une compromission pourrait influer sur le comportement du robot.
| Couche | Fonction | Risque de sécurité |
|---|---|---|
| Couche de contrôle | Mouvement physique et équilibre | Impact direct sur la sécurité |
| Couche de compétences | Manipulation d’objets et navigation | Exécution d’actions non autorisées |
| Couche des agents | Planification et orchestration des tâches | Injection de requêtes / manipulation |
| Réseau | Communication avec l’infrastructure | Risque de déplacement latéral |
| Modèles d’IA | Interprétation des commandes et de l’environnement | Exploitation du modèle |
Cartographier les risques liés aux robots agents sur l’OWASP Top 10 des LLM
Si un robot utilise un modèle de langage ou de vision pour interpréter des instructions, des données environnementales ou les sorties d’outils, plusieurs risques de l’OWASP Top 10 for LLM Applications deviennent directement pertinents.
Voici quelques exemples :
- LLM01 : injection de requêtes — des entrées spécialement conçues manipulent le comportement du modèle
- LLM02 : gestion non sécurisée des sorties — utilisation dangereuse des sorties générées par le modèle
- LLM08 : agentivité excessive — accorder trop d’autonomie aux modèles sans garde-fous
Ces catégories ont été initialement conçues pour les applications logicielles d’IA, mais leurs implications deviennent bien plus graves lorsque l’« application » peut se déplacer dans l’espace physique, ouvrir des portes ou manipuler des équipements.
Les cadres de gouvernance restent applicables
Les organisations qui déploient des systèmes autonomes doivent également considérer leurs programmes de robotique comme des initiatives de gouvernance de l’IA.
Le NIST AI Risk Management Framework fournit une structure pratique pour évaluer et gérer ces risques. Ses fonctions fondamentales — gouverner, cartographier, mesurer et gérer — aident les organisations à intégrer les politiques, les mesures de protection techniques, la surveillance et l’amélioration continue tout au long du cycle de vie de l’IA.
Pour les déploiements robotiques, ce cadre contribue à relier les pratiques de sécurité à la supervision de la sûreté et des opérations.
Les incidents cyber peuvent devenir des incidents de sécurité physique
Contrairement aux terminaux traditionnels, les robots compromis peuvent entraîner des conséquences physiques immédiates.
Un robot manipulé pourrait notamment :
- Pénétrer dans des zones restreintes ou déverrouiller des portes
- Déplacer des stocks ou des équipements de manière non autorisée
- Bloquer des sorties de secours ou perturber les flux de travail
- Endommager des actifs physiques
Dans des environnements tels que les entrepôts, les usines et les installations logistiques, ces actions pourraient rapidement faire passer un incident de sécurité au stade d’événement mettant en jeu la sécurité physique.
C’est pourquoi la sécurité de la robotique doit associer les pratiques de cybersécurité et de sûreté opérationnelle.
Mesures de sécurité de base pour les déploiements robotiques
Les équipes de sécurité qui évaluent des déploiements robotiques doivent exiger plusieurs protections de base avant d’autoriser les robots dans les environnements de production.
Segmentation du réseau et services internes uniquement
Les robots doivent fonctionner sur des réseaux segmentés dont le trafic est-ouest est strictement contrôlé, et leurs services d’agents ainsi que leurs systèmes de contrôle doivent rester sur une infrastructure interne plutôt que d’être exposés à l’Internet public.
Cette approche suit les bonnes pratiques établies de sécurité des technologies opérationnelles (OT), conçues pour limiter les déplacements latéraux et réduire les surfaces d’attaque.
Authentification et autorisation fortes pour l’invocation des compétences
Les systèmes robotiques exposent souvent des « compétences » distinctes, telles que la navigation, la manipulation d’objets ou l’interaction avec l’environnement.
Le déclenchement de ces compétences doit être traité comme l’exécution d’une action privilégiée, avec des contrôles d’identité, l’application de politiques et une journalisation complète.
Mises à jour signées et contrôles de la chaîne d’approvisionnement logicielle
Les robots modernes sont des systèmes largement définis par logiciel. Les mises à jour des piles d’autonomie, des modèles d’IA et des logiciels de contrôle doivent suivre des pratiques strictes de chaîne d’approvisionnement logicielle, notamment des artefacts signés, des déploiements progressifs et des mécanismes de restauration.
Contraintes de sûreté étayées par la documentation des fournisseurs
Certains fabricants de robots avertissent explicitement les utilisateurs de maintenir des distances de sécurité en raison de la puissance et de la complexité des machines humanoïdes. Ces avertissements doivent se traduire par des contrôles de sûreté formels et des procédures opérationnelles au sein des déploiements.
Que doivent inclure les exigences de sécurité en robotique
Les organisations qui envisagent de déployer des robots humanoïdes doivent intégrer des exigences de sécurité dans la planification des achats et du déploiement.
Les principales exigences sont les suivantes :
- Limites de confiance claires (composants sur le robot, sur site et dans le cloud)
- Documentation complète des ports et des protocoles
- Journalisation détaillée des commandes, des compétences invoquées et des actions des agents
- Mécanismes de validation des mises à jour et de restauration
- Procédures de réponse aux incidents, notamment l’arrêt sécurisé et l’isolement
En résumé
Les robots humanoïdes ne doivent pas être évalués comme des gadgets — et ils ne doivent pas être sécurisés comme des ordinateurs portables.
Ils représentent une nouvelle classe de terminaux cyberphysiques : des appareils de technologie opérationnelle augmentés par des couches décisionnelles d’IA.
Les sécuriser nécessite de combiner les pratiques traditionnelles de sécurité OT, telles que la norme NIST SP 800-82 (Guide to OT Security) et la norme ISA/IEC 62443, avec des approches modernes de modélisation des menaces liées à l’IA, comme l’OWASP Top 10 des LLM, ainsi qu’avec des cadres de gouvernance tels que le NIST AI RMF.
À mesure que les robots passent des démonstrations aux déploiements réels, les organisations qui les traiteront comme des infrastructures critiques dès le départ seront bien mieux préparées à gérer les risques qu’ils introduisent.
Cette convergence des technologies OT et de l’informatique d’entreprise pousse les organisations à adopter des solutions zero trust pour mieux sécuriser les technologies émergentes et les systèmes critiques.