Enseigner le pentest : retour d'expérience terrain

Comprendre avant d'attaquer : un défi pédagogique

Former des étudiants au pentest n'est pas une mince affaire.
Entre la technicité des outils, l'éthique indispensable à toute démarche d'intrusion et la diversité des profils en école, l'équilibre est fragile.
Beaucoup d'enseignants constatent que leurs étudiants aiment "casser"… mais peinent à comprendre pourquoi et comment le faire dans un cadre professionnel.

C'est précisément ce que Julien, consultant en cybersécurité et teacher chez Cyber Teachers, a vécu lorsqu'il a commencé à enseigner le pentest dans une école d'ingénieurs.

"Les étudiants arrivaient avec l'image du hacker de film. Mon rôle, c'était de leur faire comprendre que le vrai pentest, c'est de la rigueur, de la méthode et surtout de la responsabilité."

Ce qui suit est son retour d'expérience : ce qui a fonctionné, ce qui a échoué, et ce que je referais différemment dès la première heure de cours.

La toute première séance : poser le cadre avant les outils

La tentation, en arrivant, c'est de lancer Kali et de montrer un exploit qui marche. C'est l'erreur la plus coûteuse. Une fois qu'un étudiant a vu une faille tomber, plus personne n'écoute la méthodologie.

Ma première séance ne contient donc aucun exploit. Elle sert à trois choses :

• Cadrer l'éthique et le droit. On parle clairement de ce qui distingue un test autorisé d'une intrusion illégale. Le message tient en une phrase : on n'attaque que ce qu'on a le droit écrit d'attaquer.
• Signer les "règles d'engagement". Chaque étudiant signe un document court qui définit le périmètre autorisé (les seules cibles du lab), les horaires, les actions interdites (pas de déni de service, pas d'exfiltration réelle) et l'obligation de tout documenter. C'est exactement le réflexe attendu d'un pentesteur en mission.
• Donner la méthode avant la technique. On dessine au tableau les quatre temps d'un test : reconnaissance → énumération → exploitation → documentation. Tout le semestre s'accroche à ce squelette.

"Le jour où j'ai fait signer les règles d'engagement avant de distribuer les VM, le ton du cours a changé. Les étudiants ont compris que ce n'était pas un jeu."

Le lab : local, jetable, hors ligne

Le choix du lab détermine la moitié de la réussite du module. Mon principe : un environnement local, isolé et reproductible, que l'étudiant peut casser puis réinitialiser sans conséquence.

Concrètement, voici la base que je distribue.

Tout tourne en machines virtuelles, en réseau host-only, sans accès au réseau de l'établissement. Cette isolation n'est pas un détail technique : c'est le prolongement concret des règles d'engagement. Pour le montage pas à pas, je renvoie d'ailleurs mes étudiants vers ce guide dédié pour créer un lab pentest gratuit.

Ce qui a échoué : au premier semestre, j'avais laissé chacun installer son propre environnement. Résultat, on a perdu deux séances à déboguer des problèmes de VirtualBox et de cartes réseau. Désormais je fournis une image préconfigurée et la première manipulation se fait sur un snapshot identique pour tous.

Le déroulé : un module pentest séance par séance

Plutôt qu'un empilement de théorie, je structure le module comme une mission qui se construit. Voici la progression que j'utilise aujourd'hui (déclinable en cinq jours pour un format intensif, comme détaillé dans structurer un module pentest en 5 jours).

1. Séance 1 — Cadre, éthique, règles d'engagement. Aucun outil offensif. Méthodologie au tableau et signature du scope.
2. Séance 2 — Reconnaissance et énumération. Prise en main de nmap sur Metasploitable : balayage de ports, détection de versions, cartographie des services. On insiste sur la prise de notes systématique.
3. Séance 3 — Web, partie 1. DVWA en mode "low" : on observe l'injection SQL et le XSS manuellement, avant tout outil automatique.
4. Séance 4 — Web, partie 2. Introduction de Burp Suite comme proxy d'interception sur Juice Shop. Manipulation de requêtes, compréhension des en-têtes et des cookies.
5. Séance 5 — Exploitation système. Un premier exploit guidé sur un service Metasploitable, replacé dans la chaîne reconnaissance → exploitation.
6. Séance 6 — Rédaction du rapport. On transforme les notes en livrable : findings, criticité, preuves, remédiations.
7. Séance 7 — Soutenance et débrief. Chaque groupe présente, les autres jouent le rôle du client.

Cette montée en charge respecte une règle simple : on n'introduit jamais un outil avant d'avoir fait la chose à la main une fois. Burp arrive après l'interception manuelle, Metasploit après l'exploitation guidée. L'outil doit éclairer une compréhension, pas la remplacer.

Les erreurs récurrentes des étudiants (et comment les traiter)

Au fil des promotions, les mêmes blocages reviennent. Les anticiper fait gagner un temps considérable.

• Sauter la reconnaissance. Le réflexe est de lancer un exploit tout de suite. Le remède : refuser toute tentative d'exploitation tant que la cartographie nmap n'est pas écrite. Pas de notes, pas d'attaque.
• Tout automatiser, ne rien comprendre. Un scanner crache 200 lignes, l'étudiant en conclut "c'est vulnérable" sans savoir pourquoi. Le remède : exiger qu'il rejoue le finding à la main avant de l'inscrire au rapport.
• Confondre "ça plante" et "c'est exploité". Un service qui tombe n'est pas une preuve d'intrusion. On apprend à distinguer un bug d'une faille réellement exploitable.
• Oublier la preuve. Une faille non documentée, avec capture et requête à l'appui, n'existe pas pour un client. Chaque finding doit être reproductible par un tiers.
• Négliger le périmètre. Un étudiant motivé veut "tester aussi le site de l'école". C'est le moment pédagogique le plus important : on revient au document signé et on explique pourquoi cette curiosité, hors cadre, est une faute professionnelle.

"Quand un étudiant me demande s'il peut scanner une cible hors lab, je ne le gronde pas. Je lui ressors les règles d'engagement. La leçon rentre beaucoup mieux."

Gérer l'hétérogénéité des niveaux

En école, une même promotion mélange des étudiants qui montent déjà des labs chez eux et d'autres qui découvrent la ligne de commande. Ignorer cet écart casse le module : les premiers s'ennuient, les seconds décrochent.

Trois leviers m'ont permis de tenir les deux extrémités :

• Le binôme déséquilibré assumé. J'associe volontairement un profil avancé et un débutant, avec une consigne claire : l'avancé n'a pas le droit de taper la commande à la place de l'autre, seulement de l'expliquer. Faire verbaliser consolide ses propres acquis.
• Les objectifs bonus. Chaque TP a un socle obligatoire et une ou deux extensions facultatives (un niveau "high" de DVWA, une chaîne d'exploitation plus longue). Les rapides ont de quoi creuser sans attendre la classe.
• Le pas de côté individuel. Pour les débutants en difficulté, je préfère cinq minutes de reprise sur la reconnaissance plutôt que d'avancer. Un étudiant qui ne comprend pas nmap ne comprendra rien à l'exploitation qui suit.

Ce qui a échoué : vouloir un rythme unique pour tout le monde. La première année, j'alignais la classe sur le niveau médian ; j'ai perdu les deux tiers des extrêmes. La différenciation par objectifs bonus a été le correctif le plus rentable.

Ce qui marche vraiment en classe

Plusieurs formats ressortent systématiquement dans les retours des étudiants.

• Les démonstrations live. Voir le formateur dérouler une attaque en temps réel, hésiter, se tromper, corriger, vaut tous les slides. C'est le moment où la méthode devient vivante.
• Les CTF courts. Un défi de 45 minutes en fin de séance fixe les acquis et entretient la motivation sans épuiser l'attention.
• Le travail en binôme attaquant/défenseur. Faire défendre une cible par un groupe pendant qu'un autre l'attaque ancre l'idée que le pentest sert à protéger, pas à détruire.
• Le rattachement au métier. Relier chaque exercice à une réalité de mission (et au parcours de certification, type OSCP) donne du sens à l'effort.

Ce qui a échoué : les longues séquences de théorie OWASP sans manipulation. Présenter le Top 10 d'affilée, sans toucher au clavier, fait décrocher la salle en vingt minutes. J'ai redécoupé : chaque catégorie OWASP est désormais introduite par une démonstration de trois minutes, puis manipulée.

Le débrief : le vrai moment où l'on apprend

La séance ne s'arrête pas au dernier exploit. Le moment qui fait progresser, c'est le débrief collectif de fin de TP — souvent dix minutes, parfois davantage.

Les erreurs n'y sont pas sanctionnées, elles sont disséquées. "Pourquoi ton scan n'a-t-il rien trouvé ? Qu'as-tu oublié dans ta reconnaissance ?" Ce questionnement, fait à voix haute devant le groupe, vaut plus qu'un corrigé distribué. Chaque échec d'un binôme devient une leçon partagée, et les étudiants intègrent vite que se tromper proprement fait partie du métier.

J'y ajoute systématiquement un retour terrain : comment ce type d'oubli se traduit en mission réelle, ce qu'il coûte à un client, comment un auditeur expérimenté l'aurait évité. Ce pont entre l'exercice et la réalité professionnelle est ce que les étudiants citent le plus dans leurs retours de fin de semestre.

Évaluer sur le rapport, pas sur un QCM

Le pentest ne se note pas avec des cases à cocher. Un QCM mesure la mémoire ; le métier demande du raisonnement et de la communication écrite. J'évalue donc sur le livrable.

Chaque étudiant rend un rapport d'audit structuré comme en mission :

• Contexte et scope rappelant le périmètre autorisé ;
• Synthèse pour décideur, en quelques lignes lisibles par un non-technicien ;
• Findings priorisés par criticité, avec preuve reproductible ;
• Remédiations concrètes pour chaque vulnérabilité ;
• Méthodologie retraçant la démarche, y compris les pistes qui n'ont rien donné.

Ce qui pèse dans la note, ce n'est pas le nombre de failles trouvées, mais la qualité du raisonnement et la clarté de la communication. Un étudiant qui documente proprement deux vulnérabilités bien comprises vaut mieux que celui qui en empile dix sans preuve. La soutenance finale, où le groupe présente face à un "client", complète l'évaluation sur la posture et la pédagogie.

L'approche Cyber Teachers : transmettre l'expérience du terrain

Chez Cyber Teachers, nos enseignants ne sont pas seulement des formateurs : ce sont des professionnels actifs.
Ils ont audité, testé, sécurisé des systèmes réels — et savent transformer cette expérience en apprentissage vivant.

Dans le cas de Julien, cette approche se traduit par :

• des labs progressifs inspirés de missions réelles (tests web, Wi-Fi, Active Directory) ;
• une évaluation continue basée sur la démarche, pas uniquement le résultat ;
• des retours d'expérience concrets : "voici comment, en mission, ce type de fail a coûté une semaine d'audit".

Les étudiants en sortent plus autonomes, plus rigoureux, et surtout plus conscients de l'impact de leur futur métier. C'est aussi l'esprit de notre cours pentest : du concret, applicable dès le lendemain.

Enseigner le pentest, c'est transmettre une culture

En fin de semestre, Julien remarque un changement tangible :

"Au début, ils cherchaient la faille. À la fin, ils cherchaient à comprendre le système."

C'est là tout l'enjeu de l'enseignement du pentest : former des professionnels curieux, responsables et capables de raisonner.
Pas seulement des exécutants d'outils.

Et c'est précisément cette vision que Cyber Teachers porte dans chaque partenariat avec les écoles : faire de la cybersécurité un savoir vivant, ancré dans la réalité du terrain et la pédagogie active.

Vous cherchez un enseignant pour initier vos étudiants au pentest ?

Découvrez les profils de nos teachers spécialisés en cybersécurité offensive sur Cyber Teachers et construisez avec eux un programme concret, motivant et aligné avec les enjeux du terrain.