AP2 — Projet PARCUS

Le projet en bref

Le besoin

Une petite structure devait se doter d'un service informatique complet : savoir ce qu'elle possède comme matériel, recevoir et traiter les demandes de ses salariés, et pouvoir dépanner les postes à distance — le tout hébergé en interne, sans dépendre d'un service en ligne.

Le projet a donc été découpé en trois lots complémentaires, chacun sous la responsabilité d'un membre du groupe. Au-delà de mon lot, j'ai participé à la mise en place des deux autres. L'ensemble tourne sur des machines virtuelles reliées au réseau interne 192.168.137.0/24 : aucun service n'est publié sur Internet.

Répartition des lots

• LOT 1 — RustDesk (Maxence Rodriguez) : serveur de prise en main à distance auto-hébergé, chiffrement BitLocker.
• LOT 2 — GLPI (Aksel Karacelik) : gestion de parc, inventaire automatique et tickets d'assistance.
• LOT 3 — Windows Server 2025 (Alexis Jeanney) : Active Directory, DHCP, WDS et déploiement de logiciels par GPO.

Architecture mise en place

Ma réalisation : le lot GLPI

GLPI est une solution open source de gestion de parc et d'assistance (ITSM). Je l'ai installée et mise en service de bout en bout, puis documentée pour trois publics différents : celui qui installe, celui qui utilise, celui qui exploite.

Socle technique

Ce que j'ai mis en place

• Serveur GLPI sur pile LAMP — installation d'Apache, PHP et ses extensions, puis de MariaDB ; sécurisation de la base et import des fuseaux horaires.
• Sécurisation post-installation — suppression du dossier d'installation, changement des mots de passe de tous les comptes par défaut et désactivation des comptes inutilisés.
• Inventaire automatique — déploiement du GLPI Agent sur les postes Windows, en interface graphique et en installation silencieuse (msiexec /quiet) pour un déploiement de masse. Les machines remontent seules dans Parc > Ordinateurs avec leur processeur, leur RAM, leurs disques et leurs logiciels.
• Collecteur de mails — un message envoyé à l'adresse du support devient automatiquement un ticket (objet = titre, corps = description), relevé toutes les 10 minutes par l'action automatique mailgate.
• Authentification centralisée — liaison de GLPI à l'Active Directory du LOT 3 en LDAPS (port 636), pour que les salariés se connectent avec leur compte de domaine.
• Cycle de vie des tickets — du portail Self-Service côté utilisateur jusqu'à l'attribution, le traitement et la clôture côté technicien.

Difficultés rencontrées

La partie la plus formatrice du projet. Chaque blocage est documenté dans le livrable avec son symptôme, sa cause et sa résolution.

• La VM Debian ne joignait pas le réseau — ni résolution DNS, ni ping. La carte réseau ajoutée à la machine virtuelle n'était pas active. Résolu en activant l'interface et en demandant une adresse (ip link set ens33 up, dhclient), puis en fixant la configuration dans /etc/network/interfaces pour qu'elle survive au redémarrage.
• L'extension php-imap absente des dépôts Debian 13 — or elle est indispensable au collecteur de mails. Il a fallu l'ajouter par une méthode complémentaire, puis vérifier sa présence avec php -m | grep imap.
• L'agent d'inventaire créait un dossier au lieu d'envoyer l'inventaire — l'URL du serveur avait été saisie dans le champ du dossier d'installation (Local Target) au lieu de Remote Targets. Un piège d'interface qui coûte une réinstallation de l'agent.
• LDAPS injoignable — « No route to host » sur le port 636 — GLPI bloquait à l'étape du flux TCP vers le contrôleur de domaine. Diagnostic méthodique depuis la Debian : d'abord ping pour vérifier que les deux VM se voient, puis nc -zv pour vérifier que le port est bien ouvert.

Recette et plan de tests

Chaque lot a été validé par un plan de tests rejoué après chaque modification importante de l'infrastructure. Pour le lot GLPI, huit tests couvrent la chaîne complète — tous au statut OK.

Ce que j'en retiens

Ce projet m'a fait travailler l'administration Linux en conditions réelles — installation d'une pile LAMP, diagnostic réseau, sécurisation d'un service — mais aussi un aspect que je n'attendais pas : écrire pour quelqu'un d'autre. Rédiger trois documentations pour trois publics distincts oblige à comprendre vraiment ce qu'on a fait.

L'interconnexion des trois lots a également été un bon exercice de travail en équipe : mon serveur GLPI devait s'authentifier sur l'Active Directory d'un camarade, ce qui nous a demandé de nous mettre d'accord sur l'adressage, les ports et les certificats.

Compétences du référentiel mobilisées