Catégorie : B1.5 Service informatique

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.3 — Développer la présence en ligne de l’organisation · B1.4 — Travailler en mode projet · B1.5 — Mettre à disposition des utilisateurs un service informatique

L’organisation et le contexte

Dans le cadre d’un projet proposé en BTS SIO, j’ai réalisé le site vitrine de la Brasserie Terroir & Saveurs, une brasserie artisanale des Hauts-de-France souhaitant moderniser sa présence en ligne. L’objectif : un site présentant son identité, ses produits (bières et spiritueux) et ses informations de contact, mis en ligne et accessible publiquement.

Le cahier des charges fixait des contraintes précises : affichage du logo et de photos de la production, respect d’un code couleur cuivré (beige, ocre, marron, orange), barre de navigation structurant les rubriques, et fiches produits consultables pour l’ensemble des références.

Le besoin et l’analyse du cahier des charges

Derrière la demande « faire un site », le vrai besoin de l’organisation était une vitrine : un contenu stable, présenté avec soin, qui ne nécessite ni espace de publication régulière, ni comptes utilisateurs, ni fonctionnalités dynamiques. Cette analyse a directement orienté mes choix d’architecture — c’est elle qui distingue un projet réussi d’un projet techniquement surdimensionné.

Les choix techniques et leur justification

Le sujet préconisait WordPress. J’ai fait — et assumé — un choix différent : un site statique (HTML/CSS/JS) servi par Apache, hébergé sur mon VPS Debian 12 déjà en production pour d’autres services. La justification est concrète : un CMS complet implique une pile PHP, une base de données, et surtout une maintenance continue (mises à jour du cœur, des extensions, de la base), pour un site dont le contenu n’a pas vocation à changer chaque semaine. Sur un VPS aux ressources partagées entre plusieurs projets, un site statique est plus léger, plus rapide, et surtout n’ajoute aucune surface d’attaque à maintenir. À l’inverse, un besoin de publication éditoriale régulière justifierait pleinement un CMS — c’est d’ailleurs le choix que j’ai fait pour ce blog, dans un autre contexte et pour un autre besoin.

Pour la production du code, j’ai utilisé Lovable, un outil de génération de sites assisté par IA, en lui fournissant le cahier des charges complet et les ressources visuelles (logo, photos, fiches produits). Le rôle du technicien ne s’arrête pas à la génération, au contraire : la relecture systématique du code produit m’a permis d’identifier et de corriger une erreur réelle — deux bières inversées sur les fiches produits, les descriptions ne correspondant pas aux visuels — directement dans les fichiers avant toute mise en ligne.

Le déploiement a ensuite suivi un processus maîtrisé : transfert sécurisé des fichiers sur le VPS, configuration d’un hôte virtuel Apache dédié, et mise en production sur un sous-domaine propre au projet. Le résultat final respecte l’intégralité du cahier des charges : identité visuelle cuivrée sur toutes les pages, navigation vers les cinq rubriques, fiches consultables pour les cinq références, affichage adapté aux mobiles, et site publiquement accessible.

La dimension sécurité

Le choix du statique est en lui-même une décision de sécurité : pas de code exécuté côté serveur, pas de base de données exposée, pas de back-office à protéger ni de CMS à patcher en urgence à chaque vulnérabilité publiée. La surface d’attaque se réduit au serveur web lui-même, déjà administré et maintenu à jour sur le VPS. Le transfert des fichiers vers le serveur s’effectue exclusivement par canal chiffré, et le site est servi en HTTPS.

Ma plus-value personnelle

Ce projet démontre une compétence que je considère centrale : savoir justifier un choix technique face à une préconisation, en argumentant sur le besoin réel plutôt qu’en suivant l’outil à la mode. Il illustre aussi ma capacité à utiliser les outils de génération assistée par IA de manière professionnelle — comme des accélérateurs dont la production doit être relue, validée et corrigée, jamais comme des boîtes noires : l’erreur d’inversion des fiches produits, invisible sans relecture attentive, serait partie en production. Enfin, héberger le résultat sur ma propre infrastructure, plutôt que sur une plateforme clé en main, m’a fait pratiquer la chaîne complète de mise en ligne : du fichier local au site public, en passant par la configuration du serveur web.

La procédure de déploiement détaillée est disponible en téléchargement au format PDF ci-dessous, et le site est consultable en ligne.

Compétences du Bloc B1 : B1.5 — Mettre à disposition des utilisateurs un service informatique · B1.6 — Organiser son développement professionnel

Le contexte et l’objectif

Ce projet personnel est né d’un besoin simple : mon PC fixe sous Windows 11, puissant, reste à la maison ; mon PC portable sous Ubuntu m’accompagne partout. Je voulais pouvoir contrôler le fixe à distance depuis n’importe où — principalement pour jouer à mes jeux depuis le portable, sans transporter une machine lourde. Autrement dit : me construire mon propre service de cloud gaming, de bout en bout, sur ma propre infrastructure.

Au-delà du loisir, j’ai traité ce projet comme un vrai déploiement de service : besoin exprimé, solution choisie et justifiée, mise en œuvre par étapes validées, et automatisation jusqu’à ce que l’utilisation quotidienne ne demande plus aucune manipulation technique.

Le besoin technique

Le service à rendre se décompose en quatre exigences : diffuser le flux vidéo du PC fixe avec une latence compatible avec le jeu ; y accéder depuis n’importe quel réseau, pas seulement depuis la maison ; que les services nécessaires soient actifs dès l’allumage de la machine, sans intervention ; et pouvoir allumer le PC fixe à distance, car le laisser fonctionner en permanence n’était pas envisageable.

La solution, construite par étapes

J’ai avancé par étapes successives, en ne passant à la suivante qu’une fois la précédente validée. La première a établi la connexion en réseau local avec le duo open source Sunshine (serveur de streaming GPU installé sur le PC fixe) et Moonlight (client sur le portable Ubuntu) : détection automatique de l’hôte, appairage par code PIN, et contrôle total avec flux vidéo en temps réel.

La deuxième étape a étendu l’accès à n’importe quel réseau grâce à Tailscale, un VPN maillé fondé sur le protocole WireGuard : chaque machine rejoint un réseau privé chiffré et communique comme en réseau local — sans ouvrir le moindre port sur la box. La troisième étape a automatisé le démarrage : Sunshine et Tailscale se lancent avec Windows, avant même l’ouverture d’une session, de sorte que la machine est joignable dès qu’elle est sous tension.

Restait le dernier verrou : la mise sous tension à distance. La voie classique, le Wake on LAN, a été correctement configurée (activation dans le BIOS, paramétrage de la carte réseau pour rester alimentée et réagir au « paquet magique ») — et a échoué : ma carte réseau ne restait pas alimentée une fois le PC éteint. Plutôt que de m’acharner, j’ai cherché une alternative et identifié une option de BIOS méconnue : le redémarrage automatique au retour du courant. Après l’avoir testée avec succès avant tout achat, j’ai branché le PC sur une prise connectée pilotable depuis mon téléphone. Allumer la prise allume le PC ; les services démarrent seuls ; une minute plus tard, je joue.

La dimension sécurité

Le choix de Tailscale plutôt qu’une ouverture de ports est le cœur de la sécurité du projet : mon PC n’est jamais exposé sur Internet, le trafic est chiffré de bout en bout par WireGuard, et seuls les appareils explicitement membres de mon réseau privé peuvent l’atteindre. L’appairage Sunshine/Moonlight par code PIN ajoute une validation à l’échelle applicative : même un appareil présent sur le réseau ne peut pas se connecter au flux sans avoir été approuvé.

Ma plus-value personnelle et ce que ce projet m’a appris

Ce projet illustre ma manière de travailler en autonomie : découper un objectif en étapes testables, valider chaque brique avant d’empiler la suivante, et documenter le tout. L’épisode du Wake on LAN est celui dont je suis le plus satisfait — non pas malgré l’échec, mais grâce à lui : diagnostiquer précisément pourquoi la solution standard ne fonctionnait pas sur mon matériel, puis trouver, tester et valider une alternative avant d’investir un euro, c’est exactement la démarche attendue face à un problème d’infrastructure réel. J’y ai aussi consolidé des compétences directement transférables en entreprise : VPN WireGuard, gestion de services au démarrage, configuration BIOS et administration d’un environnement multi-OS Windows/Linux.

La procédure technique détaillée (installation, appairage, configuration complète) 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.