L'IA comme outil pour l'enseignant en cybersécurité : générateurs de labs, quiz et scénarios
La question n'est plus de savoir si les outils d'IA générative vont changer l'enseignement de la cybersécurité. C'est déjà fait. La question est : comment les utiliser intelligemment pour gagner du temps sur les tâches répétitives, sans déléguer la qualité pédagogique à un modèle de langage ?
Cet article s'adresse aux formateurs en cybersécurité qui veulent adopter les LLM comme outils de productivité, pas comme béquilles. Vous trouverez ici des méthodes concrètes, des exemples de prompts et les limites à ne jamais oublier.
Ce que l'IA peut faire concrètement pour vous (et ses vraies limites)
Ce que les LLM font bien
Les grands modèles de langage (ChatGPT, Claude, Gemini, Mistral) sont devenus des assistants raisonnables pour plusieurs tâches pédagogiques à faible risque d'erreur :
- Générer des premiers jets de quiz à partir d'une liste d'objectifs pédagogiques. La forme est souvent bonne, la validité technique doit être vérifiée.
- Varier des scénarios d'attaque fictifs : créer un cas d'entreprise imaginaire avec un vecteur d'attaque donné, pour alimenter une discussion en classe.
- Résumer des CVE complexes en langage accessible aux étudiants débutants, sans les détails d'exploitation.
- Proposer des plans de cours ou des progressions pédagogiques à partir d'un syllabus existant.
- Rédiger des énoncés de TP clairs et structurés, en quelques minutes.
- Traduire ou adapter des ressources anglophones en français avec un bon niveau de qualité.
Ce que les LLM font mal (et qu'il ne faut pas leur confier)
L'IA générative a des lacunes structurelles importantes en cybersécurité :
- L'exactitude technique sur les détails d'exploitation : les versions précises de CVE, les comportements réels d'outils comme Metasploit ou Burp Suite, les configurations exactes de pare-feu. Les modèles inventent facilement des détails plausibles mais faux.
- La mise à jour en temps réel : un modèle entraîné jusqu'en 2024 ne connaît pas les vulnérabilités découvertes en 2025 ni les évolutions réglementaires récentes (NIS2, DORA, CRA).
- Le code de configuration qui fonctionne vraiment : un playbook Ansible généré par IA demande systématiquement une revue humaine avant déploiement.
- Les subtilités légales : la frontière entre ce qui est légal en lab pédagogique et ce qui ne l'est pas varie selon les contextes. Ne jamais déléguer ce point à un LLM.
Règle d'or : toute sortie technique d'un LLM doit être vérifiée par l'enseignant avant d'être transmise à des étudiants. L'IA est un premier jet, jamais une source finale.
Générer des scénarios d'attaque fictifs et des cas pratiques variés
L'intérêt des scénarios fictifs
Les études de cas concrètes sont l'un des formats les plus efficaces en cybersécurité. Elles permettent aux étudiants de raisonner sur des situations réalistes sans les contraintes légales et éthiques qui pèsent sur les cas réels. L'IA excelle ici, car créer dix variantes d'un même scénario prend dix fois plus de temps à la main qu'avec un LLM bien prompté.
Un exemple de prompt efficace
Voici la structure d'un prompt qui produit des scénarios utilisables :
Tu es un formateur en cybersécurité. Génère un scénario fictif d'incident de sécurité pour une discussion en classe de niveau licence.
- Entreprise fictive : une PME française de 150 employés dans le secteur de la logistique
- Vecteur d'attaque : un e-mail de phishing ciblé envoyé au responsable comptable
- Impact : exfiltration de données bancaires et tentative de virement frauduleux
- Durée du scénario : 48 heures
- Format : chronologie heure par heure, 10 étapes maximum, langage accessible
- Ne pas mentionner de vrai produit de sécurité nommé
- Ne pas inventer de statistiques
Ce prompt produit un scénario structuré en 10 étapes, utilisable pour une activité de 20 minutes en classe. Le formateur lit le scénario, pose des questions à chaque étape : "Quel signal d'alerte était visible ici ?", "Qu'aurait dû faire l'employé ?".
Varier par niveau de difficulté
- Niveau débutant : ingénierie sociale simple (phishing, prétexte téléphonique), impact limité et détectable.
- Niveau intermédiaire : attaque par watering hole sur le prestataire, mouvement latéral interne, détection tardive.
- Niveau avancé : attaque supply chain via une mise à jour logicielle compromise, persistance longue durée. Ce type de scénario permet d'introduire la modélisation des menaces dans un contexte réaliste.
La sécurité de l'IA peut aussi être intégrée comme vecteur dans les scénarios avancés : attaque par prompt injection sur un chatbot interne, empoisonnement de dataset.
Créer et diversifier les quiz et évaluations formatives
Pourquoi le quiz manuel est chronophage
Créer de bonnes questions à choix multiples est un travail intellectuellement exigeant. Il faut définir l'objectif, formuler la question, trouver la réponse correcte, puis inventer trois à quatre distracteurs plausibles mais faux. Pour un module de dix séances, préparer soixante bonnes questions prend plusieurs jours.
L'IA réduit ce temps de manière significative, surtout pour la génération des distracteurs.
Comment prompter pour des quiz de qualité
Partez toujours d'un objectif pédagogique précis :
Objectif : les étudiants doivent savoir expliquer la différence entre un IDS et un IPS, et identifier lequel utiliser dans quel contexte réseau.
Génère 5 questions à choix multiples sur cet objectif. Pour chaque question :
- 1 réponse correcte
- 3 distracteurs plausibles (pas évidents à éliminer)
- Indication du niveau Bloom (connaissance, compréhension, application)
- La réponse correcte entre parenthèses à la fin
Ne pas répéter les mêmes formulations. Varier les types (contexte, définition, comparaison, cas).
Le résultat brut est généralement utilisable à 70-80 %. La validation technique porte surtout sur les distracteurs : certains LLM inventent des comportements d'outils incorrects qui pourraient induire les étudiants en erreur.
Liste de vérification avant d'utiliser un quiz généré par IA
| Critère | À vérifier |
|---|---|
| Exactitude technique | La réponse correcte est-elle bien correcte ? |
| Qualité des distracteurs | Sont-ils plausibles sans être ambigus ? |
| Clarté de la formulation | La question est-elle compréhensible sans contexte supplémentaire ? |
| Niveau de difficulté | Correspond-il à votre groupe ? |
| Originalité | Une recherche Google rapide ne donne-t-elle pas la réponse directement ? |
Automatiser la génération de topologies de lab et de configurations
Le gain principal : le brouillon initial
Concevoir une topologie de lab from scratch prend du temps : identifier les zones réseau, définir l'adressage, choisir les machines, écrire la documentation. L'IA peut générer un premier brouillon en quelques secondes que vous affinez ensuite.
Exemple de prompt pour une topologie réseau
Génère la description textuelle d'une topologie réseau pour un TP de sécurité réseau niveau M1.
Scénario : une entreprise avec un réseau interne (postes utilisateurs), une DMZ (serveur web, serveur mail), et un réseau administrateur (SIEM, admin).
L'étudiant joue le rôle d'un attaquant externe qui doit tenter de compromettre le serveur web puis pivoter vers l'interne.
Format : liste des VMs, leur rôle, leur OS suggéré, leur adresse IP, les règles de filtrage entre zones.
Ne pas utiliser de vrais noms de produits commerciaux.
Le LLM produit un tableau propre avec adressages, rôles et règles de base. Ce brouillon est transformable en playbook Ansible ou configuration Terraform avec une deuxième étape de prompt ou manuellement.
Ce que vous devez toujours vérifier manuellement
- L'isolation réseau : l'IA oublie souvent les routes de retour ou les règles NAT nécessaires.
- La cohérence des adressages IP : les masques de sous-réseau sont parfois incohérents.
- Les règles de filtrage : les LLM ont tendance à sur-autoriser (trop permissif) ou sous-autoriser (lab inutilisable).
- La faisabilité sur votre infrastructure : les ressources CPU/RAM suggérées ne correspondent pas toujours à ce dont vous disposez.
En pratique, un lab bien conçu par un enseignant expérimenté prend deux à trois heures. Avec l'IA comme point de départ, ce temps peut descendre à quarante-cinq minutes à une heure.
Correction formative automatisée : ce qui est possible
Le rapport d'analyse, un livrable universel en cyber
Les cours de forensic, de pentest, de threat modeling ou de DevSecOps demandent souvent des rapports écrits comme livrables. Ces rapports sont utiles pédagogiquement mais chronophages à corriger manuellement pour un groupe de vingt à trente étudiants.
L'IA peut intervenir sur la correction formative (pendant le cours) sans remplacer la notation finale.
Ce que l'IA corrige bien
- La structure du rapport : sections présentes ou manquantes, ordre logique, longueur des sections.
- La complétude de surface : "vous n'avez pas mentionné de recommandations de remédiation" ou "la section IoC est vide".
- Le vocabulaire : usage ou non des termes techniques appropriés, mélanges de registres.
- La cohérence interne : "votre analyse statique dit X mais votre analyse dynamique dit le contraire".
Ce que l'IA ne corrige pas bien
- L'exactitude des conclusions techniques : si l'étudiant identifie mal un comportement de malware, l'IA peut ne pas le détecter.
- La pertinence des recommandations : une recommandation techniquement valide mais disproportionnée par rapport au risque passe généralement le filtre de l'IA.
- La qualité de la démarche : un étudiant peut produire un rapport bien structuré en utilisant les mauvaises méthodes d'analyse.
Un workflow hybride efficace
- L'étudiant soumet son rapport en fin de TP.
- L'enseignant envoie le rapport à un LLM avec un prompt de relecture structurée.
- L'IA renvoie un retour formatif en 2 minutes : points manquants, points bien couverts.
- L'étudiant peut corriger avant la remise finale (si délai le permet).
- L'enseignant évalue la version finale avec focus sur l'exactitude technique.
Ce workflow est particulièrement adapté au module IA générative et aux cours de sensibilisation où les livrables sont plus textuels que techniques.
Politique d'usage acceptable de l'IA dans vos cours
Trois modèles, une seule position viable
Modèle 1 : l'interdiction totale. Irréaliste en 2026. Les étudiants utilisent l'IA hors classe quelle que soit la règle, et l'interdire ne prépare pas à la pratique professionnelle.
Modèle 2 : l'usage libre non encadré. Risqué. Les étudiants ne développent pas leurs compétences de base si tout le travail peut être sous-traité à un LLM. La détection est difficile.
Modèle 3 : l'usage supervisé et déclaré. Recommandé. L'étudiant peut utiliser l'IA, mais doit déclarer qu'il l'a fait, citer les prompts utilisés, et défendre à l'oral ses choix et son résultat.
Une charte d'usage type (à adapter)
Voici une charte minimale applicable à un cours cyber :
"L'usage d'outils d'IA générative est autorisé pour la rédaction de rapports et la préparation de cas pratiques, à condition de :
- Mentionner explicitement l'outil utilisé dans le document remis.
- Joindre les prompts principaux utilisés.
- Être capable de défendre oralement chaque point du document remis.
L'IA ne remplace pas la compétence technique. Tout contenu technique généré par IA qui s'avère inexact lors d'un oral entraîne une pénalité sur la note finale."
Cette charte transforme l'IA en outil professionnel (ce qu'elle est dans les entreprises cyber) plutôt qu'en outil de triche.
L'IA comme sujet de cours
La sécurité de l'IA et les risques associés (hallucinations, fuites de données, prompt injection) sont eux-mêmes des sujets de cours pertinents. Profiter de l'usage pédagogique de l'IA pour aborder ces risques est une opportunité rare d'ancrer la théorie dans l'expérience immédiate des étudiants.
Surveiller et détecter l'usage non déclaré de l'IA
Les limites des détecteurs automatiques
Les outils de détection de contenu IA (GPTZero, Turnitin AI, Originality.ai) produisent un score de probabilité, pas une certitude. Les faux positifs (contenu humain détecté comme IA) et les faux négatifs (contenu IA bien paraphrasé non détecté) sont fréquents. Ces outils ne constituent pas une preuve utilisable pour sanctionner un étudiant.
La vraie défense : l'évaluation orale et pratique
Un étudiant ne peut pas générer par IA une démonstration live. Quelques principes pour des évaluations robustes face à l'IA :
Exiger des justifications contextuelles : "Pourquoi avez-vous choisi cette règle de filtrage plutôt qu'une autre pour votre topologie ?" L'IA généralise ; l'étudiant compétent contextualise.
Demander des screenshots de session terminale : la trace réelle du TP (commandes, erreurs rencontrées, corrections) ne peut pas être générée après coup.
Faire debugger en live : "Votre script Python pour parser les logs ne fonctionne pas sur ce fichier. Trouvez l'erreur." C'est impossible à tricher.
Progresser de séance en séance : si un étudiant produit un rapport parfait mais ne sait pas répondre aux questions de la séance suivante qui en découlent, c'est un signal clair.
Les cours de sensibilisation sont les plus exposés à la génération IA car les livrables y sont souvent textuels. Une soutenance orale courte (dix minutes) à la fin de chaque module les rend robustes.
Ce qu'il faut retenir
- Les LLM sont des outils de productivité, pas des sources de vérité technique. Vérifiez tout avant de l'enseigner.
- Les meilleurs cas d'usage : variation de scénarios, génération de quiz (avec relecture), brouillons de topologies, correction formative de structure.
- Les cas d'usage à éviter : configuration de sécurité directement déployée, conseils juridiques ou réglementaires, évaluation technique fine.
- Côté étudiants : une charte d'usage déclaré est plus efficace qu'une interdiction. Transformez l'IA en compétence professionnelle à maîtriser.
- Anti-triche : privilégiez les oraux et les TP en direct aux rendus purement écrits.
Vous cherchez des formateurs capables d'intégrer les enjeux de l'IA dans leurs cours de cybersécurité, à la fois comme outil et comme sujet ? Explorez les profils disponibles sur Cyber Teachers et trouvez l'intervenant qui allie compétence technique et pédagogie active.