Évaluation de la sécurité et durcissement

Notre approche consiste à compromettre les systèmes d'IA de la même manière que de véritables assaillants, puis à les durcir contre les chemins d'attaque révélés par l'évaluation — de l'extraction de modèle à la compromission de la supply chain. Les tests d'intrusion traditionnels couvrent vos API, votre infrastructure et vos flux d'authentification, mais ils ne testent jamais si un attaquant peut dérober votre modèle affiné, introduire une porte dérobée dans votre chaîne de dépendances ou détourner votre pipeline RAG. Cette méthodologie d'évaluation doit être conçue spécifiquement pour les modes de défaillance propres aux systèmes d'IA.

Surfaces d'attaque que votre équipe de sécurité n'a jamais testées

Les tests d'intrusion traditionnels couvrent vos API, votre infrastructure et vos flux d'authentification. Ils ne testent pas si un attaquant peut extraire votre modèle affiné au moyen de 50,000 requêtes soigneusement structurées. Ils ne détectent pas si un adaptateur LoRA empoisonné dans votre chaîne de dépendances HuggingFace a introduit une porte dérobée il y a trois mois. Ils n'évaluent pas si votre pipeline RAG exécutera des instructions intégrées dans un document récupéré. Ce sont là les chemins d'attaque qui compromettent réellement les systèmes d'IA en production.

Il ne s'agit pas de risques théoriques évoqués lors de conférences. Protect AI a identifié 352,000 fichiers suspects sur 51,700 modèles sur HuggingFace en avril 2025. Les attaques assistées par l'IA ont augmenté de 89% d'une année sur l'autre, et 97% des organisations compromises manquaient de contrôles d'accès élémentaires sur leurs systèmes d'IA. L' attaque de la supply chain Mercor au début de 2026 a compromis des milliers d'entreprises par le biais d'une unique dépendance open source.

Ce que nous testons réellement — et ce que la plupart des évaluations manquent

Nous structurons nos évaluations autour du référentiel MITRE ATLAS , qui répertorie désormais 84 techniques réparties sur 16 tactiques ciblant spécifiquement les systèmes d'IA. Mais un référentiel est une carte, pas un test. Notre méthodologie est conçue pour exécuter les attaques qu'il répertorie, et non pour simplement cocher des cases.

Déploiements de LLM et injection de prompts

Nous testons l'injection indirecte de prompts via chaque voie d'ingestion : récupération RAG, sorties d'outils, documents téléversés par les utilisateurs et contenus d'e-mails transmis aux agents. L'injection directe fait les gros titres, mais Anthropic a totalement abandonné sa métrique d'injection directe en février 2026 car c'est l'injection indirecte via le contexte de récupération qui compromet réellement les systèmes en production. Nous testons également la manipulation multi-tours, l'extraction de prompt système et les modes de défaillance spécifiques de la pile de garde-fous que vous avez mise en place.

Sécurité au niveau du modèle

Nous évaluons le risque d'extraction en exécutant des campagnes de requêtes structurées contre votre API et en mesurant la part de comportement du modèle qu'un assaillant peut reproduire. Nous évaluons la robustesse contradictoire aussi bien par des méthodes basées sur les gradients (lorsque nous avons accès au modèle) que par des attaques en boîte noire basées sur le transfert (la manière dont opèrent les assaillants réels). Nous auditons votre pipeline d'entraînement pour détecter les vulnérabilités d'empoisonnement de données, en vérifiant tant vos données d'entraînement directes que les dépendances en amont qui les alimentent (détaillé dans nos recherches sur la protection des entreprises contre l'empoisonnement des modèles).

Intégrité de la supply chain

Nous traçons chaque artefact de modèle jusqu'à sa source : poids pré-entraînés, jeux de données de fine-tuning, couches d'adaptation et versions des frameworks de service. Nous recherchons les vulnérabilités connues dans votre infrastructure ML — PyTorch, vLLM et Triton Inference Server ont tous fait l'objet de CVE en 2025–2026 — et vérifions que la sérialisation de vos modèles utilise des formats sûrs. Les $12 milliards de pertes dues à des modèles ML compromis en 2025 provenaient en écrasante majorité d'attaques sur la supply chain, et non d'une exploitation directe des modèles (voir nos recherches sur la sécurisation du cycle de vie de la supply chain ML).

Systèmes agentiques

Nous testons la surface d'attaque définie par l' Agentic AI Top 10 de l'OWASP : détournement d'objectifs, usage abusif d'outils, usurpation d'identité, empoisonnement de mémoire et défaillances en cascade à travers les workflows multi-agents. La crise OpenClaw en 2026 — au cours de laquelle plus de 21,000 instances d'un agent d'IA comptant 135,000 étoiles ont été exposées à des vulnérabilités critiques — a montré ce qui se produit lorsque des agents sont déployés sans ces tests (détaillé dans nos recherches sur la sécurisation de la frontière humain-IA).

Un durcissement qui transforme le fonctionnement de votre système

Une évaluation sans remédiation n'est qu'un PDF coûteux. Notre approche intègre directement les contrôles de durcissement au sein de votre système.

• Défense au niveau de la couche d'inférence : détection des anomalies de requêtes qui identifie le trafic correspondant à des schémas d'extraction — couverture systématique des entrées, sondage des frontières décisionnelles et balayages programmatiques par paraphrase — et le distingue d'un usage légitime. Les pipelines de validation des entrées sont calibrés selon votre modèle de menace spécifique, et non réduits à des filtres regex génériques qui laissent passer les attaques sémantiques tout en bloquant les requêtes légitimes.
• Durcissement de la supply chain : pipelines de vérification des modèles qui contrôlent la provenance des artefacts, valident les formats de sérialisation, détectent les motifs malveillants connus et imposent la signature obligatoire avant que tout artefact de modèle n'intègre votre pipeline de déploiement — complétés par une surveillance des dépendances qui intercepte les paquets compromis en amont avant qu'ils n'atteignent la production.
• Durcissement des systèmes agentiques : cloisonnement des privilèges d'accès aux outils, validation des sorties entre les étapes de l'agent et surveillance comportementale détectant toute divergence entre le schéma d'exécution d'un agent et son workflow prévu.

Votre SIEM a été conçu pour détecter des anomalies de comportement humain. Un agent qui exécute 10,000 requêtes en séquence paraît normal à ces systèmes, même lorsqu'il agit sous le contrôle d'un attaquant.

Quand vous n'en avez pas besoin

Si vous faites appel à une API managée (OpenAI, Anthropic, Google) sans fine-tuning, sans RAG, sans utilisation d'outils et sans données sensibles dans les prompts, votre risque de sécurité se résume à la gestion des clés d'API et au traitement des données. Un examen standard de sécurité applicative suffit à couvrir cela — vous n'avez pas besoin d'une évaluation spécifique à l'IA.

Si votre modèle est un simple classifieur exécuté en interne, sans API exposée vers l'extérieur et sans pipeline de réentraînement, votre surface d'attaque est limitée et une brève revue du modèle de menace est proportionnée. Effectuer des tests complets de robustesse contradictoire sur un classifieur de sentiment interne situé derrière un pare-feu revient à dépenser $30,000 pour protéger un risque de $500.

Nous le disons sans détour car la crédibilité compte davantage que le chiffre d'affaires. Les organisations qui ont besoin de ces travaux le savent pertinemment : toute structure exploitant des modèles affinés, des pipelines RAG traitant du contenu externe, des systèmes agentiques dotés d'accès à des outils, des modèles dans des secteurs régulés ou des systèmes d'IA prenant des décisions ayant un impact financier ou sécuritaire.

La pression réglementaire est réelle et comporte des échéances précises

L'application de l'EU AI Act débute en août 2026. Les systèmes d'IA à haut risque exigent une gestion documentée des risques, des tests de robustesse technique et des contrôles de gouvernance des données. La non-conformité expose à des amendes pouvant atteindre 7% du chiffre d'affaires annuel mondial ou EUR 35 millions. Le NIST a publié son profil du Cybersecurity Framework pour l'IA en décembre 2025, associant les risques spécifiques à l'IA aux contrôles du CSF 2.0. Ces cadres apparaissent désormais dans les exigences d'appels d'offres et les revues de risques au niveau des conseils d'administration.

La difficulté réside dans le fait qu'aucun référentiel ne couvre l'intégralité du périmètre à lui seul. Nous mettons en correspondance les résultats de votre évaluation avec les cadres requis par vos régulateurs, auditeurs et clients — produisant ainsi des preuves qui satisfont aux exigences de conformité parce qu'elles sont issues de tests réels, et non d'un simple exercice consistant à cocher des cases.

Outils de plateforme vs évaluation sur mesure

Les plateformes automatisées de sécurité de l'IA (HiddenLayer, Mindgard, Giskard) exécutent des schémas d'attaque connus à grande échelle. Elles s'avèrent utiles pour les tests de régression continus après une évaluation initiale, mais ne sauraient remplacer l'évaluation initiale elle-même. Un scanner ne comprend pas votre logique métier, ne sait pas quelles sorties de modèle entraînent des conséquences critiques pour la sécurité et ne peut pas évaluer si votre modèle de menace correspond à votre architecture de déploiement réelle.

Nous utilisons ces outils là où ils apportent une réelle valeur ajoutée. Le red teaming automatisé et continu a toute sa place dans votre pipeline CI/CD une fois que nous avons défini ce qu'il convient de tester. En revanche, les chemins d'attaque les plus déterminants pour votre système spécifique exigent, pour être découverts, un regard expert maîtrisant à la fois les modes de défaillance de l'IA et votre contexte opérationnel.

Pour les organisations exploitant plusieurs fournisseurs d'IA (OpenAI, Anthropic, Google, modèles open source), nous évaluons les frontières de sécurité de chaque fournisseur de manière indépendante et testons les points d'intégration où transitent les données entre eux. La surface d'attaque d'une pile multi-fournisseurs n'est pas la simple somme des risques de chaque fournisseur — c'est la couche d'interaction, là où les postulats sur les garanties de sécurité d'un fournisseur s'effondrent lors du transfert vers un autre.