UE3 - Administrer des systèmes

Gérer et maintenir les infrastructures informatiques

Je vous présente Le Mérovingien

Le Mérovingien, c'est le pouvoir ancien qui contrôle les accès : il détient des clés, des informations et des passages que tout le monde convoite, et il décide qui peut passer et qui reste à la porte. C'est très exactement le rôle d'un administrateur système : gérer les permissions, les comptes et les accès aux ressources sensibles.

Sa maîtrise des causes et effets et sa capacité à voir les dépendances cachées d'un système avant tout le monde illustrent bien ce qu'on attend d'un administrateur : anticiper ce qui va casser avant que ça casse, et savoir dire non quand il le faut.

Qu'est-ce que l'UE3 ?

"Administrer des systèmes", c'est l'UE de l'infrastructure : serveurs, réseaux, droits d'accès, sécurité. Le travail est discret quand il est bien fait mais immédiatement visible quand il ne l'est pas. Il s'agit de comprendre ce qui fait tourner les choses en arrière-plan et de savoir qui a le droit de toucher à quoi.

Mes projets SAE

Anime Rivals — SAE 2e année

Contexte : Projet web nécessitant la mise en place d'un environnement serveur pour l'hébergement et l'accès au jeu en ligne. Le déploiement a été réalisé sur un serveur web avec gestion de la base de données et des services associés.

Ce qui a été fait : Participation à la mise en place de l'environnement de production : configuration du serveur web (Apache/Nginx), installation et configuration de PHP et MySQL, mise en place de la base de données du jeu, configuration des droits d'accès et permissions, gestion des certificats SSL pour le HTTPS, mise en place des sauvegardes automatiques.

Difficultés : Assurer la disponibilité du service tout en garantissant la sécurité. La configuration initiale du serveur a nécessité plusieurs ajustements pour optimiser les performances.

Ce qui a été appris : Ce projet a permis de développer la configuration d'un serveur web complet, la gestion des services réseau associés, les bases de l'administration système, et les bonnes pratiques de sécurité serveur.

Ressenti : Partie souvent invisible mais essentielle. Voir le projet accessible depuis n'importe quel poste de travail donne une autre dimension au développement.

Voir le projet →

Configuration d’un serveur web local — UE3

Contexte : Exercice en ligne de commande sur une VM Ubuntu Killercoda pour monter un serveur web local avec Apache2 puis Nginx, et comprendre le cheminement d'une requête HTTP entre le navigateur et le serveur.

Ce qui a été fait : Installation et test des services, création d'un fichier `mon-site.conf` dans `/etc/apache2/sites-available`, réglage des droits (`chmod`, `chown`), modification de `/etc/hosts`, rechargement d'Apache et tests sur `http://mon-site.local:8080`. Reprise du même principe avec Nginx et comparaison des deux configurations.

Difficultés : Oublier de recharger Apache après chaque changement de config, confusion entre `sites-available` et `sites-enabled`, et un `403 Forbidden` causé par l'absence du droit `+x` sur le dossier parent pour l'utilisateur `www-data`.

Ce qui a été appris : Comprendre `systemctl`, les VirtualHosts, le rôle du fichier `/etc/hosts` comme mini-DNS local, l'importance des droits Unix pour un serveur web, et l'analyse de trames HTTP avec Wireshark pour voir les `GET`, `200 OK`, `User-Agent` et les en-têtes réels.

Ressenti : Un exercice très pratique et concret. C'était moins sexy que du code, mais ça a transformé ma vision du web : plus rien n'est laissé au hasard, chaque permission et chaque port compte.

Voir le tutoriel →

Rédaction de notices techniques — UE3

Contexte : Deux livrables distincts pour un même commanditaire : une notice utilisateur Windows pour la famille RAOPS, et une notice technique pour la configuration d'une station de montage photo/vidéo professionnelle.

Ce qui a été fait : Analyse des besoins, définition d'une arborescence de dossiers et d'une matrice de droits pour 6 comptes Windows, création de comptes et de groupes avec `lusrmgr.msc`, rédaction pas à pas des permissions NTFS, sélection de composants compatibles pour une station 8K (Ryzen 9, RX 7800 XT, 64 Go DDR5, SSD 4 To, 850W, refroidissement liquide).

Difficultés : Expliquer simplement l'héritage des permissions Windows et la priorité du refus sur l'autorisation, réaliser une configuration cohérente sous budget pour le monteur, et concevoir deux documents clairs pour deux publics très différents.

Ce qui a été appris : Maitriser la gestion des utilisateurs, groupes et permissions sous Windows, comprendre le rôle des SID et de l'héritage NTFS, et structurer une configuration matérielle professionnelle avec des choix équilibrés pour montage 8K.

Ressenti : J'ai apprécié le mélange entre administration des droits et architecture matérielle. C'était concret, utile, et j'ai vraiment senti l'intérêt de présenter l'information différemment selon le public.

Télécharger la notice famille → Télécharger la notice monteur →

Expériences professionnelles

Stage SNCF — Scripts Shell de collecte et automatisation

Contexte : Stage SNCF Voyageurs — Projet Ripley. Toute la mécanique de collecte repose sur des scripts Shell s'exécutant sur des machines Linux. Les scripts se connectent en SSH à des serveurs distants (Ubuntu et Solaris) pour y collecter des métriques. Travail en autonomie sur un environnement de production AWS EC2. Première exposition à l'administration système réelle.

Ce qui a été fait : Intégration complète de la chaîne de scripts : collect_sar.sh se connecte en SSH aux serveurs distants et déclenche l'exécution de gsar.sh qui récupère les métriques. Pour les métriques bases de données, j'ai reproduit cette architecture avec deux scripts maison — collecte_distanceBD.sh et collect_bd.sh — en l'adaptant aux contraintes spécifiques : chargement des variables d'environnement Oracle, gestion des identifiants via un fichier .env, compatibilité cross-OS entre Ubuntu et Solaris. Comprendre les métriques SAR elles-mêmes a aussi été un chantier à part : savoir qu'une colonne représente l'activité CPU ne suffit pas, il faut comprendre ce que mesure exactement chaque indicateur.

Difficultés : Apprendre Shell from scratch en contexte de production. Compatibilité des commandes système (grep, awk) entre Ubuntu et Solaris. Chargement des variables d'environnement Oracle : déterminer lesquelles charger et où les trouver. Droits d'accès bloquants sur une librairie Oracle partagée : problème non résolvable seul, nécessité de solliciter un collègue DBA.

Ce qui a été appris : Que les contraintes organisationnelles (protocoles de sécurité) peuvent primer sur la solution techniquement élégante. La structure en deux scripts (script distant + script local) comme pattern d'architecture pour la collecte à distance. L'importance des logs horodatés en production : une preuve formelle vaut mieux qu'une vérification manuelle. Crontab comme planificateur de tâches.

AC validés : AC 4.03.01 (déployer des services dans une architecture réseau), AC 4.03.02 (sécuriser les services et données), AC 4.03.03 (faire évoluer et maintenir un système).

Ressenti : Découverte totale et franchement enrichissante. Shell en contexte réel, c'est très différent des exercices académiques. Les vrais systèmes ont des histoires, des conventions, des contraintes héritées — et ça change tout.

« Le code impératif est une litanie servile. Prolog, lui, est un acte d'autorité : vous y posez des vérités immuables, et le moteur, avec la patience d'un gourmet, remonte les méandres du temps par le backtracking pour débusquer la cause. L'élégance, mon cher, n'est pas dans l'exécution, mais dans l'ordonnancement du destin.»
— Le Mérovingien