Mettre les RH, le juridique et les services généraux sur le même GLPI que l'informatique, ce n'est pas actionner un bouton : c'est une décision d'architecture. L'Enterprise Service Management (ESM) réutilise le moteur ITSM que vous exploitez déjà, mais ce qui distingue un projet qui passe à l'échelle d'un projet qui vire au chaos, c'est la façon dont chaque domaine est isolé : par entité, par catégorie ou par groupe. Se tromper de choix coûte du retravail et, pour les RH et le juridique, expose des données confidentielles.
La première décision : entité, catégorie ITIL ou groupe ?
Avant de créer un formulaire ou un SLA, définissez l'unité d'isolement. GLPI offre trois voies pour modéliser un domaine hors informatique, et chacune a un compromis réel entre confidentialité et effort de maintenance.
| Approche | Isolement des données | SLA/calendrier propre | Effort de maintenance | Quand l'utiliser |
|---|---|---|---|---|
| Entité dédiée | Total (tickets, pièces jointes et rapports séparés) | Oui, par entité | Élevé (profils, règles et catégories par entité) | RH et juridique, en présence de confidentialité |
| Catégorie ITIL + groupe | Partiel (qui a l'entité voit tout) | Partagé ; le SLA peut varier par catégorie | Faible | Services généraux et domaines sans forte confidentialité |
| Sous-entité sous l'informatique | Élevé, héritant de la gouvernance de la maison mère | Oui | Moyen | Domaine rattaché à la même direction |
La règle pratique que nous appliquons : si un ticket du domaine peut contenir une donnée que l'informatique ne devrait pas lire - paie, contrat, contentieux prud'homal - la réponse est une entité dédiée. Pour le reste, une catégorie plus un groupe règlent l'affaire avec une fraction de l'effort.
Isolement des données : l'angle mort des RH et du juridique
Dans la maintenance de parcs GLPI pour nos clients, l'erreur que nous voyons le plus dans un projet ESM n'est pas une histoire de formulaire, c'est une histoire de visibilité. Quelqu'un crée l'entité "Juridique", soigne les catégories, mais accorde le profil aux analystes informatiques de façon récursive depuis la racine - et voilà : l'informatique voit désormais tous les tickets du juridique, pièces jointes comprises. Pire : dans GLPI la pièce jointe hérite de l'entité du ticket (le lien Document_Item exige que le document et l'objet soient dans la même entité), donc un contrat joint à un ticket dans une entité partagée devient visible pour tous ceux qui ont accès à cette entité. C'est précisément pourquoi, pour le juridique, nous isolons par entité, jamais par catégorie.
Avant d'ouvrir un domaine sensible, nous lançons cet audit pour trouver qui a un accès trop large :
-- Audit de visibilite : qui voit les tickets de TOUS les domaines.
-- A executer sur la base GLPI. L'acces recursif depuis la racine (entities_id = 0,
-- is_recursive = 1) permet a l'utilisateur de voir les tickets de toutes les entites filles.
SELECT u.name AS utilisateur,
p.name AS profil,
e.completename AS entite_base,
pu.is_recursive
FROM glpi_profiles_users pu
JOIN glpi_users u ON u.id = pu.users_id
JOIN glpi_profiles p ON p.id = pu.profiles_id
JOIN glpi_entities e ON e.id = pu.entities_id
WHERE pu.is_recursive = 1
AND pu.entities_id = 0
ORDER BY p.name, u.name;Chaque ligne est un utilisateur qui voit tout. Pour les domaines confidentiels, le lien profil-utilisateur doit pointer vers l'entité précise, avec is_recursive désactivé. Et attention à un détail de GLPI : l'entité d'id 0 est la racine, une valeur valable - ne la traitez pas comme "vide".
SLA et calendrier par domaine : l'erreur du 8x5 aux services généraux
Un SLA dans GLPI est lié à un calendrier (heures ouvrées), et le calendrier se définit par entité. L'erreur courante est de créer les services généraux en héritant du calendrier 8x5 de l'informatique et de promettre un SLA de maintenance des locaux qui, en pratique, ne tourne ni la nuit ni le week-end - justement quand une climatisation de datacenter ou une panne électrique exigent une réponse. Avant de publier le SLA d'un domaine, vérifiez :
- Calendrier : des services généraux critiques exigent souvent du 24x7 ; les RH et le juridique tournent bien en 8x5.
- Jours fériés : le calendrier GLPI accepte les fériés et fermetures - renseignez-les, sinon le SLA compte du temps hors heures ouvrées.
- Escalade : définissez le groupe de techniciens du domaine avant d'activer le SLA, sinon le ticket dépasse l'échéance sans destinataire.
Onboarding multi-domaine : le flux qui rentabilise l'ESM
Le cas qui justifie l'investissement le plus vite, c'est l'onboarding. Un formulaire "Nouveau collaborateur" (natif dans GLPI 11, ou FormCreator dans GLPI 10) déclenche des tickets coordonnés : l'informatique crée la messagerie et les accès, les services généraux préparent le poste, les RH gèrent la paperasse. Chaque ticket naît dans la bonne entité, avec le bon groupe, et notifie le responsable. Un extrait d'un modèle de notification que nous utilisons pour l'alerte d'ouverture du domaine :
Objet : [##ticket.entity##] Onboarding : ##ticket.title## (##ticket.id##)
Une nouvelle demande a ete ouverte et attend votre domaine.
Ticket......: ##ticket.title##
Entite......: ##ticket.entity##
Categorie...: ##ticket.category##
Demandeur...: ##ticket.authors##
Groupe......: ##ticket.assigntogroups##
Echeance SLA: ##ticket.time_to_resolve##
Ouvrir......: ##ticket.url##Les ##...## sont des balises natives de GLPI, remplacées au moment de l'envoi. L'erreur courante ici est de créer les catégories du domaine et d'oublier de les marquer comme visibles dans le helpdesk (le champ is_helpdeskvisible) : le collaborateur ouvre le portail en libre-service et ne trouve pas la catégorie RH, parce qu'elle est née visible uniquement pour l'interface technique.
Checklist de déploiement
- Cartographiez les services du domaine (ce qu'il traite) avant de toucher à GLPI.
- Décidez de l'unité d'isolement avec le tableau ci-dessus (entité vs catégorie vs groupe).
- Créez l'entité par l'interface - jamais en SQL (GLPI construit l'arbre avec getSonsOf et un INSERT direct reste invisible dans la hiérarchie).
- Configurez le calendrier et le SLA du domaine.
- Créez les catégories ITIL et cochez la visibilité helpdesk.
- Créez le groupe de techniciens et les profils, avec la bonne portée d'entité (lancez l'audit de récursivité).
- Montez le formulaire (natif sur 11 ou FormCreator sur 10) et testez-le avec un vrai ticket en préproduction.
- Ce n'est qu'ensuite que vous ouvrez aux utilisateurs et publiez les indicateurs.
Que mesurer (fourchettes honnêtes)
Avec les domaines sur le même GLPI, vous comparez ce qui était incomparable auparavant : temps moyen de réponse, volume par catégorie et taux de réouverture, côte à côte entre informatique, RH et services généraux. Ne promettez pas de chiffre magique : réduire l'"e-mail perdu" est souvent le gain le plus visible le premier mois, car toute demande devient un ticket traçable. Le gain de temps à l'onboarding dépend de la part du flux que vous automatisez - plus le formulaire déclenche de tâches tout seul, plus l'effet est grand.
Chez NexTool, nous déployons et maintenons GLPI multi-domaine pour nos clients, de la conception des entités au SLA et aux règles de routage. Si vous voulez emmener GLPI au-delà de l'informatique sans exposer les données RH ou juridiques, nos services de support et de maintenance couvrent cette conception de bout en bout.
Révisé par l'équipe NexTool Solutions.
