Dictionnaires GLPI : comment standardiser l'inventaire automatique

Guide technique des dictionnaires GLPI 10/11 : SQL pour cartographier le désordre de l'inventaire, règles de fabricant et regex pour les modèles, rejet des KB Windows, un rejeu contrôlé qui ne fait pas tomber le serveur et une matrice de décision sur l'action à utiliser. Comme nous le faisons en maintenance de parcs GLPI clients.

Dans cet article8 sections

Un inventaire automatique sans dictionnaires est une CMDB à laquelle personne ne se fie. Chaque agent remonte "Dell Inc.", "DELL" et "Dell Technologies" comme des fabricants différents, et le responsable ouvre le rapport de parc avec trois lignes pour la même chose. Les dictionnaires GLPI règlent cela à l'entrée des données, mais ils ne fonctionnent vraiment que si vous cartographiez le désordre d'abord, comprenez que rejeter est destructif et lancez le rejeu sans faire tomber le serveur. Ce guide est le chemin que nous utilisons en maintenance de parcs GLPI clients.

Pourquoi l'inventaire arrive sale

Quand le GLPI Agent collecte les données de centaines de machines, le même objet réel apparaît avec plusieurs orthographes, car chaque fournisseur écrit la chaîne à sa façon dans le BIOS, le registre Windows ou le paquet. Les cas classiques :

  • Fabricants : "Dell Inc.", "Dell", "DELL", "Dell Technologies" deviennent quatre enregistrements.
  • Modèles : "Latitude 5520", "LATITUDE 5520" et "Dell Latitude 5520" ne se regroupent pas.
  • Logiciels : des centaines de KB et d'entrées "Update for Windows" noient les logiciels que vous devez réellement gérer.
  • Système d'exploitation : "Windows 10 Pro", "Microsoft Windows 10 Professional" et "Win10Pro" fragmentent tout décompte de licences.

L'effet concret : des tableaux de bord aux totaux gonflés, un rapport de conformité logicielle inutile et des décisions d'achat fondées sur le mauvais chiffre. Standardiser n'est pas cosmétique : c'est ce qui rend la CMDB fiable.

Cartographiez le désordre avant d'écrire la première règle

L'erreur du débutant est de créer des règles à l'aveugle. Mesurez d'abord. Une requête SQL en lecture seule directement sur la base montre l'ampleur du problème et priorise l'effort. Lancez-la sur un réplica ou hors des heures de pointe :

-- Fabricants avec des orthographes divergentes du meme groupe
SELECT id, name
FROM glpi_manufacturers
WHERE name LIKE 'Dell%' OR name LIKE '%DELL%'
ORDER BY name;

-- Volume de "pollution" dans le catalogue de logiciels (KB et mises a jour)
SELECT COUNT(*) AS logiciels_parasites
FROM glpi_softwares
WHERE name LIKE 'KB%'
   OR name LIKE 'Update for%'
   OR name LIKE 'Security Update for%';

-- Top 20 des noms de logiciels les plus repetes (candidats a une regle)
SELECT name, COUNT(*) AS occurrences
FROM glpi_softwares
GROUP BY name
ORDER BY occurrences DESC
LIMIT 20;

Avec ces chiffres, vous savez où la règle rapporte le plus. Dans la plupart des parcs, fabricant et logiciel concentrent l'essentiel du désordre.

Les types de dictionnaire et quand utiliser chaque action

Dans Administration > Dictionnaires vous trouvez des dictionnaires pour les logiciels, le fabricant, les modèles (ordinateur, moniteur, imprimante, téléphone, réseau), les types et le système d'exploitation. Ce qui change entre eux, c'est l'action que vous choisissez. Cette matrice résume la décision :

Situation dans l'inventaireDictionnaireAction recommandéeRéversible ?Piège
Fabricant avec plusieurs orthographesFabricantAttribuer un nom fixeOuiLa fusion peut laisser une entrée orpheline dans la liste déroulante
Modèle portant le préfixe du fabricantModèlesRegex + attribuer le groupe capturéOuiExige le critère "expression régulière", pas "contient"
KB et mises à jour polluant le catalogueLogicielsIgnorer l'importPartielLe rejeu SUPPRIME le logiciel déjà importé
Versions d'OS fragmentéesSystème d'exploitationAttribuer OS / éditionOuiLe nom de l'OS et l'édition sont des champs distincts
Plusieurs logiciels qui sont le même produitLogicielsAttribuer nom + fabricantOuiRegroupe les versions ; vérifiez avant de fusionner

Normaliser fabricants et modèles (pas à pas)

  1. Dans le dictionnaire Fabricant, créez la règle : critère Nom - contient - Dell ; action Attribuer Nom = Dell. Cela réduit toutes les orthographes à un seul enregistrement.
  2. Pour les modèles qui portent le préfixe du fabricant, "contient" ne suffit pas : utilisez une regex. Réglez le critère sur expression régulière et ne capturez que la partie utile.
# Dictionnaire des Modeles d'ordinateur
# Critere -> Nom | l'expression reguliere correspond :
/^(?:Dell\s+)?(Latitude\s+\d+)/i

# Action -> Nom | Attribuer la valeur de l'expression reguliere :
#1

# Resultat :
#   "Dell Latitude 5520" -> "Latitude 5520"
#   "LATITUDE 5520"       -> "Latitude 5520"
#   "Latitude 5520"       -> "Latitude 5520"

#1 est le premier groupe capturé ; #0 serait la chaîne entière. Ce détail piège beaucoup de monde : l'action "attribuer la valeur de l'expression régulière" ne fonctionne que si le critère est réglé comme expression régulière. Avec "contient", #1 devient du texte littéral.

Rejeter les KB sans faire exploser l'inventaire

Pour sortir les mises à jour du catalogue, créez dans le dictionnaire Logiciels une règle avec l'action Ignorer l'import :

  • Critère : Nom - commence par - KB - action Ignorer l'import.
  • Critère : Nom - contient - Update for Windows - action Ignorer l'import.

Dès lors, les nouveaux imports ignorent ces éléments. Le détail que presque personne n'anticipe : lorsque vous lancez le rejeu de cette règle, GLPI supprime les logiciels déjà importés qui correspondent au critère. C'est la bonne action pour nettoyer, mais elle est destructive : c'est pourquoi elle passe toujours d'abord par un environnement de préproduction.

Rejeu : appliquer les règles aux données existantes

Une règle de dictionnaire n'agit qu'à l'entrée. Pour les données déjà en base, utilisez le bouton Rejouer les règles du dictionnaire dans chaque dictionnaire. Deux précautions d'exploitation apprises à la dure :

  • Découpez par fabricant. Dans le rejeu du dictionnaire logiciels, GLPI laisse choisir le fabricant. Tout lancer d'un coup sur un gros catalogue dépasse le max_execution_time de PHP et renvoie une erreur 500. Lancez par lots.
  • Fenêtre de faible trafic. Le rejeu retraite des milliers de lignes ; planifiez-le hors des heures ouvrées.

Après le rejeu, confirmez que la consolidation a fonctionné avec un simple décompte :

-- Il ne doit rester qu'1 enregistrement "Dell" (et non 4)
SELECT id, name FROM glpi_manufacturers
WHERE name LIKE '%Dell%';

-- Les logiciels KB doivent tendre vers zero apres le rejeu avec "Ignorer l'import"
SELECT COUNT(*) AS kb_restants
FROM glpi_softwares
WHERE name LIKE 'KB%';

L'erreur courante en maintenance client

Sur un parc client d'environ 3 000 actifs, le dictionnaire logiciels rejetant les KB et mises à jour a fait chuter le catalogue de dizaines de milliers de "logiciels" à quelques milliers d'éléments réels : le rapport de conformité est enfin devenu lisible. Mais nous avons lancé le rejeu avec "ignorer l'import" directement en production et le client a perdu la trace des machines qui avaient chaque KB, car le rejet supprime l'enregistrement, il ne fait pas que le masquer. La décision devenue règle pour tous les environnements : le rejeu de dictionnaire naît en préproduction, le rejet est traité comme une opération destructive, et une fusion de fabricant est toujours suivie d'un nettoyage des valeurs orphelines dans la liste déroulante, que GLPI ne retire pas tout seul. C'est le genre de détail qui n'apparaît qu'après l'avoir fait sur un vrai parc.

Bonnes pratiques qui évitent le retravail

  • Commencez par le fabricant et le logiciel : ils concentrent l'essentiel du désordre et rapportent vite.
  • L'ordre des règles compte : placez les plus spécifiques avant les génériques.
  • Testez toujours en préproduction et validez le rejeu avec un SQL de décompte avant et après.
  • Revoyez les dictionnaires après chaque grande vague d'inventaire (un nouveau lot de machines, une acquisition, un changement de fournisseur).
  • Documentez chaque règle : un dictionnaire sans trace du "pourquoi" devient une boîte noire à la maintenance suivante.

Standardiser l'inventaire est le socle d'indicateurs fiables et du cycle de vie des actifs. Si votre parc a grandi et que la CMDB est devenue un enchevêtrement de doublons, NexTool réalise cet assainissement dans le cadre de la maintenance : cartographie du désordre, règles de dictionnaire testées en préproduction et rejeu contrôlé, sans faire tomber votre GLPI.


Révisé par l'équipe NexTool Solutions.

Questions fréquentes

Dans Administration > Dictionnaires. De là, vous accédez aux dictionnaires des logiciels, du fabricant, des modèles (ordinateur, moniteur, imprimante, téléphone, réseau), des types et du système d'exploitation. Chaque dictionnaire est un ensemble de règles avec un critère et une action évalués lors de l'import de l'inventaire.

Pas automatiquement. La règle agit à l'entrée de nouvelles données. Pour l'appliquer aux enregistrements existants, utilisez le bouton 'Rejouer les règles du dictionnaire' dans le dictionnaire. Lancez-le découpé par fabricant et hors des heures de pointe, car le rejeu retraite des milliers de lignes et peut dépasser le temps d'exécution de PHP (erreur 500).

Créez la règle qui attribue le nom fixe (par ex. contient 'Dell' alors attribuer 'Dell') et lancez le rejeu pour réaffecter les actifs. Vérifiez ensuite dans Configuration > Listes déroulantes s'il reste des fabricants à zéro élément et purgez-les. GLPI réaffecte les actifs, mais ne supprime pas toujours l'ancienne valeur de la liste.

Oui, au moment du rejeu. L'action 'Ignorer l'import' ne se contente pas de bloquer les imports futurs : au rejeu, elle supprime les logiciels déjà importés qui correspondent au critère, et vous perdez la trace des machines qui avaient ce KB. Testez donc en préproduction et traitez le rejet comme une opération destructive.

Oui. Réglez le critère sur 'expression régulière' et utilisez des groupes de capture. Dans l'action, 'attribuer la valeur de l'expression régulière' accepte #0 (chaîne entière) et #1 à #9 (groupes capturés). L'erreur courante est de laisser le critère sur 'contient' et d'attendre que #1 fonctionne : il ne se résout que lorsque le critère est une regex.

Oui. Les règles sont évaluées de haut en bas. Placez les plus spécifiques avant les génériques pour qu'une règle large ne capture pas un cas qui devrait avoir son propre traitement. Revoyez l'ordre chaque fois que vous ajoutez de nouvelles règles.

Besoin d'aide ?