Réseau Proxmox — 10.0.0.0/16
Cette zone représente le serveur Proxmox général du GRETA et du lycée, qui hébergeait le Proxmox dédié de chaque étudiant.
Présentation du centre de formation et apprentissage par l'alternance
Mon centre de formation est le GRETA Ardèche-Drôme, sur le site de Valence. Cet organisme est rattaché à l'Éducation nationale et regroupe plusieurs établissements scolaires publics répartis sur des sites comme Valence, Crest, Tournon ou Aubenas.
Sa vocation est d'assurer des formations professionnelles adaptées aux réalités du marché local, aussi bien pour des adultes en reconversion que pour des étudiants en alternance comme moi. Au fil des années, il a développé une expertise reconnue dans les métiers du numérique, en réponse aux besoins des entreprises de la Drôme et de l'Ardèche.
Je suis en alternance : je partage mon temps entre les cours au centre de formation et les missions en entreprise. Cela me permet d'appliquer tout de suite ce que j'apprends sur des infrastructures réelles. Le GRETA s'appuie pour cela sur un réseau d'entreprises partenaires solidement ancré dans la région.
Mise en place d'une ferme de serveurs
Cette ferme de serveurs a été réalisée de janvier à mai 2026 pour valider mon BTS : elle devait remplir plusieurs critères pour être validée. Elle a été montée sur un serveur Proxmox du GRETA. Chaque étudiant a réalisé sa propre ferme, sur son propre serveur Proxmox dédié. Ce serveur était lui-même une machine virtuelle (VM) d'un serveur Proxmox général, géré et administré par le GRETA et le lycée.
La liste de ces critères est consultable dans le cahier des charges de l'épreuve E6 (PDF) (s'ouvre dans un nouvel onglet).
Les commutateurs du schéma ne sont pas cliquables : ce sont des switchs virtuels, appelés « vmbr » sur Proxmox.
Cliquez sur un serveur, un PC, un pare-feu ou une zone du schéma pour afficher son rôle.
Voir l'ancien schéma (V1 du portfolio) (s'ouvre dans un nouvel onglet)
Faites défiler le schéma vers la droite pour voir tout le réseau.
Sélectionnez un équipement ou une zone du schéma pour afficher son rôle.
Rôle de chaque équipement et de chaque zone
Proxmox VE
Mon serveur Proxmox dédié. C'est une VM du Proxmox général, géré et administré par le GRETA et le lycée. Il héberge toutes les VM de la ferme.
Pare-feu de la ferme
Pare-feu du GRETA et du lycée. Je n'y avais pas accès : il me servait uniquement de passerelle par défaut.
OVH
Cette zone représente mon serveur personnel chez OVHcloud, où j'ai hébergé le système de sauvegarde de la ferme.
DEB13-PBS
VM « Proxmox Backup Server », hébergée sur mon serveur OVHcloud, en dehors de la ferme. Elle recevait les sauvegardes externalisées, c'est-à-dire une copie des VM conservée à distance pour pouvoir reprendre l'activité en cas de sinistre majeur sur la ferme. Cinq VM étaient sauvegardées : pfSense-01, W11-Admin, WS2025-AD01, DEB13-MariaDB et DEB13-Nextcloud. Chaque jour à 1 h du matin, une sauvegarde incrémentale était réalisée et conservée pendant deux jours. Chaque dimanche à 1 h, une sauvegarde complète était faite. J'ai testé une restauration, qui a parfaitement fonctionné.
pfSync — 172.16.0.0/24
Cette zone permet aux deux pfSense d'échanger les informations CARP et pfSync pour rester synchronisés.
pfSense-01
Pare-feu et routeur principal (maître) du cluster en haute disponibilité, en mode actif/passif : l'un fonctionne, l'autre attend que le premier tombe pour prendre le relais. Il héberge les adresses IP virtuelles (VIP CARP) utilisées comme passerelles des réseaux. Il assure le routage entre les réseaux, le filtrage de sécurité et le NAT vers le WAN. Il synchronise sa configuration et ses états de connexion avec pfSense-02.
pfSense-02
Pare-feu de secours (passif) du cluster en haute disponibilité. Il reprend automatiquement les adresses IP virtuelles (VIP CARP) si pfSense-01 tombe en panne, et conserve les sessions actives grâce à la synchronisation des états et de la configuration. Après la bascule, il assure les mêmes fonctions de routage, de filtrage et de NAT, avec la même politique de filtrage.
CLIENTS — 172.16.1.0/24
Réseau des postes clients, dont les adresses IP sont attribuées par DHCP. Il sert à valider l'accès aux services et les règles de sécurité.
PC01
Poste client Windows 11 du réseau CLIENTS. Il sert à valider l'accès aux services et les règles de sécurité. Son adresse IP est attribuée par DHCP. Wireshark est installé pour effectuer des captures lors des dépannages.
PC02
Poste client Windows 11 du réseau CLIENTS. Il sert à valider l'accès aux services et les règles de sécurité. Son adresse IP est attribuée par DHCP. Wireshark est installé pour effectuer des captures lors des dépannages.
SERVEURS — 172.16.2.0/24
Réseau qui regroupe les serveurs de la ferme : les deux contrôleurs de domaine, la base de données, GLPI, Zabbix et Nextcloud. Ils ont tous une adresse IP fixe.
WS2025-AD01
Contrôleur de domaine principal, sous Windows Server 2025. Il héberge les services AD DS, AD CS, DNS et DHCP du domaine mathys-demon.lan. Ils assurent l'authentification centralisée, la gestion des comptes, la signature de certificats par une autorité de certification, la résolution des noms internes et la distribution de la configuration IP au réseau CLIENTS. Il applique aussi des stratégies de groupe (GPO). Wireshark est installé pour analyser les paquets lors des diagnostics réseau.
WS2025-AD02
Contrôleur de domaine secondaire, sous Windows Server 2025, pour la redondance. Il héberge les services Active Directory, DNS et DHCP, et garantit la continuité de l'authentification, de la résolution de noms et de la distribution des adresses IP si le contrôleur principal est indisponible. Wireshark est installé pour analyser les paquets lors des diagnostics réseau.
DEB13-MariaDB
Serveur de bases de données sous Debian 13. Il héberge MariaDB, utilisé par GLPI, Zabbix et Nextcloud, ainsi que phpMyAdmin pour administrer les bases de données depuis une interface web. phpMyAdmin n'est accessible que depuis le réseau ADMIN. Fail2Ban, tcpdump et termshark sont installés.
DEB13-GLPI
Serveur Debian 13 dédié à la gestion du parc informatique et des incidents. Il héberge GLPI, qui permet le suivi des tickets, des demandes, des équipements et des interventions. Le service est publié en HTTPS. Fail2Ban, tcpdump et termshark sont installés.
DEB13-Zabbix
Serveur Debian 13 de supervision de l'infrastructure. Il héberge Zabbix, qui surveille la disponibilité et les performances des équipements et des services, avec un tableau de bord en temps réel. Je n'ai pas mis en place de remontées d'alertes (e-mail, SMS…), car la ferme était arrêtée chaque fois que j'avais fini de travailler dessus. Le service est publié en HTTPS et n'est accessible que depuis le réseau ADMIN. Fail2Ban, tcpdump et termshark sont installés.
DEB13-Nextcloud
Serveur Debian 13 dédié au partage et à la synchronisation de fichiers. Il héberge Nextcloud, un espace collaboratif sécurisé avec gestion des droits d'accès, pour faciliter l'échange de documents. Le service est publié en HTTPS. Fail2Ban, tcpdump et termshark sont installés.
ADMIN — 172.16.3.0/24
Réseau d'administration. Les serveurs Windows (RDP) et Linux (SSH) ne peuvent être administrés que depuis le poste W11-Admin. phpMyAdmin et Zabbix ne sont accessibles que depuis ce réseau.
W11-Admin
Poste de travail Windows dédié à l'administration de l'infrastructure. C'est depuis lui que sont administrés les serveurs Windows (RDP) et Linux (SSH). Wireshark est installé pour analyser les paquets lors des diagnostics.
DMZ-FRONT — 172.16.4.0/24
La DMZ est segmentée en deux réseaux. DMZ-FRONT est le réseau d'exposition : il porte le reverse-proxy, qui publie l'intranet auprès des autres réseaux de la ferme.
DEB13-ReverseProxy
Serveur Debian 13 qui joue le rôle de reverse-proxy dans la DMZ. Il publie l'intranet auprès des autres réseaux, assure le routage et le NAT du réseau DMZ-BACK vers DMZ-FRONT, et répartit la charge entre DEB13-Web-01 et DEB13-Web-02. Fail2Ban, tcpdump et termshark sont installés.
DMZ-BACK — 172.16.5.0/24
Réseau privé entre le reverse-proxy et les serveurs web. Il est routé et traduit (NAT) par le reverse-proxy.
DEB13-Web-01
Serveur Debian 13 qui héberge le site intranet, une simple page web statique. Elle permet de vérifier que le service fonctionne et de voir sur quel serveur on se trouve, pour contrôler la répartition de charge 50/50. Il n'est accessible que par le reverse-proxy et n'est pas exposé directement sur le réseau. Le service est publié en HTTPS. Fail2Ban, tcpdump et termshark sont installés.
DEB13-Web-02
Serveur Debian 13 qui héberge la seconde instance de l'intranet, pour la redondance et la répartition de charge du service web principal. Comme DEB13-Web-01, c'est une simple page web statique qui indique sur quel serveur on se trouve. Il n'est accessible que par le reverse-proxy, en HTTPS. Fail2Ban, tcpdump et termshark sont installés.
Création d'un portfolio de type web
Contexte et objectif
Dans le cadre du BTS, le GRETA Ardèche-Drôme demandait la réalisation d'un site internet de type portfolio. Ce site devait présenter mon parcours, mes compétences et mes mises en situation professionnelles dans un format accessible et professionnel, et être consultable publiquement, en HTTPS, par le jury lors de l'examen. La mise en ligne et la rédaction devaient être terminées avant le 13 mai 2026. Le projet était estimé à environ une semaine, en comptant la mise en place de l'infrastructure et la création du contenu.
Le choix de WordPress auto-hébergé
J'ai comparé WordPress auto-hébergé et WordPress.com, une offre où la plateforme gère tout. J'ai choisi l'auto-hébergement. Je louais déjà un serveur Proxmox chez OVHcloud pour d'autres services, donc le coût supplémentaire se limitait au nom de domaine, acheté chez IONOS. L'auto-hébergement m'offrait aussi un contrôle total : thème et extensions sans restriction, configuration SSL, performances. C'était enfin une vraie montée en compétences dans l'administration système et réseau.
L'infrastructure et la mise en place
Le portfolio WordPress tourne sur trois VM Debian 13, hébergées sur mon serveur OVHcloud personnel : un reverse-proxy Nginx, un serveur Apache avec PHP 8.4 pour WordPress, et un serveur MariaDB.
La mise en place s'est faite dans cet ordre :
- Configuration de Cloudflare : enregistrement DNS, proxy activé, SSL en mode « Complet (strict) ».
- Configuration du reverse-proxy Nginx : redirection vers WordPress, redirections de HTTP vers HTTPS et du domaine sans « www » vers « www », certificat SSL généré avec Certbot.
- Configuration d'Apache2 sur la VM WordPress : écoute sur le port 81 et VirtualHost.
- Téléchargement de WordPress en ligne de commande, puis assistant d'installation, qui crée la base de données sur le serveur MariaDB.
- Installation du thème Astra et des extensions Spectra, SureForms, SureRank SEO, Subresource Integrity Manager et Yoast Duplicate Post. Je suis parti d'un modèle (template) trouvé sur WordPress, qui contenait déjà ce thème et ces extensions : je les ai donc gardés.
Les trois VM (le reverse-proxy, WordPress et MariaDB) sont sauvegardées automatiquement toutes les deux heures sur mon serveur OVHcloud. Ce serveur est lui-même sauvegardé vers un autre datacenter OVHcloud grâce à l'agent de sauvegarde fourni par OVHcloud.
Respect des visiteurs
Le portfolio n'a ni formulaire de contact, ni commentaires, ni cookies de tracking, ni outil d'analyse d'audience. Une page de politique de confidentialité l'explique. Il est hébergé chez OVHcloud, en France.
Difficulté et bilan
Le site a été mis en place dans le délai prévu, d'environ une semaine. Sa principale difficulté a été le fonctionnement de WordPress derrière un reverse-proxy : WordPress voyait une connexion en HTTPS côté visiteur, mais en HTTP entre le reverse-proxy et lui. Cela provoquait des boucles de redirection. J'ai résolu le problème en configurant une connexion HTTPS entre le reverse-proxy et WordPress, sans vérification du certificat, pour éviter de créer une autorité de certification locale.
Ce projet m'a fait comprendre en profondeur le fonctionnement des certificats SSL, gérés ici à trois niveaux : entre le visiteur et Cloudflare, entre Cloudflare et le reverse-proxy (Let's Encrypt via Certbot), et entre le reverse-proxy et WordPress.
Rédaction de plusieurs procédures
Ces onze procédures ont été rédigées au GRETA pour valider mon BTS. La plupart font suite à un TP réalisé en classe ; pour les autres, j'explique leur origine dans chaque présentation. La plupart suivent aussi le même plan : le besoin, les ressources, la comparaison de deux solutions, le choix argumenté, la mise en place, les tests et le bilan. Voici, pour chacune, pourquoi je l'ai réalisée et pourquoi j'ai choisi cette solution plutôt que l'autre.
La procédure sur la formation à Cyberelements est la seule réalisée en entreprise, au centre hospitalier de Valence, et elle compte aussi pour la validation du BTS.
Voir toutes les mises en situation (V1 du portfolio) (s'ouvre dans un nouvel onglet)
-
Mise en place d'un serveur de déploiement d'image – FOG
Ce TP consistait à déployer une image sur d'autres postes, en unicast puis en multicast, pour faciliter la mise en place d'un poste. J'ai comparé FOG et WDS, l'outil de Microsoft. WDS impose un serveur Windows avec une licence valide et ne gère pas nativement le déploiement de systèmes Linux. J'ai retenu FOG pour sa gratuité, sa mise en place facile et sa capacité à déployer n'importe quel système.
-
Mise en place d'un pare-feu avec redondance – PfSense
Ce TP demandait d'installer deux pare-feux synchronisés, avec une adresse IP virtuelle partagée, pour que les clients gardent la même passerelle même si l'un des pare-feux tombe en panne. J'ai comparé pfSense et Fortinet FortiGate. FortiGate est payant (matériel et licences) et repose sur un système propriétaire. pfSense est gratuit, open source, gère la haute disponibilité (CARP, pfSync) et fonctionne très bien en virtualisation : je l'ai retenu car il offre des fonctionnalités de niveau professionnel sans rien coûter.
Je l'ai réutilisé dans ma ferme de serveurs, où pfSense-01 et pfSense-02 fonctionnent de la même façon.
-
Installation et configuration d'un serveur GLPI
Ce TP consistait à installer un outil libre pour inventorier un poste Windows 11 grâce à un agent. J'ai comparé GLPI et OCS Inventory, deux logiciels libres qui tournent sous Linux. OCS est spécialisé dans l'inventaire et gère très peu, voire pas du tout, les tickets. GLPI y ajoute un vrai suivi des tickets : je l'ai jugé plus complet et mieux adapté à un environnement professionnel.
Je l'ai réutilisé dans ma ferme, où la VM DEB13-GLPI gère le parc informatique et les incidents.
-
Mise en place d'un serveur AD, DNS avec redondance
Ce TP demandait de mettre en place deux serveurs Active Directory et DNS qui se répliquent, pour que l'authentification et la résolution de noms continuent de fonctionner si l'un des deux tombe. J'ai comparé l'Active Directory de Windows Server et Samba 4. Samba est gratuit mais plus technique, avec des stratégies de groupe (GPO) partielles et une réplication plus sensible. L'AD de Windows est payant, mais nettement plus simple à déployer et bien moins risqué à maintenir.
Ma ferme repose sur le même principe : WS2025-AD01 et WS2025-AD02 sont deux contrôleurs de domaine redondants.
-
Mise en place d'un tunnel OpenVPN avec certificats AD CS
Ce TP consistait à créer un tunnel VPN dont les utilisateurs s'authentifient par des certificats émis par l'autorité de certification de Windows (AD CS) et distribués par GPO. J'ai comparé OpenVPN et WireGuard. WireGuard est plus rapide et plus léger, mais son intégration avec une infrastructure de certificats est moins aboutie. OpenVPN s'intègre nativement à AD CS et permet de révoquer des certificats. Je l'ai retenu pour son authentification forte par certificats, qui élimine les risques liés aux mots de passe faibles.
J'ai ensuite réutilisé AD CS dans ma ferme : WS2025-AD01 héberge l'autorité de certification, qui signe par exemple le certificat HTTPS de Zabbix.
-
Mise en place d'un serveur DHCP
Ce TP demandait de mettre en place un DHCP redondant, avec un relais DHCP sur pfSense pour le second sous-réseau, afin que les clients des deux sous-réseaux obtiennent une configuration IP même si le serveur principal est indisponible. J'ai comparé le DHCP de Windows Server et Kea, sous Linux. Kea est gratuit et flexible, mais sa haute disponibilité est plus complexe à mettre en place. Sous Windows, la redondance est intégrée et se configure directement depuis la console DHCP, ce qui convient à une infrastructure Windows.
Dans ma ferme, le DHCP du réseau CLIENTS est assuré par mes deux contrôleurs de domaine.
Voir la procédure (PDF) « Mise en place d'un serveur DHCP » (s'ouvre dans un nouvel onglet)
-
Développement d'un site internet type portfolio
Le GRETA demandait un portfolio accessible publiquement, pour que le jury puisse le consulter à l'examen. Cette procédure décrit sa création, la comparaison entre WordPress auto-hébergé et WordPress.com, et les raisons de mon choix. Le détail se trouve dans la partie « Création d'un portfolio de type web », plus haut.
-
Mise en place d'un serveur de supervision Zabbix
Contrairement aux précédentes, cette procédure ne vient pas d'un TP : je l'ai rédigée après avoir mis en place Zabbix sur ma ferme de serveurs, pour en superviser en temps réel la disponibilité. J'ai comparé Zabbix et Centreon. Chez Centreon, la cartographie, les rapports et la haute disponibilité sont réservés aux versions commerciales. Zabbix est entièrement gratuit, propose des agents natifs, des modèles (templates) gratuits, une authentification native avec l'AD (LDAP) et une API REST : c'est celui que j'ai retenu.
Il tourne sur la VM DEB13-Zabbix, accessible en HTTPS depuis le réseau ADMIN.
-
Analyse d'un Contrat de service
Nous devions tous réaliser une procédure d'analyse d'un contrat de service. J'ai analysé celui de mon propre hébergeur, OVHcloud : ses conditions générales de services, dans leur version du 17 janvier 2025. J'y ai relevé la hiérarchie des documents contractuels, ainsi que les niveaux de service et les crédits en cas d'indisponibilité. J'y ai aussi relevé une responsabilité plafonnée au montant payé sur six mois, une sauvegarde entièrement à la charge du client et des modifications possibles avec un préavis de 30 jours. Mon bilan : un contrat relativement équilibré, mais avec plusieurs clauses favorables au prestataire.
Voir la procédure (PDF) « Analyse d'un Contrat de service » (s'ouvre dans un nouvel onglet)
-
Veille technologique Rapports du CERT-FR
Le BTS demande de mener une veille technologique sur un sujet libre. J'ai choisi les rapports du CERT-FR et automatisé cette veille avec n8n, hébergé sur mon propre serveur. Le fonctionnement est le suivant : des flux RSS alimentent un salon Discord ; les liens sont analysés dans un Projet Claude, qui produit des données structurées ; celles-ci alimentent ensuite une base Notion publique, présentée sous forme de calendrier.
J'ai comparé n8n auto-hébergé et Inoreader, un service en ligne payant sans intégration native avec Discord ni Notion. n8n ne me coûte rien de plus, puisque mon infrastructure existait déjà. L'IA aide à analyser les rapports, mais ne dispense pas d'un regard critique sur ses résultats.
Voir la procédure (PDF) « Veille technologique Rapports du CERT-FR » (s'ouvre dans un nouvel onglet)
-
Formation utilisateurs à Cyberelements
Cette procédure ne vient pas d'un TP : elle est née d'un projet du centre hospitalier de Valence, où j'ai fait mon alternance. Elle a pourtant compté pour la validation de mon BTS au GRETA.
Le besoin
L'hôpital disposait de deux accès à distance à sa ferme RDS, qui permet de travailler à distance sur les applications métiers. Le premier, RDS Web Access, est intégré à Windows Server mais assure peu de sécurité et oblige à exposer les serveurs RDS sur Internet. Le second, Cyberelements, est un service en ligne qui sert de passerelle sécurisée. Un audit réalisé avec SILENE, un outil de l'ANSSI qui repère les failles exposées sur le web, a montré qu'il fallait sécuriser l'accès à distance à la ferme.
La solution choisie par l'hôpital
Avec Cyberelements, l'utilisateur ne se connecte plus directement à la ferme : il s'authentifie sur un portail avec son identifiant, son mot de passe, un code TOTP et une vérification de son ordinateur. La ferme RDS n'est plus exposée sur Internet. C'est une approche « Zero Trust » : on vérifie l'identité de l'utilisateur et l'état de son poste avant chaque accès.
Ma mission
J'avais sept mois pour appeler, migrer et former chaque utilisateur concerné : les télétravailleurs, les personnes d'astreinte et celles qui se connectent au dossier patient informatisé, comme les sages-femmes libérales. Un collègue avait mis en place un script qui listait chaque jour, dans un fichier Excel, les utilisateurs connectés à la ferme sans passer par Cyberelements. Grâce à ce script, j'ai établi une liste d'environ 150 utilisateurs.
Ma méthode
Avant d'appeler qui que ce soit, j'ai testé sur un compte Active Directory dédié pour comprendre le rôle de chaque groupe lié à Cyberelements. Lors des appels, j'ai adapté mon approche : certains utilisateurs ont suivi les procédures en autonomie, d'autres ont préféré que je les accompagne pas à pas. Un suivi rigoureux sous Excel recensait les personnes à contacter, celles déjà jointes et celles injoignables, ainsi que les rappels à faire et les incidents.
Un suivi régulier
Je faisais un point chaque semaine avec mon tuteur. Il m'a orienté sur la méthode à adopter pour les appels et m'a encouragé à contacter activement les utilisateurs. Il relisait aussi mes procédures : selon les cas, il les validait ou demandait des corrections.
Les conséquences du changement
Chaque utilisateur doit disposer d'un appareil mobile compatible pour recevoir le code TOTP. Pour l'équipe informatique, cela ajoute du travail : enregistrer les comptes et aider les personnes qui n'ont plus accès à leur code, par exemple après la perte ou la réinstallation d'un téléphone.
La passation
En fin de projet, j'ai formé les équipes du support informatique et les personnes d'astreinte, pour qu'elles prennent le relais en toute autonomie grâce aux procédures que j'avais rédigées.
Confidentialité
L'hôpital est un établissement de santé public : je ne suis pas autorisé à détailler sa configuration réseau. La procédure ne contient donc qu'un schéma simplifié, et le document destiné aux utilisateurs a été modifié pour cette raison.
Voir la procédure (PDF) « Formation utilisateurs à Cyberelements » (s'ouvre dans un nouvel onglet)