La difficulté des robots humanoïdes ne réside pas seulement dans le fait de les faire bouger ou reconnaître des objets, mais dans la construction d’un système informatique et de sécurité capable de gérer un grand nombre de capteurs et de décisions instantanées, tandis que la machine fonctionne à proximité des êtres humains, dans les maisons, les hôpitaux et les écoles. Selon une analyse publiée par Semiconductor Engineering le 3 septembre 2026, cette proximité rend les risques des robots humanoïdes différents de ceux des voitures autonomes, car le piratage d’un système numérique dans un robot peut se traduire directement par un impact physique sur les personnes et l’environnement.
Une architecture hybride entre centralisation et distribution
Les conceptions de robots humanoïdes s’orientent vers un modèle hybride associant une unité informatique centrale puissante à des unités distribuées à proximité des membres et des articulations. L’unité centrale prend en charge la perception globale, la compréhension de la scène, la planification et la coordination des mouvements à l’échelle du robot, tandis que de plus petites unités traitent les données des doigts et des articulations ainsi que les boucles de contrôle locales avec un temps de réponse court.
Ce système peut comprendre des microcontrôleurs (MCU), des processeurs généraux, des unités de traitement graphique, des processeurs de traitement d’images et de signaux, ainsi que des unités neuronales dédiées à l’accélération de l’intelligence artificielle. Ronald Stärz, ingénieur systèmes spécialisé dans les robots humanoïdes chez Infineon Technologies, a indiqué qu’une unité de contrôle dédiée à la sécurité devait accompagner le traitement principal et que la sécurité ne devait pas être laissée au seul modèle d’intelligence artificielle.
Edo Cohen, responsable du groupe Physical AI Birds of a Feather au sein de la MIPI Alliance, estime pour sa part que le calcul local est utile pour les boucles rapides liées aux mains, aux pieds, à l’équilibre et au retour tactile. En revanche, la centralisation peut être plus efficace en matière de nombre de composants, de coût, de consommation énergétique et de simplification du développement logiciel. Il n’existe donc pas encore de conception unique adaptée à tous les usages.
Les capteurs déterminent la forme du système
Les robots humanoïdes reçoivent des données de caméras, de microphones, de radars, de lidars et de capteurs à ultrasons, ainsi que de capteurs tactiles magnétiques, capacitifs et résistifs. Les doigts de la main, en particulier, ont besoin d’un retour continu pour ajuster la force de préhension et empêcher l’écrasement ou la chute de l’objet.
Dans une conception centralisée, il est possible d’utiliser des capteurs relativement simples et d’envoyer les données brutes vers un pont de capteurs reposant sur un FPGA, tel que Nvidia HoloScan, puis de les transmettre par Ethernet à une unité GPU pour analyser la scène. Cela permet d’ajouter un plus grand nombre de petits capteurs et de transférer une plus grande partie de la consommation énergétique vers un seul point de calcul, mais l’unité GPU elle-même peut consommer beaucoup d’énergie.
La distribution du traitement à proximité des capteurs réduit le temps de réponse et envoie à l’unité centrale des données prétraitées, mais elle accroît le nombre de composants, de logiciels et de points de connexion. Selon Nebu Philips de Synaptics, la décision dépend de l’ensemble de la chaîne de traitement, depuis la réception et le décodage des données jusqu’au traitement des images, en passant par leur point de regroupement, ainsi que du type de robot, qu’il soit humanoïde, collaboratif ou de service.
De la périphérie au cloud
Le choix du calcul local ne signifie pas nécessairement isoler le robot du cloud. Certains systèmes peuvent avoir besoin de se connecter à des centres de données pour entraîner de grands modèles de langage ou des modèles de vision-langage-action (VLA), tandis que d’autres applications tirent parti de petits modèles de langage spécialisés fonctionnant sur l’appareil.
Le choix dépend des priorités de l’entreprise : confidentialité, contrôle des données, coût d’exploitation, nature de l’environnement de travail et disponibilité d’une connexion filaire ou sans fil aux centres de données. Matthew Bubis d’Imagination Technologies a expliqué que le calcul local et le calcul centralisé continueront d’exister ensemble, car aucune solution unique ne convient à toutes les entreprises et à toutes les tâches.
Une surface d’attaque plus vaste que celle des voitures
Les robots humanoïdes combinent une forte densité de capteurs, des modèles d’intelligence artificielle, des communications sans fil et la capacité de se déplacer et de manipuler des objets. Les points d’attaque potentiels comprennent donc les logiciels des modèles, les mises à jour de micrologiciels par voie hertzienne, les pilotes des caméras, les canaux Wi-Fi, les interfaces de contrôle et les mécanismes de connexion des agents intelligents.
Dana Neustadter de Synopsys a mis en garde contre les risques d’altération de l’intégrité du modèle lors de son chargement ou de sa mise à jour, ainsi que contre les attaques par empoisonnement des données au moyen de mises à jour sans fil. L’exploitation du flux de vision pourrait amener le robot à saisir le mauvais objet, à entrer dans une zone dangereuse ou à exécuter un mouvement non sûr. Des attaques de type homme du milieu ou le piratage de la connexion sans fil pourraient également permettre de prendre le contrôle du robot et de lui envoyer des commandes.
Sylvain Guilley de Secure-IC estime que l’apparence humaine peut créer des risques supplémentaires, comme la difficulté à distinguer un agent robotique d’une personne autorisée, ou l’utilisation du robot pour écouter discrètement à proximité ou usurper l’identité d’une autre personne. Selon l’analyse présentée dans l’article, les interactions vocales et naturelles pourraient devenir un canal d’exploitation de la confiance, en particulier lorsque l’utilisateur traite le robot comme s’il était un interlocuteur humain.
Qu’est-ce qui change concrètement ?
La conclusion la plus importante pour les développeurs est que la sécurité et la sûreté doivent être conçues avec l’architecture des puces et des communications, et non ajoutées ultérieurement sous la forme d’une couche logicielle. Les mesures mentionnées par les participants comprennent une identité intégrée de l’appareil, un démarrage sécurisé, un stockage protégé des clés, des communications chiffrées et une protection pendant l’exécution des modèles. L’importance de l’authentification multimodale ressort également : la voix seule peut ne pas suffire et peut être complétée par le toucher, l’empreinte digitale ou la combinaison de la caméra et de la voix afin de vérifier l’identité et le contexte.
L’article souligne également l’importance des normes ouvertes, telles que les spécifications MIPI et RISC-V, pour offrir davantage de choix aux fournisseurs et raccourcir les cycles de développement. Toutefois, l’ouverture ne supprime pas la nécessité d’une vérification de sécurité et d’une gestion des risques, et ne permet pas à elle seule de trancher entre une conception centralisée ou distribuée.
L’énergie et le coût restent des contraintes déterminantes. L’utilisation excessive d’unités GPU ou de capteurs peut réduire l’autonomie ou augmenter le prix jusqu’à affaiblir la viabilité commerciale. Aux États-Unis, les ventes de robots ont atteint 11,4 milliards de dollars en 2026, soit une hausse de 29 % sur un an, selon le rapport du Robotics Center mentionné dans l’article. Toutefois, l’expansion plus large des robots humanoïdes restera liée à l’amélioration de l’autonomie des batteries, à la réduction des coûts et à la démonstration de la capacité des systèmes à résister au piratage.
Lecture éditoriale : la source n’annonce ni une plateforme unique ni une solution de sécurité complète, mais décrit une phase de conception dans laquelle l’architecture n’est pas encore stabilisée. Le véritable défi consiste à équilibrer le temps de réponse, la consommation énergétique, le nombre de capteurs, la flexibilité logicielle ainsi que les exigences de sûreté et de sécurité. Les avertissements concernant la manipulation des modèles et l’interaction humaine montrent également que la protection du robot ne s’arrête ni à la puce ni au réseau, mais s’étend au comportement des agents et aux façons dont les utilisateurs se fient à leurs résultats. La nature des exigences réglementaires et les mécanismes pratiques permettant de démontrer la sécurité de ces systèmes restent des questions ouvertes dans l’article, qui rapporte les avis d’experts de plusieurs entreprises sans présenter de norme de marché unifiée.