Le GLPI Agent vous livre des centaines d'actifs en quelques jours - et aucun d'eux avec une valeur d'achat, une garantie ou un fournisseur. L'inventaire automatique remplit le matériel ; le cycle de vie financier - acquisition, amortissement, alerte de garantie et mise au rebut - est une autre couche, il vit dans l'onglet Gestion et dans la table glpi_infocoms, et c'est précisément là que presque tout projet de gestion d'actifs s'arrête à mi-chemin. Ce guide fait correspondre les cinq phases aux objets réels de GLPI, montre le cron qui déclenche vraiment les alertes et la requête que nous exécutons en support pour trouver les actifs aveugles à l'amortissement.
Ce que l'inventaire automatique ne remplit pas
La première déception de presque tout projet est la même : le client installe le GLPI Agent, voit apparaître 400 machines avec CPU, RAM, disque et numéro de série, et conclut que "la gestion d'actifs est prête". Elle ne l'est pas. L'agent collecte ce que le système d'exploitation sait de lui-même - et l'OS ne sait pas combien la machine a coûté, à qui elle a été achetée, quand la garantie expire ni à quel centre de coût elle appartient. Toutes ces données vivent dans l'Infocom (onglet Gestion de l'actif, table glpi_infocoms) et relèvent de la saisie manuelle ou de l'import. Aucune version de l'agent ne les remplit, et c'est la confusion numéro un que nous rencontrons dans les environnements hérités : un inventaire magnifique, un cycle de vie financier vide. Sans Infocom, pas d'amortissement, pas d'alerte de garantie et pas de coût total - le cycle de vie n'existe tout simplement pas sous la surface.
Les cinq phases mises en correspondance avec les objets GLPI
Avant de configurer quoi que ce soit, il faut savoir où chaque phase vit réellement dans GLPI. Il n'y a pas de module "cycle de vie" ; il y a des champs, des statuts et des tables qui, ensemble, forment le cycle. Voici la carte que nous utilisons comme checklist de déploiement :
| Phase | Où elle vit dans GLPI | Table | Rempli par |
|---|---|---|---|
| Acquisition | Onglet Gestion : fournisseur, facture, valeur, garantie | glpi_infocoms | Manuel ou import CSV |
| Déploiement | Statut + Lieu + Utilisateur/Groupe | glpi_states, glpi_locations | Agent (specs) + manuel (statut/lieu) |
| Exploitation | Tickets liés à l'actif | glpi_items_tickets | Automatique, à l'ouverture du ticket |
| Amortissement | Onglet Gestion : type, durée, coefficient | glpi_infocoms (sink_type, sink_time) | Calcul automatique de GLPI |
| Mise au rebut | Statut "Mis au rebut" + document joint | glpi_states, glpi_documents_items | Manuel |
Remarquez que seules deux lignes sont automatiques : les specs matériel et le lien actif-ticket. Tout le reste - ce qui donne un sens financier à l'actif - relève de la décision et de la discipline humaine. C'est pourquoi la gestion d'actifs échoue par le processus, pas par l'outil.
Acquisition : l'Infocom est le cœur du cycle
La phase d'acquisition se résume à bien remplir l'Infocom. Les champs qui comptent, et qui soutiennent tout le reste du cycle :
- Fournisseur, numéro de facture et date d'achat - traçabilité et base pour actionner la garantie.
- Valeur - base de calcul de l'amortissement ; sans elle la valeur résiduelle ne sort jamais.
- Durée de garantie - en mois ; utilisez
-1pour une garantie à vie. L'alerte se déclenche à compter de cette date. - Budget - relie l'actif à un centre de coût pour des rapports par poste.
Remplir cela à la main sur 400 actifs est impraticable, donc au déploiement nous importons l'Infocom avec le parc, depuis le CSV du tableau d'achat, en faisant correspondre par numéro de série. L'erreur courante ici est de laisser la valeur vide "pour remplir plus tard" : le plus tard n'arrive jamais, et l'amortissement naît mort.
Statut : une machine à états sobre
Le statut de l'actif (champ states_id, table glpi_states) est ce qui fait avancer l'actif dans le cycle : En service, En stock, En réparation, Mis au rebut. Le statut est entièrement configurable dans Configuration > Listes déroulantes > Statuts, et c'est là que vit le deuxième piège de terrain : l'explosion des statuts. Nous avons vu des environnements avec trente statuts ("En service - siège", "En service - agence 2", "En service - portable"...) qui, en pratique, mélangent statut, lieu et type, et cassent tout rapport par état. Le statut est une machine à états, pas une taxonomie : gardez-en une demi-douzaine, transversale à tout type d'actif.
Deux détails de support sur le statut et l'agent. Premièrement : dans la configuration de l'inventaire natif, vous définissez le statut par défaut des actifs nouvellement découverts - pointez-le sur "En stock" pour qu'une machine neuve n'entre pas déjà comme "En service". Deuxièmement : les actifs inventoriés sont dynamiques (is_dynamic = 1) ; si vous supprimez un actif que l'agent voit encore, il ressuscite au cycle suivant. Pour le retirer pour de bon, désinstallez l'agent de la machine ou verrouillez l'élément, ne le supprimez jamais seulement dans l'interface.
Amortissement : linéaire ou dégressif
Avec la valeur et la date d'achat dans l'Infocom, GLPI calcule la valeur résiduelle tout seul. Vous choisissez la méthode sur l'actif lui-même :
| Type (sink_type) | Comment il amortit | Quand l'utiliser |
|---|---|---|
| Linéaire | Montant fixe par an sur la durée de vie (sink_time) | Standard comptable de la plupart des actifs informatiques |
| Dégressif | Montant plus élevé au début, via un coefficient (sink_coeff) | Quand la politique fiscale exige d'accélérer la perte de valeur |
La durée (sink_time) est en années - typiquement 3 à 5 pour les ordinateurs, selon votre politique. Vous pouvez définir une valeur par défaut globale pour ne pas la saisir sur chaque actif, mais la durée de vie réelle varie selon la classe de matériel ; un serveur ne s'amortit pas comme un portable. Laissez la valeur par défaut pour le cas courant et ajustez les exceptions.
Les alertes dépendent du bon cron
L'expiration de garantie et la fin de contrat ne deviennent des notifications que si l'action automatique infocom s'exécute. Et voici le piège qui génère le plus souvent "GLPI ne m'a pas prévenu" : le cron en mode GLPI (interne) est déclenché par les visites de page. Sur une instance à faible trafic - typique de la gestion d'actifs, où seule l'équipe informatique se connecte - les actions automatiques prennent du retard ou ne s'exécutent jamais, et l'alerte de garantie ne part jamais. La correction consiste à sortir le cron du mode interne et à l'ancrer au système d'exploitation :
# /etc/cron.d/glpi - declenche les actions automatiques de GLPI toutes les 5 min.
# Parmi elles l'action "infocom" : alerte d'expiration de garantie et de fin de contrat.
*/5 * * * * www-data /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1Ensuite, dans Configuration > Actions automatiques > infocom, changez le mode d'exécution en CLI/externe. Sans cela, tout le reste du cycle de garantie est décoratif.
SQL de diagnostic : les actifs aveugles à l'amortissement
À l'entrée d'un contrat de support, avant de discuter du processus, nous mesurons le trou de l'Infocom : combien d'ordinateurs existent dans l'inventaire mais n'ont aucune information financière. Ce sont les actifs invisibles pour l'amortissement, le coût total et l'alerte de garantie. Nous l'exécutons directement contre la base de données, sur un client en lecture seule, pour avoir le nombre exact :
-- Ordinateurs SANS information financiere (infocom) :
-- inventories par l'agent, mais invisibles pour l'amortissement et les alertes de garantie.
SELECT c.id, c.name, c.serial
FROM glpi_computers c
LEFT JOIN glpi_infocoms i
ON i.itemtype = 'Computer' AND i.items_id = c.id
WHERE c.is_deleted = 0
AND c.is_template = 0
AND i.id IS NULL
ORDER BY c.name;Le même schéma vaut pour les écrans, les imprimantes et les équipements réseau - changez la table et l'itemtype. Le nombre qui en sort est la taille réelle du travail de saisie financière, et c'est souvent un choc salutaire pour qui pensait le parc "entièrement renseigné".
Mise au rebut avec une piste RGPD
La fin de vie ne se résume pas à passer le statut à "Mis au rebut". Un équipement avec des données (portable, serveur, stockage) quitte l'entreprise avec des informations personnelles à l'intérieur, et la mise au rebut a besoin d'une piste auditable pour le RGPD. Dans GLPI : changez le statut, enregistrez la date de fin d'usage dans l'Infocom et joignez la preuve de destination (certificat de destruction de disque, acte de don, manifeste de recyclage électronique) comme document de l'actif. Ainsi, quand le DPO demande "prouvez que le disque du portable de l'employé parti a été détruit", la réponse est sur l'actif lui-même, pas dans la mémoire de quelqu'un. Ne supprimez pas l'actif mis au rebut : c'est la preuve. Sortez-le seulement des rapports opérationnels en filtrant sur le statut.
Vous devez transformer un inventaire automatique en un cycle de vie d'actifs qui soutient vraiment l'amortissement, les alertes de garantie et une piste de mise au rebut ? Découvrez le service de support et de maintenance GLPI de NexTool.
Révisé par l'équipe NexTool Solutions.
