

La surface d’attaque de l’IA s’étend à mesure que les modèles accèdent à des outils, des identifiants, du code et des systèmes de production. Les recherches de F5 Labs publiées d’avril à juillet 2026 font ressortir un constat majeur : le risque que l’IA représente pour les entreprises ne dépend pas uniquement de la possibilité de manipuler un modèle, mais aussi des ressources auxquelles le système qui l’entoure lui permet d’accéder et des actions qu’il l’autorise à effectuer en cas de manipulation ou d’erreur.
Les recherches de F5 révèlent que des modèles aux capacités similaires peuvent présenter des profils de sécurité radicalement différents, que ces profils peuvent évoluer après le déploiement, que des fonctionnalités utiles peuvent créer de nouveaux vecteurs d’attaque et que des autorisations excessives peuvent transformer une faiblesse au niveau du modèle en incident pour l’entreprise. Ce risque n’est plus théorique. Lors d’incidents examinés par F5 Labs, des attaquants ont manipulé un processus de récupération de compte assisté par l’IA afin de modifier les informations d’accès, tandis qu’un agent de codage a supprimé une base de données de production ainsi que ses sauvegardes.
Pour les RSSI, l’intérêt de cette étude ne réside pas dans un récapitulatif du classement, mais dans les enseignements pratiques qu’elle apporte en matière de sélection des modèles, d’approvisionnement, d’assurance continue et de contrôle des ressources auxquelles les systèmes d’IA sont autorisés à accéder et des actions qu’ils peuvent effectuer.
F5 Labs utilise deux indicateurs complémentaires pour évaluer ces risques. Le F5 Comprehensive AI Security Index (F5 CASI) mesure la résistance aux attaques par injection de prompt et contournement des restrictions, tandis que le F5 Agentic Resistance Score (F5 ARS) mesure la résistance aux attaques prolongées en plusieurs étapes dans des scénarios agentiques. Tous deux sont notés de 0 à 100, les scores les plus élevés indiquant une meilleure résistance.
“Les recherches de F5 révèlent que des modèles aux capacités similaires peuvent présenter des profils de sécurité radicalement différents, que ces profils peuvent évoluer après le déploiement, que des fonctionnalités utiles peuvent créer de nouveaux vecteurs d’attaque et que des autorisations excessives peuvent transformer une faiblesse au niveau du modèle en incident pour l’entreprise.”
L’autorité transforme le risque lié au modèle en impact sur l’entreprise
Une faiblesse au niveau du modèle devient un incident pour l’entreprise lorsque le système qui l’entoure permet d’effectuer des actions lourdes de conséquences. Un modèle qui produit une réponse non sécurisée crée un risque. Un modèle connecté à du code, à des identifiants, à des processus de récupération de compte ou à des données de production peut provoquer un incident.
Dans un cas étudié par F5 Labs, un agent de programmation a supprimé une base de données de production ainsi que ses sauvegardes. Dans un autre, des attaquants ont manipulé un processus de récupération de compte assisté par l’IA afin de modifier les informations d’accès à des comptes de réseaux sociaux très suivis. Le problème critique ne tenait pas seulement au fait que l’IA avait tiré une conclusion erronée. Le système environnant a permis à cette conclusion de déclencher une action aux conséquences majeures.
L’opération de rançongiciel JadePuffer a confirmé ce constat du point de vue de l’attaquant. Un humain a sélectionné la victime, fourni les identifiants et mis en place l’infrastructure, mais l’agent a automatisé une part importante de la reconnaissance, de l’exploitation, des déplacements latéraux et du chiffrement. Une autonomie totale n’était pas nécessaire : l’automatisation partielle réduisait déjà le temps, les compétences et les efforts requis.
Pour les RSSI, le risque immédiat ne réside pas seulement dans l’autonomie, mais aussi dans les pouvoirs accordés. Les agents d’IA doivent être gérés comme des identités à privilèges, avec des identifiants aux droits strictement limités, un accès restreint aux outils, une surveillance continue et une approbation indépendante pour les actions à fort impact. Il faut ensuite se demander comment les attaquants exploitent les comportements qui font précisément l’utilité de ces systèmes.
Les fonctionnalités utiles créent des vecteurs d’attaque
Les recherches de F5 Labs ont révélé que les attaquants exploitaient de manière répétée des comportements que les entreprises recherchent activement dans les systèmes d’IA. Attaque par rôle de développeur ciblait la manière dont les modèles interprètent les instructions privilégiées. BiasJailbreak utilisait un cadrage démographique pour mettre en évidence les incohérences dans les comportements de refus, tandis que Topic Bridge exploitait la continuité conversationnelle pour faire progressivement passer les modèles de sujets légitimes à des requêtes malveillantes.
Adversarial Tales a prolongé cette même approche en intégrant des procédures nuisibles dans des récits fictifs et en demandant aux modèles d’analyser l’histoire plutôt que de répondre à une requête ouvertement malveillante. Sur 26 modèles de pointe issus de neuf fournisseurs, cette technique a atteint un taux de réussite moyen de 71,3 %.
Ces attaques ciblaient le suivi des instructions, le raisonnement contextuel, la compréhension des rôles et l’analyse de contenu, autant de capacités qui sous-tendent des cas d’usage légitimes en entreprise. Elles montrent comment des fonctionnalités utiles peuvent élargir la surface d’attaque de l’IA. Les filtres statiques et les bibliothèques de techniques de jailbreak connues peineront à faire face à des attaquants capables de préserver une intention malveillante tout en modifiant la manière dont elle est présentée.
Les comportements utiles peuvent donc ouvrir la voie à la manipulation, tandis que le niveau d’autorité et les droits d’accès déterminent l’impact potentiel sur l’entreprise. La probabilité d’une manipulation dépend également de la résilience intrinsèque du modèle, dont les capacités ne constituent qu’un indicateur peu fiable.
Les capacités ne permettent pas de prédire la résilience
Les tests de F5 Labs ont révélé que des modèles aux capacités similaires peuvent se situer aux extrémités opposées du classement en matière de sécurité, tandis que des modèles appartenant à une même famille peuvent se comporter de manière très différente.
L’exemple le plus frappant est celui de Qwen3.5. Son modèle à 2 milliards de paramètres a obtenu un score de 1,28 au F5 CASI, tandis que la version à 4 milliards de paramètres a obtenu un score de 80, soit un écart de près de 79 points entre deux modèles appartenant à la même famille.
Les derniers tests ont confirmé cette tendance. Sur F5 CASI, les scores des modèles phares aux capacités relativement similaires allaient de 93,08 à 16,25. Les données de F5 ARS ont apporté un éclairage supplémentaire : Qwen3.5-4B a obtenu un score de 91,04 sur F5 ARS, contre 58 sur F5 CASI, avec des performances moyennes de 16 %. Ce contraste montre pourquoi F5 CASI, F5 ARS et les performances doivent être interprétés comme des indicateurs distincts et complémentaires.
Pour les RSSI, les tests de capacités indiquent si un modèle peut accomplir une tâche, mais pas s’il peut le faire de manière sécurisée. Chaque modèle et chaque version doivent être évalués indépendamment lors de l’acquisition et tout au long du déploiement. Le choix du modèle n’est toutefois que la première décision : les équipes de sécurité doivent également tenir compte de l’évolution de sa résilience au fil du temps.
La posture de sécurité de l’IA peut évoluer après le déploiement
La résilience des modèles n’est pas immuable. F5 Labs a observé une baisse de plus de 29 points F5 CASI en un mois pour un modèle, tandis qu’un autre a évolué de plus de 55 points sur la période étudiée. D’autres versions sont restées relativement stables, faisant de la constance elle-même un élément du profil de risque.
Les fournisseurs peuvent mettre à jour les invites système, les classificateurs et les mécanismes de sécurité sans modifier le nom du modèle affiché aux clients. Un modèle peut donc sembler inchangé alors que son niveau de sécurité a considérablement évolué.
Il ne s’agit pas d’un problème classique de gestion des correctifs. Une approbation ponctuelle ne suffit pas lorsque la posture de sécurité d’un modèle peut évoluer sans changement de nom ni événement de déploiement visible. Les équipes de sécurité doivent réévaluer les modèles après les mises à jour du fournisseur, les changements de configuration et les modifications importantes apportées à l’application, et vérifier en permanence que les contrôles environnants restent efficaces.
Cette volatilité rend indispensable une assurance continue, mais l’évaluation seule ne suffit pas. Les RSSI doivent également contrôler les ressources auxquelles les systèmes d’IA sont autorisés à accéder ainsi que les actions qu’ils peuvent effectuer.
Ce que les RSSI doivent faire dès maintenant
La principale conclusion de cette étude est que le niveau d’autorisation détermine l’impact. Les RSSI doivent encadrer les systèmes d’IA en fonction des ressources auxquelles ils sont autorisés à accéder et des actions qu’ils peuvent effectuer, tout en évaluant en permanence les modèles, les contrôles et les systèmes qui les entourent.
- Traitez les agents d’IA comme des identités à privilèges élevés. Recensez et limitez les accès aux identifiants, aux outils, aux données et aux systèmes de production ; exigez une approbation indépendante pour les actions à fort impact ; et consignez chaque étape ayant des conséquences.
- Évaluez en continu l’ensemble du système d’IA. Évaluez chaque modèle et chaque version de manière indépendante lors de l’acquisition et tout au long du déploiement, procédez à une nouvelle évaluation après toute modification du fournisseur ou de la configuration, et testez les passerelles, les packages, les plugins, les workflows, les identités et les intégrations, et pas seulement le modèle.
Comment F5 Labs mesure la résilience de l’IA
F5 CASI et F5 ARS sont des mesures comparatives, et non des certifications de sécurité permanentes. Les résultats doivent être interprétés en tenant compte de la version exacte du modèle, de la date de l’évaluation, de l’usage prévu et des mesures de contrôle en place.
Pris dans leur ensemble, ces travaux mettent en évidence une chaîne de risques interconnectés : les capacités ne permettent pas de prédire la résilience, celle-ci peut évoluer après le déploiement, des fonctionnalités utiles peuvent élargir la surface d’attaque de l’IA, et des pouvoirs excessifs peuvent transformer une faiblesse du modèle en incident pour l’entreprise.
Pour les RSSI, la question n’est plus seulement de savoir si un modèle d’IA peut être manipulé, mais ce que le système qui l’entoure lui permettra de faire lorsque la manipulation réussira.
En savoir plus
- Découvrez les derniers classements F5 CASI et F5 ARS sur la sécurité de l’IA pour comparer la résilience des modèles et suivre l’évolution de leur niveau de sécurité au fil du temps.
- Découvrez comment F5 AI Red Team aide les organisations à tester leurs modèles, applications et agents face à des attaques réelles.
- Découvrez la F5 AI Security Platform pour bénéficier d’une visibilité, d’une gouvernance et d’une protection continues sur l’ensemble des applications, modèles et agents d’IA de l’entreprise.
À propos des auteurs

Malcolm Heath est chercheur principal en menaces chez F5 Labs. Au cours de sa carrière, il a travaillé dans la réponse aux incidents, la gestion de programmes, les tests d’intrusion, l’audit de code, la recherche sur les vulnérabilités et le développement d’exploits, au sein d’entreprises de toutes tailles. Avant de rejoindre F5 Labs, il était ingénieur senior en sécurité au sein de la F5 SIRT.
Autres articles de Malcolm Heath
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 ScullyArticles de blog associés

IA et cybersécurité
Découvrez comment l’IA et la cybersécurité fonctionnent de concert. Découvrez comment l’IA et le machine learning (ML) permettent à votre entreprise de rester sécurisée, efficace et prête à innover avec F5.

Suivre le rythme de l’innovation de pointe ne suffit pas à faire avancer l’entreprise : se préparer à la réglementation de l’IA
À mesure que la réglementation de l’IA évolue, réfléchissez aux mesures de protection que vous pouvez mettre en place dès maintenant.

Les contrôleurs de mise à disposition d’applications reviennent au cœur des priorités stratégiques
L’IA rebat les cartes de la livraison d’applications. Nirav Shah de F5 revient sur la nouvelle étude de Gartner® consacrée aux ADC et explique ce qu’elle implique pour les décisions des entreprises en matière d’infrastructure.

Ce que nos clients nous disent sur l’IA, le multicloud hybride et la sécurité des applications
Le nouveau vice-président senior du marketing produit de F5 explique les pressions liées à l’IA auxquelles sont confrontés les dirigeants d’entreprise et ce dont ils ont besoin pour renforcer leur organisation.

Cinq niveaux de cyberrésilience antifragile transforment les pratiques en résultats
Découvrez comment cinq niveaux de résilience antifragile transforment les perturbations en comportements adaptatifs qui limitent les défaillances et renforcent l’architecture multicloud hybride.

Optimiser les pipelines d’IA en éliminant les goulets d’étranglement dans les charges de travail modernes
À mesure que les charges de travail d’IA montent en puissance, les entreprises constatent des ralentissements provenant du pipeline de données en amont qui alimente le modèle d’IA. Voici comment F5 BIG-IP peut les aider.