Microsoft et NVIDIA déplacent le débat sur les risques des modèles ouverts

Un cadre commun pour dépasser l’étiquette du modèle

Microsoft et NVIDIA ont publié le 16 octobre 2026 un document commun consacré aux modèles à poids ouverts en entreprise. Les poids sont les paramètres numériques appris pendant l’entraînement, qui déterminent une grande partie du comportement du modèle. Leur accès permet à une organisation d’examiner, d’évaluer, de modifier et d’exécuter le modèle dans son propre environnement. Cette liberté déplace aussi une partie des choix de sécurité vers l’entreprise qui l’adopte.

Le document inaugure une série de ressources communes sur la gestion de ces risques. Il propose un vocabulaire partagé et une méthode inspirée de normes de l’Organisation internationale de normalisation, dite ISO, et du cadre de gestion des risques liés à l’intelligence artificielle du NIST. Le NIST est l’Institut national américain des normes et de la technologie. Les auteurs ne présentent toutefois ni une politique prête à appliquer, ni une liste de contrôle universelle.

Le contexte d’usage change les conséquences

L’observation centrale concerne les conditions réelles d’utilisation. Un modèle qui aide un salarié à rédiger un document ne soulève pas les mêmes questions qu’un service directement accessible aux clients. De même, un point d’accès isolé, qui reçoit une demande et produit une réponse, diffère d’un système connecté à des données ou à des outils externes. Les conséquences possibles dépendent donc moins d’une étiquette que de l’architecture complète.

Selon Microsoft et NVIDIA, modèles ouverts et fermés peuvent partager des risques de même nature. Un modèle fermé ne donne pas accès à ses poids, mais cette différence ne décide pas seule de la sécurité. La provenance, l’usage prévu, les utilisateurs, les conditions de déploiement et les contrôles environnants modifient la manière dont un problème peut apparaître. Une protection efficace peut ainsi se trouver dans l’application ou dans l’exploitation, plutôt que dans le modèle.

Cinq familles de risques pour réunir les métiers

La méthode commence par une taxonomie, c’est-à-dire un classement commun des risques. Elle retient cinq familles : cybersécurité, protection des données, contenus, interaction entre humains et intelligence artificielle, puis biais. Ce découpage doit aider les équipes techniques, juridiques, commerciales, de sécurité et de sûreté à décrire les mêmes problèmes. Il ne fixe pas automatiquement le niveau de risque acceptable pour une organisation.

Chaque entreprise doit adapter ce classement à ses systèmes et à ses critères. Elle peut ensuite relier un risque pertinent à une évaluation, à une mesure de réduction et à une personne responsable. Cette chaîne vise à éviter qu’un problème reste abstrait ou sans propriétaire. Elle constitue l’interprétation opérationnelle du cadre, mais le document ne prétend pas qu’un même contrôle conviendra à tous les déploiements.

Des évaluations utiles, mais jamais suffisantes seules

Le document décrit ensuite sa méthode pour produire des éléments de preuve. Il associe certaines évaluations aux risques des cinq familles, afin de tester ce qui compte dans un déploiement donné. Microsoft Foundry propose pour cela des évaluations intégrées ou personnalisées sur la qualité, l’appui sur des informations vérifiables et la sûreté. La plateforme inclut aussi du red teaming automatisé, une mise à l’épreuve volontaire destinée à chercher des faiblesses.

Des contrôles configurables peuvent détecter et réduire les entrées, les réponses nuisibles et les attaques qui manipulent les instructions du modèle. Les équipes doivent vérifier que ces fonctions existent pour leur modèle et leur configuration, notamment lorsqu’elles sont encore en préversion. Elles doivent les compléter par des tests propres à l’application, une surveillance et un contrôle humain. Un résultat d’évaluation reste un indice à interpréter dans le contexte précis du déploiement.

La responsabilité évolue avec chaque déploiement

L’accès aux poids et le mode d’hébergement constituent deux décisions distinctes. Un modèle à poids ouverts peut aussi fonctionner sur une plateforme gérée par un prestataire. À l’inverse, une entreprise qui exploite elle-même son déploiement peut devoir reprendre des protections fournies ailleurs par un service géré. Selon le risque, elle peut modifier le modèle, limiter les accès, filtrer les échanges, surveiller le système ou imposer une validation humaine.

La principale limite de la publication tient à son périmètre. Elle examine surtout les risques situés au niveau du modèle, sans établir la sûreté globale d’un agent ou d’une application. Un agent est un système qui utilise un modèle avec des outils ou des actions. Son évaluation doit aussi couvrir ses autorisations, ses données, ses outils, son environnement d’exécution et ses contrôles opérationnels.

Microsoft et NVIDIA annoncent de futurs travaux sur l’environnement d’exécution, les mécanismes qui entourent le modèle et la couche applicative. Leur dépôt commun doit accueillir d’autres évaluations, y compris des contributions extérieures. Aucune validation empirique générale des contrôles n’est fournie dans la matière publiée ici. La méthode devra donc évoluer avec les modèles, les formes de déploiement et les risques émergents.