IA hors ligne : quand robots et véhicules doivent penser sans le cloud

Un chatbot peut attendre une demi-seconde la réponse du cloud. Un bras robotisé, non. Pas plus qu’un véhicule qui réduit l’écart à vitesse d’autoroute, ni qu’un humanoïde qui rattrape une pièce glissant sur une ligne de production. C’est ce décalage temporel qui a fait de la robotique IA embarquée une discipline à part entière : garder la boucle fermée — percevoir, décider, agir — sur la machine, et traiter le cloud comme un professeur, un cerveau de flotte et un recours, pas comme un copilote temps réel.

Ce guide de fond explique pourquoi l’inférence IA hors ligne compte pour les robots et les véhicules autonomes, comment les modèles vision-langage-action (VLA) sont repensés pour l’IA incarnée hors ligne, et dans quels cas un serveur local proche, à l’usine ou en bord de route, reste utile sans placer le contrôle critique pour la sécurité sur l’Internet public.

La latence est un problème de physique, pas un slogan produit

Pour un assistant numérique, la latence est un désagrément. Pour un système incarné, c’est de la cinématique.

Les automaticiens répartissent des budgets en millisecondes entre perception, planification et commandes des actionneurs. Dépasser ce budget ne donne pas une « réponse lente » : cela donne un dépassement de consigne, un objet qui tombe, une marche instable ou un freinage décidé trop tard. Comme le rapporte EE Times à partir des propos des responsables robotique de STMicroelectronics, lorsque les articulations doivent se coordonner, le délai d’aller-retour vers un processeur central (sans parler d’un cloud lointain) peut transformer de petites erreurs de suivi en préhensions ratées ou en mouvements du corps entier dangereux.

Trois contraintes font du cloud un mauvais choix par défaut pour la boucle la plus interne :

1. Propagation et gigue. Même un saut 5G « rapide » ajoute un délai variable. Les dossiers de sécurité s’intéressent à la latence dans le pire des cas, pas à la latence médiane.
2. Trous de connectivité. Entrepôts, mines, tunnels, routes rurales, navires et zones sinistrées perdent régulièrement la liaison montante. Un robot qui se fige sans le cloud n’est pas autonome.
3. Asymétrie de bande passante. Envoyer en continu vers le cloud des flux multicaméras, lidar et tactiles coûte cher. Les compresser pour le cloud détruit souvent les détails dont la politique de contrôle a justement besoin.

La pratique de la sécurité fonctionnelle traite donc la coupure réseau comme une condition de conception. Les recommandations de consultants sur les déploiements d’IA embarquée relevant de l’ISO 26262 / IEC 61508 (par exemple Hyperion Consulting) énoncent clairement la règle : l’entraînement, la supervision et l’orchestration des mises à jour peuvent vivre dans le cloud ; le chemin d’inférence temps réel doit continuer à fonctionner hors ligne.

Voilà la définition de l’IA incarnée hors ligne : une intelligence qui reste compétente quand la radio tombe.

Ce que « local » veut dire en robotique (trois couches)

Les praticiens désignent généralement l’un de ces trois emplacements — parfois les trois au sein d’une même flotte :

L’étude 2026 de Microsoft Research sur l’inférence déportée pour l’IA physique rend l’arbitrage explicite. Des GPU uniquement embarqués peuvent limiter la taille des modèles, réduire l’autonomie et dégrader le taux de réussite des tâches ; déporter l’inférence vers un GPU sur site ou dans le cloud peut améliorer la réussite et allonger l’autonomie — mais seulement si la latence et la bande passante réseau restent dans le budget de contrôle. Dans leurs mesures de manipulation mobile, des GPU embarqués plus légers ralentissaient fortement la cartographie et la planification par rapport à un GPU de data center puissant, nuisaient à la détection d’obstacles en temps utile pendant la navigation, et s’accompagnaient de fortes baisses de précision des VLA lorsque le modèle tournait trop lentement. Le déport aidait — mais le même article prévient que le bon partage dépend de la charge de travail, pas d’un dogme.

L’architecture durable, c’est l’autonomie par couches : garder à bord le temps réel dur et les comportements de repli sûrs ; ne déporter que ce que votre SLA de latence et la fiabilité de votre radio peuvent honnêtement prendre en charge.

Les modèles vision-langage-action rencontrent l’embarqué

Les modèles VLA sont aujourd’hui le pont entre « des robots qui suivent des scripts » et « des robots qui suivent des consignes en langage naturel ». Un VLA prend des images de caméra (et souvent la proprioception) ainsi qu’une instruction en langage naturel, et produit des actions : consignes articulaires, torseurs de l’effecteur ou tokens d’action discrets.

De RT-2 aux VLA embarqués

RT-2 de Google DeepMind (2023) a montré que des modèles vision-langage entraînés à l’échelle du web pouvaient être co-affinés pour émettre des actions robotiques sous forme de tokens, améliorant la généralisation sur des objets et des scènes inédits. Selon DeepMind, RT-2 a environ doublé le taux de réussite sur des scénarios nouveaux par rapport à RT-1 dans leurs évaluations (environ 62 % contre 32 % sur la série de scénarios inédits qu’ils mettent en avant). Ces travaux ont prouvé l’idée des VLA. Ils n’ont pas prouvé qu’un transformer de plusieurs milliards de paramètres avait sa place dans l’enveloppe thermique de chaque robot.

En 2025-2026, le domaine s’est scindé en deux voies :

• Les VLA phares, optimisés pour la capacité (souvent adossés au cloud ou à des serveurs lors des démos).
• Les VLA embarqués, optimisés pour la latence locale et une connectivité intermittente.

Gemini Robotics On-Device de DeepMind (annoncé en juin 2025) s’inscrit explicitement dans la seconde voie : un VLA « optimisé pour s’exécuter localement sur les appareils robotiques », utile pour les tâches sensibles à la latence et les environnements à connectivité « intermittente ou nulle ». DeepMind fait état d’une grande dextérité (ouvrir la fermeture éclair d’un sac, plier des vêtements…), d’une adaptation avec seulement 50 à 100 démonstrations, et d’expériences de transfert entre incarnations (dont le Franka FR3 et l’humanoïde Apollo d’Apptronik) dans le cadre d’un programme de testeurs de confiance. La gamme Gemini Robotics On-Device 2 qui a suivi prolonge la même thèse : conçue pour les contraintes réseau et l’exécution locale.

Piles ouvertes : OpenVLA, π₀ et silicium de classe Jetson

Les écosystèmes ouverts comptent, car une flotte ne peut pas dépendre d’une seule clé d’API.

• Les modèles de type OpenVLA (VLA d’environ 7 milliards de paramètres bâti sur une pile VLM Prismatic avec des backbones linguistiques de classe Llama et des encodeurs visuels modernes) ont popularisé le contrôle par tokens d’action pour les bras de recherche. Le Jetson AI Lab de NVIDIA documente l’exécution de ces VLA sur des flux caméra avec des outils orientés TensorRT — utile, mais le décodage autorégressif token par token est souvent trop lent pour un contrôle à haute fréquence sans optimisation poussée.
• La lignée π / OpenPi de Physical Intelligence (dont les VLA à flow matching π₀ et π₀.₅) a imposé un autre mode de génération : prédire des segments d’actions en quelques étapes de débruitage plutôt que token par token. Les tutoriels du Jetson AI Lab de NVIDIA pour π₀.₅ sur Jetson AGX Thor font état d’une latence de bout en bout d’environ 49 ms avec TensorRT FP8 + NVFP4 (contre environ 132 ms en PyTorch BF16 dans leur tableau pour une configuration pi05_libero) — le genre de chiffre qui commence à ressembler à de la manipulation en boucle fermée plutôt qu’à une démo sur diapo.
• Des travaux système indépendants (par exemple la série de recherches « Running VLAs at Real-time Speed ») montrent qu’une ingénierie soignée peut ramener l’inférence multivue de classe π₀ à quelques dizaines de millisecondes sur un seul GPU haut de gamme — preuve que la robotique IA embarquée relève autant du savoir-faire en compilateurs et runtimes que de la recherche sur les modèles.
• La prépublication VLA-HWBench (qui mesure de nombreux VLA ouverts sur du matériel Jetson AGX Thor et de classe AMD Ryzen AI Max) confirme une leçon pratique : la manière dont un VLA génère ses actions (segments par flow matching ou tokens autorégressifs) pèse davantage sur la latence que le nombre brut de paramètres.

Pour les concepteurs, la check-list durable est simple : privilégier des représentations d’actions qui émettent un court horizon de commandes continues en quelques étapes ; quantifier agressivement (FP8 / NVFP4 / INT4 tant que la précision tient) ; fusionner les noyaux ; et profiler le prétraitement CPU — car une fois les noyaux GPU accélérés, la gestion des images côté hôte devient le nouveau goulot d’étranglement.

Robots humanoïdes : des pixels au couple, sans fil à la patte

Les humanoïdes amplifient chaque contrainte de l’embarqué. Ils combinent équilibre, mains dextres, perception multicaméra et présence humaine à proximité : une politique de contrôle qui cale n’est pas seulement une prise ratée, c’est un incident de sécurité.

Le Figure 03 de Figure (octobre 2025) est un exemple commercial concret de matériel conçu autour d’une pile VLA propriétaire (Helix). L’annonce de Figure met en avant :

• Une architecture de caméras pensée pour le contrôle visuomoteur à haute fréquence — avec une cadence d’images doublée, une latence divisée par quatre et un champ de vision par caméra environ 60 % plus large que la génération précédente.
• Des caméras dans la paume pour le contrôle rapproché lorsque les caméras du torse sont masquées.
• Une détection tactile au bout des doigts assez sensible pour percevoir des forces de l’ordre de trois grammes, afin d’anticiper le glissement.
• Un délestage de données mmWave à 10 Gbit/s pour l’apprentissage de flotte — nuance importante : ce délestage haut débit sert aux données d’entraînement et à l’amélioration, pas à remplacer la boucle de contrôle temps réel.
• Une recharge inductive sans fil (Figure cite une station d’accueil de 2 kW) pour que les cellules commerciales gardent les robots en rotation.

Ces détails comptent pour le récit de l’IA incarnée hors ligne, car ils montrent le schéma qui s’impose dans l’industrie : la captation à haute fréquence et l’exécution de la politique sur le robot ; les gros tuyaux, une fois à quai, pour améliorer le modèle suivant.

Les analyses sectorielles du calcul des humanoïdes (y compris celles consacrées aux piles NVIDIA/Arm dans les déploiements d’humanoïdes) reviennent toujours à la même architecture : inférence embarquée pour la locomotion et la manipulation ; serveur local de proximité optionnel pour le raisonnement plus lourd ; cloud pour l’apprentissage de flotte. Qu’une démo donnée soit entièrement hors ligne doit être vérifié dans les notes techniques des fabricants — un livestream marketing n’est pas un dossier de sécurité —, mais la direction ne fait aucun doute.

Véhicules autonomes : les pionniers de l’inférence IA hors ligne

Voitures et robotaxis ont tranché le débat « pas de cloud dans la boucle » des années avant que les VLA n’aient un nom. On ne peut pas appeler un data center pour classifier une voiture qui se rabat dans un tunnel.

Les plateformes de véhicules autonomes modernes industrialisent cette leçon :

• Des piles de perception de recherche et de production sur des SoC de classe NVIDIA DRIVE Orin ont publié des chaînes de perception multicaméra en vue de dessus avec une latence totale mesurée de l’ordre de 19 ms (environ 53 images/s) pour un réseau de type NVAutoNet à huit caméras sur le GPU embarqué d’Orin — une illustration de la barre temps réel que la perception doit franchir avant que planification et contrôle ne consomment le reste du budget.
• NVIDIA DRIVE AGX Thor, disponible commercialement selon les documents de 2025, étend la logique embarquée à l’IA générative et multimodale à bord. La documentation développeurs de NVIDIA compare Thor à Orin avec un débit de crête en apprentissage profond INT8 d’environ 1 000 contre 254 (dans les unités publiées par NVIDIA), des performances CPU supérieures et une sécurité visant jusqu’à l’ISO 26262 ASIL-D, le logiciel DriveOS évoquant explicitement des VLA, LLM et VLM exécutés dans le véhicule. Les tableaux du DriveOS LLM SDK listent parmi les exemples de LLM/VLM embarqués pris en charge des variantes Llama 3.x et Qwen2-VL en quantification FP16 / INT4 / FP8 / NVFP4.

Les véhicules continuent d’appeler la maison pour les cartes, la télémétrie et les mises à jour de modèles. Ils ne sous-traitent pas la boucle d’évitement de collision. Cette séparation — inférence IA hors ligne pour la politique de conduite, services en ligne pour tout le reste — est le modèle que les usines copient désormais pour les manipulateurs mobiles et les humanoïdes.

Concevoir pour la compétence hors ligne (le guide durable)

Que vous livriez un AMR d’entrepôt, un humanoïde ou une pile pour véhicule, les règles de conception durables sont les mêmes.

1. Séparer la sécurité de l’« intelligence »

Gardez arrêts d’urgence, géorepérages, limites de couple et chiens de garde en dehors de la politique neuronale. Les runtimes d’IA embarquée utilisés en robotique industrielle mettent de plus en plus en avant une application des règles de sécurité qui continue même quand les modèles déraillent. Les textes orientés normes sur l’IA embarquée sous sécurité fonctionnelle insistent sur un budget de latence dans le pire des cas (par exemple à un percentile élevé), et non sur les temps moyens d’une démo.

2. Budgéter la boucle, puis choisir le modèle

Partez de la fréquence de contrôle requise (par exemple quelques dizaines de Hz pour des segments de manipulation, davantage pour les boucles de couple internes). Remontez jusqu’à la latence maximale admissible pour le modèle. Si un VLA ne tient pas le budget après TensorRT et quantification, réduisez le modèle, raccourcissez l’horizon d’action, ou déportez uniquement le planificateur lourd vers un GPU de proximité locale sur un réseau déterministe — pas vers une région cloud en best effort.

3. Faire de la connectivité un atout, pas une dépendance

Utilisez le cloud pour :

• l’entraînement par imitation / RL et la simulation ;
• le délestage des jeux de données de la flotte (téléversements à quai façon Figure) ;
• les assistants sémantiques non critiques ;
• le déploiement OTA progressif de modèles signés.

Gardez à bord :

• la perception utilisée pour l’évitement de collision et l’équilibre ;
• la génération d’actions VLA à court horizon ;
• les modes locaux de fonctionnement dégradé sûr.

4. Mesurer ce que ressentent les opérateurs

Suivez la chaîne de bout en bout : exposition caméra → prétraitement → modèle → commande → actionneur. Les outils et articles de la littérature sur les systèmes VLA montrent qu’après optimisation GPU, le prétraitement CPU peut devenir dominant. Les équipes de robotique IA embarquée qui ne surveillent que les FLOPs du modèle passent à côté de la régression.

5. Planifier le partage de façon délibérée

Les résultats de Microsoft sur le déport mettent en garde contre les deux extrêmes. Le tout-embarqué peut épuiser les batteries et imposer des modèles plus faibles. Le tout-déporté peut laisser le robot en plan au moindre hoquet du Wi-Fi. Les flottes gagnantes documentent quels modules peuvent quitter le châssis, et sous quels SLA.

Ce qui a toujours sa place dans le cloud

Même un robot farouchement hors ligne a besoin du cloud sur le long terme :

• L’entraînement des modèles de fondation sur des corpus de plusieurs milliers d’heures (jeux de données à l’échelle d’Open X-Embodiment et flottes de téléopération des fabricants).
• La simulation, à un volume qu’aucun robot ne pourrait vivre en une nuit.
• L’apprentissage inter-flottes et les tableaux de bord d’évaluation.
• La supervision humaine à grande échelle — une surveillance à distance qui ne fait remonter que les cas ambigus.

La communication robotique de DeepMind continue d’ailleurs de proposer des modèles Gemini Robotics plus grands aux développeurs qui veulent une capacité maximale sans les limites de l’embarqué. Cette franchise est utile : l’IA incarnée hors ligne n’est pas anti-cloud ; elle est contre le cloud dans la boucle interne.

En résumé

Les robots et les véhicules n’échappent pas à la météo du réseau. La physique du contact, de l’inertie et du trafic exige une inférence IA hors ligne pour tout ce qui touche aux moteurs et aux freins. Les VLA — de RT-2, qui a prouvé que le langage pouvait devenir action, à Gemini Robotics On-Device, aux modèles de recherche de classe OpenVLA et aux politiques à flow matching de type π₀.₅ sur Jetson Thor — convergent vers la même vérité de déploiement : la capacité doit être comprimée dans l’enveloppe de latence et d’énergie du corps qui porte les capteurs.

Appelons cette pile par son nom : la robotique IA embarquée au service de l’IA incarnée hors ligne. Placez les réflexes et les VLA à court horizon à bord. Recourez aux GPU de proximité locale quand la batterie et la taille du modèle l’exigent et que le réseau est conçu pour, pas simplement espéré. Réservez le cloud public à l’apprentissage et à l’intelligence de flotte. Concevez chaque produit pour que, le jour où la liaison montante disparaît, la machine reste une machine — et non un client léger attendant la permission de bouger.

À lire aussi

• L’IA embarquée en 2026 : NPU, modèles locaux et cloud
• Modèles vision-langage-action : la nouvelle couche fondatrice des robots
• Les humanoïdes à l’usine : des vidéos de démo aux équipes complètes

Images : illustrations originales créées pour AndBeyond.Tech ; aucun logo ni aucune personne réelle n’y figurent.