NexTool Solutions

GLPI conserve tout l'historique du service desk, mais les rapports natifs s'arrêtent là où la direction commence à demander "pourquoi". Metabase et Grafana lisent la même base MariaDB de GLPI et transforment cet historique en tableaux de bord - mais ils résolvent des problèmes différents, et se tromper coûte du retravail.

Ce qui change quand on branche un BI sur GLPI

Avant de comparer les deux outils, il faut comprendre que la base de GLPI n'a pas été conçue pour le BI. Trois détails définissent la majeure partie du travail sur n'importe quel tableau de bord, que ce soit dans Metabase ou dans Grafana :

• Le statut, la priorité et l'urgence sont des nombres, pas du texte. Dans glpi_tickets, la colonne status va de 1 (Nouveau) à 6 (Clos). Aucun outil ne le sait tout seul - si vous ne traduisez pas les codes, le gestionnaire voit "status 2" sur le graphique.
• Rien n'est vraiment supprimé. GLPI utilise la suppression logique : is_deleted = 1 marque l'enregistrement comme "dans la corbeille". Oublier le filtre is_deleted = 0 gonfle tous les décomptes.
• C'est multi-entité. La colonne entities_id segmente les données par client ou service. Un tableau de bord que le client va voir doit filtrer le bon sous-arbre d'entités - et ce n'est pas gratuit en SQL pur.

Ajoutez un quatrième point, purement opérationnel : pointer le BI directement sur la base de production, en heures ouvrées, avec des requêtes qui balaient toute la table glpi_tickets jointe à glpi_logs, est le moyen le plus rapide de ralentir GLPI lui-même. Nous y revenons plus bas.

Comparatif direct

Comment se connecter sans plomber GLPI

Quel que soit l'outil, la connexion est la même : un utilisateur de base en lecture seule, idéalement pointant sur une réplique ou une copie restaurée de nuit, jamais sur le maître de production avec droit d'écriture.

-- Utilisateur en lecture seule pour le BI (executer sur le MariaDB/MySQL de GLPI).
-- Pointez de preference sur une replique ou une copie restauree,
-- jamais sur le maitre de production avec droit d'ecriture.
CREATE USER 'bi_ro'@'10.0.0.%' IDENTIFIED BY '${MOT_DE_PASSE_FORT}';
GRANT SELECT ON glpi.* TO 'bi_ro'@'10.0.0.%';
FLUSH PRIVILEGES;

Une fois l'accès prêt, le premier artefact qui règle le problème des "nombres bruts" est une requête qui traduit les codes de statut. Elle vaut pour les deux : dans Metabase elle devient une "Question SQL", dans Grafana un panneau tableau ou barres.

-- Tickets ouverts par statut, avec les codes traduits.
-- Dans GLPI, glpi_tickets.status va de 1 a 6.
SELECT
  CASE status
    WHEN 1 THEN 'Nouveau'
    WHEN 2 THEN 'En cours (attribue)'
    WHEN 3 THEN 'En cours (planifie)'
    WHEN 4 THEN 'En attente'
    WHEN 5 THEN 'Resolu'
    WHEN 6 THEN 'Clos'
  END AS statut,
  COUNT(*) AS total
FROM glpi_tickets
WHERE is_deleted = 0          -- ignore la corbeille (suppression logique)
  AND status IN (1, 2, 3, 4)  -- seulement ceux encore ouverts
GROUP BY status
ORDER BY status;

Metabase offre un raccourci : au lieu du CASE, vous pouvez mapper les valeurs de la colonne directement dans les réglages du champ (1 vers "Nouveau", 2 vers "En cours" et ainsi de suite), et l'étiquette apparaît automatiquement sur tout graphique. C'est un gain de productivité que Grafana n'a pas - là le CASE est obligatoire.

Grafana : le tableau de bord comme code

L'avantage de Grafana pour qui exploite beaucoup d'environnements n'est pas à l'écran, il est sur le disque : source de données et panneaux sont des fichiers versionnables. Nous provisionnons le même tableau de bord chez plusieurs clients à partir d'un YAML et d'un JSON dans Git, sans cliquer nulle part.

# /etc/grafana/provisioning/datasources/glpi.yaml
# Source de donnees versionnable : le meme fichier provisionne N environnements.
apiVersion: 1
datasources:
  - name: GLPI-MariaDB
    type: mysql
    access: proxy
    url: mariadb.interne:3306
    database: glpi
    user: bi_ro
    jsonData:
      maxOpenConns: 5             # limitez les connexions : n'etouffez pas GLPI
      timezone: America/Sao_Paulo
    secureJsonData:
      password: ${GLPI_BI_PASSWORD}

L'autre différenciateur, c'est le temps. Grafana comprend les séries temporelles nativement : avec les macros $__timeFilter et $__timeGroup, le sélecteur de période et l'auto-refresh du haut de l'écran pilotent la requête, et une variable de template devient un filtre d'entité dynamique.

-- Panneau de serie temporelle : les macros branchent le time picker du haut.
SELECT
  $__timeGroup(date, '1d') AS time,    -- regroupe par jour
  COUNT(*)                 AS ouverts
FROM glpi_tickets
WHERE is_deleted = 0
  AND entities_id IN (${entite})        -- variable de template (filtre par client)
  AND $__timeFilter(date)               -- respecte l'intervalle choisi a l'ecran
GROUP BY 1
ORDER BY 1;

-- Requete qui alimente la variable de template "entite" :
SELECT name AS __text, id AS __value
FROM glpi_entities
ORDER BY completename;

Le compromis qui apparaît en exploitation

En maintien en condition opérationnelle de parcs GLPI pour des clients, la décision est rarement technique - elle porte sur qui va regarder le tableau de bord. L'erreur la plus courante que nous corrigeons est toujours la même : quelqu'un choisit Grafana parce que "c'est plus puissant", monte un panneau opérationnel impeccable, et trois mois plus tard le directeur demande un rapport mensuel des tickets par catégorie avec export pour le client. Dans Grafana c'est pénible : il a été conçu pour des métriques en direct, pas pour qu'un gestionnaire navigue et exporte des tableaux. Alors Metabase entre en scène, et l'environnement devient deux BI à maintenir.

Un détail que seule l'exploitation révèle, c'est le cloisonnement par client. Dans un cabinet qui sert plusieurs clients sur le même GLPI (ou sur des GLPI distincts), il faut garantir que le tableau de bord du client A n'affiche jamais un ticket du client B. Dans Metabase, le vrai row-level security - le sandboxing par utilisateur - est une fonction payante ; en version gratuite, la parade est de créer une question par client avec l'entities_id figé dans le WHERE, ce qui multiplie la maintenance. Dans Grafana, nous le résolvons avec une variable de template liée aux entités, mais le contrôle de qui voit quoi reste entre vos mains. Il n'existe pas de raccourci gratuit pour l'isolation multi-client - nous décidons au cas par cas, et dans le doute nous séparons par instance, pas par requête.

Verdict par scénario

Choisissez Metabase quand le public est la direction, le client ou l'analyste sans SQL. La courbe est douce, le rapport sort navigable et exportable, et le mapping visuel des statuts règle les "nombres bruts" sans écrire de CASE. C'est le meilleur outil pour amener la donnée du service desk à ceux qui n'ouvrent jamais un terminal.

Choisissez Grafana quand le tableau de bord est opérationnel et en direct - file par groupe, SLA à risque, tickets par heure - pour l'équipe technique ou le NOC. Le time picker, l'auto-refresh, les alertes multi-canal et le provisioning comme code sont des avantages réels que Metabase ne couvre pas bien.

Utilisez les deux quand le même GLPI sert des publics différents : Grafana sur le mur de l'exploitation, Metabase entre les mains de la direction et du client. C'est courant et ça marche, mais assumez le coût de maintenir deux BI - ne prenez pas cette voie "par précaution".

Coût et effort

La licence n'est pas l'axe de la décision : les deux ont une édition open source gratuite qui suffit aux tableaux de bord GLPI, et les offres payantes (Metabase Pro/Enterprise, Grafana Enterprise) ne comptent qu'à l'échelle ou pour la gouvernance. Le vrai coût, c'est la modélisation. Le plus lourd n'est pas d'installer - c'est de connaître le schéma de GLPI : mapper les statuts et priorités, se souvenir de is_deleted, résoudre l'arbre des entités et ne pas surcharger la production. Comme fourchette honnête : une poignée de panneaux opérationnels dans Grafana se monte en une après-midi ; un jeu de rapports de gestion bien modélisés dans Metabase, avec filtres par client et statuts traduits, prend généralement de deux à quatre jours de travail avant d'être fiable. Pour savoir quelles métriques mettre sur chaque tableau de bord, voyez notre guide des KPI de Service Desk dans GLPI.

Chez NexTool, nous déployons Metabase et Grafana sur le GLPI des clients sur les deux fronts - rapport de gestion et tableau de bord opérationnel - toujours avec un utilisateur en lecture seule et sans plomber la production. Si vous voulez les bons tableaux de bord pour le bon public, sans être otage d'un BI inadapté, notre conseil conçoit cette couche d'indicateurs de bout en bout.

Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.