ActualTime vs Contract Hours : Suivi du Temps dans GLPI

ActualTime mesure le temps réel du technicien ; Contract Hours suit le solde du contrat et le facture. Comparatif des deux plugins de temps GLPI, le compromis de l'actiontime partagé, un verdict par scénario et comment mesurer l'écart d'arrondi.

Dans cet article8 sections

Mesurer le temps sur un ticket et facturer ce temps sont deux problèmes différents. L'un concerne la productivité de l'équipe : combien de temps réel le technicien a passé. L'autre concerne le contrat : combien d'heures le client a consommées et combien il lui en reste. Confondre les deux est l'erreur que nous voyons le plus souvent en maintenance - et le choix entre ActualTime et Contract Hours commence précisément là.

Le problème : trois plans de "temps" dans GLPI

Avant de choisir un plugin, il vaut mieux séparer trois choses que GLPI traite différemment :

  • Temps estimé - la durée que vous avez planifiée pour la tâche.
  • Temps réel - le temps que le technicien a réellement mis, chronométré.
  • Temps facturable - ce qui entre dans le contrat, déjà arrondi et avec des règles commerciales.

Le champ natif Durée de la tâche (stocké en secondes dans actiontime) couvre le basique, mais exige une saisie manuelle et ne sait rien du contrat. C'est là qu'interviennent les deux plugins.

ActualTime (TICGAL)

ActualTime est un plugin gratuit et open source de TICGAL. Il ajoute des boutons play, pause et stop sur la tâche du ticket et chronomètre le temps réel que le technicien y passe. À l'arrêt, il inscrit ce temps mesuré dans la durée de la tâche. Le périmètre est honnête et étroit : transformer "je crois que j'ai mis environ 40 minutes" en un nombre mesuré. Il n'a aucune notion de contrat, de solde ou de facturation - et il n'en a pas besoin, car son but est la métrique d'effort, pas la facturation.

Contract Hours (NexTool)

Contract Hours est un module sous licence de NexTool destiné à ceux qui vendent des forfaits d'heures. Le chronomètre est sur la timeline du ticket, mais ce qu'il produit est différent : à l'arrêt, le temps est arrondi au minimum facturable configuré (15 minutes par défaut), devient une TicketTask privée automatique et débite le solde du contrat lié à ce ticket. Il apporte ce qu'ActualTime n'a pas : un quota mensuel par contrat, un relevé de consommation, un tableau de bord "Consommation d'heures" pour le client sur l'interface simplifiée, des alertes de contrat expiré ou dépassé et, depuis la version 3.6, la notion d'heures non facturables (courtoisie) - du temps enregistré mais qui ne déduit pas le solde.

Comparatif côte à côte

CritèreDurée native (manuelle)ActualTime (TICGAL)Contract Hours (NexTool)
Comment le temps est capturéSaisie manuelleChronomètre sur la tâcheChronomètre sur la timeline
Mesure le temps réelNon (ce que vous saisissez)OuiOui
Arrondi facturableNonNonOui (minimum configurable, multiple de 5)
Lien avec le contratNonNonOui (par entité ; groupe ET catégorie)
Solde / quota d'heuresNonNonOui (quota mensuel + alertes)
Heures non facturables (courtoisie)NonNonOui (bascule par tâche)
Relevé / rapport de consommationNatif (limité)BasiqueDétaillé par cycle / période
Tableau de bord pour le clientNonNonOui ("Consommation d'heures")
Où le temps est stockéactiontimeactiontimeactiontime (source de vérité) + solde
LicenceNatifGratuit (GPL)Sous licence
GLPI pris en charge10 et 1110 et 1111 uniquement

Le compromis qui compte en exploitation

En maintenance, nous avons déjà utilisé les deux : ActualTime chez des clients dont la douleur était la productivité interne, Contract Hours là où le contrat d'heures était le cœur de la facturation. Le détail qui n'apparaît qu'en exploitant est que les deux finissent par toucher le même champ natif, l'actiontime de la tâche. ActualTime y inscrit le temps réel mesuré ; Contract Hours traite l'actiontime de la tâche comme source de vérité (depuis la 3.4.2) et crée une tâche privée avec le temps déjà arrondi. Faire tourner les deux sur le même ticket, sans règle sur qui est le "propriétaire" de la tâche, produit deux durées concurrentes - la mesure brute du technicien contre l'entrée facturable arrondie. C'est pourquoi nous avons décidé de séparer les plans : ActualTime comme métrique interne (jamais facturable) et Contract Hours comme plan contractuel, sans jamais laisser les deux créer une tâche sur le même ticket. La raison est simple : le nombre qui figure sur la facture du client doit être celui arrondi et conscient du contrat, pas les secondes brutes - et les secondes brutes sont justement ce que la direction veut pour dimensionner la capacité. Deux publics, deux nombres, deux outils.

L'erreur courante est d'attendre d'ActualTime qu'il réponde "combien d'heures reste-t-il sur le contrat ?". Il n'a pas ce concept. Tout client qui a tenté de monter cela en exportant les données d'ActualTime vers un tableur a vu le nombre s'écarter de la réalité en quelques semaines. Et il y a l'écart d'arrondi : Contract Hours arrondit au minimum facturable (15 minutes par défaut, multiple de 5 pour la compatibilité GLPI). Une tâche de 3 minutes facture 15. Sur un mois avec beaucoup de tickets courts, la différence entre le total réel (ActualTime) et le total facturé (Contract Hours) est significative - et c'est exactement cette différence que vous négociez avec le client, ou que vous absorbez en courtoisie via la bascule non facturable.

Mesurez l'écart vous-même

Comme les deux plugins écrivent dans le champ natif actiontime (en secondes), vous pouvez quantifier le temps enregistré directement depuis la base de données, sans dépendre d'une table de plugin. Additionnez par technicien sur le mois et comparez avec le total facturé qui apparaît dans le relevé Contract Hours :

-- Heures enregistrées par technicien sur le mois (champ natif actiontime, en secondes)
SELECT u.name AS technicien,
       ROUND(SUM(tt.actiontime) / 3600, 2) AS heures_enregistrees
FROM glpi_tickettasks tt
JOIN glpi_users u ON u.id = tt.users_id_tech
WHERE tt.date BETWEEN '2026-06-01' AND '2026-06-30 23:59:59'
  AND tt.actiontime IS NOT NULL
GROUP BY tt.users_id_tech
ORDER BY heures_enregistrees DESC;

Si le total d'ici correspond au temps réel mesuré mais diverge du facturé, la différence est l'arrondi plus les heures de courtoisie - et c'est une information de négociation, pas une erreur.

Verdict par scénario

  • Utilisez ActualTime lorsque la question est "mon équipe est-elle productive ?". Vous voulez mesurer l'effort réel, alimenter des indicateurs internes et vous ne facturez pas à l'heure. Coût nul, installation simple.
  • Utilisez Contract Hours lorsque vous vendez des forfaits d'heures et que le client demande "combien ai-je utilisé et combien reste-t-il ?". Vous avez besoin du solde, du relevé, de l'arrondi facturable, d'un tableau de bord client et d'une alerte de dépassement. C'est un investissement, mais il se rembourse dès le premier contrat que vous cessez de sous-facturer.
  • Utilisez les deux lorsque vous voulez le réel interne ET le facturable externe, tant qu'ils sont sur des plans séparés : ActualTime comme métrique (non facturable) et Contract Hours comme facturation, avec la règle claire qu'un seul crée une tâche par ticket.
  • Restez sur le champ natif lorsque le volume est faible et que la durée manuelle suffit déjà. N'installez pas de plugin pour un problème que vous n'avez pas.

Coût et effort

ActualTime est gratuit (GPL) : le coût est celui habituel d'un plugin - valider la build pour votre version de GLPI et l'inclure dans la fenêtre de mise à niveau. Contract Hours est sous licence, mais l'effort réel de déploiement n'est pas dans le chronomètre, il est dans le modèle de contrat : définir le quota, mapper le groupe et la catégorie qui résolvent chaque contrat (la règle est ET, pas OU), configurer le minimum facturable et qui voit chaque contrat sur le tableau de bord. C'est une demi-heure de clics et quelques heures de décisions commerciales. Le retour apparaît à la première clôture de mois où le relevé sort prêt pour le client, sans tableur.

Chez NexTool, nous déployons et maintenons les deux modèles sur le GLPI de clients B2B. Si votre goulot d'étranglement est de transformer des heures de ticket en facturation défendable - avec solde, relevé et tableau de bord que le client comprend - le module Contract Hours du plugin NexTool résout exactement cela. Si vous hésitez encore sur le plan qui convient à votre exploitation, parlez-en avec nous.


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

Questions fréquentes

Oui, les deux finissent par écrire dans le champ natif actiontime de la tâche. Ils peuvent coexister, mais sur des plans séparés : ActualTime pour la métrique interne (non facturable) et Contract Hours pour la facturation. Ne laissez jamais les deux créer une tâche sur le même ticket, sinon vous additionnez la mesure brute à l'entrée arrondie et vous gonflez les heures.

Parce que Contract Hours arrondit au minimum facturable (15 minutes par défaut, multiple de 5). Une tâche de 3 minutes facture 15. La différence entre le réel et le facturé, c'est l'arrondi plus les heures marquées comme non facturables (courtoisie). C'est attendu, et c'est justement ce que vous négociez avec le client.

Non. ActualTime mesure seulement le temps réel passé sur la tâche ; il n'a aucune notion de contrat, de quota ou de solde. Pour répondre à 'combien ai-je utilisé et combien reste-t-il', il vous faut Contract Hours ou un contrôle externe, qui tend à s'écarter de la réalité avec le temps.

Non. Le module Contract Hours est réservé à GLPI 11. Sur GLPI 10, pour mesurer le temps vous utilisez ActualTime ou le champ natif de durée ; le contrôle du contrat doit être résolu autrement jusqu'à la migration vers 11.

GLPI natif propose le champ Durée sur la tâche (actiontime, en secondes). Vous pouvez le sommer par technicien via SQL ou via la recherche. Cela fonctionne pour un faible volume, mais c'est manuel et cela ne sait rien du contrat ni de l'arrondi facturable.

Besoin d'aide ?