Cadre légal de la reconnaissance et des tests de sécurité

En France, sonder un système informatique sans autorisation peut constituer un délit : l'accès frauduleux simple est puni de trois ans d'emprisonnement et 100 000 € d'amende (article 323-1 du Code pénal). Cette leçon ouvre le module sur la mesure de l'exposition. Elle explique ce que la loi punit, ce que le « motif légitime » protège réellement, ce qu'une autorisation écrite doit contenir, et pourquoi la frontière entre reconnaissance passive et active détermine quand il faut un papier. Elle s'adresse aux personnes qui vont utiliser des outils de reconnaissance (moteurs de recherche, bannières, scanners) et qui connaissent déjà les sept phases d'une cyberattaque.

Ce que vous allez apprendre

Un outil de sécurité est légal ou non selon le geste et le papier qui l'accompagne, pas selon son nom. Concrètement, vous saurez :

• Citer les infractions des articles 323-1 à 323-3-1 du Code pénal et les peines en vigueur.
• Expliquer ce que couvre le motif légitime de l'article 323-3-1, et ce qu'il ne couvre pas.
• Rédiger le contenu minimal d'une autorisation : périmètre, dates, règles d'engagement.
• Classer une action de reconnaissance en passive ou active, et décider si elle exige une autorisation.
• Choisir une cible d'entraînement légale, installer ses outils sans risque, et signaler une vulnérabilité sans s'exposer.

Que punit le Code pénal en matière de systèmes informatiques ?

Le chapitre III du titre II du livre III du Code pénal réprime les atteintes aux systèmes de traitement automatisé de données (les « STAD » : tout ensemble de machines, de logiciels et de données qui traite de l'information). Les peines ci-dessous sont celles du texte consolidé en vigueur au 2026-10-16, tel que le publie Légifrance. Elles ont été relevées pour les articles 323-1 et 323-4-1 par la loi n° 2023-22 du 24 janvier 2023 : une page plus ancienne peut encore afficher deux ans et 60 000 €.

Article	Fait puni	Peine
323-1, alinéa 1	Accéder ou se maintenir frauduleusement dans un système	3 ans et 100 000 €
323-1, alinéa 2	Idem, avec suppression ou modification de données, ou altération du fonctionnement	5 ans et 150 000 €
323-2	Entraver ou fausser le fonctionnement d'un système (déni de service)	5 ans et 150 000 €
323-3	Introduire, extraire, détenir, copier, modifier ou supprimer frauduleusement des données	5 ans et 150 000 €
323-3-1	Importer, détenir, offrir ou céder un outil conçu ou spécialement adapté pour commettre ces infractions, sans motif légitime	Peine de l'infraction visée
323-4-1	Les infractions précédentes commises en bande organisée	10 ans et 300 000 €

Glissez pour voir

Lorsque le système visé traite des données à caractère personnel pour le compte de l'État, les peines des articles 323-1 à 323-3 passent à 7 ans et 300 000 €. L'article 323-7 punit la tentative comme l'infraction elle-même, et l'article 323-5 ajoute des peines complémentaires, dont l'interdiction d'exercer l'activité professionnelle liée à l'infraction et la confiscation du matériel utilisé.

Deux conséquences pratiques en découlent. Un simple accès sans dégât est déjà un délit : il n'est pas nécessaire d'avoir rien cassé ni rien volé. Et l'intention affichée (« je voulais seulement vérifier ») n'exonère pas, parce que le texte ne parle pas d'intention de nuire mais d'accès frauduleux, c'est-à-dire sans le droit d'y accéder.

Que protège exactement le « motif légitime » ?

L'article 323-3-1 punit la détention d'un outil de piratage « sans motif légitime, notamment de recherche ou de sécurité informatique ». Le texte ne vise que les outils conçus ou spécialement adaptés pour commettre une infraction : un analyseur de trafic généraliste comme Wireshark n'entre pas dans la même catégorie qu'un framework d'exploitation tel que Metasploit, et la qualification revient au juge. Le motif légitime n'est pas réservé aux professionnels : un étudiant, un chercheur ou un administrateur peut l'invoquer, à condition que le motif soit réel et se démontre. Il protège la détention et l'étude de l'outil.

Il ne protège pas l'usage contre un système dont vous n'avez pas le droit de vous servir. Les articles 323-1 à 323-3 punissent l'accès, l'entrave et l'atteinte aux données, quel que soit l'outil employé, et aucune ligne du texte n'ouvre une exception pour le chercheur qui teste « pour vérifier ». Un motif légitime de détention n'est donc pas une autorisation d'accès : ce sont deux questions différentes.

Une jurisprudence connue éclaire le mot « frauduleusement » : dans l'affaire jugée par la Cour de cassation (chambre criminelle, 20 mai 2015, pourvoi n° 14-81.336), une personne qui avait atteint, par une recherche sur un moteur, des documents d'un extranet (espace web réservé à des partenaires) mal protégé a été condamnée pour maintien frauduleux (et pour vol de données), après avoir constaté un contrôle d'accès. La leçon à en tirer est prudente : « accessible » ne veut pas dire « autorisé », y compris quand c'est un moteur de recherche qui a servi de porte d'entrée.

Que doit contenir une autorisation écrite ?

Une autorisation écrite est le document qui transforme un test d'intrusion en prestation légale. Elle est signée par une personne qui a le pouvoir d'engager le propriétaire des systèmes. Elle prend souvent la forme d'une lettre de mission ou d'un contrat de prestation, complété par des règles d'engagement (rules of engagement, le cahier des gestes permis et interdits).

Un bon document nomme sans ambiguïté :

• le périmètre : noms de domaine, plages d'adresses IP, applications, environnements (production ou préproduction) ;
• les exclusions : systèmes tiers, services hébergés chez un fournisseur qui impose sa propre procédure, équipements fragiles ;
• la fenêtre de temps : dates et heures pendant lesquelles les tests sont permis ;
• les techniques permises ou interdites : scan seul, exploitation de failles, déni de service, hameçonnage de collaborateurs ;
• les contacts de part et d'autre, pour arrêter immédiatement un test qui dérape ;
• le traitement des données trouvées en chemin : conservation, destruction, confidentialité.

La question du propriétaire réel compte autant que la signature. Un site hébergé chez un prestataire (cloud, hébergeur mutualisé) dépend en partie de ce prestataire : beaucoup publient leur propre politique de tests, à respecter en plus de l'autorisation du client. Un test fait avec l'accord du client sur une adresse IP qui n'est plus la sienne est un accès non autorisé chez un tiers.

Un programme de bug bounty (une entreprise invite des chercheurs à signaler des failles, souvent contre récompense) joue le même rôle quand il est public : son règlement fixe un périmètre et des règles, et constitue l'autorisation, dans ces limites seulement.

Quelle cible peut-on viser pour s'entraîner légalement ?

On s'entraîne sur ses propres machines ou sur une cible qui annonce publiquement qu'elle accepte les tests. La première option est à privilégier : un homelab de machines virtuelles isolées permet de scanner, casser et reconstruire sans conséquence pour personne, et les exercices de ce module se rejouent sur un conteneur local.

La seconde option est scanme.nmap.org, un serveur que le projet Nmap maintient pour cet usage. La documentation de Nmap donne la permission de le scanner avec Nmap uniquement, sans test d'exploits ni déni de service, et demande de ne pas dépasser une douzaine de scans par jour : en cas d'abus, le service sera retiré. Cette autorisation vient du propriétaire lui-même, publiée à l'adresse du serveur : c'est exactement ce que la loi attend. Elle ne s'étend à aucun autre domaine du projet.

Une cible « qui a l'air vulnérable » n'est pas une cible d'entraînement. Le fait qu'un serveur réponde, qu'il soit ancien ou mal configuré, ne vaut pas autorisation. Les plateformes d'entraînement (machines volontairement vulnérables, défis en ligne) publient leurs règles : celles-ci tiennent lieu de lettre de mission.

Quels autres risques courent ceux qui manipulent ces outils ?

Au-delà de la loi, les outils de sécurité présentent des risques pour celui qui les installe. Les logiciels gratuits trouvés sur des dépôts ou des forums ne sont pas tous fiables, et certains embarquent un logiciel malveillant : téléchargez depuis les sources officielles du projet et vérifiez les signatures quand elles existent. Testez dans une machine virtuelle isolée, séparée de vos données personnelles.

Côté technique, un scan réseau trop rapide peut ralentir un réseau local, une attaque par force brute peut verrouiller des comptes ou corrompre des données, et un script mal configuré peut modifier des fichiers système. Côté professionnel, un test non autorisé sur le réseau de son employeur peut entraîner un licenciement, au-delà de la procédure pénale : l'employeur n'a pas besoin d'attendre le jugement pour tirer ses conséquences.

Reconnaissance passive ou active : où passe la frontière ?

La reconnaissance passive collecte de l'information sans envoyer aucune requête aux systèmes de la cible ; la reconnaissance active leur en envoie. Cette distinction, vue du côté de l'attaquant dans la phase de reconnaissance, est ici retournée côté défenseur : elle dit quand il faut un papier.

	Passive (OSINT, renseignement en sources ouvertes)	Active
Exemples	Moteur de recherche, journaux de transparence des certificats (liste publique des certificats TLS émis), WHOIS (registre public des titulaires de noms de domaine), réseaux sociaux	Scan de ports, capture de bannière, interrogation d'un service
Qui voit l'action ?	La cible ne voit rien	La cible peut la voir dans ses journaux
Autorisation	Non requise pour lire des sources publiques, mais le RGPD (règlement européen sur les données personnelles) s'applique aux données collectées	Hors de vos propres systèmes : autorisation écrite exigée par la règle professionnelle, et prudence juridique au-delà de l'usage normal (voir les trois cas ci-dessous)
Risque légal	Faible tant qu'on reste en lecture de sources publiques	Accès ou maintien frauduleux possible, entrave seulement si la perturbation du service est délibérée

Glissez pour voir

La frontière compte pour trois raisons. Elle fixe d'abord la responsabilité : une requête envoyée à un système tiers engage son auteur. Elle fixe ensuite la détectabilité : l'active laisse des traces chez la cible, qui peut déposer plainte. Elle fixe enfin le risque technique : un scan trop agressif ralentit un réseau ou sature un équipement fragile.

Ce dernier risque touche à l'entrave de l'article 323-2, mais l'entrave est un délit intentionnel : l'article 121-3 du Code pénal pose qu'il n'y a pas de délit sans intention, sauf quand la loi prévoit l'imprudence, ce que l'article 323-2 ne fait pas. Une saturation accidentelle n'est donc pas, à elle seule, ce délit ; elle engage en revanche la responsabilité contractuelle du testeur et sa réputation.

Le schéma ci-dessous résume le raisonnement à mener avant chaque action. Il se lit de haut en bas : la première question (l'action envoie-t-elle des requêtes ?) range l'action côté passif ou actif ; ensuite, la propriété des systèmes, l'autorisation écrite puis le périmètre séparent l'action autorisée de celle qu'il ne faut pas lancer. Sur vos propres systèmes, la question du périmètre n'a pas d'objet : la branche s'arrête dès la réponse « oui ». L'arbre applique la règle la plus prudente, celle du métier ; la seule exception, l'usage normal d'un service public, est détaillée plus bas. À chaque sortie « Ne pas lancer » (en rouge), on s'arrête.

Deux garde-fous séparent la reconnaissance active de l'accès frauduleux : la propriété ou l'autorisation, puis le périmètre. Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Un cas trompe souvent : un simple curl -I sur une page publique est proche de ce qu'enverrait un navigateur, alors que la capture de bannière d'un service qui n'est pas fait pour le public ou un balayage de ports vont au-delà de l'usage normal. La leçon sur le banner grabbing se limite donc à des conteneurs locaux, par prudence et par règle professionnelle.

Une requête vers un système tiers est-elle toujours interdite sans autorisation ?

Non : la loi ne dit nulle part « toute requête active exige une autorisation écrite », et il faut distinguer trois cas. Les articles 323-1 à 323-3 punissent l'accès ou le maintien frauduleux, c'est-à-dire sans en avoir le droit. Le texte ne définit pas où commence la fraude pour une simple requête, et c'est le juge qui apprécie les faits.

• Usage normal d'un service public. Charger une page d'un site ouvert au public, c'est envoyer la requête qu'un navigateur enverrait. Le propriétaire a ouvert ce service pour cet usage : cela ne demande aucune autorisation particulière.
• Sondage de sécurité au-delà de l'usage normal. Balayer des ports, essayer des chemins ou des identifiants, interroger un service qui n'est pas fait pour le public : c'est la zone grise, laissée à l'appréciation du juge selon les faits, comme le rappelle la phase de reconnaissance. Le plus sûr est de ne pas s'y aventurer sans accord.
• Règle professionnelle de l'autorisation écrite. Tout test mené pour le compte d'un client, ou sur un système qui n'est pas le sien, se fait avec un écrit. Ce n'est pas un article de loi qui l'impose mot pour mot : c'est la règle du métier, qui protège le testeur en lui donnant un papier à présenter si un incident survient.

Un point reste net : « accessible » ne veut pas dire « autorisé » dès qu'un contenu protégé est en jeu. L'arrêt de 2015 cité plus haut retient le maintien frauduleux après le constat d'un contrôle d'accès, pas la simple requête qui y a mené.

Comment signaler une vulnérabilité sans se mettre en cause ?

Si vous découvrez une faille par hasard, l'article L2321-4 du Code de la défense organise un signalement à l'ANSSI, sans dénonciation au procureur pour la personne de bonne foi. L'article 40, alinéa 2, du Code de procédure pénale oblige les autorités constituées, officiers publics et fonctionnaires à signaler au procureur les crimes et délits dont ils ont connaissance : il pèse sur eux, pas sur un particulier. L'article L2321-4 écarte cette obligation à l'égard d'une personne de bonne foi qui transmet à la seule ANSSI, autorité nationale de sécurité des systèmes d'information, une information sur une vulnérabilité : l'agence n'a pas à dénoncer cette personne au procureur, et elle préserve la confidentialité de son identité. Elle peut aussi avertir l'hébergeur, l'opérateur ou le responsable du système.

Ce dispositif a des limites. Il protège la transmission faite à l'ANSSI ; il ne légalise pas l'accès qui a conduit à la découverte, et il ne vaut que pour une transmission à l'ANSSI, pas pour une publication. La démarche prudente est donc de ne pas aller plus loin que ce qui a permis de constater la faille : pas d'exploration, pas de copie de données, pas de test de contournement. L'ANSSI décrit la procédure sur sa page Déclaration de vulnérabilités, qui renvoie vers un formulaire de déclaration en ligne : lisez-la avant d'écrire.

Pour une faille dans un logiciel ou un service qui publie un point de contact (fichier security.txt qui indique à qui écrire, page de divulgation, programme de bug bounty), suivre la procédure du propriétaire reste la voie la plus directe.

À retenir

• Accéder ou se maintenir frauduleusement dans un système est un délit (article 323-1) : trois ans et 100 000 € pour l'accès simple, cinq ans et 150 000 € si des données sont modifiées ou le fonctionnement altéré.
• L'entrave (déni de service, 323-2) et l'atteinte aux données (323-3) valent cinq ans et 150 000 € ; la tentative est punie comme l'infraction.
• Le motif légitime de l'article 323-3-1 protège la détention d'un outil, pas son usage contre un système dont vous n'avez pas le droit de vous servir.
• Une autorisation écrite nomme le périmètre, les exclusions, les dates, les techniques permises et les contacts d'urgence ; elle est signée par qui peut engager le propriétaire.
• La reconnaissance passive ne touche pas la cible ; la active lui envoie des requêtes : un usage normal d'un service public ne demande rien, un sondage au-delà est une zone grise que le juge apprécie, et la règle professionnelle impose une autorisation écrite pour tout test sur un système qui n'est pas le vôtre.
• Entraînez-vous sur vos propres machines, dans une machine virtuelle isolée, ou sur scanme.nmap.org, qui annonce publiquement accepter les scans.
• Pour signaler une faille trouvée de bonne foi, adressez-vous à l'ANSSI (article L2321-4 du Code de la défense, qui préserve votre identité) sans aller plus loin dans le système.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →