Mise en place d’un outil de gestion de parc et de tickets (GLPI)

Seul, dans le laboratoire de l’école qui reproduit l’informatique du siège de GSB (Galaxy Swiss Bourdin, laboratoire pharmaceutique fictif du cas d’étude de la formation), du 5 au 6 novembre 2026, puis le 11 novembre pour le portail des salariés.

Compétences mises en œuvre

Compétence	Ce que j’ai fait	Preuve
Gérer le patrimoine informatique
Recenser et identifier les ressources numériques	Inventaire automatique : 13 machines remontées par un agent, chacune rangée dans l’entité de sa zone réseau	figure 2, tests
Mettre en place et vérifier les niveaux d’habilitation associés à un service	Comptes par défaut sécurisés ; relais limité au profil Technicien ; salariés en Self-Service dans leur seule entité	figure 3, tests
Vérifier les conditions de la continuité d’un service	Deux serveurs en actif / secours ; bascule réelle : 7 s, utilisateur toujours connecté	tests
Répondre aux incidents et aux demandes d’assistance et d’évolution
Collecter, suivre et orienter des demandes	Les alertes de la supervision deviennent des tickets rattachés à la machine ; les salariés ouvrent leurs demandes par le portail	figures 3 et 4
Traiter des demandes concernant les services réseau et système, applicatifs	Ticket réel d’un salarié traité jusqu’à sa validation	figure 4, tests
Mettre à disposition des utilisateurs un service informatique
Accompagner les utilisateurs dans la mise en place d’un service	Guide d’une page pour les salariés : connexion, catégorie, suivi, validation	guide du salarié

Contexte et besoin

Mon laboratoire reproduit l’informatique du siège de GSB : un pare-feu qui sépare cinq zones réseau, deux serveurs web derrière un répartiteur de charge, un cluster de trois bases de données, un annuaire et une supervision qui envoie des alertes par courriel.

La mission « Assistance » de GSB demande un outil de gestion de parc et de tickets. Avant cette réalisation, je n’en avais pas : les incidents du laboratoire étaient notés dans un document texte, pas dans un outil. Dans mon audit de l’environnement exigé par l’épreuve, la ligne « gestion des incidents » était donc rouge.

Il manquait aussi une trace des pannes. La supervision prévient par courriel, mais un courriel se lit et s’oublie : il ne dit ni combien de temps la panne a duré, ni comment elle a été résolue.

Enfin, un outil de tickets sert d’abord aux utilisateurs. Après la première mise en service, aucun salarié ne pouvait ouvrir de ticket : ils naissaient seulement des alertes ou de ma propre saisie. Le 11 novembre, j’ai donc ouvert un portail simplifié où chaque salarié se connecte avec son compte Windows.

Objectifs et contraintes

Objectifs

Installer GLPI (gestionnaire libre de parc informatique) pour tenir le parc et les tickets.
Qu’il reste disponible si un serveur web tombe.
Que chaque machine du laboratoire apparaisse dans le parc sans saisie à la main.
Que les alertes importantes de la supervision deviennent des tickets, pour garder la trace des incidents.
Que les salariés ouvrent, suivent et valident eux-mêmes leurs demandes, avec leur compte Windows, sans rien voir d’autre.

Contraintes

Aucune nouvelle machine : l’hyperviseur, partagé avec d’autres élèves, n’avait plus que 11 Gio de mémoire libre.
Le site de GSB doit continuer à tourner sur les mêmes serveurs web : GLPI s’installe à côté de WordPress, pas à sa place.
La base dans le cluster existant, par le même chemin que WordPress : le cluster devient un service de base de données partagé.
Aucun secret dans les fichiers ni dans la documentation : mots de passe et jetons sont dans un gestionnaire de mots de passe.
Le moins de flux possible vers l’annuaire : un seul port, depuis la seule zone des serveurs web ; pas d’accès depuis la zone des invités.

Analyse et choix techniques

Question	Mon choix	Pourquoi
Quelle version ?	GLPI 11.0.12	La 12.0.1 venait de sortir et ses prérequis n’étaient pas encore documentés ; la 11 est mûre
Répartir la charge ou actif / secours ?	Actif / secours : un serveur sert tout, l’autre prend le relais s’il tombe	GLPI écrit des fichiers (documents joints, sessions) : une répartition au hasard aurait demandé un stockage partagé
Comment garder le secours à jour ?	Recopie automatique des fichiers vers le second serveur	L’outil de recopie servait déjà au site web ; la base est commune aux deux serveurs
Comment ranger le parc ?	Une entité par zone réseau (WEB, BDD, ADM, USERS), choisie par l’étiquette envoyée par l’agent	La fiche d’une machine dit tout de suite où elle se trouve dans le réseau
Un ticket pour chaque alerte ?	Non : tout de suite pour la sécurité ; pour le reste, si l’alerte dure plus de 2 heures	Sur 8 jours, 62 alertes, dont 57 revenues à la normale en moins de 30 minutes : un ticket par alerte aurait noyé l’outil
Comptes locaux ou annuaire ?	Les comptes du domaine, lus dans l’annuaire	Un seul mot de passe pour le salarié ; un compte désactivé dans l’annuaire ne peut plus entrer dans GLPI
Comment lire l’annuaire ?	En LDAPS (port 636), avec un compte de liaison sans droit particulier	Le contrôleur refuse le LDAP en clair ; certificat auto-signé, vérifié par les serveurs web
Quels droits pour un salarié ?	Profil Self-Service dans l’entité GSB > USERS, sans les entités du dessous ; règle livrée « Root » désactivée	Le salarié ouvre et suit ses tickets, rien d’autre ; la règle livrée ouvrait toute l’arborescence
Qui crée le ticket d’une alerte ?	Un petit relais sur le serveur de supervision, qui appelle l’interface de programmation de GLPI	La supervision détecte, le relais décide, GLPI garde la trace : si le relais ou GLPI tombe, les courriels continuent

Ce que j’en retiens : une application qui garde un état (sessions, fichiers) derrière un répartiteur de charge se met en actif / secours, pas en répartition : l’utilisateur doit retomber sur le même serveur tant que celui-ci fonctionne.

Mise en œuvre

Schéma : accès à GLPI par le répartiteur, serveur actif et secours, base dans le cluster, inventaire, tickets et lecture de l’annuaire

Figure 1 · GLPI dans le laboratoire : accès, secours, base, inventaire, tickets et portail des salariés (état au 11 novembre 2026).

La base : base et compte créés dans le cluster, recopiés automatiquement sur les trois nœuds.
L’installation : archive officielle, empreinte vérifiée avant l’installation ; configuration, clés et documents rangés hors du dossier publié sur le web ; création des 442 tables, que j’ai lancée moi-même.
Le serveur de secours : même code et même configuration sur le second serveur web, recopie automatique des documents et des sessions.
La publication : un nom propre à GLPI dans l’annuaire (glpi.sio.internal), un certificat dédié sur le répartiteur et un groupe de serveurs « actif + secours ».
Les premiers pas : j’ai changé les mots de passe des quatre comptes créés par défaut ; fuseau horaire réglé sur Paris.
La surveillance : une sonde vérifie que GLPI répond, et sa base fait partie de l’export de sauvegarde de chaque nuit.
L’inventaire : un agent GLPI sur chaque machine, installé par script depuis le bastion (Linux) ou en PowerShell (Windows) ; j’ai lancé moi-même le script pour les zones d’administration et de bases de données, et créé la règle de pare-feu de la zone d’administration.
Les tickets : le relais, son compte limité au profil Technicien, puis le rattachement automatique de chaque ticket à la fiche de sa machine.
La lecture de l’annuaire (11 novembre) : un compte de liaison dont j’ai saisi moi-même le mot de passe, un certificat sur le contrôleur de domaine pour le LDAPS, une règle de pare-feu étroite des serveurs web vers le contrôleur, port 636 seulement ; dans GLPI, l’annuaire limité à l’unité des salariés, comptes désactivés exclus.
Les droits : la règle livrée « Root » désactivée, remplacée par une règle « Salariés du domaine » (profil Self-Service, entité GSB > USERS) ; les six comptes des salariés importés et vérifiés un par un.
Le portail : six catégories de ticket (poste de travail, compte et mot de passe, réseau, messagerie, application métier, autre demande), créées par un script ; les tuiles de l’accueil traduites en français ; un guide d’une page pour les salariés.

Les 13 machines inventoriées dans GLPI, rangées par entité

Figure 2 · Les 13 machines inventoriées, chacune rangée dans l’entité de sa zone réseau (6 novembre 2026).

Le portail simplifié de GLPI vu par un salarié connecté avec son compte du domaine

Figure 3 · Le portail d’un salarié connecté avec son compte du domaine : profil Self-Service, entité GSB > USERS (11 novembre 2026).

Tests et recette

Test	Résultat
Tables créées sur les trois nœuds du cluster	442 tables identiques sur les trois nœuds
Bascule réelle : arrêt du serveur web actif	Retiré par le répartiteur en 7 s ; le second serveur sert GLPI ; je suis resté connecté, et le ticket ouvert avec sa pièce jointe s’affichait toujours
Inventaire	13 machines, chacune dans l’entité de sa zone ; une machine supprimée puis réinventoriée revient d’elle-même au bon endroit
Interface de programmation depuis une autre machine que le bastion	Refusée (erreur 403), testé depuis le répartiteur et depuis l’adresse publique
Alerte réelle : 6 connexions refusées sur un serveur	Ticket ouvert 1 min 36 s après l’attaque, rattaché au serveur, puis « Résolu » au retour à la normale ; une alerte courte ne crée aucun ticket
Lecture de l’annuaire en LDAPS depuis les deux serveurs web	TLS 1.3, certificat vérifié, connexion du compte de liaison acceptée
Connexion d’un salarié depuis le poste utilisateur	Portail Self-Service, entité GSB > USERS, aucun menu d’administration
Compte du domaine hors de l’unité des salariés (administrateur)	Refusé : « Identifiant ou mot de passe incorrect »
Ticket réel d’un salarié, de bout en bout (ticket 44)	Ouvert par le salarié à 12:50, suivi du technicien à 12:58, solution à 13:04, acceptée par le salarié à 13:05 : ticket clos
Refus d’une solution par le salarié (ticket 47)	Ticket rouvert « En cours », le commentaire du salarié ajouté au suivi

Le ticket 44 ouvert par un salarié dans le portail, catégorie Application métier

Figure 4 · Le premier ticket ouvert par un salarié dans le portail, avec sa catégorie (11 novembre 2026).

Bilan critique

Ce qui a coincé. L’activation de GLPI sur les serveurs web a fait tomber le site de GSB : le nouveau site est devenu le site par défaut, et WordPress, qui ne déclarait pas son propre nom, n’était plus servi. Le site public a renvoyé une erreur pendant environ 43 secondes, et son administration est restée injoignable 18 minutes. La correction a consisté à déclarer le nom du site dans sa configuration. J’en retiens que chaque site d’un serveur web doit déclarer tous ses noms.

Le lendemain, il est apparu que le contrôle de santé du répartiteur ouvrait une session GLPI toutes les 2 secondes, jamais effacée : des dizaines de milliers de fichiers recopiés un par un vers le secours. Un ménage des sessions toutes les 15 minutes a été ajouté et la recopie a été espacée.

Pour le portail, le contrôleur de domaine a refusé le LDAP en clair, ce que je n’avais pas prévu : les contrôleurs récents exigent la signature. Le LDAPS est devenu obligatoire, et il a d’abord refusé de démarrer : un certificat auto-signé doit aussi figurer dans les autorités racines du contrôleur lui-même (incident H-97). Un test m’a trompé un moment : l’outil affichait « vérification réussie » alors qu’aucun chiffrement n’avait été négocié. Enfin, le champ d’identifiant gardait la valeur par défaut de GLPI, qui ne correspond pas à l’annuaire de Windows.

Les limites que j’assume.

En cas de bascule, les fichiers modifiés dans les 30 dernières secondes peuvent manquer sur le secours : c’est le prix d’une recopie espacée. La base, elle, est complète.
Les salariés ne reçoivent pas de courriel de suivi : c’est un choix, le suivi se lit dans le portail.
Le certificat du LDAPS est auto-signé et installé à la main sur les deux serveurs web : il expire le 11 novembre 2031 et devrait venir d’une autorité de certification interne si le laboratoire grandit.

Ce que je referais autrement. Je vérifierais les noms déclarés par chaque site du serveur web avant d’en activer un nouveau, je regarderais l’effet d’un contrôle de santé sur l’application avant de le laisser tourner, et je prévoirais le LDAPS dès le départ.

Outils et aides. Les choix et les décisions sont les miens, ainsi que les étapes écrites à la première personne. Un assistant IA (Claude Code) a exécuté une partie des commandes et m’a aidé à rédiger la documentation, que j’ai relue.