NVIDIA a réuni des dizaines d’entreprises et d’organisations open source afin de former l’Open Secure AI Alliance, un groupe axé sur le développement d’outils librement accessibles pour la sécurité de l’IA et la cybersécurité. Cette initiative a pour objectif d’aider les défenseurs à inspecter, adapter et exploiter des systèmes de sécurité au sein de leur propre infrastructure plutôt que de s’en remettre exclusivement à des fournisseurs d’IA fermés.

L’alliance comprend des entreprises telles qu’Amazon, Microsoft, IBM, Cisco, Google ? Non — Google n’est pas cité — ainsi que Hugging Face, Mistral, Red Hat, CrowdStrike, Palo Alto Networks, Salesforce, ServiceNow, Databricks, GitHub et la Linux Foundation. NVIDIA indique que le groupe développera et partagera des technologies pour sécuriser les logiciels et les agents d’IA, notamment des modèles, des harnesses d’agents, des systèmes d’identité, des outils d’évaluation et des formats de modèle sécurisés.

Une alliance construite autour d’une infrastructure défensive ouverte

NVIDIA présente l’initiative comme une extension des travaux de sécurité open source déjà associés à l’initiative Akrites de la Linux Foundation et à l’Open Source Security Foundation, ou OpenSSF. Son objectif déclaré est d’aider à corriger et à divulguer les vulnérabilités à l’aide de technologies ouvertes, tout en donnant à davantage de défenseurs accès à des systèmes qu’ils peuvent examiner et modifier.

L’argument central est que la sécurité de l’IA ne peut pas dépendre uniquement d’un petit nombre de systèmes opaques et fermés. NVIDIA affirme que les modèles et outils ouverts peuvent offrir un contrôle local, une protection des données et la possibilité d’adapter les flux de travail de sécurité à des secteurs ou à des juridictions spécifiques. L’entreprise soutient également qu’un écosystème multi-fournisseur peut réduire la dépendance à un seul prestataire.

Cette position n’équivaut pas à un rejet des modèles fermés. NVIDIA affirme que les défenseurs ont besoin à la fois de systèmes frontaliers ouverts et fermés, en utilisant chacun là où il est le plus approprié. L’accent mis par l’alliance est de garantir que des alternatives ouvertes performantes restent disponibles pour les opérations de sécurité et la recherche.

L’annonce intervient alors que les entreprises passent de l’expérimentation avec des modèles de langage au déploiement d’agents d’IA capables d’accéder à des fichiers, d’appeler des outils logiciels et d’agir. Ce changement élargit le problème de sécurité au-delà du comportement du modèle. Il introduit également des risques liés à l’identité, aux autorisations, à l’isolation, à l’auditabilité et à la chaîne d’approvisionnement logicielle.

La pile proposée va au-delà des poids du modèle

NVIDIA indique que sa contribution comprendra des modèles ouverts, des poids de modèle, des données et des recherches sur les harnesses d’agents. Elle publie également sur GitHub le framework NVIDIA Labs Object-Oriented Agent, ou NOOA. L’entreprise décrit NOOA comme un cadre de recherche destiné à rendre le comportement des agents plus facile à tester, à tracer, à auditer et à gouverner en améliorant la manière dont les harnesses s’intègrent aux modèles.

D’autres exemples cités par NVIDIA illustrent l’ampleur visée par l’alliance. HPE contribue à SPIFFE/SPIRE, un cadre d’identité conçu pour vérifier cryptographiquement les agents et les services avant qu’ils ne communiquent ou n’accèdent aux ressources de l’entreprise. Hugging Face a proposé Safetensors, un format de poids de modèle destiné à empêcher l’exécution de code à distance, à la PyTorch Foundation.

IBM et Red Hat sont associés à Lightwell, qui étend les correctifs signés numériquement à la chaîne d’approvisionnement open source. Microsoft contribue à MDASH, décrit comme un harness de balayage multi-modèle dans lequel des agents spécialisés recherchent, débattent et déterminent si des bogues logiciels sont exploitables.

L’ensemble des projets suggère que l’alliance considère un agent d’IA comme un système opérationnel complet et non comme un simple modèle. En pratique, cela signifie que les contrôles de sécurité doivent couvrir le modèle, ses outils, ses autorisations, ses journaux et l’infrastructure qui l’exécute. Des harnesses ouverts et des formats communs pourraient faciliter l’inspection et l’évaluation de ces contrôles par des équipes indépendantes.

Ce que montrent les éléments probants — et ce qui reste à démontrer

Les preuves disponibles proviennent principalement de l’annonce de NVIDIA elle-même. StorageNewsletter mentionne le même lancement de l’alliance, mais le texte intégral de son article n’est pas disponible dans les éléments de reportage fournis. Par conséquent, la liste des membres, les contributions techniques et les objectifs déclarés doivent être considérés comme des informations publiées par NVIDIA plutôt que comme des preuves indépendamment vérifiées d’une exécution conjointe.

NVIDIA cite un récent incident de sécurité chez Hugging Face comme exemple de la raison pour laquelle les défenseurs pourraient avoir besoin de systèmes d’IA ouverts et auto-hébergés. Selon le récit de NVIDIA, les outils fermés ont bloqué certaines parties de l’analyse forensique parce qu’ils ne pouvaient pas distinguer les défenseurs des attaquants. Hugging Face a ensuite exécuté le modèle open-weight GLM 5.2 sur sa propre infrastructure pour analyser plus de 17 000 actions et contenir l’intrusion.

Ce récit illustre l’intérêt opérationnel du contrôle local, mais les détails sont présentés par NVIDIA et ne sont pas corroborés indépendamment dans les sources fournies. L’annonce ne fournit pas non plus de calendrier de livraison, de modèle de gouvernance, de structure de financement, de chiffres d’adoption ni de description de la manière dont les organisations participantes coordonneront les versions et la réponse aux vulnérabilités.

Le débat sur la sécurité reste lui aussi non résolu. NVIDIA reconnaît que les modèles ouverts peuvent être mal utilisés, notamment en affaiblissant les garde-fous ou en détournant des capacités à des fins d’attaque. Sa réponse proposée consiste à combiner l’ouverture avec l’évaluation, le red teaming, des règles d’utilisation et une remédiation rapide. Ce sont à ce stade des principes et non des résultats démontrés.

Pourquoi les développeurs et les acheteurs d’entreprise devraient s’y intéresser

Pour les développeurs d’IA, l’alliance pourrait créer des composants plus réutilisables pour sécuriser les applications agentiques. Une identité standardisée, des formats de modèle plus sûrs et des harnesses testables pourraient réduire la nécessité pour chaque entreprise de construire des contrôles distincts autour de l’accès aux outils, de la journalisation et de la provenance des modèles. Ils pourraient aussi faciliter l’exécution d’agents de sécurité dans l’environnement propre d’une entreprise lorsque des données sensibles ne peuvent pas être envoyées à un service externe.

Les acheteurs d’entreprise devraient suivre la manière dont ces projets mûrissent, et pas seulement la taille des membres fondateurs. Les composants ouverts peuvent améliorer la portabilité et l’auditabilité, mais ils créent aussi des responsabilités opérationnelles. Les organisations devront toujours valider le code, gérer les correctifs, surveiller le comportement des modèles et décider quels agents obtiennent l’accès aux systèmes de production.

L’alliance pourrait également accentuer la concurrence entre les plateformes d’IA centralisées et des architectures de sécurité plus distribuées. Un écosystème ouvert solide pourrait donner aux équipes de sécurité un pouvoir de négociation supplémentaire et réduire la dépendance à un fournisseur de modèles. Cependant, des outils fragmentés, une gouvernance incohérente et des accords de support peu clairs pourraient annuler ces avantages si les projets ne convergent pas vers des normes pratiques.

Pour les chercheurs et les décideurs publics, l’annonce renforce une question importante : les systèmes d’IA ouverts doivent-ils être considérés principalement comme des risques à restreindre, ou comme une infrastructure défensive que les équipes de sécurité doivent examiner et contrôler ? NVIDIA défend clairement la seconde vision, tout en reconnaissant que l’ouverture exige des garde-fous plutôt qu’un déploiement sans restriction.

Ce qu’il faut surveiller ensuite

Le premier signal sera de savoir si l’alliance publie une structure de gouvernance concrète, une feuille de route commune ou des normes techniques allant au-delà des projets nommés dans l’annonce de NVIDIA. Les acheteurs devraient également surveiller les versions prêtes pour la production de NOOA, MDASH, SPIFFE/SPIRE et des outils connexes de sécurité des agents, ainsi que la documentation montrant leur fonctionnement dans différents modèles et environnements cloud.

Les évaluations indépendantes compteront davantage que la liste des partenaires. Des éléments utiles incluraient des tests reproductibles des autorisations des agents, de la détection des vulnérabilités, des faux positifs, de la résistance à l’injection de prompts et de la sécurité des chaînes d’approvisionnement des modèles et des outils. Il sera également important de voir si les entreprises participantes divulguent les vulnérabilités via un processus commun et maintiennent les projets dans le temps.

Perspective de Creati.ai

L’Open Secure AI Alliance est importante parce qu’elle définit la sécurité de l’IA comme un problème d’infrastructure et de systèmes, et non simplement comme une question de choix d’un modèle plus sûr. Sa contribution la plus pratique pourrait être une couche partagée d’identité, de harnesses, de formats et d’outils d’évaluation permettant aux organisations d’exploiter des agents avec davantage de visibilité et de contrôle.

Mais l’annonce n’est encore qu’un point de départ. NVIDIA a fourni une large coalition et une série d’exemples rapportés par les fournisseurs, mais pas la preuve qu’une pile défensive interopérable existe déjà. L’alliance gagnera en crédibilité grâce à une gouvernance ouverte, des tests indépendants et une maintenance soutenue — surtout lorsque ses outils seront utilisés dans des incidents de sécurité sous forte pression plutôt que dans de simples démonstrations.