Brief type pour école d'ingénieurs : cadrer un module cybersécurité en une page

Pourquoi le brief est le vrai livrable du recrutement

Recruter un intervenant en cybersécurité sans brief, c'est comme commander une infrastructure cloud sans spécifications. Le formateur livre ce qu'il sait faire — et c'est souvent excellent — mais pas nécessairement ce dont vos étudiants ont besoin dans le contexte précis de votre programme.

Un brief de module est un document d'une page (deux maximum) qui précise le contexte, les objectifs mesurables, le format, l'infrastructure disponible et les critères d'évaluation attendus. Il sert de référentiel commun entre le commanditaire (responsable de mention, équipe pédagogique) et l'intervenant, avant même que la première heure de cours soit planifiée.

Les équipes qui utilisent des briefs structurés signalent moins d'allers-retours sur les contenus, moins de surprises le jour J (lab pas configuré, niveau trop élevé, évaluation inattendue) et des retours étudiants plus homogènes. Ce n'est pas une formalité administrative : c'est l'acte fondateur d'une collaboration pédagogique réussie.

Contexte, public, prérequis et objectifs mesurables

C'est la section la plus importante et la plus souvent bâclée. Elle doit répondre à quatre questions en moins de dix lignes :

Contexte : quelle est la place de ce module dans la maquette globale ? Est-ce un cours obligatoire ou optionnel ? En quelle année ? Dans quelle spécialité ?

Exemple : Module obligatoire de 4e année d'école d'ingénieurs généraliste, parcours Systèmes et Réseaux. Intervient après un module de sécurité réseau de 18h et avant le projet de fin d'études.

Public : combien d'étudiants, quel profil (généraliste, spécialisé, alternants), quelle expérience pratique antérieure ?

Exemple : 24 étudiants, dont 8 en alternance dans des DSI. Niveau hétérogène : la moitié a pratiqué Wireshark, un tiers a monté une VM sous VMware.

Prérequis : ce que l'intervenant peut considérer comme acquis. Être explicite évite les redites et les trous.

Exemple : Maîtrise du modèle OSI, TCP/IP, notions de base sur les pare-feux. Pas de prérequis en sécurité offensive.

Objectifs mesurables : au format "l'étudiant sera capable de…", formulés de façon observable. Éviter les formulations floues ("comprendre la cybersécurité").

Exemple : À l'issue du module, l'étudiant sera capable de (1) réaliser un scan de reconnaissance sur un réseau de test avec Nmap et d'interpréter les résultats, (2) exploiter une vulnérabilité de type injection SQL sur une application vulnérable de lab, (3) produire un rapport de test d'intrusion structuré en deux pages.

Format, nombre d'heures, livrables attendus

Cette section précise ce que l'intervenant doit produire, pas seulement ce qu'il doit enseigner.

Livrables systématiques à demander :

• Syllabus détaillé par séance (avec objectifs et durée de chaque bloc) — avant le début du module.
• Supports de cours au format éditable (PowerPoint, Reveal.js, PDF + sources) — à la fin du module, avec cession de licence d'utilisation interne.
• Grille d'évaluation ou sujet de TP noté — au moins une semaine avant la séance d'évaluation.
• Rapport de fin de module (1 page) — difficultés rencontrées, suggestions pour la prochaine promotion.

Infra lab, données fictives et contraintes RGPD

C'est la section que les équipes pédagogiques oublient le plus souvent de renseigner — et qui génère le plus de problèmes le jour J.

Un intervenant en cours de pentest ou en sécurité offensive a besoin de savoir exactement ce qu'il peut faire, avec quoi, et dans quel périmètre. Préciser :

Infrastructure disponible :

• Machines physiques ou VMs ? Nombre ? Système d'exploitation ?
• Réseau isolé ou accès Internet ? VPN ? Qui configure le lab avant la séance ?
• Plateformes existantes (TryHackMe Education, Hack The Box Academy, infra interne) ?
• Droits administrateurs pour les étudiants : oui ou non ?

Données utilisées en TP :

• Toutes les données manipulées en TP doivent être fictives ou anonymisées. Préciser explicitement qu'aucune donnée réelle d'entreprise ne doit être utilisée, même à titre d'exemple.
• Si l'intervenant amène ses propres scénarios (captures réseau, logs, etc.), demander qu'ils soient vérifiés avant le cours.

Contraintes RGPD :

• Les enregistrements de séance (vidéo, audio) nécessitent le consentement des étudiants. Préciser si la captation est autorisée ou interdite.
• Les fichiers de TP contenant des données d'exercice (même fictives) ne doivent pas être hébergés sur des services cloud hors contrat École.
• Si des outils d'IA (assistants de code, chatbots) sont utilisés en TP, préciser la politique de l'école sur le transfert de données.

Périmètre légal des TP offensifs :

• Toute manipulation sur un système sans autorisation est illégale (art. 323-1 du Code pénal). Le brief doit mentionner explicitement que les TP se déroulent uniquement sur des systèmes appartenant à l'école ou mis à disposition avec autorisation écrite.
• L'intervenant doit vérifier que les étudiants ont signé une charte d'utilisation informatique.

Évaluation et critères de succès

L'évaluation est souvent le point le moins cadré dans les briefs initiaux. Pourtant, elle conditionne la cohérence pédagogique du module.

Format d'évaluation à préciser :

Critères de succès du module (à définir avec la direction des études) :

• Taux de réussite attendu (cohérent avec le niveau des prérequis et la difficulté des objectifs).
• Taux de satisfaction étudiants cible (enquête à chaud post-module).
• Compétences mesurables à l'issue (cf. objectifs de la section 1).

Pour un module de pentest de niveau avancé, un taux de réussite de 70-80 % avec une majorité d'étudiants atteignant les objectifs de base est réaliste. Éviter de calibrer l'évaluation sur les 20 % les plus avancés de la promo.

Planning des points de contact et validation

Un module bien cadré implique trois points de contact entre le commanditaire et l'intervenant :

J-21 (trois semaines avant le premier cours) :

• Brief validé, syllabus remis par l'intervenant.
• Accès lab configuré et testé par l'intervenant ou l'admin système de l'école.
• Matériel étudiant vérifié (VMs installées, VPN testé, droits validés).

J-7 (une semaine avant) :

• Validation finale du syllabus et des supports par le référent pédagogique.
• Confirmation de la salle, du vidéoprojecteur, des accès réseau.
• Envoi aux étudiants des prérequis techniques à installer (si applicable).

J+7 (une semaine après le dernier cours) :

• Remise des supports finaux par l'intervenant.
• Collecte des retours étudiants (formulaire court, 5 questions).
• Réunion de bilan de 30 minutes : ce qui a fonctionné, ce à adapter pour la prochaine promo.

Le brief en une page : modèle complet

Voici le modèle à utiliser directement. Il tient sur une page A4 en police 10.

MODULE CYBERSÉCURITÉ — BRIEF PÉDAGOGIQUE [Nom de l'école] — [Parcours] — [Année académique]

CONTEXTE Module de __ heures, obligatoire / optionnel, [Année]. Intervient après [module précédent] et avant [module suivant].

PUBLIC __ étudiants, [profil : généraliste / spécialisé / alternants]. Niveau technique : [description courte]. Prérequis validés : [liste].

OBJECTIFS (l'étudiant sera capable de…)

1. [Objectif mesurable 1]
2. [Objectif mesurable 2]
3. [Objectif mesurable 3]

FORMAT __ séances × __ h. Présentiel / distanciel / hybride. Salle : [lieu]. Lab : [description infrastructure].

LIVRABLES ATTENDUS DE L'INTERVENANT

• Syllabus détaillé (J-21)
• Supports au format éditable (fin de module)
• Sujet et grille d'évaluation (J-7 avant séance notée)
• Rapport de fin de module (J+7)

ÉVALUATION [Format]. Pondération : [répartition]. Qui corrige : [intervenant / enseignant permanent / double correction].

INFRASTRUCTURE [Machines / VMs / plateformes disponibles]. Réseau : [isolé / Internet / VPN]. Admin étudiants : oui / non.

CONTRAINTES Données fictives obligatoires. Enregistrements : [autorisés / interdits]. Charte signée : oui / non. RGPD : [précisions si nécessaire].

PLANNING Première séance : [date]. Validation syllabus : [date]. Remise des notes : [date].

RÉFÉRENT PÉDAGOGIQUE [Nom, email, téléphone]

Ce modèle est intentionnellement court. Un brief de deux pages qui précise tout dans les moindres détails n'est pas lu. Une page suffit à aligner les attentes et à éviter les surprises majeures.

Pour les modules complexes (plusieurs intervenants, lab partagé, projet long), ce brief sert de socle ; un cahier des charges complet peut le compléter sans le remplacer.

Les erreurs de brief les plus fréquentes

Objectifs flous : "l'étudiant comprendra la cybersécurité offensive" ne permet pas d'évaluer si l'objectif est atteint. Reformuler en capacités observables.

Infrastructure non précisée : un intervenant qui découvre le matin J que les VMs ne sont pas installées et que le réseau n'est pas isolé perdra la première heure à gérer la logistique.

Évaluation laissée à la discrétion de l'intervenant sans cadre : cela produit des évaluations très variables selon les promos. Définir le format et la pondération dans le brief, et valider le sujet avant la séance.

Absence de point de contact technique : l'intervenant doit savoir à qui s'adresser en cas de problème de lab, pas seulement au référent pédagogique.

Ne pas préciser les droits sur les supports : si l'école souhaite réutiliser les slides la saison suivante, le brief doit mentionner explicitement la cession de licence d'utilisation interne.

Adapter le brief selon le type de module

Un brief de pentest n'est pas identique à un brief de sensibilisation ou de GRC. Voici les points de différenciation essentiels selon la nature du module.

Modules offensifs (pentest, red team, sécurité web) :

• La section infrastructure et périmètre légal est la plus critique. Détailler explicitement les machines cibles, le sous-réseau autorisé et les outils explicitement exclus (ex. : pas de DoS, pas de scan de l'infrastructure de production de l'école).
• Préciser si les étudiants ont des droits root/admin sur leurs machines. Beaucoup de TP offensifs en ont besoin ; beaucoup d'écoles ne les accordent pas par défaut.
• Demander à l'intervenant de fournir ses machines cibles ou de valider la liste de celles fournies par l'école.

Modules de gouvernance / GRC / conformité :

• Les prérequis peuvent inclure des notions juridiques (RGPD, NIS2, responsabilité pénale) que tous les étudiants n'ont pas. Le préciser dans le brief pour que l'intervenant calibre l'introduction.
• Les cas pratiques utilisent souvent des documents fictifs (politiques de sécurité, contrats, rapports d'audit). S'assurer que ces documents sont clairement identifiés comme fictifs et que les étudiants ne les confondront pas avec de vrais modèles.
• L'évaluation peut inclure une soutenance devant un jury fictif (COMEX ou RSSI). Préciser le format et les rôles dans le brief.

Modules de sensibilisation (public non-technique) :

• Le niveau de prérequis est quasi nul. Le brief doit mentionner explicitement que les étudiants n'ont pas de background informatique.
• Les outils utilisés doivent être accessibles sans installation : préférer les démonstrations web aux installations locales.
• L'évaluation est souvent qualitative (quiz de culture risque, plan d'action individuel). Le préciser pour que l'intervenant adapte ses livrables.

Modules blue team / SOC / forensic :

• Ces modules nécessitent souvent des jeux de données (logs, captures réseau, images disque) préparés spécifiquement pour le TP. Demander ces fichiers avec un délai suffisant pour les valider.
• Les outils (Splunk, Elastic, Autopsy, Wireshark) ont des interfaces lourdes : vérifier que les postes étudiants ont la RAM suffisante (16 Go recommandés pour un SIEM pédagogique).

Ce qu'il faut retenir

• Un brief en une page est le meilleur investissement de temps avant de recruter un intervenant : il prévient 80 % des problèmes de coordination.
• Les quatre sections essentielles : contexte/objectifs, format/livrables, infrastructure/RGPD, évaluation.
• Les objectifs doivent être formulés en capacités observables ("l'étudiant sera capable de…"), pas en intentions.
• L'infrastructure et les contraintes RGPD doivent être précisées avant la première séance : un lab non configuré le matin J est la cause la plus fréquente d'un premier cours raté.
• Trois points de contact sont suffisants : J-21 (brief + accès), J-7 (validation finale), J+7 (bilan et remise des supports).

Vous cherchez un intervenant qualifié pour animer ce module dans votre école d'ingénieurs ? Retrouvez des formateurs cybersécurité sélectionnés sur Cyber Teachers — chaque profil inclut les thèmes d'intervention, le niveau de public et les références terrain.