Retour d'expérience : un CTF de 500 étudiants (infra, bénévoles, communication)

J'avais déjà organisé une dizaine de CTF pédagogiques — des formats de 20 à 80 étudiants, dans une salle, avec un serveur monté la veille, deux bénévoles et un canal Discord improvisé. Ça fonctionnait. Les étudiants étaient engagés, les incidents se réglaient en cinq minutes, et on finissait la journée sur un débriefing détendu.

Puis est venue la commande d'un CTF inter-écoles pour 500 étudiants, répartis sur trois sites, pour une journée complète. J'avais confiance dans le format — la mécanique jeopardy, je la connaissais. Ce que je n'avais pas anticipé, c'est que passer de 80 à 500 participants ne change pas seulement la quantité de travail : ça change la nature de l'événement.

Ce retour d'expérience est écrit pour les organisateurs qui vont affronter la même transition. Non pas pour décourager — c'est l'un des événements pédagogiques les plus marquants que j'aie organisé — mais pour éviter de réapprendre à leurs dépens ce que j'ai mis plusieurs mois à comprendre.

Pourquoi 500 participants changent tout

L'illusion de la scalabilité linéaire

L'erreur de raisonnement classique : "J'ai déjà fait un CTF de 80 personnes, 500 c'est 6 fois plus de challenges, 6 fois plus de bénévoles, un serveur plus gros." Ce calcul est faux.

Avec 20 ou 30 étudiants dans une salle, vous connaissez la situation en temps réel. Vous voyez qui est bloqué, vous entendez les conversations, vous détectez l'ambiance. Quand un challenge dysfonctionne, un bénévole le signale en 3 minutes. La topologie est celle d'une salle de classe agrandie : vous en restez le centre de gravité.

À 500, vous ne pouvez plus rien voir directement. Vous ne gérez plus des individus mais des flux — un flux de tickets support, un flux de soumissions sur la plateforme, un flux de messages sur le canal bénévoles, un flux de retours de référents par site. La topologie bascule vers celle d'un événement logistique : vous devenez chef d'orchestre d'une organisation que vous ne pouvez pas observer directement.

Ce qui bascule concrètement

Trois domaines changent de nature à cette échelle.

La gestion des incidents. À 80 participants, un incident technique touche quelques équipes. À 500, un challenge cassé ou un serveur ralenti génère des dizaines de messages simultanés, des accusations de triche, des demandes de compensation de points. La pression est d'un ordre de magnitude différent — et elle arrive toujours dans les premières minutes, quand la plateforme encaisse le pic de connexions.

La communication. À 80, on envoie un message sur Discord et tout le monde le lit. À 500, un message mal rédigé génère 50 questions d'interprétation. Un règlement ambigu sur un point de scoring devient un litige public. La communication n'est plus un outil pratique — c'est un acte architectural qui structure l'événement.

La charge serveur. La courbe de charge n'est pas linéaire. 500 participants qui se connectent dans les cinq premières minutes génèrent un pic de trafic que peu de configurations légères supportent. Les premiers CTF que j'ai organisés tenaient sur un VPS à 4 cœurs. Pour 500 étudiants, j'ai dû raisonner en termes d'infrastructure de production.

Infra, file d'attente support et escalade

Le choix de plateforme : CTFd self-hosted sans compromis

Pour un événement de cette taille, j'ai retenu CTFd en auto-hébergé sur un serveur dédié. Les plateformes cloud clés-en-main ont l'avantage de la simplicité, mais elles ont deux problèmes rédhibitoires à grande échelle : la latence lors des pics, et l'absence de contrôle en cas d'incident.

La configuration minimale que j'ai testée avec succès : 8 cœurs, 32 Go de RAM, SSD NVMe, PostgreSQL comme base de données (pas SQLite), et un reverse proxy nginx devant l'application. Ajoutez à cela un cache Redis pour les sessions et les classements — sans ça, le leaderboard en temps réel devient un goulot d'étranglement dès que les soumissions s'accélèrent.

L'isolation réseau des challenges est non-négociable. Chaque challenge hébergé côté serveur (web, pwn, réseau) doit tourner dans un conteneur isolé avec un réseau dédié, sans accès au réseau de production. C'est une évidence en théorie ; en pratique, ça représente plusieurs heures de configuration Docker Compose ou Kubernetes qu'il faut anticiper, pas improviser le matin de l'événement.

Prévoyez des snapshots automatiques toutes les deux heures. Sur cet événement, j'ai dû restaurer une instance de challenge défaillante en milieu de matinée — la présence d'un snapshot récent a réduit l'interruption à moins de huit minutes. Sans ça, c'était une heure minimum de reconstruction.

La file d'attente support à trois niveaux

Le point d'organisation qui a le plus différencié cet événement de mes éditions précédentes : un système de tickets support avec escalade structurée, inspiré des pratiques des équipes DevOps.

Concrètement :

• Niveau 1 — Bénévole support : premier filtre. Répond aux questions générales (règlement, connexion à la plateforme, problème de compte). Résout les incidents courants sans intervention technique. Objectif : traiter 80 % des demandes sans escalade.
• Niveau 2 — Technicien CTF : intervention sur les incidents challenge (challenge cassé, container down, flag non accepté malgré une soumission correcte). A accès SSH au serveur et peut redémarrer des services. Objectif : résolution en moins de 15 minutes.
• Niveau 3 — Organisateur principal : décisions de scoring, litiges contestés, incidents de sécurité (participant qui sort du périmètre). Seul habilité à modifier le scoring d'une équipe ou à invalider un flag.

Ce système peut paraître lourd pour un événement d'une journée. En pratique, il a évité la saturation des organisateurs principaux sur des tickets de niveau 1 — et il a donné aux bénévoles un cadre clair qui les a rendus beaucoup plus efficaces.

Rôles bénévoles et charge estimée

Total : 20 personnes. C'est le minimum viable pour un CTF d'une journée à 500 participants sur trois sites. Réduire ce nombre revient à surcharger des rôles clés et à dégrader la qualité de réponse aux incidents.

Communication avant / pendant / après

Avant : construire le kit participant

La communication pré-événement est souvent bâclée, avec un email récapitulatif envoyé la veille. À 500 participants sur trois sites, c'est une erreur qui se paie le jour J.

J'ai construit un kit participant envoyé dix jours avant l'événement, complété par un rappel à J-3. Ce kit contenait :

• Le règlement complet (format des flags, règles de scoring, politique anti-triche, conduite à tenir en cas d'incident).
• La FAQ technique : accès à la plateforme, création de compte et d'équipe, prérequis logiciels à installer avant le jour J (VPN si nécessaire, Burp Suite Community, netcat, Python).
• Les horaires précis par site, avec le nom du coordinateur local et son moyen de contact.
• Un guide de connexion pas à pas avec captures d'écran — parce que même des étudiants en cybersécurité peuvent échouer à créer leur équipe sur une nouvelle plateforme sous la pression du temps.

Ce kit a réduit de façon notable les questions d'organisation le matin de l'événement. Les participants arrivaient prêts ; les bénévoles d'accueil n'avaient plus à gérer des cas de "je n'ai pas reçu le lien de la plateforme".

Pendant : gérer le canal Discord comme une salle de crise

La communication pendant l'événement repose sur un serveur Discord dédié avec des canaux séparés par fonction :

• #annonces (lecture seule pour les participants) : annonces officielles, corrections de bugs, changements de scoring.
• #support-technique : questions techniques, réponses des bénévoles N1.
• #general : discussions libres entre participants.
• #bénévoles-interne (privé) : coordination interne, escalades, status serveur.

La règle la plus importante que j'ai apprise sur cet événement : les annonces officielles doivent être sobres, non-ambiguës, et ne jamais être rédigées sous pression. Dans les premières minutes de l'événement, quand le serveur a connu un pic de charge, j'ai posté un message de communication de crise rédigé à la hâte. Ce message a généré plus de confusion qu'il n'en a résolu — parce qu'il était mal formulé et que chacun l'interprétait différemment.

La leçon : préparez des templates d'annonces de crise à l'avance (incident serveur, challenge retiré, correction de scoring) et ne postez que les versions relues.

Après : la restitution pédagogique comme acte fort

Le débriefing post-CTF est souvent expédié en une heure de présentation du top 3 et de quelques corrections de challenges. C'est une occasion manquée.

Pour cette édition, j'ai organisé une session de restitution en deux temps :

• Une session synchrone le lendemain (deux heures) : corrections des challenges les plus résolus et des challenges que personne n'a réussi à finir, avec les approches inattendues présentées par les participants eux-mêmes.
• Une publication de write-ups sélectionnés sur l'espace pédagogique de l'école, avec un accent délibéré sur les méthodes créatives plutôt que sur les solutions les plus rapides.

Ce deuxième temps a eu un effet que je n'avais pas anticipé : plusieurs étudiants qui n'avaient pas terminé dans le top 10 avaient produit des approches particulièrement intelligentes sur des challenges complexes. Les valoriser publiquement a changé la perception de l'événement — du simple classement vers une culture d'apprentissage collectif. C'est précisément l'ambition d'un cours de pentest bien conçu : valoriser la démarche autant que le résultat.

Incidents vécus et solutions

Incident 1 : le pic de charge des premières minutes

Dès l'ouverture des challenges, à 9h00 précises, 300 participants se sont connectés quasi simultanément. La plateforme a commencé à répondre avec des temps de latence de 8 à 12 secondes. Le classement ne se rafraîchissait plus.

La cause était connue à l'avance en théorie — j'avais vu cette limite lors du test de charge — mais j'avais sous-estimé le pic réel. La solution d'urgence : désactiver temporairement le rafraîchissement du leaderboard en temps réel et passer à une mise à jour toutes les 5 minutes. La charge serveur a chuté immédiatement. L'annonce sur Discord a été bien reçue par les participants.

La leçon : le leaderboard en direct est un élément de l'expérience, pas une nécessité technique. Dès le prochain CTF de cette taille, je le désactive par défaut au démarrage et je l'active progressivement une fois la charge stabilisée.

Incident 2 : le litige de scoring

À 11h30, une équipe a contesté un flag qu'elle avait soumis correctement mais qui avait été accepté dans un format non standard (majuscules au lieu de minuscules). Le système l'avait refusé. Deux autres équipes avaient eu le même problème et n'avaient pas contesté.

La solution : validation manuelle du flag par le technicien N2, correction du challenge pour accepter les deux formats, et crédit rétroactif de points aux trois équipes. Durée totale : 22 minutes.

Ce qui a évité l'escalade : le technicien N2 disposait d'une procédure documentée pour les corrections de scoring, avec les droits d'accès nécessaires sur la plateforme. Sans ça, cet incident aurait remonté jusqu'à l'organisateur principal en plein milieu de la matinée.

Incident 3 : le participant qui sort du périmètre

Vers 14h00, un coordinateur de site m'a signalé qu'un participant avait lancé un scan réseau sur le réseau local du site — pas sur le réseau d'isolation des challenges, mais sur le réseau de l'école. Un comportement classique d'un étudiant curieux qui dépasse les limites du périmètre autorisé, sans intention malveillante visible.

Intervention immédiate : entretien individuel avec le participant (accompagné du coordinateur site), rappel du règlement, documentation de l'incident. Pas de disqualification — le règlement ne prévoyait pas explicitement ce cas, et la sanction aurait été disproportionnée. En revanche, l'incident a été ajouté au compte-rendu post-événement, et le règlement de l'édition suivante mentionne désormais explicitement les limites du périmètre autorisé, avec les sanctions associées.

Ce type d'incident n'est pas rare dans des CTF impliquant des étudiants qui suivent un cours de sécurité réseau ou un cursus orienté attaque. La plupart des profils qui explorent ces limites ne sont pas malveillants — ils testent ce qu'ils peuvent faire. C'est aux organisateurs de définir le cadre avec précision.

Incident 4 : l'abandon massif sur un challenge mal calibré

À 15h00, l'analyse du tableau de bord montrait qu'un challenge en catégorie "reverse" n'avait reçu aucune soumission correcte depuis 3 heures — sur 500 participants. Aucune équipe n'avait passé le premier obstacle.

Après consultation entre les organisateurs, nous avons pris la décision de publier un premier indice gratuit (normalement payant en points). Le taux de résolution a progressé immédiatement. Le challenge avait un prérequis implicite qui n'était pas évident pour des étudiants sans background en désassemblage — un défaut de calibrage que le test interne n'avait pas détecté parce que les testeurs, des profils expérimentés proches des red teamers, trouvaient la résolution naturelle.

La leçon : les challenges doivent être testés par des profils représentatifs du public cible, pas seulement par les créateurs ou des experts. Un challenge que trois spécialistes résolvent en 10 minutes peut bloquer 500 étudiants de niveau master pendant toute une journée.

Indicateurs de réussite au-delà du classement

Le podium final est l'indicateur le plus visible d'un CTF. C'est aussi l'un des moins pertinents pour évaluer la qualité pédagogique de l'événement. Voici les indicateurs que j'ai appris à suivre.

Taux de participation active

Sur 500 participants inscrits, combien ont résolu au moins un challenge ? Dans mon expérience, un taux de participation active supérieur à 70 % signale un bon calibrage de la pyramide de difficulté. Les challenges d'entrée de gamme ont correctement joué leur rôle.

Sur cette édition, ce taux s'est établi à un niveau que je considère satisfaisant — légèrement supérieur à deux tiers des participants. Les équipes qui n'ont validé aucun challenge correspondaient principalement à des inscrits qui n'ont pas participé du tout (absences, connexions manquées), pas à des équipes actives en échec complet.

Qualité des write-ups partagés

Demander aux équipes volontaires de produire un write-up après l'événement révèle deux choses : le niveau de compréhension réelle des solutions (pas juste la chance d'avoir trouvé le flag), et la capacité à communiquer une démarche technique.

Les meilleurs write-ups que j'ai reçus ne venaient pas des équipes du top 10. Certaines équipes classées dans le tiers médian avaient produit des analyses remarquablement bien structurées sur des challenges qu'elles avaient eu du mal à résoudre — justement parce qu'elles avaient dû chercher plus longtemps et comprendre plus en profondeur.

Retours sur la courbe de difficulté

Un questionnaire post-événement de 5 questions (anonyme, prend 2 minutes) donne des données précieuses : difficulté perçue par catégorie, challenge le plus frustrant, challenge le plus satisfaisant, suggestion pour la prochaine édition. Les retours terrain montrent que la majorité des critiques utiles portent non pas sur les challenges les plus difficiles, mais sur les challenges mal calibrés — trop vagues, avec des prérequis non annoncés, ou dépendants d'une information impossible à trouver.

Engagement post-CTF

L'indicateur de long terme le plus significatif : combien d'étudiants se sont impliqués dans un club CTF ou ont demandé à rejoindre l'organisation de l'édition suivante ? Dans mon expérience, un CTF bien organisé génère systématiquement un effet d'entraînement — des étudiants qui découvrent qu'ils aiment ce mode d'apprentissage et veulent aller plus loin. Certains cherchent des certifications, d'autres des stages en sécurité offensive, d'autres encore s'impliquent dans l'organisation d'événements similaires.

Ce qu'il faut retenir

• Un CTF de 500 participants n'est pas un grand CTF de 80 participants. C'est un événement d'une nature différente, qui exige une infrastructure de production, une organisation en équipes avec des rôles définis, et une communication préparée à l'avance — pas improvisée le jour J.
• Dimensionnez l'infrastructure pour le pic de charge, pas pour la charge moyenne. Les premières minutes d'un CTF concentrent l'essentiel du trafic. Testez avec un script de charge la semaine avant ; ce test vous donnera les seules données fiables sur lesquelles planifier.
• Un système de tickets d'escalade à trois niveaux n'est pas du luxe. Il protège les organisateurs principaux des questions de niveau 1, il donne aux bénévoles un cadre clair, et il garantit que les incidents critiques reçoivent une réponse dans des délais acceptables.
• Les challenges doivent être testés par des profils représentatifs du public cible. Un challenge validé uniquement par des experts aura des défauts de calibrage invisibles jusqu'au jour J.
• La restitution pédagogique est aussi importante que l'événement lui-même. Valoriser les approches créatives plutôt que le seul classement transforme un concours en expérience d'apprentissage collectif. C'est là que se joue l'impact pédagogique réel.
• Mesurez la participation active, la qualité des write-ups et l'engagement post-événement — pas seulement le podium. Ces indicateurs vous disent si votre CTF a eu un impact formatif, pas seulement compétitif.

Vous envisagez d'organiser un CTF pour vos étudiants — que ce soit un premier événement de 50 personnes ou un inter-écoles à plusieurs centaines de participants ? Cyber Teachers vous met en relation avec des professionnels expérimentés dans la conception et l'animation de compétitions pédagogiques en cybersécurité.