Sécuriser et prouver son IA : la chaîne qui relie le test à la preuve réglementaire

Un test de sécurité qui ne débouche sur aucune preuve opposable ne vous protège pas devant un régulateur, et un dossier de conformité qui n'a jamais été confronté à une attaque ne protège pas vos utilisateurs. La bonne approche relie les deux dans une seule chaîne : on descend jusqu'au modèle en l'attaquant, puis on remonte en produisant la preuve. C'est exactement le fil rouge qui distingue un traducteur de risques d'un avocat comme d'une ESN. Dans cet article, je vous montre comment un même effort couvre à la fois votre sécurité technique et votre conformité, sans les traiter comme deux chantiers séparés.

Le problème : deux angles morts qui se répondent

La plupart des organisations tombent dans l'un de deux pièges. Le premier est la conformité sur le papier : un dossier épais, des politiques bien rédigées, mais aucune preuve que le système résiste réellement à une attaque. Le second est le test sans lendemain: un audit technique révèle des failles, on les corrige, mais rien de tout cela ne se transforme en artefact exploitable le jour d'un contrôle. Dans les deux cas, l'effort est réel et le résultat reste fragile.

Le scénario que je vois revenir : une équipe sécurité mène un excellent test offensif, produit un rapport technique, puis ce rapport dort dans un dossier pendant que le service conformité remplit, de son côté, des formulaires qui ne s'appuient sur aucune mesure. Les deux mondes ne se parlent pas, et l'entreprise paie deux fois pour une protection qui reste incomplète.

La méthode : une seule chaîne, deux mouvements

L'idée est de considérer votre système d'IA comme un unique objet que l'on parcourt dans les deux sens. On descenden partant de l'attaquant pour aller jusqu'au modèle, ce qui répond à la question « est-ce que ça tient ? ». Puis on remontedepuis ce même modèle vers la preuve auditable, ce qui répond à la question « comment le prouver ? ». Le point bas est commun : c'est le modèle lui-même, mis à l'épreuve puis documenté.

Chaque maillon alimente le suivant. Le test offensif fournit les mesures ; les mesures alimentent les contrôles ; les contrôles nourrissent la preuve. Rien n'est produit en double, et chaque artefact sert autant la sécurité que la conformité.

Descendre : attaquer le modèle pour savoir s'il tient

La descente part de la posture de l'attaquant. On construit des scénarios d'attaque réalistes plutôt que de cocher des cases. Le référentiel de départ est l'OWASP LLM Top 10, qui nomme les risques propres aux modèles de langage : injection de prompt, fuite d'information sensible, sorties non filtrées, agentivité excessive. Pour aller plus loin dans la sophistication des scénarios, on s'appuie sur la taxonomie MITRE ATLAS, et pour le socle d'hygiène technique, sur les recommandations de l'ANSSI (isolation des phases, maîtrise des dépendances, audit avant mise en production).

Si ce vocabulaire des risques ne vous est pas familier, commencez par le panorama que je détaille dans OWASP LLM Top 10, puis par la façon d'auditer concrètement une application dans l'audit de sécurité d'une application IA. La descente s'arrête au modèle : c'est lui, et non seulement l'interface, que l'on cherche à faire céder.

Le point bas : le modèle et ses mesures

Au fond de la chaîne se trouve le modèle, et surtout ce que le test en révèle. Ce n'est pas une impression, c'est un jeu de mesures: quels scénarios ont réussi, avec quelle probabilité, quel impact, quels contrôles ont tenu. Ces mesures sont le matériau brut de tout ce qui va suivre. Un test qui produit un simple « c'est risqué » ne permet pas de remonter ; un test qui produit « tel scénario réussit dans telles conditions, voici la preuve » alimente directement la partie conformité.

C'est ici que se joue la différence entre un rapport qui impressionne et un rapport qui sert. Le bon livrable relie chaque faille à un contrôle vérifiable, et chaque contrôle à une exigence réglementaire. Sans cette traçabilité, la remontée est impossible.

Remonter : transformer les mesures en preuve auditable

La remontée est le mouvement que la plupart des équipes techniques négligent, et celui que la plupart des équipes conformité bâclent faute de matière. Elle consiste à convertir les mesures du test en artefacts que l'on peut présenter à un tiers. Le cadre de structuration le plus opérationnel est le NIST AI RMF, avec ses quatre fonctions (gouverner, cartographier, mesurer, gérer) : il organise vos mesures de test en un système de contrôle continu, plutôt qu'en un instantané.

À partir de là, les mêmes contrôles se déclinent en preuves attendues par chaque régime. La documentation technique de l'AI Act (son Annexe IV) décrit le système, ses risques et ses garde-fous. L'analyse d'impact du RGPD documente le traitement des données personnelles. Le système de management ISO 42001 organise le tout en démarche d'amélioration continue. Et pour un acteur financier, ces mêmes artefacts nourrissent la résilience opérationnelle exigée par DORA. Une seule chaîne, plusieurs régimes servis.

Cette remontée est précisément ce que structure une feuille de route de mise en conformité, où chaque étape produit un artefact réutilisable plutôt qu'un document jetable.

La chaîne complète, maillon par maillon

Voici comment chaque artefact répond à une question précise, et à quel régime il sert. C'est la lecture qui évite de produire deux fois la même chose sous deux noms différents.

Questions fréquentes

Faut-il être expert technique pour piloter cette chaîne ?

Non. Le rôle du dirigeant, du DPO ou du RSSI est de s'assurer que les deux mouvements existent et se rejoignent. Le travail technique peut être délégué, mais personne ne doit accepter un test sans preuve ni une preuve sans test. C'est ce lien qui fait la valeur.

Un audit de conformité classique ne suffit-il pas ?

Il documente vos intentions, pas votre robustesse. Un régulateur outillé sait faire la différence entre une politique bien rédigée et un système qui a réellement été mis à l'épreuve. La chaîne comble précisément cet écart en ancrant chaque affirmation de conformité dans une mesure de test.

Pourquoi parler de sécurité et de conformité ensemble ?

Parce que ce sont deux vues du même objet. La sécurité pose la question « est-ce que ça tient ? », la conformité pose la question « pouvez-vous le prouver ? ». Les traiter séparément revient à payer deux fois pour une protection qui reste, au bout du compte, à moitié faite.

Par où commencer si je n'ai encore rien mené ?

Par la descente : un premier test offensif ciblé sur votre usage d'IA le plus exposé. Il vous donne des mesures concrètes, qui deviennent immédiatement la matière de votre première preuve. C'est l'objet même de mon audit Sécurité & Conformité IA.

C'est tout le sens de mon positionnement « ni avocat, ni ESN » : je relie le test à la preuve dans une seule chaîne d'artefacts. Si vous voulez situer où vous en êtes, un premier échange suffit à identifier votre maillon le plus faible.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.