Les agents d’IA ne sont pas prêts à gérer les infrastructures

La capacité du modèle n’est pas la question principale

Je ne placerais pas la capacité du modèle au premier plan. En novembre 2026, le frein aux agents d’IA dans l’énergie, l’eau et le ferroviaire est d’abord un problème d’ingénierie : comment prouver la sûreté de chaque action. Le projet Cyber AI Profile du NIST relie la gestion des risques liés à l’IA aux pratiques informatiques, OT, de contrôle industriel et de cybersécurité.

C’est là que la situation devient inconfortable. Un agent qui accède à un système de supervision ne reçoit pas seulement un nouvel outil : il obtient un nouveau chemin vers un processus physique. L’injection de prompt, une télémétrie empoisonnée, un capteur compromis ou une instruction malveillante destinée à un outil peuvent transformer une réponse plausible en commande dangereuse.

L’hallucination n’est qu’une catégorie de défaillance. Il faut aussi compter avec des données obsolètes ou contradictoires, la perte de capteurs, des modes de fonctionnement rares, des délais de réaction stricts et les changements de comportement du modèle après une mise à jour. Un benchmark ordinaire de modèle de langage ne prouve pas qu’un système se comportera correctement lors d’une urgence ou d’une attaque.

C’est pourquoi une architecture raisonnable reste pour l’instant ennuyeuse, et c’est un compliment. L’agent agit comme conseiller, tandis qu’une logique de sécurité déterministe vérifie la recevabilité des commandes. L’accès aux outils est limité par des listes d’autorisation et le principe du moindre privilège, les réseaux sont segmentés et les actions critiques sont confirmées par un opérateur qualifié.

Il faut également des journaux infalsifiables pour les données d’entrée, les appels d’outils, les validations et les commandes exécutées. Sans retour arrière, état sûr et contrôle manuel, l’autonomie revient à parier qu’un scénario inhabituel ne se produira jamais.

Un humain dans la boucle ne règle pas la responsabilité

La présence d’un humain dans la boucle ne résout pas automatiquement le problème. Face à une avalanche d’alertes, un opérateur peut se fier à une formulation assurée, manquer de contexte ou ne pas avoir le temps d’intervenir. La supervision doit donc offrir un véritable droit de refuser l’action, des preuves compréhensibles et un mode manuel entraîné.

La fracture juridique est tout aussi grave. Après un accident, la responsabilité peut être répartie entre l’exploitant d’infrastructure, l’intégrateur, le fournisseur du modèle, le développeur logiciel, le sous-traitant et un salarié précis. Tant que les rôles ne sont pas fixés à l’avance, l’enquête risque de débattre de l’auteur de la défaillance plutôt que de sa cause.

La limite est assez nette selon les secteurs. Dans les réseaux électriques, l’agent est utile pour la prévision et le diagnostic ; dans l’eau, pour l’analyse de la maintenance et de la qualité des processus ; dans le rail, pour les horaires, la priorisation des réparations et l’analyse des incidents. En revanche, agir sur les réglages de protection, le dosage, la pression, le routage ou l’autorisation de mouvement exige des garanties dignes de composants critiques pour la sûreté, et non une belle précision sur un jeu de données général.

Ma conclusion est simple : il ne s’agit pas d’interdire l’IA, mais d’interdire un pouvoir sans limites vérifiables. Le composant le plus difficile de cet agent n’est probablement pas le modèle, mais le système de responsabilité qui l’entoure.

Nous avons déjà expliqué comment les attaques par homoglyphes Unicode peuvent tromper des agents d’IA et les amener à suivre des liens d’hameçonnage ou à exécuter des commandes malveillantes. Ces vecteurs d’attaque sont particulièrement importants lorsque les agents opèrent dans des environnements d’infrastructures critiques.