TIP 1.4 – Créer, qualifier et suivre un ticket d’assistance

Dans un service informatique, une demande utilisateur ne doit pas rester uniquement dans un échange oral, un e-mail ou la mémoire du technicien.

Elle doit généralement être enregistrée dans un outil de gestion des tickets, aussi appelé outil de ticketing ou helpdesk.

Le ticket permet de conserver une trace de la demande, du diagnostic, des actions réalisées et du résultat obtenu.

1. Qu’est-ce qu’un ticket d’assistance ?

Un ticket est un enregistrement permettant de suivre une demande adressée au support informatique.

Il peut concerner par exemple :

• une panne ;
• un problème logiciel ;
• une imprimante ;
• un problème de connexion ;
• une demande d’installation ;
• une création d’accès ;
• une demande d’information.

Chaque ticket possède généralement un identifiant unique.

Exemple :

INC-2026-01452

ou :

TICKET #1452

Cet identifiant permet de retrouver facilement la demande et son historique.

2. Pourquoi utiliser un outil de ticketing ?

Un outil de ticketing permet de centraliser les demandes et d’assurer leur suivi.

Il permet notamment de savoir :

• qui a signalé le problème ;
• quel équipement est concerné ;
• quand la demande a été créée ;
• quel technicien la prend en charge ;
• quelles vérifications ont déjà été réalisées ;
• si une réponse de l’utilisateur est attendue ;
• si l’incident a été résolu ;
• comment il a été résolu.

Le ticket facilite également le travail en équipe.

Si un autre technicien reprend l’intervention, il doit pouvoir comprendre rapidement ce qui a déjà été fait.

3. Incident ou demande de service ?

Les outils de support distinguent souvent plusieurs types de demandes.

Incident

Un incident correspond généralement à une interruption ou une dégradation d’un service qui fonctionnait normalement.

Exemples

• l’utilisateur ne peut plus imprimer ;
• Outlook ne démarre plus ;
• le poste n’accède plus au réseau ;
• une application affiche une erreur ;
• un ordinateur ne démarre plus.

Demande de service

Une demande de service correspond davantage à une action souhaitée par l’utilisateur sans panne préalable.

Exemples

• installer un logiciel ;
• ajouter une imprimante ;
• préparer un nouveau poste ;
• demander un accès à une ressource ;
• installer un écran supplémentaire.

4. Les informations essentielles d’un ticket

Un ticket doit contenir suffisamment d’informations pour permettre sa compréhension et son traitement.

L’utilisateur

Identifier :

• nom et prénom ;
• service ;
• coordonnées si nécessaire ;
• site ou bâtiment lorsque cela est utile.

L’équipement

Identifier si possible :

• nom du poste ;
• numéro d’inventaire ;
• imprimante ;
• smartphone ;
• équipement concerné.

La description

Décrire :

• ce que l’utilisateur voulait faire ;
• ce qui se produit réellement ;
• depuis quand ;
• le message d’erreur éventuel ;
• l’étendue du problème.

Le contexte

Préciser notamment :

• si le problème est permanent ou intermittent ;
• si d’autres utilisateurs sont concernés ;
• si une modification récente a eu lieu.

5. Rédiger un bon titre

Le titre doit permettre de comprendre rapidement le sujet du ticket.

Titres à éviter

Problème informatique

Urgent

Ça ne marche pas

Imprimante

Ces titres sont trop vagues.

Titres plus précis

Impossible d'imprimer sur KYOCERA-COMPTA depuis PC-COMPTA-12

Outlook ne démarre plus sur PC-RH-07

Accès refusé au partage \\SRV-FICHIERS\COMPTA

Demande d'installation de LibreOffice sur PC-ACCUEIL-03

6. Qualifier un ticket

Qualifier un ticket consiste à lui attribuer les informations permettant de le classer et de le transmettre correctement.

Selon l’outil utilisé, cela peut comprendre :

• type de demande ;
• catégorie ;
• sous-catégorie ;
• équipement ;
• service concerné ;
• technicien ou groupe assigné ;
• statut ;
• priorité.

Exemple

Un utilisateur ne peut plus imprimer.

La notion de priorité sera étudiée plus précisément dans TIP 1.5 avec l’impact et l’urgence.

7. Les principales catégories

L’organisation des catégories dépend de chaque entreprise.

On peut par exemple rencontrer :

• Poste de travail ;
• Windows ;
• Logiciels ;
• Messagerie ;
• Impression ;
• Réseau ;
• Compte utilisateur ;
• Accès et droits ;
• Téléphonie ;
• Matériel.

Une bonne catégorisation facilite :

• la recherche des tickets ;
• leur attribution ;
• la production de statistiques ;
• l’identification des problèmes récurrents.

8. Les statuts d’un ticket

Un ticket évolue pendant son traitement.

Les noms peuvent varier selon les outils, mais on retrouve souvent les statuts suivants.

Nouveau

Le ticket vient d’être créé et n’a pas encore été traité.

Assigné

Le ticket a été attribué à un technicien ou une équipe.

En cours

Le technicien travaille actuellement sur la demande.

En attente utilisateur

Une information ou une action de l’utilisateur est nécessaire.

Exemple :

En attente externe

Le traitement dépend d’un autre acteur.

Par exemple :

• un fournisseur ;
• un éditeur ;
• une autre équipe informatique.

Résolu

Une solution a été apportée et le fonctionnement a été rétabli.

Fermé

Le traitement est terminé et le ticket est clôturé.

9. Documenter le diagnostic

Chaque étape significative doit être consignée dans le ticket.

Exemple insuffisant

Test OK.

Cette information ne permet pas de comprendre ce qui a réellement été vérifié.

Exemple exploitable

10:15 - Prise en charge du ticket.

10:20 - Test d'impression depuis Word : document reste dans la file.

10:23 - Imprimante joignable par ping.

10:25 - Autres utilisateurs : impression fonctionnelle.

10:30 - Redémarrage du service Spouleur d'impression.

10:32 - Nouvelle impression de test : OK.

Un autre technicien peut immédiatement comprendre :

• les tests réalisés ;
• les hypothèses éliminées ;
• l’action corrective ;
• le résultat.

10. Distinguer observation et action

Une bonne documentation permet de distinguer :

Ce qui a été observé

« Document bloqué dans la file d’impression. »

Ce qui a été testé

« Imprimante joignable depuis le poste avec ping. »

Ce qui a été modifié

« Redémarrage du service Spouleur d’impression. »

Le résultat

« Impression d’une page de test : OK. »

Cette distinction améliore fortement la lisibilité du ticket.

11. Communiquer avec l’utilisateur

Le ticket sert aussi à suivre la communication avec l’utilisateur.

Il peut être nécessaire de préciser :

• qu’une intervention est en cours ;
• qu’une information supplémentaire est nécessaire ;
• que le ticket a été transmis ;
• que l’incident semble résolu.

Exemple

« Les premières vérifications ont été réalisées. J’ai besoin du message d’erreur exact affiché lors de la connexion afin de poursuivre le diagnostic. »

Le ticket peut alors passer au statut :

12. Suivre un ticket

Créer un ticket ne suffit pas.

Le technicien doit ensuite s’assurer que la demande progresse.

Il faut notamment vérifier :

• si une réponse a été reçue ;
• si une autre équipe a repris la demande ;
• si de nouvelles informations sont disponibles ;
• si l’utilisateur est toujours bloqué ;
• si l’incident peut être clôturé.

Un ticket oublié peut entraîner :

• une interruption prolongée ;
• une mauvaise expérience utilisateur ;
• une perte d’information ;
• un nouveau ticket pour le même problème.

13. Clôturer correctement un ticket

Un ticket ne doit pas être fermé simplement parce qu’une manipulation a été effectuée.

Avant la clôture, vérifier :

• que la solution a été appliquée ;
• que le résultat a été contrôlé ;
• que l’utilisateur peut reprendre son activité ;
• que les actions sont documentées.

Exemple de résolution

14. Les erreurs fréquentes

Créer un ticket trop vague

Internet HS

Cette description ne permet pas de savoir :

• quel utilisateur ;
• quel poste ;
• quel symptôme ;
• depuis quand ;
• quelle étendue.

Ne pas documenter les tests

Un technicien réalise dix manipulations mais écrit uniquement :

Problème résolu.

L’information est insuffisante pour les interventions futures.

Fermer trop rapidement

Une commande réussie ne signifie pas nécessairement que le problème utilisateur est résolu.

Copier des informations inutiles

Un ticket doit être précis, mais pas rempli de données sans rapport avec la demande.

15. Manipulation pratique – Rédiger des tickets

Transforme les demandes suivantes en tickets exploitables.

Imprimante KO

16. TP – Créer et suivre un ticket d’assistance

Situation

Paul Bernard du service Finances contacte le support.

« Je ne peux plus accéder au dossier Budget. J’y accédais encore hier. »

Après questionnement, tu apprends que :

• le poste est PC-FIN-15 ;
• la connexion réseau fonctionne ;
• Internet fonctionne ;
• le partage \\SRV-FICHIERS\BUDGET est accessible aux collègues ;
• Paul reçoit le message « Accès refusé » ;
• le problème est apparu ce matin ;
• son mot de passe a été changé hier.

10:05 - Test réseau PC-FIN-15 : OK.
10:08 - SRV-FICHIERS joignable.
10:10 - Accès au partage BUDGET fonctionnel depuis un poste voisin.
10:12 - Incident limité au compte Paul Bernard.

Quiz final