Anthropic a ouvert le 27 août une preview de recherche du Model Hardware Standard (MHS), une spécification commune pour que des agents IA découvrent, pilotent et dépannent des équipements physiques : microscopes, bras robotisés, manipulateurs de liquides, lasers, automates de production. Un pilote standardisé expose des commandes de lecture et d'écriture unifiées, des étiquettes en langage naturel décrivant chaque instrument et un fichier de référence généré automatiquement qui documente ses limites de sécurité. Les agents y accèdent via MCP, en ligne de commande ou par des fichiers de code faisant office d'API. Accès sur candidature (modelhardwarestandard.com), passage en open source annoncé sans date.
- Le positionnement est explicite : « ce que MCP a fait pour le logiciel, MHS le fera pour le matériel » (Alek Kemeny, Anthropic) ; le standard est indépendant du modèle et fonctionne avec tout appareil qui expose une interface programmable
- Résultats des premiers partenaires : intégration d'instrument en heures au lieu de semaines, expériences de découverte de médicaments trois fois plus rapides à Carnegie Mellon, et chez QuEra un re-verrouillage de laser réussi dans 99,3 % des cas contre 58 % avec un script sur mesure
- Limites posées par Anthropic : les appareils sans API, SDK ou interface graphique ne sont pas pris en charge, l'agent a eu besoin d'aide humaine sur des pannes physiques qu'il ne pouvait pas déduire du code, et les évaluations de sécurité sont précisément ce que la preview doit produire
Ce que le standard fait vraiment, et ce qu'il ne fait pas encore
Le problème adressé est connu de quiconque a travaillé dans un laboratoire ou une usine : chaque instrument parle sa propre langue, et brancher un nouvel appareil dans une chaîne automatisée coûte des semaines de pilote sur mesure. MHS ne remplace pas les protocoles industriels ; il pose une couche au-dessus, entre le système d'exploitation et la machine, où découverte, lecture, écriture et métadonnées sont uniformes. Les limites de sécurité (plages de température, vitesses, positions) sont appliquées au niveau du pilote, sous l'agent : un agent ne peut pas demander ce que le fichier de référence interdit. C'est la différence architecturale avec un simple serveur MCP branché sur un automate.
Les cas publiés valent d'être lus pour leurs détails. Chez Genentech, un agent a coordonné un manipulateur de liquides, un bras robotisé et un lecteur de plaques sur un dosage protéique standard, et a optimisé seul les débits de pipetage (environ 140 microlitres par seconde pour l'eau, 10 pour une solution visqueuse) en se comparant à une référence experte ; il a récupéré seul des erreurs de prise de cônes et de détection de fluide, mais a eu besoin d'un humain quand des bulles ont provoqué des pannes physiques invisibles depuis le code. Au HHMI Janelia, une chaîne d'imagerie est passée de semaines à une journée. Les partenaires qui construisent ou testent des pilotes couvrent les fabricants (Danaher, Tecan, QIAGEN, MBF Bioscience pour ScanImage, utilisé dans des centaines de labos de neurosciences), la robotique collaborative (Universal Robots, Doosan), le cloud (AWS), l'open source (LeRobot de Hugging Face) et le matériel amateur (Raspberry Pi).
Trois réserves. MCP a mis environ un an entre son lancement et une adoption large, et le matériel bouge plus lentement que le logiciel : « en développement » chez un fabricant est une direction, pas une date. Le règlement Machines européen s'applique à partir de janvier 2027 et n'a pas été écrit pour des agents qui pilotent des équipements ; la question de responsabilité est ouverte. Et la preview est justement là pour produire les évaluations de sécurité dont les industries réglementées auront besoin avant tout déploiement.
Mon avis : c'est le mouvement le plus important d'Anthropic depuis MCP, parce qu'il applique la même stratégie, un standard ouvert et indépendant du modèle, à un domaine où personne n'en a. Si l'open source arrive et que deux ou trois fabricants majeurs livrent des pilotes, le standard s'impose par défaut comme MCP l'a fait. L'usage n'est pas réservé aux labos : une chaîne de production, une flotte d'imprimantes 3D, un parc de capteurs, c'est le même problème.
Ce que ça change pour vous
Si vous travaillez dans l'industrie, la recherche ou le matériel, la preview est ouverte aux candidatures et la barrière est l'existence d'une interface programmable sur vos équipements, pas votre architecture. Si vos agents tournent déjà sur des serveurs MCP, une intégration MHS est une surface MCP de plus.
Si vous faites du logiciel ou du web, l'enseignement est indirect mais précis : la couche de sécurité est sous l'agent, dans le pilote, avec des limites écrites que le modèle ne peut pas franchir. C'est le modèle à copier pour tout agent qui a des droits d'écriture sur un système réel, base de données, CMS ou back-office compris.
- Si tu as des équipements pilotables, inventorie ceux qui exposent une API, un SDK ou une interface graphique scriptable : c'est le critère d'éligibilité, et la liste te dit ce qui pourrait être intégré en heures plutôt qu'en semaines
- Pour tout agent en production avec droits d'écriture, écris un « fichier de référence » à la MHS : limites explicites, actions interdites, valeurs plafonnées, appliquées dans la couche d'accès et non dans le prompt
- Si tu es fabricant ou intégrateur, candidate à la preview maintenant : les partenaires qui livrent un pilote avant l'open source définiront les conventions que les autres devront suivre
Sources
- Anthropic - Previewing the Model Hardware Standard (27 août 2026)
- Quartz - déclarations d'Anthropic à Bloomberg et CNBC, liste des partenaires
- AlphaSignal - détails des cas Genentech et QuEra
- Technspire - lecture d'architecture et enjeu du règlement Machines européen
Source : Anthropic.com
Cet article a été rédigé avec l’assistance d’un modèle de langage (LLM).
