---
title: Espérer n’est pas sécuriser : les cinq pièces d’un agent en entreprise
description: À la GTC Berlin, Jensen Huang a découpé un agent IA en cinq pièces : le modèle, le harnais, la sandbox, la connaissance de l’entreprise et ses outils. Son conseil aux entreprises qui se préparent aux agents commence par la sandbox, car aujourd’hui seule une demande polie retient un agent. Notes sur OpenShell, Sentry, l’agent knowledge foundation, et où en sont mes propres agents.
date: 2026-10-23
tags: agents IA, sécurité des agents, NVIDIA, OpenShell, IA en entreprise
---

À la GTC Berlin, le 21 octobre, Jensen Huang a démonté un agent IA en cinq pièces : le modèle, le harnais (harness), la sandbox dans laquelle tourne ce harnais, la connaissance de votre entreprise et vos outils. Son conseil à toute entreprise qui se prépare aux agents commence par la sandbox, pas par le modèle. Aujourd’hui, la seule chose entre un agent et vos clés SSH, c’est un prompt qui lui demande gentiment. OpenShell, la réponse de NVIDIA, place les règles hors de l’agent, là où une politique contrôle chaque fichier, chaque appel système et chaque connexion réseau.

La partie agents de la [keynote](https://www.youtube.com/watch?v=PvFjbPYEOZI&t=2502s) va à peu près de la minute 41 à la minute 66. C’est la checklist la plus claire que j’aie vue sur ce qu’une entreprise doit avoir en place avant que des agents touchent à ses systèmes. C’est aussi la keynote d’un fournisseur, donc je signale les affirmations arrivées sans chiffre. Je fais tourner une flotte d’agents OpenClaw sur un Mac mini, et à la fin je confronte ma propre installation à la liste.

## Un agent, c’est cinq pièces, et une seule est le modèle

Jensen a ouvert sur le grand changement de l’année. Les agents réfléchissent, raisonnent, itèrent et utilisent des outils, et cela brûle une quantité énorme de tokens : la consommation de tokens, selon ses mots, « a explosé », et la demande en GPU avec elle. Selon lui, c’est OpenClaw, dont NVIDIA parlait en début d’année, qui a lancé la vague d’agents open source qu’on voit partout aujourd’hui.

Puis l’anatomie. Le modèle de langage génère des tokens. Le harnais les consomme ; Jensen l’appelle l’exosquelette, et son exemple, c’est OpenClaw. Le harnais vit dans une sandbox qui l’isole du reste du système. Les deux dernières pièces sont la connaissance et les outils.

Le schéma de NVIDIA dessine le harnais comme une boucle : prendre le contexte, raisonner, planifier, agir, puis recommencer, avec la connaissance et les outils branchés en dessous. Le modèle réfléchit. Les quatre autres pièces décident de ce que cette réflexion peut toucher.

<figure class="fd-fig ea ea-loop" aria-labelledby="ea1-cap" data-desc="L’anatomie d’un agent selon NVIDIA, redessinée. En haut, le modèle génère des tokens. Ils alimentent le harnais, que Jensen appelle l’exosquelette, dessiné comme une boucle de quatre étapes : contexte, raisonnement, plan et action, puis retour au contexte. Le harnais vit dans une sandbox qui l’isole du reste du système. Sous la sandbox, le harnais se branche sur les deux dernières pièces : la connaissance de l’entreprise et ses outils. La phrase de Jensen : modèles, sandbox, harnais, connaissance et outils sont les cinq éléments d’un agent.">
<p class="ea-now ea-say4" aria-hidden="true"><span>Contexte</span><span>Raisonnement</span><span>Plan</span><span>Action</span></p>
<div class="ea-anat">
<div class="ea-model"><p class="ea-part"><b>1</b>Modèle</p><p class="ea-sub">génère les tokens</p></div>
<p class="ea-feed" aria-hidden="true"><i></i><i></i><i></i></p>
<div class="ea-sb">
<p class="ea-part ea-part-sb"><b>3</b>Sandbox <span class="ea-sub">l’isole du reste du système</span></p>
<div class="ea-hn">
<p class="ea-part"><b>2</b>Harnais <span class="ea-sub">l’exosquelette</span></p>
<ol class="ea-steps ea-cyc4" aria-label="La boucle du harnais">
<li>Contexte</li>
<li>Raisonnement</li>
<li>Plan</li>
<li>Action</li>
</ol>
</div>
</div>
<p class="ea-stem" aria-hidden="true"><span>&lt;/></span></p>
<div class="ea-base">
<div class="ea-kt"><p class="ea-part"><b>4</b>Connaissance</p><p class="ea-sub">les données de l’entreprise</p></div>
<div class="ea-kt"><p class="ea-part"><b>5</b>Outils</p><p class="ea-sub">ce avec quoi l’agent agit</p></div>
</div>
</div>
<p class="mp-strip"><b>Jensen</b><span>« Modèles, sandbox, harnais, connaissance et outils. Ce sont les cinq éléments d’un agent. »</span></p>
<figcaption id="ea1-cap">La boucle est le dessin du harnais par NVIDIA, redessiné et numéroté dans l’ordre de Jensen. La surbrillance parcourt les quatre étapes ; les carrés sont des tokens.</figcaption>
</figure>

## Le « s’il te plaît » n’est pas un modèle de sécurité

Avant de rendre les agents utiles, dit Jensen, il faut les sécuriser. Un agent est un système autonome qui a accès à des fichiers, des ressources, des réseaux et des outils. Ses privilèges doivent être minimaux, et il doit être surveillé en permanence.

La vidéo qui a suivi contient la meilleure phrase de la keynote. Aujourd’hui, la seule chose qui empêche un agent d’abuser de ses accès, c’est de lui demander gentiment. « S’il te plaît, ne supprime rien. S’il te plaît, ne touche pas à mes clés SSH. » NVIDIA appelle ça l’approche du « s’il te plaît », et y répond en trois mots : « hope isn’t security », espérer n’est pas sécuriser.

J’ai écrit ces prompts. Tous ceux qui font tourner des agents l’ont fait. Le problème, c’est l’endroit où ils vivent : dans le contexte de l’agent lui-même, là où atterrit aussi une injection de prompt venue d’un e-mail ou d’une page web.

La vidéo compare avec les débuts du web. Les virus étaient partout jusqu’à ce que les navigateurs imposent des limites strictes à ce qu’une page pouvait faire. Personne n’a demandé gentiment à la page. OpenShell veut être ce navigateur pour les agents : vous écrivez une politique qui dit ce que chaque agent peut toucher, et elle s’applique aux appels système, aux accès fichiers et aux connexions réseau, en dehors de l’agent, « pas seulement dans les garde-fous du LLM ».

<figure class="fd-fig ea ea-please" aria-labelledby="ea2-cap" data-desc="Deux façons de tenir un agent loin de vos clés SSH. À gauche, l’approche du s’il te plaît : les règles sont des lignes dans le prompt de l’agent, s’il te plaît ne supprime rien et s’il te plaît ne touche pas à mes clés SSH, et la requête de l’agent passe à travers et atteint les clés. À droite, le contrôle hors de l’agent : une politique se place entre l’agent et les clés, et la même requête y est refusée. En dessous, la comparaison de la vidéo de NVIDIA : les virus étaient partout aux débuts du web, jusqu’à ce que les navigateurs imposent des limites strictes à ce qu’une page pouvait faire.">
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">L’approche du « s’il te plaît »</p>
<p class="mp-two-name">Demander gentiment</p>
<div class="ea-prompt"><p class="ea-prompt-k">Dans le prompt</p><p>S’il te plaît, ne supprime rien.</p><p>S’il te plaît, ne touche pas à mes clés SSH.</p></div>
<div class="ea-run ea-run-pass" aria-hidden="true"><span class="ea-chip">agent</span><span class="ea-track"><i></i></span><span class="ea-chip ea-chip-key">~/.ssh</span></div>
<p class="ea-verdict ea-v-bad">Clés atteintes</p>
<p class="mp-two-line">La règle vit dans le contexte de l’agent</p>
</div>
<p class="mp-two-vs">contre</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Appliqué hors de l’agent</p>
<p class="mp-two-name">Une politique</p>
<div class="ea-prompt ea-prompt-pol"><p class="ea-prompt-k">Dans la politique</p><p>fichiers : ~/.ssh interdit</p><p>réseau : hôtes approuvés seulement</p></div>
<div class="ea-run ea-run-stop" aria-hidden="true"><span class="ea-chip">agent</span><span class="ea-track"><b class="ea-wall"></b><i></i></span><span class="ea-chip ea-chip-safe">~/.ssh</span></div>
<p class="ea-verdict ea-v-good">Refusé par la politique</p>
<p class="mp-two-line">Le contrôle est là où l’agent ne peut pas le modifier</p>
</div>
</div>
<p class="mp-strip"><b>Les débuts du web</b><span>Les virus étaient partout jusqu’à ce que les navigateurs imposent des limites strictes à ce qu’une page pouvait faire.</span></p>
<figcaption id="ea2-cap">La même requête, deux fois. Les lignes de politique sont mon croquis, pas la syntaxe d’OpenShell.</figcaption>
</figure>

## Les clés n’entrent jamais dans la sandbox

C’est la partie à copier, même si vous n’installez jamais OpenShell. Le projet est open source sous Apache 2.0, et sa [documentation d’architecture](https://docs.nvidia.com/openshell/latest/about/architecture) répartit le travail en quatre.

- La sandbox contient l’agent et n’a aucune route directe vers le réseau. Elle intercepte chaque connexion et chaque requête DNS, identifie le programme qui en est à l’origine et la transmet. Elle ne décide jamais rien.
- Le superviseur se tient hors de la sandbox et prend les décisions. Il vérifie chaque requête contre la politique, ouvre la vraie connexion si elle est autorisée, et détient les identifiants.
- La gateway est le plan de contrôle : l’identité, les politiques et le cycle de vie de chaque sandbox.
- Le policy prover tourne dans la gateway et contrôle par vérification formelle les changements de politique proposés.

L’astuce des identifiants est celle que je préfère. Un provider associe un service à un identifiant stocké, et le superviseur ne l’ajoute qu’aux requêtes destinées à un endpoint que la politique approuve. L’agent ne voit jamais la vraie clé. Comme le dit la vidéo, un agent compromis ne peut pas faire fuiter une clé qu’il n’a jamais eue.

Les règles ne bougent pas toutes au même rythme non plus. Les règles de système de fichiers et de processus sont figées à la création de la sandbox. Les règles réseau se rechargent pendant qu’elle tourne, et les identifiants peuvent être ajoutés, renouvelés ou révoqués à l’exécution.

<figure class="fd-fig ea ea-flow" aria-labelledby="ea3-cap" data-desc="Comment une requête réseau sort d’une sandbox OpenShell, d’après la documentation d’architecture du projet. La gateway, au-dessus, est le plan de contrôle, avec le policy prover à l’intérieur. Un : l’agent ouvre une connexion dans la sandbox, qui n’a aucune route directe vers l’extérieur. Deux : la sandbox l’intercepte et identifie le programme à l’origine. Trois : le superviseur, hors de la sandbox, vérifie la requête contre la politique. Quatre : si elle est autorisée, le superviseur ajoute l’identifiant en route vers l’endpoint approuvé, si bien que l’agent ne détient jamais la clé. Cinq : une requête vers un hôte que la politique n’approuve pas est refusée au superviseur.">
<p class="ea-now ea-say5" aria-hidden="true"><span>L’agent ouvre une connexion</span><span>La sandbox identifie le programme</span><span>Le superviseur vérifie la politique</span><span>La clé s’ajoute à la sortie</span><span class="ea-no">Hôte inconnu : refusé</span></p>
<p class="ea-gw"><b>Gateway</b><span>plan de contrôle : identité, politique, sandboxes</span><span class="ea-gw-pr">policy prover</span></p>
<div class="ea-lane" aria-hidden="true">
<div class="ea-box ea-box-sb"><p class="ea-box-k">Sandbox</p><p class="ea-box-n">agent</p></div>
<div class="ea-box ea-box-sv"><p class="ea-box-k">Superviseur</p><p class="ea-box-n">politique, clés</p></div>
<div class="ea-box"><p class="ea-box-k">Endpoint</p><p class="ea-box-n">hôte approuvé</p></div>
<i class="ea-req"></i>
</div>
<ol class="ea-rows ea-cyc5" aria-label="Le trajet de la requête">
<li><b>1</b><span class="ea-who">Agent</span><span>Ouvre une connexion ou une requête DNS. La sandbox n’a aucune route directe vers l’extérieur.</span></li>
<li><b>2</b><span class="ea-who">Sandbox</span><span>L’intercepte, identifie le programme à l’origine, la transmet. Ne décide rien.</span></li>
<li><b>3</b><span class="ea-who">Superviseur</span><span>Vérifie la requête contre la politique, hors de la sandbox.</span></li>
<li><b>4</b><span class="ea-who">Superviseur</span><span>Ajoute l’identifiant pour un endpoint approuvé seulement, puis ouvre la vraie connexion.</span></li>
<li class="ea-row-no"><b>5</b><span class="ea-who">Superviseur</span><span>Un hôte que la politique n’approuve pas : refusé.</span></li>
</ol>
<p class="mp-strip"><b>La vidéo</b><span>Un agent compromis ne peut pas faire fuiter une clé qu’il n’a jamais eue.</span></p>
<figcaption id="ea3-cap">Une requête autorisée, puis une refusée. Le carré est la requête : il passe au cobalt quand le superviseur ajoute la clé, au rouge quand elle est refusée.</figcaption>
</figure>

## Chaque lancement a ses propres privilèges

De retour sur scène, Jensen a posé l’idée qui transforme un conteneur en produit. Chaque niveau de capacité, chaque tâche confiée à l’agent, chaque personne qui l’utilise : chaque combinaison demande un niveau de privilège différent. À chaque lancement d’un agent, les privilèges changent. Les privilèges, l’application des politiques et la surveillance doivent donc tous se jouer à l’exécution.

C’est le travail du prover. Quand un agent demande un nouvel accès, OpenShell vérifie ce que le changement autoriserait avant de l’appliquer. La documentation liste ce qui est signalé : une nouvelle portée avec des identifiants, une nouvelle méthode HTTP, un accès aux métadonnées cloud. Le moindre signalement bloque l’approbation automatique, et le changement attend un humain. Dans les mots de la vidéo : les agents n’obtiennent jamais plus d’accès que prévu.

Il a aussi précisé que ce n’est pas réservé aux entreprises qui construisent des agents. C’est pour toutes celles qui vont recevoir des agents et les laisser tourner chez elles. Voilà l’exigence pour les entreprises, en une ligne : il vous faut le runtime même si vous n’écrivez jamais d’agent. Sur la même scène, il a annoncé un partenariat entre Anthropic et NVIDIA autour d’agents Claude qui tournent dans OpenShell.

C’est aussi la conclusion de Jiquan Ngiam dans ma [note sur les collègues IA dans Slack](/fr/notes/ai-coworkers-slack-agent-identity.html) : les bonnes permissions dépendent de qui a demandé, de qui verra la réponse et de la tâche, donc elles se décident message par message.

<figure class="fd-fig ea ea-ceil" aria-labelledby="ea4-cap" data-desc="Des privilèges décidés à chaque lancement. L’addition de Jensen : le niveau de capacité de l’agent, plus la tâche, plus la personne qui l’utilise, donnent ses privilèges à un lancement, et chaque lancement est différent. En dessous, un schéma : trois lancements du même agent reçoivent trois niveaux d’accès différents, tous sous le plafond de permissions de l’entreprise. Une quatrième barre, un changement de politique proposé, dépasserait le plafond : le policy prover le signale et le changement attend un humain. Le prover signale une nouvelle portée avec des identifiants, de nouvelles méthodes HTTP et l’accès aux métadonnées cloud, et le moindre signalement bloque l’approbation automatique. Les couches d’OpenShell : les règles de système de fichiers et de processus sont figées à la création de la sandbox, tandis que les règles réseau et les identifiants changent pendant qu’elle tourne.">
<p class="ea-sum"><span>Capacité</span><i>+</i><span>Tâche</span><i>+</i><span>Personne</span><i>=</i><span class="ea-sum-r">Les privilèges de ce lancement</span></p>
<p class="ea-now ea-say4" aria-hidden="true"><span>Lancement 1</span><span>Lancement 2</span><span>Lancement 3</span><span class="ea-no">Au-dessus du plafond : un humain tranche</span></p>
<div class="ea-plot" aria-hidden="true">
<p class="ea-ceiling"><span>Votre plafond de permissions</span></p>
<i class="ea-bar ea-b1"></i><i class="ea-bar ea-b2"></i><i class="ea-bar ea-b3"></i><i class="ea-bar ea-b4"></i>
</div>
<p class="ea-plot-lbl" aria-hidden="true"><span>Lancement 1</span><span>Lancement 2</span><span>Lancement 3</span><span>Changement proposé</span></p>
<div class="rp-pair">
<p><span class="rp-k">Le prover signale</span>Une nouvelle portée avec des identifiants, une nouvelle méthode HTTP, l’accès aux métadonnées cloud. Le moindre signalement bloque l’approbation automatique.</p>
<p><span class="rp-k">Figé à la création</span>Les règles de fichiers et de processus. Les règles réseau et les identifiants changent pendant l’exécution.</p>
</div>
<figcaption id="ea4-cap">La hauteur des barres est schématique : NVIDIA ne donne aucun chiffre. La liste des signalements et les couches viennent de la documentation d’OpenShell.</figcaption>
</figure>

## Un second garde, sur sa propre puce

OpenShell applique ses règles depuis le noyau de l’hôte. L’option supplémentaire de NVIDIA quitte carrément l’hôte. Sentry tourne sur un BlueField-4, un DPU : un processeur sur la carte réseau du serveur, dans son propre domaine matériel. Le trafic de raisonnement de l’agent vers le modèle passe par lui. Si l’agent planifie une action non voulue, Sentry met à jour la politique et coupe la connexion au modèle, ce qui met l’agent en quarantaine, en quelques millisecondes selon NVIDIA. Il conserve pour l’équipe sécurité des traces où toute altération se voit et ne dépend pas des logs de l’hôte ni de l’agent.

Deux réserves. NVIDIA présente Sentry comme optionnel, une couche en plus, pas une obligation. Et je n’ai trouvé aucune méthode publiée derrière ces « millisecondes ». À Berlin, l’ensemble est présenté comme l’architecture de référence OpenShell : Vera Rubin pour l’inférence du modèle, des CPU Vera pour les harnais et les outils, un BlueField-4 qui fait tourner Sentry.

<figure class="fd-fig ea ea-sentry" aria-labelledby="ea5-cap" data-desc="Le second garde de NVIDIA, hors de l’hôte. À gauche, l’hôte, un CPU Vera, fait tourner l’agent dans sa sandbox OpenShell. Au milieu, Sentry tourne sur un DPU BlueField-4, dans son propre domaine matériel, et le trafic de raisonnement de l’agent vers le modèle passe par lui. À droite, le modèle sur Vera Rubin. Quand l’agent planifie une action non voulue, Sentry met à jour la politique, coupe la connexion au modèle et met l’agent en quarantaine, ce qui prend quelques millisecondes selon NVIDIA, et il conserve une trace scellée que les opérateurs peuvent vérifier. NVIDIA présente cette couche comme optionnelle et n’a pas publié comment les millisecondes ont été mesurées.">
<p class="ea-now ea-say4" aria-hidden="true"><span>Le raisonnement passe par Sentry</span><span class="ea-no">Un plan non voulu</span><span class="ea-no">Connexion coupée, agent isolé</span><span>Une trace scellée</span></p>
<div class="ea-hw" aria-hidden="true">
<div class="ea-box ea-hw-host"><p class="ea-box-k">Hôte · CPU Vera</p><p class="ea-box-n">agent dans sa sandbox</p><p class="ea-q">En quarantaine</p></div>
<span class="ea-link ea-l1"><i></i></span>
<div class="ea-box ea-hw-dpu"><p class="ea-box-k">BlueField-4</p><p class="ea-box-n">Sentry</p></div>
<span class="ea-link ea-l2"><i></i></span>
<div class="ea-box"><p class="ea-box-k">Vera Rubin</p><p class="ea-box-n">le modèle</p></div>
</div>
<p class="ea-rec"><b>Trace</b><span>Scellée, pour la détection, l’enquête et la réponse</span></p>
<p class="mp-strip"><b>Selon NVIDIA</b><span>Quarantaine en quelques millisecondes, même si l’hôte est compromis. Aucune méthode publiée.</span></p>
<figcaption id="ea5-cap">Sentry est optionnel, une couche au-dessus d’OpenShell. Les trois blocs suivent l’architecture de référence OpenShell annoncée à Berlin.</figcaption>
</figure>

## Louer le modèle généraliste, posséder le spécialisé

Ensuite, les modèles. Jensen ne s’attend pas à ce qu’une entreprise fasse tout tourner sur un seul modèle. Quand le travail est assez générique, un modèle généraliste fait un travail incroyablement bon. Quand le travail renferme trop de votre savoir propriétaire, et que vous voulez continuer à l’améliorer, vous prenez un modèle ouvert et vous le post-entraînez sur vos propres données. Chaque entreprise, dit-il, utilisera les deux.

La famille ouverte de NVIDIA s’appelle Nemotron, livrée avec les poids ouverts, les données d’entraînement et les scripts pour la reproduire, si bien que vous savez d’où vient le modèle. Il a été franc sur la limite : ces modèles « ne sont pas forcément la frontière des frontières », surtout pour le langage. La promesse, c’est qu’une fois post-entraînés sur vos données, ils atteignent le niveau de la frontière pour votre cas d’usage. Il l’a appuyée sur des binômes de partenaires, dont Baseten avec CodeRabbit et Scale avec Skydance, et sans aucun benchmark sur scène.

Ma flotte est déjà découpée ainsi. La plupart de mes agents tournent sur Claude. Fortuna, celui qui lit mon appli de finances, tourne sur Qwen 3.6, sur le Mac mini lui-même.

<figure class="fd-fig ea ea-models" aria-labelledby="ea6-cap" data-desc="Le partage entre modèles selon Jensen. À gauche, le travail assez générique va à un modèle généraliste, souvent fermé, qui selon lui fera un travail incroyablement bon. À droite, le travail qui renferme trop de votre savoir propriétaire va à un modèle ouvert que vous post-entraînez sur vos propres données et que vous continuez à améliorer. Nemotron, chez NVIDIA, est livré avec les poids ouverts, les données d’entraînement et les scripts pour le reproduire, et avec vos données par-dessus il devient votre modèle. Sa réserve : ces modèles ne sont pas forcément la frontière des frontières, surtout pour le langage.">
<p class="ea-now ea-say4" aria-hidden="true"><span>Poids ouverts</span><span>Plus les données d’entraînement</span><span>Plus les scripts pour le refaire</span><span>Plus vos données : votre modèle</span></p>
<div class="mp-two-row">
<div class="mp-two-card">
<p class="mp-two-who">Travail assez générique</p>
<p class="mp-two-name">Louer</p>
<p class="ea-mdl"><b>Modèle généraliste</b>fermé ou ouvert, utilisé tel quel</p>
<p class="mp-two-line">« Va faire un travail incroyablement bon »</p>
<p class="mp-two-line">Toutes les entreprises s’en serviront</p>
</div>
<p class="mp-two-vs">et</p>
<div class="mp-two-card mp-two-peter">
<p class="mp-two-who">Votre savoir propriétaire</p>
<p class="mp-two-name">Posséder</p>
<ol class="ea-recipe ea-cyc4" aria-label="Ce qu’un modèle ouvert fournit, puis votre part">
<li>Poids ouverts</li>
<li>Les données d’entraînement</li>
<li>Les scripts pour le reproduire</li>
<li class="ea-recipe-you">Vos données : post-entraînez-le</li>
</ol>
<p class="mp-two-line">Et continuez à l’améliorer</p>
</div>
</div>
<p class="mp-strip"><b>Jensen</b><span>Ces modèles « ne sont pas forcément la frontière des frontières, surtout pour le modèle de langage ».</span></p>
<figcaption id="ea6-cap">Les deux, pas l’un ou l’autre. La recette est ce que NVIDIA livre avec les poids de Nemotron ; la dernière ligne est la part qui n’appartient qu’à vous.</figcaption>
</figure>

## La connaissance fait des agents des super-agents

« Ce qui transforme ces agents en super-agents, c’est de leur donner accès à la connaissance de votre entreprise. » La brique de NVIDIA pour ça, c’est l’agent knowledge foundation : des bibliothèques et des modèles qui tirent du sens de vos données, qu’elles soient non structurées, comme des PDF qu’il faut une IA pour lire, ou structurées, comme les lignes d’une base de données.

Il en a nommé les pièces une par une. Nemotron Parse lit les documents. Nemotron Embed rapproche une requête de ce que contient une base vectorielle. Nemotron Rerank prend les nombreuses sources trouvées pour une requête et les classe par pertinence. Kumo prédit ce qui risque d’arriver à partir d’une base structurée.

Puis son exemple. Un avis arrive : un fournisseur livrera moins ou en retard. C’est un document. Vos commandes sont dans une base SQL. Kumo prédit quelles commandes vont manquer, et de combien. Puis la recherche vectorielle trouve le document d’ingénierie d’un composant de remplacement. Une seule question, et elle traverse un document, une base de données et une archive.

C’est la partie la plus proche de mon métier. Je connecte des systèmes de commerce pour gagner ma vie, et un agent ne peut répondre à cette question qu’une fois que quelqu’un l’a branché au système de commandes.

<figure class="fd-fig ea ea-supply" aria-labelledby="ea7-cap" data-desc="L’exemple de chaîne d’approvisionnement de Jensen pour l’agent knowledge foundation, en trois étapes. Un : un avis arrive, un fournisseur livrera moins ou en retard ; c’est un document non structuré, lu par Nemotron Parse. Deux : les commandes de l’entreprise sont dans une base SQL structurée, et Kumo prédit quelles commandes vont manquer, et de combien. Trois : une recherche vectorielle dans les documents d’ingénierie, avec Nemotron Embed et Nemotron Rerank, trouve un composant de remplacement. En dessous, les quatre pièces qu’il a nommées : Parse lit les documents, Embed rapproche une requête de la base vectorielle, Rerank classe les sources par pertinence, et Kumo prédit à partir de données structurées.">
<p class="ea-now ea-say3" aria-hidden="true"><span>Un avis : un fournisseur sera en retard</span><span>Quelles commandes manquent, et de combien</span><span>Une pièce de remplacement</span></p>
<ol class="mp-trio ea-trio">
<li><svg class="mp-grow-art" viewBox="0 0 170 100" aria-hidden="true"><rect class="rp-doc" x="56" y="8" width="62" height="84"/><rect class="mp-ln" x="66" y="22" width="40" height="5"/><rect class="mp-ln" x="66" y="34" width="44" height="4"/><rect class="mp-ln" x="66" y="44" width="32" height="4"/><rect class="ea-hl" x="66" y="56" width="42" height="7"/><rect class="mp-ln" x="66" y="70" width="36" height="4"/></svg><p class="mp-trio-n"><b>1</b>L’avis</p><p class="mp-trio-what">Un document, donc non structuré. Parse le lit.</p></li>
<li><svg class="mp-grow-art" viewBox="0 0 170 100" aria-hidden="true"><path class="ea-db" d="M50,22 V78 A35,10 0 0 0 120,78 V22"/><ellipse class="ea-db" cx="85" cy="22" rx="35" ry="10"/><path class="ea-db-ln" d="M50,41 A35,10 0 0 0 120,41"/><path class="ea-db-ln" d="M50,60 A35,10 0 0 0 120,60"/><rect class="ea-hl" x="76" y="64" width="18" height="7"/></svg><p class="mp-trio-n"><b>2</b>Les commandes</p><p class="mp-trio-what">Des lignes en SQL. Kumo prédit lesquelles vont manquer, et de combien.</p></li>
<li><svg class="mp-grow-art" viewBox="0 0 170 100" aria-hidden="true"><rect class="rp-doc" x="40" y="14" width="44" height="60"/><rect class="rp-doc" x="52" y="22" width="44" height="60"/><rect class="mp-ln" x="60" y="34" width="28" height="4"/><rect class="mp-ln" x="60" y="44" width="22" height="4"/><circle class="ea-lens" cx="112" cy="52" r="18"/><path class="ea-lens-h" d="M125,65 L144,84"/></svg><p class="mp-trio-n"><b>3</b>La solution</p><p class="mp-trio-what">La recherche vectorielle trouve la doc d’ingénierie d’un remplaçant.</p></li>
</ol>
<p class="ea-libs"><span><b>Parse</b>lit les documents</span><span><b>Embed</b>rapproche une requête de la base vectorielle</span><span><b>Rerank</b>classe les sources par pertinence</span><span><b>Kumo</b>prédit à partir de données structurées</span></p>
<figcaption id="ea7-cap">Son exemple, étape par étape. Les quatre noms en dessous sont les pièces de l’agent knowledge foundation de NVIDIA qu’il a citées sur scène.</figcaption>
</figure>

## Les outils, c’est le métier

La dernière pièce, ce sont les outils. Les bibliothèques CUDA-X de NVIDIA sont des simulateurs, des solveurs, des moteurs de traitement de données et des bibliothèques métier, et Jensen les appelle les joyaux de la couronne de l’entreprise. La phrase de la vidéo : le scientifique le plus brillant a toujours besoin d’un laboratoire, et le meilleur ingénieur a toujours besoin de simulateurs et de solveurs.

Il a aussi expliqué pourquoi le code est passé en premier. Le logiciel a été l’un des premiers domaines conquis par les agents, et là, un compilateur ou Python suffit à l’agent. Les autres métiers demandent plus d’outils.

La vidéo en a montré trois. Lila Sciences, qui conçoit une thérapie contre le lymphome B : l’agent Iris transforme l’objectif en plan expérimental, des agents lancent des millions d’expériences virtuelles dans un laboratoire numérique (dry lab), les meilleurs candidats partent dans une usine scientifique IA où des robots les fabriquent et les testent, et les résultats reviennent à Iris. Siemens, dans son usine électronique d’Erlangen : des agents produisent des prototypes virtuels et des données synthétiques, recommandent des plans de production à partir des commandes, des stocks et de la configuration des lignes, et un jumeau numérique vérifie ces plans par simulation physique avant que quoi que ce soit change dans l’atelier. Dassault Systèmes, qui adapte une portière de Volkswagen Golf pour le Tiguan : un agent de simulation détecte un problème de vibration, le renvoie à l’agent de conception, et l’ingénieur choisit le design final.

Son résumé ensuite : « Construire des agents, ce n’est pas si difficile. » Cinq pièces. Le modèle et le harnais existent en versions fermées et ouvertes. Puis le runtime OpenShell, « et ensuite, surtout, la connaissance et les outils, et cette connaissance et ces outils vous appartiennent. C’est votre expertise. »

<figure class="fd-fig ea ea-lab" aria-labelledby="ea8-cap" data-desc="La boucle de Lila Sciences dans la vidéo de NVIDIA, pour concevoir une thérapie contre le lymphome B. L’agent Iris transforme l’objectif en plan expérimental. Des agents, dans un laboratoire numérique, lancent des millions d’expériences virtuelles avec BioNeMo. Les candidats les plus prometteurs partent dans une usine scientifique IA, où des robots et des instruments les fabriquent et les testent. Les résultats reviennent à Iris et orientent les conceptions suivantes, et la boucle continue. En dessous, les deux autres exemples de la vidéo. Dans l’usine électronique de Siemens à Erlangen, des agents produisent des prototypes virtuels et des données synthétiques et recommandent des plans de production, et un jumeau numérique vérifie les plans par simulation physique avant que l’atelier change. Chez Dassault Systèmes, des agents adaptent une portière de Volkswagen Golf pour le Tiguan, un agent de simulation détecte un problème de vibration et le renvoie à la conception, et l’ingénieur choisit le design final.">
<p class="ea-now ea-say4" aria-hidden="true"><span>Iris planifie l’expérience</span><span>Des millions d’expériences virtuelles</span><span>Des robots testent les meilleurs</span><span>Les résultats reviennent à Iris</span></p>
<p class="ea-goal"><b>Objectif</b>Une thérapie contre le lymphome B</p>
<div class="ea-ring ea-cyc4">
<p class="ea-node ea-n1"><b>Plan</b><span>Iris transforme l’objectif en plan expérimental</span></p>
<p class="ea-node ea-n2"><b>Dry lab</b><span>BioNeMo lance des millions d’expériences virtuelles</span></p>
<p class="ea-node ea-n3"><b>Usine scientifique</b><span>Des robots fabriquent et testent les meilleurs candidats</span></p>
<p class="ea-node ea-n4"><b>Résultats</b><span>Retour à Iris, qui oriente les conceptions suivantes</span></p>
<span class="ea-arr ea-a1" aria-hidden="true">→</span><span class="ea-arr ea-a2" aria-hidden="true">↓</span><span class="ea-arr ea-a3" aria-hidden="true">←</span><span class="ea-arr ea-a4" aria-hidden="true">↑</span>
</div>
<div class="rp-pair">
<p><span class="rp-k">Siemens, Erlangen</span>Prototypes virtuels et données synthétiques, plans de production tirés des commandes et des lignes, un jumeau numérique les vérifie d’abord</p>
<p><span class="rp-k">Dassault Systèmes</span>Une portière de Golf retravaillée pour le Tiguan. La simulation trouve une vibration, la conception la corrige, l’ingénieur choisit</p>
</div>
<p class="mp-strip"><b>La vidéo</b><span>Le scientifique le plus brillant a toujours besoin d’un laboratoire.</span></p>
<figcaption id="ea8-cap">La boucle de Lila telle que la vidéo la raconte. La surbrillance la parcourt comme les résultats : un tour, puis un autre.</figcaption>
</figure>

## Où en sont mes propres agents

J’ai donc confronté ma flotte OpenClaw aux cinq pièces.

Le modèle est mixte : Claude pour la plupart des agents, Qwen 3.6 en local pour quelques-uns. Le harnais, c’est OpenClaw 2026.9.4. La connaissance passe par huit serveurs MCP branchés sur mes propres applis. Les outils sont filtrés par une liste d’interdits par agent dans openclaw.json : Rex, mon coach nutrition, n’a aucun shell, et seul Nova peut atteindre mon téléphone.

La sandbox, c’est la ligne vide. Mes agents exécutent leurs outils sur l’hôte, ce qui est le comportement par défaut d’OpenClaw, et précisément ce contre quoi je mettais en garde dans ma [comparaison d’OpenClaw et Hermes](/fr/notes/hermes-agent-vs-openclaw.html).

Ces listes d’interdits sont du vrai code, pas un « s’il te plaît ». Mais c’est le harnais qui les applique, sur la même machine que l’agent, et elles nomment des outils. Tout agent qui a encore un shell peut atteindre tout ce que mon compte utilisateur atteint. C’est exactement le contrôle depuis l’intérieur de l’agent que NVIDIA juge insuffisant.

<figure class="fd-fig ea ea-mine" aria-labelledby="ea9-cap" data-desc="Ma flotte OpenClaw sur le Mac mini, confrontée aux cinq pièces. Modèle : mixte, Claude pour la plupart des agents et Qwen 3.6 en local pour quelques-uns. Harnais : OpenClaw 2026.9.4. Connaissance : huit serveurs MCP branchés sur mes propres applis. Outils : une liste d’interdits par agent dans openclaw.json, appliquée par le harnais sur la même machine ; Rex n’a pas de shell, et seul Nova peut atteindre le téléphone. Sandbox : aucune pour l’instant, les outils tournent sur l’hôte, le comportement par défaut d’OpenClaw. L’écart : mes règles vivent dans le harnais, et l’idée de NVIDIA est de les placer hors de l’agent.">
<p class="ea-now ea-say5" aria-hidden="true"><span>Modèle : mixte</span><span>Harnais : OpenClaw</span><span>Connaissance : huit serveurs MCP</span><span>Outils : interdits, en interne</span><span class="ea-no">Sandbox : pas encore</span></p>
<ol class="ea-card ea-cyc5" aria-label="Mon installation, pièce par pièce">
<li><span class="ea-card-k">Modèle</span><span class="ea-card-v">Claude pour la plupart des agents, Qwen 3.6 sur le mini pour quelques-uns</span><b class="ea-pill">Mixte</b></li>
<li><span class="ea-card-k">Harnais</span><span class="ea-card-v">OpenClaw 2026.9.4</span><b class="ea-pill">Oui</b></li>
<li><span class="ea-card-k">Connaissance</span><span class="ea-card-v">Huit serveurs MCP branchés sur mes applis</span><b class="ea-pill">Oui</b></li>
<li><span class="ea-card-k">Outils</span><span class="ea-card-v">Une liste d’interdits par agent. Rex n’a pas de shell ; seul Nova atteint le téléphone</span><b class="ea-pill ea-pill-mid">Interne</b></li>
<li class="ea-row-no"><span class="ea-card-k">Sandbox</span><span class="ea-card-v">Aucune : les outils tournent sur l’hôte, par défaut dans OpenClaw</span><b class="ea-pill ea-pill-no">Pas encore</b></li>
</ol>
<p class="mp-strip"><b>L’écart</b><span>Mes règles vivent dans le harnais. L’idée de NVIDIA est de les placer hors de l’agent.</span></p>
<figcaption id="ea9-cap">Mon installation au 23 octobre, lue dans mon openclaw.json. La dernière ligne est celle que la keynote dit de faire en premier.</figcaption>
</figure>

## À vous d’essayer

OpenShell tourne sous Linux, sous macOS sur Apple Silicon ou sous Windows avec WSL 2, avec Docker, Podman ou la virtualisation de l’hôte. Deux commandes :

```
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo
```

L’installeur met en place la CLI et une gateway locale, et la sandbox par défaut est un Ubuntu minimal sans agent dedans. Le guide [Run your first agent](https://docs.nvidia.com/openshell/latest/about/run-your-first-agent) y installe OpenCode sur un modèle OpenRouter gratuit et montre comment approuver les nouveaux accès au fur et à mesure que l’agent les demande. Je ne l’ai pas encore lancé : lisez cette note comme une lecture, pas comme un test.

Pour aller plus loin :

- [La keynote de la GTC Berlin](https://www.youtube.com/watch?v=PvFjbPYEOZI&t=2502s), la partie agents à partir de la minute 41, et [la vidéo OpenShell](https://www.youtube.com/watch?v=PvFjbPYEOZI&t=2657s) à 44:17
- [OpenShell sur GitHub](https://github.com/NVIDIA/OpenShell), sous Apache 2.0, avec la documentation d’[architecture](https://docs.nvidia.com/openshell/latest/about/architecture) et celle des [politiques](https://docs.nvidia.com/openshell/latest/how-it-works/policies/overview)
- [NVIDIA Sentry](https://www.nvidia.com/en-us/networking/products/software/sentry/), la couche BlueField-4
- [How autonomous AI agents become secure by design](https://blogs.nvidia.com/blog/secure-autonomous-ai-agents-openshell/), l’article de lancement d’OpenShell par NVIDIA
- [OpenClaw et Hermes Agent offrent les mêmes fonctionnalités, mais pas les mêmes réglages par défaut](/fr/notes/hermes-agent-vs-openclaw.html), où les sandboxes par défaut sont comparées
- [Les collègues IA dans Slack ont besoin de leur propre identité](/fr/notes/ai-coworkers-slack-agent-identity.html), sur les permissions décidées à l’exécution

Si votre entreprise se prépare aux agents, commencez par la partie ingrate. Écrivez ce que chaque agent a le droit de toucher, et placez ce contrôle là où l’agent ne peut pas le modifier. Si vous essayez OpenShell avant moi, dites-moi combien d’approbations il a fallu avant que votre agent devienne utile.
