Gemini Robotics 2 : ce que montrent les chiffres de DeepMind

Ce qu'est vraiment Gemini Robotics 2

La dénomination ne rend service à personne ici, donc voici la version simple. « Gemini Robotics 2 » est à la fois le nom de la famille et le nom d'un modèle spécifique au sein de cette famille. Trois modèles sont sortis ensemble le même jour, et chacun fait un travail différent.

Cette séparation compte, car c'est exactement l'architecture que je dessinerais pour tout système d'agents sérieux. Un modèle raisonne sur ce qu'il faut faire, et suit si cela a fonctionné. Une pièce séparée, plus rapide, s'occupe de l'exécution. DeepMind précise explicitement qu'ER 2 « transmet l'exécution motrice à n'importe quel modèle vision-langage-action (VLA) de niveau inférieur donné », c'est-à-dire que le planificateur reste délibérément agnostique quant aux mains.

Un détail dans la documentation change la perspective sur tout ça : ER 2 est construit sur Gemini 3.5 Flash. Pas une dérivée de niveau Pro. Pas non plus une architecture sur mesure. C'est un modèle de classe Flash, avec du raisonnement spatial, la localisation de moments dans une vidéo et l'orchestration multi-robot ajustés par-dessus. Quiconque a suivi Gemini 3.6 Flash sait déjà à peu près à quoi ressemble le budget de calcul sous-jacent, et la gamme Flash-Lite raconte la même histoire.

Le pointage et le travail sur les coordonnées viennent de la même lignée que la vision agentique de Gemini. Et si vous évaluez toute la famille, je tiens à jour une liste d'alternatives à Gemini.

L'affirmation du contrôle du corps entier est réelle, et vaut la peine d'être clarifiée. Les versions précédentes ne contrôlaient que le haut du corps de l'humanoïde, pour du travail de table. Celle-ci contrôle aussi les jambes. Le prompt de démo publié par DeepMind est « mets l'arrosoir dans le bac vert de l'étagère du bas », et l'Apollo 2 d'Apptronik marche jusqu'à la table, ramasse l'arrosoir, se déplace jusqu'aux étagères et le pose. Le même checkpoint de modèle pilote aussi un Franka Duo équipé de pinces à deux doigts, ce qui est la partie la plus discrètement impressionnante de tout ça.

Les chiffres que DeepMind a publiés sur lui-même

Voici le tableau complet, exactement comme DeepMind l'a rapporté. Les trois groupes de compétences fonctionnent sur un seul checkpoint partagé, sur trois corps de robot différents, et c'est pourquoi la dispersion ici est intéressante plutôt que gênante.

Lisez ensemble le haut et le bas du groupe à plusieurs doigts, car cette seule paire raconte toute l'histoire de l'état de l'apprentissage robotique en 2026. Dévisser une ampoule, c'est 92%. En revisser une, c'est 36%. Les deux utilisent la même main SharpaWave à cinq doigts et 22 degrés de liberté, sur le même robot. Ce qui change, c'est le mouvement. Dévisser est souple et tolérant ; revisser demande de maintenir un alignement tout en appliquant un couple. L'un, c'est une prise. L'autre, c'est un problème de contrôle.

Le groupe pince bat le groupe main presque partout, et c'est le deuxième point qui vaut la peine qu'on s'y arrête un instant. Une pince Robotiq à deux doigts sur le Franka Duo atteint 89,6% en insertion de précision, tandis que la main anthropomorphe n'obtient que 40% sur un sac ziplock. Plus de degrés de liberté ont acheté de moins bons résultats sur le travail fin. Au moins pour l'instant.

Et DeepMind l'a dit lui-même. La légende du graphique indique : « Bien que Gemini Robotics 2 atteigne un taux de réussite moyen à élevé pour les tâches dextres corps entier et à base de pince, la manipulation dextre à plusieurs doigts reste difficile. » Ailleurs sur cette même page : « nos robots ont encore des progrès à faire en vitesse de mouvement », la dextérité au niveau humain étant présentée comme un objectif et non une affirmation.

Pourquoi un seul chiffre mélangé aurait tout caché

Faites la moyenne de ces cinq tâches à plusieurs doigts en un seul chiffre, et vous atterrissez quelque part au milieu des quarante, sans avoir rien appris. Vous ne sauriez pas que le modèle est presque résolu sur un mouvement et à peine fonctionnel sur un autre. Vous ne sauriez pas non plus autour de quelle tâche éviter de concevoir votre produit.

Ce n'est pas du tout un problème de robotique. C'est l'état par défaut du marketing IA dans toutes les catégories, la mienne incluse, où un seul chiffre de déflexion de niveau 1 cache exactement la même dispersion. Déplacez vous-même les chiffres et regardez à quel point il est facile de piloter le titre :

Essayez « Seulement les 4 flatteuses » et il en sort un chiffre que n'importe quelle équipe marketing imprimerait avec plaisir. Même modèle, même jour, même laboratoire. Rien n'a été fabriqué pour le produire. C'est le tour de passe-passe, et il est à la disposition de tout fournisseur qui rapporte un seul chiffre.

Le chiffre le plus intéressant parle des humains, pas des robots

Enfoui dans les benchmarks d'ER 2 se trouve une comparaison que DeepMind fait de trois façons. Elle mesure à quel point le modèle de raisonnement dirige bien un exécutant en aval, et ce qui change, c'est cet exécutant : d'abord un robot réel, puis un simulé, puis un télé-opérateur humain.

Le même planificateur est 14 points meilleur pour diriger une personne que pour diriger un robot. Le modèle n'est pas moins bon dans l'un des deux cas. L'humain de l'autre côté absorbe simplement l'ambiguïté, se remet d'une mauvaise prise, complète l'intention que l'instruction a laissée de côté.

Un commentateur Reddit qui regardait les images de la démo est arrivé de l'extérieur à la même conclusion :

"The bottleneck seems to be software. So until we get ai good enough to pilot a robot, it's going to remain slow.

If you see robots piloted by humans, they are much faster."

u/dranaei, Reddit

C'est la découverte que j'accrocherais à un mur, et ce n'est pas vraiment une découverte de robotique. C'est l'argument du copilote IA avec un chiffre attaché. Un modèle qui planifie puis passe la main à un humain compétent surpasse le même modèle pilotant l'effecteur final seul, et l'écart est mesurable. Dans le travail de support, c'est la différence entre un agent qui rédige une réponse pour que quelqu'un l'envoie, et un agent qui répond de lui-même. La réponse honnête sur ce qui fonctionne le mieux est la même que celle de DeepMind : celle avec une personne dans la boucle, jusqu'à ce que les chiffres par tâche disent autre chose.

Rien de tout cela n'est un argument contre l'autonomie. C'est un argument pour connaître le chiffre avant de choisir, et ce chiffre évolue vite, assez vite pour que les meilleurs agents IA d'il y a six mois ne soient pas ceux que vous choisiriez aujourd'hui.

Le reste de l'ensemble de comparaison d'ER 2 est solide, et cela vaut la peine d'être rapporté équitablement :

La classification de la progression est la marge la plus large de toute la page : 57,4% contre 46,2% pour le meilleur modèle non robotique. L'indicateur mesure « pouvez-vous dire où vous en êtes dans une tâche », noté par image dans cinq catégories. Peu glamour, et c'est exactement ce qu'un agent doit savoir avant de décider de continuer ou de demander de l'aide. DeepMind rapporte aussi une précision de 91,3% pour la localisation de moments, avec une distance moyenne absolue de 0,96 seconde, à 4 fois la vitesse d'exécution des catégories de modèles plus grands.

Il convient aussi de noter que ces mêmes 57,4% signifient qu'il se trompe sur la progression environ quatre fois sur dix. Le meilleur de sa catégorie, et il se trompe pourtant aussi souvent, ce qui est un état normal dans ce domaine. C'est aussi exactement le genre de chose qu'une affirmation d'une ligne sur l'« état de l'art » efface.

Le bond de sécurité dont personne ne parle

C'est le chiffre qui m'a fait me redresser. Je ne l'ai vu couvert nulle part encore.

Gemini Robotics ER 1.6 respectait les instructions de sécurité 47,2% du temps. Ce modèle est sorti en avril 2026, donc il y a quatre mois, et il se classait sous Opus 5 et sous GPT 5.6 Sol sur les deux indicateurs de sécurité. Un modèle ajusté pour la robotique, moins bon en sécurité robotique que les modèles de texte à usage général auxquels il a été comparé.

ER 2 corrige cela en profondeur, jusqu'à 97,9% et 93,0%. Bien. La leçon utile, cependant, c'est ce que le chiffre de la génération précédente dit sur la confiance accordée à une étiquette de version. « Le dernier modèle de robotique d'un laboratoire de pointe » était, jusqu'à la semaine dernière, quelque chose qui respectait une contrainte de sécurité moins de la moitié du temps. DeepMind a aussi publié un nouveau benchmark pour cela, ASIMOV-Agentic, publié comme un jeu de données public. Il mesure si l'agent de raisonnement refusera un appel d'outil non sûr, s'il peut prédire qu'une tâche est impossible, puis s'il demande de l'aide à un humain quand il n'est pas certain.

Refuser, prédire l'échec, escalader en cas d'incertitude. C'est une meilleure description d'un agent de support bien conçu que ce que réussit la plupart de la documentation d'IA de support, et cela s'applique directement à la gestion de l'escalade. Le transfert est une discipline à part au-dessus de cela, et le transfert de chat est le cas que la plupart des équipes ratent en premier.

Il vaut la peine d'être précis sur les limites ici. Le blog affirme qu'ER 2 est le modèle de robotique le plus sûr de DeepMind à ce jour, mais ne publie aucun score numérique pour les résultats d'ASIMOV-Agentic eux-mêmes. Ceux-ci figurent dans un rapport technique de sécurité séparé. Et la documentation pour développeurs est directe sur où retombe la responsabilité : « il vous incombe de maintenir un environnement sûr autour du robot ».

Ce que ça coûte, et les pièges de la documentation

Seul ER 2 a un prix. Les deux modèles qui touchent au matériel n'en ont aucun, pour la simple raison qu'on ne peut pas les acheter.

Le prix a doublé. ER 2 coûte deux fois plus que ER 1.6, tant en entrée qu'en sortie, bien que le tarif d'entrée plat signifie que le travail à forte composante audio voit une hausse relative plus faible que le travail centré sur la vision. La fenêtre de contexte n'a pas grandi du tout. Il existe aussi un modèle jumeau en streaming, gemini-robotics-er-2-streaming-preview, au même tarif de base, sans palier Batch ni cache.

Quatre choses dans la documentation qui vous coûteront un après-midi si vous ne les lisez pas d'abord :

1. Une clé API sans restriction reçoit un 403 sans appel. La robotique est la seule surface Gemini qui refuse une clé par défaut, donc ajoutez des restrictions dans AI Studio avant votre premier appel.
2. L'endpoint de streaming limite l'entrée image à JPEG, 1 image par seconde. Ce qui paraît étrange face à tout le discours temps réel. Un robot qui diffuse des images de caméra à pas plus d'une par seconde.
3. L'endpoint de streaming abandonne les sorties structurées et l'exécution de code. Le chemin schéma JSON appartient donc au modèle non-streaming, ainsi que le chemin de vision agentique.
4. La documentation recommande un niveau de raisonnement medium pour la latence, mais l'exemple de démarrage rapide est livré avec high. Copiez-collez-le, et vous héritez du réglage par défaut lent.

Il existe aussi une notice de confidentialité attachée à ces modèles, qu'aucune page Gemini ordinaire ne porte. Comme les modèles « exploitent des données vidéo et audio pour faire fonctionner et déplacer votre matériel », Google exige que vous ne laissiez pas de personnes identifiables présentes autour du robot avant qu'elles n'aient été informées et n'aient donné leur consentement, et demande en plus un flou du visage. Mettez ça en regard du « utilisé pour améliorer nos produits : oui » du palier gratuit. Un robot du palier gratuit avec une caméra pointée sur des personnes devient alors un problème de consentement, pas de quota.

Et une note d'agenda qui vaut la peine d'être notée : gemini-robotics-er-1.6-preview s'arrête le 31 août 2026. ER 1.5 a déjà été retiré en avril. Donc, deux endpoints retirés en un an, et tout le code de modèle actuel porte encore un suffixe -preview, sans aucun alias stable sur lequel se fixer.

S'adapter à de nouveaux robots, et la partie multi-robot

Gemini Robotics On-Device 2 est la pièce que je trouve la plus discrètement importante. Il fonctionne localement, hérite du travail de transfert de mouvement de Gemini Robotics 1.5, et s'adapte à un robot bi-bras entièrement nouveau « avec seulement quelques heures de temps d'adaptation, généralement moins de 200 exemples ». Nouvelles formes, nouveaux capteurs, degrés de liberté qui ne correspondent pas.

Moins de 200 démonstrations pour mettre en service un nouveau corps de robot, c'est le chiffre qui change l'économie du domaine. Les tâches de cette grille ont tourné sur des plateformes Dexmate, SO101 et Trossen, aucune n'étant l'humanoïde phare. Un panneau montre un bras robotique cliquant sur une case « je suis un robot », ce que je suppose être une blague, et que j'apprécie.

La collaboration multi-robot est l'autre nouvelle capacité. Des robots qui communiquent, reconnaissent les forces physiques de l'autre, puis se délèguent des tâches entre eux. Dans la démo, un humanoïde Apollo 2 travaille aux côtés d'un bras Franka, avec un écran montrant ce que voit le modèle.

DeepMind a remercié Apptronik, Boston Dynamics et Agile Robots comme partenaires, et dans une démo séparée, un Spot de Boston Dynamics va chercher du popcorn via des API Spot orchestrées. Côté matériel : Apptronik a levé une série A-X de 520 millions de $ en février 2026, portant son total à près de 1 milliard de $. Il vaut la peine de signaler qu'Apollo 2 est une plateforme de collecte de données, pas l'unité commerciale. La commerciale est Apollo 3, et elle n'a pas de date annoncée. Aucune spécification publiée et aucun prix publié, chez aucun des quatre fournisseurs de matériel impliqués.

Ce que les praticiens ont vraiment dit

Le fil Hacker News a atteint 619 points et 553 commentaires, et c'est une meilleure lecture que n'importe quelle couverture médiatique. Le commentaire le plus utile là-bas venait de quelqu'un qui travaille sur ces modèles :

"Plus we have no good reliable accuracy testing data in most cases (most tests occur on a few demos, but that isn't a good representation of how must things work), popular benchmarks, such as libero have been saturated, and nearly everything gets 95% there, most companies and researchers have their own benchmarks here."

adityashankar, Hacker News

Des benchmarks saturés, et tout le monde qui note son propre devoir. Cela décrit aussi l'évaluation de l'IA logicielle, presque mot pour mot, et c'est pourquoi les propres recommandations d'évaluation d'OpenAI misent tellement sur la construction de son propre jeu d'évaluation plutôt que sur la confiance dans un classement public.

La critique la plus acérée ne porte pas du tout sur le modèle. Elle porte sur la grammaire vidéo :

"This is why we need long continuous shots of robots interacting doing tasks, rather than the sizzle reels with 5 second shots. The long shots tell the true story of how far along the technology is, while the short shots make it look way more advanced than it really is. Still, great to see the progress being made."

u/edgroovergames, Reddit

Un commentateur HN est allé plus loin, qualifiant les démos de « pick and place glorifié avec de faibles taux de réussite sur un robot inutilement complexe », et disant qu'il préférerait les images ouvertement télé-opérées d'un concurrent, car elles étaient plus proches d'un déploiement réel. Sévère. Pas non plus déraisonnable, étant donné les 45,7%.

Ce chiffre de 36% a ensuite été repris comme preuve d'un argument plus large :

"A 36% success rate on screwing in a light bulb means there's probably something to LeCunn's take that VLM/VLA models aren't going to be the thing powering tomorrow's robots, but only time will tell."

cowboy_henk, Hacker News

La meilleure réplique est arrivée en une ligne, et c'est celle sur laquelle je parierais :

"It's still very early days. There are many benchmarks that LLMs scored 36% on just 18 months ago that they're now at 100% on."

heaney-555, Hacker News

Et puis un roboticien, expliquant pourquoi « lent et prudent » est une classe de problème différente de « rapide et fluide » :

"An algorithm to fold tshirts 90% of the time is easy. The cloth hangs down by gravity and you can just look for right angles (corners), find their coordinates with binocular matching, and move them to meet each other. Getting 99%, or folding them quickly, so that the fabric is actually moving instead of just hanging still- incredibly, incredibly more complex."

hwillis, Hacker News

Il y avait aussi une bonne dose de « Figure ne l'avait pas déjà montré ? » là-dedans, ce qui m'amène à la comparaison qui compte vraiment.

Personne d'autre ne publie ce tableau

Je suis allé chercher les chiffres équivalents par tâche de tous les autres laboratoires de ce domaine. Voici ce qui est public, tout ça.

DeepMind est le seul à avoir mis des taux d'échec absolus par tâche sur sa propre page de lancement. Figure nomme des tâches de dextérité et montre un passage de quatre minutes avec un lave-vaisselle en vidéo, sans y attacher aucun chiffre. Tesla n'a jamais nommé de modèle Optimus, jamais du tout. Physical Intelligence trace bien des taux par tâche, mais par rapport à une référence de spécialiste en RL, et avec des valeurs affichées côté client plutôt qu'énoncées.

Donc la lecture honnête de Gemini Robotics 2 n'est pas « le robot de Google est en retard ». Google est le seul à montrer où se trouve réellement son robot, et se fait ensuite critiquer pour les chiffres qu'il a choisi de divulguer. C'est une mauvaise incitation. Si cela persiste, le prochain laboratoire se contentera de publier des vidéos.

Ce que cela signifie si vous achetez des agents IA

Je ne travaille pas sur les robots. Je construis des agents IA qui gèrent des tickets de support, et cette sortie a bel et bien changé ce que je pense qu'un fournisseur devrait être obligé de me montrer.

Il y avait un client, une équipe danoise B2B de télématique automobile traitant environ 200 tickets par mois sur Zendesk et montant vers 2 000, dont l'agent a commencé à dire avec assurance aux clients « oui, nous prenons en charge votre modèle de voiture » pour des marques qui n'étaient pas dans leur base de données. La base de connaissances disait « nous prenons en charge tous les modèles ». Le bot l'a cru. Leur propre résumé de cette configuration initiale était « des essais et erreurs au début ». Ce type de ticket aurait obtenu un zéro pointé dans un tableau par tâche, et dans le chiffre mélangé il était simplement invisible. C'est la forme d'échec ordinaire dans l'automatisation du service client, rien d'exotique, et c'est pourquoi la prévention des hallucinations est plus une question de configuration que de modèle.

C'est pourquoi chaque déploiement eesel exécute d'abord une simulation sur l'historique de tickets propre au client. On prend un lot de tickets résolus, on génère ce que l'agent aurait dit, on compare cela à ce que l'humain a réellement envoyé, on note le tout, puis on produit un rapport d'écart avant qu'un seul client réel ne soit impliqué. C'est le tableau de DeepMind, sauf qu'il est construit à partir de vos tickets plutôt que d'ampoules. Une responsable CX dans une marque de compléments D2C a formulé cette exigence mieux que je ne le pourrais :

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Trois choses que je retiendrais de cette sortie pour tout achat d'agent IA, physique ou pas :

1. Demandez le tableau par tâche, pas le titre. Quand un fournisseur cite un seul chiffre de déflexion, demandez qu'il soit ventilé par intention ou par type de ticket. La vérité se trouve dans la dispersion, et les indicateurs de performance de l'IA ne sont utiles qu'à ce niveau de granularité. Même chose pour la résolution au premier contact.
2. Testez sur votre propre historique avant la mise en production. Un benchmark réalisé sur les tâches de quelqu'un d'autre ne prédit rien sur les cas limites de votre politique de remboursement. Le même instinct que les tests adversariaux, et la raison pour laquelle évaluer les agents vaut mieux que de faire confiance à une démo.
3. Concevez pour la tâche à 32%, pas celle à 92%. Sachez quel travail l'agent devrait refuser. Fixez des seuils de confiance délibérément, gardez le transfert propre. Prévenir une réponse fausse énoncée avec assurance vaut plus qu'un point de couverture.

Ce dernier point est tout l'enjeu. Un agent qui résout 60% des tickets puis escalade proprement le reste est un meilleur produit que celui qui vise 100% et se trompe sur un sur cinq, et les clients me le disent constamment. Le calcul du coût par résolution est aussi meilleur, une fois que vous intégrez le coût des tickets qu'une mauvaise réponse crée.

Si vous voulez le tableau de mesure complet, mon article sur l'évaluation du service client va plus loin que ce que je peux faire ici, tout comme la comparaison coût agent contre humain. Et si vous choisissez encore un modèle de base, quel LLM convient au support est une meilleure question de départ que n'importe quel benchmark de robotique.

Essayer eesel

Si vous cherchez un logiciel de service client agentique, et que vous voulez l'honnêteté par tâche que cet article défend sans arrêt, c'est plus ou moins ce pour quoi eesel a été conçu. Il se branche sur Zendesk ou tout autre helpdesk que vous utilisez déjà, Freshdesk inclus. Il apprend de vos macros et de vos anciens tickets. Puis il fait tourner une simulation sur votre historique réel, pour que vous puissiez voir la forme de sa précision par type de ticket avant qu'il ne réponde jamais à un client.

La différence concrète : vous décidez quels types de tickets il touche et lesquels il laisse tranquilles, et vous obtenez des compteurs d'approbation et de rejet par action plutôt qu'un seul pourcentage de déflexion. Gridwise a vu 73% des demandes de niveau 1 résolues dès le premier mois, et savait quels étaient les 27% restants. La tarification se fait par ticket, donc vous n'achetez pas de sièges pour un agent qui ne gère qu'une tranche de la file.

Essayez eesel gratuitement, ou pointez-le simplement sur cent de vos anciens tickets et voyez ce que dit le rapport d'écart.