Portfolio — BTS SIO SISR

Catégorie : B1.2 Incidents et assistance

  • Cycle de vie d’un compte utilisateur : de la validation du contrat à la remise du poste

    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.

  • Diagnostic d’une panne réseau : quand deux causes se superposent

    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.

  • Un serveur de jeu ARK autonome : VPN maillé, automatisation et sauvegardes

    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.