NexTool Solutions

Une enquête de satisfaction à laquelle personne ne répond ne produit aucune décision. Ce guide montre comment GLPI déclenche, stocke et mesure réellement l'enquête de satisfaction - de quelle colonne provient chaque réglage, pourquoi elle n'est parfois tout simplement pas envoyée, et ce que nous faisons en maintien en condition des environnements clients pour sortir le taux de réponse du plancher.

Où l'enquête se configure (et pourquoi c'est par entité)

Contrairement à ce que beaucoup cherchent, l'enquête de satisfaction dans GLPI n'est pas un bouton global : elle se configure par entité, dans Administration > Entités > (sélectionnez l'entité) > onglet Assistance. Chaque champ de l'écran écrit dans une colonne de la table glpi_entities, et la valeur peut être héritée de l'entité parente. Connaître la colonne derrière chaque champ, c'est ce qui permet de diagnostiquer par SQL quand l'interface "dit" que tout va bien.

Le champ Configuration à -2 (hériter) est le piège silencieux : une sous-entité peut sembler active alors qu'elle hérite en réalité de "aucune enquête" depuis la racine. Les versions récentes ont apporté la même mécanique aux Changements, dans des colonnes équivalentes avec le suffixe _change.

Le vrai déclencheur : la clôture + le cron, pas la résolution

Voici la cause numéro 1 de "l'enquête ne part pas". L'enquête ne naît pas quand le ticket est résolu (statut 5, Résolu) ; elle naît quand le ticket est clos (statut 6, Clos) et, même alors, seulement quand la tâche de cron createinquest s'exécute et tire ce ticket au sort dans la limite du inquest_rate. Deux prérequis indépendants :

1. Le ticket doit se clore. Si la clôture automatique est désactivée et que les techniciens se contentent de "résoudre", les tickets restent Résolu pour toujours et aucune enquête n'est générée. La clôture automatique est le champ autoclose_delay de l'entité elle-même.
2. Le cron doit tourner en mode externe. La tâche createinquest génère les enquêtes des tickets clos. En mode interne, elle ne s'exécute que lorsque quelqu'un charge une page - dans les entités à faible trafic, elle peut rester des jours sans tourner.

C'était exactement le cas dans un environnement que nous avons repris : l'enquête était "activée" depuis des mois et la base de données ne contenait pas une seule réponse. Ce n'était ni le modèle ni le taux. createinquest était en mode interne (mode = 1) sur un GLPI à faible trafic, donc le cron ne se déclenchait presque jamais ; et, pire encore, la clôture automatique était désactivée, donc presque rien n'atteignait le statut Clos. Nous avons activé le cron externe du système d'exploitation et ajusté autoclose_delay : les enquêtes ont commencé à être générées le jour même. Depuis, vérifier ces deux points est devenu un point fixe de notre runbook chaque fois que nous reprenons un GLPI.

Le cron externe est une ligne dans le crontab du système, exécutée avec l'utilisateur PHP :

# /etc/cron.d/glpi - cron externe de GLPI (utilisateur PHP-FPM)
# 1 exécution par minute ; traite TOUTES les tâches en mode externe,
# y compris "createinquest" (génération des enquêtes de satisfaction).
* * * * *  apache  /usr/bin/php /var/www/glpi/front/cron.php >/dev/null 2>&1

Et le diagnostic direct dans la base de données confirme que la tâche est active et sa dernière exécution :

-- État de la tâche qui génère les enquêtes (utiliser un utilisateur en lecture seule)
-- state: 0=désactivée 1=en attente 2=en cours
-- mode:  1=interne (s'exécute au chargement de page)  2=externe (cron du SE)
-- frequency: intervalle en secondes (par défaut 86400 = 1 jour)
SELECT name, state, mode, frequency,
       lastrun,
       DATE_ADD(lastrun, INTERVAL frequency SECOND) AS prochaine_prevue
FROM glpi_crontasks
WHERE name = 'createinquest';

Le modèle de notification

Une fois l'enquête générée, c'est la notification qui invite l'utilisateur. Personnalisez-la dans Configuration > Notifications > Modèles de notification, dans le modèle lié à l'événement de satisfaction du Ticket. Les balises utiles :

• ##ticket.urlsatisfaction## - lien direct et authentifié vers l'enquête (le plus important).
• ##ticket.id## et ##ticket.title## - référence pour que l'utilisateur se souvienne de l'intervention.
• ##satisfaction.text## / ##satisfaction.type## - texte et type de l'enquête.

L'erreur courante ici est de soigner un e-mail long : plus il y a de texte avant le lien, plus la conversion baisse. Une ligne de contexte, le lien, terminé.

Mesurer le taux de réponse pour de vrai

La moyenne honnête de réponse aux enquêtes par e-mail se situe dans la fourchette de 10% à 20% ; considérer 30% comme "mauvais" est irréaliste. Toutes les réponses vivent dans glpi_ticketsatisfactions, une ligne par enquête générée. Quand elle n'a pas été répondue, date_answered est nul - c'est ainsi qu'on sépare "envoyée" de "répondue" :

-- Taux de réponse et moyenne (90 derniers jours), utilisateur en lecture seule
-- type: 1=interne (étoiles)  2=externe (URL)
-- satisfaction: 0 à 5 ; date_answered nul = pas encore répondue
SELECT
    COUNT(*)                                                   AS generees,
    SUM(date_answered IS NOT NULL)                            AS repondues,
    ROUND(100 * SUM(date_answered IS NOT NULL) / COUNT(*), 1) AS taux_reponse_pct,
    ROUND(AVG(CASE WHEN date_answered IS NOT NULL
                   THEN satisfaction END), 2)                 AS moyenne_0a5
FROM glpi_ticketsatisfactions
WHERE date_begin >= DATE_SUB(CURDATE(), INTERVAL 90 DAY);

Notez que la moyenne ne considère que ceux qui ont répondu. Calculer la moyenne sur toutes les lignes (valeurs nulles incluses) fausse le chiffre et c'est une autre distorsion que nous avons déjà corrigée dans un rapport client.

Sortir le taux de réponse du plancher

Une configuration correcte est un prérequis ; le volume de réponses est une autre bataille. Ce qui fonctionne en pratique :

• Bloquer les nouveaux tickets jusqu'à la réponse avec le module Pending Survey : l'utilisateur retrouve l'enquête en attente en essayant d'ouvrir le ticket suivant. C'est ce qui fait le plus bouger l'aiguille.
• Réduire le inquest_delay pour générer l'enquête près de la clôture, tant que l'intervention est encore fraîche en mémoire.
• Notifier par un autre canal en plus de l'e-mail, par exemple via WhatsApp.
• Rester simple : 1 note et 1 commentaire facultatif. Une enquête longue casse la conversion.

Un piège du inquest_rate : le tirage a lieu au moment du cron et n'est pas rétroactif. Passer de 100% à 30% n'"annule" pas les enquêtes déjà générées, et remonter ne récupère pas les tickets déjà passés - le filigrane max_closedate n'avance que vers l'avant.

Besoin d'une satisfaction qui mesure vraiment, avec un cron fiable et un taux de réponse sain ? Le support GLPI de NexTool prend en charge la configuration, la surveillance du cron et les rapports mensuels pour votre exploitation. Découvrez le service de support et de maintenance.

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