Polarys
GLPI : administrer son parc et son helpdesk/Inventorier le parc automatiquement

Inventorier le parc automatiquement

La chaîne d'inventaire, de bout en bout

Qui parle à qui

Comprendre l'enchaînement évite la moitié des diagnostics. L'agent est installé sur le poste, il collecte, et c'est lui qui contacte le serveur, jamais l'inverse.

flowchart LR
    A[Poste\nagent GLPI] -->|inventaire XML\nHTTP sortant| B[Serveur GLPI\n/front/inventory.php]
    B --> C[(Base MariaDB)]
    B --> D[Règles d'import\net de rapprochement]
    D --> C

Trois conséquences pratiques découlent de ce sens unique.

Aucun port entrant n'est à ouvrir sur les postes. Le flux part du poste vers le serveur, en HTTP ou HTTPS. Un poste nomade qui rentre au bureau remonte tout seul.

Un poste éteint ne remonte rien, et son absence d'inventaire n'est pas une panne. C'est d'ailleurs l'information la plus utile de l'inventaire : la liste des machines qui n'ont plus donné signe de vie depuis trente jours.

Le rapprochement se fait côté serveur. GLPI décide si l'inventaire reçu correspond à une machine connue ou à une nouvelle, selon des règles d'import qu'on peut ajuster.

Activer l'inventaire, sans quoi rien n'arrive

Le point que tout le monde oublie au premier essai : la réception d'inventaire est désactivée par défaut. Elle s'active dans l'administration, section inventaire, par une case à cocher.

Sans cela, l'agent envoie ses données, le serveur les refuse, et l'agent signale un succès d'envoi. Le symptôme est donc : rien n'apparaît, et rien ne semble en erreur.

Ce que l'agent remonte, et ce qu'il ne remonte pas

Il remonte le matériel, le système, les logiciels installés, les volumes, les cartes réseau et leurs adresses, les moniteurs branchés, les imprimantes locales, parfois l'antivirus et les machines virtuelles hébergées.

Il ne remonte pas les données des utilisateurs, ni le contenu des disques, ni l'activité. Le dire explicitement compte : le déploiement d'un agent sur les postes est un sujet de confiance, et la réponse précise vaut mieux qu'une réponse rassurante.

Le rapprochement, et les doublons

Le serveur reconnaît une machine par un faisceau de critères : numéro de série, identifiant unique du matériel, adresses réseau, nom.

Les doublons apparaissent quand ce faisceau est faible. Deux cas reviennent.

Les machines virtuelles clonées qui partagent le même identifiant unique, parce que le modèle n'a pas été généralisé avant le clonage.

Les machines sans numéro de série exploitable, fréquentes sur les assemblages et certaines VM, où le constructeur laisse une chaîne générique.

La parade est le tag d'agent : une étiquette posée à l'installation, par site ou par lot, qui entre dans le rapprochement et permet aussi de filtrer les inventaires par origine.

Le rythme

L'agent s'exécute par défaut toutes les quelques heures, avec un décalage aléatoire pour ne pas faire arriver tout le parc en même temps.

Un inventaire quotidien par poste suffit très largement. Augmenter la fréquence gonfle l'historique sans rien apporter : un poste ne change pas de processeur trois fois par jour.

Pour forcer une remontée immédiate lors d'un test, l'agent expose une page locale sur le port 62354, avec un bouton d'exécution. C'est l'outil de diagnostic le plus direct, et il est local à la machine.

À retenir

L'agent contacte le serveur, jamais l'inverse : rien à ouvrir en entrée. La réception d'inventaire est désactivée par défaut, et son oubli produit un échec silencieux. Un inventaire par jour suffit. Et la page locale sur le port 62354 force une remontée pour tester.

Quiz de validation

Quiz - 3 questions

1. Dans quel sens circule l'inventaire ?

2. L'agent est installé, il signale un envoi réussi, et rien n'apparaît dans GLPI. Que vérifier en premier ?

3. Quelle cause produit des doublons d'ordinateurs dans l'inventaire ?

Suis ta progression

Crée un compte gratuit pour suivre ta progression et accéder à toutes les leçons.