Comment les RSSI peuvent mesurer les risques de sécurité liés à l’IA

Lee EnnisResponsable senior, science des données | F5

Louise ScullyResponsable senior du marketing produit, sécurité de l’IA et renseignement sur les menaces | F5

Les risques liés à la sécurité de l’IA deviennent de plus en plus difficiles à gérer par les RSSI au moyen des seules politiques. À mesure que les organisations adoptent davantage de modèles d’IA, d’applications d’IA et de workflows agentiques, les responsables de la sécurité ont besoin de méthodes plus claires pour déterminer quels modèles peuvent être utilisés, quels fournisseurs sont susceptibles d’introduire des risques et comment les systèmes d’IA se comportent lorsqu’ils sont exposés à des menaces réelles.

C’est là que la mesure prend toute son importance. Les référentiels de sécurité de l’IA de F5, notamment le Comprehensive AI Security Index (CASI) et l’Agentic Resistance Score (ARS), aident les organisations à évaluer les risques liés aux modèles d’IA, à comparer leur niveau de sécurité et à comprendre comment les modèles et les systèmes agentiques se comportent face à des attaques. Associés aux renseignements continus sur les menaces liées à l’IA fournis par F5 Labs, ces référentiels offrent aux RSSI une base factuelle plus solide pour sélectionner les modèles, encadrer les fournisseurs, assurer la protection à l’exécution et évaluer en continu les risques liés à l’IA.

C’est important, car de nombreuses décisions relatives à la sécurité de l’IA sont prises bien avant qu’un modèle ne soit mis en production. Lorsqu’un système d’IA devient opérationnel, l’organisation peut avoir déjà sélectionné le modèle, approuvé le fournisseur, défini l’architecture, cartographié les flux de données, connecté les outils et accordé les accès au système. Les contrôles à l’exécution restent essentiels, mais ils sont plus efficaces lorsqu’ils reposent sur de meilleures décisions prises en amont.

Pour les RSSI, la question n’est plus seulement de savoir comment sécuriser l’IA une fois déployée. Il s’agit de déterminer comment mesurer les risques liés à l’IA tout au long de son cycle de vie, depuis l’acquisition et la sélection des modèles jusqu’au déploiement, à la surveillance et aux tests continus.

Le risque lié à l’IA apparaît avant même son exécution

La sécurité de l’IA est souvent abordée sous l’angle de la protection à l’exécution : surveillance des prompts, contrôle des résultats et prévention des usages abusifs une fois les systèmes d’IA mis en production. Ces mesures de contrôle sont essentielles, mais elles ne constituent qu’une partie du cycle de vie de la sécurité de l’IA.

Le risque lié à l’IA ne se limite pas à la phase d’exécution. Il concerne également les achats, la gouvernance des fournisseurs et l’architecture. Si l’évaluation de la sécurité n’intervient qu’après le déploiement, les RSSI peuvent se retrouver à gérer des risques qui auraient pu être réduits, remis en question ou évités plus tôt dans le processus. L’objectif n’est pas de ralentir l’adoption de l’IA, mais d’aider les organisations à avancer plus rapidement en ayant une vision plus claire des risques qu’elles acceptent.

Ce que montrent les recherches récentes

Chaque mois, F5 Labs publie des renseignements sur les menaces liées à la sécurité de l’IA, parallèlement aux classements CASI et ARS, afin de suivre l’évolution des risques associés aux modèles, aux systèmes agentiques et à l’écosystème. Les recherches de F5 Labs de mai 2026 mettent en évidence une évolution plus générale de la manière dont les RSSI doivent appréhender les risques liés à l’IA. Ces conclusions ne constituent pas seulement des indicateurs techniques destinés aux chercheurs ; elles offrent des enseignements concrets aux responsables de la sécurité chargés d’approuver les modèles, d’évaluer les fournisseurs, de définir les politiques et de protéger les applications d’IA lors de leur mise en production.

Le premier enseignement est que le choix du modèle constitue désormais une décision de sécurité. L’analyse CASI de mai a révélé un écart marqué en matière de posture de sécurité au sein de la famille de modèles Qwen, notamment une différence de 78 points entre Qwen3-2B et Qwen3-4B. Pour les RSSI, la conclusion est claire : connaître le nom du modèle ne suffit pas. Les différentes tailles, versions, configurations et options de déploiement peuvent présenter des profils de risque distincts.

Un modèle plus petit ou moins coûteux peut sembler constituer une solution de remplacement intéressante s’il offre des performances suffisantes pour une tâche donnée. Toutefois, s’il présente un niveau de sécurité sensiblement différent, les équipes de sécurité devront peut-être remettre en question ou empêcher ce remplacement. Il est plus facile de défendre cette décision en s’appuyant sur des tests objectifs, des scores comparatifs et une vision claire des performances respectives des modèles dans des conditions adverses.

Le deuxième enseignement est que les mécanismes de sécurité de l’IA peuvent échouer d’une manière que des politiques statiques ne permettent pas de détecter. Les renseignements sur les menaces publiés en mai ont mis en évidence des techniques adverses qui continuent de mettre à l’épreuve les limites des dispositifs de protection des modèles, notamment des méthodes de jailbreak conçues pour contourner les contrôles prévus. Pour les RSSI, il faut retenir que les tests de sécurité de l’IA doivent évoluer au même rythme que les attaques, car un modèle qui semble sûr lors d’un test peut échouer lors d’un autre.

La troisième leçon est que les risques liés à la chaîne d’approvisionnement de l’IA font désormais partie intégrante de la sécurité de l’IA. Les renseignements sur les menaces recueillis en mai ont mis en évidence des risques touchant les workflows de développement liés à l’IA, les écosystèmes de paquets, les pipelines CI/CD, les registres et les outils de développement intégrant l’IA. Leur point commun est la confiance : paquets, automatisations, registres, outils et chemins d’exécution de confiance. Pour les RSSI, cela signifie que les risques liés à l’IA ne proviennent pas uniquement des prompts, des résultats générés ou du comportement des modèles lors de leur exécution. Ils peuvent également provenir des fournisseurs, des outils, des paquets, des pipelines et des couches d’automatisation sur lesquels reposent les applications d’IA.

Ensemble, ces enseignements conduisent à la même conclusion : les RSSI doivent passer d’une politique en matière d’IA à une mesure de l’IA. Les politiques définissent ce qui devrait se produire, mais la mesure aide les équipes de sécurité à comprendre ce qui se passe réellement, quels risques sont introduits et quelles décisions doivent être revues.

Le risque lié aux modèles progresse plus vite que la gouvernance

À mesure que l’adoption de l’IA s’accélère, les organisations sont contraintes d’agir rapidement, de réduire les coûts et de prendre en charge davantage de cas d’usage dans l’ensemble de l’entreprise. Les équipes comparent les modèles en fonction de leurs performances, de leur latence, de leur disponibilité, de leur facilité de déploiement et de leur prix. Toutefois, les capacités et le coût ne suffisent pas à dresser un tableau complet. Un modèle qui semble pouvoir en remplacer un autre d’un point de vue opérationnel peut présenter un niveau de risque différent en matière de sécurité de l’IA, même s’il appartient à la même famille de modèles.

Un fournisseur peut affirmer qu’il utilise un modèle connu. Une équipe interne peut indiquer qu’elle passe à un modèle plus petit pour gagner en efficacité. Une équipe produit peut supposer que les modèles d’une même famille se comportent globalement de manière similaire. Du point de vue de la sécurité, ces suppositions peuvent être risquées, en particulier lorsque le modèle est connecté à des données sensibles, à des expériences destinées aux clients, à des processus métier critiques ou à des systèmes agentiques capables d’agir au nom des utilisateurs.

Les RSSI ont besoin d’éléments probants qui vont au-delà du nom du modèle. Ils doivent comprendre comment un modèle se comporte face à des attaques, comment il se compare aux autres solutions et si une modification proposée a une incidence significative sur le niveau de risque de l’organisation.

CASI permet de mesurer plus tôt les risques liés aux modèles

CASI permet aux organisations de comparer le niveau de sécurité de référence des modèles d’IA avant leur déploiement. Pour les RSSI, la sécurité des modèles cesse ainsi d’être un sujet d’appréciation subjective et devient un indicateur mesurable facilitant la prise de décision.

Dans la pratique, CASI prend en charge plusieurs processus de gouvernance. Il aide les équipes de sécurité à déterminer si un modèle convient à un cas d’usage particulier, sachant qu’un modèle utilisé pour des synthèses internes à faible risque peut ne pas nécessiter le même niveau d’examen qu’un modèle connecté à des données clients, à des processus critiques pour l’entreprise ou à des systèmes agentiques autonomes. Il peut également renforcer la gouvernance des achats et des fournisseurs en donnant aux équipes de sécurité des bases plus claires pour déterminer quels modèles sont utilisés, comment ils ont été testés et quels éléments probants justifient ces choix.

Si l’entreprise souhaite adopter un modèle moins coûteux, l’analyse comparative peut aider à déterminer si ce changement est acceptable, si des contrôles supplémentaires sont nécessaires ou si le risque l’emporte sur les avantages.

La veille sur les menaces révèle les risques liés à l’écosystème

Les récentes informations sur les menaces sont importantes, car elles montrent que les risques de sécurité liés à l’IA ne se limitent pas au modèle lui-même. Pour les RSSI, le constat le plus pertinent est que ces risques s’étendent aux systèmes qui entourent l’IA : processus de travail des développeurs, écosystèmes de paquets, pipelines CI/CD, registres, couches d’automatisation et outils intégrant l’IA.

Les développeurs installent des paquets, les agents exécutent des tâches, les pipelines CI/CD publient du code, les registres distribuent des dépendances et les outils intégrant l’IA ont accès aux environnements locaux et aux workflows. Si ces chaînes de confiance ne sont pas encadrées, testées et surveillées, des risques peuvent être introduits avant même qu’une application d’IA ne soit mise en production.

Pour les RSSI, l’enseignement à tirer de ces renseignements sur les menaces est que la gouvernance de l’IA doit englober l’écosystème qui soutient le développement de l’IA, et pas seulement le modèle choisi ou les contrôles d’exécution qui l’encadrent. Les évaluations des fournisseurs doivent porter sur les sources des modèles, les pipelines de développement, la gouvernance des paquets, les autorisations accordées aux outils et la gestion des dépendances. Les revues d’architecture doivent examiner les ressources auxquelles les agents et les outils intégrant l’IA peuvent accéder, les actions qu’ils peuvent exécuter et les cas où une approbation humaine est requise. CASI aide à évaluer les risques liés aux modèles avant leur déploiement, tandis qu’ARS permet d’évaluer le comportement des systèmes agentiques face à des attaques.

ARS mesure la résilience agentique

À mesure que les organisations passent des modèles d’IA aux applications d’IA et aux workflows agentiques, la mesure devient plus complexe. Un modèle peut sembler acceptable lorsqu’il est évalué isolément, mais le niveau de risque peut évoluer lorsqu’il est connecté à des outils, des API, des sources de données, une logique métier ou des systèmes qui lui permettent d’agir.

ARS étend la mesure à cette couche opérationnelle en aidant les organisations à évaluer les performances des systèmes agentiques soumis à une pression adverse prolongée. Ces systèmes ne se contentent pas de générer des résultats : ils peuvent prendre des décisions, faire appel à des outils, récupérer des données, déclencher des workflows ou influer sur des processus métier.

Cela signifie que les tests de sécurité de l’IA doivent tenir compte du comportement des systèmes dans la durée et lorsqu’ils sont soumis à des attaques, et pas seulement des performances d’un modèle individuel dans le cadre d’une évaluation contrôlée. ARS aide les RSSI à déterminer dans quels domaines les systèmes agentiques peuvent être plus résilients, où des contrôles supplémentaires peuvent s’avérer nécessaires et comment les applications d’IA se comportent lorsqu’elles sont exposées à des techniques d’attaque réelles.

De la politique à l’action mesurable

L’étape suivante consiste à intégrer dès le départ la mesure dans les décisions relatives à l’IA. La sécurité de l’IA doit faire partie intégrante de l’ensemble du cycle de vie, depuis l’évaluation des modèles et l’examen des fournisseurs jusqu’à la conception de l’architecture, au déploiement, à la protection lors de l’exécution, aux tests continus et à la surveillance permanente. Cette vision globale du cycle de vie est essentielle, car les risques liés à l’IA évoluent au fil du temps. De nouvelles techniques d’attaque apparaissent, les modèles sont mis à jour, les fournisseurs modifient leurs systèmes sous-jacents et les workflows agentiques ouvrent de nouvelles voies à une utilisation abusive.

Pour les RSSI, cela signifie que la sécurité de l’IA ne peut pas se limiter à une validation ponctuelle. Elle doit devenir une discipline continue, intégrant des mesures et des tests tout au long du cycle de vie.

Rendre le risque lié à l’IA défendable

Les RSSI sont appelés à accompagner l’adoption de l’IA tout en gérant un paysage des risques encore en pleine évolution. Ils doivent favoriser l’innovation, mais aussi répondre aux questions difficiles des conseils d’administration, des autorités de réglementation, des clients et des parties prenantes internes.

Quels modèles sont approuvés pour une utilisation ? Quels fournisseurs sont susceptibles d’introduire des risques liés à l’IA ? Quels cas d’usage nécessitent des tests supplémentaires ? Dans quels cas un modèle moins coûteux ou plus rapide constitue-t-il une solution de remplacement acceptable, et dans quels cas présente-t-il trop de risques ? Sur quels éléments probants ces décisions reposent-elles ?

Ces questions ne sont pas purement techniques. Elles concernent la gouvernance, les achats et les risques pour l’entreprise. Elles nécessitent de plus en plus de preuves objectives.

Les organisations qui gagneront le plus rapidement en maturité seront celles qui dépasseront le stade des évaluations informelles de l’IA et commenceront à intégrer des mesures dans leurs processus décisionnels en matière d’IA. Cela implique d’évaluer les modèles avant de les sélectionner, de tester les systèmes avant de les déployer à grande échelle et de réévaluer continuellement les risques à mesure que les modèles, les menaces, les fournisseurs et les cas d’usage évoluent.

Les RSSI ne peuvent pas attendre le déploiement pour mesurer les risques liés à l’IA. Les décisions les plus pertinentes se prennent plus tôt dans le cycle de vieEn combinant CASI, ARS et les renseignements continus sur les menaces liées à l’IA fournis par F5 Labs, les RSSI peuvent rendre les risques de sécurité liés à l’IA plus visibles, plus faciles à justifier et plus exploitables tout au long du cycle de vie de l’IA.

Pour en savoir plus, consultez les recherches de F5 Labs.

À propos des auteurs

Lee EnnisResponsable senior, science des données | F5

Lee Ennis dirige l’équipe de recherche et de science des données en IA chez F5, où il se consacre au développement de solutions avancées de sécurité de l’IA qui aident les entreprises à déployer et à surveiller en toute sécurité les grands modèles de langage (LLM) et les systèmes d’IA générative. Son équipe conjugue son expertise en apprentissage automatique, en tests adversariaux et en assurance des modèles afin d’identifier les vulnérabilités et de renforcer la confiance dans les environnements pilotés par l’IA.

Autres articles de Lee Ennis

Louise ScullyResponsable senior du marketing produit, sécurité de l’IA et renseignement sur les menaces | F5

Louise Scully est Senior Manager en marketing produit pour la sécurité de l’IA et le renseignement sur les menaces chez F5. Au cours de sa carrière, elle a exercé dans les domaines du marketing produit, de la gestion de produits, de la stratégie de mise sur le marché, de la communication, du leadership d’opinion et du développement de catégories, dans les secteurs de la sécurité de l’IA et des technologies d’entreprise. Avant de rejoindre F5, Louise a dirigé le marketing chez CalypsoAI et Artomatix, contribuant à la commercialisation de technologies et de travaux de recherche en IA.

Autres articles de Louise Scully