Virtualisation & Conteneurisation
Définition
La virtualisation sur hyperviseur repose sur un logiciel intermédiaire qui crée une couche d'abstraction entre le matériel et les systèmes invités, permettant à plusieurs environnements indépendants de fonctionner simultanément sur une même machine physique. L'hyperviseur répartit les ressources (CPU, mémoire, stockage, réseau) tout en garantissant l'isolation de chaque machine virtuelle.
La conteneurisation est une méthode complémentaire : les conteneurs partagent le noyau du système hôte, ce qui les rend plus légers et rapides à déployer. Docker standardise leur création, Kubernetes orchestre des dizaines à des milliers d'instances, et Terraform permet de provisionner l'infrastructure sous-jacente sous forme de code (IaC).
Contexte actuel : la virtualisation est un socle non négociable de toute infrastructure moderne. Avec la généralisation du cloud, la pression sur l'efficacité énergétique des datacenters et la montée des architectures hybrides on-prem / cloud, la maîtrise des hyperviseurs et de Kubernetes est devenue un prérequis. La fin annoncée du support de Broadcom-VMware pour les petits clients accélère par ailleurs l'adoption massive de Proxmox VE en France depuis 2024, ce qui correspond directement à mon environnement de travail.
Hyperviseurs utilisés
Conteneurisation & orchestration
La compétence en pratique
Bâtir une infrastructure virtualisée à partir de zéro chez une TPE
À mon arrivée chez Valesys en septembre 2023, l'infrastructure se résumait à un NAS et un pare-feu : pas d'hyperviseur, pas de VM, aucune segmentation, aucun environnement de test. Avec un autre alternant, nous avons récupéré un serveur Dell 1U d'occasion et déployé Proxmox VE dessus dès octobre 2023. En deux mois, j'ai mis en place le Proxmox Backup Server (PBS) avec déports des sauvegardes sur le NAS existant pour ne pas dépendre du serveur unique.
En mars 2024, l'entreprise a obtenu un budget pour un second serveur Proxmox hébergé en cloud. J'ai profité de cette opportunité pour déployer un cluster Ceph à 2 nœuds avec 2 To utiles par serveur, en miroir, ce qui nous a permis de basculer vers un stockage distribué et résilient.
Au final, l'infrastructure hébergeait une quinzaine de VM en production (DNS, reverse proxy Nginx, Passbolt, Zabbix, stack Wazuh/ELK/Graylog/Grafana, AD secondaire) et une vingtaine de VM de pré-production / lab pour tester les évolutions avant mise en service.
Une difficulté très formatrice est survenue avant le cluster : nous n'avions encore que 500 Go sur le premier serveur, et les logs ingérés par ELK ont saturé le datastore une nuit. Le Proxmox a crashé. Nous avons dû redémarrer en mode single-user Linux, identifier la VM en cause (la stack ELK), purger une VM de test inutile pour libérer de l'espace, et refaire toute la politique de rétention des logs ELK côté Elasticsearch (ILM policies, hot/warm tiers). Quelques semaines plus tard, une coupure de courant a confirmé l'autre faiblesse de l'architecture : un seul serveur physique signifiait l'indisponibilité totale de tous les services. C'est ce double incident qui a directement justifié la demande budgétaire pour un second nœud cloud et le déploiement du cluster Ceph.
Concevoir une sonde IDS conteneurisée publiée sur GitHub
En octobre 2025, j'ai démarré Docker-IDS-Sensor, un projet personnel visant à standardiser le déploiement d'une sonde réseau open source réunissant Suricata, Zeek, Arkime et un OpenCanary. Une v1 a été publiée environ un mois après le démarrage, et le projet a continué d'évoluer depuis.
J'ai conçu un Dockerfile par composant (Suricata, Zeek, Arkime, OpenCanary) à partir d'images Alpine Linux de base, puis l'orchestration via docker-compose. La stack OpenSearch / OpenSearch Dashboards utilisée comme backend SIEM s'appuie sur les images officielles, qui sont indispensables au fonctionnement de l'ensemble.
Difficulté technique principale : les versions récentes de Suricata et Zeek n'existent pas en image Docker officielle à jour. J'ai donc dû compiler ces outils depuis les sources dans des Dockerfiles multi-stage Alpine, en gérant les dépendances système (libpcap, hyperscan pour Suricata, etc.). Autre point sensible : faire fonctionner la capture réseau en mode promisc dans un conteneur. Cela impose de lancer les conteneurs avec --cap-add=NET_ADMIN et --cap-add=NET_RAW, et de soigner le binding des interfaces physiques (souvent en network_mode: host) pour que la sonde voie réellement le trafic. Sans ces réglages, les conteneurs démarrent sans erreur mais ne capturent rien, un faux positif silencieux particulièrement piégeux.
Multiples interfaces réseau : la sonde devait pouvoir surveiller plusieurs VLAN simultanément. J'ai donc paramétré chaque conteneur Suricata / Zeek pour écouter sur une interface spécifique, avec des fichiers de configuration générés dynamiquement à partir d'un fichier d'inventaire YAML simple à éditer.
Monter une infrastructure Docker + Kubernetes auto-hébergée pour combler ma marge sur l'orchestration
J'ai identifié l'orchestration Kubernetes comme la principale zone de progression de cette compétence. Plutôt que de me contenter d'un cours théorique, je construis depuis fin 2025 une infrastructure complète auto-hébergée sur mon homelab Proxmox, basée sur Docker puis Kubernetes : DNS interne, serveur web, reverse proxy, GitLab auto-hébergé avec runners CI/CD, et base de données PostgreSQL avec sauvegardes.
L'objectif est explicite : atteindre un niveau opérationnel équivalent à un administrateur systèmes junior sur K8s d'ici mi-2026, en confrontant la théorie à la pratique sur des services réels (pas des nginx-demo).
Mon niveau de maîtrise
Mon niveau varie fortement selon les briques techniques. Je préfère afficher honnêtement où je suis solide et où j'ai encore à progresser, plutôt que de revendiquer une maîtrise globale qui ne correspondrait pas à la réalité.
Contextualisation : ma maîtrise des hyperviseurs est solide en environnement PME ou opérateur télécom (Proxmox, Ceph 2-nœuds, VLAN multiples, PBS). Elle resterait en progression sur des environnements grand compte avec dizaines de nœuds, vMotion VMware multi-datacenter ou orchestrations VRO complexes, contextes que je n'ai pas encore rencontrés.
Place dans mon profil et vitesse d'acquisition
La virtualisation est pour moi une compétence socle, à priorité maximale dans mon profil d'ingénieur infrastructure orienté sécurité. Aucun projet récent que j'ai mené (chez Valesys comme chez Paritel) ne se serait fait sans elle : c'est ce qui rend une infrastructure déployable, testable, reproductible et résiliente.
Vitesse d'acquisition : j'ai appris Proxmox en 2 à 3 semaines d'usage intensif en septembre-octobre 2023, en lisant l'intégralité de la documentation officielle sur un week-end puis en l'appliquant en conditions réelles la semaine suivante. C'est ma méthode habituelle quand un sujet me passionne : je lis tout, puis je casse des labs jusqu'à ce que ça marche. La même méthode m'a permis de monter à un niveau opérationnel sur Ceph en environ un mois, et de publier la v1 de la sonde IDS Docker un mois après le démarrage.
Mon recul sur la compétence
Avec l'expérience que j'ai aujourd'hui, je conseille d'aborder la virtualisation par le dessin avant le clic. Une architecture qu'on n'arrive pas à schématiser sur papier est une architecture qu'on ne maîtrisera pas en production : les schémas réseau et système doivent exister avant que la première VM ne soit créée. C'est ce que j'ai appliqué systématiquement chez Valesys, et c'est ce qui a permis aux choix initiaux de rester cohérents tout au long du déploiement.
Je conseille aussi de lire la documentation officielle en entier, en une seule fois, plutôt que de la consulter par fragments selon les problèmes rencontrés. Survoler n'apprend rien : c'est en absorbant Proxmox, Docker ou Ceph d'un bloc qu'on capte les concepts ensemble, et qu'on évite les erreurs de débutant qu'on retrouve cinq mois plus tard en incident. Ma méthode personnelle est claire : un week-end de lecture intégrale, suivi d'une semaine de pratique en lab.
Enfin, et c'est probablement le conseil le plus important pour quelqu'un qui débute, il faut comprendre la différence fondamentale entre virtualisation et conteneurisation. Ce ne sont pas des outils interchangeables : un conteneur n'est pas une « petite VM ». Tant qu'on n'a pas intégré que le conteneur partage le noyau de l'hôte, on prend les mauvaises décisions d'isolation et de sécurité. Cette confusion est la première source d'erreurs que j'observe chez les autres apprenants autour de moi.
Évolution et formations
Mon niveau cible à 18-24 mois est d'atteindre une maîtrise opérationnelle complète sur Kubernetes (déploiement, observabilité, sécurité des workloads, networking) et de gagner en aisance sur l'IaC avec Terraform, afin de pouvoir concevoir des infrastructures hybrides on-prem / cloud sans dépendre d'un spécialiste.
Sur le plan des formations, je suis actuellement engagé dans plusieurs certifications cloud qui couvrent directement le volet virtualisation managée : Microsoft Azure Cloud Computing (en cours), avec un complément orienté workloads spécialisés sur Microsoft Azure IA (en cours), et l'Associate Cloud Engineer Google Cloud (en cours) pour me construire une vision multi-cloud et éviter de dépendre d'un seul fournisseur. Une certification Kubernetes reste à définir précisément en fonction de l'évolution de mon labo personnel, mais l'objectif est de valider formellement ce niveau d'ici fin 2026.
En complément, je maintiens une veille continue sur les documentations officielles de Proxmox, Docker et Kubernetes, sur les blogs techniques de la communauté Proxmox, ainsi que sur les release notes de Suricata, Zeek et Arkime qui conditionnent l'évolution de ma sonde IDS open source.
Réalisations rattachées
Cette compétence est mobilisée dans plusieurs réalisations détaillées. Infrastructure sécurisée illustre le déploiement Proxmox, PBS et Ceph en environnement de production TPE. Sonde IDS conteneurisée matérialise la conception et la publication open source d'une stack Docker complète. Enfin, l'Audit de sécurité mobilise quotidiennement des machines virtuelles jetables pour les phases de reconnaissance et de pentest.