GLPI n'a pas à rester enfermé dans l'informatique. Avec des entités, des catégories et des règles métier bien conçues, la même instance sert les RH, le Juridique, les Services généraux et la Finance comme un Centre de Services Partagés (CSP). Ce qui distingue un CSP qui fonctionne d'un tas de tickets, c'est la décision d'architecture prise avant le premier formulaire.
Décision d'architecture : une entité par service ou une catégorie par service ?
C'est le premier choix et le plus coûteux à annuler. Dans GLPI, une entité est une frontière multi-locataire : elle isole les données, les SLA, les profils et le catalogue. Une catégorie ITIL n'est qu'une étiquette de classification à l'intérieur d'une entité. Une entité par service donne un isolement fort mais exige de l'administration ; les catégories gardent tout simple mais dépendent des groupes et des règles pour router et protéger les données.
| Critère | Une entité par service | Une catégorie par service |
|---|---|---|
| Isolement des données | Fort (un profil non récursif ne voit pas les services voisins) | Faible (dépend du groupe et de la règle) |
| SLA indépendant par domaine | Natif | Manuel, via règle + SLA par catégorie |
| Rapport consolidé | Exige un profil récursif ou l'entité racine | Trivial (une seule entité) |
| Effort d'administration | Élevé (profils, droits, cron) | Faible |
| Recommandé pour | RH et Juridique (données confidentielles) | Services généraux et Finance (faible confidentialité) |
Règle pratique : utilisez des entités lorsqu'il existe une réelle exigence de confidentialité (les RH et le Juridique en ont souvent une) ou des SLA et profils très distincts. Utilisez des catégories lorsque les domaines partagent le même pool d'agents et que la confidentialité est faible. Une conception hybride est fréquente : une entité séparée pour les RH et le Juridique, les Services généraux et la Finance en catégories dans l'entité de l'entreprise.
Pas à pas pour le premier service hors informatique
- Modélisez la frontière : choisissez entité ou catégorie avec la matrice ci-dessus avant de créer quoi que ce soit.
- Créez l'entité (Administration > Entités) ou l'arbre de catégories (Configuration > Catégories de tickets), en activant toujours la visibilité récursive lorsque la structure est partagée.
- Créez un groupe d'agents par domaine (Administration > Groupes) et cochez "Peut être affecté à des tickets".
- Définissez le SLA/OLA du domaine (Configuration > Niveaux de service) avec des délais de réponse et de résolution réalistes.
- Configurez des règles métier (Règles > Règles métier pour les tickets) pour affecter automatiquement le groupe, la catégorie et le SLA selon l'origine du ticket.
- Montez le catalogue : formulaires natifs (GLPI 11) ou le plugin Formcreator (GLPI 10) avec les champs du domaine.
- Ajustez les profils et les droits : un agent RH ne doit pas voir la file de l'informatique, et inversement.
- Activez le cron externe (section suivante) avant d'annoncer le service.
Diagnostic : qui utilise vraiment le centre
Mesurez avant et après l'extension. La requête ci-dessous lit directement la base de données et montre le volume et le temps jusqu'à la résolution par entité et catégorie sur les 30 derniers jours. Exécutez-la sur une réplique ou hors des heures de pointe.
-- Volume et temps jusqu'a la resolution par entite/categorie (30 jours)
SELECT e.completename AS entite,
IFNULL(c.completename, '(sans categorie)') AS categorie,
COUNT(t.id) AS tickets,
ROUND(AVG(TIMESTAMPDIFF(HOUR, t.date, t.solvedate)), 1) AS heures_jusqu_resolution
FROM glpi_tickets t
JOIN glpi_entities e ON e.id = t.entities_id
LEFT JOIN glpi_itilcategories c ON c.id = t.itilcategories_id
WHERE t.date >= NOW() - INTERVAL 30 DAY
AND t.is_deleted = 0
GROUP BY e.completename, c.completename
ORDER BY tickets DESC;Si de nombreuses lignes affichent "(sans categorie)", c'est le signe d'un catalogue incomplet ou d'agents ouvrant des tickets sans les classer - le premier symptôme d'un CSP sur le point de perdre sa traçabilité.
Cron externe : pourquoi le SLA des RH ne se déclenche pas à l'heure
Dans le support quotidien d'environnements multi-domaines, le schéma qui échoue le plus silencieusement est l'entité sans cron externe. L'informatique, à fort trafic, déclenche le cron interne à chaque chargement de page et personne ne remarque le problème. L'entité Juridique, avec quelques visites par jour, accumule des escalades de SLA qui ne s'exécutent que lorsque quelqu'un ouvre l'interface. Le ticket qui nous parvient est souvent "les e-mails d'échéance du Juridique arrivent tous par lot vers 9 h" - exactement au moment où le premier utilisateur se connecte et où le cron interne traite enfin la file en attente. La correction consiste toujours à déplacer l'exécution vers le cron du système d'exploitation (MODE_EXTERNAL) et à réduire la dépendance au déclencheur par chargement de page.
# /etc/cron.d/glpi - cron externe de GLPI (execute par l'utilisateur du serveur web)
# Declenche notifications, escalade de SLA et cloture automatique.
* * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php &>/dev/nullAprès l'avoir planifié, allez dans Configuration > Actions automatiques et vérifiez que les tâches critiques (envoi de notifications, escalade de SLA et clôture des tickets) s'exécutent en mode CLI et non "GLPI" (exécution au chargement de page). Dans un environnement multi-domaines, les laisser en mode interne est la cause numéro 1 de "l'échéance est passée mais personne n'a été prévenu".
L'erreur courante : catégorie non récursive et visibilité cassée
L'erreur que nous voyons le plus en support est subtile : une catégorie créée dans l'entité racine sans activer la visibilité pour les entités enfants n'apparaît tout simplement pas dans le formulaire du service. Sans la bonne catégorie, l'agent ouvre le ticket en "Incident" générique ou saisit la classification dans le titre - et le rapport du domaine naît faussé. Il en va de même pour les profils : un agent RH avec une portée de profil non récursive ne voit que l'entité exacte où il se trouve, pas les sous-entités. En créant des catégories à la racine, activez "Entités enfants" (visible dans les sous-entités), avec entities_id = 0 et is_recursive = 1 ; en créant des profils de domaine, décidez délibérément si la portée est récursive.
Gouvernance : évitez l'explosion des catégories
- Limitez l'arbre à 2 niveaux par domaine ; au-delà, personne ne classe correctement.
- Nommez les catégories par l'action du demandeur ("Demander un remboursement"), pas par le jargon interne.
- Revoyez chaque trimestre les lignes "(sans categorie)" du diagnostic.
- Un responsable par domaine, en charge du catalogue et des SLA.
- Ne répliquez pas la même catégorie sur plusieurs entités à la main ; rendez-la récursive depuis la racine.
Commencez par l'informatique, déjà habituée au service desk, puis étendez progressivement. Chaque nouveau domaine entre avec une frontière définie, un groupe de support, un SLA et un cron externe validé - pas avec un catalogue improvisé.
Besoin de dessiner la frontière entre entités et catégories avant de faire évoluer votre CSP ? NexTool déploie et maintient GLPI multi-domaines pour des clients B2B, de la modélisation des entités au cron et aux règles de routage.
Révisé par l'équipe NexTool Solutions.
