Inventorier le parc IT avec GLPI Agent 1.17

Garder un inventaire de parc IT à jour à la main est une bataille perdue d’avance. Dès vingt postes, la dérive entre la réalité du terrain et le tableur partagé devient ingérable. GLPI 11 résout le problème avec GLPI Agent, le successeur officiel de FusionInventory Agent. La version 1.17 publiée le 31 mars 2026 est l’état de l’art : un binaire unique installé sur chaque poste qui remonte automatiquement matériel, logiciels, sessions utilisateurs, périphériques connectés et adresses IP vers le serveur GLPI.

Ce tutoriel détaille le déploiement de GLPI Agent 1.17 sur Linux, Windows et macOS, l’activation des modules d’inventaire utiles, la planification, et la première vérification côté serveur. Le contexte ITSM global est posé dans le guide GLPI 11 helpdesk ITIL : déployer un service desk professionnel.

Étape 1 — Activer l’inventaire natif côté serveur GLPI

GLPI 11 reçoit nativement les inventaires sans plugin (différence majeure avec GLPI 9.5 et antérieures qui exigeaient FusionInventory). Vérifiez que la réception est active : « Configuration » → « Générale » → « Inventaire » → « Activer l’inventaire » sur Oui. Notez l’URL d’envoi affichée, généralement https://glpi.example.com/front/inventory.php. C’est l’endpoint que les agents appelleront.

Définissez ensuite la fréquence de remontée (par défaut 24 heures, ce qui suffit pour un parc bureautique standard) et l’expiration des sessions d’inventaire. Pour un parc nomade très mobile, une fréquence de 4 à 6 heures est plus pertinente afin que les ordinateurs portables se présentent au moins une fois par jour de bureau.

Étape 2 — Installer GLPI Agent sur Linux Ubuntu/Debian

Pour un serveur Linux, le paquet Debian officiel est le plus simple. Téléchargez la dernière version 1.17 depuis GitHub et installez :

cd /tmp
wget https://github.com/glpi-project/glpi-agent/releases/download/1.17/glpi-agent_1.17-1_all.deb
sudo apt install -y ./glpi-agent_1.17-1_all.deb

L’installation crée un service systemd et déclenche un premier inventaire local. Vérifiez l’état du service :

systemctl status glpi-agent
sudo glpi-agent --list-tasks

Le service doit être active, et la liste des tâches doit inclure au minimum Inventory, NetDiscovery, NetInventory, WakeOnLan. Si vous avez installé le paquet sans dépendances, la liste sera plus courte — les paquets « extras » à installer en complément sont glpi-agent-task-network pour la découverte SNMP et glpi-agent-task-deploy pour la télé-distribution.

Étape 3 — Configurer l’agent Linux pour pointer sur le serveur

L’agent ne sait pas tout seul vers quel serveur envoyer son inventaire. Éditez /etc/glpi-agent/agent.cfg :

sudo tee /etc/glpi-agent/agent.cfg > /dev/null <<'EOF'
server = https://glpi.example.com/front/inventory.php
ca-cert-dir = /etc/ssl/certs
delaytime = 3600
httpd-trust = 127.0.0.1,10.0.0.0/8
EOF

sudo systemctl restart glpi-agent

L’option delaytime contrôle l’attente aléatoire au démarrage pour éviter que cent postes envoient leur inventaire au même instant. Le réglage httpd-trust autorise un déclenchement manuel depuis votre réseau de gestion (utile pour forcer un inventaire avant un audit).

Forcez une remontée immédiate et observez les logs :

sudo glpi-agent --no-fork --debug

La sortie doit afficher « sending data » puis « response received » avec un code 200. Si vous obtenez 401, le serveur GLPI n’accepte pas l’envoi anonyme — passez par un token de service.

Étape 4 — Déployer GLPI Agent en masse sur Windows

Sur Windows, GLPI Agent existe en MSI 64 bits signé, ce qui permet une distribution par stratégie de groupe (GPO), Microsoft Intune, ou tout outil de gestion comme Endpoint Configuration Manager. Téléchargez GLPI-Agent-1.17-x64.msi depuis la page releases du projet.

Pour un déploiement GPO en deux clics, créez un dossier réseau lisible par tous les postes, déposez-y le MSI, puis créez une nouvelle stratégie « Computer Configuration » → « Software installation » → « New Package » pointant sur le MSI. Spécifiez les paramètres MSI silencieux dans l’onglet « Modifications » via un fichier MST, ou en ligne de commande dans la GPO :

msiexec /i \\srv-deploy\share\GLPI-Agent-1.17-x64.msi /qn ^
  SERVER=https://glpi.example.com/front/inventory.php ^
  HTTPD_TRUST=10.0.0.0/8 ^
  ADD_FIREWALL_EXCEPTION=1 ^
  ALLUSERS=1

L’argument SERVER est obligatoire, le reste configure le pare-feu Windows pour autoriser le déclenchement manuel et installe le service pour tous les utilisateurs. Au prochain redémarrage du poste, le service est en place et démarre automatiquement.

Pour valider qu’un poste remonte bien, ouvrez une fenêtre PowerShell sur ce poste et lancez :

Get-Service GLPI-Agent
& "C:\Program Files\GLPI-Agent\perl\bin\glpi-agent.bat" --no-fork --debug

La commande déclenche un inventaire à la main et imprime les détails. Sur un poste sain, le premier inventaire prend entre 30 secondes et 2 minutes selon le volume de logiciels installés et la vitesse du réseau.

Étape 5 — Installer GLPI Agent sur macOS

Pour la flotte macOS, un package PKG signé est disponible. Téléchargez GLPI-Agent-1.17_x86_64.pkg pour Intel ou GLPI-Agent-1.17_arm64.pkg pour Apple Silicon. Installez :

sudo installer -pkg GLPI-Agent-1.17_arm64.pkg -target /

Configurez le serveur dans /Applications/GLPI-Agent/etc/agent.cfg avec la même syntaxe que sous Linux, puis lancez le démon :

sudo launchctl load /Library/LaunchDaemons/com.teclib.glpi-agent.plist

Sur macOS Ventura et plus récent, l’agent demande l’autorisation « Accès complet au disque » dans Préférences Système → Confidentialité pour pouvoir énumérer les logiciels et les caches utilisateur. Pensez à pré-autoriser via un profil MDM si vous gérez la flotte avec Jamf Pro, Kandji ou Mosyle, sinon l’inventaire restera partiel.

Étape 6 — Découvrir et inventorier les équipements réseau via SNMP

Les équipements réseau (switches, routeurs, imprimantes réseau, NAS) ne portent pas d’agent. GLPI les inventorie via SNMP avec les tâches NetDiscovery et NetInventory. Installez d’abord le paquet additionnel sur un agent qui agira comme « inventaire proxy ». Comme le projet GLPI ne publie pas encore ses paquets sur les dépôts officiels Debian/Ubuntu, on installe le .deb depuis GitHub :

cd /tmp
wget https://github.com/glpi-project/glpi-agent/releases/download/1.17/glpi-agent-task-network_1.17-1_all.deb
sudo apt install -y ./glpi-agent-task-network_1.17-1_all.deb

Côté GLPI, créez une « Plage IP » et associez-la à l’agent proxy : « Configuration » → « Inventaire » → « Plages IP ». Renseignez la plage CIDR à scanner (par exemple 10.0.1.0/24), les credentials SNMP (communautés v2c en lecture seule, ou v3 avec authentification), et déclenchez un balayage. GLPI Agent envoie alors une requête SNMP sur chaque IP, identifie le type d’équipement, et remonte sa fiche dans GLPI.

Les imprimantes réseau remontent en plus leurs compteurs (pages imprimées, niveaux de toner). C’est immédiatement exploitable pour facturer la consommation interne ou commander les consommables avant rupture.

Étape 7 — Lire et exploiter l’inventaire côté GLPI

Une fois les premières remontées arrivées, parcourez « Parc » → « Ordinateurs ». Vous devez voir apparaître chaque poste avec :

• Fabricant, modèle, numéro de série
• Processeur, mémoire vive, disques
• Système d’exploitation et version exacte
• Adresses IP et adresses MAC de toutes les interfaces réseau
• Logiciels installés avec leur version
• Sessions utilisateurs récentes (utile pour lier un poste à un titulaire)

Activez ensuite la jonction automatique « Ordinateur ↔ Utilisateur » : si l’agent remonte qu’un poste est utilisé par jdupont et que l’utilisateur jdupont existe dans GLPI (importé depuis l’AD comme expliqué dans Configurer LDAP/AD avec GLPI 11), la fiche ordinateur lie automatiquement les deux. Les tickets ouverts par cet utilisateur héritent du contexte matériel.

Étape 8 — Inventaire « one-shot » sans installation permanente

Certains environnements n’autorisent pas l’installation d’un service permanent (postes de prestataires, serveurs hors gestion). Pour ces cas, GLPI Agent propose un mode portable :

curl -O https://github.com/glpi-project/glpi-agent/releases/download/1.17/glpi-agent-1.17-x86_64.AppImage
chmod +x glpi-agent-1.17-x86_64.AppImage
./glpi-agent-1.17-x86_64.AppImage --server=https://glpi.example.com/front/inventory.php --no-fork --debug

L’AppImage exécute un inventaire unique, l’envoie, et se termine. Idéal pour un script d’onboarding qui inventorie un poste prêté avant restitution.

Étape 9 — Diagnostiquer une remontée qui ne passe pas

Un agent silencieux est rarement un agent installé correctement. Quatre vérifications dans l’ordre :

Service vivant. Sous Linux, systemctl status glpi-agent doit être actif. Sous Windows, Get-Service GLPI-Agent doit retourner « Running ».

Configuration serveur. Cherchez la directive server = dans la config et vérifiez l’URL exacte. Un protocole http au lieu de https ou un slash final manquant suffit à casser la remontée.

Connectivité réseau. Depuis le poste agent, testez : curl -I https://glpi.example.com/front/inventory.php. Vous devez obtenir un code 200 ou 405 (méthode non autorisée — normal, l’endpoint attend du POST). Si vous obtenez 403 ou un timeout, c’est un blocage pare-feu ou un certificat refusé.

Lecture des logs. Forcez un inventaire en mode debug : sudo glpi-agent --no-fork --debug --debug. Le second --debug active la verbosité maximale. Les erreurs deviennent évidentes : certificat non reconnu, JSON mal formé, réponse serveur HTTP 500.

Erreurs fréquentes

Indicateurs à surveiller après déploiement

Une fois le déploiement initial fait, deux chiffres trahissent la santé de votre inventaire :

• Taux de couverture = nombre de postes inventoriés / nombre de comptes utilisateurs actifs. Une valeur inférieure à 90 % révèle des postes oubliés ou des agents en panne
• Fraîcheur médiane = âge médian de la dernière remontée par poste. Plus de 7 jours pour la médiane = problème de planification ou de connectivité

Affichez les deux dans un widget dashboard GLPI et reprenez les analyses chaque mois.

Articles associés

• GLPI 11 helpdesk ITIL : déployer un service desk professionnel
• Installer GLPI 11 sur Ubuntu Server 24.04 LTS
• Configurer LDAP/AD avec GLPI 11
• Workflows ITIL incidents et demandes

Références

• Documentation officielle GLPI Agent
• Release GLPI Agent 1.17 sur GitHub
• Documentation officielle GLPI

Sécuriser les communications agent ↔ serveur

Par défaut, GLPI Agent envoie son inventaire en HTTPS si le serveur le supporte, ce qui est le cas après l’étape Let’s Encrypt du tutoriel d’installation. Mais deux mesures complémentaires renforcent la chaîne :

Filtrer l’IP source côté GLPI. Dans « Configuration » → « Inventaire » → « Adresses IP autorisées », limitez les envois aux réseaux internes connus (LAN d’entreprise, VPN clients). Un agent malveillant qui tenterait depuis Internet une remontée forgée serait refusé d’office.

Activer l’authentification HTTP côté serveur. GLPI Agent supporte deux mécanismes natifs pour authentifier la remontée. Le plus simple est l’authentification Basic via les options user et password dans agent.cfg, couplée à une protection Basic Auth sur le virtual host Apache qui sert /front/inventory.php. Une remontée sans identifiants valides est refusée par Apache avant même d’atteindre GLPI.

Depuis GLPI Agent 1.10, l’authentification OAuth2 est également disponible via oauth-client-id et oauth-client-secret, configurés côté GLPI dans les clients API. C’est l’option recommandée pour les parcs sensibles : les credentials se renouvellent indépendamment et la révocation se fait sans toucher à la configuration des agents un par un.

Sur les parcs particulièrement sensibles, ajoutez un certificat client TLS exigé par le serveur via ssl-cert-file + ssl-key-file. La documentation officielle note que cette piste exige une configuration Apache avancée et reste moins testée que Basic Auth ou OAuth2 — réservez-la aux contextes où la PKI interne est déjà mature.

Planification fine avec les profils horaires

Un parc bureautique ne demande pas la même cadence d’inventaire qu’un datacenter. GLPI Agent supporte la notion de « profils horaires » qui adaptent la fréquence selon les besoins :

• Postes bureautiques : un inventaire par 24 heures suffit ; planifier entre 9h et 17h pour profiter de la connexion
• Serveurs critiques : un inventaire par 12 heures, plus une remontée déclenchée par modification matérielle (ajout disque, changement RAM)
• Postes nomades : un inventaire par 4 heures, planifié n’importe quand car ils sont rarement connectés en continu
• Imprimantes et NAS : un inventaire par 6 heures, planifié la nuit pour éviter les pics réseau

Le paramètre delaytime + lazy côté agent permet de fixer une fenêtre aléatoire au sein de la période, ce qui lisse la charge serveur quand cent agents partagent la même fréquence. Le serveur GLPI tient sans broncher 500 inventaires par minute sur une VM 4 vCPU si la base est correctement indexée.

Lien inventaire ↔ tickets pour accélérer le diagnostic

L’inventaire prend toute sa valeur quand il rejoint le ticketing. Activez l’association automatique « Ordinateur ↔ Ticket » : quand un utilisateur ouvre un ticket depuis le portail self-service, le poste qu’il utilise (déduit de sa session active remontée par l’agent) est pré-rempli dans le ticket. Le technicien sait immédiatement quel matériel l’utilisateur a sous les doigts, quel système, et avec quels logiciels.

Pour aller plus loin, certains plugins (TicketFilter, BetterTickets) permettent de filtrer automatiquement les tickets concernant un matériel défaillant identifié dans l’inventaire (par exemple tous les ordinateurs portables d’un modèle précis avec batterie en fin de vie). C’est un cas typique de croisement ITAM × ITSM que GLPI fait nativement, là où d’autres outils exigent deux licences séparées.