
Secteurs d'activité ciblés
Dernière mise à jour :
8 min.
Sur la base des travaux de recherche du Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann
Une équipe d'experts en sécurité informatique attaque ses propres systèmes. Non pas par sabotage, mais sur commande. Ils endossent le rôle de véritables attaquants, recherchent des failles, testent des mots de passe, tentent de s'introduire dans les réseaux — et documentent le tout. Ce qui ressemble à un exercice paradoxal est aujourd'hui l'une des méthodes les plus efficaces de cyberdéfense : le test d'intrusion. Et pour de nombreuses entreprises, il ne s'agit plus depuis longtemps d'une démarche facultative, mais d'une obligation légale.
Dans ses recherches, Teichmann a analysé avec précision tant les exigences réglementaires que les limites du droit pénal de ces tests. La question de savoir ce que les entreprises ont le droit de faire, doivent faire et ce qu'elles doivent absolument éviter lors des tests d'intrusion et des opérations de Red Teaming a une réponse — mais elle est plus complexe que beaucoup ne le pensent (Teichmann & Boticiu, An Overview of the Benefits, Challenges, and Legal Aspects of Penetration Testing and Red Teaming, International Cybersecurity Law Review 2023, p. 1–11).
Qu'est-ce que les tests d'intrusion et le Red Teaming ?
Un test d'intrusion est une attaque simulée et autorisée contre des systèmes informatiques, des réseaux ou des applications, dans le but d'identifier des failles de sécurité avant que de véritables attaquants ne le fassent. Le testeur d'intrusion agit pour le compte de l'entreprise, avec son autorisation écrite expresse, dans un périmètre défini et à un moment convenu.
Le Red Teaming va encore plus loin. Alors qu'un test d'intrusion classique se concentre souvent sur des systèmes spécifiques, une Red Team simule une attaque complète et réaliste contre l'ensemble de l'entreprise — souvent à l'insu de l'équipe interne de sécurité informatique. L'objectif n'est pas seulement d'identifier des vulnérabilités techniques, mais de tester l'ensemble des capacités de détection et de réaction de l'organisation (Teichmann & Boticiu, ICLR 2023, p. 1–11).
La différence est de taille : un test d'intrusion répond à la question « Quelles failles techniques avons-nous ? » Une opération de Red Team répond à la question « Un véritable attaquant pourrait-il compromettre notre entreprise — et nous en rendrions-nous seulement compte ? »
Pourquoi les tests d'intrusion sont aujourd'hui obligatoires — ou le deviendront bientôt
Le règlement DORA oblige explicitement les institutions financières d'importance à effectuer régulièrement des tests d'intrusion basés sur la menace, appelés Threat-Led Penetration Tests (TLPT). Ces exercices de Red Team doivent être menés au moins tous les trois ans par des testeurs indépendants et qualifiés, selon un cadre harmonisé au niveau de l'UE. Les résultats doivent être communiqués à l'autorité de surveillance, et les failles critiques doivent être corrigées dans des délais définis. Le modèle de référence est le framework TIBER-EU, qui était déjà établi en Allemagne sous le nom de TIBER-DE (Teichmann, Digital Operational Resilience Act – EU-weit einheitliche IT-Sicherheitsregeln für Finanzinstitute, BB 2025, p. 2760–2770).
La directive NIS 2 exige des entités essentielles et importantes qu'elles prennent des mesures techniques et organisationnelles appropriées. Les tests d'intrusion réguliers sont considérés comme un élément reconnu de l'état de l'art et sont donc implicitement requis. Quiconque ne les réalise pas prend le risque, en cas d'incident, de devoir prouver que ses systèmes étaient tout de même conformes à l'état de l'art sans ces mesures — une preuve difficile à apporter (Teichmann, NIS2-Schulungspflicht der Geschäftsleitung, Computer und Recht 2025, p. 718–725).
La loi allemande sur la sécurité informatique (IT-Sicherheitsgesetz 2.0) oblige depuis mai 2023 les exploitants d'infrastructures critiques (KRITIS) à utiliser des systèmes de détection des attaques qui surveillent en continu et de manière automatisée les paramètres d'exploitation. Les tests d'intrusion sont alors l'instrument qui permet de vérifier si ces systèmes de détection fonctionnent réellement (Teichmann, IT-Sicherheitsgesetz 2.0 in der Praxis: Angriffserkennung und kritische Komponenten, BB 2025, p. 1993–1998).
La frontière pénale : quand le hacker éthique devient-il un délinquant ?
L'article 202a du Code pénal allemand (StGB) punit l'espionnage de données de peines de prison allant jusqu'à trois ans pour quiconque accède sans autorisation à des données particulièrement protégées. L'article 202c du StGB — surnommé « l'article des hackers » — punit déjà la préparation de tels actes, c'est-à-dire l'acquisition ou la fabrication d'outils d'attaque. Et l'article 303b du StGB sur le sabotage informatique s'applique si les systèmes informatiques sont perturbés par les actions de test.
Le motif de justification décisif est le consentement de l'ayant droit. Le propriétaire ou l'exploitant qui donne expressément son autorisation à un testeur d'intrusion lève ainsi le caractère illicite d'actes qui seraient autrement punissables par la loi.
Mais ce consentement doit répondre à des critères stricts. Il doit être accordé par la personne qui dispose réellement du pouvoir de décision. Il doit être donné avant le début du test — une autorisation a posteriori ne guérit pas une infraction pénale. Il doit couvrir le périmètre précis du test : toute action menée en dehors du scope convenu perd la protection du consentement. Et il doit être documenté par écrit, car en cas de litige, il conviendra de prouver qu'un consentement valable existait (Teichmann & Boticiu, ICLR 2023, p. 1–11).
Ce que le contrat doit obligatoirement prévoir
Un contrat de test d'intrusion juridiquement sûr doit contenir plusieurs éléments clés. Le périmètre (scope) doit être défini avec précision : quels systèmes, réseaux, applications et plages d'adresses IP peuvent être testés ? Qu'est-ce qui est formellement exclu ? La période doit être fixée. Les méthodes autorisées doivent être décrites : l'ingénierie sociale est-elle permise ? L'accès physique ? Les simulations de déni de service ? L'exfiltration de données pour tester la détection ?
Des dispositions d'urgence sont obligatoires : que se passe-t-il si le testeur découvre de véritables attaques en cours, non simulées ? Un numéro d'assistance téléphonique permettant d'interrompre immédiatement le test est requis. Enfin, des clauses de confidentialité doivent garantir que les résultats des tests ne tombent pas entre de mauvaises mains (Teichmann & Boticiu, ICLR 2023, p. 1–11).
Fournisseurs tiers et Cloud : le problème juridique sous-estimé
Dans le paysage informatique moderne, presque toutes les entreprises utilisent des services cloud, des applications SaaS et des hébergeurs externes — et ces tiers ont leurs propres conditions générales d'utilisation qui peuvent limiter ou interdire les tests d'intrusion sur leur infrastructure. Les grands fournisseurs de cloud autorisent les tests sur l'infrastructure louée, mais exigent soit une notification préalable, soit excluent certaines méthodes de test. Ignorer ces règles expose l'entreprise non seulement à la résiliation de son contrat cloud, mais aussi à des poursuites judiciaires.
Le régime de NIS 2 aborde ce problème via la responsabilité de la chaîne d'approvisionnement : les entreprises doivent gérer activement la sécurité de leurs prestataires informatiques et ont le droit d'exiger des audits de sécurité. Ce droit d'audit devrait être ancré dès la conclusion du contrat avec les prestataires — car un test d'intrusion qui exclut l'infrastructure de tiers ne fournit qu'une image incomplète de la surface d'attaque réelle.
Red Teaming et devoir de diligence accru
Les exercices de Red Team menés à l'insu de la Blue Team (l'équipe interne de défense) comportent des risques particuliers. L'équipe interne de sécurité informatique peut réagir à l'attaque simulée comme s'il s'agissait d'une vraie : arrêter des systèmes, alerter des organismes externes ou déclencher des plans d'urgence. Teichmann recommande donc d'établir une structure d'escalade claire : un groupe restreint de personnes de confiance — généralement le RSSI et la direction générale — est informé de l'exercice et peut intervenir en cas d'urgence. Une ligne d'assistance joignable immédiatement est obligatoire. De plus, la documentation juridique doit être conçue de manière à pouvoir être présentée immédiatement aux autorités ou aux forces de l'ordre en cas de besoin (Teichmann & Boticiu, ICLR 2023, p. 1–11).
Prendre les résultats au sérieux — une obligation légale
Les recherches de Teichmann démontrent que de nombreuses entreprises font réaliser des tests d'intrusion sans en exploiter réellement les résultats. Un test dont les conclusions finissent dans un tiroir ne représente pas seulement un budget gaspillé — il crée une situation juridiquement dangereuse. Quiconque sait que des failles existent et ne les corrige pas agit de manière coupable. Sous l'empire de DORA, les institutions financières sont expressément tenues de traiter les failles critiques issues des tests TLPT dans des délais stricts et d'en faire rapport à l'autorité de contrôle (Teichmann, BB 2025, p. 2760–2770).
Conclusion : l'attaque comme meilleure défense — sécurisée sur le plan juridique
Le test d'intrusion et les exercices de Red Team constituent aujourd'hui les outils les plus efficaces pour mesurer la résilience réelle d'une entreprise face aux cyberattaques. Aucun concept technique ni aucun audit de conformité papier ne peut remplacer ce qu'une attaque simulée éthique met au jour.
Les travaux de recherche de Teichmann le confirment : le cadre juridique de ces tests est clair, mais exigeant. Un consentement valide, un périmètre précis, des contrats juridiquement blindés et un processus de remédiation structuré en sont les conditions préalables indispensables. Et pour un nombre croissant d'entreprises, ce test n'est plus une option — c'est une obligation.
Toutes les sources font référence à des publications scientifiques du Dr. iur. Dr. rer. pol. Fabian M. A. Teichmann. La bibliographie complète est documentée dans la liste des publications (état en mai 2026).
Articles similaires


