IA physique : comment les machines intelligentes agissent, et ce qui les rend sûres

L’IA ne se contente plus de générer des réponses : elle commence à piloter des machines physiques. L’opportunité est réelle, mais une distinction familière en ingénierie devient décisive : un système capable d’accomplir une tâche n’est pas forcément prêt à l’accomplir en toute sécurité dans le monde réel.

Image de couverture fournie par la rédaction de TechiesJournal pour cet article (générée par IA). Il s’agit d’une vue conceptuelle des quatre étapes qui mènent de la perception à l’action physique, et non d’une photographie ni de la représentation d’un système réel. Les libellés des étapes font partie de l’illustration.

En informatique, nous distinguons souvent un système qui fonctionne d’un système prêt pour la production.

Une application peut réussir ses tests fonctionnels et pourtant se comporter autrement face à des informations incomplètes, à une demande inattendue ou à une dépendance défaillante. La préparation à la production pose une question plus difficile : que se passe-t-il quand les conditions ne sont plus idéales ?

L’IA physique transpose cette question dans le monde du mouvement. Une machine intelligente peut reconnaître un objet, planifier un itinéraire ou ajuster un bras robotisé. Mais si la décision est mauvaise, ou correcte mais impossible à exécuter en toute sécurité, le résultat peut être immédiat et irréversible.

Je trouve les progrès de l’IA physique passionnants. Des machines plus polyvalentes pourraient prendre en charge des tâches industrielles difficiles et travailler là où les conditions ne peuvent pas être programmées à l’avance. Mais ce qui m’intéresse tout autant, c’est l’ingénierie qui entoure l’intelligence.

Montrer qu’un robot sait faire quelque chose n’est pas la même chose que montrer qu’il sait le faire en toute sécurité dans l’environnement auquel il est destiné.

Quand l’automatisation rencontre une situation imprévue

En mars 2018, un véhicule autonome expérimental exploité par Uber a percuté et tué une piétonne à Tempe, en Arizona.

L’enquête du National Transportation Safety Board (NTSB) américain a établi que le système de conduite automatisée avait détecté la piétonne environ 5,6 secondes avant l’impact. Il a continué à la suivre, mais ne l’a pas correctement classée comme piétonne et n’a pas prédit sa trajectoire. Au moment où le système a déterminé qu’une collision était imminente, la situation dépassait déjà les spécifications de réponse de son système de freinage.

La conception du véhicule excluait également le freinage d’urgence automatique destiné à atténuer une collision tant que le système en développement avait le contrôle. Elle reposait sur l’opérateur de sécurité humain, qui ne regardait pas la route et est intervenu trop tard.

Le NTSB a désigné comme cause probable le défaut de surveillance de l’environnement de conduite par l’opérateur, distrait. Il a aussi cité, parmi les facteurs contributifs, l’évaluation des risques insuffisante d’Uber, une supervision inefficace des opérateurs et des mesures insuffisantes contre l’excès de confiance. Enquête du NTSB.

Il est tentant de réduire un tel accident à une défaillance unique : l’IA n’a pas compris ce qu’elle voyait. Mais on passe alors à côté de la leçon d’ingénierie la plus utile.

La détection, la prédiction, la conception du freinage, la supervision et la gestion des risques par l’organisation ont toutes compté. Un système de sécurité ne vaut que par la manière dont ces responsabilités s’articulent.

Ce cas ne décrit pas toutes les machines autonomes modernes. Il montre en revanche pourquoi l’ensemble du système d’exploitation, et pas seulement le modèle d’IA, doit faire partie d’une évaluation de la sécurité.

Explorer les faits : la chronologie de l’accident qui accompagne cet article présente la séquence et les conclusions documentées par le NTSB. Ce n’est pas une reconstitution simulée de la collision.

Un plan intelligent a encore besoin d’un moyen sûr d’agir

Depuis des décennies, les robots industriels exécutent des tâches prédéfinies, souvent dans des espaces de travail délimités. L’IA physique élargit l’éventail des situations auxquelles les machines peuvent répondre.

Prenons un robot d’entrepôt qui manipule des colis arrivant dans des positions différentes. Ses capteurs recueillent des informations. Un contrôleur doté d’IA peut identifier un objet et proposer une façon de le saisir ou de le déplacer. Les moteurs et les autres systèmes de commande traduisent ensuite ce plan en mouvement.

Le plan peut être sensé alors que l’action physique ne l’est pas. Un employé peut s’engager sur la trajectoire. Un colis peut être plus lourd que prévu. Une caméra peut perdre la vue dégagée au pire moment.

C’est pourquoi la distinction entre proposer une action et laisser cette action atteindre la machine est importante.

Un contrôleur de protection peut limiter la vitesse, empêcher un mouvement vers une zone interdite ou commander un repli défini lorsque des informations nécessaires manquent. Les machines industrielles utilisent déjà des protections comme les dispositifs de verrouillage, les arrêts de protection et les limitations de vitesse. Les chercheurs étudient désormais comment des contrôles de sécurité plus adaptatifs peuvent fonctionner aux côtés de modèles d’IA appris.

Par exemple, les travaux de recherche SHIELD de 2025 ont exploré des contraintes de sécurité pour la locomotion des robots humanoïdes, avec notamment des expériences sur un robot Unitree G1. L’article de 2026 Verifiable Foundation Models for Robot Safety a examiné comment un composant de sécurité plus limité et vérifiable peut encadrer un contrôleur appris performant. Ce sont deux pistes de recherche utiles. Aucune ne démontre que tous les mouvements de tous les robots humanoïdes sont sûrs. SHIELD · Verifiable Foundation Models for Robot Safety.

Un composant distinct ne devient pas non plus une protection indépendante simplement parce qu’un schéma le présente ainsi. Si le planificateur et le contrôle de sécurité dépendent du même capteur défaillant, tous deux peuvent aboutir à la mauvaise conclusion. Si un robot ne peut pas s’arrêter assez vite, un avertissement logiciel correct peut arriver trop tard pour éviter le contact.

Quand j’examine cette architecture, je veux savoir ce que le système de protection peut réellement imposer, comment il se comporte quand d’autres composants tombent en panne et si ces affirmations ont été testées sur la machine elle-même.

Explorer le mécanisme : le module sur le contrôle de sécurité compare un mouvement normal, une obstruction inattendue et la perte des informations des capteurs. C’est un exemple pédagogique conceptuel, pas un simulateur physique ni une certification de sécurité.

Le vrai test commence hors de la simulation

La simulation est précieuse, car un robot peut y affronter virtuellement des situations difficiles avant que quiconque soit exposé à un risque. Les chercheurs peuvent faire varier les objets, les obstacles et les conditions de fonctionnement, et répéter les expériences de nombreuses fois.

Mais un robot simulé ne reproduit pas tous les détails d’un robot réel. Les frottements varient. Les charges se déplacent. Les capteurs deviennent bruités ou obstrués. L’usure mécanique et les latences influent sur la façon dont une machine réagit.

Un modèle peut identifier correctement une personne alors que le robot complet n’a toujours pas la distance ou la capacité de freinage nécessaires pour s’arrêter en toute sécurité.

Cet écart entre les performances expérimentales et le déploiement en pratique est l’une des raisons pour lesquelles le National Institute of Standards and Technology (NIST) américain met au point des méthodes pour mesurer et tester la robotique dotée d’IA dans l’industrie manufacturière. Le NIST identifie explicitement un écart entre la recherche sur l’IA incarnée et ce que les fabricants et les intégrateurs peuvent appliquer en toute confiance. Projet Physical AI du NIST.

L’ingénierie de la sécurité établie reste pertinente. ISO 10218-1:2025 traite de la sécurité des robots industriels. ISO 10218-2:2025 traite des applications de robots industriels et des cellules robotisées. Cette distinction a une portée pratique : même un robot doté de protections intégrées peut devenir dangereux une fois intégré avec des outils, des charges ou des aménagements de l’espace de travail inadaptés. Ces normes ne constituent pas une certification universelle pour tout véhicule, drone, robot de service ou dispositif médical. ISO, partie 1 · ISO, partie 2.

Je préfère une affirmation étroite et honnête (cette machine a été testée pour ces tâches, dans ces conditions, avec ces limites) à la promesse générale qu’un système est tout simplement « sûr ».

Le développement de l’IA physique en Inde : une orientation utile, mais des preuves encore attendues

L’activité récente de l’Inde offre un exemple intéressant d’une évolution plus large : séparer l’action intelligente de l’application des règles de sécurité.

En octobre 2026, Inner Sky Labs a présenté une plateforme modulaire comprenant des modèles de perception, d’action et de sécurité. L’architecture publiée décrit des modèles de perception visuelle, auditive et tactile. Des modèles destinés à planifier ou à anticiper des actions physiques. Et une famille de sécurité appelée Kavach qui, selon l’entreprise, peut évaluer les actions avant leur exécution. Inner Sky Labs.

Cette séparation mérite qu’on s’y arrête, car elle répond à une vraie question d’architecture : le système qui choisit un mouvement doit-il être aussi le seul à juger si ce mouvement est autorisé ?

Mais nous devons distinguer ce qu’une entreprise décrit de ce que des tests indépendants ont établi. Inner Sky Labs annonce pour Kavach v2 un score de sécurité des prompts de 1,00 et un score de sécurité des réponses de 0,91. Il s’agit d’affirmations de benchmark publiées par l’entreprise, portant sur la sécurité des instructions données à l’IA et de ses réponses. Ce ne sont pas des mesures de l’évitement des collisions d’un robot, de sa distance d’arrêt ou de sa force de contact. L’entreprise décrit des capacités multimodales plus larges pour la v3 et une incarnation physique pour la v4. Les documents publics examinés ici n’établissent pas de manière indépendante une certification complète de sécurité physique pour ces affirmations.

Texte alternatif accessible pour cette figure

Quatre bandes superposées reliées par des flèches. Perception, avec Drishti pour la vision, Shruti pour l’audio et Sparsh pour le toucher. Action et modélisation du monde, avec Kriya, Karma et Prana. Sécurité, avec Kavach, qui selon l’entreprise évalue les actions avant leur exécution. Les actionneurs du robot en bas.

Sous les bandes, deux colonnes. Déclaré par l’entreprise : scores de sécurité des prompts et des réponses de Kavach v2 issus d’un benchmark textuel, sans que l’évaluateur soit nommé. Non établi par les sources citées : une validation indépendante de la sécurité physique sur un robot, comme l’évitement des collisions, l’arrêt ou la force de contact.

Ce n’est pas une raison pour écarter ces travaux. C’est une raison de poser la question suivante : comment la protection proposée se comporte-t-elle sur du matériel réel quand une personne entre dans l’espace de travail, que la charge change ou qu’un capteur tombe en panne ?

L’activité de l’Inde ne se limite pas à une seule entreprise. L’IIT Roorkee et Avathon ont annoncé leur projet de laboratoire d’IA physique consacré à la recherche industrielle en 2026. C’est un investissement dans les compétences et la collaboration, et non, en soi, la preuve d’un système certifié et déployé. Annonce du gouvernement indien.

J’évaluerais les développements indiens, américains, européens et chinois selon le même critère : des capacités démontrées, des limites clairement énoncées et des preuves issues de l’environnement d’exploitation prévu.

Ce que je demanderais avant de faire confiance à la machine

La question n’est pas de savoir s’il faut développer des machines intelligentes. Il existe de bonnes raisons de concevoir des robots capables de s’adapter à des conditions changeantes, d’effectuer des travaux dangereux et de réduire les efforts physiques répétitifs.

La question est de savoir quelles preuves justifient leur déploiement.

Avant de faire confiance à un système d’IA physique sur un lieu de travail ou à proximité du public, je voudrais que trois points soient clairs.

Qu’a-t-il le droit de faire ? La machine a besoin de conditions d’exploitation définies et de limites applicables à son comportement. Ces limites peuvent porter sur l’espace de travail, la vitesse, la force, les tâches autorisées ou la proximité avec les personnes.

Que se passe-t-il quand quelque chose tourne mal ? Une réponse sûre doit être testée, et non supposée. S’arrêter immédiatement n’est pas toujours la bonne réponse : par exemple, couper brutalement l’alimentation d’une machine qui tient une charge suspendue peut introduire un autre danger.

Quelles preuves étayent l’affirmation ? J’attendrais des essais sur la machine réelle, avec des tâches représentatives, des résultats mesurés, des limites énoncées et une évaluation indépendante appropriée.

La responsabilité compte aussi. Le développeur du modèle, le fabricant du robot, l’intégrateur système et l’organisation exploitante peuvent contrôler des parties différentes du système. Leurs responsabilités ne peuvent pas se fondre dans une vague affirmation selon laquelle « l’IA » était aux commandes.

On ne peut pas non plus toujours considérer un opérateur humain comme un mécanisme de sécurité fiable de dernière seconde. En mars 2026, le NTSB a publié les conclusions de deux accidents mortels impliquant Ford BlueCruise, un système d’automatisation partielle de la conduite qui exige un conducteur attentif. Les enquêtes ont relevé, entre autres problèmes, une confiance excessive dans le système et les limites de la surveillance du conducteur. BlueCruise n’est pas un système entièrement sans conducteur, mais ces conclusions soulignent l’importance de concevoir une supervision humaine réaliste. Conclusions du NTSB sur BlueCruise.

L’IA physique va continuer à progresser. Des modèles plus performants, de meilleurs capteurs et de nouvelles méthodes de commande peuvent tous y contribuer. Mais la confiance devrait croître avec les preuves, et non avec des démonstrations toujours plus soignées.

Dans l’informatique d’entreprise, un logiciel qui fonctionne n’est que le début d’une discussion sur la préparation à la production. Avec l’IA physique, cette distinction devient encore plus importante, car une erreur peut déjà avoir des conséquences avant que quiconque puisse revenir en arrière.

L’intelligence élargit ce qu’une machine peut tenter. L’ingénierie et les preuves déterminent ce qu’on devrait lui confier.

Sources et lectures complémentaires

Sources examinées jusqu’au 15 octobre 2026. Chaque source a été ouverte et vérifiée le 15 octobre 2026. Les descriptions et les affirmations de benchmark de l’entreprise sont rapportées telles qu’elle les publie et n’ont pas été vérifiées de manière indépendante.

1. NTSB: Uber developmental automated-driving collision investigation. Enquête sur la collision de mars 2018 à Tempe, en Arizona.
2. NTSB: Ford BlueCruise partial-automation investigations, March 31, 2026. Communiqué de presse sur deux accidents mortels impliquant un système d’automatisation partielle de la conduite.
3. NIST: Physical AI and Data Generation for Robotics. Page du projet du NIST.
4. SHIELD: Safety on Humanoids via CBFs in Expectation on Learned Dynamics. Article de recherche.
5. Verifiable Foundation Models for Robot Safety. Prépublication de recherche.
6. ICML 2026: Position: Modular Safety Guardrails Are Necessary for Foundation-Model-Enabled Robots in the Real World. Article de position.
7. ISO 10218-1:2025. Robotique, exigences de sécurité, partie 1 : robots industriels.
8. ISO 10218-2:2025. Robotique, exigences de sécurité, partie 2 : applications robotiques industrielles et cellules robotisées.
9. Inner Sky Labs: Modular Physical AI Platform. Descriptions et affirmations de benchmark de l’entreprise.
10. Government of India: IIT Roorkee and Avathon Physical AI Lab. Annonce, par le Press Information Bureau, du projet de laboratoire.