Cadre légal : quand tu as le droit de tester
Le red teaming et le pentest IA vivent dans une zone grise légale. La plupart des juridictions n'ont pas de loi explicite sur le « hacking éthique de l'IA », contrairement aux tests de cybersécurité. Ce qui est permis dépend de ton mandat et de ta juridiction.
Trois scénarios légaux
- Interne à l'organisationTu es employé ou contractant d'une entreprise qui développe une IA. Tu testes leur système. C'est légal si tu as un mandat écrit explicite qui couvre le scope de test.
- Accord de serviceUn client te paie pour auditer/red teamer son système IA. C'est légal s'il y a un contrat signé qui énumère les droits d'accès, les méthodes autorisées, et les limites (pas de destruction de données, pas d'exfiltration prolongée, etc.).
- Programme de bug bountyL'entreprise publie un programme : « Trouvez des vulnérabilités dans notre IA, déclarez-les, on paie. » C'est légal pour les participants qui respectent les règles du programme.
Tester sans autorisation — même pour « vérifier la sécurité » d'un LLM public — peut enfreindre des lois : les conditions d'utilisation du service, les lois sur l'accès non autorisé, voire les lois de protection des données. Les tests « research » sur des systèmes publics sont une zone grise.
Responsabilités du pentesteur IA
Ce que tu dois faire
- Obtenir un mandat écritAvant tout test, avoir un contrat ou une lettre qui dit : scope, méthodes autorisées, durée, données accessibles, confidentialité, assurance.
- Rester dans le scopeNe pas tester au-delà de ce qui est convenu. Ne pas accéder à des données hors scope. Ne pas tester des systèmes adjacents non autorisés.
- Documenter tes testsGarder des logs précis : quand, quoi, avec quel outil, quels résultats. Cela te protège si on te pose des questions ultérieurement.
- Déclarer les vulnérabilités trouvéesPas d'exploitation pour compte personnel. Pas d'exfiltration. Pas de pub avant accord. Suivre le protocole de disclose convenu.
- Nettoyer après toiPas de « portes dérobées » en arrière-plan. Pas de données conservées au-delà du test. Pas de traces malveillantes.
Ce que tu NE dois pas faire
- Exploiter une vulnérabilité découverteLa découvrir c'est bien, l'exploiter pour accéder à des données ou causer du dommage c'est criminel (même « pour prouver l'impact »).
- Exfiltrer des donnéesCopier les données du client, les logs du modèle, le dataset d'entraînement. C'est du vol, même si tu les gardes « sécurisées ».
- Accéder à des données personnelles au-delà du scopePar exemple, le modèle processus des données personnelles de vrais utilisateurs. Tu dois limiter ton accès.
- Disclose publiquement sans accordAnnoncer la vulnérabilité sur les réseaux, dans un article, avant que le client n'ait eu le temps de corriger. C'est un manquement contractuel.
- Continuer à accéder après la fin du mandatUne fois le test terminé, tu arrêtes. Pas d'accès prolongé « pour observer ».
Points clés du contrat de test IA
Un bon contrat de pentest/audit IA doit inclure :
Scope
- Systèmes à testerÉnumérer précisément : quel modèle ? quel RAG ? quel LLM ? quels environnements ? (développement, staging, prod ?)
- Méthodes autoriséesTester l'injection ? Le poison des données ? L'exfiltration du modèle ? Extraction via queries répétées ?
- Donnée et accèsQuelles données de test tu as accès ? Réelles ou synthétiques ? Droits de lecture seuls ou aussi écrire ?
- Durée et calendrierDu X au Y, pendant Z jours ouvrés. Avec pause (ex. ne pas tester pendant la prod en heures de pointe).
Confidentialité et disclose
- Qu'est-ce qui reste confidentielLes méthodes du client, l'architecture, les données, les résultats du test.
- Qui peut voir le rapportJuste le client ? Ses assureurs ? Des régulateurs ?
- Calendrier de discloseSi une vulnérabilité critique est trouvée : combien de jours avant que tu la discloses ? Si c'est un bug bounty, est-ce que tu peux la publier après ?
Responsabilités et assurance
- Assurance du pentesteurTu dois avoir une couverture responsabilité civile professionnelle qui couvre les dommages en cas de faute (ex. crash du système, exposition accidentelle de données).
- Non-reprise du dommage« Le pentesteur n'est pas responsable des dommages causés par l'IA existante, juste des dommages directs causés par le test lui-même. »
- Limitation de responsabilité« Pas de responsabilité au-delà du montant du contrat » (protection mutuelle).
Protocole de disclose des vulnérabilités
Tu as trouvé une vulnérabilité critique. Comment faire ?
Disclose responsable
Jour 1 : Notifier confidentiellement le propriétaire du système. Fournis : description de la vulnérabilité, preuve de concept (PoC), impact estimé, suggestions de correction.
Jour 3–7 : Attendre sa réaction. Il peut dire : « c'est pas grave », « on la corrige », « on a déjà un plan ».
Jour 30–90 : Vérifier la correction. S'il n'y a rien, relancer.
Jour 90+ : Si toujours rien, tu peux disclose publiquement après notification (ou suivre le protocole du programme de bug bounty).
Bonnes pratiques
- Pas de PoC exécutableSi tu donnes un PoC, assure-toi qu'il ne peut pas être copié/collé et exploité directement. Pseudo-code, snippets fragmentés, commentaires..
- PGP ou canal chiffréSi c'est très sensible, offre de discuter en visio ou par email chiffré.
- Coordonner avec la sécurité du clientNe va pas directement au PDG ; contact l'équipe sécurité/CISO du client.
- Pas de chantage« Si tu payes pas X, je disclose ». C'est extorsion, c'est illégal.
Assurance et couverture légale
Si tu as un accident (crash du système, exposition accidentelle, réclamation de dommage), une bonne assurance professionnelle protège :
- Responsabilité civile professionnelleDommages causés par ton travail (ex. test qui plante une API, crée une fuite mémoire). Cible : couverture €1M–€5M selon la criticité.
- Couverture cyberSi tu stockais localement les résultats de test et tu te fais voler. L'assurance couvre les frais de notification et de rectification.
- Protection juridiqueFrais de défense si tu es poursuivi ou accusé à tort. Utile si le client conteste ton travail ou prétend tu as volé des données.
Vérifier que ta couverture d'assurance inclut les tests IA et le red teaming. Certaines polices cyber classiques excluent explicitement le pentest. Demander à ton assureur une couverture claire pour les tests IA/ML.
Checklist : avant de tester
Jurisprudence croissante
Les affaires de pentest « sans mandat » se multiplient. Quelques repères :
- USA : CFAA (Computer Fraud and Abuse Act)Tester sans autorisation = accès non autorisé. Violation criminelle possible, même pour les chercheurs. Exceptions en débat.
- France : CNIL et RGPDAccéder à des données personnelles sans consentement dans un test est une violation RGPD. L'amende peut être lourde.
- EU : Directive NIS 2Obligation de mener des essais de sécurité, mais ils doivent rester internes ou sous contrat d'audit.