Tests d'intrusion (pentest) : guide et obligations 2026

L’essentiel. Un test d’intrusion (pentest) simule une attaque réelle pour identifier les vulnérabilités exploitables avant qu’un attaquant ne le fasse. Le texte du RGPD ne contient pas le mot « pentest », mais l’article 32(1)(d) impose de tester, analyser et évaluer régulièrement l’efficacité des mesures de sécurité — et NIS2 va dans le même sens. Le pentest est aujourd’hui le moyen le plus reconnu de satisfaire cette exigence. Sa légalité repose entièrement sur une autorisation écrite préalable (convention de pentest) : sans elle, les techniques employées tombent sous le coup du droit pénal.

Les tests d’intrusion — ou pentests — consistent à simuler des attaques informatiques contre les systèmes d’une organisation afin d’identifier les failles exploitables avant un attaquant réel. Longtemps réservés aux organisations les plus matures, ils sont devenus une quasi-obligation juridique pour un nombre croissant d’acteurs sous l’effet conjugué du RGPD, de la directive NIS2 et des réglementations sectorielles. Ce guide analyse le cadre juridique applicable, les différentes méthodologies, la convention à signer avant toute intervention, et les critères de choix d’un prestataire.

Le cadre juridique des tests d’intrusion

L’obligation de tester la sécurité sous le RGPD

L’article 32(1)(d) du RGPD impose une « procédure visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement ». C’est le fondement légal le plus explicite de l’obligation de tester la sécurité — et donc, en pratique, de réaliser des tests d’intrusion.

Les obligations de l’article 32 ne sont pas satisfaites par la seule mise en place de mesures : celles-ci doivent être testées régulièrement. La CNIL a retenu, dans plusieurs procédures de sanction, l’absence de tests de sécurité réguliers comme un manquement à l’article 32, en particulier sur des systèmes traitant des données personnelles en volume ou des données sensibles. Un système exposé sur Internet qui n’a jamais fait l’objet d’un test technique constitue un angle mort difficile à justifier en cas de contrôle.

NIS2 : évaluer l’efficacité des mesures

L’article 21(2) de la directive NIS2 impose des politiques et procédures visant à évaluer l’efficacité des mesures de gestion des risques en cybersécurité. Les tests d’intrusion sont l’un des principaux moyens de satisfaire cette exigence. Pour les entités essentielles et importantes, l’autorité compétente peut exiger la réalisation de tests de sécurité dans le cadre de ses pouvoirs de supervision.

Le règlement DORA (Digital Operational Resilience Act), applicable aux entités financières depuis janvier 2025, va plus loin : il impose des tests d’intrusion fondés sur la menace (TLPT — Threat-Led Penetration Testing) pour les entités significatives. Cette approche, inspirée du cadre européen TIBER-EU développé par la BCE, préfigure probablement de futures exigences sectorielles.

Le cadre pénal : la frontière de l’autorisation

Les tests d’intrusion emploient des techniques qui, sans autorisation, constitueraient des infractions au sens des articles 323-1 et suivants du Code pénal (accès frauduleux à un système de traitement automatisé de données, maintien frauduleux, entrave au fonctionnement). La frontière entre un pentest légitime et une infraction repose entièrement sur l’autorisation préalable du propriétaire du système.

Cette autorisation doit être formalisée dans un document écrit — la « convention de pentest » ou « lettre de mission » — qui définit précisément le périmètre autorisé, les techniques admises, les dates, les contacts d’urgence et les exclusions. Sans ce document, le pentester s’expose à des poursuites pénales, quand bien même son objectif était de sécuriser le système. Ce point n’est pas théorique : c’est la première chose à verrouiller avant toute intervention.

Texte	Disposition	Ce qu’elle impose
RGPD	Art. 32(1)(d)	Tester, analyser, évaluer régulièrement l’efficacité des mesures
NIS2	Art. 21(2)	Évaluer l’efficacité des mesures de gestion des risques
DORA	TLPT	Tests fondés sur la menace pour les entités financières significatives
Code pénal	Art. 323-1 et s.	Sanctionne l’accès/maintien frauduleux — d’où la nécessité d’une autorisation

Typologie des tests d’intrusion

Selon le niveau d’information fourni

• Boîte noire (black box). Le pentester ne dispose d’aucune information préalable. Il simule un attaquant externe sans accès privilégié. Approche la plus réaliste pour l’exposition externe, mais limitée aux vulnérabilités accessibles depuis l’extérieur.
• Boîte grise (grey box). Le pentester dispose d’informations partielles (comptes utilisateurs, architecture). Il simule un attaquant ayant déjà un accès initial (compte compromis, salarié malveillant). Bon équilibre entre réalisme et couverture.
• Boîte blanche (white box). Le pentester dispose de tout : code source, architecture, comptes administrateurs. Il peut mener une revue de code et couvrir des scénarios inaccessibles autrement. Couverture maximale, réalisme moindre.

Selon la cible

Type de test	Cible	Objectif
Intrusion externe	Sites web, VPN, API, messagerie exposés	Un attaquant externe peut-il pénétrer le SI ?
Intrusion interne	Réseau interne	Évaluer la progression latérale et l’élévation de privilèges
Applicatif (web/mobile)	Applications	Injection SQL, XSS, IDOR, défauts d’authentification (OWASP Top 10)
Wi-Fi	Réseaux sans fil	Chiffrement, segmentation, points d’accès frauduleux
Ingénierie sociale	Collaborateurs	Phishing, pretexting — sensibilisation des équipes

Le test d’ingénierie sociale mérite une vigilance particulière : simuler un phishing ciblé sur des salariés soulève des questions de loyauté et d’information à traiter en amont, en lien avec la charte informatique et, le cas échéant, les représentants du personnel. Le contexte du télétravail élargit encore la surface d’attaque à tester (accès distants, terminaux personnels).

Les tests fondés sur la menace (TLPT)

Les TLPT représentent l’approche la plus avancée. Ils commencent par une phase de renseignement sur les menaces réelles ciblant l’organisation (threat intelligence), puis construisent des scénarios d’attaque réalistes fondés sur les tactiques, techniques et procédures (TTP) des groupes d’attaquants identifiés. Le référentiel TIBER-EU encadre cette approche pour le secteur financier.

Méthodologie de conduite d’un pentest

Un pentest structuré suit quatre phases.

Phase	Contenu	Livrable
1. Cadrage	Périmètre, objectifs, contraintes, règles d’engagement	Convention de pentest signée
2. Reconnaissance	OSINT, énumération, scans passifs puis actifs	Cartographie de la surface d’attaque
3. Exploitation	Exploitation des failles, enchaînement (chaining)	Journal détaillé des actions
4. Post-exploitation & rapport	Évaluation de l’impact, remédiation priorisée	Rapport de pentest

Phase 1 — Cadrage. On définit le périmètre (systèmes, adresses IP, applications), les objectifs (évaluation globale ou vérification ciblée), les contraintes (horaires, techniques exclues, systèmes critiques à ménager) et les livrables. Le RSSI est le point de contact habituel côté client.

Phase 2 — Reconnaissance. Collecte d’un maximum d’informations : découverte de sous-domaines, énumération des services, identification des technologies, recherche d’informations publiques (OSINT), analyse des fuites existantes. La phase est d’abord passive, puis active (scans de ports et de vulnérabilités).

Phase 3 — Exploitation. Le pentester exploite les vulnérabilités identifiées (CVE connues, défauts de configuration, mots de passe faibles, injection, élévation de privilèges, mouvement latéral) et documente chaque étape. L’objectif n’est pas de causer des dommages mais de démontrer l’impact potentiel d’une attaque réelle.

Phase 4 — Post-exploitation et rapport. On documente l’étendue de l’accès obtenu et l’impact sur la confidentialité, l’intégrité et la disponibilité. Le pentester doit évaluer si les données accessibles incluent des données personnelles — ce qui, en cas d’attaque réelle, déclencherait des obligations de notification de violation. Le rapport contient un résumé exécutif (direction), le détail de chaque vulnérabilité (criticité, preuve, impact), des recommandations de remédiation priorisées et une synthèse des risques. Il alimente directement l’analyse de risques.

La convention de pentest : la checklist des clauses indispensables

Aucune intervention ne doit démarrer sans convention écrite. Voici les clauses à vérifier avant signature :

• Autorisation expresse du propriétaire (ou du responsable) de chaque système ciblé.
• Périmètre précis : adresses IP, domaines, applications autorisés — et surtout la liste des systèmes exclus.
• Techniques autorisées et exclues (ex. : déni de service, ingénierie sociale, exploitation destructive interdits ou encadrés).
• Fenêtres d’intervention : dates et horaires autorisés, pour limiter l’impact sur la production.
• Règles d’engagement (rules of engagement) : conduite à tenir en cas de découverte d’une compromission réelle ou d’accès à des données sensibles.
• Contacts d’urgence joignables pendant toute la durée du test, des deux côtés.
• Responsabilités en cas de perturbation accidentelle d’un système et assurance du prestataire.
• Confidentialité : voir notre modèle de clause de confidentialité. Si le prestataire est susceptible d’accéder à des données personnelles, un encadrement au titre de l’article 28 et un statut de sous-traitant doivent être examinés.
• Propriété et sort du rapport et des données collectées (restitution, destruction).

Modèle indicatif fourni à titre documentaire — ne constitue pas un conseil juridique. À adapter à votre contexte avant usage. Version 1.0 — juillet 2026.

Intégrer les pentests dans la stratégie de sécurité

Fréquence et planification

Type de test	Fréquence recommandée
Pentest externe complet	Annuel
Pentest interne	Annuel
Test ciblé	Après chaque mise en production majeure
Scan de vulnérabilités automatisé	Mensuel à hebdomadaire

Un pentest annuel est le minimum pour soutenir une démarche conforme au RGPD et à NIS2. Les organisations à haut risque (finance, santé, infrastructures critiques) devraient envisager des tests semestriels. La checklist de conformité NIS2 intègre la planification des tests.

Articulation avec les audits

Les tests d’intrusion sont complémentaires des audits de sécurité informatique et de l’audit RGPD. L’audit évalue la conformité à un référentiel (ISO 27001, RGPD, NIS2), la documentation et les processus. Le pentest évalue l’efficacité réelle des mesures en conditions opérationnelles. Un système peut être conforme sur le papier et vulnérable dans les faits — l’inverse est également vrai. La politique de sécurité (PSSI) doit définir le cadre et la fréquence des tests.

Gestion des vulnérabilités identifiées

Le pentest n’a de valeur que si les vulnérabilités sont corrigées. Le processus de remédiation doit être formalisé : priorisation selon la criticité, attribution des actions, délais, puis retest de vérification. Les vulnérabilités critiques et hautes se corrigent en jours à semaines ; les moyennes en semaines à mois. Lorsqu’un test révèle une compromission réelle (backdoor, présence d’un attaquant), il bascule en investigation d’incident et peut déclencher la procédure de gestion d’incident et, si des données personnelles sont concernées, la notification à la CNIL sous 72 h.

Choix du prestataire et qualifications

Qualifications et certifications

En France, l’ANSSI délivre la qualification PASSI (Prestataires d’Audit de la Sécurité des Systèmes d’Information), qui atteste de la compétence technique et de la rigueur méthodologique du prestataire. Elle est obligatoire pour certains périmètres (opérateurs d’importance vitale, administrations). Les certifications individuelles des pentesters (OSCP, OSCE, GPEN, CEH) sont des indicateurs de compétence, mais ne remplacent pas la qualification PASSI, qui porte sur l’organisation dans son ensemble.

Critères de sélection

Au-delà de la qualification, évaluez : l’expérience sectorielle (un pentest en environnement industriel OT n’a rien à voir avec un test d’application web), la méthodologie documentée, des références vérifiables, l’assurance responsabilité civile professionnelle, et la capacité à produire un rapport réellement exploitable. La couverture des risques liés aux fuites de données doit être explicitement prévue au contrat. Un manquement de sécurité peut par ailleurs exposer l’organisation à des sanctions RGPD : le pentest est autant une mesure de sécurité qu’une pièce de votre dossier d’accountability.

Ce qu’un pentest ne couvre pas

Un pentest est puissant mais partiel. Il fournit une photographie de la sécurité d’un périmètre donné, à un instant donné. Il ne remplace pas :

• une analyse de risques complète (type EBIOS Risk Manager), qui raisonne sur les scénarios métier et pas seulement sur les failles techniques ;
• une revue de conformité documentaire (registre, politiques, contrats de sous-traitance), qui relève d’un audit ;
• une surveillance continue : entre deux pentests, de nouvelles vulnérabilités apparaissent, d’où l’intérêt des scans automatisés et d’un dispositif de détection.

Un système peut « passer » un pentest et rester exposé à un risque organisationnel majeur (mauvaise gestion des accès, absence de sauvegardes testées, sensibilisation insuffisante). Le pentest est une brique d’un dispositif de sécurité, pas le dispositif tout entier.

Pentest interne ou prestataire externe ?

Certaines organisations disposent d’une équipe sécurité capable de mener des tests en interne. C’est utile pour des vérifications continues, mais un regard externe reste indispensable pour trois raisons. D’abord, l’indépendance : un testeur externe n’a pas de biais sur l’architecture qu’il n’a pas conçue. Ensuite, la preuve : en cas de contrôle ou de contentieux, un rapport émis par un prestataire qualifié (idéalement PASSI) a une valeur probante supérieure à un test auto-réalisé. Enfin, la compétence spécialisée : certaines expertises (applicatif, cloud, environnements industriels OT) sont rares et coûteuses à maintenir en interne.

La bonne pratique combine les deux : des tests internes réguliers et ciblés, complétés par un pentest externe annuel confié à un prestataire indépendant. Cette articulation nourrit aussi bien votre analyse de risques que votre dossier d’accountability RGPD, la sécurité étant une obligation dont le défaut peut entraîner des sanctions. Côté suivi, un logiciel RGPD permet de centraliser les mesures de sécurité, les rapports de tests et les preuves de conformité, de façon à démontrer facilement, en cas de contrôle, que l’efficacité des mesures est bien évaluée dans la durée.

FAQ

Les tests d’intrusion sont-ils légalement obligatoires ?

Indirectement mais clairement. L’article 32(1)(d) du RGPD impose de « tester, analyser et évaluer régulièrement l’efficacité des mesures de sécurité », et les tests d’intrusion sont le moyen le plus reconnu de satisfaire cette exigence pour les systèmes techniques. NIS2 impose de même l’évaluation de l’efficacité des mesures. Le texte ne mentionne pas le mot « pentest », mais l’interprétation concordante des autorités impose de facto leur réalisation pour les systèmes exposés ou sensibles.

Quelle différence entre un pentest et un scan de vulnérabilités ?

Le scan de vulnérabilités est un processus automatisé qui identifie des failles connues (CVE) en comparant la configuration à une base de données. Rapide et peu coûteux, il ne détecte que le connu et ne valide pas l’exploitabilité. Le pentest est conduit par un expert humain qui exploite les failles, enchaîne les techniques et simule une attaque réelle. Plus long et plus coûteux, mais bien plus réaliste. Les deux sont complémentaires : scans fréquents entre deux pentests annuels.

Comment cadrer le périmètre d’un test d’intrusion ?

En fonction des risques identifiés par l’analyse de risques : les systèmes les plus critiques et exposés sont prioritaires. Le périmètre précise les adresses IP et domaines autorisés, les applications ciblées, les comptes de test (boîte grise), les systèmes exclus, les horaires autorisés et les techniques exclues. Tout est formalisé dans la convention signée par les deux parties.

À quelle fréquence réaliser un pentest ?

Au minimum une fois par an sur le périmètre global, complété après chaque évolution majeure du système d’information (nouvelle application, migration cloud). Les organisations à haut risque devraient envisager des tests semestriels. Entre deux pentests, des scans automatisés mensuels maintiennent la visibilité sur les nouvelles failles.

Un pentest peut-il déclencher une obligation RGPD ?

Oui, dans deux cas. D’une part, si l’accès obtenu porte sur des données personnelles, le rapport doit le documenter et alimenter votre analyse de risques. D’autre part, si le test révèle une compromission réelle (attaquant déjà présent, exfiltration passée), vous pouvez être en présence d’une violation de données au sens des articles 33 et 34, avec l’obligation de notifier la CNIL sous 72 heures.

Faut-il un contrat de sous-traitance avec le prestataire de pentest ?

Cela dépend de l’accès aux données. Si le prestataire est amené à traiter des données personnelles pour votre compte (par exemple en accédant à des bases en clair pendant le test), un encadrement conforme à l’article 28 et une clause de confidentialité robuste s’imposent. À défaut d’accès effectif à des données personnelles, une convention de pentest et une clause de confidentialité suffisent généralement.