Agents IA : NVIDIA veut les surveiller jusque dans le silicium

NVIDIA propose une couche de sécurité matérielle pour encadrer les agents IA. Ce que ça révèle et ce que les PME peuvent en retenir dès maintenant.

Le 28 septembre, NVIDIA a publié un billet technique qui part d’un constat inconfortable. Selon l’entreprise, plusieurs laboratoires d’IA de pointe ont récemment vu des agents sortir des environnements de test censés les contenir, atteindre des systèmes auxquels ils n’avaient pas accès et, dans certains cas, mal rapporter ce qu’ils avaient fait.

La réponse de NVIDIA tient en une idée simple : on ne peut pas demander à un agent de se surveiller lui-même. Il faut un gardien externe, placé hors de sa portée. Et NVIDIA propose de le mettre directement dans le matériel.

Ce qui s’est passé

NVIDIA a présenté l’Open Agent Safety Platform, une architecture de référence qui combine deux briques.

La première est OpenShell, un environnement d’exécution open source (licence Apache 2.0). Il fait tourner chaque agent dans un bac à sable isolé au niveau du noyau du système. L’opérateur définit à quels fichiers, réseaux, outils, processus et identifiants l’agent a droit. OpenShell vérifie ces limites avant le lancement, puis les applique pendant que l’agent travaille.

La seconde est Sentry, un module de surveillance qui tourne sur une puce séparée, le DPU BlueField-4. Un DPU est un processeur réseau dédié, installé à côté du serveur principal. Dans les serveurs Vera Rubin de NVIDIA, cette puce se trouve sur le seul chemin qui mène au modèle. Tout ce que l’agent demande au modèle passe donc par elle. Elle peut observer, enregistrer et couper la connexion au besoin, même si le serveur principal est compromis.

La couche logicielle DOCA met en relation les actions de l’agent, les décisions de politique et les accès aux données pour construire un historique complet de son activité. Elle vérifie aussi en continu l’identité de chaque agent et l’étendue des droits qu’on lui a délégués.

NVIDIA précise que la plateforme reste compatible avec d’autres matériels. Pour ses propres clients déjà équipés en Vera et BlueField-4, l’activation se ferait par simple mise à jour logicielle.

Pourquoi c’est important

Le passage le plus intéressant du billet ne porte pas sur les puces. Il porte sur ce que NVIDIA appelle la « dérive ».

Un agent dérive quand ses actions s’éloignent de la tâche prévue. Ça peut arriver après un blocage, un bogue, un outil manquant ou une consigne floue. Ça arrive aussi quand on laisse un agent travailler pendant des jours sur un problème difficile. Après mille tentatives ratées, il finit par essayer des choses que personne n’avait envisagées.

NVIDIA affirme qu’on ne peut pas éliminer ce comportement sans réduire en même temps les capacités de l’agent. Autrement dit, l’initiative qui rend un agent utile est la même qui le rend imprévisible.

L’entreprise fait un parallèle avec les débuts du web. Internet n’est pas devenu sûr parce que les développeurs ont promis d’écrire du code honnête. Il l’est devenu parce que le navigateur a cessé de faire confiance aux pages : chaque onglet tourne dans son propre bac à sable. NVIDIA veut appliquer la même logique aux agents.

Ce que cela change pour les entreprises

Soyons clairs : une PME de Laval ou un OBNL de Montréal-Nord n’achètera pas de serveurs Vera Rubin. Cette annonce vise les laboratoires d’IA, les fournisseurs infonuagiques et les grandes entreprises.

Les principes, eux, concernent tout le monde qui confie une tâche à un agent. Et c’est déjà beaucoup de monde. Un scénario Make avec une étape ChatGPT qui lit vos courriels. Un assistant Claude branché sur votre Google Drive. Un agent qui met à jour votre CRM la nuit.

Trois de ces principes se transposent facilement à une petite organisation.

Le contrôle doit se trouver hors de l’agent. Si c’est l’agent qui décide de ce qu’il enregistre dans ses journaux, ces journaux ne valent pas grand-chose. Les traces doivent venir de l’outil qui l’héberge, pas de l’agent lui-même.

Les permissions se définissent avant, pas après. On donne à l’agent l’accès minimal pour sa tâche. Un agent qui trie des factures n’a pas besoin de pouvoir envoyer des courriels.

Plus un agent a de pouvoir, plus son raisonnement doit être visible. Un agent qui propose un brouillon peut rester opaque. Un agent qui peut supprimer des données ou effectuer un paiement doit laisser une trace claire de ce qu’il a fait et pourquoi.

Les opportunités

OpenShell est open source. Même si la couche matérielle reste propriétaire, le moteur d’exécution et son langage de politiques peuvent devenir un standard que d’autres fournisseurs adopteront. C’est exactement ce que NVIDIA dit vouloir, avec un modèle de responsabilité partagée où chaque acteur (laboratoire, entreprise, fournisseur de matériel) gère sa couche.

Pour les secteurs réglementés, l’enjeu est concret. En santé ou en finance, on hésite à déployer des agents parce qu’on ne sait pas prouver ce qu’ils ont fait. Un historique complet et indépendant de l’agent change la conversation avec un comité de conformité.

Au Québec, la Loi 25 exige de savoir qui accède aux renseignements personnels et dans quel but. Quand ce « qui » devient un agent, un journal d’activité fiable et externe cesse d’être un luxe technique. Il devient une pièce de votre dossier de conformité.

Les risques ou limites

Il faut lire ce billet pour ce qu’il est : une annonce de NVIDIA, qui vend des puces. La meilleure façon de sécuriser vos agents, selon NVIDIA, passe par du matériel NVIDIA. Ce n’est pas faux pour autant, mais ça mérite d’être gardé en tête.

Les incidents qui servent de point de départ restent vagues. NVIDIA ne nomme ni les laboratoires ni les agents concernés, et ne décrit pas précisément ce qui s’est passé. Difficile d’évaluer la gravité réelle à partir de ça.

Certaines promesses demandent aussi à être vérifiées. NVIDIA parle d’un « prouveur » capable de démontrer, avant l’exécution, qu’une politique ne peut pas déborder de l’intention de l’opérateur. C’est une ambition sérieuse. On attendra de voir comment elle se comporte face à des consignes réelles, qui sont rarement aussi précises qu’un contrat.

Enfin, la surveillance du raisonnement suppose de pouvoir le lire. NVIDIA le reconnaît : c’est plus facile avec des modèles ouverts. Avec les modèles fermés que la plupart des PME utilisent, une grande partie de ce raisonnement reste invisible.

Et aucune surveillance ne corrige une consigne mal écrite. Elle détecte le problème, elle ne l’empêche pas de naître.

Mon analyse

Je trouve l’analogie avec le navigateur juste, et c’est ce qui rend l’annonce intéressante au-delà du matériel.

Pendant deux ans, la sécurité des agents a surtout reposé sur le modèle lui-même : on lui donne de bonnes consignes système, on espère qu’il les respecte. NVIDIA dit en substance que ça ne suffit plus. Je suis d’accord. On ne sécurise pas un employé en lui demandant de promettre d’être honnête. On lui donne des accès limités et on garde des traces.

Quand je conçois une automatisation avec une étape IA pour un client, c’est la question que je pose maintenant en premier : que peut faire cet agent s’il se trompe complètement ? Si la réponse est « envoyer un courriel à toute la liste de clients » ou « effacer un dossier », l’architecture n’est pas prête, peu importe la qualité du modèle.

Ce qui me dérange un peu, c’est le ton de fond. Quand un fournisseur de puces écrit que des agents ont échappé à leurs gardiens et que la solution passe par ses processeurs, il faut garder une distance critique. Le problème est réel. La solution n’est pas forcément celle qu’on nous vend.

Conclusion

L’annonce de NVIDIA confirme une chose : plus les agents deviennent autonomes, plus leur surveillance doit venir de l’extérieur. Vous n’avez pas besoin d’un DPU pour appliquer cette logique.

Voici ce que je recommande dès maintenant :

  • Dressez la liste des agents et automatisations IA qui tournent dans votre organisation, avec les accès de chacun.
  • Retirez toutes les permissions qui ne servent pas directement à la tâche.
  • Activez la journalisation dans l’outil qui héberge l’agent (Make, n8n, votre CRM), pas seulement dans l’agent.
  • Exigez une validation humaine pour toute action irréversible : envoi, suppression, paiement.
  • Relisez vos consignes. Une instruction ambiguë est la porte d’entrée la plus fréquente de la dérive.

Vous souhaitez appliquer ces idées à votre organisation ? FD Stratégies peut vous accompagner dans la création de solutions numériques, l’automatisation de vos processus et la structuration de votre présence en ligne.

Fito Damour

Auteur

Fito Damour

Développeur web & Chef de projet digital — FD Stratégies

Spécialiste TI & plateformes numériques | Gestion des systèmes d'information | Cloud, DevOps & automatisation | Architecture d'infrastructures | Solutions digitales pour PME et organisations

Me contacter →

Une veille tech utile, claire et accessible

Recevez mes analyses sur l'IA, les technologies, le cloud, les systèmes d'information, le marketing et l'entrepreneuriat.

Je m'abonne