NVIDIA détaille les plans NemoClaw qui conservent les cadres d’agents et encadrent les outils avec OpenShell

Le 30 octobre 2026, NVIDIA a présenté des plans ouverts NemoClaw réunissant le cadre d’agent choisi par le développeur, des modèles Nemotron, des outils NeMo d’optimisation et d’observation, et l’environnement OpenShell chargé de contrôler les accès. Le billet cite OpenClaw, Hermes Agent et LangChain Deep Agents parmi les cadres actuellement pris en charge et précise qu’un plan assemble une pile autour du cadre, sans le remplacer ni devenir lui-même l’environnement sécurisé. Notre édition du 2 novembre traite cette explication technique, pas le lancement initial de NemoClaw en mars.

La distinction entre les couches est essentielle. Le modèle produit du texte et des décisions; le cadre définit les outils, les compétences, la mémoire et l’enchaînement des tâches; l’environnement d’exécution limite les fichiers, les réseaux et les identifiants accessibles. Les plans NemoClaw assemblent ces éléments avec des composants de mesure et d’optimisation. NVIDIA indique explicitement que NemoClaw n’est ni un cadre concurrent ni un environnement d’exécution autonome. Une équipe qui utilise déjà un des trois cadres peut donc essayer d’ajouter un modèle réglé et une gouvernance sans réécrire toute la logique de son agent. Cela ne garantit pas la compatibilité de chaque extension ou version: les dépendances et les autorisations réelles restent à tester.

Le texte attribue des rôles distincts aux trois cadres. OpenClaw peut agir sur des fichiers et des applications, écrire du code et conserver du contexte entre les sessions. Hermes Agent transforme les corrections et les procédures répétées en compétences réutilisables. LangChain Deep Agents apporte la planification, le contexte géré par fichiers, la mémoire et la délégation. Tous déterminent comment l’agent travaille, mais la capacité d’appeler un outil ne définit pas à elle seule une frontière de permissions convenable en production. Avant de choisir un plan, il faut inventorier les outils et l’état conservé, puis traduire chaque besoin en règles OpenShell explicites pour les fichiers, les destinations réseau et les secrets. Les permissions larges d’un poste de développement ne devraient pas être transférées tacitement.

Les plans associent également les modèles ouverts Nemotron aux outils NeMo. NVIDIA présente NeMo Relay comme un moyen d’observer et d’améliorer l’exécution, et évoque un routage destiné à aider le débit, le coût et la fiabilité. Observer une action ne signifie pas empêcher automatiquement toutes les erreurs; optimiser le modèle et le cadre ne remplace pas les restrictions de l’environnement. Une évaluation sérieuse commence par le moindre privilège et une trace vérifiable, puis mesure sur de vraies tâches le taux de réussite, la latence, le coût et les refus. Les pages récupérées, les fichiers d’un dépôt et la mémoire de l’agent restent des entrées non fiables: leur contenu ne doit jamais pouvoir augmenter l’accès au réseau ou révéler des identifiants.

NVIDIA prend l’exemple de LangChain, qui a adapté les consignes, les outils et les intergiciels de Deep Agents à Nemotron 3 Ultra sans réentraîner le modèle. La société rapporte une performance proche de modèles de pointe pour un coût par exécution environ dix fois moindre que celui de grands modèles fermés. C’est une comparaison attribuée au fournisseur et à son partenaire pour une configuration particulière, pas une économie universelle démontrée sur toutes les tâches, machines et méthodes de facturation. Le résumé du billet ne fournit pas un dénominateur par tâche et une réplication indépendante complets. Un acheteur devrait mesurer le coût par exécution réussie sur ses propres tâches, avec le même barème, au lieu de comparer un tarif ou une démonstration isolée. Le résultat porte sur le couple cadre-modèle, non sur de nouveaux poids du modèle seul.

Pour essayer la pile, on peut suivre la documentation et les exemples officiels dans un environnement isolé. Il faut noter les versions du cadre et du modèle, l’inventaire des outils, les règles OpenShell et les paramètres de télémétrie avant le test. Le protocole doit inclure des tâches autorisées et des demandes de fichiers, réseau ou identifiants qui doivent être refusées, y compris des instructions malveillantes insérées dans un document consulté. La comparaison avant et après doit garder les mêmes tâches et critères de réussite; un bon score fonctionnel ne prouve pas la maîtrise des accès. En production, il faut également désigner les responsables des journaux, des alertes, des approbations humaines et du retour arrière. La mention du cloud, du centre de données, du DGX Spark et des machines RTX ne démontre pas des performances ou des règles identiques partout.

Un plan d’architecture ne constitue pas une certification de conformité. Les permissions par défaut, les exceptions, les données sensibles dans les journaux, le comportement des extensions et la dérive des règles après une mise à jour demandent un examen distinct. Si les essais ne couvrent que les tâches qui réussissent, ils ne prouvent pas que les accès interdits sont effectivement bloqués.

L’apport du billet est de placer le cadre existant, le modèle réglé, la télémétrie et une gouvernance d’exécution indépendante dans une même architecture. Le plan fournit un point de départ reproductible; la fiabilité, l’économie et la frontière d’accès doivent encore être vérifiées sur les tâches, permissions et machines de l’exploitant.