Tenter de contourner les garde-fous d’un modèle d’IA générative pour lui faire produire du contenu interdit : c’est ce qu’on appelle un jailbreak. La pratique explose. Des études académiques récentes montrent des taux de réussite de 80 à 100 % sur certains modèles de pointe, y compris des systèmes déployés par les plus grands laboratoires. Le modèle DeepSeek R1 a par exemple échoué à l’intégralité des 50 tests de jailbreak menés par Cisco et l’université de Pennsylvanie.
Mais cette activité est-elle légale ? La réponse dépend entièrement du cadre dans lequel elle s’exerce. Entre le red teaming encadré par contrat, le programme de bug bounty officiel, la recherche académique indépendante et le bricolage sauvage sur une API publique, le droit trace des frontières nettes — et d’autres, beaucoup plus floues. En France, le cadre juridique combine la loi Godfrain de 1988 (articles 323-1 à 323-8 du Code pénal), la loi pour une République numérique de 2016, le règlement sur l’IA (AI Act) et bientôt la transposition de la directive NIS 2.
Cet article décortique le paysage juridique complet, en France et en Europe, pour les professionnels qui veulent tester la sécurité d’un système d’IA sans se retrouver au tribunal.
1. Jailbreak, red teaming, pentest IA : de quoi parle-t-on exactement ?
Les termes se mélangent souvent. Clarifions.
Le jailbreak désigne toute technique visant à contourner les restrictions de sécurité (guardrails) d’un modèle d’IA pour lui faire produire du contenu normalement interdit. Cela inclut les attaques par injection de prompt (prompt injection), le roleplay adversarial, les encodages en base64, les pièges logiques et les dialogues multi-tours progressifs. Selon une étude systématique de plus de 1 400 prompts adversariaux, les techniques de roleplay atteignent un taux de réussite de 89,6 %, les pièges logiques 81,4 % et les encodages 76,2 %.
Le red teaming IA est une démarche structurée et encadrée de test adversarial. Historiquement issu de la cybersécurité militaire (les équipes « rouges » de la Guerre froide simulaient des attaques soviétiques), le concept s’est étendu à l’IA pour désigner l’évaluation systématique des vulnérabilités d’un modèle avant son déploiement. L’Executive Order américain le définit comme un « effort de test structuré visant à trouver les failles et vulnérabilités d’un système d’IA, souvent dans un environnement contrôlé et en collaboration avec les développeurs ».
Le test d’intrusion IA (pentest) va au-delà du modèle seul : il teste l’ensemble de la pile applicative — API, bases de données vectorielles, guardrails, infrastructure — dans des conditions proches de la production.
| Activité | Cible | Cadre habituel | Risque juridique |
|---|---|---|---|
| Jailbreak sauvage | Modèle via interface publique | Aucun contrat | Élevé |
| Red teaming contractuel | Modèle en environnement contrôlé | Contrat de mission | Faible |
| Bug bounty officiel | Modèle + système de sécurité | Programme encadré | Nul (si respect des règles) |
| Pentest IA complet | Pile applicative complète | Contrat d'audit | Faible |
| Recherche académique | Modèle open source / API | Variable | Moyen |
2. Le droit pénal français : la loi Godfrain et les systèmes d’IA
Le socle du droit français en matière de cybersécurité reste la loi Godfrain du 5 janvier 1988, codifiée aux articles 323-1 à 323-8 du Code pénal. Ces dispositions ont été régulièrement mises à jour, notamment par la loi du 24 janvier 2023 (LOPMI).
L’article 323-1 punit l’accès ou le maintien frauduleux dans un système de traitement automatisé de données (STAD) de 3 ans d’emprisonnement et 100 000 € d’amende. Si l’accès entraîne une modification de données ou une altération du fonctionnement, les peines montent à 5 ans et 150 000 €. Pour les systèmes de l’État traitant des données personnelles : 7 ans et 300 000 €.
L’article 323-2 vise l’entrave ou le faussement du fonctionnement d’un STAD : 5 ans et 150 000 €.
L’article 323-3 réprime l’introduction, l’extraction ou la modification frauduleuse de données : 5 ans et 150 000 €.
Un modèle d'IA accessible via une API ou une interface web est bien un STAD au sens du Code pénal. Envoyer des prompts adversariaux à un système d'IA sans autorisation peut donc théoriquement tomber sous le coup de ces articles. La question centrale est celle de l'élément intentionnel : le caractère frauduleux de l'accès.
L’article 323-3-1 est particulièrement pertinent : il sanctionne la détention et la diffusion d’outils de hacking « sans motif légitime, notamment de recherche ou de sécurité informatique ». Cette exception pour la recherche et la sécurité informatique est la porte d’entrée légale du red teaming — mais elle n’est pas un blanc-seing.
La Cour de cassation a précisé dans un arrêt du 2 septembre 2025 que le maintien frauduleux est caractérisé dès que l'usage d'un accès dépasse la finalité autorisée, même quand l'accès technique est légitime. Le droit technique ne suffit pas ; seul le droit juridique compte.
3. Les hackers éthiques et la loi Lemaire : une protection limitée
La loi du 7 octobre 2016 pour une République numérique (dite loi Lemaire) a créé l’article L. 2321-4 du Code de la défense, qui offre une protection aux white hats signalant des vulnérabilités à l’ANSSI.
Le mécanisme fonctionne ainsi : un chercheur qui découvre une faille et la signale exclusivement à l’ANSSI (via le CERT-FR) bénéficie d’une présomption de bonne foi. L’ANSSI n’est alors pas tenue de transmettre le dossier aux autorités judiciaires en application de l’article 40 du Code de procédure pénale.
Mais cette protection a des limites sérieuses :
Elle ne constitue pas une immunité pénale. Comme le souligne Amélie Köcke dans Actu-Juridique, « en France, il n’y a aucun mécanisme juridique non-contractuel mis en place pour garantir au hacker éthique qu’il ne sera pas sanctionné ». La bonne foi est appréciée au cas par cas par l’ANSSI.
Le signalement doit être exclusif : toute divulgation publique avant ou en parallèle du signalement à l’ANSSI fait tomber la protection. Les conditions sont précisées dans le cadre du dispositif de signalement du CERT-FR.
Le dispositif a été conçu pour la cybersécurité classique (failles dans des réseaux, logiciels, serveurs). Son application au jailbreak d’IA n’a jamais été testée devant les tribunaux et reste juridiquement incertaine.
Certains prévenus se revendiquent hackers éthiques en défense pénale pour échapper aux poursuites. Les magistrats spécialisés de la section J3 du parquet de Paris connaissent cette stratégie et examinent la bonne foi avec une grande rigueur.
4. L’AI Act et l’obligation de red teaming : quand « hacker » l’IA devient une exigence légale
Le règlement européen sur l’IA (règlement (UE) 2024/1689) renverse la perspective : pour certains modèles, le test adversarial n’est plus seulement toléré — il est obligatoire.
L’article 55 de l’AI Act impose aux fournisseurs de modèles GPAI (General-Purpose AI) à risque systémique de :
- Réaliser des évaluations du modèle selon des protocoles standardisés, « y compris la conduite et la documentation de tests adversariaux du modèle en vue d’identifier et d’atténuer les risques systémiques »
- Évaluer et atténuer les risques systémiques au niveau de l’Union
- Signaler les incidents graves au Bureau de l’IA (AI Office)
- Garantir un niveau adéquat de cybersécurité
Un modèle GPAI est classé à risque systémique lorsqu’il dépasse le seuil de 10²⁵ FLOP de calcul à l’entraînement ou lorsque la Commission le désigne sur la base de critères qualitatifs (article 51).
| Calendrier AI Act — Obligations GPAI | Date |
|---|---|
| Entrée en vigueur du règlement | 1er août 2024 |
| Définitions et interdictions applicables | 2 février 2025 |
| Obligations GPAI (articles 53, 55) applicables | 2 août 2025 |
| Début des actions d'exécution par l'AI Office | 2 août 2026 |
| Conformité des modèles déjà sur le marché | 2 août 2027 |
| Application complète de l'AI Act | 2 août 2027 |
Le Code de pratique GPAI, publié dans sa version finale le 10 juillet 2025, détaille ces obligations. Les signataires doivent mener des évaluations utilisant « des techniques adversariales de pointe » conduites par des équipes pluridisciplinaires disposant d’au moins 3 ans d’expérience et d’un accès suffisant au modèle (y compris les composants internes comme les logits et activations).
Si votre entreprise développe ou adapte un modèle GPAI distribué dans l'UE, le red teaming n'est pas une option — c'est une obligation réglementaire. Les amendes pour non-conformité atteignent 15 millions d'euros ou 3 % du chiffre d'affaires mondial (article 101).
5. Les programmes de bug bounty IA : le cadre le plus sûr
Les grands laboratoires d’IA ont tous mis en place des programmes de bug bounty spécifiquement dédiés au jailbreak et à la sécurité des modèles. C’est le cadre juridique le plus protecteur pour le chercheur.
Anthropic a lancé en partenariat avec HackerOne un programme de bug bounty sur la sécurité des modèles offrant jusqu’à 25 000 $ pour des jailbreaks universels vérifiés. Le programme se concentre sur les contournements des Constitutional Classifiers, le système de protection contre les contenus CBRN (chimique, biologique, radiologique, nucléaire). Le programme a été étendu en 2025 aux tests sur Claude Opus 4.
OpenAI opère un programme de bug bounty via HackerOne et a lancé des initiatives spécifiques comme le GPT-5 Bio Bug Bounty en août 2025, ciblant les jailbreaks universels sur les questions de biosécurité. L’accès est sur invitation, couvert par un NDA.
Google DeepMind et Meta conduisent également des exercices de red teaming internes et externes. Meta a employé des équipes internes pour tester la sécurité de LLaMA, notamment sur l’injection de prompt et la sécurité des mineurs.
| Programme | Récompense max | Cible | Accès |
|---|---|---|---|
| Anthropic (HackerOne) | 25 000 $ | Jailbreaks universels CBRN | Sur invitation |
| OpenAI Bug Bounty | 20 000 $ | Vulnérabilités système + modèle | Ouvert + invitation |
| OpenAI Bio Bug Bounty | Non publié | Jailbreaks biosécurité GPT-5 | Sur invitation + NDA |
Dans le cadre d'un programme de bug bounty, le chercheur est couvert par les conditions contractuelles du programme. C'est la voie la plus sûre pour un chercheur indépendant basé en France.
6. Le contrat de red teaming : les clauses indispensables
En dehors des programmes de bug bounty, le red teaming IA s’exerce le plus souvent dans un cadre contractuel entre le fournisseur du modèle (ou le déployeur) et l’équipe de test. Ce contrat est la première ligne de défense juridique du red teamer.
Les clauses essentielles à inclure :
1. Périmètre précis de la mission : quels systèmes sont testés, quels types d’attaques sont autorisés, quelles sont les limites (pas d’accès aux données de production, pas d’exfiltration de données utilisateurs, etc.).
2. Autorisation explicite d’accès : cette clause neutralise l’élément de fraude des articles 323-1 à 323-3. Sans elle, même un test « amical » reste potentiellement un accès frauduleux.
3. Clause de confidentialité (NDA) : les résultats du red teaming ne doivent pas être divulgués publiquement, surtout si des vulnérabilités critiques sont identifiées.
4. Limitation de responsabilité : le prestataire ne peut être tenu responsable des conséquences des vulnérabilités découvertes, ni des dommages causés dans le cadre normal de la mission.
5. Conformité réglementaire : si le modèle testé relève de l’AI Act, le contrat doit prévoir que le red teaming contribue à la conformité article 55 et que la documentation sera conservée.
Comme le souligne le cabinet CMS dans son analyse, l'externalisation du red teaming ne décharge pas le fournisseur de sa responsabilité. En cas de dommage causé par un modèle malgré le red teaming, la question de la responsabilité produit se posera au regard de la directive révisée sur la responsabilité des produits.
7. NIS 2 et la cybersécurité des systèmes d’IA : le cadre à venir
La directive NIS 2 (directive (UE) 2022/2555) ajoute une couche réglementaire supplémentaire. En France, sa transposition est en cours via le projet de loi « Résilience », adopté par le Sénat en mars 2025 et en cours d’examen à l’Assemblée nationale. L’ANSSI sera l’autorité de supervision.
NIS 2 impose aux entités essentielles et importantes des mesures de cybersécurité incluant explicitement les tests d’intrusion réguliers et les exercices de simulation de crise. Les entreprises qui déploient des systèmes d’IA dans des secteurs critiques (santé, énergie, transports, finance) seront directement concernées.
Les sanctions sont lourdes : jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles. Les dirigeants sont personnellement responsables de la conformité.
| Cadre réglementaire | Obligation de test | Sanctions max | Autorité (France) |
|---|---|---|---|
| AI Act (art. 55) | Red teaming obligatoire (GPAI à risque systémique) | 15 M€ ou 3 % CA | AI Office (Commission) |
| NIS 2 | Tests d'intrusion + simulation de crise | 10 M€ ou 2 % CA | ANSSI |
| RGPD | DPIA incluant tests de sécurité | 20 M€ ou 4 % CA | CNIL |
| Directive responsabilité produits | Tests de sécurité pré-commercialisation | Responsabilité civile | Juridictions nationales |
Pour une entreprise française qui déploie un système d'IA dans un secteur critique, la convergence AI Act + NIS 2 + RGPD crée un impératif juridique de tester la sécurité du système, y compris par des méthodes adversariales.
8. Les zones grises : recherche indépendante, jailbreak « récréatif » et divulgation
C’est le territoire le plus risqué. Plusieurs scénarios restent juridiquement incertains en France.
Le chercheur indépendant qui teste un modèle accessible via API publique, sans contrat ni programme de bug bounty, se trouve dans un flou juridique. L’article 323-3-1 du Code pénal prévoit bien une exception pour la « recherche ou sécurité informatique », mais les tribunaux n’ont jamais précisé son application au jailbreak d’IA. Le chercheur devra démontrer sa bonne foi, l’absence d’intention malveillante et le caractère scientifique de sa démarche.
Le jailbreak « récréatif » — tenter de faire dire n’importe quoi à ChatGPT par curiosité — est probablement le cas le plus fréquent et le moins risqué en pratique. Les fournisseurs de modèles n’engagent généralement pas de poursuites contre les utilisateurs individuels. Mais en théorie, cette activité viole les conditions d’utilisation du service et pourrait, dans un cas extrême, donner lieu à une résiliation de compte ou à des poursuites civiles.
La divulgation publique de jailbreaks sans signalement préalable au fournisseur ou à l’ANSSI pose un problème plus sérieux. Publier un prompt de jailbreak universel sur un forum peut être qualifié de mise à disposition d’outils de hacking au sens de l’article 323-3-1.
Anthropic a annoncé qu'il accepte les signalements de jailbreaks universels découverts sur des plateformes publiques (réseaux sociaux, forums). C'est une incitation à la divulgation responsable, mais pas une protection juridique en droit français.
9. Le red teaming vu de l’intérieur : ce que les fournisseurs exigent
Le Code de pratique GPAI fixe des standards élevés pour les évaluateurs externes :
Les équipes de red teaming doivent être pluridisciplinaires, combinant expertise technique en ML, sécurité informatique et expertise de domaine liée au risque systémique évalué. Les évaluateurs doivent justifier d’au moins 3 ans d’expérience pertinente.
Ils doivent disposer d’un accès suffisant au modèle, incluant les composants internes (logits, activations) et les versions non atténuées du modèle. Le temps alloué doit être d’au moins 20 jours ouvrables pour la plupart des tâches.
Les fournisseurs doivent également nommer des évaluateurs indépendants qualifiés, sauf si le modèle est déjà considéré comme « aussi sûr ou plus sûr » que ses pairs.
Le rapport de sécurité (Safety and Security Model Report) doit être déposé auprès de l’AI Office avant la mise sur le marché et tenu à jour. Les incidents graves doivent être signalés dans un délai de 2 à 15 jours selon leur gravité.
Le Code de pratique est volontaire, mais les signataires qui l'adoptent bénéficient d'une présomption de bonne foi pendant la première année (jusqu'au 2 août 2026). Les fournisseurs qui ne le signent pas devront démontrer une conformité équivalente par d'autres moyens.
10. Bonnes pratiques : comment tester la sécurité d’une IA en toute légalité
Pour les entreprises et chercheurs français, voici les recommandations concrètes :
1. Privilégier les programmes de bug bounty officiels. C’est le cadre le plus sûr. Consultez les pages de sécurité d’Anthropic, OpenAI et Google pour postuler.
2. Formaliser systématiquement par contrat. Tout test adversarial hors programme de bug bounty doit être couvert par un contrat écrit avec autorisation explicite, périmètre défini et clause de confidentialité.
3. Documenter rigoureusement. L’AI Act exige la conservation de la documentation de red teaming. Même en dehors du cadre GPAI, la documentation démontre la bonne foi et le caractère professionnel de la démarche.
4. Signaler via les canaux officiels. Si vous découvrez une vulnérabilité : signalez-la d’abord au fournisseur, puis si nécessaire à l’ANSSI via le CERT-FR. Ne publiez jamais un jailbreak fonctionnel avant d’avoir obtenu une réponse.
5. Constituer des équipes pluridisciplinaires. Le Code de pratique GPAI fait du red teaming une discipline à part entière. Investissez dans la formation et la certification (le France Cybersecurity Challenge organisé par l’ANSSI est un excellent point d’entrée).
6. Intégrer le red teaming dans votre cycle de conformité AI Act. Si vous êtes fournisseur ou déployeur d’un système d’IA à haut risque, le test adversarial doit faire partie intégrante de votre processus de conformité, documenté et reproductible.
7. Séparer environnement de test et production. Comme le recommandent toutes les méthodologies de red teaming IA, les tests doivent se faire dans un environnement isolé, avec journalisation complète et limitation des risques.
11. Et les CGU dans tout ça ? Le droit contractuel en embuscade
Un point souvent négligé : les conditions générales d’utilisation (CGU) des plateformes d’IA interdisent quasi systématiquement les tentatives de contournement des mesures de sécurité.
Même si votre activité ne constitue pas une infraction pénale, violer les CGU d’un service expose à :
- La résiliation immédiate du compte et la perte d’accès
- Des poursuites civiles pour violation contractuelle
- La perte de données associées au compte
Le contournement de mesures techniques de protection peut également relever du Code de la propriété intellectuelle (articles L. 335-3-1 et suivants), qui réprime la neutralisation de dispositifs techniques de protection.
Les CGU d'OpenAI, d'Anthropic et de Google interdisent explicitement le reverse engineering et les tentatives de contournement des garde-fous, sauf dans le cadre de leurs programmes de sécurité dédiés. Le programme de bug bounty constitue une exception contractuelle à cette interdiction.
12. Perspective : vers un statut juridique du red teamer IA en France ?
Le droit français est en retard sur le sujet. Là où la Belgique et la Suisse ont mis en place des guidelines pour encadrer l’activité des hackers éthiques, la France reste dans un entre-deux.
Plusieurs pistes d’évolution sont envisagées par les praticiens et les juristes spécialisés :
La création d’un statut légal spécifique pour les testeurs de sécurité IA, s’inspirant du modèle des professions réglementées. Le label ExpertCyber de l’ANSSI identifie déjà les prestataires de confiance en cybersécurité, mais il ne couvre pas spécifiquement le red teaming IA.
Le développement de programmes de bug bounty publics encadrés par l’État. La DINUM a déjà étendu ses programmes à des services comme Tchap et FranceConnect. Un programme similaire pour les systèmes d’IA publics serait une avancée logique.
La convergence AI Act + NIS 2 pourrait naturellement créer un cadre harmonisé au niveau européen, rendant le red teaming IA une activité non seulement tolérée mais encouragée et standardisée.
La CNIL dans son plan stratégique 2025-2028 a annoncé vouloir « développer les capacités d’audit » en matière d’IA. Le rapprochement entre la CNIL, l’ANSSI et les futures autorités de contrôle AI Act pourrait aboutir à un cadre français de certification des red teamers IA.
- ✅ Le red teaming contractuel (contrat de mission ou bug bounty) est parfaitement légal et constitue même une obligation réglementaire pour les fournisseurs de modèles GPAI à risque systémique depuis le 2 août 2025.
- ✅ L'article 323-3-1 du Code pénal prévoit une exception pour la recherche et la sécurité informatique, mais son application au jailbreak d'IA n'a jamais été testée en jurisprudence.
- ✅ La loi Lemaire protège les chercheurs qui signalent des vulnérabilités à l'ANSSI, mais cette protection n'est pas une immunité pénale absolue.
- ✅ Le Code de pratique GPAI (version finale du 10 juillet 2025) impose des standards élevés de red teaming : équipes pluridisciplinaires, 3 ans d'expérience, 20 jours de test minimum.
- ✅ La convergence AI Act + NIS 2 + RGPD crée un impératif croissant de test adversarial pour les entreprises déployant de l'IA en France.
- ✅ La zone la plus risquée reste le jailbreak sauvage sans cadre contractuel et la divulgation publique de vulnérabilités sans signalement préalable.
Sources principales