Séance 1 : ITSM/ITIL simplifié, GLPI et gestion des tickets

Introduction (10 min)

En 2018, un incident réseau majeur chez la SNCF a illustré la valeur d'une documentation opérationnelle à jour : quatre techniciens ont passé presque deux heures à chercher la procédure alors qu'une intervention correctement guidée aurait pris environ quatre heures. Le défaut de runbooks et de règles d'escalade a multiplié le temps de réparation par trois et engendré des coûts très élevés. Cette séance montre comment formaliser les tickets, définir des SLA clairs et utiliser un outil de gestion (GLPI) pour réduire le MTTR et améliorer la satisfaction utilisateur.

À l'issue de cette séance, vous serez capable de :

• Expliquer et appliquer un ITSM/ITIL simplifié (incidents, demandes, changements) dans le contexte d'une PME.
• Installer et configurer un serveur GLPI (option Docker ou apt), définir entités, profils, SLAs, catégories et alimenter une CMDB.
• Simuler des tickets (incident P1, demande standard, changement RFC), produire un rapport statistique mensuel (MTTR, taux de résolution N1) et exploiter la base de connaissances.

1. ITSM / ITIL simplifié (70 min)

ITSM (IT Service Management) décrit la manière dont une DSI délivre des services à ses utilisateurs. ITIL est un corpus de bonnes pratiques ; pour une PME, nous retenons une version pragmatique : classer, prioriser, documenter et automatiser les actions répétitives.

Les trois types d'objets fondamentaux

Cycle de vie d'un incident et matrice SLA

Cycle de vie incident :
Ouvert → En cours → En attente → Résolu → Fermé

Matrice de priorités et SLA — InnovatTech :
┌──────┬───────────────┬───────────────┬──────────────────────────────┐
│ Prio │ Réponse       │ Résolution    │ Exemple                      │
├──────┼───────────────┼───────────────┼──────────────────────────────┤
│  P1  │ 15 min        │ 4 h           │ AD en panne, réseau core down│
│  P2  │  1 h          │ 8 h           │ Messagerie dégradée          │
│  P3  │  4 h          │ 5 jours       │ Imprimante en panne          │
│  P4  │  8 h          │ 10 jours      │ Demande matériel             │
└──────┴───────────────┴───────────────┴──────────────────────────────┘

Métadonnées d'un ticket de qualité

Chaque ticket doit contenir des métadonnées exploitables :

• Titre synthétique (ex : « P1 - AD en panne - win-srv01 »)
• Description précise : observables, horodatage, actions déjà effectuées
• Catégorie, priorité, service impacté
• Technicien assigné, SLA et liens vers la base de connaissances ou CMDB

La qualité de ces champs conditionne la rapidité de résolution et la capacité d'escalade automatisée.

Gestion des changements (RFC)

Un changement doit inclure une RFC avec : objectif, prérequis, fenêtre planifiée, rollback plan et approbation (CAB — Change Advisory Board). Trois niveaux :

• Standard : faible risque, pré-approuvé (ex : ajout utilisateur).
• Normal : analyse et approbation requises (ex : mise à jour pare-feu).
• Emergency : intervention hors fenêtre, procédure d'urgence accélérée.

2. GLPI — Installation, configuration, CMDB et bonnes pratiques (70 min)

GLPI est une solution open-source de gestion des services et de la configuration (CMDB). Elle centralise tickets, actifs et base de connaissances.

2.1 Installation

Option A — Docker Compose (recommandé pour TP rapide)

version: '3.7'
services:
  db:
    image: mariadb:10.6
    environment:
      MYSQL_ROOT_PASSWORD: 'rootpass'
      MYSQL_DATABASE: 'glpi'
      MYSQL_USER: 'glpi'
      MYSQL_PASSWORD: 'glpipass'
    volumes:
      - db_data:/var/lib/mysql
  glpi:
    image: glpi/glpi:latest
    ports:
      - "8080:80"
    environment:
      GLPI_DB_HOST: db
      GLPI_DB_NAME: glpi
      GLPI_DB_USER: glpi
      GLPI_DB_PASSWORD: glpipass
    depends_on:
      - db
volumes:
  db_data: {}

cd /opt/glpi
docker-compose up -d
# Vérifier les conteneurs
docker ps --filter name=glpi

Option B — Installation sur Debian 12 (méthode détaillée)

sudo apt update
sudo apt install -y apache2 mariadb-server php php-mysql php-xml \
  php-cli php-gd php-curl php-ldap libapache2-mod-php unzip wget

cd /tmp
wget https://github.com/glpi-project/glpi/releases/download/9.5.9/glpi-9.5.9.tgz
tar -xzf glpi-9.5.9.tgz
sudo mv glpi /var/www/html/
sudo chown -R www-data:www-data /var/www/html/glpi
sudo systemctl restart apache2

# Créer la base de données
sudo mysql -u root -p -e "
  CREATE DATABASE glpi CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
  CREATE USER 'glpi'@'localhost' IDENTIFIED BY 'glpipass';
  GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'localhost';
  FLUSH PRIVILEGES;"

2.2 Configuration initiale recommandée

Une fois connecté en admin :

• Créer l'entité « InnovatTech » et éventuellement des sous-entités par service.
• Créer les profils : Administrateur, Technicien N2, Technicien N1, Utilisateur standard.
• Limiter l'accès des N1 à leurs files d'attente ; permettre aux N2 de transférer/fermer les tickets.

Catégories de tickets à créer

• Incident → AD / Réseau / Postes / Impressions / Application
• Demande → Création compte / Accès VPN / Demande matériel
• Changement → Standard / Normal / Emergency

2.3 CMDB — Actifs InnovatTech à créer

2.4 Création d'un ticket incident P1 (exemple)

1. Connexion à GLPI en tant que Technicien.
2. Assistance → Ajouter un ticket.
3. Titre : « P1 - AD en panne - win-srv01 »
4. Catégorie : Incident / AD | Priorité : P1
5. Description : « Depuis 08:12, win-srv01 (192.168.10.5) ne répond plus aux requêtes LDAP. Événements : EventID 4013 DNS / réplication AD échouée. Actions déjà effectuées : redémarrage service DNS — sans effet. »
6. Assignation : Technicien N2 (Bob Durand).
7. Joindre logs ou captures (Event Viewer export).
8. Sauvegarder et renseigner l'heure d'ouverture pour SLA.

2.5 Base de connaissances

Documenter chaque résolution dans la base de connaissances GLPI : titre clair, symptômes, diagnostic, procédure pas-à-pas, commandes et captures. Associer l'article à la catégorie et au ticket pour la résolution rapide N1.

3. Intégration rapide : Jira Service Management (20 min)

Jira Service Management peut compléter ou remplacer GLPI. Un projet « IT Service » expose des files d'attente par priorité ou SLA. Workflow type : Open → In Progress → Waiting for Customer → Resolved → Closed.

Les SLA sont définis via JQL (Jira Query Language) pour surveiller les tickets en risque :

project = IT AND status IN ("Open","In Progress") AND "Time to resolution" < ago(4h)

Exemple d'automatisation : « Quand SLA < 15 minutes restant → notifier le canal #it-oncall. »

Travaux Pratiques (90 min)

Contexte : Vous êtes technicien chez InnovatTech SARL. L'équipe IT vous demande de déployer une instance GLPI et de peupler la CMDB. Infrastructure : win-srv01, debian-srv01, debian-srv02, proxmox01, nas01, pfsense01, sw-core-01, 30 postes utilisateurs.

Objectif : Installer GLPI, créer l'entité InnovatTech, créer 5 techniciens, importer 30 utilisateurs CSV, définir la matrice SLA P1–P4, alimenter la CMDB (8 actifs), simuler 3 tickets, produire un rapport mensuel (MTTR + taux résolution N1).

Étapes

1. Déployer GLPI via Docker Compose (ou procédure apt) et vérifier l'accès web.

   cd /opt/glpi
   docker-compose up -d
   docker ps --filter name=glpi

2. Lancer l'installateur web et connecter la BDD (glpi / glpipass). Créer l'utilisateur admin initial.
3. Administration → Entités → Ajouter → Nom : « InnovatTech ».
4. Administration → Profils : créer « Technicien N1 » (droits limités) et « Technicien N2 » (droits escalade/clôture).
5. Créer 5 techniciens : alice.martin (N2), bob.durand (N2), claire.petit (N2), denis.lefebvre (N1), emma.rousseau (N1).
6. Importer 30 utilisateurs via Administration → Import (CSV standard) :

   firstname,lastname,login,email,entity
   John,Doe,jdoe,john.doe@innovattech.local,InnovatTech

7. Configurer les SLAs P1–P4 avec règles d'escalade (email N2, alerte Slack).
8. CMDB : Parc → Ajouter un équipement — remplir les 8 actifs du tableau ci-dessus.
9. Créer les catégories de tickets et les rattacher aux règles SLA.
10. Simuler les 3 tickets :
    • Ticket 1 (P1) : « P1 - AD en panne - win-srv01 » — Priorité P1, Technicien N2.
    • Ticket 2 (Demande) : « Demande - Création compte VPN - Télétravailleur » — Standard.
    • Ticket 3 (RFC) : « RFC - Mise à jour pfSense 2.7.1 → 2.7.2 » — Fenêtre planifiée, rollback plan, approbation.
11. Résoudre/fermer les tickets et documenter la résolution en base de connaissances.
12. Produire le rapport mensuel via export GLPI ou requêtes SQL :

    -- Nombre total de tickets sur la période
    SELECT COUNT(*) AS nb_tickets FROM glpi_tickets
    WHERE DATE(date) BETWEEN '2025-01-01' AND '2025-01-31';
    
    -- MTTR en heures
    SELECT AVG(TIMESTAMPDIFF(SECOND, date, closedate))/3600 AS mttr_hours
    FROM glpi_tickets
    WHERE closedate IS NOT NULL AND DATE(date) BETWEEN '2025-01-01' AND '2025-01-31';
    
    -- Taux résolution N1
    SELECT (SUM(CASE WHEN resolver_profile = 'Technicien N1' THEN 1 ELSE 0 END)
            / COUNT(*)) * 100 AS pct_resolution_n1
    FROM glpi_tickets
    WHERE DATE(date) BETWEEN '2025-01-01' AND '2025-01-31';

13. Exporter le rapport CSV/PDF et joindre les captures d'écran CMDB + tickets.

Livrable attendu

• Archive ZIP : export CSV tickets, capture CMDB (8 actifs), captures 3 tickets simulés, rapport MTTR+taux N1 en PDF.

Critères de réussite

• Instance GLPI accessible et installée.
• 5 techniciens créés (2 N1, 3 N2) et 30 utilisateurs importés.
• CMDB avec 8 actifs renseignés.
• 3 tickets créés et traités conformément aux SLAs.
• Rapport mensuel calculé avec MTTR et taux résolution N1.

Synthèse (10 min)

Cette séance a montré que la combinaison d'un référentiel ITSM simplifié, d'un outil de tickets et d'une CMDB permet de réduire le temps de détection, de diagnostic et de résolution. Les runbooks et la base de connaissances transforment la résolution d'incidents en processus reproductibles et mesurables.

Question de vérification : En une phrase, expliquez comment un SLA P1 diffère d'une demande standard et quelle conséquence cela a sur l'escalade.

Séance suivante : Rédaction de runbooks, documentation Markdown et versioning Git.