Modèles de robots open source contre stacks de fondation fermés
Un guide pratique du débat sur les modèles de robots open source : comment l’écosystème LeRobot se compare aux stacks propriétaires comme Gemini Robotics, et qui en profite.
Téléchargez une policy de robot comme vous téléchargeriez un modèle de langage. C’est à peu près là que la robotique en est arrivée en 2025. LeRobot, de Hugging Face, fournit des poids de modèle, des jeux de données et une boucle d’entraînement qui tourne sur un seul GPU grand public. Physical Intelligence a publié les poids de π0, l’une des policies de manipulation généralistes les plus performantes publiées à ce jour. NVIDIA a placé Isaac GR00T N1 sur le même pied : poids ouverts, plus une recette de post-entraînement ouverte pour les humanoïdes. Un étudiant de troisième cycle et un laboratoire bien financé peuvent désormais partir d’un checkpoint similaire.
Regardez maintenant l’autre moitié du terrain. Gemini Robotics, de Google DeepMind, se présente sous la forme d’une API et d’une courte liste d’intégrations partenaires, pas d’un téléchargement de poids. Figure, 1X et Skild gardent leurs policies à l’intérieur du robot et de l’entreprise. Deux philosophies avancent désormais en parallèle sur le même matériel. La question intéressante n’est pas de savoir laquelle remporte une démo ce trimestre. C’est de savoir laquelle produit des effets cumulés.
Le vrai clivage n’est pas « ouvert contre fermé » dans l’abstrait. C’est un empilement de choix concrets : qui contrôle le modèle, qui peut l’inspecter, qui peut le déployer sans demander la permission et, sous tout cela, qui possède les données dont dépend entièrement la qualité du modèle.
Ce que « ouvert » signifie réellement ici
L’ouverture, dans les modèles de fondation pour robots, comporte au moins quatre niveaux, et presque aucune publication ne les ouvre tous : les poids, le code d’entraînement, la licence et les données. GR00T N1 et π0 sont à poids ouverts et à code ouvert, ce qui vous permet de les affiner et de les héberger vous-même. C’est un cadeau considérable. Mais les corpus sur lesquels ils ont été pré-entraînés ne sont que partiellement divulgués, et les licences varient quant à l’usage commercial qu’elles autorisent.
Comparez cela aux jeux de données véritablement ouverts. Open X-Embodiment a réuni en une seule collection les données de 22 morphologies de robots issues de dizaines de laboratoires, de l’ordre d’un million de trajectoires. DROID y a ajouté environ 76 000 démonstrations téléopérées capturées en conditions réelles dans de nombreuses scènes. RH20T a fait progresser la manipulation multimodale riche en contacts. Ce sont des données ouvertes, et c’est la raison même de l’existence des modèles à poids ouverts. La leçon : la plupart des modèles de robots « ouverts » sont à poids ouverts, non à données ouvertes, et il ne s’agit pas de la même liberté.
Le stack ouvert : LeRobot comme centre de gravité
LeRobot est moins un modèle qu’un puits de gravité. Il standardise un format de jeu de données, héberge des milliers de jeux de données et de policies communautaires sur le Hub, et propose de petits modèles entraînables comme SmolVLA qu’un laboratoire peut exécuter sans cluster. Associez cela à des bras robotiques bon marché et reproductibles, dans une fourchette de $100 à $500, et vous obtenez quelque chose que le stack fermé ne peut pas fabriquer par décret : un substrat commun où l’affinage réalisé par un groupe est directement chargeable par le suivant.
Le bénéfice se cumule. Chaque jeu de données téléversé dans le format commun rend le modèle suivant moins coûteux à entraîner. Chaque policy publiée appelle un benchmark, un rapport de bug, un fork. C’est la même dynamique qui a fait des modèles de langage ouverts un choix par défaut de la recherche, transplantée sur du matériel réel, où la reproductibilité a toujours été misérable.
Les poids ouverts permettent à mille laboratoires de partir du même checkpoint. Ils ne leur donnent pas les mêmes données. C’est là que commence la véritable divergence.
Le stack fermé : l’intégration verticale comme stratégie
Les acteurs fermés ne thésaurisent pas par habitude. L’intégration verticale est le pari. Lorsqu’une seule entreprise possède le matériel, la flotte de téléopération, le modèle et le déploiement, elle contrôle un volant d’inertie de données : chaque heure passée par un robot sur le site d’un client alimente l’entraînement suivant. Gemini Robotics s’appuie sur les modèles multimodaux plus larges de Google et garde les poids derrière une interface. Figure construit son propre VLA pour son propre humanoïde. L’avantage tient à la cohérence et à la vitesse sur une morphologie unique, plus une douve commerciale et un récit plus net sur la sécurité et la responsabilité, puisque personne ne peut forker une policy que vous n’avez jamais livrée.
Le coût, c’est la portée. Un modèle fermé progresse sur les données que son propriétaire peut collecter. Un modèle ouvert progresse sur les données que tout le monde collecte. Sur un horizon suffisamment long, ce sont des courbes de croissance très différentes, et rien n’indique clairement quelle courbe l’emporte pour quelle tâche.
Comparatif : ce que chaque stack vous donne réellement
| Dimension | Stack ouvert (LeRobot, π0, GR00T N1) | Stack fermé (Gemini Robotics, Figure, 1X) |
|---|---|---|
| Accès aux poids | Téléchargeable, auto-hébergeable | API ou sur l’appareil uniquement |
| Données d’entraînement | En partie publiques, plus des jeux ouverts (OXE, DROID) | Propriétaires, non divulguées |
| Personnalisation | Affinage complet sur votre propre robot | Limitée, par l’intermédiaire du fournisseur |
| Déploiement | Aucune permission requise | Lié par contrat et intégration |
| Volant d’inertie de données | Partagé au sein de la communauté | Captif d’un seul opérateur |
| Idéal pour | Recherche, startups, flottes multi-robots | OEM capitalisés livrant une seule plateforme |
Qui en profite, et où se situe le vrai goulot d’étranglement
Pour un groupe de recherche ou une startup en phase d’amorçage, l’ouvert tient de l’oxygène. Affiner π0 ou GR00T sur un jeu de données modeste coûte une erreur d’arrondi à côté du pré-entraînement d’une policy généraliste à partir de zéro, que peu d’acteurs en dehors des plus grands laboratoires peuvent se permettre. Pour un OEM de robots, le calcul est réellement mitigé : une base ouverte réduit la facture du modèle, mais l’avantage durable revient à celui qui possède les données de déploiement ; aussi beaucoup affineront-ils un modèle ouvert sur des données privées et garderont-ils cet affinage fermé. Pour l’acteur en place bien capitalisé, le fermé reste rationnel tant que le volant d’inertie interne devance celui de la communauté. Et pour le domaine dans son ensemble, les jeux de données ouverts sont l’infrastructure silencieuse : sans OXE, DROID et les corpus égocentriques, aucun des deux camps n’aurait une base assez grande pour compter.
Voici ce sur quoi les deux stacks s’accordent, qu’ils le disent tout haut ou non. La contrainte déterminante n’est ni l’architecture du modèle ni la puissance de calcul. Ce sont les données : des enregistrements réels, variés, physiquement ancrés, de corps accomplissant des tâches. Les poids ouverts ne servent à rien si chaque laboratoire effectue son affinage sur les mêmes quelques milliers de trajectoires. Un volant d’inertie fermé ne sert à rien s’il ne voit jamais qu’une seule usine. La robotique n’a pas encore son corpus à l’échelle du web, et l’écart entre les modèles de langage et les modèles de robots est surtout l’écart entre mille milliards de tokens de texte et quelques milliers d’heures de démonstration incarnée.
Où tout cela nous mène
Attendez-vous à ce que les deux stacks se brouillent avant que l’un ou l’autre ne l’emporte. La forme probable des prochaines années : un modèle de base ouvert, affiné sur des données de démonstration privées, déployé dans le cadre d’un contrat commercial. Ouvert là où cela réduit le coût, fermé là où cela protège la marge. Dans ce monde, le levier n’appartient ni à l’éditeur du modèle ni au fabricant de robots, mais à celui qui peut produire des données incarnées à grande échelle et les livrer propres. Surveillez les jeux de données, pas les checkpoints.