Ce qui fait vivre l'outil
Un GLPI qui ne sert qu'à l'inventaire est consulté une fois par trimestre. Un GLPI qui porte les tickets est ouvert toute la journée, et c'est ce qui maintient l'inventaire à jour : on corrige une fiche parce qu'on est dessus pour un ticket.
L'ordre de mise en service compte donc : l'inventaire d'abord, parce qu'il alimente les tickets en matériel, le helpdesk ensuite.
Les canaux d'arrivée
Trois portes, et vous n'en ouvrez pas trois d'un coup.
L'interface web, en profil Self-Service. Structurée, avec des catégories, c'est la porte qui produit les tickets les mieux qualifiés.
Le collecteur de courriel, qui relève une boîte et transforme chaque message en ticket. C'est le canal que les utilisateurs adoptent sans formation, parce qu'ils écrivaient déjà à cette adresse.
L'API, pour les intégrations.
Le collecteur demande deux précautions. Il faut une boîte dédiée, jamais une boîte personnelle, et surveiller les boucles : une réponse automatique de l'autre côté peut alimenter un ticket qui répond, qui relance, indéfiniment.
Les catégories, moins qu'on ne croit
La tentation est l'arborescence de quatre-vingts catégories, qui paraît rigoureuse. Elle produit deux effets, tous deux mauvais : l'utilisateur choisit au hasard, et le technicien passe son temps à recatégoriser.
Commencez avec une dizaine, alignées sur ce que les gens disent réellement : messagerie, poste de travail, impression, réseau, application métier, accès et comptes.
Affinez au bout de trois mois, à partir du contenu réel des tickets. Une catégorie qui n'a servi à rien en un trimestre se supprime ; une catégorie fourre-tout à cent tickets se coupe en deux.
Les SLA, seulement s'ils sont tenus
Un accord de niveau de service définit des délais de prise en charge et de résolution, avec des alertes à l'approche de l'échéance.
Le piège est d'annoncer des délais que l'équipe ne peut pas tenir. Un GLPI où tous les tickets sont en retard n'apporte rien, et le voyant rouge permanent cesse d'être lu.
La méthode qui fonctionne : mesurer trois mois sans SLA, regarder les délais réellement obtenus, puis fixer des engagements légèrement plus exigeants. Deux niveaux suffisent au début, un pour ce qui bloque l'activité, un pour le reste.
Notifications : moins vaut mieux
GLPI peut envoyer un courriel à chaque événement. Activer l'ensemble produit un bruit tel que plus personne ne lit, technicien comme demandeur.
Quatre notifications suffisent : le ticket est ouvert, il a été pris en charge, une réponse attend le demandeur, il est résolu.
Vérifiez la configuration d'envoi dès l'installation, en envoyant un message de test. Une notification qui ne part pas est invisible, et c'est le demandeur qui signalera qu'il n'a jamais eu de réponse.
La base de connaissances, alimentée par les tickets
Elle ne se remplit pas par un projet dédié, mais par un geste : à la clôture d'un ticket instructif, un lien propose d'en faire un article.
Deux règles pour qu'elle serve. Écrire pour celui qui cherchera, avec les mots du symptôme et non ceux du diagnostic. Et distinguer ce qui est public, visible du demandeur, de ce qui est interne : un article public bien écrit évite le ticket suivant.
À retenir
Le helpdesk maintient l'inventaire vivant, pas l'inverse. Une dizaine de catégories, affinées après trois mois de réel. Des SLA fondés sur des délais mesurés, sinon tout est rouge. Quatre notifications, testées. Et des articles nés des tickets, écrits avec les mots du symptôme.