Un inventaire répond à "qu'est-ce que je possède ?". Une CMDB répond à "qu'est-ce qui tombe en même temps quand ceci échoue ?". Le pont entre les deux dans GLPI n'est pas l'onglet Connexions, comme beaucoup le supposent - c'est l'analyse d'impact, et c'est exactement là que la plupart des projets de CMDB s'enlisent. Ce guide présente les quatre mécanismes de relation qu'offre GLPI, lequel utiliser selon le cas, et les requêtes que nous exécutons en exploitation pour repérer la CMDB aveugle.
Inventaire vs CMDB : la différence qui change la réponse aux incidents
L'inventaire est un enregistrement : marque, modèle, numéro de série, garantie, responsable. C'est du contrôle patrimonial et c'est là que tout le monde commence - avec l'inventaire automatique de GLPI Agent, vous peuplez des centaines d'actifs en quelques jours. La CMDB, c'est l'étape suivante : la couche de relation qui répond à la question qui compte en plein incident - si ce switch tombe, quels serveurs, services et utilisateurs s'arrêtent avec lui ?
| Aspect | Inventaire | CMDB |
|---|---|---|
| Question à laquelle il répond | Qu'est-ce que je possède ? | Qu'est-ce qui dépend de quoi ? |
| Unité | Actif (élément) | Relation entre CI |
| Comment il se peuple | Automatique (GLPI Agent) | Manuel, une décision de modélisation |
| Valeur pendant un incident | Trouver l'équipement | Prévoir le rayon d'impact |
L'erreur stratégique courante est de traiter la CMDB comme un "inventaire plus détaillé" et de vouloir renseigner une relation pour tout. Ça ne passe pas à l'échelle et personne ne le maintient. Une bonne CMDB est sobre : uniquement les CI critiques et les dépendances que vous utiliseriez réellement dans une analyse d'impact.
Les quatre mécanismes de relation dans GLPI
GLPI n'a pas un unique "champ de relation" - il a quatre mécanismes distincts, chacun dans sa table, et choisir le mauvais est la racine de la plupart des CMDB qui ne fonctionnent pas. En exploitation, l'erreur numéro 1 est de tout monter dans l'onglet Connexions en croyant que c'est la CMDB, puis de découvrir que l'analyse d'impact est vide.
| Mécanisme | Table | Modélise | Orienté ? | Peuplé par |
|---|---|---|---|---|
| Connexions directes | glpi_computers_items | Périphérique relié à un ordinateur (écran, imprimante, téléphone) | Non | Inventaire ou manuel |
| Ports réseau | glpi_networkports_networkports | Câblage entre deux ports (switch ↔ hôte) | Non | SNMP/LLDP ou manuel |
| Applications (Appliances) | glpi_appliances_items | Un service/une application comme CI + l'infrastructure qui le soutient | Non (regroupement) | Manuel |
| Analyse d'impact | glpi_impactrelations | Graphe de dépendance pour calculer le rayon d'impact | Oui (source → impacté) | Manuel (onglet Impact) |
Connexions et ports réseau modélisent le lien physique. Applications regroupe l'infrastructure d'un service. Et l'analyse d'impact - la seule orientée - est le graphe de dépendance qui répond vraiment à "qu'est-ce qui tombe ensemble". Les quatre coexistent ; la confusion vient de s'attendre à ce que l'un fasse le travail de l'autre.
Modélisez le service comme un CI : Applications (Appliances)
L'étape qui manque à la plupart des inventaires est de donner au service une existence propre. "Messagerie", "ERP", "Portail client" ne sont pas du matériel - ce sont des services qui tournent sur du matériel. Dans GLPI, l'objet adapté est l'Application (Appliances, menu Parc), disponible depuis GLPI 9.5. Une Application est un CI logique auquel vous reliez les éléments qui le soutiennent :
- Créez l'Application (par ex. "Service de messagerie").
- Dans l'onglet des éléments associés, reliez les CI de support : le serveur, le switch cœur, le stockage, le lien internet. Cela s'écrit dans glpi_appliances_items.
- Renseignez le responsable technique, le contrat de support et le fournisseur sur l'Application elle-même.
À partir de là, le service existe comme entité interrogeable : vous ouvrez "Service de messagerie" et voyez la liste de l'infrastructure qui le soutient, sans dépendre de la mémoire de qui que ce soit.
La vraie CMDB : l'analyse d'impact
Regrouper l'infrastructure dans une Application indique qui soutient quoi, mais ne calcule pas le rayon d'impact d'une panne. C'est le rôle de l'onglet Analyse d'impact (présent depuis GLPI 9.4), qui dessine un graphe orienté de dépendances stocké dans glpi_impactrelations. Chaque arête a une source et une cible : itemtype_source, items_id_source impacte itemtype_impacted, items_id_impacted.
Le sens est le détail qui sépare celui qui comprend de celui qui a juste déplacé des cases. Une arête du switch vers le serveur signifie "le switch impacte le serveur". Quand le switch tombe, vous suivez les flèches vers l'avant et voyez tout ce qui s'arrête avec lui. L'erreur courante est de tracer la flèche à l'envers - relier le serveur comme impactant le switch - et alors l'analyse d'impact du switch en panne ressort vide, justement quand vous en avez le plus besoin. Modélisez toujours dans le sens du flux de dépendance : de l'infrastructure de base vers le service au sommet.
Une précaution de terrain : le graphe est rendu dans le navigateur et devient lent avec des centaines de nœuds. N'essayez pas de dessiner tout le parc. Utilisez la criticité métier (la liste déroulante Criticité, sous Configuration > Listes déroulantes) pour marquer les CI critiques et ne mettez que ceux-là sur le graphe. Une CMDB dense est une CMDB abandonnée.
SQL de diagnostic : trouver la CMDB aveugle
Au démarrage d'un contrat de maintenance, avant même de parler processus, nous lançons un audit de couverture : quels CI critiques sont dans l'inventaire mais hors de toute relation d'impact. Ce sont les points où l'analyse d'impact mentira, en disant "rien n'est affecté" alors qu'en réalité personne ne l'a modélisé. La requête liste les ordinateurs sans aucune arête - ni comme source, ni comme cible :
-- Ordinateurs SANS aucune relation d'impact :
-- ils existent dans l'inventaire, mais sont invisibles pour l'analyse d'impact.
SELECT c.id, c.name
FROM glpi_computers c
LEFT JOIN glpi_impactrelations r
ON (r.itemtype_source = 'Computer' AND r.items_id_source = c.id)
OR (r.itemtype_impacted = 'Computer' AND r.items_id_impacted = c.id)
WHERE c.is_deleted = 0
AND r.id IS NULL
ORDER BY c.name;Et l'autre côté : pour un service modélisé en Application, quels CI il regroupe. Utile pour vérifier si "Service de messagerie" pointe bien vers le bon serveur et le bon switch avant de s'y fier en pleine nuit d'incident :
-- Elements qui soutiennent une Application (service) precise :
SELECT ai.itemtype, ai.items_id
FROM glpi_appliances_items ai
INNER JOIN glpi_appliances a ON a.id = ai.appliances_id
WHERE a.name = 'Service de messagerie';Nous exécutons ces deux requêtes directement sur la base de données (via un client SQL en lecture seule), jamais par un LIKE dans l'interface, car nous voulons le nombre exact d'orphelins pour dimensionner l'effort de modélisation.
La découverte automatique ne construit pas la CMDB à votre place
Il faut défaire une attente présente dans chaque projet : l'inventaire réseau par SNMP découvre les connexions physiques - si GLPI Agent scanne les switches en SNMP et que LLDP/CDP est actif, les ports réseau entre switch et hôte se peuplent tout seuls dans glpi_networkports_networkports. C'est excellent et vous ne devez pas le faire à la main. Mais la dépendance logique de service - "la messagerie dépend de ce serveur" - aucun protocole ne la découvre. L'agent ne sait pas que tel processus Exchange est votre service de messagerie critique. Cette couche est toujours une décision humaine, et c'est précisément elle qui transforme l'inventaire en CMDB.
Gardez le graphe vivant, sinon il ment
Une CMDB obsolète est pire qu'une CMDB inexistante : elle donne une fausse confiance. Vous remplacez un switch, oubliez de mettre à jour la relation, et à la panne suivante l'analyse d'impact pointe vers un équipement qui n'existe plus. Rattachez la maintenance du graphe au processus de gestion des changements - tout changement sur un CI critique doit revoir ses relations d'impact avant clôture. Sans cette discipline, le graphe vieillit en quelques semaines. C'est le même principe que la base de connaissances : une relation que personne ne maintient devient du bruit.
Vous avez besoin d'une CMDB GLPI qui soutient une vraie analyse d'impact, avec le graphe modélisé sur les bons CI et maintenu au rythme des changements ? Découvrez le service de maintenance GLPI de NexTool.
Révisé par l'équipe NexTool Solutions.
