Risques juridiques et solutions

1. L’élément fondamental : le Système de Traitement Automatisé de Données (STAD)

Toute l’analyse juridique repose sur une définition technique : qu’est-ce qu’un STAD ? Le Code pénal ne le définit pas explicitement, laissant ce soin à la jurisprudence. Depuis près de quarante ans, les juges ont adopté une interprétation extensive, couvrant pratiquement tout dispositif numérique.

Sont considérés comme des STAD :

La Cour de cassation a, dès les années 2000, validé cette approche large. Dans un arrêt célèbre concernant le système Carte Bleue (TGI Paris, 25 février 2000), les juges ont rappelé qu’un système est un ensemble composé d’unités de traitement, de mémoires, de logiciels, de données et de liaisons. En 2026, cette définition englobe sans ambiguïté les systèmes d’intelligence artificielle et les infrastructures...

1. Jurisprudence liée à l’élément moral

La jurisprudence constante (notamment CA Paris, 30 octobre 2002, Tati ; Cass. crim., 20 mai 2015, Bluetouff) établit que la fraude suppose la conscience de l’absence d’autorisation.

Trois scénarios peuvent être distingués :

Scénario 1 : la porte ouverte (Open Directory)

Situation : vous découvrez une URL publique contenant des données sensibles non protégées.

Question : est-ce légal de la télécharger ?

Réponse juridique : NON.

Depuis l’arrêt Bluetouff, même si aucun mot de passe ne protège le fichier, le maintien est frauduleux si vous avez conscience que ces données ne sont pas destinées au public. La conscience s’infère de la nature des données (données nominatives, données financières) ou du contraste (le site dispose de zones protégées, celle-ci ne l’est pas par erreur).

Scénario 2 : accès sans contrat mais avec communication d’information

Situation : vous découvrez une faille critique de sécurité (injection SQL, RCE) sur le site d’une petite PME. Vous contactez le propriétaire avant d’exploiter.

Question : pouvez-vous tester la faille ?

Réponse juridique : OUI, sous conditions.

Si le propriétaire vous répond « Allez-y, testez », cette autorisation orale a posteriori n’est pas suffisante pour couvrir rétroactivement l’intrusion antérieure. L’autorisation doit être antérieure ou contemporaine...

1. Les prestataires cloud

Scénario assez commun en 2026

Situation : votre client, une PME, héberge son serveur web sur AWS, sa base de données sur Azure, et utilise un CRM SaaS (Salesforce). Il vous mandate pour tester sa sécurité globale.

Question : avez-vous le droit de tester les infrastructures AWS/Azure/Salesforce ?

Réponse juridique : NON, sauf autorisation écrite des prestataires.

Les Conditions Générales d’Utilisation (CGU) d’AWS, Microsoft Azure, Google Cloud et autres imposent des restrictions strictes. Vous ne pouvez pas mener de stress tests ou d’attaque DDoS sans autorisation préalable. De nombreuses plateformes ont des programmes d’autorisation appelés pentest authorization ou authorized security testing.

Avant de tester :

2. Les risques...

1. Obligation de sécurité du responsable du traitement

L’article 32 du RGPD impose au responsable du traitement (le client, en général) une obligation de sécurité « adaptée au risque ». Ce n’est pas une obligation de sécurité absolue, mais une obligation de moyens renforcée.

Pour le pentesteur, cette obligation implique d’aider le client à démontrer qu’il a mis en place des mesures de sécurité appropriées.

En cas de violation de données due à une faille détectée lors de votre pentest, la responsabilité civile du client envers les personnes concernées dépendra de deux facteurs :

2. Notification des violations

Depuis le RGPD (2018) et renforcé par NIS 2...

1. Les clauses de sécurité partagée en environnement cloud

En 2026, presque aucun système d’information n’est sur site (on-premises) purement. Les architectures hybrides et multicloud dominent. Or, chaque plateforme cloud (AWS, OVH, Azure, Google Cloud, Alibaba Cloud…) impose ses propres conditions d’utilisation qui restreignent les tests de sécurité.

La solution contractuelle s’impose : exiger du client une clause affirmative : « Le Client garantit avoir obtenu l’autorisation écrite de chaque prestataire cloud hébergeant les données ou systèmes testés, conformément à leurs conditions d’utilisation. Une copie de ces autorisations sera fournie au Prestataire avant le commencement du pentest. Le Client demeure seul responsable du respect des conditions d’utilisation de ces prestataires. »

Cette clause vous protège en cas de découverte qu’Azure ou AWS ne voulaient pas du test. Vous avez une preuve que le client vous avait induit en erreur ou avait négligé de demander l’autorisation....

1. Le statut de lanceur d’alerte

L’article 122-9 du Code pénal prévoit une exonération de responsabilité pénale pour le lanceur d’alerte qui signale une menace pour l’intérêt général, sous conditions strictes.

Pour qualifier une personne de lanceur d’alerte, quatre conditions cumulatives doivent être remplies. D’abord, la personne doit avoir eu connaissance des faits de manière licite, ce qui signifie que si vous avez volé les documents, vous n’êtes pas un lanceur d’alerte protégé.

Deuxièmement, la signalisation ou divulgation doit se faire sans contrepartie financière directe et de bonne foi. Un chercheur en sécurité acceptant une prime bug bounty après coup pourrait voir son statut remis en question par les juges.

Troisièmement, le signalement doit révéler un fait constitutif d’une infraction, un crime, un délit, une violation grave...

1. Plateforme et tiers de confiance

En 2026, les grandes plateformes de bug bounty actives en France (ex. : YesWeHack, Yogosha, HackerOne…) jouent un rôle crucial de tiers de confiance légal.

Lorsqu’une entreprise lance un programme bug bounty, elle doit accepter les conditions d’utilisation qui autorisent les chercheurs à tester la sécurité dans le périmètre défini. La plateforme doit fournir un cadre contractuel qui protège formellement le chercheur contre les poursuites pénales de l’entreprise.

Juridiquement, le chercheur bug bounty qui découvre une faille doit disposer d’une protection contractuelle équivalente à celle d’un pentesteur classique. L’élément moral de fraude est absent : le chercheur agit avec l’assentiment de l’entreprise cible, transmis via la plateforme.

Cependant, une distinction fondamentale existe car le bug bounty ne couvre que le périmètre défini par l’entreprise. Tester un serveur hors programme est qualifié de délit. Exploiter une faille pour accumuler des primes sur plusieurs vulnérabilités connexes sans...

1. La notification en cascade

Dès la transposition en droit français de la Directive NIS 2, les obligations de notification seront accélérées.

Si la faille découverte affecte un opérateur de service essentiel (banques, électricité, eau, transports, communications) ou une entité importante (autres entreprises du secteur critique), l’ANSSI doit être informée dans les 24 heures suivant la connaissance de l’incident. Pour les autres entités, le délai est de 72 heures.

Parallèlement, si des données personnelles sont affectées, la CNIL doit être notifiée sous 72 heures après la découverte. En cas de risque élevé pour les personnes concernées, celles-ci doivent aussi être notifiées.

Enfin, l’entreprise dispose généralement de 90 jours (délai standard recommandé par l’ANSSI et la CNIL) pour corriger la faille avant divulgation publique ou transmission à des tiers.

2. L’implication du pentesteur dans la procédure

En tant...

1. La collecte illicite de données personnelles

L’article 226-18 du Code pénal dispose :

« Le fait de collecter des données à caractère personnel par un moyen frauduleux, déloyal ou illicite est puni de cinq ans d’emprisonnement et de 300 000 euros d’amende. »

Cette infraction vise spécifiquement celui qui collecte (c’est-à-dire recueille ou exfiltre) des données personnelles sans droit. Pour le pentesteur, cela crée un double piège.

D’abord, télécharger un fichier contenant des données personnelles (même une seule ligne d’une base de clients) constitue matériellement une collecte au sens de cet article. 

Deuxièmement, cette collecte est frauduleuse dès...

1. La chaîne de preuve

En droit français, une preuve numérique (log, capture d’écran, dump de mémoire, image de disque) n’est admissible devant un tribunal que si son intégrité peut être garantie. Cela passe par une documentation rigoureuse que l’on appelle la chaîne de preuve.

La chaîne de preuve enregistre chaque manipulation de la preuve : qui l’a créée, quand, comment, qui l’a stockée, qui l’a examinée. Chaque étape doit être horodatée et signée. En cas de brèche dans cette chaîne, le juge peut rejeter la preuve.

Pour le pentesteur, cela signifie que chaque rapport de test, chaque capture d’écran, chaque log d’attaque doit être créé et conservé en respectant des normes précises. Une photo d’écran prise au smartphone sans horodatage ni contexte documenté risque d’être rejetée. Une vidéo de session pentesting enregistrée (avec permissions du client) et horodatée sera plus crédible.

2. Les standards techniques

Pour les investigations informatiques...

1. Responsabilité directe envers les personnes concernées

L’article 82, alinéa 1^er du RGPD stipule que « Toute personne ayant subi un dommage matériel ou moral du fait d’une violation du présent règlement a le droit d’obtenir du responsable du traitement ou du sous-traitant réparation du préjudice subi. ».

Cela signifie qu’une personne ayant subi un préjudice du fait de votre traitement de ses données personnelles peut vous poursuivre directement devant la juridiction civile, en plus de toute action pénale.

Par exemple : lors d’un pentest, vous exfiltrez une base de données contenant les données de santé d’un millier de patients. Ces données sont ultérieurement compromises (perdues, volées ou divulguées). Chacun des mille patients peut théoriquement vous poursuivre en responsabilité civile pour les dommages moraux et immatériels qu’il a subis (menaces pour sa vie privée, discrimination potentielle si les données de santé sont publiques…)....

1. La Directive NIS 2

La Directive NIS 2 (2022/2555), prochainement transposée en droit français, élargit considérablement le périmètre des entités soumises à une obligation légale de sécurité.

Auparavant, seuls les opérateurs de services essentiels (banques, électricité, transport) avaient une obligation explicite de sécurité. NIS 2 ajoute une large catégorie d’entités importantes : entreprises de plus de 250 salariés ou chiffre d’affaires > 50 millions € dans des secteurs critiques (santé, finance, énergie, transports, communications, autorités publiques…).

Pour ces entités, l’obligation de réaliser des tests de sécurité réguliers (y compris des pentests) est maintenant une obligation légale, pas une simple bonne pratique. Le non-respect expose les dirigeants à une responsabilité personnelle potentielle.

Pour le pentesteur, cela crée une aubaine économique : la demande de pentests...

1. Qu’est-ce que la qualification PASSI ?

Le PASSI, délivré par l’ANSSI depuis les années 2010, est une certification que le prestataire dispose des compétences techniques et organisationnelles pour réaliser des audits de sécurité informatique sensibles, conformément aux standards nationaux.

Pour obtenir le PASSI, un cabinet ou un professionnel indépendant doit passer une évaluation rigoureuse portant sur trois domaines : les compétences techniques et méthodologiques du personnel, les processus organisationnels (gestion des risques, confidentialité et traçabilité) et la capacité à respecter les secrets d’État (notamment pour les audits de systèmes gouvernementaux).

Le PASSI se décline en plusieurs niveaux : PASSI standard (audits classiques), PASSI de niveau « Élevé » (systèmes critiques), et PASSI spécialisé (ex. : PASSI Logiciels, pour les tests sur les produits informatiques).

2. Avantages et responsabilité...

1. Avant le pentest

Vérification du mandat : avant toute action, documenter que vous avez reçu un mandat écrit du propriétaire légitime du système. Une simple conversation avec le responsable informatique ne suffit pas. Il convient d’exiger une signature sur le contrat de la part d’une personne ayant compétence légale (ex. : directeur informatique avec délégation de pouvoir, directeur général ou autre représentant légal).

Périmètre précis : lister exhaustivement toutes les adresses IP, noms de domaine, services autorisés. Exclure explicitement tout ce qui n’est pas listé. Ajouter des clauses comme « En cas de découverte d’un système en dehors du périmètre défini, le pentest s’arrête immédiatement et ne sera pas exploré ».

Données personnelles : si le système contient des données personnelles (ce qui est quasi-certain en 2026), inclure une clause RGPD. Spécifier le rôle du prestataire (sous-traitant selon l’article 28 RGPD), l’obligation de destruction des données...