Comment structurer un module pentest en 5 jours (plan pédagogique + labs)

Le pentest en formation : un exercice d'équilibre pédagogique

Concevoir un module de pentest condensé sur cinq jours est l'un des défis pédagogiques les plus exigeants en cybersécurité. Il faut couvrir suffisamment de théorie pour que les étudiants comprennent ce qu'ils font, tout en leur laissant assez de temps de pratique sur des environnements réalistes. Trop de cours magistraux et les étudiants décrochent. Trop de labs sans cadre et ils se dispersent — ou, pire, sortent du périmètre autorisé.

Ce guide propose une structure éprouvée, pensée pour des étudiants de niveau intermédiaire en cybersécurité, avec des bases solides en réseaux et en systèmes. L'objectif : qu'en cinq jours, chaque étudiant soit capable de mener un audit de sécurité simplifié de bout en bout — de la lettre de mission au rapport de remédiation — dans un cadre légal et éthique maîtrisé.

Prérequis : définir le public avant d'écrire le syllabus

Un module pentest de 5 jours n'est pas adapté à tous les publics. Définir les prérequis avec précision évite deux écueils symétriques : les étudiants qui décrochent dès le deuxième jour faute de bases, et les experts qui s'ennuient sur des fondamentaux qu'ils maîtrisent depuis des années.

Tableau des prérequis par public cible

Test de diagnostic recommandé : envoyer un questionnaire de 5 questions ouvertes avant le premier jour (pas un QCM). Demander aux participants de décrire leur expérience avec Wireshark, de citer deux protocoles de la couche transport, et d'expliquer ce qu'est un shell inversé. Les réponses calibrent le niveau réel bien mieux que l'intitulé de la formation.

Ce que le formateur doit avoir prêt avant J1

• Les VMs de lab déployées et testées depuis un poste étudiant représentatif (pas depuis sa propre machine)
• La charte informatique / lettre d'autorisation signée par la direction ou le responsable pédagogique
• Le document de définition de périmètre : quelles machines, quel sous-réseau, quels outils autorisés
• Un plan B pour chaque lab (scénario dégradé si un composant ne fonctionne pas)

Cadre légal et éthique : une première séance non négociable

Le cadre légal doit être enseigné avant le premier lab, pas glissé dans une slide de fin de journée. En France, l'article 323-1 du Code pénal punit l'accès frauduleux à un système informatique. Un étudiant qui, enthousiasmé par le cours, tente de scanner le réseau de l'école ou de tester une faille sur un site réel commet une infraction — et son formateur peut être tenu pour responsable si le cadre légal n'a pas été clairement établi.

Points essentiels à couvrir en 45 minutes :

1. La lettre de mission / périmètre d'autorisation : tout test d'intrusion légal commence par un document signé qui définit exactement ce qui est autorisé. Le formateur le présente comme une pratique professionnelle, pas comme une contrainte administrative.

2. Le périmètre du lab : les étudiants doivent savoir exactement quelles IPs, quels sous-réseaux, et quels services sont dans le périmètre. Tout ce qui est hors périmètre est interdit — même si la machine semble vulnérable.

3. La déontologie du pentesteur : confidentialité, non-divulgation des failles sans accord, intégrité des preuves. Ce sont des compétences professionnelles que les employeurs vérifient.

4. La PTES et l'OWASP Testing Guide : deux méthodologies de référence qui structurent un pentest professionnel. Les étudiants doivent savoir qu'une démarche rigoureuse n'est pas optionnelle.

Plan jour par jour : le module en détail

Jour 1 — Fondamentaux, cadre légal et prise en main de l'environnement

Matin — Contexte, méthodologie et éthique (3h)

La première demi-journée pose les bases. Avant de toucher un terminal, les étudiants comprennent pourquoi on fait du pentest, pour qui, et dans quel cadre légal précis.

Points essentiels :

• La différence entre pentest, red team, bug bounty et audit de sécurité
• Les méthodologies reconnues : OWASP Testing Guide, PTES, OSSTMM
• Le cadre juridique français (art. 323-1 du Code pénal) et la notion de périmètre autorisé
• La déontologie : confidentialité, chaîne de preuves, non-divulgation
• Présentation de la certification OSCP comme repère de niveau et d'employabilité

Après-midi — Prise en main de l'environnement de lab (3h)

Les étudiants configurent leur poste de travail et valident chaque composant :

Check-list de démarrage J1 :

□ Distribution Kali ou Parrot installée et démarrée
□ Connexion au réseau lab validée (ping vers la machine cible)
□ Nmap installé et fonctionnel (nmap -sV <IP-cible> → résultats cohérents)
□ Burp Suite ouvert et proxy configuré dans le navigateur
□ Wireshark lancé et capture réseau active
□ Accès à la plateforme CTF ou lab Jira/GitLab pour les livrables

Un premier exercice encadré — scanner un réseau lab et identifier les services exposés — permet de valider que tout le monde est opérationnel et de repérer les participants qui ont besoin d'accompagnement supplémentaire.

Jour 2 — Reconnaissance et énumération

Matin — Reconnaissance passive et active (3h)

La reconnaissance est la phase la plus sous-estimée par les apprenants. Pourtant, la qualité de la reconnaissance conditionne directement la pertinence de l'exploitation.

Reconnaissance passive :

• OSINT : Google Dorks, Shodan, theHarvester, Recon-ng
• DNS : dig, nslookup, transferts de zone (zone transfer)
• Whois et RDAP
• Wayback Machine et cache

Reconnaissance active :

• Scan de ports : nmap -sS -sV -O --script default <cible>
• Fingerprinting des services (bannières, headers HTTP, versions)
• Énumération des sous-domaines (Gobuster, ffuf en mode DNS)
• Détection de CMS (WPScan, whatweb)

Outil phare : Nmap

Nmap est le premier outil à maîtriser. Insistez sur la compréhension des résultats, pas seulement l'exécution de la commande. Un étudiant qui sait lire un output Nmap et en déduire les vecteurs d'attaque potentiels a compris l'essentiel.

Après-midi — Lab de reconnaissance (3h)

Les étudiants cartographient un réseau lab comprenant 3 à 5 machines. Livrable attendu : un rapport de reconnaissance structuré (1 page par machine) avec :

• IP, OS probable, services et versions exposés
• Surfaces d'attaque potentielles identifiées
• Prochaine étape d'exploitation envisagée

Ce rapport est le premier livrable noté. Il développe autant les compétences techniques que la rigueur documentaire, essentielle dans le métier.

Jour 3 — Exploitation web et système

Matin — Vulnérabilités et techniques d'exploitation (3h)

C'est le jour que les apprenants attendent. Mais avant de lancer un exploit, la logique sous-jacente doit être comprise :

Exploitation web :

• Injection SQL : SQLmap pour la confirmation, explication manuelle pour la compréhension
• XSS stocké et réfléchi : impact sur l'authentification, vol de session
• CSRF et clickjacking : scénarios réalistes
• Failles d'authentification : password spraying, credential stuffing, tokens JWT faibles
• Enumération de fichiers et répertoires (Gobuster, ffuf)

Exploitation système :

• Services mal configurés : FTP anonyme, SMB null session, SSH avec credentials par défaut
• Exploitation de vulnérabilités connues avec Metasploit (modules exploit/, auxiliary/)
• Élévation de privilèges Linux : SUID mal configuré, cron jobs, variables d'environnement

Message pédagogique clé : un exploit sans compréhension n'est qu'un copier-coller. L'objectif est que l'étudiant sache expliquer chaque étape — pourquoi telle vulnérabilité existe, comment elle est exploitée, et pourquoi le système y est vulnérable.

Après-midi — Lab d'exploitation guidé (3h)

Un environnement vulnérable (DVWA, Metasploitable, ou machines personnalisées) est mis à disposition. Les étudiants travaillent en binôme sur des scénarios progressifs :

Le formateur circule, guide, et organise des micro-debriefs réguliers pour mutualiser les découvertes et corriger les erreurs de raisonnement.

Jour 4 — Post-exploitation et rédaction du rapport

Matin — Post-exploitation et persistance (3h)

Cette phase est souvent négligée dans les formations courtes, mais elle est indispensable pour comprendre la réalité du terrain et ce qu'un attaquant peut faire une fois qu'il a un accès initial :

• Collecte d'informations post-compromission : fichiers sensibles, hash de mots de passe (SAM, /etc/shadow), clés SSH
• Mouvement latéral : pass-the-hash, pass-the-ticket en environnement Active Directory simplifié
• Persistance : création d'un utilisateur backdoor, tâche planifiée, service malveillant
• Nettoyage des traces : logs à effacer, artefacts à supprimer (et pourquoi c'est documenté dans un vrai pentest)

Ces notions donnent aux étudiants une vision complète de la chaîne d'attaque — et comprendre l'attaquant est indispensable pour concevoir une réponse à incident efficace.

Après-midi — Rédaction du rapport d'audit (3h)

Le rapport est le livrable final du pentesteur. C'est lui que le client lit — et qui justifie la mission. Les étudiants apprennent à structurer :

Structure d'un rapport professionnel :

Le rapport est aussi important que la phase technique. Un pentest sans rapport exploitable n'a aucune valeur professionnelle : les failles restent non corrigées et le client ne comprend pas l'impact.

Jour 5 — Challenge final et évaluation

Matin — CTF ou audit simulé (3h)

La dernière journée commence par un exercice intégrateur. Deux formats fonctionnent bien :

Option A — CTF (Capture The Flag) : un ensemble de challenges couvrant les compétences vues pendant la semaine. Les étudiants progressent individuellement ou en équipe à travers des épreuves de difficulté croissante. Ce format développe l'autonomie et la débrouillardise.

Option B — Audit simulé : les étudiants reçoivent une lettre de mission fictive et doivent auditer un environnement inconnu en temps limité. Ce format est plus proche de la réalité professionnelle et évalue mieux la démarche méthodologique.

Le format audit simulé est recommandé pour les formations orientées insertion professionnelle ; le CTF pour les groupes où la motivation et la compétition saine peuvent jouer un rôle pédagogique positif.

Après-midi — Restitution et évaluation (3h)

Chaque binôme ou équipe présente ses résultats en 15 minutes : méthodologie suivie, vulnérabilités trouvées, rapport produit. L'évaluation porte sur :

• La rigueur de la démarche (pas seulement le nombre de failles trouvées)
• La qualité du rapport (clarté, preuves, recommandations)
• La pertinence des recommandations (priorisées, réalistes, actionnables)
• La posture professionnelle lors de la restitution (communication du risque)

Un débrief collectif clôture le module : ce qui a bien fonctionné, les difficultés rencontrées, les pistes d'approfondissement vers des certifications comme l'OSCP, le OSCP ou le CEH.

Choix d'infrastructure lab : on-prem vs cloud pédagogique

Comparatif des options

Recommandation pour un premier module : VMs locales pour les étudiants (Kali + Metasploitable + DVWA sur VirtualBox) avec un réseau host-only. Simple, gratuit, parfaitement isolé. Ajouter TryHackMe comme complément asynchrone pour les exercices entre les séances.

La règle des 48 heures

Testez l'intégralité du lab depuis un poste étudiant représentatif (pas votre propre machine) 48 heures avant le premier cours. Vérifiez :

• Chaque machine cible est accessible depuis le sous-réseau étudiant
• Chaque outil listé dans le TP est installé à la bonne version
• Les droits suffisants sont disponibles (certains outils requièrent sudo)
• Un snapshot "état initial" existe pour repartir proprement entre les groupes

Conseils pratiques pour le formateur

Adapter le rythme. Certains groupes avancent vite, d'autres ont besoin de plus de temps sur les fondamentaux. Prévoyez des exercices bonus pour les plus rapides : des machines VulnHub ou des challenges HackTheBox supplémentaires maintiennent l'engagement des profils avancés pendant que vous accompagnez les autres.

Documenter les erreurs fréquentes. Tenez un journal des difficultés rencontrées par vos étudiants d'une session à l'autre. Les mêmes blocages reviennent (Metasploit qui échoue à cause d'une version de payload, Burp Suite mal configuré, réseau lab mal isolé). Anticiper ces points gagner une à deux heures sur le module.

Varier les formats. Alternez cours magistral, démonstrations en direct (demo live, y compris les échecs — ils sont pédagogiques), travaux en binôme et restitutions orales. La pédagogie active est la clé de l'engagement sur des modules intensifs.

Nommer le faux positif. En pentest, les étudiants découvrent vite que tous les outils donnent parfois de faux résultats. Enseigner à valider manuellement un résultat d'outil avant de l'intégrer dans un rapport est l'une des leçons les plus importantes du module.

Ce qu'il faut retenir

• Définir les prérequis précis avant d'écrire le syllabus : un test de diagnostic avant J1 évite les décalages de niveau qui plombent la dynamique du groupe.
• Le cadre légal est incontournable en première séance : périmètre signé, déontologie du pentesteur, loi française (art. 323-1). Ce n'est pas facultatif.
• La structure J1-J5 (méthodologie → reconnaissance → exploitation → post-exploitation → évaluation) reproduit le cycle professionnel réel : chaque journée a un livrable concret.
• Tester le lab 48h avant depuis un poste étudiant : les problèmes de lab en J1 sont la cause la plus fréquente d'un module raté.
• Le rapport d'audit est aussi important que la phase technique : enseigner à rédiger un résumé exécutif lisible par un non-technique et des recommandations priorisées est une compétence différenciante.

Vous cherchez un intervenant spécialisé en pentest pour animer ce module dans votre école ou bootcamp ?
Découvrez les profils de formateurs sélectionnés sur Cyber Teachers — chaque profil inclut les thèmes, le niveau de public et les références terrain.