Catégorie : B1.1 Patrimoine

Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.4 — Travailler en mode projet · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

L’IP2I (Institut de Physique des 2 Infinis de Lyon) est un laboratoire de recherche CNRS / Université Claude Bernard Lyon 1 rattaché à l’IN2P3. Son service informatique doit régulièrement préparer, réinstaller ou recycler des postes de travail pour les personnels et les nouveaux arrivants. Jusqu’ici, chaque installation était une opération manuelle : démarrage sur une clé USB, assistant d’installation, configuration poste par poste. Une méthode chronophage, non reproductible, et qui mobilise un technicien pendant toute la durée de l’opération.

Le cœur de mon projet de stage a consisté à mettre en place la pièce centrale d’une solution industrialisée : un serveur d’orchestration capable de piloter le déploiement automatisé des postes par le réseau.

Le besoin technique

Le besoin exprimé par le service était triple : pouvoir démarrer n’importe quelle machine du parc directement par le réseau (PXE), sans support amovible ; centraliser sur un seul serveur tous les services nécessaires à ce démarrage (attribution d’adresses IP, distribution des fichiers d’amorçage, mise à disposition des images systèmes) ; et disposer d’une interface d’administration claire permettant de déclarer une machine, de lui associer un comportement (installer tel système, capturer une image, effacer les disques) et de suivre les opérations.

La solution retenue : Foreman

Après étude, la solution retenue est Foreman, un outil open source de gestion du cycle de vie des serveurs et postes, très répandu dans les infrastructures Linux. Foreman présente plusieurs atouts décisifs pour le laboratoire : il regroupe et coordonne nativement tous les services du démarrage réseau (DHCP, TFTP, DNS) via son composant Smart Proxy, il s’appuie sur un serveur web Apache pour distribuer les fichiers volumineux, et son interface web permet de modéliser proprement l’infrastructure (organisation, emplacement, domaine, sous-réseau, plages d’adresses).

Le serveur a été installé sur une machine virtuelle Debian 12 hébergée sur l’hyperviseur Proxmox du laboratoire, dimensionnée en conséquence (l’installation échoue ou devient interminable en dessous d’un certain seuil de ressources). Point d’architecture important : la VM dispose de deux interfaces réseau. La première est raccordée au VLAN 30, le réseau de déploiement isolé présenté dans un article précédent, sur lequel le serveur rend ses services aux machines à installer et joue le rôle de passerelle. La seconde est raccordée au réseau du laboratoire et fournit l’accès à Internet, indispensable pour télécharger paquets et images. Cette séparation nette entre le réseau de service et le réseau d’accès structure toute la suite du projet.

Une fois le serveur opérationnel, les objets de base ont été déclarés dans l’interface : domaine, sous-réseau du VLAN 30 avec sa plage d’adresses réservée au déploiement, et comportement par défaut du menu PXE — un réglage discret mais essentiel, qui garantit qu’une machine démarrant en réseau sans déploiement programmé poursuit simplement son démarrage sur son disque, au lieu de rester bloquée.

La dimension sécurité

Le serveur n’expose ses services de déploiement que sur le réseau isolé du VLAN 30, jamais sur le réseau de production. Foreman génère ses certificats SSL à partir du nom complet de la machine, ce qui a exigé une configuration rigoureuse de la résolution de noms avant toute installation : une erreur à ce niveau compromet les certificats et la communication interne des composants. L’interface d’administration est protégée par authentification, et les journaux applicatifs (Foreman, Smart Proxy, Apache) sont identifiés et consultables pour analyser toute anomalie.

Ma plus-value personnelle

Au-delà de l’installation elle-même, ma contribution principale tient dans la fiabilisation et la documentation du processus. L’installation de Foreman sur Debian recèle plusieurs pièges non documentés que j’ai rencontrés, diagnostiqués et résolus : une ligne de configuration créée par défaut par Debian qui fait échouer les contrôles internes de Foreman, une base de données absente au premier lancement, des erreurs de connexion au démarrage du service web, ou encore l’obligation de conserver l’IPv6 actif sur l’interface de bouclage sous peine de casser la communication entre composants. Chacun de ces incidents a été analysé, corrigé, puis intégré à la procédure que j’ai rédigée avec mon tuteur — avec sa cause, son message d’erreur exact et sa résolution — afin que n’importe quel membre de l’équipe puisse reproduire l’installation sans retomber dans ces pièges. Le serveur validé en fin de procédure par un test grandeur nature (démarrage réseau d’une machine témoin, observation du dialogue DHCP et TFTP en temps réel) constitue le socle de tous les articles suivants : masterisation Clonezilla, effacement certifié ShredOS, déploiement AlmaLinux et automatisation Ansible.

La procédure technique détaillée pas à pas, avec captures d’écran et commandes complètes, est disponible en téléchargement au format PDF ci-dessous.

Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

Au sein du service informatique de l’IP2I (laboratoire de recherche en physique CNRS / Université Lyon 1), le serveur Foreman présenté dans l’article précédent fournit désormais tous les services de démarrage réseau. Restait à répondre à la vraie question du projet : comment installer automatiquement un système complet — système d’exploitation, applications, configuration — sur les postes de travail du parc, notamment les Dell Latitude récents qui équipent le laboratoire ?

Le besoin technique et l’obstacle rencontré

L’approche « classique » consiste à faire démarrer la machine sur l’installeur réseau d’une distribution Linux, puis à automatiser les réponses de l’assistant. Nous avons testé cette voie et nous nous sommes heurtés à un obstacle matériel de taille : les postes récents utilisent la technologie Intel VMD/RST, un contrôleur qui s’intercale entre le système et les SSD M.2 NVMe. Le pilote correspondant est absent de l’installeur réseau minimal de Debian : l’installeur ne « voyait » tout simplement aucun disque.

Plusieurs pistes ont été explorées méthodiquement. L’image Live complète de la distribution, qui embarque le pilote, détectait bien le disque — mais elle impose une installation manuelle via l’assistant graphique, ce qui allait à l’encontre de l’objectif d’automatisation. Nous avons été jusqu’à extraire le module pilote depuis le système de fichiers compressé de cette image Live pour tenter de l’injecter dans l’installeur réseau : le module se chargeait, mais le disque restait invisible. Ce travail d’investigation a permis de conclure en connaissance de cause : l’installation réseau classique n’était ni fiable ni maintenable sur ce matériel.

La solution retenue : le clonage d’image disque

La méthode finalement retenue renverse le problème. Plutôt que d’installer le système à distance, on prépare une seule fois un poste de référence complet — le « master » — puis on en capture une image disque intégrale (partitions, système, applications) que l’on redéploie ensuite à volonté sur n’importe quel poste du parc. L’outil choisi pour cela est Clonezilla, la référence open source du clonage de disques, intégré au démarrage réseau via Foreman.

Deux comportements ont été modélisés dans Foreman. Le mode « Capture » démarre un poste de référence sur Clonezilla et envoie son image vers le serveur. Le mode « Déploiement », déclinable pour chaque master (un master Debian minimal et un master Ubuntu bureau ont été produits), fait l’opération inverse : la machine cible démarre en réseau, récupère l’image et la restaure automatiquement sur son disque. La capture ne se fait qu’une fois ; le déploiement se répète autant que nécessaire — c’est là tout le gain : préparer un poste ne prend plus qu’un démarrage réseau et le temps de la copie, sans aucune intervention pendant l’opération.

La dimension sécurité

Les images disque contiennent des systèmes complets : leur transfert et leur stockage devaient être sécurisés. Les échanges entre le poste en cours de clonage et le serveur se font en SSH, avec une paire de clés dédiée et un compte de stockage spécifique aux images, distinct du compte administrateur du serveur. L’empreinte du serveur est vérifiée automatiquement au démarrage de Clonezilla, ce qui évite toute connexion vers un serveur usurpé — la machine cliente ne fait confiance qu’au serveur légitime. Enfin, l’ensemble du processus circule exclusivement sur le VLAN 30 isolé : ni les images, ni les postes en cours d’installation ne sont exposés au reste du réseau du laboratoire.

Ma plus-value personnelle

Ma contribution sur ce volet est double. D’abord, l’investigation technique autour d’Intel VMD : reproduire le problème, formuler des hypothèses, tester chaque piste (installeur réseau, image Live, extraction et injection du pilote) et documenter pourquoi chacune échoue ou réussit. C’est ce travail qui a justifié objectivement le choix du clonage, présenté et validé avec mon tuteur. Ensuite, l’automatisation complète de la chaîne : j’ai notamment mis en place le mécanisme qui permet à Clonezilla de s’authentifier tout seul auprès du serveur au démarrage, via un script qui récupère la clé et l’empreinte du serveur avant le clonage — sans lui, chaque opération aurait exigé une saisie manuelle, ruinant l’intérêt de l’automatisation. J’ai enfin rédigé la procédure complète en veillant à la rendre accessible : chaque terme technique (PXE, TFTP, initrd, master…) y est défini, pour qu’un technicien qui découvre le sujet puisse dérouler la procédure en autonomie. J’y ai aussi consigné les améliorations possibles identifiées, comme la détection automatique du disque cible, aujourd’hui fixé manuellement.

La procédure technique détaillée pas à pas, avec captures d’écran et commandes complètes, est disponible en téléchargement au format PDF ci-dessous.

Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

À ce stade du projet de masterisation mené à l’IP2I (Institut de Physique des 2 Infinis de Lyon), la chaîne Foreman + Clonezilla permet de déployer un système complet sur n’importe quel poste du parc en un démarrage réseau. Mais un poste cloné n’est pas encore un poste prêt : selon le service et le profil de l’utilisateur final — chercheur, doctorant, personnel administratif — les besoins applicatifs diffèrent. L’un aura besoin d’outils de calcul scientifique, l’autre d’une suite de visioconférence, un troisième d’un environnement de rédaction complet.

Le besoin technique

Maintenir un master par combinaison d’applications aurait été ingérable : chaque nouvelle demande aurait imposé de recréer et de restocker une image de plusieurs gigaoctets. À l’inverse, installer les applications à la main après chaque déploiement aurait réintroduit exactement le travail manuel que le projet visait à éliminer. Le besoin était donc clair : conserver un petit nombre de masters génériques, et personnaliser automatiquement chaque poste après son déploiement, en fonction d’une simple liste d’applications choisie au moment de la demande.

La solution retenue : Ansible déclenché au premier démarrage

L’outil retenu est Ansible, la référence open source de l’automatisation de configuration, explicitement adaptée à ce besoin : on décrit dans des « playbooks » l’état souhaité d’une machine (tel paquet installé, tel fichier présent), et Ansible se charge de l’atteindre de manière fiable et rejouable. Il fonctionne sans agent : seule une connexion SSH est nécessaire, ce qui allège les masters.

L’architecture mise en place fonctionne ainsi : les images masters embarquent un petit service système qui s’exécute une seule fois, au tout premier démarrage du poste fraîchement déployé. Ce service lit un fichier listant les applications demandées pour ce poste, puis déclenche depuis le serveur Foreman l’exécution des playbooks correspondants sur la machine. Une bibliothèque de playbooks a été constituée et testée pour couvrir les demandes courantes du laboratoire : outils de tracé scientifique, visioconférence, messagerie, distribution scientifique Python, environnement de composition de documents, synchronisation de fichiers. Ajouter une application au catalogue revient désormais à écrire et tester un playbook une seule fois — il devient ensuite disponible pour tous les déploiements futurs.

Le résultat concret pour le service : la préparation d’un poste, du déploiement de l’image à l’installation du dernier logiciel, ne demande plus aucune intervention manuelle. Le technicien déclare la machine, choisit un master et une liste d’applications, démarre le poste en réseau — et le récupère prêt à être remis à l’utilisateur.

La dimension sécurité

Toutes les communications entre le serveur et les postes reposent sur des clés SSH dédiées, sans aucun mot de passe stocké ni transmis. Le service de premier démarrage est conçu pour ne s’exécuter qu’une seule fois : un poste en production ne conserve pas de mécanisme d’exécution automatique dormant. Le caractère déclaratif d’Ansible est lui-même un atout de sécurité et de qualité : les playbooks sont relisibles, versionnables et rejouables à l’identique, ce qui élimine les écarts de configuration entre postes — un poste installé aujourd’hui est strictement identique à un poste installé dans six mois avec la même liste.

Ma plus-value personnelle

Ce volet est celui où j’ai le plus conçu « sur mesure ». Le mécanisme de personnalisation au premier démarrage n’existe pas clé en main : il a fallu articuler trois briques (le service embarqué dans le master, le fichier de description des applications, le déclenchement des playbooks via SSH) et les faire fonctionner ensemble de manière fiable, y compris dans le cas d’un poste sans liste d’applications, qui doit simplement démarrer sans erreur. J’ai construit et testé chaque playbook du catalogue individuellement avant de valider la chaîne complète de bout en bout : déploiement d’un master vierge, premier démarrage, installation automatique, vérification applicative. Cette approche par petites briques validées puis assemblées — que j’applique aussi dans mes projets personnels — s’est révélée précieuse pour isoler rapidement les problèmes. Enfin, ce travail m’a fait pratiquer un outil central du métier d’administrateur systèmes : Ansible est aujourd’hui un standard de l’industrie, et savoir concevoir des playbooks propres et idempotents est une compétence directement réutilisable.

La procédure technique détaillée pas à pas, avec captures d’écran et commandes complètes, est disponible en téléchargement au format PDF ci-dessous.

Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

Gérer le patrimoine informatique d’un laboratoire de recherche comme l’IP2I (CNRS / Université Lyon 1), ce n’est pas seulement déployer des machines neuves : c’est aussi organiser proprement la fin de vie du matériel. Les postes réformés, donnés ou recyclés quittent le laboratoire — mais leurs disques, eux, ont pu contenir des données de recherche, des documents internes, des identifiants. Un simple formatage ne suffit pas : les données restent largement récupérables avec des outils grand public.

Le service avait donc besoin d’un processus d’effacement systématique, fiable, et surtout traçable : pouvoir prouver, pour chaque machine sortie du parc, que ses disques ont bien été effacés, quand, et selon quelle méthode.

Le besoin technique

Le cahier des charges que nous nous sommes fixé était exigeant : l’effacement devait s’intégrer à l’infrastructure de démarrage réseau déjà en place (aucune clé USB à préparer, aucun assistant à dérouler), traiter tous les disques d’une machine sans oubli possible, produire une preuve formelle de l’opération, et acheminer automatiquement cette preuve jusqu’au responsable — le tout sans aucune intervention manuelle entre le démarrage de la machine et la réception du certificat.

La solution mise en œuvre

La solution retenue s’appuie sur ShredOS, un système minimaliste dont l’unique rôle est d’exécuter nwipe, l’outil open source de référence pour l’effacement sécurisé des disques. Intégré au serveur Foreman, le processus complet se déroule ainsi : la machine à recycler est déclarée dans Foreman avec le comportement « effacement », puis démarrée en réseau. Elle charge ShredOS, qui efface automatiquement l’intégralité des disques détectés, génère un certificat PDF d’effacement (méthode utilisée, disques concernés, horodatage, statut), transmet ce certificat au serveur, puis éteint la machine.

Côté serveur, j’ai construit la chaîne de traitement qui prend le relais : un service de dépôt reçoit les certificats, un mécanisme de surveillance détecte chaque nouveau fichier dès son arrivée, et le certificat est immédiatement envoyé par courriel au responsable via le relais de messagerie du laboratoire. Du point de vue de l’équipe, l’opération se résume à brancher la machine sur le réseau de masterisation, la démarrer, et recevoir la preuve d’effacement dans sa boîte mail.

La dimension sécurité

Ce projet est par nature un projet de sécurité : il protège le laboratoire contre la fuite de données via le matériel sortant, un risque souvent sous-estimé et directement lié aux obligations de protection des données. La traçabilité est au cœur du dispositif — le certificat PDF constitue la preuve opposable que l’effacement a eu lieu, archivable pour chaque machine réformée. La puissance de l’outil impose aussi ses garde-fous, que la procédure documente explicitement : le mode automatique efface tous les disques détectés sans distinction, il est donc impératif de débrancher tout support externe avant le démarrage. Enfin, le compte de dépôt des certificats sur le serveur est un compte dédié et confiné à son seul dossier de réception, sans accès au reste du système.

Ma plus-value personnelle

L’effacement en lui-même existait sous forme d’outil ; ma contribution a été d’en faire un service complet et autonome. J’ai conçu et assemblé toute la chaîne aval — réception des certificats, surveillance automatique des arrivées, envoi immédiat par courriel — en la construisant comme un vrai service système : elle démarre avec le serveur et fonctionne sans supervision. J’ai également apporté un soin particulier à la testabilité : la procédure inclut un test complet de la chaîne de bout en bout sans effacer le moindre disque, en déposant un fichier factice et en vérifiant sa réception par courriel. Ce réflexe — pouvoir valider un dispositif sans déclencher son action destructive — me paraît essentiel sur un outil de cette nature. Enfin, la procédure rédigée explique chaque construction utilisée, y compris pour un lecteur débutant, afin que le service reste exploitable et maintenable après mon départ du laboratoire.

La procédure technique détaillée pas à pas, avec captures d’écran et commandes complètes, est disponible en téléchargement au format PDF ci-dessous.

Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

Le projet de masterisation mené à l’IP2I (laboratoire de recherche en physique, CNRS / Université Lyon 1) couvrait d’abord les postes de travail. Mais le service informatique administre aussi des serveurs, pour lesquels les besoins diffèrent : dans le monde de la recherche et de l’IN2P3, c’est la famille Red Hat qui fait référence, et le laboratoire s’appuie sur AlmaLinux 9, distribution communautaire compatible. Il fallait donc étendre l’infrastructure de déploiement à ce second cas d’usage.

Le besoin technique

Contrairement aux postes de travail, où le clonage d’une image de référence est pertinent, un serveur se prête mal à cette approche : chaque serveur a une identité propre et doit être installé « au propre », avec les dernières versions des paquets, dans une configuration minimale et reproductible. Le besoin était donc une installation réseau entièrement automatisée : de la mise sous tension de la machine à un serveur joignable en SSH, sans répondre à une seule question de l’installeur. Une contrainte d’architecture s’ajoutait : les machines du réseau de déploiement (VLAN 30) n’ont volontairement aucun accès direct à Internet, alors que l’installation doit télécharger ses paquets depuis les dépôts officiels.

La solution mise en œuvre

La réponse s’appuie sur Kickstart, le mécanisme d’installation automatisée natif de la famille Red Hat : un fichier de réponses unique décrit toute l’installation (partitionnement, fuseau horaire, mot de passe, paquets, configuration réseau), et l’installeur Anaconda le déroule sans intervention. L’image de démarrage minimale est servie par le serveur Foreman, et les paquets sont téléchargés depuis les dépôts officiels au travers d’un proxy installé sur le serveur : c’est lui qui offre aux machines du réseau isolé une sortie Internet contrôlée, limitée à ce seul usage et aux seules machines du réseau de déploiement.

Le fichier de réponses ne se contente pas d’installer le système : il livre un serveur déjà conforme aux standards du service. Dès la fin de l’installation, la machine redémarre configurée, joignable, et prête à être administrée à distance — le technicien n’a littéralement qu’à la déclarer dans Foreman et à la démarrer en réseau.

La dimension sécurité

C’est le volet le plus abouti de ce projet. Chaque serveur installé sort durci : la connexion de l’administrateur à distance n’est possible que par clé SSH — toute tentative par mot de passe est refusée, le mot de passe restant utilisable uniquement sur la console physique ou l’hyperviseur. La clé du serveur d’administration est déposée automatiquement pendant l’installation, avec les permissions strictes exigées par SSH. L’accès Internet des machines en cours d’installation est canalisé par le proxy, jamais direct. Enfin, j’ai préparé la distribution centralisée des clés publiques de toute l’équipe informatique : le mécanisme est déjà intégré au fichier de réponses et conçu pour être tolérant — tant que le fichier de clés n’est pas publié, l’installation se déroule sans la moindre erreur ; le jour où il le sera, tous les nouveaux serveurs recevront automatiquement les clés de l’équipe, sans modifier quoi que ce soit à la procédure.

Ma plus-value personnelle

Ma contribution la plus significative sur ce volet est justement cette conception « prête pour demain ». Plutôt que de figer la procédure sur l’état actuel du réseau (qui ne permet pas encore au serveur de déploiement d’atteindre le stockage partagé où l’équipe centralise ses clés), j’ai écrit un mécanisme conditionnel et silencieux : il tente de récupérer le fichier des clés, l’utilise s’il existe, et s’efface proprement sinon. C’est une manière de penser l’automatisation que ce stage m’a apprise : un script robuste doit prévoir l’absence de ses dépendances. J’ai aussi documenté en détail le rôle de chaque directive du fichier de réponses — y compris les choix de sécurité et leurs conséquences pratiques — pour que la procédure serve de référence à l’équipe. Ce volet complète la couverture du parc : postes de travail par clonage, serveurs par installation automatisée, effacement certifié en fin de vie — l’ensemble du cycle de vie du matériel passe désormais par la même infrastructure.

La procédure technique détaillée pas à pas, avec captures d’écran et commandes complètes, est disponible en téléchargement au format PDF ci-dessous.

Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.2 — Répondre aux incidents et aux demandes d’assistance et d’évolution · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

Dès ma première journée de stage au service informatique de l’IP2I (Institut de Physique des 2 Infinis de Lyon), j’ai été plongé dans une réalité quotidienne du métier : l’arrivée d’un nouvel utilisateur. Dans un laboratoire de recherche, les arrivées sont fréquentes — doctorants, stagiaires, chercheurs invités, personnels administratifs — et chacune déclenche une chaîne d’opérations précises, à cheval entre l’administratif et le technique. J’ai suivi cette procédure pas à pas avec l’équipe, puis je l’ai documentée, ce qui m’a permis d’en comprendre chaque maillon et d’en faire une fiche réutilisable.

Le besoin : intégrer sans jamais improviser

Donner un accès au système d’information n’est jamais anodin. Le besoin auquel répond cette procédure est double : garantir que chaque nouvel arrivant dispose, dès son premier jour, de tout ce qui lui est nécessaire (compte, droits, poste de travail configuré) — et garantir tout autant qu’il ne dispose de rien de plus. Une intégration improvisée produit les deux défauts symétriques : l’utilisateur bloqué qui multiplie les demandes d’assistance, ou l’utilisateur sur-privilégié qui constitue une faille de sécurité durable.

La procédure observée et documentée

Le point de départ est une règle absolue : aucun compte n’est créé tant que le contrat de l’arrivant n’est pas administrativement validé. L’identité numérique découle du lien contractuel, jamais l’inverse.

La suite illustre la réalité d’un environnement hétérogène, typique des institutions de recherche. Le compte est d’abord créé dans l’annuaire historique des environnements Unix/Linux du laboratoire (NIS), avec des vérifications de cohérence pour écarter tout conflit avec l’existant — identifiant déjà pris, doublon d’identifiant numérique. Il est ensuite synchronisé avec Active Directory, l’annuaire Microsoft qui gouverne les ressources Windows, où l’objet utilisateur est complété avec les informations de l’arrivant et son service d’affectation. L’utilisateur est alors ajouté aux groupes correspondant à son profil : ce sont ces groupes qui portent les politiques de sécurité et les droits d’accès aux ressources partagées, plutôt que des droits attribués individuellement — un principe de gestion centralisée qui rend les droits lisibles, auditables et réversibles.

En parallèle du volet annuaire, l’équipement physique est préparé : poste de travail installé avec le système et les applications correspondant aux besoins exprimés, puis remis à l’utilisateur, avec un suivi assuré en cas de problème matériel dans les premiers jours.

La dimension sécurité

Cette procédure est une application concrète de la gestion des identités et des accès. Deux principes la structurent. Le premier est le lien strict entre existence contractuelle et existence numérique, qui évite les comptes orphelins ou anticipés — une source classique de failles. Le second est le principe du moindre privilège : les droits sont ouverts en fonction du service d’affectation, et seulement ceux-là. La gestion par groupes garantit de surcroît qu’un changement de politique de sécurité s’applique uniformément à toute une population, sans dépendre de la mémoire d’un administrateur.

Ma plus-value personnelle

Mon apport ici est celui du regard neuf qui documente. Une procédure vécue quotidiennement par une équipe finit par n’exister que dans les têtes ; en la suivant pour la première fois, j’en ai consigné chaque étape, chaque vérification et chaque justification dans une fiche structurée — une contribution directe à la base de connaissances du service, qui servira aussi bien aux prochains stagiaires qu’aux nouveaux membres de l’équipe. Cette immersion m’a aussi apporté une compréhension que les cours seuls ne donnent pas : la coexistence de deux annuaires (Unix et Windows) n’est pas une bizarrerie mais l’héritage assumé d’une infrastructure de recherche construite sur des décennies, et savoir travailler avec cet existant — plutôt que de rêver de tout refaire — fait partie intégrante du métier d’administrateur systèmes et réseau.

Le compte rendu détaillé de cette procédure est disponible en téléchargement au format PDF ci-dessous.

Compétences du Bloc B1 : B1.2 — Répondre aux incidents et aux demandes d’assistance et d’évolution · B1.1 — Gérer le patrimoine informatique

L’organisation et le contexte

Pendant mon stage au service informatique de l’IP2I (laboratoire de recherche en physique, CNRS / Université Lyon 1), un ticket d’incident a été ouvert : plusieurs prises réseau d’une salle du laboratoire étaient hors service, sans aucune connectivité. J’ai participé au diagnostic et à la résolution de cet incident aux côtés de l’équipe — une intervention en apparence banale, mais qui s’est révélée être un excellent cas d’école de démarche de diagnostic.

Le besoin : rétablir le service, mais méthodiquement

Face à un incident réseau, la tentation est de tester des solutions au hasard jusqu’à ce que « ça remarche ». La démarche appliquée ici est l’inverse : une résolution structurée — reproduire le problème, délimiter son périmètre exact, remonter la chaîne du plus proche de l’utilisateur vers les équipements actifs, isoler la cause, corriger, puis valider par des tests avant de clôturer le ticket. C’est cette rigueur qui permet non seulement de réparer, mais de comprendre ce qui s’est passé et d’éviter que l’incident se reproduise.

Le diagnostic, étape par étape

La première étape s’est jouée sur le terrain : brancher un équipement sur chacune des prises signalées pour confirmer le symptôme et cerner le périmètre — toutes les prises de la salle étaient-elles touchées, ou seulement certaines ? Cette qualification initiale oriente toute la suite : une panne généralisée pointe vers l’amont (équipement actif, lien montant), une panne isolée vers le brassage ou la prise elle-même.

L’investigation est ensuite remontée vers les équipements actifs desservant la salle : état des ports côté switch (voyants, statut des interfaces, journaux) et vérification des liaisons entre les switchs. C’est là qu’est apparue la première cause : un câble reliant deux switchs en cascade était tout simplement absent. Sans ce lien, tous les ports situés en aval de la rupture se retrouvaient privés de connectivité, quelle que soit leur configuration.

Le câble remis en place, les tests ont repris — et c’est ici que l’incident devient instructif : une prise fonctionnait, la suivante restait muette. La panne principale en masquait une seconde. L’investigation a révélé que deux ports avaient été inversés lors d’une rénovation de la salle : le brassage physique ne correspondait plus au brassage logique — la prise murale A aboutissait sur le port attribué à la prise B, et inversement. La correction a été effectuée sur le switch pour réaligner la configuration sur la réalité du câblage, puis chaque prise de la salle a été testée une à une avant validation et clôture du ticket.

La dimension sécurité et patrimoine

Cet incident dépasse le simple dépannage. Un brassage qui ne correspond plus à la documentation, c’est une perte de maîtrise du patrimoine réseau : le jour où un port doit être affecté à un VLAN précis ou isolé pour raison de sécurité, c’est potentiellement la mauvaise prise qui est touchée. L’incident illustre aussi les conséquences d’une intervention (ici, une rénovation de salle) menée sans phase de tests et sans mise à jour de la documentation à l’issue des travaux — une leçon directement applicable à tout changement sur une infrastructure.

Ma plus-value personnelle et ce que j’en retiens

Ce que je retiens de cette intervention tient en une phrase : résoudre la première cause ne suffit pas toujours. Les pannes réseau peuvent avoir des causes superposées, et seule la poursuite méthodique des tests — prise par prise, jusqu’au bout — a permis de découvrir le second problème derrière le premier. J’ai aussi mesuré la valeur du cycle de vie complet d’un ticket : le symptôme décrit par l’utilisateur n’est qu’un point de départ, et la clôture n’intervient qu’après validation complète, pas au premier signe d’amélioration. Enfin, cette intervention m’a convaincu qu’un réseau se gère autant avec de la documentation à jour qu’avec des équipements : c’est un réflexe que j’applique désormais systématiquement, y compris dans mes projets personnels.

Le compte rendu détaillé de cette intervention est disponible en téléchargement au format PDF ci-dessous.

Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.2 — Répondre aux incidents et aux demandes d’assistance et d’évolution · B1.5 — Mettre à disposition des utilisateurs un service informatique

Le contexte et l’objectif

Dans un cadre personnel, j’ai conçu et déployé pour un groupe d’amis une infrastructure complète autour d’un serveur de jeu ARK: Survival Ascended, hébergé sur ma machine. L’objectif dépassait le simple « faire tourner un serveur » : je voulais un service entièrement autonome, que n’importe quel membre du groupe puisse démarrer ou arrêter sans mon intervention et sans compétences techniques, avec la garantie que la sauvegarde du monde est toujours la plus récente, qu’aucune double instance ne tourne à l’insu du groupe, et que le serveur est toujours à jour.

Le besoin technique

Les exigences que je me suis fixées ressemblent à un vrai cahier des charges d’exploitation : accès réservé aux seuls membres du groupe, sans exposer ma machine sur Internet ; démarrage et arrêt « presse-bouton » par n’importe quel membre ; détection préalable d’une instance déjà en cours, localement ou chez un autre membre ; synchronisation systématique de la sauvegarde avant lancement et après arrêt ; et configuration identique quel que soit l’hébergeur du moment.

La solution mise en œuvre

L’architecture réseau repose sur Tailscale, un VPN maillé fondé sur WireGuard : chaque membre rejoint un réseau privé chiffré, et tous les appareils communiquent comme en réseau local. J’aurais pu ouvrir les ports du jeu sur ma box, mais ce choix aurait exposé mon adresse publique en permanence ; le VPN restreint l’accès aux seuls membres du réseau privé — plus sûr, et plus simple à maintenir.

L’automatisation a été construite par preuves de concept successives : chaque brique (lancement du serveur avec tous ses paramètres, détection d’une instance en cours, synchronisation de la sauvegarde) a d’abord été développée et testée isolément, puis les briques validées ont été assemblées en scripts complets. La détection d’instance illustre bien la démarche : le script vérifie d’abord localement qu’aucun serveur ne tourne, puis interroge chaque machine du réseau privé sur le port du jeu avec un délai court, pour s’assurer qu’aucun autre membre n’héberge déjà la partie. La sauvegarde du monde et les fichiers de configuration sont centralisés sur un espace cloud partagé et synchronisés automatiquement : n’importe quel membre peut héberger, la partie reprend toujours là où elle s’était arrêtée. À l’arrêt, une commande d’administration distante ordonne d’abord la sauvegarde propre du monde, puis le serveur est arrêté et la sauvegarde renvoyée vers le cloud.

Le service a ensuite évolué en réponse à un problème d’exploitation récurrent : à chaque mise à jour du jeu, un serveur resté sur l’ancienne version refuse les connexions des joueurs à jour, et il fallait intervenir manuellement. J’ai donc fait évoluer le script de démarrage : il vérifie désormais, avant chaque lancement, si une mise à jour du serveur est disponible et l’applique automatiquement le cas échéant — puis enchaîne les contrôles habituels (détection d’instances, synchronisation de la sauvegarde) avant de démarrer. Cette évolution a fait disparaître la première cause de demandes d’assistance du groupe.

La dimension sécurité

Trois choix structurent la sécurité du service : aucune ouverture de port sur Internet, tout l’accès passant par le réseau privé chiffré ; une administration distante du serveur protégée par mot de passe et limitée au réseau local de l’hôte ; et une stratégie de sauvegarde systématique, synchronisée avant et après chaque session, qui protège les données du groupe contre la panne ou la fausse manipulation d’un hôte.

Ma plus-value personnelle

Ce projet est probablement celui qui ressemble le plus à de l’exploitation réelle : des utilisateurs non techniciens, un service qui doit fonctionner sans moi, des incidents (versions, doubles instances, sauvegardes divergentes) qu’il a fallu transformer en évolutions du service. J’y ai appris à concevoir pour les autres : les scripts sont « clé en main », prévoient les cas d’erreur et affichent des messages compréhensibles. La démarche par preuves de concept, la synchronisation cloud en ligne de commande, l’administration à distance et la supervision multi-machines sont autant de réflexes que j’ai directement réinvestis pendant mon stage.

La procédure technique détaillée, avec l’ensemble des scripts commentés, est disponible en téléchargement au format PDF ci-dessous.

Compétences du Bloc B1 : B1.3 — Développer la présence en ligne de l’organisation · B1.1 — Gérer le patrimoine informatique

Le contexte et l’objectif

Le site que vous êtes en train de lire est lui-même un projet du portfolio. Pour l’épreuve E5, j’avais besoin d’un espace de publication régulière : des articles présentant mes réalisations, classés par compétences du Bloc B1, enrichis au fil de la formation, avec des documents téléchargeables (les procédures techniques en PDF). Ce besoin éditorial — publication fréquente, taxonomie, gestion de médias, back-office — justifie cette fois pleinement un CMS, là où mon projet de site vitrine avait, pour un besoin inverse, justifié un site statique. J’ai choisi WordPress, le CMS le plus répandu, et je l’ai déployé sous forme conteneurisée avec Docker sur mon VPS personnel (Debian 12), qui héberge déjà d’autres services derrière Apache.

Le besoin technique

Le cahier des charges que je me suis fixé : une pile LAMP complète (Apache, MySQL, PHP) portant WordPress ; une cohabitation propre avec les services déjà en production sur le VPS, sans conflit de ports ni dépendances entremêlées ; des données strictement séparées du moteur applicatif, pour pouvoir mettre à jour ou reconstruire les conteneurs sans jamais toucher au contenu ; une exposition publique uniquement en HTTPS ; et une stratégie de sauvegarde complète et testée — un blog de portfolio qui perdrait ses articles la veille de l’épreuve serait un comble.

La solution retenue : la conteneurisation

Docker répond exactement à la problématique de cohabitation. Plutôt que d’installer PHP et MySQL directement sur le système — au risque d’entrer en conflit avec l’existant et de compliquer chaque mise à jour — la pile WordPress vit dans deux conteneurs isolés, décrits dans un unique fichier de composition : un conteneur applicatif (Apache + PHP + WordPress, l’image officielle) et un conteneur de base de données MySQL. Les données persistantes (base de données d’un côté, fichiers du site de l’autre) résident dans des volumes Docker dédiés, indépendants du cycle de vie des conteneurs : détruire et recréer la pile ne touche pas au contenu.

L’intégration au VPS suit une architecture de production classique : le conteneur WordPress n’écoute que sur l’interface locale de la machine, jamais directement sur Internet ; c’est l’Apache déjà en place sur le VPS qui joue le rôle de mandataire inverse (reverse proxy) et publie le blog sur son sous-domaine, avec un certificat TLS Let’s Encrypt renouvelé automatiquement. La base de données, elle, n’est joignable que depuis le réseau interne des conteneurs — elle n’expose aucun port, ni sur Internet, ni même sur le VPS.

Enfin, conformément à l’exigence de sauvegarde, un script automatisé exporte chaque nuit les trois composants vitaux — la base de données (export logique cohérent), les fichiers du site (thèmes, extensions, médias) et la configuration de la pile — avec une rotation des archives, et la procédure de restauration associée a été rédigée et testée : une sauvegarde dont on n’a jamais vérifié la restauration n’offre aucune garantie.

La dimension sécurité

La sécurité du déploiement repose sur la réduction de la surface exposée : un seul point d’entrée public (le reverse proxy en HTTPS), un conteneur applicatif confiné à l’interface locale, une base de données invisible de l’extérieur, et des secrets (mots de passe de la base) stockés dans un fichier d’environnement exclu de toute publication — jamais en dur dans la configuration. La conteneurisation apporte aussi une hygiène de maintenance : les mises à jour de WordPress, de PHP ou de MySQL se font en remplaçant les images, de façon réversible, les données étant hors des conteneurs. Les sauvegardes chiffrables et externalisables complètent le dispositif en couvrant le dernier risque : la perte du serveur lui-même.

Ma plus-value personnelle

Ce projet boucle la boucle du portfolio : l’outil qui présente mes compétences est lui-même une démonstration de ces compétences. J’y ai fait des choix d’architecture argumentés (conteneurisation pour la cohabitation, reverse proxy pour l’exposition, volumes pour la persistance) plutôt qu’une installation par défaut, et j’ai traité la sauvegarde comme une exigence de premier rang, avec script, planification, rotation et test de restauration. C’est aussi une réponse assumée à mon propre article sur le site vitrine : le bon choix technique dépend du besoin — statique quand le contenu est figé, CMS conteneurisé quand la publication est vivante. Savoir défendre les deux, c’est précisément ce que j’attends de moi en tant que futur administrateur.

La procédure technique détaillée pas à pas (déploiement Docker, reverse proxy, HTTPS) ainsi que la procédure complète de sauvegarde et de restauration sont disponibles en téléchargement au format PDF ci-dessous.