Le modèle a passé tous vos tests de sécurité, puis un jailbreak l'a fait dérailler : êtes-vous responsable ?

Il y a une asymétrie fondamentale dans l'évaluation de sécurité des modèles IA : on ne peut pas prouver qu'un modèle est sûr, on peut seulement démontrer qu'il a résisté aux attaques qu'on lui a soumises. Un red teaming, aussi rigoureux soit-il, explore un espace fini d'attaques au sein d'un espace de menaces infini et mouvant. C'est une vérité technique évidente pour l'ingénieur, mais qui se perd dès qu'elle se traduit en une phrase de rapport du type « modèle robuste aux contournements ».

Or les techniques d'attaque sur les grands modèles — injections de prompt, jailbreaks par jeu de rôle, encodage, attaques multilingues, manipulations adversariales — évoluent en permanence. Une attaque inconnue le jour de votre évaluation peut devenir publique et triviale trois semaines plus tard. Le décalage entre la photographie que constitue votre benchmark et la réalité vivante de la menace est précisément le terrain des litiges.

La question juridique n'est donc pas « le modèle a-t-il été contourné ? » — il le sera tôt ou tard — mais « votre évaluation était-elle conforme à ce qu'un professionnel diligent devait faire à cette date, et avez-vous correctement décrit ce que vous garantissiez ? »

Comme la plupart des prestataires intellectuels, l'ingénieur évaluation est en principe tenu d'une obligation de moyens : mettre en œuvre des tests de sécurité conformes à l'état de l'art, pas garantir l'invulnérabilité. Mais deux dérives transforment cette obligation de moyens en quasi-obligation de résultat, bien plus dangereuse :

• Le vocabulaire absolu. Écrire « le modèle est sécurisé », « aucun jailbreak ne fonctionne », « conforme aux exigences de sûreté » sans qualifier ces affirmations, c'est créer une attente d'invulnérabilité. En cas de contournement, le client opposera votre propre formulation.
• Le périmètre flou. Ne pas préciser quelles familles d'attaques ont été testées, sur quelle version du modèle, à quelle date, laisse penser que l'évaluation couvrait tout. Le silence sur le périmètre se retourne contre l'évaluateur.

La frontière entre l'aléa couvert et la faute reprochable tient souvent à une phrase. « Robuste aux jailbreaks » est un piège ; « a résisté aux 14 familles d'attaques testées le 12 mars, hors techniques émergentes postérieures » est une protection.

Plus votre rapport est précis sur ce que vous avez fait et ce que vous n'avez pas couvert, plus vous restez dans le champ de l'obligation de moyens — celui où un contournement ultérieur ne vous est pas imputable.

Lorsqu'un modèle que vous avez évalué est contourné en production — un assistant qui révèle des données sensibles, génère un contenu prohibé ou exécute une action non autorisée — plusieurs reproches peuvent vous être adressés :

• Le red teaming statique. Avoir utilisé une batterie d'attaques figée, sans intégrer les techniques connues et documentées à la date de la mission. Tester « comme l'an dernier » est un manquement si le paysage a évolué.
• L'absence de test sur le système complet. Évaluer le modèle isolément alors qu'en production il est connecté à des outils, une base documentaire ou des actions : la surface d'attaque réelle (injection indirecte via un document, par exemple) n'a pas été couverte.
• Le défaut de conseil. Ne pas avoir alerté le client que la sécurité d'un modèle exige une évaluation continue et un monitoring, en laissant croire qu'un audit ponctuel suffisait.
• La confusion des rôles. Laisser penser que vous validiez aussi l'intégration et l'exploitation, alors que votre mission portait sur le modèle seul.

Chacun de ces points se neutralise par la documentation : la liste datée des attaques testées, le périmètre exact, les hypothèses, et les recommandations de suivi. C'est ce dossier qui, en cas de contentieux, démontre que vous avez agi en professionnel diligent.

Le paradoxe de l'évaluation de sécurité IA est qu'elle a une date de péremption invisible. Votre rapport est juste le jour où vous le rendez, et potentiellement obsolète peu après, sans qu'aucune ligne de votre travail n'ait changé. Cette obsolescence par l'extérieur — c'est le monde des attaques qui bouge, pas votre livrable — crée une zone grise où un client mécontent cherchera à faire remonter dans le temps une exigence qui n'existait pas le jour de la mission.

D'où deux réflexes essentiels. Sur le plan technique, recommander par écrit une cadence de réévaluation et un monitoring de production : vous reportez ainsi sur le client la responsabilité du suivi que vous l'avez explicitement invité à mettre en place. Sur le plan assurantiel, disposer d'une RC Pro qui couvre les réclamations même tardives : un contournement peut être découvert et reproché des mois après votre intervention.

Cette protection ne récompense pas la négligence — un évaluateur bâclé reste exposé. Elle protège le professionnel sérieux contre l'inévitable décalage temporel entre son audit et l'évolution des menaces, qui fait de ce métier l'un des plus difficiles à « garantir ».

Vous passez vos journées à chercher les angles morts d'un système. Le pire angle mort serait celui de votre propre exposition. Un ingénieur en évaluation de sécurité fait des affirmations à fort enjeu sur des systèmes dont l'usage en production échappe à son contrôle : c'est la définition même d'un risque professionnel qu'on assure plutôt qu'on subit.

La RC Professionnelle couvre les réclamations liées à vos prestations d'évaluation et de conseil, et finance votre défense — y compris l'expertise technique nécessaire pour démontrer, face à un juge ou un client, que votre red teaming était conforme à l'état de l'art au moment où vous l'avez conduit. C'est cette prise en charge de la défense qui compte le plus dans un métier où la mise en cause est souvent une affaire d'interprétation.

Pour ajuster vos garanties à la criticité des modèles que vous auditez — assistant client grand public, système décisionnel, agent connecté à des outils sensibles — consultez notre page assurance ingénieur en fiabilité et évaluation des modèles IA, et soignez la formulation écrite de chacun de vos rapports : c'est là que se gagne ou se perd un litige.