Un agent IA peut-il piloter un robot industriel en toute sécurité ?

En bref : Un agent d’IA peut proposer des tâches, expliquer des alarmes et assister les opérateurs, mais sa sortie ne doit jamais remplacer la commande déterministe, les fonctions de sécurité ni l’évaluation des risques de la machine.

Pourquoi une réponse fluide n’est pas un signal de commande

Un grand modèle de langage produit la suite la plus plausible de son entrée. Une même demande peut donner des sorties différentes, le temps de réponse n’est pas borné et une réponse formulée avec assurance peut être fausse. Le mouvement d’un robot exige les propriétés inverses : la même entrée doit produire le même comportement, vérifiable et dans un délai connu. La question est donc de savoir sur quelles décisions un agent peut influer et quel mécanisme vérifie chacune d’elles.

Donnez à l’agent une autorité limitée et explicite

Un rôle défendable pour un agent consiste à classer une demande, à choisir parmi des recettes approuvées à l’avance, à préparer un jeu de paramètres ou à expliquer une alarme. Entre l’agent et la machine se trouve une couche d’autorisation qui est un logiciel ordinaire et testable : elle vérifie qui fait la demande, si l’opération figure sur la liste des actions autorisées, si chaque paramètre reste dans des limites validées et si la cellule se trouve dans un état et un mode de fonctionnement où la demande est admise. Tout ce qui échoue à une vérification est rejeté et consigné ; ce n’est jamais « interprété ». L’agent propose ; il n’écrit jamais directement dans le contrôleur du robot ni dans l’automate programmable (PLC).

Gardez la commande et la sécurité déterministes

L’automate et le contrôleur du robot restent responsables des séquences, des verrouillages, du mouvement, des temporisations et de la reprise après défaut, comme dans une cellule sans IA. Les fonctions de sécurité – arrêt d’urgence, verrouillage des protecteurs, limitation de vitesse et d’espace – sont réalisées par du matériel et du logiciel de sécurité dont les performances requises découlent de l’évaluation des risques de l’application concernée. L’ISO 10218-2 est la norme internationale qui fixe les exigences de sécurité pour les applications robotisées et les cellules robotisées ; cet article ne les reproduit pas. Aucun texte généré n’est une entrée de ces fonctions, et aucun agent ne peut les neutraliser, les contourner ni les reconfigurer. Si l’ajout de l’agent modifie la façon dont les personnes interagissent avec la cellule, l’évaluation des risques doit être revue par ceux qui en sont responsables ; l’agent n’abrège pas ce travail.

Traitez les prompts, les documents et les outils comme des entrées non fiables

Un agent lit du texte que personne dans le projet n’a écrit : pages web, courriels, entrées de journal, notes des opérateurs. Chacun de ces contenus peut contenir des instructions, par accident ou délibérément ; c’est ce qu’on appelle l’injection de prompt. Partez du principe que cela arrivera : séparez le contenu récupéré des commandes authentifiées, donnez à l’agent le moins d’outils possible, exigez qu’une personne désignée approuve chaque étape lourde de conséquences et consignez chaque proposition avec la décision de la couche d’autorisation. Testez ensuite les cas de défaillance avant tout essai sur un équipement réel : valeurs de capteur périmées, commandes en double, cibles mal formées, perte du réseau, objectifs contradictoires et intervention d’une personne en cours de cycle. Pour chacun, écrivez le rejet ou le comportement de repli attendu, et pas seulement le déroulement sans erreur.

Liste de contrôle avant d’engager un budget ou un périmètre

• Une liste écrite de ce que l’agent peut proposer et de ce qu’il ne peut jamais faire.
• Une couche d’autorisation entre l’agent et l’automate : identité, liste des actions autorisées, limites de paramètres et vérifications d’état.
• Des fonctions de sécurité réalisées et validées indépendamment de tout composant d’IA.
• Un comportement défini lorsque l’agent est lent, indisponible ou se trompe : temporisations, comportement de repli et autorité de l’opérateur.
• Des tests d’injection et des tests de commandes mal formées, exécutés d’abord en simulation ou sur un contrôleur déconnecté.
• Un journal d’audit des propositions, des approbations et des rejets, avec un responsable désigné qui le relit.

Ce que ce guide n’établit pas

Ceci est une aide à la planification. Ce n’est ni un rapport d’essai, ni une validation de sécurité, ni un avis juridique, ni une certification de produit, et cela ne remplace pas l’évaluation des risques de votre machine. Le cadre de gestion des risques liés à l’IA du NIST est un guide d’application volontaire, pas une norme de sécurité des machines. L’architecture et les fonctions de sécurité d’une cellule réelle doivent être conçues et validées par les personnes compétentes qui en sont responsables.

Sources et vérifications complémentaires

• ISO — ISO 10218-2:2025, Robotics — Safety requirements — Part 2: Industrial robot applications and robot cells (norme sur les applications et cellules robotisées ; 2025-02 ; consulté le 2026-10-11).
• NIST — AI Risk Management Framework (AI RMF 1.0), Core: Govern, Map, Measure, Manage (cœur du cadre de gestion des risques liés à l’IA ; 2023-01 ; consulté le 2026-10-12).
• OSHA — Robotics: Overview (vue d’ensemble sur la robotique et la sécurité au travail ; non daté ; consulté le 2026-10-12).

Prochaine étape utile

Si vous envisagez d’ajouter une couche d’IA à une cellule existante ou en projet, commencez par rédiger la liste des propositions autorisées et les vérifications associées à chacune, puis apportez-la, avec votre liste d’interfaces, sur la page Robotique et automatisation. Les projets qui partent de là sont cadrés et réalisés par l’intermédiaire d’Eurobots/ReBots, et ils commencent par la faisabilité et les limites de responsabilité, non par une installation clés en main supposée acquise. Le portfolio AYXWORKS présente le parcours d’ingénierie qui sous-tend ces guides.