Catalogue de Services dans GLPI 11 : Du Concept à la Pratique

Dans GLPI 11 le catalogue de services est natif et a sa propre page (/ServiceCatalog). Guide technique pour construire un service de bout en bout avec formulaire, contrôle d'accès et destination : le piège de visibilité qui fait disparaître le catalogue, la matrice de décision par scénario et la requête d'élagage par usage_count que NexTool exécute en support.

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 :

  1. Créez le formulaire et rattachez-le à une catégorie épurée (deux niveaux au maximum ; glpi_forms_categories est un arbre, et un arbre profond devient un labyrinthe).
  2. 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.
  3. Configurez le Contrôle d'accès : la stratégie AllowList restreint le service à des profils, groupes ou utilisateurs ; DirectAccess gé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.
  4. Définissez la Destination : l'itemtype FormDestinationTicket crée un ticket ; il existe aussi FormDestinationChange et FormDestinationProblem. Dans la destination, vous mappez la catégorie ITIL, le groupe responsable et le demandeur de l'élément généré.
  5. 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 catalogueContrôle d'accèsDestination (itemtype)D'où vient le SLA
Demander un accès VPN (self-service)AllowList : profil Self-ServiceFormDestinationTicket + catégorie "Accès"Règle métier sur la catégorie
Ouvrir une demande de changement (techniciens seulement)AllowList : profil TechnicienFormDestinationChangeFlux de changement, pas un SLA de ticket
Formulaire pour un prestataire externeDirectAccess (lien/token)FormDestinationTicket + entité du prestataireRègle par entité
Service en constructionAucune 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.

Questions fréquentes

Oui. Les formulaires sont entrés dans le cœur et il existe une page self-service dédiée, servie par la route /ServiceCatalog. Chaque service du catalogue est un formulaire natif, sans dépendre de FormCreator.

Il manque presque toujours une politique de Contrôle d'accès active. Dans GLPI 11, publier (is_active) et rendre visible sont deux choses distinctes : sans une AllowList ou DirectAccess active, le formulaire n'apparaît pas dans le catalogue. Exécutez la requête des formulaires sans accès actif pour les trouver tous d'un coup.

AllowList restreint le service à des profils, groupes ou utilisateurs authentifiés (self-service interne). DirectAccess génère un lien direct, utile pour quelqu'un en dehors de GLPI comme un prestataire externe, éventuellement protégé par un token.

Non. Le formulaire crée un ticket (ou changement, ou problème) et le SLA est appliqué à cet élément, par la catégorie ITIL ou une règle métier. Mappez la bonne catégorie dans la Destination et laissez le SLA à la couche du ticket.

Oui. Les destinations natives sont FormDestinationTicket, FormDestinationChange et FormDestinationProblem, et un même formulaire peut avoir plusieurs destinations, même conditionnelles - par exemple, toujours créer un ticket et, sur certaines réponses, aussi un changement.

Non. La visibilité par profil de FormCreator ne devient pas automatiquement une AllowList dans GLPI 11. Les formulaires arrivent actifs, mais sans politique d'accès, c'est-à-dire invisibles. Il suffit d'ajouter une AllowList active à chacun.

Besoin d'aide ?