À propos
Étudiant en première année de BTS SIO option SISR au Lycée Vilgénis (Massy), je combine formation académique et expérience professionnelle concrète en alternance chez Essity à Saint-Ouen. Passionné par les infrastructures informatiques, le support et la résolution de problèmes, j'ai eu l'opportunité de travailler dans plusieurs environnements IT — dont un stage Erasmus+ en Irlande.
À l'aise dans de nouveaux environnements et face à de nouveaux défis.
Envie d'apprendre et de rester à jour dans les évolutions technologiques.
Capacité à travailler de manière indépendante et à prendre des initiatives.
Attention aux détails et respect des procédures pour un travail de qualité.
Expériences Professionnelles
4 expériences concrètes en support IT, déploiement et administration système.
Formations & Diplômes
Formation en alternance axée sur l'administration des réseaux, la cybersécurité, la virtualisation et la gestion des systèmes d'information en entreprise.
Spécialité Réseaux Informatiques et Systèmes Communicants. Section Européenne — enseignement en anglais technique.
Certifications
Préparation en cours pour la certification CCNA via Cisco Networking Academy. Fondamentaux réseaux, routage, switching et sécurité.
En préparationCertification attestant la maîtrise des fondamentaux du Règlement Général sur la Protection des Données.
CNIL · RGPDFormation en cybersécurité de l'Agence Nationale de la Sécurité des Systèmes d'Information.
ANSSICompétences
Réalisations
Des sites web simples, beaux et sur-mesure, pensés pour vous et votre activité.
Installation et configuration complète d'un environnement NixOS combiné avec le gestionnaire de fenêtres dynamique Hyprland (Wayland) sur machine personnelle, pour approfondir l'écosystème Linux avancé et la gestion des dotfiles.
ARDUINO UNO.
Série de projets électroniques réalisés avec Arduino, explorant l’IoT, la biométrie et les systèmes de sécurité embarqués.
Refonte complète du réseau d'un cabinet d'ingénierie de 25 collaborateurs : architecture, segmentation en 5 VLANs, plan d'adressage, brassage, conventions de nommage et sécurisation des accès.
Un robot lit mes sources à ma place et me livre 10 actualités sur Discord tous les deux jours : support IT, réseau, Microsoft, Apple, cybersécurité, IA. Cinq en français, cinq en anglais.
Un ancien PC recyclé en sonde de supervision : il centralise les logs de mes machines dans un SIEM, applique des règles de détection et me pousse une alerte sur Discord dès qu'un événement sort du cadre. Un SOC, à l'échelle d'un appartement.
Un poste de travail Linux 100 % déclaratif et reproductible — du noyau au moindre menu de la barre des tâches, tout est décrit en code Nix, versionné sur Git et reconstructible par une seule commande.
L'objectif n'était pas d'installer un bureau mais de construire le mien, brique par brique. Chaque fonctionnalité d'un environnement moderne (thème auto, dictée vocale, menus réseau, multi-écran) a été réimplémentée en modules Nix indépendants plutôt que consommée d'une suite toute faite. Résultat : un OS où rien n'est configuré « à la main quelque part » — tout est dans le code.
flake.lock).writeShellScriptBin), dépendances par chemin Nix exact. Zéro dépendance implicite.nixos-rebuild switch --flake .#pc1 reconstruit tout l'OS — rollback instantané vers n'importe quelle génération.display-apply (pc-only / external / extend / mirror), détection auto via hyprctl + jq.Je m'intéresse à pas mal de sujets en informatique : le support IT, le réseau, Windows et Apple, Linux, la cybersécurité, l'IA. Ça fait beaucoup de sites à ouvrir chaque matin — et en pratique, au bout de deux semaines on ne les ouvre plus. Alors je l'ai automatisé : mes sources sont relevées à ma place et 10 actualités, cinq en français et cinq en anglais, m'attendent sur Discord un matin sur deux. Court exprès, pour que ça se lise vraiment.
Flux officiels et presse spécialisée relevés à chaque passage, du CERT-FR à Apple.
Un job GitHub Actions part seul tous les 2 jours à 7h. Aucun serveur à maintenir.
Dédoublonnage, puis un tour de table entre les sujets : 5 actus FR et 5 EN, jamais deux fois le même thème.
Un message Discord structuré : urgences en tête, le reste groupé par famille de source.
Priorité aux sources de première main — celles qui publient l'information plutôt que celles qui la recopient.
Le robot ne fait que rassembler les actualités. C'est moi qui les lis : quand un sujet touche à ce que j'utilise au travail, j'ouvre l'article en entier.
Le message ci-dessous est le dernier rapport réellement produit par le robot, tel qu'il arrive dans mon salon Discord.
Node.js sans aucune dépendance, GitHub Actions en ordonnanceur, webhook Discord en sortie.JSON réutilisé par ce portfolio.J'ai un ancien PC dont je ne me sers plus. Plutôt que de le laisser prendre la poussière, je le transforme en sonde de supervision de sécurité pour mon réseau : il centralise les logs de mes machines — authentification, événements système, intégrité des fichiers, trafic réseau — les confronte à des règles de détection, et me pousse une alerte sur Discord dès qu'un événement sort du cadre. Le projet démarre : voici ce qu'est un SOC, pourquoi j'en monte un chez moi, et dans quel ordre je m'y prends.
SOC, pour Security Operations Center — centre des opérations de sécurité. Dans une entreprise, c'est l'équipe et les outils chargés de surveiller le système d'information en continu : repérer ce qui sort de l'ordinaire, qualifier l'événement, et réagir avant qu'il devienne un incident. Techniquement, ça tient en trois gestes.
Chaque hôte et chaque équipement réseau produit des logs en continu : auth.log, journaux d'événements Windows, flux du pare-feu. Un agent les remonte vers un collecteur unique — le SIEM — où ils sont normalisés et indexés. Sans ça, chaque journal reste sur sa machine : il faudrait se connecter à cinq machines chaque matin pour les relire, donc personne ne le fait, et un incident peut passer des mois sans être vu.
Des règles de corrélation confrontent ce flux à des comportements connus, chacune avec un niveau de criticité et souvent une correspondance MITRE ATT&CK : dix échecs d'authentification en une minute, une élévation de privilèges, un binaire déposé dans un répertoire surveillé.
L'alerte est poussée vers un humain qui la qualifie — c'est le triage : faux positif, ou vrai début d'attaque. Puis on isole, on corrige, et on écrit la règle qui évitera de repasser par là.
L'intérêt n'est pas d'empêcher l'attaque — le pare-feu et l'antivirus s'en chargent, et ils échouent parfois. L'intérêt, c'est de la voir. Le délai moyen entre une intrusion et sa découverte se compte encore en semaines : tout l'enjeu d'un SOC est de le ramener à des minutes.
J'ai écrit cette liste avant d'installer quoi que ce soit, et elle sert deux fois. D'abord comme objectif : voilà ce que le dispositif doit savoir repérer. Ensuite comme plan de test : je provoque moi-même chaque situation, et si l'alerte ne tombe pas, c'est que la règle est à corriger.
auth.log, technique T1110.EICAR sur un partage, attrapé par le contrôle d'intégrité (FIM) qui surveille les répertoires sensibles.nmap -sS lancé depuis mon portable vers le serveur, vu côté réseau par l'IDS.sudo ou une ouverture de session administrateur à une heure où je dors.Une alerte utile se lit sans ouvrir l'interface : quoi, où, qui, à quel point c'est grave. Voilà la forme que je veux obtenir — la barre de couleur donne le niveau, les champs donnent le contexte, l'identifiant de règle permet de retrouver l'événement dans le SIEM.
Ces deux messages sont des maquettes — le dispositif n'est pas encore monté. Ils reprennent les deux premières situations de la liste ci-dessus : ce sont les deux alertes que je devrai voir arriver pour de vrai avant de continuer.
Six étapes, dans cet ordre. Chacune doit fonctionner seule avant de passer à la suivante — sinon on ne sait plus ce qui casse.
Debian sur l'ancien PC, unattended-upgrades, SSH par clé avec mot de passe désactivé, pare-feu en refus par défaut, et la machine sur un segment à part. Une sonde de sécurité mal durcie n'est qu'une porte d'entrée de plus.
Le serveur Wazuh (manager + indexeur + tableau de bord), puis un agent sur chaque hôte — Windows et Linux. Les logs d'authentification, les événements système et le FIM remontent enfin au même endroit, normalisés, au lieu de dormir chacun dans leur coin.
Intégration custom côté Wazuh : au-delà d'un certain niveau de règle, l'alerte part vers un webhook Discord au format embed — je réutilise la brique déjà écrite pour mon bot de veille. Une alerte qui reste dans une interface qu'on n'ouvre pas n'existe pas.
Suricata en écoute sur un port miroir, jeu de signatures Emerging Threats, et ses journaux eve.json réinjectés dans Wazuh : une seule console pour l'hôte et le réseau.
Je rejoue moi-même les six scénarios listés plus haut — hydra sur mon propre SSH, nmap depuis le portable, dépôt d'un EICAR — et je vérifie que chacun déclenche la bonne règle, capture à l'appui. Une détection non testée n'est qu'une intention.
Le premier jour, le moteur sort des centaines d'alertes dont l'immense majorité est du bruit. Je les traite une par une — règle désactivée, seuil relevé, exclusion ciblée — en notant à chaque fois la raison. C'est la partie la plus longue, et la seule qui a vraiment de la valeur.
La base : version stable, empreinte mémoire faible, correctifs de sécurité pendant des années. Sur une machine qui doit tenir des mois sans intervention, c'est le seul critère qui compte.
Le SIEM, cœur du dispositif. Un agent HIDS sur chaque hôte remonte les logs, surveille l'intégrité des fichiers (FIM), cherche les rootkits et évalue la conformité. Le serveur normalise, applique les règles — indexées MITRE ATT&CK — et conserve l'historique.
L'IDS réseau (NIDS) : il inspecte les paquets en temps réel avec des signatures ouvertes (Emerging Threats). Wazuh entend ce que les machines déclarent ; Suricata voit ce qui circule réellement entre elles — scans, protocoles inattendus, destinations douteuses.
La sortie : un webhook qui reçoit l'alerte formatée en embed. C'est déjà là que tombe ma veille technologique — une seule application à surveiller, donc des alertes réellement lues.

EcoBat Solutions est un cabinet d'ingénierie de 25 collaborateurs spécialisé dans la rénovation énergétique. Son réseau avait grandi sans plan : tous les postes, serveurs et imprimantes vivaient dans le même VLAN par défaut, sans documentation ni convention de nommage. Un prestataire de passage a fini par ouvrir le dossier « Direction » depuis le Wi-Fi visiteurs — rien ne l'en empêchait. On nous a confié la reprise complète de l'infrastructure : architecture, adressage, brassage, nommage, services et sécurité.
Mon rôle : découper le projet, répartir les lots entre les administrateurs et les techniciens, tenir le planning, arbitrer les choix techniques — et rédiger la documentation remise au client à la fin.
Réseau reconstruit autour d'un cœur de commutation de niveau 3 : routage inter-VLAN centralisé, liens montants en trunk 802.1Q, switches d'accès et switch PoE pour la téléphonie et les bornes Wi-Fi.
Un VLAN par usage, plus aucun service dans le VLAN 1. Chaque service ne voit que ce qui le concerne, et le réseau d'administration est isolé du reste.
Un sous-réseau /24 par VLAN, plages DHCP pour les postes, adressage fixe pour les serveurs et les équipements réseau. Fini les IP posées à la main sans registre.
Reprise des trois baies : chaque port de patch panel tracé jusqu'à sa prise murale, VLAN affecté port par port, et un tableau de brassage tenu à jour pour que le prochain technicien s'y retrouve.
Une règle unique pour les équipements, les VLANs et les comptes : le nom dit le site, le rôle et le numéro. Un équipement inconnu devient identifiable sans ouvrir la doc.
Serveur Proxmox hébergeant Active Directory, DNS, DHCP et GLPI : annuaire unique, attribution d'adresses maîtrisée et inventaire du parc.
| VLAN | Service | Réseau IP | Adressage | Rôle |
|---|---|---|---|---|
| 10 | RH / Direction | 192.168.10.0/24 | DHCP | Accès serveurs de paie · confidentialité |
| 20 | Bureau d'études | 192.168.20.0/24 | DHCP | Accès plans techniques et outils CAO |
| 30 | Visiteurs | 192.168.30.0/24 | DHCP | Internet uniquement, coupé du reste par ACL |
| 99 | Management | 192.168.40.0/24 | Fixe | Administration des switches et du routeur (SSH) |
| 100 | Serveurs | 192.168.50.0/24 | Fixe | Active Directory · DNS · DHCP · GLPI |
Segmenter, ce n'est pas ranger : c'est décider qui peut parler à qui. Chaque choix d'architecture répond à un risque constaté chez le client.
SSH — plus de Telnet, plus d'accès depuis un poste utilisateur.Maquetter et éprouver l'architecture avant de toucher au réseau réel : VLANs, trunks, routage et ACL testés à vide, erreurs corrigées sans couper personne.
Mettre l'architecture au propre pour le client : un schéma physique et un schéma logique lisibles par quelqu'un qui n'était pas dans la salle.
Le cerveau du groupe : répartition des lots, avancement de chacun, décisions techniques datées. C'est là que se voyait, chaque semaine, ce qui avançait et ce qui bloquait.
Virtualiser les serveurs sur une seule machine : Active Directory, DNS, DHCP et GLPI montés séparément, sans multiplier le matériel.
Contact
Un site web à créer, une opportunité en IT, ou juste envie d'échanger ? Écrivez-moi.