Model Hardware Standard d’Anthropic : comment MHS permet aux agents IA de piloter du matériel et en quoi il diffère de MCP

Le 27 août 2026, Anthropic a ouvert un research preview du Model Hardware Standard (MHS), une spécification commune visant à permettre aux agents IA de découvrir, décrire et exploiter plus sûrement des équipements physiques programmables.^[1]

MHS est né d’une collaboration entre Anthropic et HHMI Janelia Research Campus. Les premiers projets ont connecté des microscopes, liquid handlers, bras robotiques, lecteurs de plaques et des composants du système laser d’un ordinateur quantique.^[1]

Jusqu’à présent, la majorité des agents populaires travaillaient surtout dans le monde numérique :

fichiers
repositories
terminal
APIs
navigateur
bases de données
systèmes SaaS

MHS cherche à standardiser une nouvelle couche :

capteurs
caméras
microscopes
robots de laboratoire
bras robotiques
lasers
équipements de mesure
équipements de production

Il ne faut toutefois pas résumer l’annonce par « Claude peut désormais contrôler n’importe quelle machine ». MHS est actuellement un research preview limité, accessible sur candidature, et le standard n’est pas encore publié en open source. Anthropic prévoit de l’ouvrir après la phase de preview et des travaux supplémentaires sur la sécurité, mais au 30 août aucune date publique ni licence future n’est annoncée.^[1][2]

MHS n’est pas non plus un nouveau modèle IA et ne remplace pas le Model Context Protocol (MCP). Anthropic le décrit comme model-agnostic. MCP est l’un des trois mécanismes de contrôle prévus, avec le CLI et les fichiers de code/APIs.^[1]

Conclusion principale : MHS n’est ni « MCP 2.0 » ni un robot. C’est une tentative de créer une couche commune de drivers, de description des équipements et de limites physiques de sécurité, afin qu’un agent puisse exploiter plusieurs machines par une interface plus cohérente.

État des informations : 30 août 2026.

TL;DR

Question	Réponse vérifiée
Qu’a annoncé Anthropic ?	Un research preview de Model Hardware Standard
Quand ?	27 août 2026
Qu’est-ce que MHS ?	Une spécification commune et une couche de drivers pour le matériel programmable
Est-ce un nouveau modèle Claude ?	Non
Est-ce déjà open source ?	Non
Anthropic prévoit-il l’open source ?	Oui, après la preview et les travaux de sécurité
Une date est-elle connue ?	Non
Une licence future est-elle connue ?	Non dans les sources officielles vérifiées
MHS remplace-t-il MCP ?	Non
Quel rôle joue MCP ?	Un des mécanismes de contrôle du matériel MHS
Autres mécanismes	CLI et fichiers code/API
Fonctionne-t-il seulement avec Claude ?	Non, Anthropic le décrit comme model-agnostic
Quels équipements ?	Matériel à interface programmable ; pilotes en laboratoire et robotique
Meilleure métrique publique	QuEra : 695/700 relocks laser réussis, 99,3 %
Benchmark indépendant ?	Non, résultat d’un pilote partenaire
Risque principal	Une erreur d’agent peut avoir des conséquences physiques
Principe de sécurité	Limites et interlocks doivent être imposés hors du modèle

Qu’est-ce que le Model Hardware Standard ?

Anthropic définit MHS comme une shared specification for AI agents to safely operate physical devices.^[1]

Le problème visé est classique : un laboratoire ou une usine utilise des équipements de plusieurs fournisseurs avec SDK, API, formats de données, logiciels et modèles d’erreur différents.

Créer un workflow commun impose souvent du glue code spécifique.

Anthropic affirme que ces intégrations peuvent prendre des semaines ou des mois et que MHS peut réduire une partie du travail à quelques heures ou minutes.^[1] Cette affirmation reste une déclaration du fournisseur, pas un benchmark indépendant de l’ensemble du secteur.

MHS n’est ni un robot ni un modèle

MHS n’est pas :

• un nouveau modèle Claude,
• un système d’exploitation robotique,
• un nouveau type de robot,
• un remplacement du firmware,
• un algorithme autonome de motion planning,
• un protocole industriel remplaçant les systèmes de contrôle existants.

Il est plus juste de le voir comme une couche d’interopérabilité entre un agent et du matériel physique programmable.

Un agent a toujours besoin d’un modèle, d’un harness ou d’une application, de permissions, d’un driver, de l’interface du matériel et de protections physiques indépendantes.

Comment fonctionne MHS ?

3.1. Driver standardisé

MHS introduit un driver standardisé qui traduit les opérations entre l’ordinateur et l’équipement.^[1]

Anthropic cite des primitives simples :

read
write

par exemple :

read temperature
write temperature

Cela ne signifie pas qu’un appareil ne dispose que de deux commandes. Des fonctions complexes peuvent être construites sur des primitives communes.

3.2. Description standardisée du matériel

MHS rend les équipements discoverable dans un format commun afin que des agents ou d’autres machines puissent les trouver sur le réseau et comprendre leurs capacités.^[1]

La description peut indiquer :

• ce que l’équipement mesure,
• ce qui peut être modifié,
• des caractéristiques physiques,
• les contraintes importantes,
• les limites de sécurité imposées.

Anthropic cite le poids d’un bras robotique comme exemple d’information utile à une manipulation sûre.^[1]

3.3. Tags en langage naturel

L’utilisateur peut décrire les propriétés importantes par des tags en langage naturel, directement ou via un agent qui l’interroge sur le setup.^[1]

Le driver produit ensuite un fichier de référence décrivant caractéristiques, mesures, paramètres et limites.

Le billet public n’est pas une spécification complète du schéma. Tant que MHS reste en preview limitée, il faut éviter d’inventer des noms de champs ou une syntaxe prétendument officielle.

Trois mécanismes de contrôle

Anthropic en décrit trois :^[1]

1. MCP
2. CLI
3. code files / APIs

MCP

Un agent peut piloter le matériel par Model Context Protocol. Les serveurs MCP peuvent exposer des tools, fonctions exécutables qu’un modèle peut découvrir et appeler.^[4][5]

CLI

Le matériel peut également être piloté par ligne de commande, utile pour l’opérateur, les scripts, le debug et les tests d’intégration.

Fichiers de code et APIs

Un agent peut regrouper les commandes de plusieurs appareils dans un programme classique. Anthropic met en avant ce mode pour les opérations rapides, répétables ou longues, lorsque le LLM ne doit pas raisonner à chaque micro-étape.^[1]

L’agent peut apprendre une procédure puis quitter la boucle

Un modèle génératif ne doit pas forcément piloter le matériel à chaque milliseconde.

Dans un exemple, Claude :

1. ajuste un laser,
2. observe le résultat par caméra,
3. répète l’expérience,
4. identifie les relations,
5. transforme la procédure en code déterministe.^[1]

Le script peut ensuite fonctionner sans reasoning continu.

Un pattern de production intéressant est donc :

IA explore
    ↓
IA produit une procédure
    ↓
humains / tests valident
    ↓
code déterministe exécute

QuEra a utilisé ce schéma pour son contrôleur de relock laser : l’agent a contribué au développement et à la validation, mais la logique finale est un programme inspectable sans modèle en ligne au runtime.^[7]

MHS vs MCP : différence essentielle

Élément	MCP	MHS
But principal	Connecter applications IA, outils et données	Standardiser description et contrôle du matériel physique
Cible	Logiciels, APIs, données, tools	Équipements physiques programmables
Modèle	Host, client, server, JSON-RPC	Driver + description + mécanismes de contrôle
Tools	Oui	Peuvent être exposés via MCP
CLI	Pas le modèle central	Un chemin de contrôle documenté
API/code files	Possibles derrière MCP	Un chemin de contrôle documenté
Limites physiques	Pas le cœur de MCP	Partie de la sémantique MHS
Open source aujourd’hui	Oui	Pas encore
Statut	Protocole ouvert	Research preview limité

Anthropic a publié MCP en 2024 comme standard ouvert pour établir des connexions bidirectionnelles entre systèmes IA, sources de données et outils.^[4] La documentation MCP décrit l’architecture host-client-server, capability negotiation, tools, resources et prompts.^[5][6]

MHS ne remplace pas cette couche.

Stack conceptuel :

MODEL / AGENT
      │
      ├── MCP
      ├── CLI
      └── CODE / API
             │
          MHS DRIVER
             │
      INTERFACE MATÉRIEL
             │
       MATÉRIEL PHYSIQUE

Il s’agit d’un schéma conceptuel POLPROG, pas d’un diagramme officiel Anthropic.

MHS est-il « MCP pour le monde physique » ?

C’est une formule utile, mais trop simplificatrice.

Les deux projets réduisent les intégrations spécifiques et proposent une interface commune.

La différence fondamentale : MCP est un protocole de communication pour systèmes IA et outils. MHS ajoute la sémantique du matériel, son état, ses capacités et ses limites.

MHS peut lui-même utiliser MCP.

La formulation correcte est donc :

MHS complète MCP avec une couche destinée au matériel physique.

MHS est model-agnostic

Anthropic affirme explicitement que MHS est model-agnostic et qu’un agent harness peut y accéder via des protocoles standards comme MCP.^[1]

Il n’est donc pas limité formellement à Claude ou Claude Code.

Les pilotes publics concernent surtout Claude parce qu’ils viennent d’Anthropic et de ses partenaires. Aucun benchmark indépendant ne compare encore plusieurs modèles sur le même matériel avec le même driver et les mêmes tâches.

La sécurité doit exister sous le modèle

Dans le logiciel, un mauvais tool call peut supprimer un fichier. Dans le monde physique, une mauvaise décision peut provoquer une collision, renverser un échantillon ou endommager une machine.

Un prompt en langage naturel ne peut donc pas être la seule barrière.

MHS peut transmettre des safety limits imposées.^[1] QuEra précise que bounds, interlocks et emergency stops étaient appliqués au niveau de l’interface matérielle indépendamment du modèle.^[7]

Architecture recommandée :

MODEL
propose

POLICY / APPROVAL
autorise ou refuse

DRIVER / CONTROLLER
impose les limites

HARDWARE INTERLOCK
protège même si le software échoue

Genentech : un problème physique initialement mal compris

Genentech a testé MHS sur un BCA protein assay avec liquid handler, bras robotique et microplate reader.^[1]

Des bulles créées pendant le mélange ont généré des runtime errors. Claude a d’abord traité le problème comme une erreur software et a réessayé dans le même well avec d’autres paramètres. Cela a produit davantage de bulles.^[1]

Des experts humains ont dû expliquer la cause physique et indiquer d’utiliser un well propre et un mélange plus doux. La leçon a ensuite été codifiée en reusable liquid-handling skills.^[1]

Le point essentiel :

Un modèle peut comprendre le message d’erreur tout en comprenant mal la physique qui le provoque.

University of Washington : six appareils en moins d’une semaine

Les laboratoires Baker et Pinglay ont utilisé MHS pour la surveillance à distance, le qPCR supervisé par agent et la coordination d’un bras robotique avec un liquid handler.^[1]

Dans une démo de plate handoff, le liquid handler terminait son opération, l’agent recevait le signal et déclenchait environ dix secondes plus tard le mouvement du bras. Le rapport ne mentionne aucune collision pendant les tests répétés.

La connexion de six instruments, développement des drivers compris, aurait pris moins d’une semaine.^[1]

Il s’agit d’un résultat local, pas d’un délai garanti.

Carnegie Mellon : six conditions de sécurité provoquées volontairement

Une équipe de Carnegie Mellon University a utilisé MHS pour des expériences de serial dilution dose-response.^[1]

Le setup associait liquid handler, plate reader, bras robotique, caméras et trois ordinateurs aux interfaces incompatibles.

Les chercheurs ont provoqué six conditions :

1. plaque absente,
2. plaque tournée,
3. reader occupé,
4. caméra déconnectée,
5. appareil inaccessible,
6. emergency stop actif.^[1]

Le système aurait bloqué les six avant tout mouvement physique.

C’est un proof of concept utile, pas une certification de sécurité.

Correction autonome

Le premier run a produit :

R² < 0,9

L’agent a réduit la concentration maximale :

200 µg/mL
→
100 µg/mL

Le second run a atteint :

R² > 0,98

sans intervention humaine.^[1]

L’équipe rapporte environ 8 heures entre le matériel prêt mais non automatisé et une courbe finale comprenant le rerun autonome, contre plusieurs semaines pour une intégration vendor typique.^[1]

HHMI Janelia : une couche d’état pour sept programmes

Dans un projet Janelia, une chercheuse devait auparavant lancer sept programmes dans un ordre précis.

MHS a remplacé les connexions point-à-point par un state dictionary partagé en mémoire.^[1]

Selon le cas :

• ajouter une nouvelle caméra a pris quelques minutes au lieu de plusieurs jours,
• le démarrage est passé de sept étapes à une seule action,
• les flux de données ont pu être analysés avec des outils réutilisables indépendamment du logiciel vendor.^[1]

MHS imposait aussi des limites comme la puissance maximale du laser, afin qu’un agent ne puisse pas dépasser la plage sûre pour l’échantillon.^[1]

QuEra : 695 relocks réussis sur 700

Le pilote le plus quantifié vient de QuEra Computing.

QuEra a utilisé MHS pour donner à Claude accès à une partie du système laser d’un ordinateur quantique.^[1][7][8]

Après une phase d’expérimentation, un contrôleur déterministe a été créé.

QuEra a effectué :

700 essais
7 classes de perturbation
100 essais par classe

Le contrôleur a récupéré la bonne cible :

695 / 700
=
99,3 %

^[7]

Les cas simples prenaient environ :

0,9–5,4 s

les plus difficiles :

10–14 s

QuEra compare cela à :

5–10 minutes

pour un expert humain.^[7]

Ce n’est pas un benchmark Claude à 99,3 %

Pendant le blind test final, l’agent ne contrôlait pas le laser en ligne.

Il faut écrire :

Un agent utilisant MHS a aidé à développer un contrôleur qui a ensuite atteint 99,3 %.

et non :

Claude contrôle le matériel avec 99,3 % de réussite.

Divergence entre sources

Anthropic parle de « several months » pour le développement de l’ancien script QuEra.^[1]

QuEra indique environ deux à trois semaines.^[7]

Comme ces descriptions publiques divergent, nous n’utilisons pas la durée de développement de l’ancien script comme métrique comparative dure.

Limites révélées par QuEra

Les rapports publics mentionnent aussi des faiblesses.

Claude :

• ne savait pas diagnostiquer certains problèmes purement physiques,
• comprenait surtout le rig par sa représentation programmatique,
• nécessitait beaucoup de contexte,
• pouvait interrompre une expérience pour demander confirmation humaine dès qu’une action paraissait légèrement risquée.^[1]

Dans le monde physique, cette prudence peut être préférable à un agent trop confiant.

Tetsuwan : un appareil détecte le problème, un autre le résout

Tetsuwan a associé MHS à ResearchOS dans un workflow qPCR concernant la pollution de San Pedro Creek.^[1]

Une caméra a détecté des bulles. Le robot tenant l’échantillon ne pouvait pas les supprimer.

Le système :

1. a détecté l’erreur,
2. a recherché des équipements MHS,
3. a trouvé une centrifugeuse,
4. a fait proposer par Claude son utilisation,
5. a envoyé les commandes après validation.^[1]

C’est un exemple de récupération multi-appareils, plutôt qu’un workflow entièrement codé à l’avance.

Écosystème de partenaires

Anthropic cite notamment :^[1]

• Amazon Web Services,
• Automata,
• Danaher,
• Doosan Robotics,
• MBF Bioscience,
• QIAGEN,
• Tecan,
• Universal Robots,
• Hugging Face,
• Raspberry Pi.

AWS prévoit le support via Strands Robots. Hugging Face travaille sur LeRobot et Raspberry Pi sur des intégrations de produits sélectionnés.^[1]

Cela ne signifie pas que toutes ces intégrations sont déjà production-ready.

MHS n’est pas encore open source

Le site officiel parle explicitement de limited research preview.^[2]

Anthropic veut d’abord recueillir les retours des partenaires, créer des safety evaluations, développer des best practices et renforcer les protections.^[1]

Au 30 août 2026, les sources officielles vérifiées ne donnent :

• aucune date de release open-source,
• aucune licence finale,
• aucune spécification publique complète comparable à la documentation MCP.

Donc :

Anthropic prévoit de rendre MHS open source.

est correct.

MHS est déjà open source.

est faux.

Les résultats sont-ils des benchmarks indépendants ?

Non.

Les chiffres publics proviennent surtout d’Anthropic et de partenaires du preview.

Reuters confirme indépendamment le lancement, la portée générale et le projet d’ouverture future.^[3]

Mais il n’existe pas encore de benchmark public avec matériel identique, drivers identiques, plusieurs modèles, même harness et grading indépendant.

Des nombres comme :

99,3 %
3× plus rapide
8 heures
moins d’une semaine

doivent rester liés à leurs pilotes respectifs.

Threat model : que peut-il se passer ?

Reasoning incorrect

Le modèle peut mal interpréter un capteur, un error code, une image ou la cause physique d’une panne. Genentech en fournit un exemple.^[1]

Driver incorrect ou malveillant

Une mauvaise unité, un état faux ou une validation absente peut donner au modèle une représentation erronée du monde réel.

Prompt injection

Texte vu par caméra, documentation, données réseau ou systèmes externes peuvent contenir des instructions malveillantes.

Confused deputy

Un agent ayant accès à plusieurs machines peut utiliser le bon outil pour le mauvais objectif.

Race conditions

Deux agents peuvent essayer de modifier simultanément le même état physique.

Perte de connectivité

Un safe state doit être défini si le modèle, MCP, le réseau, le driver ou un capteur disparaît.

Architecture de production plus sûre

MODEL / AGENT
      ↓
POLICY + APPROVAL
      ↓
MCP / CLI / API
      ↓
MHS DRIVER
      ↓
DETERMINISTIC CONTROLLER
      ↓
HARDWARE INTERLOCK / E-STOP
      ↓
PHYSICAL HARDWARE

C’est une recommandation POLPROG, pas un diagramme officiel Anthropic.

Un LLM ne devrait jamais être le seul composant décidant si une opération physique est sûre.

Que doit imposer la couche déterministe ?

Par exemple :

• plages de température,
• puissance maximale,
• vitesse d’un bras,
• limites d’espace,
• ordre des opérations,
• collision zones,
• limites de pression,
• état des protections,
• emergency stop,
• durée maximale.

Une valeur hors plage doit être refusée indépendamment du reasoning du modèle.

Human-in-the-loop reste important

La spécification MCP Tools recommande que l’utilisateur puisse refuser les tool calls.^[5]

Pour le matériel :

READ
automatique

LOW-RISK WRITE
automatique dans une plage étroite

MEDIUM-RISK
policy + validation

HIGH-RISK
human approval

EMERGENCY / UNSAFE
toujours bloqué

Pourquoi un fallback déterministe est essentiel

QuEra montre un pattern pratique :

IA découvre une solution
→ code généré
→ tests et humains valident
→ production exécute du code déterministe

Cela réduit coût, latency, nondeterminism, dépendance à l’API et risque de décision inattendue.

MHS et systèmes industriels

MHS ne doit pas être vu comme un remplacement de PLC, SCADA, OPC UA, safety PLC ou contrôleurs temps réel.

Il peut se placer plus haut :

agent
↓
orchestration
↓
MHS
↓
contrôleurs existants
↓
hardware

Anthropic montre lui-même que les opérations rapides ou longues peuvent être converties en code pour éviter le reasoning LLM à chaque étape.^[1]

Qui devrait suivre MHS dès maintenant ?

Surtout :

• laboratoires multi-vendeurs,
• biotech et pharma,
• microscopy,
• robotique,
• quantum computing,
• advanced manufacturing,
• équipes R&D ayant beaucoup de bespoke integration code.

Qui doit rester prudent ?

Lorsque :

• le système est safety-critical,
• une spécification publique stable est obligatoire,
• une licence open-source connue est nécessaire,
• des standards industriels certifiés sont requis,
• le matériel n’a pas d’interface automatisable,
• les interlocks indépendants sont absents,
• l’équipe ne peut pas auditer drivers et contrôleurs.

Un research preview n’est pas un standard industriel mature.

Comment une entreprise peut-elle se préparer ?

Étape 1 : inventaire

vendor
model
SDK/API/GUI
unités
états
commandes
limites
E-stop
dépendances

Étape 2 : séparer read et write

Définir ce qui peut être lu, modifié, automatisé ou soumis à approval.

Étape 3 : sortir la sécurité du prompt

Ne pas dépendre d’une simple phrase :

"ne dépasse jamais 80°C"

Une vraie limite doit être imposée par code ou hardware.

Étape 4 : tout journaliser

Agent/modèle, opération, paramètres, état avant/après, résultat, timestamp, policy et approval.

Étape 5 : simuler d’abord

digital twin / mock driver

puis seulement :

real hardware

Plan minimal de tests

Driver

• unités,
• ranges,
• timeouts,
• reconnect,
• réponses invalides,
• restart.

Agent

• capteur erroné,
• données contradictoires,
• error code inconnu,
• prompt injection,
• contexte incomplet.

Hardware

• collision prevention,
• E-stop,
• coupure de courant,
• perte réseau,
• blocage mécanique,
• valeur hors plage.

Multi-agent

• writes simultanés,
• stale state,
• resource locking,
• retry après timeout.

Checklist sécurité MHS

Architecture

• Le modèle ne contrôle pas les actuators sans validation.
• Chaque driver a des limites explicites.
• Les valeurs ont unités et plages.
• Les limites critiques sont déterministes.
• E-stop fonctionne indépendamment de l’IA.
• Safe state après perte de connexion.
• Device state timestampé.
• Retry sûr.

Permissions

• L’agent voit seulement les machines nécessaires.
• READ et WRITE sont séparés.
• High-risk actions nécessitent approval.
• Les permissions expirent.
• Aucun admin token global.

Monitoring

• Chaque tool call est journalisé.
• Les changements physiques produisent de la télémétrie.
• Les alarmes ne dépendent pas seulement du modèle.
• L’opérateur voit l’état courant.
• Event replay disponible.
• Les échecs sont classifiés.

Tests

• Mock hardware.
• Physical sandbox.
• Fault injection.
• Prompt injection.
• Race conditions.
• Network partition.
• Restart agent.
• Restart driver.
• Mauvaises unités.
• Out-of-range values.

Production

• Rollout commence en read-only.
• Puis low-risk writes.
• Safety-critical actions restent hors agent.
• Code déterministe remplace l’IA quand possible.
• Drivers passent en code review.
• Rollback existe.
• Reprise manuelle possible.
• L’équipe connaît l’impact physique de chaque commande.

Que faut-il pour que MHS devienne un vrai standard ?

Il faudra notamment :

1. spécification publique,
2. versioning stable,
3. modèle de compatibilité,
4. SDK publics,
5. licence open-source,
6. reference drivers,
7. conformance tests,
8. security evaluations,
9. implémentations indépendantes,
10. support vendor,
11. validation des drivers,
12. permission model clair.

MCP a gagné en importance grâce à son écosystème interopérable. MHS devra suivre un parcours similaire.

MHS changera-t-il la robotique ?

Peut-être, mais il est trop tôt.

Le meilleur fit à court terme concerne des environnements où le matériel est déjà programmable, l’intégration coûteuse et les workflows variables :

laboratoires
R&D
biotech
microscopy
quantum
advanced manufacturing

MHS ne résout pas automatiquement perception robotique, motion planning, real-time control, safety certification ou physique de manipulation.

Il peut simplifier l’interface entre l’agent et les systèmes de contrôle existants.

Verdict POLPROG

Model Hardware Standard est l’un des développements agents les plus intéressants de 2026 car il déplace l’interopérabilité du numérique vers le physique.

Ce qui est confirmé

• research preview lancé le 27 août 2026.^[1][3]
• origine commune Anthropic et HHMI Janelia.^[1]
• model-agnostic.^[1]
• contrôle par MCP, CLI et code/API files.^[1]
• le driver MHS décrit l’équipement et ses safety limits.^[1]
• Anthropic prévoit l’open source plus tard.^[1][2]
• QuEra confirme 695 relocks réussis sur 700 pour le contrôleur final.^[7]

Ce que nous ne savons pas encore

• schéma public final,
• date open-source,
• licence,
• stabilité API,
• compatibilité entre implémentations,
• benchmark indépendant,
• performances de différents modèles sur le même matériel.

Le pattern le plus prometteur

Pas :

LLM contrôle tout en permanence

mais :

agent comprend l’objectif
→ explore un espace sûr
→ coordonne les machines
→ crée ou choisit une procédure
→ le système valide
→ le travail répétable passe en code déterministe

Si Anthropic ouvre réellement la spécification, si les vendors publient des drivers réutilisables et si des équipes indépendantes valident sécurité et interopérabilité, MHS pourrait devenir une couche importante de physical AI.

Nous n’en sommes pas encore là.