Gestion des Budgets et des Contrats avec GLPI

Pas à pas des contrats, budgets, fournisseurs et amortissement dans GLPI : comment les enregistrer, faire partir les alertes d'échéance pour de vrai (cron + glpi_alerts), diagnostiquer les contrats à échéance en SQL et choisir la bonne méthode d'amortissement.

Dans cet article8 sections

Piloter l'informatique sans contrôle financier, c'est naviguer sans boussole. GLPI propose des modules natifs pour les contrats, les budgets, les fournisseurs et l'amortissement, tous liés aux actifs et aux tickets. En pratique, la difficulté n'est pas la saisie : c'est de faire partir les alertes et de faire tomber les chiffres juste.

Contrats : quoi enregistrer (et ce qui manque souvent)

Dans Gestion > Contrats, chaque contrat doit porter :

  • Identification : numéro, type (support, maintenance, location, licence) et fournisseur lié.
  • Durée : date de début et durée en mois. GLPI ne stocke pas de date de fin ; elle est calculée à partir du début plus la durée.
  • Préavis (notice) : en mois. Il fixe l'anticipation avec laquelle l'alerte de renouvellement doit arriver.
  • Renouvellement : jamais, tacite ou exprès.
  • Coûts : dans l'onglet coûts, avec une périodicité (mensuelle, annuelle) pour que la consommation colle au budget.
  • Actifs couverts : liez ordinateurs, serveurs et autres éléments pour savoir ce qui perd sa couverture à l'échéance.

Le piège classique : enregistrer le contrat avec une durée 0 (indéterminée). Sans durée, pas de date de fin calculable, et l'alerte d'échéance ne part tout simplement jamais.

Faire partir les alertes pour de vrai

Trois couches doivent être actives en même temps, sinon aucun e-mail ne sort :

  1. Notifications globales activées dans Configuration > Notifications, avec un destinataire réel configuré.
  2. Alerte activée sur le contrat lui-même (fin de contrat et/ou préavis). La valeur par défaut vient de la clé default_contract_alert.
  3. Action automatique en marche. La tâche contract n'envoie que si le cron de GLPI est réellement appelé.

Dans les environnements client, la panne numéro un est le cron à l'arrêt. Assurez-vous que GLPI est déclenché par le système d'exploitation, et pas seulement quand quelqu'un ouvre l'interface :

# /etc/cron.d/glpi - déclenche les actions automatiques de GLPI chaque minute
* * * * * www-data /usr/bin/php /var/www/html/glpi/front/cron.php >/dev/null 2>&1

Ensuite, dans Configuration > Actions automatiques, ouvrez la tâche contract et vérifiez : mode CLI/externe, fréquence (quotidienne par défaut) et la date de la dernière exécution. Si le mode est "GLPI" (interne), la tâche dépend de quelqu'un qui navigue dans le système au bon moment, ce qui est fragile.

L'alerte configurée qui ne renvoie pas

Voici le détail qui n'apparaît qu'en exploitation : GLPI écrit dans glpi_alerts chaque notification déjà envoyée pour ne pas dupliquer. Si l'e-mail a échoué (mauvais SMTP, boîte pleine) mais que la ligne a été écrite, GLPI considère "déjà prévenu" et ne renvoie pas, même après correction du SMTP. Pour forcer le renvoi d'un contrat précis, effacez le marqueur d'alerte :

-- Trouver l'id du contrat par son nom
SELECT id, name FROM glpi_contracts WHERE name LIKE '%Support Datacenter%';

-- Supprimer le marqueur d'alerte déjà envoyée (ex. contrat 42)
DELETE FROM glpi_alerts
WHERE itemtype = 'Contract' AND items_id = 42;

À la prochaine exécution du cron, la tâche contract réévalue l'échéance et renvoie. Idem pour les garanties, en remplaçant par itemtype = 'Infocom'.

Diagnostic rapide : contrats à échéance

Avant de faire confiance au tableau de bord, un SELECT direct confirme ce qui arrive vraiment à échéance dans les 90 prochains jours, avec le fournisseur et les jours restants :

SELECT c.id,
       c.name                                            AS contrat,
       s.name                                            AS fournisseur,
       c.begin_date,
       DATE_ADD(c.begin_date, INTERVAL c.duration MONTH) AS fin,
       DATEDIFF(DATE_ADD(c.begin_date, INTERVAL c.duration MONTH),
                CURDATE())                               AS jours_restants
FROM glpi_contracts c
LEFT JOIN glpi_contracts_suppliers cs ON cs.contracts_id = c.id
LEFT JOIN glpi_suppliers s            ON s.id = cs.suppliers_id
WHERE c.is_deleted  = 0
  AND c.is_template = 0
  AND c.duration    > 0
  AND DATE_ADD(c.begin_date, INTERVAL c.duration MONTH)
      BETWEEN CURDATE() AND DATE_ADD(CURDATE(), INTERVAL 90 DAY)
ORDER BY fin ASC;

Exécutez-le en lecture seule. C'est le même calcul que celui de l'interface, pratique pour auditer avant un renouvellement en lot.

Budgets liés aux contrats et aux achats

Dans Gestion > Budgets, définissez le montant, la période (annuelle, semestrielle ou par projet) et le type. Le point que beaucoup ignorent : le budget dans GLPI est une référence de suivi, pas un blocage. Il n'empêche pas les saisies au-dessus du plafond ; il montre le prévu face au consommé dès que vous liez les coûts des contrats et les informations financières des actifs (Infocom) à ce budget. Sans ce lien, la consommation reste à zéro et le rapport trompe.

Amortissement des actifs

Chaque actif possède un onglet Gestion (Infocom) avec valeur d'achat, date d'acquisition, garantie et amortissement. GLPI calcule la valeur comptable automatiquement à partir du type et de la durée. Choisir la bonne méthode évite une distorsion du TCO :

ScénarioType (sink_type)Durée typique (années)Remarque
Portables et postes fixesLinéaire4 à 5Perte constante ; simple à auditer.
Serveurs et stockageLinéaire5 à 7Suivez la garantie étendue en parallèle.
Matériel à perte accélérée au débutDégressif3 à 5Exige un coefficient (sink_coeff) cohérent.
Licence ou actif sans valeur résiduelle notableLinéaire1 à 3Alignez la durée sur la période du contrat.

Définissez les valeurs par défaut dans Configuration > Général > onglet Parc pour ne pas les saisir un par un. L'erreur courante ici est de laisser la date de début d'utilisation vide : sans elle, GLPI n'a pas de point de départ pour amortir, et la valeur comptable reste égale à la valeur d'achat pour toujours.

Rapports et coût par ticket

  • Actifs par valeur : combien est investi par lieu ou entité.
  • Contrats à échéance : la même liste que le SELECT ci-dessus, cette fois dans le tableau de bord.
  • Amortissement : valeur comptable du parc au fil du temps.
  • Coût par ticket : valeur du contrat divisée par le nombre de tickets traités par ce fournisseur, idéal pour étayer une renégociation.

Checklist d'exploitation NexTool

Quand nous reprenons des environnements clients, avant de faire confiance à la gestion financière de GLPI, nous validons toujours la même séquence : cron appelant front/cron.php depuis le système d'exploitation (pas depuis le navigateur) ; tâche contract en mode externe avec une dernière exécution récente ; notifications globales actives et un destinataire réel sur l'alerte ; contrats sans duration = 0 abusif ; et un balayage de glpi_alerts quand le client dit qu'il "ne reçoit plus d'e-mails". Neuf cas sur dix de "GLPI ne prévient pas de l'échéance" tombent sur l'un de ces cinq points, pas sur un bug du produit.

Besoin de faire fonctionner les contrats, budgets et alertes GLPI de bout en bout ? NexTool déploie et maintient ces flux dans des environnements clients B2B : découvrez le support d'exploitation NexTool.


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

Questions fréquentes

C'est presque toujours l'une de trois causes : notifications globales désactivées, alerte non activée sur le contrat lui-même, ou l'action automatique 'contract' qui ne tourne pas parce que le cron système (front/cron.php) n'est pas planifié. Vérifiez les trois avant de soupçonner un bug.

Il ne la stocke pas. La date de fin est calculée à partir de begin_date plus duration (en mois). C'est pourquoi un contrat avec une durée 0 (indéterminée) ne produit jamais d'alerte d'échéance.

GLPI enregistre chaque alerte envoyée dans glpi_alerts pour éviter les doublons. Supprimez la ligne correspondante (itemtype égal à 'Contract' ou 'Infocom' et l'items_id de l'objet) et la prochaine exécution du cron réévalue et renvoie.

Le linéaire répartit la perte de valeur en parts égales sur la durée (sink_time). Le dégressif concentre la perte au début avec un coefficient (sink_coeff). Pour un parc informatique standard, le linéaire est plus simple à auditer.

Non. Le budget est une référence de suivi (prévu face au consommé), pas un contrôle bloquant. La consommation n'apparaît qu'une fois que vous liez les coûts des contrats et les informations financières des actifs au budget.

Besoin d'aide ?