NexTool Solutions

Migrer de FusionInventory vers GLPI Agent ne se résume pas à désinstaller l'un et installer l'autre. Dans les parcs GLPI que NexTool maintient pour des clients B2B, ce qui décide vraiment la migration, c'est de protéger le lien de l'actif : garantir que chaque machine ayant changé d'agent retombe sur le même enregistrement GLPI au lieu de devenir un doublon. Cet article montre comment nous planifions et exécutons ce remplacement à l'échelle du parc, du point d'ingestion à la vérification qui clôt chaque vague.

Ce qui change vraiment : le point d'ingestion

Le FusionInventory Agent alimentait GLPI via le plugin FusionInventory, avec son propre endpoint. GLPI Agent alimente l'inventaire natif du core, qui reçoit sur /front/inventory.php. Ce sont deux chemins d'ingestion différents qui coexistent sur le même serveur pendant la transition. L'agent n'est que la moitié de l'histoire : l'autre moitié, c'est que le serveur ne dépende plus du plugin. C'est pourquoi l'ordre compte - on migre d'abord le parc et seulement ensuite on désactive et désinstalle le plugin FusionInventory, jamais l'inverse. Retirer le plugin avant que le parc soit migré coupe le chemin de données des agents qui n'ont pas encore changé.

Bonne nouvelle pour qui craint de perdre des fonctions : GLPI Agent conserve les mêmes tasks que FusionInventory (Inventory, NetDiscovery, NetInventory, Deploy, ESX, Collect et RemoteInventory). Aucune découverte réseau ni déploiement n'est perdu dans le remplacement ; ce qui change, c'est le binaire et le point de livraison, pas l'ensemble des fonctions.

Le vrai risque : les actifs en doublon (et pourquoi ça arrive)

Voici le détail qui n'apparaît que lorsqu'on exploite ça en production. Chaque agent porte un deviceid (quelque chose comme hostname-2026-07-02-10-30-00). Installer GLPI Agent de zéro génère un nouveau deviceid. Cela crée un nouvel enregistrement Agent dans GLPI - mais cela ne devrait pas créer un nouvel Ordinateur, car l'appariement de l'actif se fait par les règles d'import via le numéro de série et l'UUID, pas via le deviceid.

En exploitation, ceux qui font doublon ne sont presque jamais les postes physiques : ils ont un numéro de série d'usine et s'apparient parfaitement. Ceux qui font doublon, ce sont les VM. Une machine virtuelle avec un numéro de série vide, ou un UUID cloné d'un modèle, échappe à l'appariement par série/UUID et devient un nouvel actif à chaque changement de deviceid. C'est pourquoi, avant la première vague, nous auditons les règles d'import et garantissons un critère de repli qui fonctionne pour les VM (nom + domaine), en plus du numéro de série. Sauter cet audit est l'erreur la plus coûteuse de la migration : on découvre le problème quand l'inventaire a doublé de volume.

Configuration réelle de GLPI Agent

Le cœur de la migration est le fichier de configuration. Sous Linux, il se trouve dans /etc/glpi-agent/agent.cfg (avec conf.d/ pour les overrides). Le server pointe directement vers l'inventaire natif, et le tag est ce que nous utilisons pour router l'actif vers la bonne entité du client via une règle :

# /etc/glpi-agent/agent.cfg  (remplace l'ancien agent.cfg de FusionInventory)
server       = https://glpi.client.com/front/inventory.php
tag          = siege-sp              # route l'actif vers la bonne entite via une regle
delaytime    = 3600                  # fenetre aleatoire avant le 1er envoi (evite un pic)
httpd-trust  = 127.0.0.1, 10.20.0.0/24   # IP autorisees a forcer une execution distante
httpd-port   = 62354
no-ssl-check = 0                     # 1 uniquement si le certificat GLPI est interne/auto-signe
logger       = File
logfile      = /var/log/glpi-agent.log

Sous Windows, le déploiement de masse passe par GPO ou un outil de gestion, avec le MSI silencieux. Les mêmes tag et server du fichier Linux deviennent des propriétés de l'installateur :

:: 1) Desinstaller le FusionInventory Agent (GUID dans la cle Uninstall du registre)
msiexec /x "{GUID-DU-FUSIONINVENTORY-AGENT}" /quiet /norestart

:: 2) Installer GLPI Agent pointant vers l'inventaire NATIF de GLPI
msiexec /i GLPI-Agent-1.11-x64.msi /quiet /norestart ^
  SERVER="https://glpi.client.com/front/inventory.php" ^
  TAG="siege-sp" RUNNOW=1 ADD_FIREWALL_EXCEPTION=1

La propriété RUNNOW=1 force un envoi juste après l'installation, ce qui raccourcit le cycle de validation de la vague : on n'attend pas la prochaine planification pour voir l'actif arriver. Et ADD_FIREWALL_EXCEPTION=1 ouvre le port local 62354, par lequel on force ensuite une exécution distante (utile quand un lot n'a pas remonté).

Migration par vagues, pas big bang

Remplacer tout le parc d'un coup, c'est déployer en pariant sur son week-end. Le flux que nous utilisons :

1. Auditer les règles d'import - appariement par série/UUID avec repli nom+domaine pour les VM. C'est l'étape qui évite les doublons.
2. Confirmer que l'inventaire natif est actif - le serveur doit recevoir sur /front/inventory.php avant qu'un nouvel agent n'y pointe.
3. Vague pilote - 5% à 10% du parc, segmenté par tag de site. On valide zéro doublon avant de continuer.
4. Déploiement par lot - GPO/Ansible retire FusionInventory et installe GLPI Agent. Chaque lot est vérifié avant le suivant.
5. Seulement à la fin - avec 100% migré, on désactive et désinstalle le plugin FusionInventory sur le serveur.

FusionInventory Agent vs GLPI Agent

Vérification : ce que nous contrôlons avant de clôturer une vague

Aucune vague ne se clôt juste parce que l'agent s'est installé. Le premier test est de forcer un envoi et de lire le retour, directement sur l'hôte :

# Forcer un envoi et le suivre en mode debug (Linux)
glpi-agent --force --debug

# Statut local de l'agent (port par defaut 62354)
curl -s http://localhost:62354/status

Côté serveur, le filet de sécurité est une requête qui parcourt tout le parc à la recherche du symptôme classique d'une migration ratée - deux actifs avec le même numéro de série :

-- Actifs avec le meme serial : candidats aux doublons post-migration
SELECT serial, COUNT(*) AS total, GROUP_CONCAT(id) AS ids
FROM   glpi_computers
WHERE  is_deleted = 0 AND serial <> ''
GROUP  BY serial
HAVING total > 1
ORDER  BY total DESC;

Si cette requête revient vide après la vague pilote, les règles d'import sont bonnes et le déploiement peut accélérer. Si elle revient avec des lignes, on s'arrête : c'est le moment d'ajuster la règle, pas d'installer plus d'agents. Nous vérifions aussi, dans la liste des Agents de GLPI, si le "dernier contact" se met à jour - un agent installé mais qui ne remonte pas sous 24h, c'est en général du SSL interne sans no-ssl-check, ou un pare-feu qui bloque la sortie.

Une migration de parc d'inventaire est un projet : audit des règles, pilote, déploiement maîtrisé et preuve objective que personne n'a dupliqué. Si vous exploitez GLPI avec FusionInventory et devez atteindre GLPI Agent sans mauvaise surprise, c'est exactement le travail que NexTool réalise. Parlons de vos projets d'implantation pour votre environnement GLPI.

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