Comment j'ai monté un lab cybersécurité avec 0 budget (astuces, ressources, limites)

Le contexte : pourquoi zéro budget ?

Il y a quelques années, j'ai pris en charge un module de cybersécurité dans un établissement d'enseignement supérieur sans que la direction n'ait anticipé le moindre budget pour l'infrastructure. Le cours était au programme, les étudiants étaient inscrits, la date de rentrée était fixée — et côté matériel, il y avait des postes bureautiques classiques, une connexion réseau filaire et rien d'autre.

J'aurais pu me contenter de slides et de démonstrations en live depuis mon propre poste. J'ai choisi de ne pas le faire. Un cours de cybersécurité sans TP pratique, c'est comme un cours de conduite sans volant : on peut expliquer la théorie, mais les réflexes ne viennent que par la pratique. Les étudiants ont besoin de scanner, d'exploiter, de défendre, de se tromper et de recommencer dans un environnement qui leur appartient.

La décision a donc été claire : monter un lab fonctionnel avec ce qu'on avait sous la main. Et cette décision avait un corollaire que j'ai trop souvent vu minimiser dans les retours d'expérience similaires : ce choix coûte énormément de temps. Récupérer du matériel, installer des systèmes, configurer des réseaux isolés, documenter pour que les collègues puissent reprendre — tout cela représente facilement plusieurs dizaines d'heures de travail bénévole avant même le premier TP. Soyons honnêtes là-dessus dès le départ.

Matériel récupéré et licences éducatives

Ce que le service informatique peut vous donner

La première démarche a été de contacter le service informatique de l'école. Dans beaucoup d'établissements, des postes en fin de vie partent à la benne ou dorment dans une réserve parce que leur configuration est jugée insuffisante pour les usages bureautiques courants. Pour un lab de cybersécurité sous virtualisation, un PC avec 8 Go de RAM et un processeur i5 de cinquième ou sixième génération suffit largement à faire tourner deux ou trois machines virtuelles légères.

J'ai récupéré de cette façon une dizaine de tours, un switch non managé de rechange et quelques câbles RJ45. Un collègue du département réseau m'a prêté un vieux switch managé qui dormait dans son armoire — ce point est crucial, j'y reviendrai dans la section sur l'isolation.

Pour centraliser les machines virtuelles et offrir aux étudiants un accès partagé, j'ai récupéré un serveur de rack de seconde génération auprès d'une entreprise partenaire de l'école qui renouvelait son parc. Avec 64 Go de RAM et deux processeurs Xeon, cette machine m'a permis d'installer Proxmox VE et d'héberger l'ensemble du lab de façon centralisée.

Les programmes académiques : une mine souvent ignorée

Avant d'acheter quoi que ce soit, vérifiez systématiquement les programmes académiques auxquels votre établissement est éligible. J'ai découvert, après plusieurs semaines de débrouillardise, que l'école était déjà référencée dans deux programmes majeurs :

Microsoft Azure Dev Tools for Teaching donne accès aux licences Windows Server, Windows 10/11 Éducation et Visual Studio aux étudiants et enseignants. C'est légal, gratuit pour les établissements partenaires, et ça change radicalement les possibilités côté systèmes Windows en lab.

GitHub Education offre aux étudiants un accès Pro à GitHub, des crédits cloud chez plusieurs fournisseurs et des licences pour des outils de développement. Pour des TP orientés DevSecOps ou gestion de code sécurisé, c'est une ressource précieuse.

Les programmes Cisco Networking Academy et VMware Academic Program méritent aussi une vérification : ils permettent d'accéder à des simulateurs réseau et à des hyperviseurs avec des conditions tarifaires très avantageuses pour l'éducation.

Inventaire type d'un lab zéro budget

Voici l'inventaire que j'ai constitué au fil des récupérations et des programmes académiques, avec le coût réel de chaque élément :

Coût total du lab initial : 0 €. La contrepartie : environ 40 heures de travail de ma part pour tout installer, configurer et documenter.

Images préconfigurées et communautés

Les machines vulnérables : un catalogue considérable

La véritable richesse du lab zéro budget ne vient pas du matériel — elle vient de la communauté open source qui a produit des dizaines d'environnements préconfigurés, légaux et pédagogiquement solides.

VulnHub est le point de départ incontournable. Ce site recense des centaines de machines virtuelles volontairement vulnérables, téléchargeables librement et accompagnées de walkthroughs rédigés par la communauté. Pour des TP de niveau L3 à M1, j'y ai trouvé de quoi alimenter un semestre entier de séances pratiques.

Metasploitable 2 et 3 restent les références pour les TP réseau et système. Metasploitable 2, vieille machine mais toujours utile, intègre une collection de services délibérément mal configurés idéale pour initier les étudiants aux bases de l'exploitation. Metasploitable 3 monte d'un cran en complexité et permet d'aborder des scénarios post-exploitation.

Pour le web applicatif, deux outils se complètent parfaitement :

• DVWA (Damn Vulnerable Web Application) couvre les vulnérabilités OWASP classiques : injection SQL, XSS, CSRF, upload non contrôlé. Simple à installer sur Apache, idéal pour les premières séances.
• OWASP Juice Shop offre une application moderne, réaliste, en Node.js, avec plus d'une centaine de défis progressifs. Je l'utilise pour les TP de niveau M1 et les modules orientés sécurité réseau applicative.

Les distributions attaquantes

Kali Linux et Parrot OS Security sont les deux distributions de référence pour les postes attaquants. Toutes deux regroupent des centaines d'outils de sécurité préinstallés : Nmap, Metasploit, Burp Suite Community, Wireshark, John the Ripper, Hydra. L'une ou l'autre fera l'affaire selon les préférences — je penche pour Kali dans les contextes pédagogiques car sa documentation communautaire est plus dense.

Les plateformes d'apprentissage guidé

TryHackMe et Hack The Box proposent toutes deux un accès partiel gratuit qui peut compléter le lab local. Je les utilise pour les modules où la machine locale n'est pas indispensable — notamment pour les techniques OSINT ou la reconnaissance, où l'environnement guidé de ces plateformes est plus adapté que des machines vulnérables hébergées localement.

Rester informé sans s'épuiser

La maintenance d'un lab gratuit repose entièrement sur la veille communautaire. Les ressources que je consulte régulièrement :

• Les GitHub des projets (Metasploitable, DVWA, Juice Shop) pour les mises à jour de sécurité et les nouvelles fonctionnalités
• Les forums et Discord de la communauté francophone (Root-Me, le Discord Hack The Box France)
• Les fils de discussion VulnHub pour les retours d'autres formateurs sur les machines adaptées à l'enseignement

Ce qu'on ne peut pas faire sans budget (honnêteté requise)

Ce serait rendre un mauvais service aux collègues que de présenter le lab zéro budget comme une solution universelle. Il y a des limites réelles, non contournables, que j'ai identifiées après plusieurs semestres d'utilisation.

Les environnements cloud ne sont pas reproductibles localement

Les modules qui mettent en pratique des attaques sur des environnements cloud (AWS, Azure, GCP) nécessitent des crédits ou des comptes de sandbox. On peut contourner partiellement avec des émulateurs comme LocalStack, mais l'expérience est très différente d'un vrai environnement cloud. Pour les formations orientées Cloud Security, le lab local atteint vite ses limites.

Le forensic avancé requiert des outils commerciaux

FTK (Forensic Toolkit) et EnCase sont les standards du marché pour l'investigation numérique professionnelle. Ces outils ont des licences commerciales dont le coût est incompressible. Autopsy (open source) couvre les cas d'usage pédagogiques de base, mais un étudiant qui vise un poste d'analyste OSINT ou d'analyste forensic dans un contexte professionnel devra impérativement se former sur les outils commerciaux à un moment ou à un autre.

La montée en charge pose des problèmes concrets

Au-delà de 15 à 20 postes simultanés, le matériel récupéré commence à montrer ses limites. Les disques durs mécaniques des vieux serveurs créent des goulots d'étranglement. Les pannes deviennent plus fréquentes. La maintenance corrective — reinstaller une VM qui ne répond plus, remplacer un disque, déboguer une configuration réseau qui a glissé — peut facilement absorber deux heures en plein TP. J'ai vécu cette situation : ce n'est pas agréable pour les étudiants et ça érode la crédibilité du dispositif.

Les certifications ont un coût incompressible

Les labs de préparation à l'OSCP (Offensive Security Certified Professional) ou aux certifications OffSec sont payants. Il est possible de s'entraîner en parallèle avec TryHackMe et VulnHub, mais le lab officiel et l'examen ont un coût que rien ne remplace. Idem pour les certifications Cisco, CompTIA ou GIAC : la préparation peut être libre, le passage ne l'est pas. Il faut être transparent là-dessus avec les étudiants.

Sécurité et isolement avec moyens limités

C'est la section que je considère comme la plus importante de ce retour d'expérience. Un lab de cybersécurité mal isolé n'est pas seulement inutile : il est dangereux.

La règle absolue d'isolation

Aucune machine du lab ne doit avoir de route vers Internet ou vers le réseau de production de l'école. Ce n'est pas une recommandation, c'est une règle non négociable. Un ver informatique libéré accidentellement dans un TP sur Metasploitable pourrait propager une charge malveillante sur le LAN de l'établissement si l'isolation n'est pas correcte. J'ai été témoin de ce type d'incident dans un établissement voisin : les conséquences administratives et techniques ont été sévères.

Configuration réseau avec des moyens limités

Avec le switch managé récupéré, j'ai configuré un VLAN dédié (802.1Q) pour le lab, sans aucune règle de routage vers les autres VLANs de l'école. Les machines du lab n'ont aucune passerelle configurée qui pointe vers le réseau de production. Si vous n'avez pas de switch managé, surveillez les marchés de seconde main : un switch Cisco ou HP 24 ports avec support VLAN se trouve régulièrement entre 30 et 60 € en occasion.

Sous Proxmox, j'ai créé des bridges internes dédiés au lab, sans liaison avec l'interface physique de l'école. Les VMs communiquent entre elles sur ce réseau interne et n'ont aucune visibilité sur l'extérieur. Sous VirtualBox sur poste étudiant, le mode Host-Only ou Internal Network assure la même isolation logique.

Journalisation minimale mais indispensable

Même sans budget, il est possible de mettre en place une journalisation basique des événements du lab. J'utilise Wazuh (SIEM open source) sur une VM dédiée du serveur central pour collecter les logs des machines du lab. C'est suffisant pour identifier une anomalie, détecter un étudiant qui sort du périmètre autorisé du TP ou retrouver l'origine d'un incident.

Pour les établissements qui souhaitent intégrer la supervision dans leur programme pédagogique, ce dispositif a une valeur double : il protège l'infrastructure et sert de cas d'usage concret pour les modules de cours blue team.

Plan de migration vers un lab financé

Le lab zéro budget est un point de départ, pas une destination. Après deux semestres de fonctionnement, j'avais suffisamment de données pour construire un argumentaire solide en faveur d'un investissement.

Documenter pour justifier

La première étape est de documenter scrupuleusement ce qui existe : inventaire matériel, configurations, incidents, temps de maintenance. Cette documentation remplit deux rôles. Elle permet à un collègue de reprendre le lab en cas d'absence. Et elle constitue la base factuelle de la demande de budget.

Un directeur pédagogique ou un directeur administratif ne décide pas sur des impressions. Il décide sur des faits chiffrés. Combien d'incidents ont eu lieu ? Combien d'heures de TP ont été perturbées ? Quel est le coût du temps enseignant absorbé par la maintenance ? Ces questions doivent trouver des réponses documentées.

L'argument ROI

La formulation qui fonctionne est celle du retour sur investissement. Si un formateur facturé à un certain taux horaire passe trois heures par semaine à maintenir un lab bricolé, le coût annuel de ce temps est réel même si personne ne l'a inscrit dans un budget. Une infrastructure fiable — un cluster Proxmox avec du matériel récent, des SSD, de la redondance — élimine l'essentiel de cette charge.

Étapes progressives de montée en gamme

Je recommande une approche par paliers plutôt qu'une demande globale :

1. Premier palier : Remplacer les postes enseignants en priorité. Un poste enseignant performant, avec une grande mémoire RAM et des SSD, permet de démontrer les scénarios sans latence. Le budget est modeste et l'impact pédagogique est immédiat.

2. Deuxième palier : Ajouter un serveur avec des SSD pour héberger les VMs étudiantes de façon fiable. Un seul serveur reconverti avec 128 Go de RAM et des SSD peut alimenter une salle de 20 postes via Proxmox.

3. Troisième palier : Envisager les solutions cloud pédagogiques comme alternative ou complément aux labs physiques. Des plateformes comme Strigo, CloudShare ou des offres AWS Educate permettent de provisionner des environnements à la demande, sans matériel à maintenir. Elles ont un coût, mais ce coût est prévisible et inclut la maintenance.

Ce qu'il faut retenir

• Le lab zéro budget est faisable et pédagogiquement viable pour les niveaux L3 à M1, à condition d'accepter le coût en temps qu'il représente : comptez plusieurs dizaines d'heures de mise en place et un temps de maintenance hebdomadaire non négligeable.

• Commencez par les licences académiques avant de chercher du matériel : Microsoft Azure Dev Tools for Teaching, GitHub Education, Cisco Networking Academy et VMware Academic Program couvrent une grande partie des besoins logiciels sans débourser un centime.

• L'isolation réseau n'est pas optionnelle : configurez un VLAN dédié ou des réseaux host-only dans votre hyperviseur dès le premier jour. Un lab mal isolé expose le réseau de l'établissement à des risques réels, notamment la propagation d'exploits ou de vers informatiques utilisés dans les TP.

• Documentez tout dès le départ : l'inventaire, les configurations, les incidents, le temps passé. Cette documentation est votre meilleur argument pour obtenir un budget ensuite, et elle garantit la continuité du lab si vous changez de poste.

• Soyez honnêtes avec vos étudiants sur les limites : le lab gratuit ne couvre pas les environnements cloud réels, les outils forensic commerciaux ou les labs de certification. Complétez avec TryHackMe, Root-Me ou les plateformes guidées pour les modules que l'infrastructure locale ne peut pas couvrir.

• Le zéro budget est un point de départ, pas un objectif : utilisez les données collectées pendant les premiers semestres pour construire un argumentaire chiffré et migrer progressivement vers une infrastructure pérenne, en commençant par les postes enseignants.

Un lab de cybersécurité, même monté avec des bouts de ficelle, reste infiniment plus formateur que des cours entièrement théoriques. La contrainte budgétaire, quand elle est gérée avec méthode et honnêteté, peut même devenir un atout pédagogique : elle oblige à comprendre en profondeur ce qu'on installe et pourquoi.

Si vous souhaitez aller plus loin dans la conception de vos cours et infrastructures pédagogiques, Cyber Teachers accompagne les établissements dans la structuration de leurs formations en cybersécurité — de la définition du programme jusqu'à la mise en place des environnements pratiques.