Dans GLPI 11, le catalogue de services a cessé d'être un plugin pour devenir partie du cœur - mais ce qui fait échouer la plupart des déploiements n'est pas l'absence d'une fonction, c'est un formulaire publié qu'aucun utilisateur ne parvient à voir. Dans le support d'environnements GLPI de clients, c'est le premier symptôme qui apparaît : "le catalogue est vide" alors que, dans la base de données, les formulaires existent et sont actifs. Ce guide montre comment construire un service de bout en bout avec les fonctions natives et comment diagnostiquer les pièges avant que l'utilisateur ne se plaigne.
Dans GLPI 11 le catalogue est natif - et a sa propre adresse
Jusqu'à GLPI 10, catalogue de services était synonyme de FormCreator. Dans GLPI 11 les formulaires sont entrés dans le cœur et, avec eux, est arrivé un vrai Catalogue de Services : une page self-service, servie par la route /ServiceCatalog, où l'utilisateur parcourt les services organisés par catégorie et ouvre le bon formulaire. Les formulaires se trouvent dans Administration > Formulaires et chaque service du catalogue est un formulaire composé de quatre pièces qui doivent être alignées :
- Formulaire (
glpi_forms_forms) : le service lui-même, avec nom, description et catégorie. - Questions (
glpi_forms_questions) : les champs que l'utilisateur remplit, avec obligation et conditions. - Contrôle d'accès (
glpi_forms_accesscontrols_formaccesscontrols) : qui voit le service dans le catalogue. - Destination (
glpi_forms_destinations_formdestinations) : ce qui est créé à l'envoi - un ticket, un changement ou un problème.
Construire un service de bout en bout
L'ordre compte. Sauter l'onglet Contrôle d'accès est l'erreur qui génère le plus de reprise. Pour chaque service :
- Créez le formulaire et rattachez-le à une catégorie épurée (deux niveaux au maximum ;
glpi_forms_categoriesest un arbre, et un arbre profond devient un labyrinthe). - N'ajoutez que les questions que vous utiliserez réellement dans le traitement. Un joli champ que personne ne lit sur le ticket est une friction pour l'utilisateur.
- Configurez le Contrôle d'accès : la stratégie
AllowListrestreint le service à des profils, groupes ou utilisateurs ;DirectAccessgénère un lien direct (pratique pour un prestataire externe). Sans politique d'accès active, le formulaire n'apparaît pas dans le catalogue. - Définissez la Destination : l'itemtype
FormDestinationTicketcrée un ticket ; il existe aussiFormDestinationChangeetFormDestinationProblem. Dans la destination, vous mappez la catégorie ITIL, le groupe responsable et le demandeur de l'élément généré. - Activez le formulaire (
is_active) et testez-le avec un vrai utilisateur self-service, pas avec votre compte administrateur.
Le piège qui fait "disparaître" le catalogue
En support, le ticket récurrent est "j'ai publié le service et l'utilisateur ne le voit pas". Dans la quasi-totalité des cas la cause est la même : le formulaire a is_active = 1, mais aucune politique de Contrôle d'accès active. GLPI 11 traite la visibilité et la publication comme deux choses distinctes - publier ne suffit pas, il faut au moins une AllowList ou DirectAccess active. Et GLPI n'émet aucun avertissement : pour le technicien le formulaire est "en ligne", pour l'utilisateur le catalogue est vide. C'est la première requête que nous exécutons lors d'un onboarding de support, avant de discuter de la taxonomie :
-- Formulaires PUBLIES qui n'apparaissent PAS dans le catalogue self-service :
-- ils sont actifs (is_active=1) mais sans AUCUNE politique d'acces active.
-- Ils existent, comptent dans le total et sont invisibles pour l'utilisateur final.
SELECT f.id, f.name, f.usage_count
FROM glpi_forms_forms f
LEFT JOIN glpi_forms_accesscontrols_formaccesscontrols ac
ON ac.forms_forms_id = f.id
AND ac.is_active = 1
WHERE f.is_active = 1
AND f.is_deleted = 0
AND f.is_draft = 0
AND ac.id IS NULL
ORDER BY f.usage_count DESC;
Un détail qui ne mord que celui qui a réellement migré : en amenant les formulaires FormCreator dans le cœur de GLPI 11, la visibilité par profil de FormCreator ne devient pas automatiquement une AllowList. Le formulaire arrive actif, mais sans politique d'accès - donc invisible. Nous avons audité des catalogues fraîchement migrés avec des dizaines de services dans ce limbe, le client jurant que "la migration a perdu les formulaires". Elle ne les a pas perdus : ils étaient bien là, mais sans personne pour les voir.
Vue client vs vue technique : où vit chacune
Le catalogue a deux couches et, dans GLPI 11, elles se trouvent à des endroits différents du formulaire :
- La vue client vit dans l'onglet Catalogue de services (titre, description conviviale, catégorie, illustration) et dans le Contrôle d'accès (qui voit). C'est ce qui apparaît sur
/ServiceCatalog. - La vue technique vit dans la Destination : catégorie ITIL, groupe technique et demandeur du ticket généré. Le SLA ne vit pas sur le formulaire - il est appliqué au ticket créé, par une règle métier ou par la catégorie ITIL.
L'erreur courante ici est d'essayer de "mettre le SLA sur le formulaire". Ce champ n'existe pas : le formulaire ne fait que créer l'élément ; c'est le ticket qui porte le délai. La matrice que nous utilisons pour décider de la configuration de chaque service :
| Service du catalogue | Contrôle d'accès | Destination (itemtype) | D'où vient le SLA |
|---|---|---|---|
| Demander un accès VPN (self-service) | AllowList : profil Self-Service | FormDestinationTicket + catégorie "Accès" | Règle métier sur la catégorie |
| Ouvrir une demande de changement (techniciens seulement) | AllowList : profil Technicien | FormDestinationChange | Flux de changement, pas un SLA de ticket |
| Formulaire pour un prestataire externe | DirectAccess (lien/token) | FormDestinationTicket + entité du prestataire | Règle par entité |
| Service en construction | Aucune active | - | Invisible - par intention, jamais par oubli |
Mesurez par l'usage, pas par la taille
Un bon catalogue n'est pas un grand catalogue. Chaque formulaire de GLPI 11 possède un compteur d'usage natif (usage_count), incrémenté à chaque envoi - utilisez-le pour prioriser et élaguer. Un service que personne n'active depuis des mois ne fait qu'alourdir le menu et enterrer ceux qui comptent. La requête d'élagage que nous exécutons lors de notre cycle de revue trimestriel :
-- Candidats a l'elagage : publies depuis plus de 90 jours et jamais utilises.
-- Un menu epure aide l'utilisateur a trouver le bon service plus vite.
SELECT id, name, usage_count, date_creation
FROM glpi_forms_forms
WHERE is_active = 1
AND is_deleted = 0
AND usage_count = 0
AND date_creation < (NOW() - INTERVAL 90 DAY)
ORDER BY date_creation;
Commencez par les dix services les plus demandés, utilisez des noms que l'utilisateur comprend ("Demander un ordinateur portable", pas "Provisionnement d'actif") et revoyez le catalogue chaque trimestre avec le usage_count en main. C'est ainsi que le catalogue cesse d'être une vitrine figée pour devenir la véritable porte d'entrée du service desk.
Besoin de structurer (ou de sauver) un catalogue de services dans GLPI 11 avec la visibilité sous contrôle et les destinations mappées à votre flux ? Découvrez les projets d'implémentation de NexTool.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et révisé par l'équipe Nextool Solutions.