Configuration Système
Définition
La configuration système regroupe l'ensemble des actions visant à installer, paramétrer et maintenir un système d'exploitation et ses services dans un état fonctionnel, cohérent et sécurisé. Elle couvre les fondamentaux comme la gestion des processus, des utilisateurs, des droits d'accès et des services, ainsi que des configurations plus avancées : serveurs web (Nginx, Apache), serveurs DNS (Bind9), reverse proxies, WAF (BunkerWeb, CrowdSec), stacks de centralisation de logs (ELK, Graylog), solutions SIEM (Wazuh, Security Onion), monitoring (Zabbix, CheckMK) et services métiers spécifiques.
Cette compétence est le fil rouge de tout métier d'ingénieur infrastructure. Elle conditionne directement la stabilité, la performance et la sécurité de tout ce qui tourne au-dessus. En 2024 et 2025, plusieurs incidents médiatisés (CrowdStrike, fuites massives liées à des certificats expirés, ransomwares exploitant des services mal configurés) ont rappelé qu'une mauvaise configuration suffit à neutraliser une infrastructure pourtant correctement dimensionnée. C'est ce qui rend cette compétence à la fois technique et critique.
Familles d'OS pratiquées
Services régulièrement configurés
La compétence en pratique
Mettre en place et opérer une stack de supervision sécurité de bout en bout
Pendant ma mission chez Valesys, j'ai conçu et configuré l'intégralité de la stack de supervision et sécurité, à l'exception de l'Active Directory géré par un collègue. La pile comprenait Wazuh comme SIEM, ELK (Elasticsearch, Logstash, Kibana) pour la centralisation et l'exploration des logs, Graylog en complément sur certains flux, Grafana pour la visualisation, Zabbix pour le monitoring d'infrastructure, Passbolt pour la gestion des secrets, et Bind9 pour le DNS interne, le tout exposé via du reverse proxy Nginx.
Le travail ne se limitait pas à l'installation. Pour Wazuh, j'ai dû passer plusieurs semaines à comprendre en profondeur comment l'outil fonctionne : le moteur de règles XML, la corrélation d'événements, les decoders, l'intégration avec les agents distants et la manière dont les alertes sont remontées dans le format compatible Elasticsearch. Sur l'ELK, j'ai défini les politiques de rétention via ILM (hot / warm / cold), construit des pipelines Logstash spécifiques pour parser les logs entrants (pare-feu, sondes, serveurs), et structuré les index pour rester performant à mesure que la volumétrie grossissait.
Sur la stack web, le reverse proxy Nginx a demandé plusieurs jours d'optimisation : tuning des workers, gestion des buffers pour les uploads lourds, terminaison TLS, headers de sécurité, isolation des back-ends. Et pour Bind9, l'apprentissage initial m'a coûté quelques heures de lecture de la documentation officielle, mais a ensuite permis de gérer proprement les vues internes / externes et les délégations de zones.
Configurer et exploiter des services en environnement opérateur
Chez Paritel, l'échelle change radicalement. J'interviens dans une équipe Sécurité & Réseaux qui gère le SI interne et le cœur de réseau d'un opérateur. Côté configuration système, je suis amené à configurer et exploiter plusieurs outils de monitoring et de sécurité simultanément : Security Onion pour la détection réseau, CrowdStrike pour l'EDR, les remontées de pare-feu Juniper, Fortinet et Palo Alto, le SSO 1Password, ainsi que Mimecast pour la sécurité de la messagerie, avec une visualisation centralisée dans ELK.
La volumétrie quotidienne dépasse 500 000 requêtes traitées par jour et environ 100 000 alertes IPS remontées par les firewalls. À cette échelle, la moindre configuration mal pensée a un impact direct : un parser Logstash mal calibré sature l'index Elasticsearch en quelques heures, une règle Wazuh trop bruyante noie les vraies alertes, un certificat expiré coupe un service entier. C'est exactement le contexte dans lequel cette compétence prend tout son sens.
Une crise d'expiration de certificat qui a façonné ma méthode
L'épisode le plus formateur de ma jeune carrière reste un incident sur un certificat X.509 expiré au niveau d'un service de VOIP. Aucune alerte d'expiration n'avait été mise en place sur ce certificat. Il a expiré une nuit, déclenchant immédiatement une astreinte. Conséquence directe : environ 5 000 clients privés de service pendant 4 heures, le temps de réémettre, redéployer et propager le certificat. Je n'ai pas géré l'astreinte moi-même mais j'étais en première ligne dans l'analyse du post-mortem.
De mon côté, j'ai aussi vécu une situation plus modeste mais avec la même cause racine : un certificat à renouveler en urgence parce que la procédure de monitoring d'expiration manquait. Les enseignements ont été clairs et durables : tout déploiement en production nécessite désormais un plan d'action écrit avant exécution, et tout certificat doit être suivi par une alerte automatisée 30 jours avant expiration minimum. C'est aussi l'origine de mon habitude de ne plus dépendre uniquement de Let's Encrypt sur les infrastructures critiques, où j'utilise désormais d'autres autorités de certification quand le contexte le justifie.
Auto-héberger ce portfolio comme démonstration vivante
Le portfolio que vous consultez actuellement est lui-même auto-hébergé sur mon homelab. Il tourne sur une VM Debian hébergée sur mon cluster Proxmox personnel, derrière un serveur Apache configuré avec les bonnes pratiques de durcissement (modules inutiles désactivés, headers de sécurité, journalisation). L'exposition Internet passe par une redirection NAT, avec un nom de domaine et un certificat X.509 émis par une autorité externe, et une protection CrowdSec en frontal pour filtrer les comportements suspects.
Le déploiement de chaque version se fait via un script Bash idempotent que j'ai écrit moi-même, qui prend en entrée un zip, vérifie les prérequis, sauvegarde la version précédente, redéploie, applique les permissions et recharge Apache. Ce script illustre concrètement comment je conçois la configuration système : reproductible, traçable et réversible.
Mon niveau de maîtrise
Je distingue mon niveau selon les familles de systèmes et de services, car la réalité de mon expérience est très contrastée. Sur Linux, je me considère comme très à l'aise en relatif, c'est-à-dire par rapport à ce qu'on attend d'un ingénieur infrastructure junior. En absolu, par rapport à l'objectif que je me suis fixé (devenir un contributeur reconnu de l'écosystème libre), il me reste un palier à franchir notamment sur la compréhension fine du kernel et la construction de distributions sur mesure.
Contextualisation : ma compétence est très solide sur les environnements Linux de production de taille petite à moyenne (TPE, PME, infrastructure opérateur). Elle resterait en progression sur des environnements grand compte avec des centaines de serveurs gérés par configuration management industrialisé (Ansible Tower, Puppet, Salt à l'échelle), ou sur des environnements très spécifiques comme les systèmes temps réel, embarqués ou HPC, que je n'ai pas eu l'occasion de pratiquer.
Place dans mon profil et vitesse d'acquisition
Cette compétence est centrale et transverse à tout mon profil. Aucune autre compétence technique de mon portfolio ne s'exerce sans elle : la virtualisation déploie des systèmes qu'il faut configurer, le réseau interconnecte des services qu'il faut configurer, le scripting automatise des configurations système. Dans mon métier actuel comme dans le métier que je vise (architecte infrastructure orienté sécurité), la configuration système est la compétence sur laquelle tout le reste s'appuie.
Vitesse d'acquisition : elle a été progressive plutôt que fulgurante. La nature de cette compétence rend l'apprentissage cumulatif sur plusieurs années, pas instantané. En revanche, ma capacité à m'approprier un nouveau service rapidement est bien réelle : quelques heures pour Bind9, quelques jours pour optimiser un reverse proxy Nginx, quelques semaines pour comprendre Wazuh en profondeur. Cette accélération vient surtout du nombre de systèmes différents que j'ai déjà manipulés, ce qui crée des automatismes de lecture et de diagnostic transférables d'un outil à l'autre.
Mon recul sur la compétence
Avec l'expérience que j'ai aujourd'hui, je conseille en premier lieu de lire la documentation officielle, sérieusement et complètement, plutôt que d'enchaîner les tutoriels YouTube qui survolent. Une documentation officielle, c'est dense, mais c'est ce qui distingue ceux qui savent vraiment de ceux qui répètent.
Je conseille ensuite de comprendre l'histoire du système ou du service qu'on configure. Pourquoi Bind9 fonctionne ainsi ? Quelle réalité technique a fait naître Wazuh à partir d'OSSEC ? Quelles contraintes ont façonné Apache puis Nginx ? L'histoire donne le sens des choix de conception, et le sens des choix de conception donne la maîtrise des paramètres.
Une autre habitude utile est d'essayer de penser comme le développeur du logiciel. Quand on configure un service, on est un utilisateur. Mais quand on a la curiosité d'aller lire un peu du code source, on comprend infiniment mieux pourquoi tel paramètre existe, et donc comment l'utiliser à bon escient.
Enfin, le conseil le plus important est probablement le plus banal : toujours utiliser, toujours pratiquer. Au bout de quelques mois sans manipuler une technologie, on perd directement certaines bases. La configuration système est une compétence qui s'entretient comme une langue vivante. Mon homelab personnel sert exactement à ça : maintenir vivantes des compétences sur des outils que je ne croise pas tous les jours en mission.
Évolution et formations
Mon objectif à 18-24 mois est de combler les zones où je sais aujourd'hui que je suis perfectible. Concrètement, je veux refaire de l'Arch Linux intensivement, car cela fait plusieurs mois que je n'en ai pas pratiqué et c'est l'une des distributions qui m'a le plus appris sur le fonctionnement bas-niveau de Linux. Je veux également creuser la compréhension du kernel Linux : comment il est compilé, ses sous-systèmes, ses mécanismes d'extension (modules, BPF/eBPF), pour ne plus traiter le noyau comme une boîte noire.
En parallèle, je veux orienter davantage ma configuration système vers la conteneurisation et l'orchestration, qui sont aujourd'hui ma principale marge de progression. Cela inclut la configuration de runtime de conteneurs (containerd, runc) et la compréhension des couches réseau et stockage qui les sous-tendent.
Sur le plan des lectures, je suis activement à la recherche d'un bon ouvrage sur le kernel. Deux références me semblent particulièrement adaptées à ma trajectoire et me sont régulièrement recommandées : "Linux Kernel Development" de Robert Love pour une vue d'ensemble du noyau et de ses sous-systèmes, et "Linux Device Drivers" de Corbet, Rubini et Kroah-Hartman pour la partie modules et pilotes. Je compte aussi me replonger dans la documentation officielle d'Arch (ArchWiki) qui reste l'une des meilleures sources techniques sur l'écosystème Linux. Ma veille technologique est aujourd'hui structurée autour de mes flux RSS, d'échanges réguliers avec des amis du milieu sur Keybase, et d'une consultation continue de Twitter sur les comptes pertinents (mainteneurs, chercheurs en sécurité, contributeurs reconnus).
Côté certifications, mes parcours en cours sur Microsoft Azure et Google Cloud Associate Cloud Engineer couvrent la configuration de systèmes en environnement cloud. À moyen terme, une certification Linux de type LPIC-2 ou RHCSA reste une option ouverte si elle s'avère pertinente pour un contexte professionnel précis.
Réalisations rattachées
Cette compétence est mobilisée dans la quasi-totalité de mes réalisations. L'Infrastructure sécurisée chez Valesys en est l'application la plus complète : configuration de bout en bout d'une vingtaine de services. La Sonde IDS conteneurisée illustre la configuration fine des outils de sécurité (Suricata, Zeek, Arkime). Enfin, le Portfolio auto-hébergé matérialise concrètement la compétence : ce que vous lisez tourne sur une configuration que j'ai entièrement définie et que je maintiens.