NexTool Solutions

Déployer GLPI sans planification, c'est créer de la dette technique dès le jour 1. Dans la maintenance d'environnements clients, presque aucun projet GLPI n'échoue à cause du logiciel. Il échoue à cause de décisions de périmètre prises trop tard, de données importées avant la définition de la hiérarchie et d'un détail d'infrastructure qui ne fait mal qu'après la mise en production. Cette checklist couvre les 12 étapes, mais la valeur réside dans les décisions à prendre avant chacune d'elles.

Avant la checklist : le périmètre est une décision métier, pas informatique

Le meilleur prédicteur de succès que nous observons n'est pas technique : c'est l'existence d'un responsable du processus côté client, quelqu'un ayant l'autorité de dire "ce flux reste hors de la phase 1". Sans ce responsable, chaque service demande une exception, le périmètre gonfle et la mise en production glisse de trois mois. La première décision d'un déploiement n'est pas quel serveur utiliser, mais ce qui ne passe pas en production le jour 1. Un GLPI qui gère bien les tickets et l'inventaire et qui livre dans les temps génère plus d'adoption qu'une CMDB parfaite qui n'est jamais mise en production.

Dimensionnement honnête : trois couches qui montent ensemble

Un environnement GLPI, c'est trois couches à dimensionner ensemble : application (PHP/PHP-FPM), base de données (MariaDB/MySQL) et stockage de documents. Sans inventer de benchmark, pour quelques centaines d'utilisateurs et quelques milliers d'actifs, les environnements tournent confortablement dans la plage de 2 à 4 vCPU et 4 à 8 Go de RAM. Les deux points qui génèrent le plus de support ne sont pas le CPU :

• MariaDB - réglez innodb_buffer_pool_size pour accueillir le jeu de données chaud. Une base à l'étroit dans un petit buffer rend la recherche GLPI lente même avec un CPU inactif.
• PHP - un memory_limit bas fait échouer les gros rapports et imports avec une erreur générique ; GLPI recommande au moins 128 Mo, et les imports d'inventaire demandent plus de marge.
• Disque - ce qui grossit le plus, c'est le dossier des documents joints et l'inventaire. Prévoyez la croissance, pas seulement la taille initiale.

Découpage en phases : la matrice qui décide quand mettre en production

La question opérationnelle n'est pas "que fait GLPI", c'est "qu'est-ce qui appartient à quelle phase". Voici la matrice que nous utilisons pour séparer la mise en production (MVP) des évolutions ultérieures. La règle : on ne passe à la phase suivante qu'une fois la précédente en usage réel, avec des données qui entrent.

Le réglage qui casse à la mise en production : le cron en mode CLI

C'est le piège que nous voyons le plus souvent saper la perception d'une mise en production réussie. Les tâches automatiques de GLPI (envoi de notifications, calcul des SLA, collecte de courriel via mailgate, synchronisation) peuvent s'exécuter dans deux modes : GLPI (déclenchées par l'accès web) ou CLI (exécution externe par crontab). En mode GLPI, les tâches n'avancent que lorsque quelqu'un ouvre une page. Le résultat classique : la file s'accumule toute la nuit et le premier utilisateur du matin "paie l'addition", traitant des centaines de courriels bloqués, et tout le monde pense que "GLPI est lent". Le correctif est trivial et presque personne ne le met en place avant que ça fasse mal : un cron externe chaque minute.

# /etc/cron.d/glpi -- file, notifications, SLA et collecte de courriel (mailgate)
# Exécuter en tant qu'utilisateur PHP (Debian/Ubuntu : www-data).
# Valable pour GLPI 10 et 11 : les deux exécutent front/cron.php via CLI.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Après avoir installé le crontab, basculez les tâches automatiques en mode CLI dans l'interface de configuration. GLPI détecte alors l'exécution externe et vide la file en continu, sans dépendre de l'accès web.

Validation avant mise en production : le diagnostic exécuté avant d'ouvrir l'accès

Avant d'ouvrir l'accès, on exécute un diagnostic rapide en base pour attraper les quatre erreurs les plus fréquentes : tâche automatique encore en mode interne, notifications désactivées, utilisateur sans profil (ne peut se connecter à aucune entité) et arbre d'entités différent de la conception validée.

-- 1) Actions automatiques encore en mode interne (mode=1). À la mise en production, elles doivent passer en CLI (mode=2)
SELECT name, state, mode FROM glpi_crontasks WHERE mode = 1;

-- 2) Système de notification activé ? (0 = désactivé, les courriels ne partent jamais)
SELECT value FROM glpi_configs WHERE context = 'core' AND name = 'use_notifications';

-- 3) Utilisateurs actifs sans profil attribué (ne se connectent à aucune entité)
SELECT u.id, u.name
FROM glpi_users u
LEFT JOIN glpi_profiles_users pu ON pu.users_id = u.id
WHERE pu.id IS NULL AND u.is_active = 1 AND u.is_deleted = 0;

-- 4) Arbre d'entités : vérifiez qu'il correspond à la conception validée
SELECT id, name, completename FROM glpi_entities ORDER BY completename;

Un bonus de terrain : testez une notification réelle de bout en bout (ouvrez un ticket de test et confirmez que le courriel arrive dans la boîte du demandeur). Une notification "configurée" qui ne part jamais est le défaut silencieux numéro un de l'adoption.

La checklist des 12 étapes

1. Définir des objectifs concrets et mesurables (tickets perdus, inventaire manquant, SLA sans contrôle).
2. Recueillir les besoins en interrogeant le support, les managers et les utilisateurs ; cartographier les flux et les irritants.
3. Dimensionner l'infrastructure (serveur, OS, base de données, RAM, disque). Voir les guides Docker ou Linux.
4. Installer et configurer GLPI, SSL, SMTP, cron (CLI) et sécurité de base.
5. Structurer entités et lieux avant d'enregistrer la moindre donnée. Voir le guide de hiérarchie organisationnelle.
6. Configurer catégories et SLA minimaux. Voir le guide SLA et OLA.
7. Configurer profils et permissions en définissant qui peut faire quoi.
8. Importer les données initiales (utilisateurs via LDAP/AD, actifs actifs, contrats en cours) - le minimum pour opérer.
9. Configurer les intégrations prioritaires (courriel, LDAP/AD, supervision, GLPI Agent).
10. Former l'équipe par rôle : techniciens, managers et utilisateurs finaux du portail.
11. Pilote (MVP) avec un petit groupe, en recueillant du feedback avant la mise en production générale.
12. Mise en production et suivi avec pilotage des KPI et ajustements les premières semaines.

Pièges de terrain qui ont coûté cher

• Importer les utilisateurs avant de figer la hiérarchie d'entités. Déplacer des éléments entre entités ensuite touche les tickets, contrats et permissions liés. Nous définissons l'arbre d'entités et le champ de synchronisation LDAP avant le premier import, car un réimport sans champ clé stable duplique les utilisateurs.
• Migrer cinq ans d'historique le jour 1. C'est la recette d'une mise en production retardée. Chargez le minimum opérationnel et laissez l'historique pour un chargement ultérieur, une fois la structure stable.
• Laisser le cron en mode GLPI. Détaillé plus haut : notifications et SLA bloqués dans la file deviennent une "lenteur" perçue.
• Ne pas tester le SMTP avec un vrai courriel. Une configuration enregistrée n'est pas une notification livrée. Testez de bout en bout avant d'ouvrir l'accès.

Besoin d'une mise en production sans surprise ? NexTool planifie et exécute des déploiements GLPI pour des clients B2B, du découpage du périmètre en phases à l'environnement validé en production. Découvrez le service Projets et Déploiement.

Révisé par l'équipe NexTool Solutions.