L’explosion de l’utilisation de l’IA depuis 2020 est sans précédent. En matière d’adoption, l’IA progresse plus rapidement que le cloud, le mobile et, bien sûr, Internet à ses débuts. Gartner prévoit que plus de 80 % des entreprises déploieront l’IA cette année.
Lorsque nous classons les différentes étapes du parcours d’adoption de l’IA d’une entreprise, nous constatons que sa maturité se répartit en quatre catégories, qui évoluent souvent en parallèle plutôt que de manière séquentielle :
- La catégorie 1 concerne l’IA à usage général et la productivité — par exemple, les employés qui utilisent ChatGPT, Gemini, Copilot, etc.
- La catégorie 2 concerne les cas où les organisations ont des usages internes et développent des chatbots personnalisés pour des fonctions telles que les RH ou l’informatique.
- La catégorie 3 comprend des cas d’usage externes, tels que le développement d’applications d’IA générative destinées au grand public, notamment des chatbots de service client.
- La catégorie 4 correspond aux workflows agentiques composés de systèmes complexes qui agissent de manière autonome pour le compte des utilisateurs.
C’est dans ces trois dernières catégories que la sécurité devient cruciale. En effet, les organisations développent des logiciels complexes reposant sur des modèles d’IA non déterministes, ce qui crée des vulnérabilités que les pare-feu traditionnels sont tout simplement incapables de détecter.
“Il est clair que les entreprises qui déploient l’IA ont besoin de tests automatisés rapides ciblant les vulnérabilités connues, ne serait-ce que pour établir une base de référence.”
La sécurité est toujours une priorité pour les entreprises, mais avec l’IA, le problème est différent : il s’agit d’un angle mort. Depuis 20 ans, les responsables de la sécurité déploient et configurent des pare-feu d’applications web (WAF) afin de protéger leurs applications web, leurs sites web et même leurs API. Toutefois, bien qu’extrêmement utiles, les WAF présentent des limites face à l’IA. Le traitement du langage naturel utilisé par l’IA peut poser problème aux systèmes de détection traditionnels des WAF ; en d’autres termes, il est impossible de protéger une conversation avec un pare-feu. Les entreprises ont besoin d’une nouvelle approche pour protéger leurs applications et leurs API, où qu’elles se trouvent, et sécuriser leur IA partout.
C’est pourquoi 75 % des RSSI signalent des incidents de sécurité liés à l’IA : leurs protections actuelles ne sont tout simplement pas conçues pour détecter ces menaces. C’est également la raison pour laquelle 91 % ont déjà détecté des tentatives d’attaque contre leur infrastructure d’IA et pas moins de 94 % font désormais des tests de leurs systèmes d’IA une priorité.
Nouvelles catégories d’attaques cognitives
À l’ère de l’IA, les organisations ne sont plus seulement confrontées aux vulnérabilités du code. Elles font face à de toutes nouvelles catégories d’attaques cognitives, notamment :
- Injection de prompt, directe comme indirecte
- Empoisonnement des données pendant la phase d’entraînement
- Jailbreak sophistiqué : techniques telles que les attaques par langage symbolique
- Compression de jetons, où les attaquants dissimulent des instructions malveillantes dans des formats que les modèles d’IA peuvent lire, mais pas les humains
Les mécanismes de sécurité traditionnels gèrent les entrées déterministes, mais l’injection de prompts et les autres attaques en langage naturel relèvent de problèmes sémantiques, et non de la reconnaissance de motifs. Il ne s’agit pas de failles isolées, mais de risques systémiques pour l’entreprise introduits par les architectures fondées sur l’IA.
De nombreux exemples concrets montrent comment l’IA transforme le modèle de menace. L’été dernier, une faille chez un fournisseur international de logiciels a été causée par une erreur de logique dans l’isolation des locataires au sein du serveur MCP, qui a permis l’exposition de données entre différentes organisations. Il s’agit d’une faille multi-tenant classique, mais elle est plus dangereuse dans les systèmes reposant sur des LLM, car les données divulguées apparaissent sous la forme d’un langage fluide, ce qui les rend beaucoup plus difficiles à détecter.
Parallèlement, un incident survenu au sein d’une entreprise technologique mondiale a mis en évidence une autre défaillance : la rupture des frontières de confiance. Une injection de prompt a redéfini le rôle d’un chatbot, et les systèmes back-end ont accepté ses requêtes d’utilisation d’outils sans appliquer de contrôle d’autorisation côté serveur. Le problème ne venait pas du fait que le modèle ignorait les règles, mais du fait que l’autorisation lui avait été déléguée à tort.
Ce ne sont que deux exemples qui s’inscrivent dans un paysage émergent de risques bien plus vaste. Le secteur s’efforce de catégoriser ces vulnérabilités liées à l’IA. De nouveaux référentiels voient le jour, tels que l’OWASP Top 10 des applications basées sur de grands modèles de langage (LLM), l’OWASP Top 10 des applications agentiques , Mitre Atlas et le cadre de gestion des risques liés à l’IA du NIST, mais nous ne disposons pas encore d’une base de données de référence ni d’une norme unifiée définissant concrètement ce qu’est un système sécurisé.
L’ancienne approche ne peut plus suivre
La pression qui pèse actuellement sur les entreprises pour qu’elles déploient l’IA est une question de survie. Les développeurs utilisent l’IA pour écrire du code 10 fois plus vite qu’auparavant ; les organisations mettent littéralement en production de nouvelles fonctionnalités, voire de nouveaux produits, du jour au lendemain.
Dans le même temps, la réglementation accélère les choses sur le plan de la conformité. Le règlement européen sur l’IA, par exemple, exige explicitement des tests contradictoires pour les systèmes d’IA à haut risque et à usage général. En pratique, cela signifie que les exercices de red teaming spécialement conçus à cet effet—qui consistent à tester les systèmes d’IA au moyen de simulations d’attaques adverses—doivent désormais être considérés comme un composant essentiel de la pile de sécurité de l’IA, selon une approche qui tient compte des défis concrets auxquels ces systèmes sont confrontés.
Alors que les RSSI et les équipes de sécurité tentent de sécuriser des changements qui se produisent à la vitesse des machines, ils peuvent avoir l’impression d’essayer d’arrêter un tsunami avec un seau. Le calcul ne tient pas. Le rythme est intenable. La surface d’attaque de l’IA est fondamentalement différente, et les anciennes approches ne peuvent pas suivre.
Il est clair que le red teaming traditionnel est inefficace et que le red teaming appliqué à l’IA est nécessaire pour résoudre la tension entre rapidité et contrôle. Nos échanges avec les clients et l’aide que nous leur apportons pour sécuriser leurs systèmes d’IA font ressortir quatre domaines clés à prendre en compte :
Premièrement, l’évolution des menaces : les attaques par IA évoluent plus rapidement que les suites de tests statiques. Dès que les contrôles sont automatisés, le modèle d’IA ou l’attaque change, et les équipes de sécurité finissent par assurer la maintenance des tests au lieu de réduire les risques.
Deuxièmement, la complexité des agents: les agents d’IA n’étant pas des systèmes déterministes, dès lors que vous ajoutez la récupération d’informations, des outils et de la mémoire, les combinaisons deviennent presque infinies. Vous ne testez plus du code, mais une conversation qui évolue en fonction du contexte.
Troisièmement, l’automatisation et le passage à l’échelle : les tests d’intrusion manuels ne sont pas adaptés à ces systèmes à grande échelle. Un chatbot peut être gérable, mais pas des centaines ou des milliers. Vous ne pouvez pas compter sur des humains pour rejouer des milliers de conversations adversariales à chaque mise à jour du modèle ou du prompt système.
Enfin, des rapports exploitables : les constats doivent être reproductibles et permettre d’agir. « Le bot s’est mal comporté » n’est pas une information exploitable. Les ingénieurs ont besoin des paramètres de la conversation et des conditions de déclenchement ; sans cela, les correctifs et les mesures de remédiation resteront au point mort.
Garantir que l’IA se comporte comme prévu, même en cas d’attaque
Confrontons cela à la réalité à l’aide de quelques exemples. L’un de nos clients est une banque internationale qui évolue dans un environnement fortement réglementé. Lorsque nous avons commencé à travailler avec ce client, il avait recensé plus de 50 cas d’usage de l’IA dans les ressources humaines, les achats et la cybersécurité, mais ne pouvait en déployer aucun, car la banque n’était pas en mesure d’en démontrer la sûreté à ses auditeurs internes.
Les tests d’intrusion appliqués à l’IA avec F5 AI Red Team ont fourni à la banque les éléments dont elle avait besoin pour comprendre le comportement réel de ses systèmes d’IA : les risques de fuite de données, les possibilités de détournement des invites et les défaillances des contrôles dans son environnement.
Ce client s’appuie sur les conclusions d’AI Red Team pour renforcer sa posture défensive grâce à des contrôles de sécurité personnalisés utilisant F5 AI Guardrails. Cette combinaison permet à la banque de déployer l’IA à grande échelle dans toute l’entreprise, avec une confiance accrue dans sa posture de sécurité et son programme de gouvernance.
Dans le secteur public, les tests ne sont plus facultatifs, mais obligatoires. Sous l’impulsion d’organismes tels que le NIST et la CISA, les organismes du secteur public prennent des mesures, notamment en réalisant des tests de résistance contradictoires afin d’identifier les risques critiques pour leurs missions, comme l’utilisation de données biologiques à des fins malveillantes. Ici, le red teaming appliqué à l’IA ne vise pas seulement à réduire les risques, mais aussi à assurer la continuité des missions et à préserver l’autorisation d’exercer.
Que vous protégiez les données de vos clients ou des services publics, l’exigence reste la même : garantir en permanence, preuves à l’appui, que les systèmes d’IA se comportent comme prévu, même lorsque quelqu’un tente de les mettre en échec.
Combler les lacunes en matière de conformité
Il est clair que les entreprises qui déploient l’IA ont besoin de tests automatisés rapides ciblant les vulnérabilités connues, ne serait-ce que pour établir une base de référence. Le contexte constitue la nouvelle surface d’attaque ; les défenses statiques sont inefficaces face aux attaques agentiques. Les organisations doivent donc tester les charges de travail, et pas seulement les modèles.
Ce sont ces lacunes concrètes que les équipes de sécurité cherchent actuellement à combler et qui expliquent pourquoi le red teaming appliqué à l’IA passe au premier plan. Dans ce contexte, la conformité constitue un avantage concurrentiel. Avec des rapports adaptés, la sécurité cesse d’être un frein et devient un levier permettant aux entreprises de commercialiser plus rapidement leurs solutions d’IA.
Dans ce contexte, les nombreuses entreprises qui prévoient de déployer l’IA cette année peuvent le faire avec confiance plutôt qu’avec crainte, quelle que soit l’étape où elles en sont dans leur parcours.
Découvrez ici comment tester vos systèmes d’IA.
Découvrez comment les experts de F5 montrent qu’AI Red Team accélère les tests adversariaux continus ici.
À propos des auteurs
Articles 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.