Le scope de pentest est le périmètre contractualisé d'une mission de test d'intrusion — il définit précisément ce qui sera testé (IPs, domaines, applications web et API, Active Directory, cloud, mobile), comment (techniques autorisées et interdites), quand (fenêtres de test, red zones exclues), et avec quelles contraintes (plafonds de requêtes, taille maximale des charges utiles, non-destruction des données). Il s'accompagne d'un document de Rules of Engagement (ROE) signé par le client et le prestataire avant démarrage, qui constitue la base légale de l'engagement au sens des articles 323-1 à 323-7 du Code pénal français (5 ans d'emprisonnement et 150 000 € d'amende pour intrusion système sans autorisation). Trois types de scope coexistent selon l'information initiale fournie : black box (aucune information, simule attaquant externe), grey box (information partielle, compromis durée/couverture, le plus fréquent en mission commerciale), white box (accès complet, audit de profondeur). Les scopes réglementés (PASSI ANSSI pour OIV et NIS 2, TIBER-FR Banque de France pour banques systémiques, DORA TLPT applicable janvier 2025 pour entités financières critiques) imposent des référentiels méthodologiques spécifiques au-delà du cadre contractuel. Un scope bien défini est le socle de toute mission professionnelle — un scope flou produit risques juridiques, opérationnels et contractuels. Cet article détaille la définition et le rôle du scope, les 3 types (black/grey/white box), la structure d'une ROE, les exclusions standards, les aspects légaux France, la gestion du scope creep et les régimes réglementaires applicables.
1. Définition et rôle du scope de pentest
Définition opérationnelle : le scope est l'ensemble formalisé des éléments techniques soumis à test, des techniques autorisées et interdites, des fenêtres temporelles, et des contraintes opérationnelles qui encadrent une mission de pentest. Il est documenté dans deux artefacts complémentaires :
- Le contrat commercial : volet juridique avec client, prestataire, dates, prix, livrables, pénalités.
- Les Rules of Engagement (ROE) : volet opérationnel avec périmètre technique précis, techniques autorisées, contacts, procédures.
Rôle fondamental du scope
- Cadre légal : en France, toute intrusion système sans autorisation explicite est réprimée par les articles 323-1 à 323-7 du Code pénal (jusqu'à 7 ans d'emprisonnement et 300 000 € d'amende en cas d'aggravation). Le scope signé est l'autorisation formelle.
- Cadre opérationnel : il protège la production client (pas de DDoS, pas de destruction), le testeur (pas de responsabilité pénale individuelle), les tiers (pas de systèmes hors périmètre affectés).
- Cadre contractuel : il définit ce qui doit être livré (rapport), ce qui est hors scope, ce qui engage les parties.
- Cadre méthodologique : il oriente la stratégie du pentester (reconnaissance large ou profondeur ciblée, priorisation).
2. Les trois types de scope : black box, grey box, white box
| Type | Information initiale fournie | Avantages | Limites | Usage typique |
|---|---|---|---|---|
| Black box | Aucune | Simulation réaliste attaquant externe, test défense périmétrique | Durée plus longue, couverture moins exhaustive | Test périmètre externe, validation défense initiale |
| Grey box | Partielle (comptes user, VPN, doc archi) | Compromis durée/couverture, le plus fréquent | Connaissance intermédiaire limite certains bias | Mission commerciale standard, audit applicatif utilisateur |
| White box | Complète (code source, credentials admin, schémas) | Couverture maximale, efficience élevée | Moins réaliste attaquant externe | Product security review, audit pré-production, due diligence M&A |
Le choix du type dépend des objectifs
- Black box : valider la surface d'attaque externe telle qu'elle serait vue par un attaquant réel. Recommandé pour test périmètre public, Internet-facing assets.
- Grey box : couvrir le maximum de vulnérabilités par unité de temps, avec une vision réaliste post-compromission initiale. Le plus fréquent en France.
- White box : trouver le maximum de vulnérabilités possible avec temps limité. Typique de product security review d'un éditeur sur sa propre application, ou audit de pré-production.
Hybrides courants : grey box plus white box combinés (grey box au démarrage, ouverture progressive à white box si le temps manque pour couvrir le scope initial). Ou black box puis grey box (phase reconnaissance black box, puis accès fournis si pas d'intrusion externe trouvée).
3. Dimensions techniques d'un scope
Un scope de pentest couvre typiquement cinq dimensions techniques indépendantes.
| Dimension | Contenu typique | Exemple |
|---|---|---|
| Périmètre réseau | IPs, plages CIDR, domaines, sous-domaines | 10.20.0.0/16 plus *.clientexample.internal plus api.clientexample.com |
| Périmètre applicatif | Applications web, API REST/GraphQL/SOAP, applis mobiles | https://app.clientexample.com plus https://api.clientexample.com plus apps iOS et Android |
| Périmètre identitaire | Active Directory, tenant Entra ID, comptes fournis | Domaine corporate.local plus tenant client.onmicrosoft.com plus 3 comptes user standard |
| Périmètre cloud | Comptes AWS, Azure subscriptions, projets GCP | AWS account 123456789012 plus subscription Azure Prod |
| Périmètre physique et humain (si scope élargi) | Sites physiques, employés ciblables, support IT | Siège Paris plus campagne phishing sur 50 employés volontaires RH |
Chaque dimension est accompagnée d'exclusions explicites. Un scope professionnel ne repose jamais sur la bonne volonté du pentester — il liste nommément ce qui est hors scope (sous-domaines tiers, systèmes hébergés, infrastructures partagées).
4. Rules of Engagement : structure documentaire complète
Un document ROE professionnel suit une structure standard — adaptée depuis les référentiels PTES (Penetration Testing Execution Standard), NIST SP 800-115 (Technical Guide to Information Security Testing) et TIBER-EU.
Exemple de ROE type (exploitable comme template de portfolio GitHub public anonymisé pour démonstration méthodologique) :
# rules-of-engagement-pentest-v1.yml
# Document Rules of Engagement - exemple pedagogique.
# Entite fictive : ETI services B2B 1 200 salaries, mission pentest web.
engagement:
identifiant: "PT-2026-0042"
type: "Pentest application web et API grey box"
duree_prevue_jours_ouvres: 10
date_debut: "2026-06-02"
date_fin: "2026-06-13"
prestataire: "CyberPrestataire SAS (PASSI qualifie)"
client: "ClientFictif SA (DSI et RSSI)"
scope_technique:
perimetre_inclus:
applications_web:
- url: "https://app.clientfictif.example"
description: "Application metier principale, B2B"
- url: "https://portail.clientfictif.example"
description: "Portail client externe"
apis:
- url: "https://api.clientfictif.example"
description: "API REST v2 authentifiee OAuth 2.0"
documentation: "Swagger OpenAPI 3.0 fournie"
exclusions_explicites:
- "Sous-domaines legacy *.old.clientfictif.example"
- "Services SaaS tiers (Salesforce, Zendesk, Datadog)"
- "Infrastructure AWS partagee avec filiale non en scope"
comptes_fournis:
- role: "user standard"
login: "pentest-user-1@clientfictif.example"
remarque: "Compte dedie mission, a desactiver en fin de mission"
- role: "user admin metier"
login: "pentest-admin-1@clientfictif.example"
remarque: "Compte dedie, scope admin metier uniquement (pas admin SI)"
fenetres_test:
jours_autorises:
- "Lundi-Vendredi 08h00-20h00"
- "Samedi 09h00-18h00 sur demande"
red_zones_interdites:
- "Dimanches (infrastructure sauvegarde et maintenance)"
- "Veille de cloture comptable (1er-3e jour de chaque trimestre)"
notification_zones_sensibles:
- "Avant 09h00 : notification white cell prealable obligatoire"
- "Apres 19h00 : notification white cell prealable obligatoire"
techniques_autorisees:
- "Reconnaissance passive (OSINT, Shodan, Censys)"
- "Scan actif plafonne 10 requetes par seconde"
- "Enumeration sous-domaines"
- "Fuzzing endpoints API plafonne"
- "Exploitation OWASP Top 10 plus OWASP API Top 10"
- "Tests authentification et session management"
- "Tests logique applicative metier"
- "Brute force credentials avec 3 tentatives maximum par compte"
techniques_interdites:
- "DDoS ou attaques volumetriques (quelle que soit l'ampleur)"
- "Destruction ou chiffrement de donnees reelles"
- "Attaques sur systemes tiers ou SaaS hors scope"
- "Ingenierie sociale (phone, email phishing, sur place)"
- "Attaques physiques (tailgating, lock picking)"
- "Exploitation de CVE zero-day non documentee prealablement"
- "Exfiltration de donnees a caractere personnel sans anonymisation"
- "Modification de donnees en production (tests en lecture uniquement sur tables sensibles)"
contacts_crise_24_7:
white_cell_rssi:
nom: "Responsable Securite Systemes Information"
email: "rssi-whitecell@clientfictif.example"
tel: "+33 X XX XX XX XX"
lead_pentester:
nom: "Lead Pentester Prestataire"
email: "lead-pt@cyberprestataire.example"
tel: "+33 X XX XX XX XX"
astreinte_dsi_client:
email: "astreinte-dsi@clientfictif.example"
tel: "+33 X XX XX XX XX"
procedure_decouverte_incident_tiers:
- "Si detection d'intrusion active tierce non liee au pentest : STOP immediate"
- "Notification white cell RSSI sous 30 minutes maximum"
- "Conservation des evidences sans interaction supplementaire"
- "Attente instruction client avant reprise mission"
procedure_stop_criteria:
- "Detection d'impact production non prevu : STOP immediate"
- "Acces donnees personnelles massives non anonymisables : STOP"
- "Acces systemes tiers ou filiales non scope : STOP"
- "Decouverte de compromission active non liee au pentest : STOP"
obligations_postmission:
livrables_prestataire:
- "Rapport technique detaille sous 10 jours ouvres"
- "Executive summary direction sous 15 jours ouvres"
- "Retour technique RSSI plus equipes sous 30 jours"
- "Destruction evidences sous 30 jours post-remise rapport"
engagements_confidentialite:
- "NDA 3 ans, renouvelable"
- "Non-exploitation des donnees collectees"
- "Non-reutilisation des vulnerabilites dans d'autres contextes clients"
- "Destruction des comptes de mission en fin de mission"
signatures:
client: "RSSI ClientFictif SA - Signature electronique qualifiee"
prestataire: "Lead Pentester CyberPrestataire SAS - Signature electronique qualifiee"
date_signature: "2026-05-28"Ce format structuré constitue un livrable professionnel. Les prestataires PASSI, les cabinets Big Four plus Wavestone et les pentesters freelance senior suivent ce gabarit adapté aux spécificités de chaque mission.
5. Exclusions standards — les 7 points quasi-systématiques
| Exclusion | Raison |
|---|---|
| DDoS et attaques volumétriques | Destructeur pour production, inutile pour évaluation sécurité réelle |
| Destruction ou chiffrement de données réelles | Risque production, disproportionné même en simulation ransomware |
| Attaques sur systèmes tiers | Hors autorité du client, engagement contractuel impossible |
| CVE zero-day non documentée préalablement | Mise en danger non maîtrisée, risque exploit side-effects |
| Ingénierie sociale sans accord explicite | Impact humain, juridique RH, consentement nécessaire |
| Modifications intrusives non réversibles | Création comptes permanents, persistance malware, backdoors |
| Accès données personnelles sensibles non anonymisées | Risque RGPD, notification CNIL possible sous 72h |
Les exclusions peuvent varier selon régimes réglementaires (TLPT plus restrictif, red team plus élargi avec social engineering autorisé sous conditions) mais ces 7 exclusions forment le socle minimum observé en France 2026.
6. Aspects légaux France et qualifications
Cadre pénal français
| Article Code pénal | Infraction | Peine maximale |
|---|---|---|
| 323-1 | Accès ou maintien frauduleux dans un système de traitement automatisé de données | 3 ans d'emprisonnement plus 100 000 € d'amende |
| 323-2 | Entrave au fonctionnement d'un système | 5 ans plus 150 000 € |
| 323-3 | Introduction ou modification frauduleuse de données | 5 ans plus 150 000 € |
| 323-3-1 | Détention ou diffusion d'outils destinés aux infractions | 5 ans plus 150 000 € |
| 323-4 | Bande organisée (aggravation) | 10 ans plus 300 000 € |
| 323-5 à 323-7 | Complicité plus dispositions diverses | Jusqu'à 7 ans |
L'autorisation écrite du propriétaire du système est le seul moyen légal de procéder à un pentest en France. La ROE signée est cette autorisation. Aucune exception : même pour un test « bienveillant » sur demande verbale, l'autorisation écrite est requise.
Qualification PASSI ANSSI
- Prestataires d'Audit de la Sécurité des Systèmes d'Information (PASSI) : référentiel ANSSI qualifiant les prestataires pour les audits des OIV et entités régulées LPM, NIS 2.
- 5 périmètres de qualification : audit architecture, audit configuration, audit code source, test d'intrusion, audit organisationnel.
- Liste publique maintenue sur le site ANSSI. Environ 50 prestataires PASSI qualifiés en France 2026.
- Obligation de scope PASSI pour les OIV et certaines entités NIS 2 entités essentielles.
Régimes réglementaires européens structurants
- TIBER-EU (Threat Intelligence-Based Ethical Red Teaming, BCE 2018) : standard pour institutions financières systémiques européennes. TIBER-FR coordonné par Banque de France.
- DORA TLPT (Threat-Led Penetration Testing, règlement UE 2022/2554, applicable janvier 2025) : obligatoire pour entités financières critiques, supervision ACPR plus AMF en France. Cycle triennal.
- NIS 2 (directive UE 2022/2555, transposée octobre 2024) : recommande les tests intrusifs sans obligation ferme pour toutes entités ; obligation stricte pour certains secteurs (énergie, transport, santé).
7. Gestion du scope creep
Le scope creep est l'expansion progressive et non-contractuelle du périmètre pendant une mission — phénomène fréquent qui produit dépassement budgétaire, frustration client et risques juridiques.
Situations classiques générant du scope creep
| Situation | Gestion recommandée |
|---|---|
| Client demande de tester application hors scope « puisque vous êtes là » | Refuser. Proposer avenant ou mission complémentaire. |
| Vulnérabilité mène à système tiers non scope | STOP immédiate, notifier client, ne pas poursuivre |
| Temps insuffisant pour scope initial | Pointage quotidien et priorisation avec client |
| Découverte extension naturelle du périmètre (sous-domaine oublié) | Notifier, proposer avenant si demande client |
| Client demande inclusion techniques interdites | Refuser strictement, rappeler la ROE signée |
Règle absolue pour le pentester : toute extension du scope exige un avenant écrit et signé avant démarrage de l'action hors scope initial. Même sous pression commerciale ou relationnelle client, aucune exception. Le pentester junior qui cède à une demande orale hors scope engage sa responsabilité personnelle — y compris pénale si l'extension va au-delà de l'autorisation écrite.
Bonnes pratiques de pointage
- Reporting quotidien 15 minutes avec white cell client.
- Dashboard partagé des actions menées plus vulnérabilités identifiées.
- Point formel mi-parcours pour réévaluer priorités et couverture.
- Documentation des demandes hors-scope avec proposition d'avenant chiffré.
8. Types de pentest selon scope dominant
| Type de pentest | Scope technique dominant | Durée typique | Livrable dominant |
|---|---|---|---|
| Pentest application web | URLs web plus API plus backend | 5-15 jours | Rapport vulnérabilités OWASP Top 10 plus business logic |
| Pentest infrastructure externe | IPs internet-facing, services exposés | 5-10 jours | Cartographie surface d'attaque plus exploitations |
| Pentest infrastructure interne | LAN, DMZ, segments internes | 10-20 jours | Accès Domain Admin ou exfiltration flags |
| Pentest Active Directory | Forêt AD, comptes, GPO, AD CS | 8-15 jours | Chemins d'attaque BloodHound plus remédiations |
| Pentest mobile iOS et Android | Applications, API backend, local storage | 8-15 jours | OWASP MASTG findings plus reverse engineering |
| Pentest cloud AWS/Azure/GCP | IAM, services cloud natifs, IaC | 8-15 jours | Misconfigurations plus IAM attack paths |
| Red team engagement | Scope large simulé attaquant réel | 4-12 semaines | Flags atteints plus mapping MITRE ATT&CK |
| TIBER-FR / DORA TLPT | Scope dédié finance, red team étendue | 8-14 semaines | Rapport TIBER aligné BCE plus supervision régulateur |
| Bug bounty (pas un pentest au sens strict) | Scope public déclaré par programme | Continu | Reports individuels par vulnérabilité |
9. Pour aller plus loin
- Devenir pentester sans expérience : trajectoire et certifications détaillées.
- Les étapes pour devenir pentester : parcours complet.
- Roadmap pentest : roadmap technique structurée.
- Roadmap pentest web : spécialisation applicative.
- Salaire pentester : fourchettes par palier France 2026.
- TJM pentester freelance : tarification freelance.
Points clés à retenir
- Le scope définit le périmètre contractualisé d'une mission pentest : quoi, comment, quand, avec quelles contraintes.
- Trois types : black box (aucune info), grey box (partielle, le plus fréquent), white box (complète).
- Rules of Engagement (ROE) document obligatoire avec scope technique, fenêtres, techniques autorisées/interdites, contacts crise, stop criteria, obligations post-mission.
- 7 exclusions standards : DDoS, destruction données, systèmes tiers, zero-day non documentée, ingénierie sociale, modifications non réversibles, données personnelles.
- Cadre pénal France : articles 323-1 à 323-7 Code pénal, jusqu'à 7 ans plus 300 000 €. Autorisation écrite ROE obligatoire.
- Qualification PASSI ANSSI pour OIV et NIS 2, 5 périmètres (architecture, config, code source, intrusion, organisationnel).
- Régimes européens : TIBER-FR (Banque de France), DORA TLPT (applicable janvier 2025, cycle triennal).
- Scope creep : toute extension nécessite avenant écrit signé. Pointage quotidien 15 minutes = prévention principale.
- Types de pentest : web, infra externe/interne, AD, mobile, cloud, red team engagement, TIBER/TLPT, bug bounty (hors pentest strict).
Le bootcamp DevSecOps Zeroday Cyber Academy inclut une formation spécifique à la rédaction de ROE professionnelle, à la lecture critique de scopes clients, à la gestion du scope creep en mission, et à la qualification PASSI ANSSI pour les candidats visant un poste pentester en cabinet spécialisé.
