Intelligence sur les risques liés aux modèles d’IA : sachez à quels modèles faire confiance avant leur déploiement

Lorsque nous avons commencé à réfléchir à la manière de faire ressortir les risques liés aux modèles d’IA dans Evo, la réponse semblait évidente : reprendre notre méthode habituelle pour évaluer les risques. Repérer le problème, lui attribuer un niveau de gravité, le signaler. Et voilà.

La nouvelle approche repose sur un véritable score de risque, fondé sur la manière dont les équipes de sécurité évaluent déjà les risques : probabilité × impact. La probabilité est calculée à partir du taux de réussite des attaques (ASR), c’est-à-dire la part des attaques adversariales réelles qui parviennent à contourner un modèle. L’impact mesure les dommages causés lorsque l’attaquant atteint son objectif. Nous combinons ces deux facteurs en un score unique de 0 à 1 000 (plus le score est bas, mieux c’est).

Comme les deux facteurs sont multipliés, aucun ne l’emporte à lui seul : une attaque rare, mais catastrophique, voit son score réduit par sa faible probabilité, tandis qu’une attaque fréquente, mais inoffensive, est pénalisée par son faible impact. Ce qui ressort, c’est ce qui compte le plus : les attaques qui réussissent souvent et causent de réels dommages.

Nouvelle méthodologie de calcul du score de risque

Ce qui différencie cette méthode d’une liste de contrôle ou d’une fiche de sécurité fournisseur, c’est que l’ASR est issu de tests adversariaux réels : prompts d’extraction, escalade en plusieurs tours, jailbreaks fondés sur des personas et stratégies d’attaque en arbre. Des évaluateurs basés sur des modèles confirment ensuite la réussite de chaque attaque.

Ces attaques ne sont pas théoriques, et les chiffres ne sont pas ceux de modèles testés « à nu ». Chaque attaque du banc d’essai cible un système de base doté d’un prompt système renforcé. Le score de risque reflète donc ce qui parvient encore à franchir une protection standard déjà en place : les attaques qui fonctionnent en production, pas seulement en laboratoire.

Le score est exploitable parce qu’il est axé sur l’impact : il tient compte de ce qui se passe réellement lorsqu’une attaque réussit, et pas seulement de sa réussite. Et il ne se limite pas à un chiffre. Evo détaille chaque score en précisant l’objectif de l’attaquant : extraction de données personnelles, extraction du prompt système par injection ou génération de code non sécurisé. Vous voyez ainsi précisément les faiblesses d’un modèle donné et pouvez mettre en place la protection adaptée. Ce niveau de détail vous fournit les informations nécessaires avant de décider d’un déploiement.

Les équipes de sécurité y trouvent immédiatement leur compte. Elles voient les risques d’un modèle détaillés selon les objectifs d’attaquants auxquels il ne résiste pas, plutôt qu’un verdict abstrait « sûr / non sûr ». Elles n’ont plus à se demander si le modèle est sûr en général : elles peuvent se demander s’il l’est pour ce qu’elles s’apprêtent à créer.

Cette première approche — repérer le problème, lui attribuer un niveau de gravité et passer à autre chose — présentait un sérieux défaut, que nos clients nous ont directement signalé.

Quand les équipes de sécurité voyaient une alerte indiquant qu’un modèle présentait un problème de « divulgation d’informations », elles posaient toujours la même question : qu’est-ce que cela signifie concrètement, et que dois-je faire ? Le libellé leur indiquait qu’un problème existait, mais pas à quel point il était grave, dans quel contexte, face à quel type d’attaque, ni quelle mesure prendre pour le corriger.

Nous avons donc repensé l’approche. Voici ce qui a changé et pourquoi.

Le problème est apparu à maintes reprises lors de conversations avec des clients. Lorsque nous avons présenté des chiffres concrets — GPT-3.5 avec un score de 397/1 000 pour le contenu dangereux, GPT-4 avec un score de 317/1 000 pour les biais et l’équité — les équipes ont cessé de demander si un modèle était sûr et ont commencé à les comparer.

Le problème ne vient pas du score, mais du contexte.

La plupart des évaluations des risques liés à l’IA traitent un modèle comme un élément statique. On lance quelques tests, on attribue une catégorie, puis on publie une fiche de sécurité. Les équipes s’appuient ensuite sur ces informations pour décider du déploiement.

Mais les risques liés à l’IA ne fonctionnent pas ainsi. Un même modèle présente des risques fondamentalement différents selon son mode de déploiement. Un agent de programmation est exposé au vol d’identifiants, aux portes dérobées, aux commandes contrôlées par un attaquant et à l’empoisonnement des dépendances. Un chatbot destiné aux clients est exposé aux jailbreaks, à la génération de contenu dangereux et à l’extraction de prompts. Un assistant personnel ayant accès aux e-mails, à l’agenda et aux documents est confronté à une surface d’attaque entièrement différente.

Un score de risque qui ne tient pas compte du contexte de déploiement n’est pas un score de risque. C’est une estimation. Evo intègre ce contexte dans la pondération de l’impact afin que le score reflète l’usage réel du modèle, et non son comportement dans l’abstrait.

Il existe un deuxième problème : les attaques indirectes. La plupart des évaluations de modèles se concentrent sur les prompts directs : un utilisateur saisit une instruction malveillante et l’on vérifie si le modèle y résiste. C’est important, mais cela laisse de côté la catégorie d’attaques la plus dangereuse pour les systèmes agentiques : l’injection indirecte de prompt, qui consiste à intégrer des instructions malveillantes dans les données consultées par l’agent, par exemple un document récupéré, le résultat d’un outil ou un commentaire de code. L’utilisateur ne les voit jamais. L’agent les traite comme du contexte. S’il suit ces instructions, il peut divulguer des données sensibles, détourner des outils ou effectuer des actions non autorisées. Les tests portant uniquement sur le modèle ne détectent jamais ce type d’attaque.

Ce n’est pas un risque théorique. Une grande entreprise nous a contactés au sujet d’un incident urgent directement lié aux risques associés aux modèles de LLM et, dans une banque internationale,, un problème similaire a été porté jusqu’au PDG. Un établissement de crédit national voulait mieux connaître l’utilisation de MCP et mettre en place des garde-fous. Ces équipes ne posaient pas de questions générales sur la sécurité des modèles : elles voulaient comprendre leur comportement dans un contexte agentique précis.

Nous voulions que Risk Intelligence réponde à une autre question : comment ce modèle se comporte-t-il face à une attaque, dans les conditions de déploiement que vous envisagez réellement ?

Notre solution : un risque fondé sur l’impact, jusqu’à l’objectif de l’attaquant

1. Quels modèles et quelles compétences d’IA sont utilisés dans la base de code ? Les équipes de sécurité doivent savoir où l’IA est utilisée, quels modèles sont appelés et quels outils ou compétences font partie du système.

2. Comment chaque modèle se comporte-t-il face aux attaques ? Les équipes ont besoin de profils de risque fondés sur des tests adversariaux, et non sur des déclarations statiques ou une documentation générique sur la sécurité.

3. Comment agir à partir des résultats ? Un score n’est utile que s’il aide les équipes à comparer les modèles, à prioriser les garde-fous et à appliquer leurs politiques dans les applications et les dépôts.

Le résultat principal est un score de risque unique de 0 à 1 000, pondéré en fonction de l’impact réel des objectifs qu’un attaquant peut atteindre. Le taux de réussite des attaques est la mesure qui le sous-tend.

Le score vous indique le niveau d’exposition d’un modèle. La taxonomie précise quelles attaques en sont à l’origine et pourquoi elles sont importantes dans votre contexte de déploiement.

Evo organise les résultats selon une taxonomie à trois niveaux, fondée sur l’impact, c’est-à-dire sur les conséquences concrètes. Une catégorie d’impact générale (par exemple, la divulgation d’informations) se décline en sous-catégories, puis en objectifs précis d’attaquants (par exemple, l’extraction de données personnelles). Les attaques directes et indirectes sont suivies comme des surfaces distinctes dans l’ensemble de la taxonomie, car elles nécessitent des protections différentes. Un agent de programmation présentant un ASR élevé pour l’injection indirecte par le biais de commentaires de code a besoin d’un garde-fou différent de celui d’un chatbot présentant un ASR élevé pour les jailbreaks. La taxonomie rend cette distinction explicite.

De plus, chaque objectif d’attaquant est associé aux référentiels utilisés par votre équipe : OWASP LLM Top 10, OWASP Agentic, MITRE ATLAS et NIST. Un résultat n’est donc pas un libellé propriétaire de Snyk que vous devez traduire : il s’intègre directement aux normes qui encadrent déjà vos activités. Vous trouverez ces correspondances dans l’onglet du profil de risque, à côté du score.

C’est ce niveau de précision qui permet aux équipes de passer d’un score à un plan de remédiation. Il permet aussi à Evo de relier directement les résultats liés aux risques à l’application des politiques, dans le cadre du même processus plutôt que d’un flux de travail distinct.

Couverture des compétences, pas seulement des modèles

Les libellés généraux de risque ne suffisent pas. Indiquer à une équipe qu’un modèle présente un problème de « divulgation d’informations » ou de « contenu dangereux » peut la sensibiliser, mais ne lui indique pas quoi corriger. Une intelligence des risques utile détaille chaque résultat en précisant l’objectif de l’attaquant : extraire le prompt système par injection, exécuter des outils sans autorisation, générer du contenu dangereux, produire du code non sécurisé ou exfiltrer des données sensibles.

Ce niveau de détail aide les équipes à décider quels garde-fous créer, quelles politiques appliquer et si un modèle convient à un cas d’utilisation donné. Il aide aussi les responsables à comprendre les risques à différents niveaux. Une catégorie générale peut révéler les domaines d’exposition de l’organisation. Une surface d’attaque plus détaillée peut montrer si les attaques sont directes ou indirectes. Un objectif précis d’attaquant peut indiquer aux équipes d’ingénierie exactement ce qui a échoué.

Les risques ne concernent pas uniquement les modèles. Ils résident aussi dans la combinaison du modèle, des outils qu’il peut appeler et des compétences qu’il utilise. Un modèle qui obtient de bons résultats de manière isolée peut se comporter très différemment lorsqu’il est associé à un outil d’accès au système de fichiers, à un environnement d’exécution de code ou à un dépôt de données sensibles.

Evo cartographie la couverture des compétences en parallèle des risques liés aux modèles, afin que les équipes sachent clairement quelles compétences sont utilisées, à quels modèles elles sont associées et quelle est la surface d’attaque combinée. Cet inventaire est indispensable aux équipes de sécurité pour prendre des décisions de déploiement en toute confiance.

C’est particulièrement important pour les agents de programmation : un même modèle peut examiner des demandes de fusion à un instant, puis exécuter des commandes de déploiement l’instant d’après. Le profil de risque varie considérablement selon la tâche effectuée par le modèle et les outils auxquels il a accès.

Des preuves à l’application des politiques

Evo aide les équipes à comprendre le comportement des modèles face aux attaques avant de leur faire confiance en production. Lorsqu’il analyse une base de code, Evo repère les modèles et les compétences d’IA utilisés et les enrichit de profils de risque issus de tests adversariaux. Ces profils s’appuient sur le taux de réussite des attaques, mesuré face à des attaques adversariales réelles et pondéré en fonction de l’impact. Le score reflète donc les conséquences, et pas seulement le nombre d’attaques.

Risk Intelligence organise également les résultats selon une taxonomie détaillée, des catégories générales jusqu’aux objectifs précis des attaquants. Chaque résultat est associé à OWASP LLM Top 10, OWASP Agentic, MITRE ATLAS et NIST. Les équipes peuvent ainsi passer d’un score général au type exact d’attaque qui a réussi, puis le rapprocher du référentiel qu’elles utilisent déjà. Grâce à son intégration au moteur de politiques d’Evo, Risk Intelligence permet de transformer les informations en mesures concrètes. Les équipes peuvent comparer les modèles avant de s’engager, repérer ceux qui présentent le plus de risques dans certains contextes de déploiement, commencer par les politiques prêtes à l’emploi et personnaliser les seuils en fonction de leur tolérance au risque.

C’est souvent entre le score de risque et la politique d’application que les programmes de sécurité de l’IA s’enlisent. Les équipes reçoivent un résultat, sans savoir quoi en faire.

Evo comble cette lacune en reliant directement Risk Intelligence à son moteur de politiques. Lorsqu’un modèle obtient un score de risque élevé pour un objectif précis d’attaquant ou un type d’attaque donné, les équipes peuvent définir des seuils, appliquer des politiques et bloquer l’utilisation de modèles à haut risque dans des contextes sensibles, le tout dans un même flux de travail.

Pour les clients de Snyk, cela prolonge une approche éprouvée : détecter les risques là où travaillent les développeurs, prioriser ce qui compte et appliquer les politiques de manière cohérente. La différence, c’est que la politique couvre désormais aussi le choix des modèles d’IA et la configuration des agents, et plus seulement le code.

Pourquoi est-ce important maintenant ?

La sécurité de l’IA ne peut pas reposer sur des suppositions. À mesure que les modèles et les agents s’intègrent aux applications du monde réel, les équipes doivent comprendre comment ces systèmes se comportent face aux attaques.

L’intelligence sur les risques liés aux modèles d’IA permet aux organisations de mesurer le comportement des modèles, de comparer les risques selon les cas d’utilisation, de prioriser la remédiation et de gouverner l’adoption de l’IA à grande échelle. La question n’est plus simplement : « Ce modèle est-il sûr ? » La meilleure question est : « Comment ce modèle se comporte-t-il face aux attaques dans les conditions de déploiement que nous envisageons ? »

La plupart des équipes avec lesquelles nous échangeons utilisent des modèles d’IA qu’elles n’ont pas explicitement choisis. Elles en ont hérité d’un fournisseur, les ont adoptés via un outil de développement ou les ont découverts au cours d’un audit. Le nouveau rapport de Snyk, State of Agentic Adoption, volume II, s’appuie sur des données de télémétrie anonymisées d’AI-BOM recueillies auprès de 3 044 organisations. Le constat est sans appel : pour chaque modèle connu d’une équipe, environ 2,8 autres composants d’IA, bibliothèques, serveurs MCP et SDK fonctionnent sans être gérés, et la plupart des organisations sont incapables de dresser un inventaire complet de leurs ressources. Une équipe qui a évalué le travail a estimé qu’un inventaire complet de l’IA lui aurait demandé 4 à 5 semaines et mobilisé 10 à 12 parties prenantes. Le problème de l’inventaire des modèles est bien réel, avant même d’aborder la question de l’évaluation des risques.

La demande pour ce type de fonctionnalité augmente rapidement. Les capacités améliorées d’AI-SPM sont dès à présent disponibles pour les clients existants. Les scores de risque fondés sur l’impact et sur le taux de réussite des attaques (Attack Success Rate), calculés à partir de tests adverses réels, seront disponibles fin août 2026. Réservez une démo dès aujourd’hui pour en savoir plus.