Portfolio — BTS SIO SISR

Catégorie : B1.4 Mode projet

  • Mise en place d’un serveur de masterisation avec Foreman

    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.

  • Un site vitrine pour une brasserie artisanale : choix d’architecture et mise en ligne

    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.