Le cadre Physical AI d’Arm fait de l’intégration le principal enjeu de la robotique

Arm a lancé son cadre Physical AI avec plus de 80 partenaires, pariant que la robotique a désormais davantage besoin de fondations partagées que d’un processeur isolé supplémentaire.

Cette nouvelle initiative associe Arm Total Design for Physical AI à un projet de Robotics Capability Framework. L’un relie les entreprises à travers toute la pile technologique. L’autre établit des termes communs pour décrire les capacités des robots.

L’annonce va au-delà d’un programme de partenariat. Arm remet en cause le modèle de développement fragmenté qui contraint les entreprises de robotique à intégrer, pour l’essentiel seules, des modèles, des capteurs, des logiciels, des processeurs et des systèmes de sécurité.

Cette position place aussi Arm aux côtés de Nvidia, dont le matériel Jetson et les logiciels Isaac proposent déjà aux développeurs une pile robotique étroitement intégrée. Arm ne copie pas directement ce modèle. L’entreprise propose une alternative plus large, pilotée par les partenaires et construite autour de son architecture de processeur.

La question centrale est de savoir si des interfaces communes et des définitions de capacités peuvent réduire les risques de déploiement sans limiter la manière dont les fabricants de robots différencient leurs produits.

Le cadre Physical AI d’Arm relie plus de 80 partenaires

Arm a fait évoluer son rôle dans la robotique, passant d’un ensemble de relations autour des processeurs à un programme industriel structuré.

L’entreprise a annoncé Arm Total Design for Physical AI le 8 septembre 2026. Arm décrit la physical AI comme une intelligence intégrée à des machines qui perçoivent leur environnement, prennent des décisions et agissent dans le monde réel.

Le programme comprend plus de 80 entreprises participantes. Les membres cités couvrent les services cloud, les modèles d’IA, les systèmes automobiles, les semi-conducteurs, les logiciels industriels et la robotique.

La liste inclut AWS, ECARX, Hugging Face, Liquid AI, NXP, PlusAI, PSYONIC, QNX, Qwen, Siemens et Unitree Robotics. Cette diversité est essentielle à l’argumentaire d’Arm.

Un robot n’est pas un modèle de langage placé dans un corps mécanique. Il a besoin de perception, de contrôle du mouvement, de traitement des capteurs, de réseau, de mémoire, de contrôles de sécurité et de temps de réponse prévisibles.

Chaque composant répond à des exigences d’ingénierie différentes. Un modèle de planification peut tolérer des délais qui seraient inacceptables pour un arrêt d’urgence ou une boucle de contrôle de l’équilibre.

Arm affirme que son programme Physical AI aidera les partenaires à concevoir et valider ensemble ces composants. L’objectif est de révéler les problèmes d’intégration avant que les entreprises ne s’engagent sur du silicium finalisé ou du matériel de production.

Cette approche étend Arm Total Design, un modèle de collaboration auparavant utilisé pour l’infrastructure cloud. Dans ce programme, les partenaires associent des sous-systèmes de calcul Arm à du silicium spécialisé, des micrologiciels, des systèmes d’exploitation et d’autres technologies.

Sa version dédiée à la physical AI couvre un éventail plus large de composants. Arm cite parmi les couches participantes les modèles d’IA, les piles logicielles, les capteurs, le matériel de calcul, les plateformes virtuelles et les jumeaux numériques.

Un jumeau numérique est une représentation logicielle d’un système ou d’un environnement physique. Les développeurs l’utilisent pour tester du code et le comportement d’un système sans dépendre entièrement de machines finalisées.

Arm cite un système de référence de cockpit numérique automobile comme premier exemple de cette méthode de développement. Arm, AWS, Google, HERE, RemotiveLabs et Siemens ont collaboré à ce système.

Le projet a permis aux développeurs de concevoir et valider des logiciels automobiles à l’aide d’un sous-système de calcul Arm Zena virtuel avant que le silicium correspondant ne soit disponible.

Ce détail illustre l’ambition concrète derrière Arm Total Design. Attendre le matériel ralentit le développement robotique et repousse le difficile travail d’intégration vers la fin d’un projet.

Le développement virtuel peut avancer une partie de ce travail. Des systèmes de référence partagés peuvent également révéler si les micrologiciels, les systèmes d’exploitation, les modèles d’IA et les capteurs fonctionnent ensemble comme prévu.

Toutefois, l’adhésion au programme ne suffit pas à établir l’interopérabilité. Il faudra encore des conceptions de référence fonctionnelles, des méthodes de validation reproductibles et des résultats documentés issus de déploiements réels.

Arm a réuni un vaste groupe. Son prochain défi sera de transformer ce groupe en ressources d’ingénierie que les fabricants de robots pourront utiliser.

L’intégration est devenue le goulot d’étranglement

Le cadre Physical AI d’Arm considère l’intégration des systèmes, et non l’intelligence brute des modèles, comme l’obstacle qui sépare les prototypes robotiques des machines déployées.

Les modèles d’IA récents ont amélioré la manière dont les robots interprètent les images, le langage et les démonstrations. Ces progrès n’éliminent pas les contraintes physiques qui entourent un système déployé.

Un robot d’entrepôt doit raisonner assez vite pour éviter les travailleurs et les équipements. Une machine chirurgicale doit présenter un comportement prévisible sous de strictes exigences de sécurité. Un robot agricole doit fonctionner avec une énergie limitée et une connectivité peu fiable.

Ces systèmes ne peuvent pas envoyer chaque décision à un centre de données distant. Les délais réseau, les pannes, les exigences de confidentialité et les coûts d’exploitation poussent davantage de traitement vers la machine elle-même.

Cela crée des exigences concurrentes. Les développeurs veulent des modèles plus grands, davantage de données de capteurs et des périodes de fonctionnement plus longues. Le robot reste confronté à des limites fixes de puissance, de poids, de mémoire, de refroidissement et de capacité de batterie.

Drew Henry, vice-président exécutif d’Arm pour la physical AI, a souligné cette différence lors d’un briefing avec des analystes. Il a déclaré que les systèmes physiques nécessitent un calcul léger, car le poids affecte le refroidissement et la conception des sous-systèmes.

Henry a également indiqué que les produits basés sur Arm avaient écoulé plus de deux milliards d’unités sur les marchés de la physical AI au cours de l’année précédente. Ce chiffre provient d’Arm et n’a pas fait l’objet d’un audit indépendant pour ce programme.

L’entreprise estime que la physical AI pourrait représenter une opportunité annuelle de 200 milliards de dollars pour le calcul au cours des années 2030. Arm identifie l’exploitation minière, l’agriculture, la fabrication, le transport et la logistique comme secteurs cibles.

Cette estimation doit être considérée comme une prévision stratégique, et non comme un chiffre d’affaires actuel du marché. Elle montre pourquoi Arm veut structurer ce marché dès maintenant.

Les entreprises de robotique combinent souvent des composants conçus selon des hypothèses différentes. Un modèle de perception peut attendre un accélérateur donné. Un contrôleur de sécurité peut utiliser un autre processeur et un autre environnement d’exploitation.

Les logiciels intermédiaires doivent alors déplacer les données entre eux. Les ingénieurs doivent gérer la synchronisation, l’utilisation de la mémoire, les délais de communication, les mises à jour logicielles et les défaillances matérielles.

Ce travail devient plus difficile lorsque chaque fournisseur emploie une terminologie différente pour la performance et l’autonomie. Un robot décrit comme autonome peut encore nécessiter de fréquentes interventions humaines dans des environnements inconnus.

Arm veut réduire ces deux formes de fragmentation. Total Design traite de la pile technique, tandis que le Robotics Capability Framework traite du langage utilisé pour décrire les systèmes qui en résultent.

Le calendrier reflète aussi une évolution de la concurrence. Les fournisseurs de processeurs vendent de plus en plus des environnements de développement, des plateformes de référence et des bibliothèques logicielles en parallèle du silicium.

Les clients ne choisissent pas une puce de manière isolée. Ils choisissent la vitesse à laquelle un produit complet peut parvenir aux phases de test, de certification et de production.

L’architecture d’Arm est déjà présente dans de nombreux contrôleurs embarqués et appareils économes en énergie. Le nouveau programme cherche à relier cette position installée à un traitement de l’IA de niveau supérieur.

Le succès permettrait aux partenaires de conserver leurs produits spécialisés tout en partageant suffisamment d’infrastructure pour raccourcir l’intégration. Un échec laisserait les clients face à une alliance supplémentaire exigeant une ingénierie sur mesure conséquente.

La différence deviendra visible dans les systèmes de référence déployables, et non dans le nombre de logos affichés au lancement.

Un Robotics Capability Framework tente de créer un langage commun

Les niveaux robotiques proposés par Arm pourraient faciliter la comparaison des systèmes, mais seulement si le secteur définit les capacités à travers des conditions de fonctionnement mesurables.

Le Robotics Capability Framework est l’une des premières initiatives dans le cadre d’Arm Total Design for Physical AI. Arm le présente comme un point de départ plutôt que comme une norme achevée.

Son modèle initial va de RL0 à RL5. Les catégories évoluent de machines réactives vers des systèmes contextuels, cognitifs et auto-améliorants.

Arm souhaite que chaque niveau relie le comportement du robot à des exigences techniques. Ces exigences comprennent la latence, le placement du calcul, la mémoire, la puissance, le déterminisme et la sécurité.

Le déterminisme signifie qu’un système produit une réponse prévisible dans des limites connues. Il est important lorsqu’un résultat retardé ou incohérent peut endommager des équipements ou blesser quelqu’un.

La structure initiale du cadre a reçu des retours d’Anaxi Labs, ANYbotics, FMC³ Robotics, Fourier, GALBOT, Gravis Robotics, Lenovo, McKinsey et Robotec.ai.

Arm invite davantage d’entreprises à façonner le modèle. Cette invitation est importante, car le cadre ne dispose pas au lancement de l’autorité d’un organisme de normalisation indépendant.

La proposition s’inspire de SAE J3016, qui a créé des niveaux d’automatisation de la conduite. La taxonomie de l’automatisation a donné aux constructeurs automobiles, aux régulateurs et aux consommateurs un vocabulaire commun.

La robotique couvre un champ plus large que les véhicules routiers. Un bras industriel, un assistant humanoïde, un tracteur autonome et un robot chirurgical exécutent des tâches différentes dans des conditions différentes.

Une échelle unique de capacités doit tenir compte de cette diversité. Sinon, un niveau risque de devenir une étiquette marketing dépourvue d’une signification opérationnelle suffisante.

Une classification utile doit préciser la tâche et l’environnement opérationnel. Elle doit aussi indiquer à quel moment les humains surveillent, approuvent, récupèrent ou contrôlent directement le système.

Prenons deux robots d’entrepôt recevant tous deux une étiquette de haute autonomie. L’un peut ne fonctionner que sur des itinéraires cartographiés, tandis que l’autre gère des personnes en mouvement et des obstacles imprévisibles.

L’étiquette révèle peu de choses si elle ne décrit pas ces limites opérationnelles. Elle doit également distinguer les performances nominales du comportement lors de défaillances de capteurs, d’itinéraires bloqués et de la présence d’objets inhabituels.

Arm semble consciente de cet enjeu. Son cadre relie les cas d’usage et les comportements aux exigences du système, au lieu de décrire l’intelligence comme une propriété abstraite.

Ce lien peut aider les équipes achats à poser de meilleures questions. Les acheteurs pourraient comparer les taux d’intervention, les limites de réponse, les besoins énergétiques et les mécanismes de sécurité dans le cadre d’une tâche définie.

Les développeurs pourraient utiliser le même cadre pour faire correspondre les exigences logicielles au matériel. Un système doté de capacités plus élevées pourrait nécessiter une inférence locale, une détection redondante, davantage de mémoire ou des garanties de synchronisation plus strictes.

Le cadre pourrait aussi mettre en évidence des comparaisons trompeuses. Un robot optimisé pour une tâche contrôlée ne devrait pas être classé en dessous d’une machine généraliste simplement parce que son champ d’action est plus restreint.

La valeur dépendra de la manière dont Arm définit chaque niveau. Des références claires, des conditions de défaillance et des domaines opérationnels importent davantage qu’une progression séduisante de zéro à cinq.

Un langage commun n’est utile que lorsqu’il rend visibles les différences importantes.

Le véritable affrontement porte sur un modèle d’écosystème, pas sur un seul processeur

Arm positionne un réseau de partenaires ouvert face aux piles étroitement intégrées qui façonnent déjà le développement de la physical AI.

Nvidia offre la comparaison la plus évidente. Sa plateforme Isaac associe des outils de simulation, des bibliothèques accélérées, des modèles d’IA et des workflows de référence pour le développement robotique.

L’entreprise vend également des modules Jetson pour l’edge computing. Jetson Thor utilise l’architecture GPU Blackwell de Nvidia et cible les humanoïdes, les robots industriels, les systèmes médicaux et les machines autonomes.

Nvidia affirme que l’écosystème Jetson compte plus de deux millions de développeurs et plus de 150 partenaires dans le matériel, les logiciels et les capteurs. L’entreprise indique également que Jetson Orin équipe plus de 7 000 clients.

Ces chiffres proviennent de Nvidia, mais ils illustrent l’écart de maturité auquel Arm est confrontée. Nvidia propose déjà un parcours identifiable, de l’entraînement et de la simulation jusqu’à l’inférence embarquée.

Sa plateforme Jetson Thor intègre 128 Go de mémoire et jusqu’à 2 070 téraflops FP4, dans une enveloppe énergétique de 130 watts.

Nvidia affirme que Thor offre jusqu’à 7,5 fois plus de puissance de calcul pour l’IA et une efficacité énergétique 3,5 fois supérieure à Jetson Orin. Ces comparaisons reposent sur les propres tests de Nvidia.

L’avantage plus large réside dans l’intégration. Les développeurs peuvent utiliser Nvidia Isaac pour la robotique, Omniverse pour la simulation, les modèles GR00T pour les humanoïdes et des outils fondés sur CUDA à toutes les étapes du développement.

Arm propose une approche différente. Son architecture de jeu d’instructions et ses conceptions de processeurs prennent en charge des produits allant des petits contrôleurs aux systèmes automobiles et serveurs.

Les partenaires peuvent y ajouter leurs propres processeurs, accélérateurs, firmwares, systèmes d’exploitation et modèles. Cette flexibilité peut réduire la dépendance à un fournisseur unique coordonnant verticalement l’ensemble.

Elle peut aussi générer davantage de travail d’intégration. Un écosystème de partenaires ne réussit que si ses composants fonctionnent ensemble sans que chaque client doive reconstruire les interconnexions.

Arm Total Design tente de résoudre ce problème grâce à la collaboration et à des solutions de référence. Le programme permet aux fournisseurs de valider des combinaisons avant que les clients ne les assemblent.

Cette distinction rappelle deux manières de bâtir une plateforme robotique.

L’une fournit un ensemble étroitement intégré, contrôlé par un fournisseur central. L’autre établit des fondations communes tout en permettant à plusieurs fournisseurs de concurrencer à chaque couche.

L’approche intégrée peut simplifier les achats et le développement. Elle concentre aussi les choix techniques, les outils et l’optimisation autour de la feuille de route d’une seule entreprise.

L’approche menée par les partenaires offre davantage de choix. Elle risque toutefois de ralentir la coordination, de produire une documentation inégale et de rendre les responsabilités floues lorsqu’un système combiné échoue.

Arm n’a pas besoin que toutes les charges de travail robotiques abandonnent Nvidia. De nombreuses machines à venir pourront associer des CPU Arm à des accélérateurs Nvidia ou à d’autres processeurs spécialisés.

Plusieurs participants annoncés travaillent déjà avec des plateformes de calcul concurrentes. Siemens, AWS et les fabricants de robots prennent régulièrement en charge plusieurs environnements matériels.

Ce chevauchement rend la concurrence moins exclusive qu’une rivalité classique entre fabricants de processeurs. La question plus profonde est de savoir quelle entreprise définira les interfaces autour de l’IA physique.

Si les interfaces d’Arm sont largement adoptées, les fournisseurs de composants pourront développer sur une architecture commune et un langage partagé des capacités. Les clients pourraient alors remplacer des éléments sans redessiner tout le système.

Si le logiciel intégré de Nvidia demeure plus facile à déployer, les clients pourraient privilégier une pile complète plutôt que la flexibilité des fournisseurs.

Arm est donc en concurrence pour influencer la conception des systèmes. Les livraisons de processeurs lui fournissent une base, mais les logiciels utilisables et les intégrations validées détermineront son poids.

Les niveaux numérotés des robots présentent un risque familier

Une échelle de capacités peut améliorer la communication, tout en encourageant les acheteurs à confondre un chiffre plus élevé avec un robot plus sûr ou plus performant.

L’analogie la plus forte d’Arm est aussi l’avertissement le plus clair. Les niveaux d’automatisation de la SAE ont contribué à normaliser la terminologie, mais leur emploi a engendré une confusion persistante.

Ces niveaux décrivent l’automatisation active pour une fonction de conduite. Ils n’attribuent pas un score permanent d’intelligence à l’ensemble d’un véhicule.

Les discussions publiques simplifient souvent cette nuance. Un chiffre plus élevé devient un raccourci pour désigner une sophistication technique, une sécurité ou une maturité commerciale supérieures.

Des recherches publiées par la communauté technologie et société de l’IEEE ont détaillé ce problème. Leur critique des niveaux soutient que les catégories numérotées peuvent suggérer une trajectoire simple vers une automatisation complète.

Cette critique souligne également que des systèmes appartenant au même niveau de conduite peuvent opérer dans des environnements très différents. Une navette géorestreinte et un véhicule routier pourraient recevoir des étiquettes similaires malgré des contraintes distinctes.

La robotique multiplie ce problème. Les machines diffèrent en matière de mobilité, de manipulation, de perception, de planification, de communication et d’interaction humaine.

Un système peut être performant sur une dimension et médiocre sur une autre. Un bras d’entrepôt peut manipuler des objets avec précision tout en restant fixe dans une cellule protégée.

Un robot mobile peut naviguer sur un site très fréquenté tout en ne manipulant qu’un chargement simple. Décrire l’une ou l’autre machine par un seul chiffre pourrait masquer davantage d’informations qu’il n’en révèle.

RL5 présente un autre risque, car Arm décrit cette catégorie à travers l’auto-amélioration. Ce terme nécessite des limites strictes avant de pouvoir étayer des décisions d’ingénierie ou d’achat.

Les acheteurs doivent savoir ce qui change, où l’apprentissage se produit et qui approuve les comportements mis à jour. Ils ont aussi besoin de procédures de retour en arrière et de preuves que les nouveaux comportements préservent la sécurité.

Un robot qui adapte sa planification d’itinéraire est différent d’un robot qui modifie ses politiques de manipulation à proximité de personnes. Tous deux pourraient être considérés comme auto-améliorants selon une définition large.

Le cadre d’IA physique d’Arm devrait donc traiter les niveaux de capacité comme des synthèses étayées par des profils détaillés. Ces profils doivent identifier les tâches, les environnements, la gestion des défaillances et les responsabilités humaines.

Une évaluation indépendante sera importante. Un fournisseur ne devrait pas obtenir une étiquette commercialement précieuse uniquement sur la base de sa propre déclaration.

Le cadre a également besoin de règles de gouvernance. Arm n’a pas encore expliqué qui maintiendra les définitions, résoudra les différends ou certifiera la conformité.

On ignore encore si l’initiative deviendra une spécification gérée par Arm, un consortium industriel ou une proposition de normalisation officielle.

Cette incertitude ne rend pas l’effort vide de sens. Les premiers cadres commencent souvent comme des accords de travail entre entreprises confrontées à un problème commun.

Toutefois, l’adoption ne doit pas être confondue avec la validation. Plus de 80 organisations participantes témoignent d’un intérêt pour la collaboration, non d’un accord sur les critères techniques définitifs.

La même distinction s’applique aux prévisions de marché d’Arm. Une importante opportunité de calcul projetée ne permet pas d’établir quels robots parviendront à un déploiement rentable.

Les systèmes physiques font face à des coûts de maintenance, de responsabilité, d’énergie, de durabilité et d’intégration au travail que les benchmarks logiciels capturent rarement.

Arm peut réduire certaines frictions d’ingénierie. Elle ne peut pas éliminer la nécessité d’analyses de sécurité propres à chaque application ni d’essais en conditions réelles.

Le cadre gagnera en crédibilité lorsqu’il clarifiera ces limites au lieu de les condenser en un chiffre séduisant.

Trois signaux montreront si le pari d’Arm fonctionne

La prochaine phase dépend de systèmes de référence, de définitions mesurables des capacités et de preuves que les clients peuvent déployer plus rapidement des robots multiconstructeurs.

Le premier signal sera un ensemble de conceptions de référence fonctionnelles. Arm a besoin de davantage d’exemples comparables à son projet de cockpit automobile virtuel, mais directement centrés sur la robotique.

Un système de référence utile connecterait les capteurs, le contrôle en temps réel, l’inférence d’IA, les fonctions de sécurité, le firmware et la simulation. Il documenterait aussi les partenaires ayant fourni chaque couche.

Les développeurs devraient pouvoir reproduire la conception ou l’adapter sans travail d’intégration privé. Des résultats de performances publiés rendraient la collaboration plus facile à évaluer.

Ce signal renforcerait l’argument d’Arm, car il transformerait l’adhésion des partenaires en une voie d’ingénierie utilisable. Des retards ou des démonstrations privées l’affaibliraient.

Le deuxième signal est un Robotics Capability Framework détaillé. Les définitions finales devraient préciser les tâches, les environnements d’exploitation, la supervision humaine, les limites de temps et le comportement en cas de défaillance.

Arm devrait également expliquer si RL0 à RL5 représente une progression stricte. Un profil multidimensionnel pourrait mieux servir les machines complexes qu’un score global unique.

La gouvernance sera tout aussi importante. Le marché doit savoir qui met à jour le cadre et si des organisations indépendantes peuvent tester la conformité.

Une spécification transparente, avec une large participation technique, renforcerait la proposition. Une étiquette principalement contrôlée via les canaux marketing d’Arm limiterait son autorité.

Le troisième signal sera constitué de preuves issues de déploiements en production. Les clients devraient faire état de cycles d’intégration plus courts, de moins de défaillances de compatibilité ou d’une réduction des refontes entre la simulation et le matériel final.

Ces résultats sont plus difficiles à mesurer que le nombre de partenaires. Ils sont aussi plus proches du problème qu’Arm affirme résoudre.

L’analyste Larry Dignan a observé qu’Arm formalise une présence dans l’IA physique construite au fil de plusieurs années. Son analyse de l’écosystème présente l’initiative comme un élément de l’effort d’Arm pour couvrir les systèmes cloud, edge et physiques.

Cette stratégie donne à Arm une position de départ crédible. Les logiciels peuvent être développés dans le cloud, testés sur des plateformes virtuelles et déployés sur du matériel edge fondé sur Arm.

Cependant, la portée architecturale ne garantit pas une expérience développeur cohérente. Les équipes robotiques jugeront le programme à travers sa documentation, ses outils, son débogage et son support lorsque les composants échoueront ensemble.

La réponse de Nvidia apportera un contexte utile, mais elle ne sera pas le seul critère. Les fabricants de robots peuvent utiliser les deux écosystèmes, et beaucoup choisiront des piles différentes pour différents sous-systèmes.

Le test le plus probant est de savoir si Arm rend le développement multiconstructeur intentionnel plutôt qu’improvisé. Cela exige des interfaces stables et une responsabilité claire sur l’ensemble de la pile.

Les développeurs devraient surveiller les implémentations de référence téléchargeables, les benchmarks publics et les méthodes de validation précises. Les acheteurs devraient demander comment les niveaux de capacité correspondent à leurs environnements d’exploitation.

Ils devraient également distinguer les estimations des entreprises des résultats de déploiement mesurés. Ni la demande de calcul projetée ni une longue liste de partenaires ne garantissent des machines fiables.

Le cadre d’IA physique d’Arm a identifié un problème réel. La robotique a besoin d’une meilleure coordination entre modèles, logiciels, capteurs, silicium, systèmes de contrôle et processus de sécurité.

Sa réponse demeure une proposition en construction. Arm Total Design apporte la coalition, tandis que le Robotics Capability Framework fournit un éventuel vocabulaire commun.

Au cours des prochains mois, la question la plus utile ne sera pas de savoir si une autre entreprise rejoint le projet. Elle sera de savoir si les entreprises participantes publient quelque chose qu’une équipe d’ingénierie peut construire, tester et juger digne de confiance.

Si vous développez ou achetez des systèmes autonomes, examinez attentivement les premières conceptions de référence. Exposent-elles des compromis mesurables, ou relient-elles simplement des produits partenaires ?

Examinez ensuite les définitions de capacités au regard de vos conditions d’exploitation réelles. Un cadre utile devrait rendre les décisions d’achat et de risque plus précises.

Arm a ouvert ce processus à l’industrie. La qualité des spécifications qui en résulteront, et non l’ampleur de l’annonce de lancement, déterminera si la robotique les adopte.