Avant que vos agents ne touchent aux moteurs : le dossier de sécurité d’un CTO pour l’IA‑vers‑I/O

Anthropic vient de présenter un standard matériel qui permet à des agents IA de contrôler le monde physique. C’est le moment qu’attendaient beaucoup d’équipes — « enfin, notre robot d’entrepôt peut appuyer sur le vrai bouton ». C’est aussi le moment où beaucoup de CTO vont se faire mal. Ici, le mode de défaillance n’est pas une UI cassée ; c’est une palette au sol, une pompe qui tourne à sec, ou un procès.

Si vous allez connecter des agents à de l’I/O — relais, moteurs, vannes — il vous faut un dossier de sécurité, pas une démo. Ce post vous donne un cadre de décision pour tracer la frontière entre autonomie et contrôle, câbler trois interverrouillages indépendants, budgéter correctement la latence, tester sur jumeau avant de toucher au métal, et livrer une piste d’audit inviolable. Nous resterons agnostiques vis‑à‑vis des fournisseurs, tout en reconnaissant la réalité : vous devrez faire le pont entre des piles agents modernes (MCP, ROS 2, gRPC) et des technos d’atelier anciennes mais fiables (OPC UA, Modbus/TCP, EtherCAT, automates de sécurité).

La frontière qui vous sauve : agent vs contrôleur

La plupart des équipes ratent l’architecture en laissant l’agent « conduire » directement l’installation. Ne le faites pas. L’agent propose ; un contrôleur certifié dispose. Cette frontière est votre ligne de sécurité juridique, opérationnelle et morale.

Représentez‑la ainsi :

• Couche agent (non certifiée, adaptative) : planifie des tâches et propose des intentions comme « déplacer le convoyeur A à 40 % pendant 12 secondes » ou « ouvrir la vanne d’admission B jusqu’à ce que le niveau atteigne 70 % ». Elle ne bascule jamais un GPIO et n’écrit jamais directement sur une bobine.
• Enveloppe de commande (déterministe, filtrable) : valide, façonne et limite le débit des intentions. Pensez‑y comme à un noyau de l’actionnement : sensible aux unités, vérifiée sur les bornes, limitée en jerk. Si l’enveloppe ne peut pas prouver la sécurité, elle refuse la commande.
• Contrôleur d’installation (certifié, temps réel) : un PLC/variateur/contrôleur de robot manipule effectivement moteurs et vannes. Il applique des interverrouillages et invariants durs à des cadences milliseconde et bascule en état sûr en cas de perte de communication.

Les agents vivent en dehors de la frontière de sécurité. Votre contrôleur et votre système de sécurité vivent à l’intérieur. C’est la ligne que vos juristes, vos auditeurs et votre équipe opérations peuvent défendre.

Rendez les contraintes de sécurité exécutables

Les politiques doivent être dans le code, pas dans un PDF. Vous avez besoin d’invariants vérifiables par machine dans le chemin de commande — avant que les commandes n’atteignent un PLC. Exemples :

• Exclusion mutuelle : « Les contacteurs avant et arrière du moteur M ne doivent jamais être alimentés simultanément. »
• Limites de vitesse/variation : « Modifier la vitesse du convoyeur de ≤10 % par seconde ; maximum absolu 60 % en zones mixtes avec humains. »
• Garde‑fous d’état : « N’ouvrez pas la vanne B sauf si la pression P < 1.2 bar et la température T < 40 °C. »
• Limites d’énergie : « La vitesse TCP du robot doit rester ≤250 mm/s tant que la zone 2 du scanner de sécurité est occupée. »

Représentez les contraintes sous forme d’un ensemble de règles métier compilées en vérifications à l’exécution. Vous n’avez pas besoin de méthodes formelles pour démarrer ; une enveloppe sûre peut être imposée avec des diagrammes d’états (statecharts) et une poignée de prédicats. Mais traitez‑la comme un contrôleur : écrivez des tests de propriétés, fuzzez les discontinuités et prouvez la monotonie lorsque c’est possible.

Trois interverrouillages, voies indépendantes

Dire « on a un arrêt d’urgence » ne suffit pas. Vous voulez des défenses redondantes et diversifiées pour qu’une seule classe de bug ne vous mette pas à terre.

1) Barrière de politique (qui peut faire quoi)

• Listes d’autorisation plutôt que des prompts : l’agent ne peut invoquer que des compétences nommées avec des arguments typés. Pas de chaînes d’actionnement en texte libre.
• RBAC + bornes temporelles : certaines compétences (p. ex., « ouvrir la vanne caustique ») exigent des rôles élevés et une approbation explicitement limitée dans le temps. Imposez une règle des deux personnes pour les changements de politique.
• Budgets de commandes : par quart ou par recette, plafonnez le nombre d’actionnements à risque et le facteur de marche (duty cycle). Vous devez pouvoir répondre : « Combien de fois avons‑nous ouvert cette vanne au cours des dernières 24 h ? »

2) Barrière physique (l’enveloppe)

• Commandes vérifiées en unités et limitées en jerk : les commandes portent leurs unités et sont automatiquement façonnées (p. ex., profils en S) pour éviter les transitoires.
• Vérification d’invariants avec corroboration capteurs : l’enveloppe refuse d’avancer si les capteurs requis sont dégradés, obsolètes ou contradictoires.
• Watchdog + horizon borné : les intentions de l’agent doivent avoir une condition de fin claire. Si elle n’est pas satisfaite, l’enveloppe annule et revient à un état connu.

3) Barrière procédé (PLC/relais de sécurité)

• Arrêts d’urgence câblés et scanners de sécurité : circuits de catégorie 3/4 selon ISO 13849, câblage en normalement fermé, et relais de sécurité qui se désénergisent vers un état sûr.
• Safe Torque Off (STO) : pour les variateurs et robots, utilisez les fonctions IEC 61800‑5‑2 lorsque disponibles.
• Watchdog à horloge indépendante : si le contrôleur manque un battement (p. ex., 100 ms) en provenance de l’enveloppe, il bascule en état sûr — sans excuses.

Ces voies doivent être technologiquement diverses lorsque c’est praticable : une couche de politique LLM peut tomber indépendamment d’un bug de firmware PLC ou d’un relais de sécurité soudé fermé.

Des budgets de latence qui n’exposeront personne au danger

L’actionnement n’est pas une complétion de chat. Mettez des chiffres dessus, ou n’expédiez pas.

• Contrôleurs en boucle fermée : boucles de 1–5 ms pour le mouvement servo ; 5–20 ms pour une logique PLC typique. Ce n’est pas le territoire des agents.
• Logistique à l’échelle humaine : convoyeurs et pick‑lights : 50–200 ms aller‑retour est acceptable. Votre enveloppe + PLC doivent maintenir la gigue totale en dessous.
• Réalités réseau : les allers‑retours OPC UA sur LAN sont souvent de 5–15 ms ; les RTT inter‑régions cloud peuvent être de 60–120 ms avec de grosses queues. Ne placez jamais une décision critique de sécurité à travers un WAN.
• Battements (heartbeats) et temporisations : heartbeat de 100 ms de l’enveloppe vers le PLC ; timeout de 300–500 ms pour passer en état sûr. Journalisez dans les deux sens.

Règle empirique : gardez l’enveloppe et le contrôleur d’installation co‑localisés en edge. Les agents peuvent être dans un back‑office ou sur un nœud edge proche, mais les dernières 10 ms de contrôle ne doivent pas traverser l’Internet public.

« Human in the loop » n’est pas une stratégie de sécurité

HITL est une couche de gouvernance, pas une boucle de contrôle. Un humain ne peut pas confirmer de manière fiable à 200 ms de cadence que des commandes ne violeront pas une limite de pression. Utilisez la revue humaine pour la politique (p. ex., « approuver un changement de recette ») et pour l’intention (p. ex., « planifier après le quart »), pas pour marteler des boutons vers la sécurité.

Testez comme dans l’aérospatial : SIL, HIL et jumeaux

N’apprenez pas sur l’installation réelle. Utilisez :

• Software‑in‑the‑loop (SIL) : simulez la logique PLC, le code d’enveloppe et les plans de l’agent contre un modèle d’installation. Pour la robotique, ROS 2 + Gazebo ou Webots ; pour les PLC, des simulateurs éditeurs (PLCSIM, CODESYS) ou un serveur OPC UA mocké.
• Hardware‑in‑the‑loop (HIL) : contrôleurs réels câblés à une installation simulée via des émulateurs d’I/O. Validez les watchdogs, le STO et les chaînes d’urgence. Prouvez que le système échoue en sûreté quand vous tirez les câbles.
• Jumeaux numériques avec injection de fautes : scénarisez des cas comme « vanne bloquée » ou « dérive capteur ». Traitez « capteur obsolète > 200 ms » comme une faute de première classe, pas un cas limite.

Rendez le critère de sortie explicite : « Aucune commande n’atteint un actionneur réel si elle n’a pas passé des tests SIL couvrant 95 % de l’espace d’états atteignable et des tests HIL pour tous les dangers de Catégorie A. »

SIL, pas du ressenti : quel standard visez‑vous ?

Si vous êtes dans des industries réglementées, vos auditeurs parlent IEC 61508/61511 (procédés), ISO 13849 (machines), ou UL 4600 (autonomie). Vous n’avez pas besoin de certifier l’agent, mais vous devez faire correspondre votre enveloppe et vos barrières procédé aux niveaux de sécurité requis (SIL/PL).

• Cibles en mode continu (IEC 61508 PFHd) : SIL 1 : 1e‑6–1e‑5 défaillances dangereuses/heure ; SIL 2 : 1e‑7–1e‑6 ; SIL 3 : 1e‑8–1e‑7. La plupart des brownfields en logistique viseront SIL 1–2 pour des fonctions de sécurité spécifiques.
• Les diagnostics comptent : on élève PL/SIL non seulement avec du matériel plus robuste, mais aussi avec une meilleure couverture de diagnostics et des intervalles de test adaptés. Les auto‑tests de votre enveloppe comptent.
• Documentez le dossier sécurité : analyse de dangers (HAZOP/STPA), allocation des exigences de sécurité, matrice de vérification, et éléments de preuve. Le « ressenti » ne passe pas les audits.

Contrats de commande : intentions, acquittements et effets mesurés

Chaque actionnement doit être traçable de l’intention à l’effet mesuré avec des acquittements explicites en chemin :

1. Intention créée : l’agent propose Actuate(ConveyorA, speed=0.4, duration=12s)
2. Acceptation/refus par l’enveloppe : validée, façonnée vers un profil sûr, ou rejetée avec motif
3. Acquittement du contrôleur : le PLC a accepté ou refusé ; journalisez le chemin de code
4. Clôture par télémétrie : les capteurs confirment l’état désiré (p. ex., capteur de vitesse ~0.4 dans la tolérance). Si non atteint en T secondes, ouvrez un incident et revenez à un état sûr

Les commandes qui n’aboutissent pas à un effet mesurable et opportun ne sont pas « terminées ». Ce sont des anomalies, et elles alimentent vos métriques MTTR et incidents.

Un audit que vous pouvez défendre devant un tribunal

Quand quelque chose tourne mal, vous n’argumenterez pas avec un ingénieur ; vous argumenterez avec un assureur ou un régulateur. Vos journaux doivent être inviolables et complets :

• Stockage en écriture seule (append‑only) : seaux WORM ou journal chaîné par Merkle par nœud edge. Hashez des instantanés vers un système séparé toutes les N minutes.
• Télémétrie haute résolution : capture à 50–100 Hz pour les capteurs/actionneurs pertinents pendant les jobs actifs. Plus grossière à l’arrêt pour maîtriser les coûts.
• Rejouabilité : étant donné un segment de log, vous pouvez reconstruire la décision de l’enveloppe, le chemin du programme PLC et l’état résultant de l’installation.
• Attribution : signez les binaires de l’agent et de l’enveloppe, enregistrez la version du modèle/hash des poids, la version du catalogue de compétences et le checksum du firmware PLC pour chaque exécution.

Intégration brownfield sans illusions

Votre atelier parle probablement OPC UA, Modbus/TCP, Profinet, EtherNet/IP, ou EtherCAT. Votre pile agent parle probablement gRPC ou ROS 2 (DDS). N’imposez pas un recâblage juste pour être « moderne ».

• Faites un pont, ne réécrivez pas : construisez une passerelle fine et testable qui traduit des intentions typées en appels au contrôleur. Limitez sa responsabilité à la sérialisation, la synchronisation temporelle et les réessais.
• Discipline d’horloge : utilisez PTP ou au minimum NTP avec supervision ; votre enveloppe et votre PLC doivent s’accorder à quelques millisecondes près.
• Dégradation maîtrisée : en cas de partition réseau, le contrôleur continue d’exécuter la dernière recette sûre ou passe à un idle sûr. L’agent ne dispose pas d’un droit de veto.

Organisation : séparez la curiosité du contrôle

La loi de Conway est un risque pour la sécurité. Si la même équipe qui ajuste les prompts peut pousser du code côté installation, vous livrerez une démo en production. Fixez des frontières :

• Responsable sécurité : un propriétaire unique, redevable de l’enveloppe et des barrières procédé. Traitez‑le comme un « SRE pour la physique ».
• Gestion des changements : règle des deux personnes pour les changements de politique de sécurité ; simulateurs de production pour les répétitions à blanc ; chaque changement a un diff de dangers.
• Exercices de red team : trimestriellement, coupez des liens réseau, fautez des capteurs et injectez de mauvaises intentions. Mesurez détection et temps de reprise.

Si vous avez besoin rapidement d’expertise métier, des équipes de mécatronique nearshore peuvent faire la différence. Brazil forme à lui seul des milliers d’ingénieurs en contrôle et en électricité chaque année et dispose d’un vivier profond d’intégrateurs PLC grâce à sa base industrielle. Avec 6–8 heures de recouvrement horaire, un pod nearshore brésilien peut câbler des passerelles OPC UA, construire la bibliothèque d’invariants de votre enveloppe et livrer des bancs de test HIL 20–30 % moins chers qu’aux États‑Unis — sans douleur de fuseaux horaires.

Acheter vs. construire : là où se trouve l’effet de levier

Construisez l’enveloppe ; achetez le reste quand c’est sensé.

• Acheter : PLCs/relais de sécurité et variateurs avec STO ; barrières immatérielles/scanners ; adaptateurs fieldbus ; serveurs OPC UA supportés par les éditeurs ; passerelles d’accès distant sécurisé.
• Construire : enveloppe de commande spécifique au domaine avec invariants ; modèles de simulation et harnais HIL ; barrière de politique et pipeline d’audit ; catalogue de compétences typé avec signatures.
• Réutiliser : ROS 2 pour le middleware robotique ; OPC UA pour les modèles d’information ; protobuf/gRPC pour les définitions de compétences ; programmes d’atelier existants avec logique bien testée.

Un plan pratique sur 90 jours

Jours 0–30 : tracez la frontière et simulez

• Inventoriez actionneurs et dangers ; rédigez un résumé d’une page des dangers (top 10 des modes de défaillance).
• Définissez 10–20 invariants comme code dans une enveloppe stub ; branchez‑la à un simulateur (Gazebo/Webots/PLCSIM/OPC UA mocké).
• Mettez en place une journalisation en append‑only avec attestation de modèle/version.
• Décidez du placement edge ; provisionnez un PC industriel avec double NIC et synchro temporelle PTP.

Jours 31–60 : câblez des contrôleurs et interverrouillages réels

• Intégrez avec un vrai PLC sur banc (HIL). Prouvez le comportement des watchdogs et du STO en tirant des câbles.
• Mettez en œuvre la barrière de politique : compétences sur liste d’autorisation, RBAC, approbations limitées dans le temps.
• Écrivez 20–30 tests SIL et 10 scénarios HIL d’injection de fautes. Ne touchez pas encore au matériel de production.

Jours 61–90 : pilote dans une cellule isolée

• Déployez dans une cellule unique, clôturée, avec arrêts d’urgence matériels et scanners de sécurité.
• Faites tourner des quarts supervisés avec des agents qui proposent des intentions ; l’enveloppe exécute sous budgets stricts.
• Collectez 2–4 semaines de journaux, affinez les invariants et publiez un dossier de sécurité v1 couvrant le périmètre du pilote.

Ce que le mouvement d’Anthropic change réellement

Le « standard matériel pour agents » d’Anthropic est un signal positif : l’écosystème reconnaît le besoin d’un plan de contrôle commun entre l’IA et l’I/O. Profitez‑en — mais ne relâchez pas vos frontières. Une API de compétences standard ou un hub GPIO n’éliminent pas le besoin de votre enveloppe, de vos interverrouillages ou de votre piste d’audit. Si quelque chose, cela facilite votre travail : vous pouvez concentrer vos efforts d’ingénierie sur le dossier de sécurité plutôt que sur la colle des pilotes.

Histoires d’échec que vous pouvez éviter

• Le watchdog optimiste : une startup laissait le PLC supposer que l’enveloppe était vivante sauf indication contraire ; un processus planté a laissé tourner une pompe. Inversez cela : par défaut, passez en sûr sur battements manqués.
• La contrainte invisible : une équipe « savait » que deux vannes ne devaient pas être ouvertes ensemble mais ne l’a jamais encodé ; un agent a « optimisé » le temps de cycle et a mélangé des réactifs. Si c’est important, c’est un invariant.
• Le réflexe cloud : un robot logistique dépendait d’une étape d’approbation de plan inter‑régions ; une panne de 40 secondes a stoppé une ligne et dérouté les opérateurs. Gardez la sécurité et les décisions à court horizon en local.

La voie ennuyeuse est la voie rapide

Les CTO se mettent en difficulté en poursuivant des commandes « novatrices » quand une commande ennuyeuse — avec de la vraie ingénierie de sécurité — aurait livré plus vite et gardé l’atelier en marche. Votre agent n’a pas besoin d’être un virtuose des bobines Modbus. Il doit être un bon citoyen qui propose des intentions claires, accepte gracieusement les refus et laisse la partie difficile — la sécurité temps réel — aux systèmes faits pour cela.

Points clés

• Tracez une frontière dure : les agents proposent des intentions ; des contrôleurs certifiés exécutent dans une enveloppe de sécurité codée.
• Mettez en œuvre trois interverrouillages indépendants : barrière de politique, barrière physique (enveloppe) et barrière procédé (PLCs/arrêts d’urgence/STO).
• Budgétez la latence de manière réaliste : gardez l’enveloppe et les contrôleurs en edge ; ne mettez jamais des décisions de sécurité sur un WAN.
• Testez avant de toucher au métal : SIL pour la couverture logique, HIL pour les watchdogs/interverrouillages réels, et jumeaux avec injection de fautes.
• Rendez les contraintes de sécurité exécutables : encodez des invariants (exclusion mutuelle, limites de variation, gardes d’état) et refusez les commandes invérifiables.
• Livrez une piste d’audit défendable : journaux append‑only, télémétrie à haut taux pendant les jobs, attribution complète des modèles et firmwares.
• Organisez‑vous pour la sécurité : équipes séparées pour les agents et le contrôle d’installation ; règle des deux personnes pour les changements de politique ; « red‑teamez » votre physique.
• Construisez l’enveloppe, achetez le matériel de sécurité, et pontez vers les standards brownfield comme OPC UA et ROS 2.
• Des pods nearshore de mécatronique au Brazil peuvent accélérer les passerelles OPC UA, les invariants et les bancs HIL avec 6–8 heures de recouvrement horaire et 20–30 % de coût en moins.