Niveau : Débutant
Durée : 50 – 60 min
Module : Support utilisateur TIP
Résoudre un incident informatique ne suffit pas.
Le technicien doit également laisser une trace claire de ce qu’il a observé, testé et réalisé afin que l’intervention puisse être comprise et éventuellement reprise par un autre membre de l’équipe.
Lorsqu’une solution est susceptible d’être réutilisée, elle peut ensuite être transformée en fiche de connaissance.
🎯 Objectifs
À la fin de ce cours, tu seras capable de :
- comprendre l’intérêt de la traçabilité ;
- rédiger un compte rendu d’intervention exploitable ;
- distinguer symptôme, observation, test, action et résultat ;
- documenter une intervention chronologiquement ;
- rédiger de manière claire, factuelle et professionnelle ;
- éviter les informations inutiles ou sensibles ;
- distinguer un ticket d’une fiche de connaissance ;
- structurer une procédure technique ;
- documenter les prérequis et le résultat attendu ;
- utiliser correctement les captures d’écran ;
- distinguer contournement et solution définitive ;
- maintenir une documentation à jour ;
- capitaliser sur les incidents récurrents.
1. Pourquoi documenter une intervention ?
Un ticket correctement documenté permet de conserver l’historique de l’incident.
Cette traçabilité permet notamment :
- de savoir ce qui a déjà été vérifié ;
- d’éviter de recommencer inutilement les mêmes tests ;
- de transmettre le ticket à un autre technicien ;
- de comprendre comment l’incident a été résolu ;
- d’identifier les problèmes récurrents ;
- d’améliorer les procédures de support ;
- d’alimenter une base de connaissances.
🔧 Réflexe technicien
Un autre technicien doit pouvoir comprendre l’intervention sans avoir à demander oralement ce qui a été fait.
2. Ce qu’un compte rendu doit contenir
Un compte rendu technique peut notamment indiquer :
- le symptôme initial ;
- l’étendue de l’incident ;
- le contexte utile ;
- les tests réalisés ;
- les résultats des tests ;
- les actions effectuées ;
- la solution appliquée ;
- la validation avec l’utilisateur ;
- une éventuelle escalade.
Exemple
Symptôme : impossible d’imprimer sur IMP-RH-01.
Étendue : incident limité à PC-RH-014.
Test : imprimante joignable sur le réseau.
Observation : documents bloqués dans la file d’impression locale.
Action : redémarrage du service Spouleur.
Résultat : la file d’impression fonctionne à nouveau.
Validation : impression d’un document réussie avec l’utilisateur.
3. Distinguer observation, test, action et résultat
Ces notions sont souvent mélangées dans les tickets.
| Élément | Exemple |
|---|---|
| Symptôme | L’utilisateur ne peut plus imprimer. |
| Observation | Trois documents sont bloqués dans la file. |
| Test | Ping de l’imprimante effectué. |
| Résultat du test | L’imprimante répond. |
| Action | Redémarrage du service Spouleur. |
| Résultat | La file se vide normalement. |
| Validation | Impression réussie par l’utilisateur. |
🔧 Réflexe technicien
Un test doit toujours être accompagné de son résultat.
4. Éviter les comptes rendus trop vagues
À éviter
« Problème résolu. »
Cette formulation ne permet pas de comprendre :
- ce qui ne fonctionnait pas ;
- ce qui a été testé ;
- ce qui a corrigé l’incident ;
- comment la résolution a été validée.
Préférer
« Incident limité à PC-RH-014. Imprimante réseau joignable. Documents bloqués dans la file locale. Redémarrage du Spouleur effectué. Impression test validée avec l’utilisateur. »
5. Être factuel et professionnel
La documentation ne doit pas contenir de jugement sur l’utilisateur.
À éviter
« L’utilisateur a encore fait n’importe quoi dans les paramètres. »
Préférer
« L’imprimante IMP-RH-02 était définie comme imprimante par défaut. IMP-RH-01 a été sélectionnée puis testée avec succès. »
Le compte rendu doit décrire des faits techniques.
6. Utiliser une chronologie
Pour un incident complexe ou long, une chronologie facilite la compréhension.
Exemple
09:10 – Ticket créé : application inaccessible.
09:18 – Vérification réseau : poste correctement connecté.
09:25 – Application inaccessible également depuis deux autres postes.
09:30 – Incident escaladé à l’équipe applicative.
10:05 – Service applicatif redémarré par l’équipe concernée.
10:12 – Accès validé avec l’utilisateur.
Cette chronologie permet de suivre facilement l’évolution du ticket.
7. Documenter également les tests négatifs
Un test qui ne révèle pas la cause reste utile.
Exemple
Le technicien recherche un problème réseau.
ping SRV-FICHIERSRésultat :
Réponse correcte du serveur.
Ce résultat permet d’éliminer certaines hypothèses.
Il peut donc être utile de l’indiquer dans le ticket :
« SRV-FICHIERS joignable depuis le poste. »
8. Ne pas documenter de secrets
Un ticket ou une base de connaissances n’est pas un gestionnaire de mots de passe.
Il ne faut jamais y inscrire :
- un mot de passe ;
- un code MFA ;
- une clé privée ;
- un secret API ;
- un token d’authentification ;
- des identifiants sensibles.
🔧 Réflexe technicien
Si une procédure nécessite un secret, indiquer où le récupérer de manière sécurisée plutôt que d’inscrire le secret dans la documentation.
9. Limiter les données personnelles
Une documentation technique doit contenir uniquement les informations nécessaires à l’intervention.
Éviter d’ajouter :
- des informations personnelles sans rapport avec le ticket ;
- des commentaires sur la personne ;
- des données confidentielles visibles dans une capture d’écran ;
- des informations médicales ou privées inutiles.
La documentation doit rester centrée sur le problème technique.
10. Qu’est-ce qu’une base de connaissances ?
Une base de connaissances regroupe des informations réutilisables par les techniciens ou parfois directement par les utilisateurs.
Elle peut contenir :
- des procédures de dépannage ;
- des guides d’installation ;
- des solutions à des erreurs connues ;
- des FAQ ;
- des procédures internes ;
- des guides utilisateurs ;
- des informations sur l’environnement informatique.
Contrairement au ticket, la fiche de connaissance n’est pas liée uniquement à une intervention particulière.
11. Ticket et base de connaissances
| Ticket | Base de connaissances |
|---|---|
| Décrit un incident précis | Décrit une solution réutilisable |
| Concerne un utilisateur ou un contexte | Doit être suffisamment générique |
| Contient l’historique de l’intervention | Contient une procédure structurée |
| Peut contenir des informations propres au ticket | Évite les informations personnelles inutiles |
| Suit l’incident jusqu’à sa clôture | Doit être maintenue dans le temps |
12. Quand créer une fiche de connaissance ?
Une fiche est particulièrement utile lorsqu’un problème :
- revient régulièrement ;
- concerne plusieurs utilisateurs ;
- nécessite toujours les mêmes vérifications ;
- possède une solution connue ;
- doit être traité de manière homogène ;
- est susceptible d’être rencontré par d’autres techniciens.
Exemple
Plusieurs tickets concernent régulièrement :
des documents bloqués dans la file d’impression Windows.
Une procédure peut être créée :
« Diagnostiquer une file d’impression Windows bloquée ».
13. Choisir un bon titre
Le titre doit permettre de retrouver facilement la fiche.
À éviter
« Impression »
Préférer
« Windows – Diagnostiquer des documents bloqués dans la file d’impression »
Le titre doit décrire :
- l’environnement ;
- le symptôme ;
- ou l’action recherchée.
14. Structure d’une fiche de connaissance
Une fiche peut suivre cette structure :
1. Titre
2. Contexte / périmètre
3. Symptômes
4. Prérequis
5. Diagnostic
6. Procédure
7. Résultat attendu
8. Retour arrière éventuel
9. Escalade si échec
10. Date / version de la fiche
15. Définir le périmètre
Une procédure doit préciser à quels systèmes elle s’applique.
Exemple
Périmètre : postes Windows 11 gérés par le service informatique et utilisant les imprimantes réseau déployées par l’organisation.
Cela évite d’appliquer une procédure à un environnement incompatible.
16. Décrire les prérequis
Avant certaines interventions, le technicien doit disposer :
- de droits spécifiques ;
- d’un accès réseau ;
- d’un logiciel ;
- d’un fichier d’installation ;
- d’une sauvegarde ;
- d’informations particulières.
Exemple
Prérequis : disposer des droits permettant de redémarrer le service Spouleur d’impression.
17. Écrire une procédure étape par étape
Chaque étape doit correspondre à une action précise.
Exemple
- Ouvrir la console Services.
- Localiser le service Spouleur d’impression.
- Vérifier son état.
- Redémarrer le service si le diagnostic le justifie.
- Tester une impression.
- Faire valider avec l’utilisateur.
Une procédure doit être lisible et éviter les étapes implicites lorsque celles-ci sont importantes.
18. Définir le résultat attendu
La procédure doit expliquer comment savoir qu’elle a fonctionné.
Exemple
Résultat attendu : les documents quittent normalement la file d’impression et une page de test est imprimée avec succès.
Sans résultat attendu, il est difficile de déterminer si la procédure est réellement terminée.
19. Documenter le retour arrière
Certaines modifications peuvent nécessiter un retour à l’état précédent.
Par exemple :
- modification d’un paramètre ;
- installation d’une version logicielle ;
- modification d’une configuration ;
- changement d’un pilote.
Lorsque cela est pertinent, la procédure doit expliquer comment revenir en arrière en cas d’échec.
20. Utiliser des captures d’écran
Une capture d’écran peut faciliter une procédure.
Elle doit toutefois :
- être lisible ;
- montrer uniquement ce qui est utile ;
- ne pas afficher de données sensibles ;
- correspondre à la version du logiciel documentée ;
- être accompagnée d’une explication.
🔧 Réflexe technicien
Une capture d’écran seule ne remplace pas une explication.
21. Distinguer contournement et solution
Un contournement permet de reprendre temporairement l’activité sans supprimer la cause.
Exemple
L’imprimante principale est en panne.
L’utilisateur imprime temporairement sur une autre imprimante.
C’est un :
contournement
Le remplacement ou la réparation de l’imprimante constitue la résolution réelle de l’incident.
La documentation doit clairement distinguer les deux.
22. Maintenir la documentation à jour
Une procédure peut devenir obsolète après :
- une mise à jour Windows ;
- une nouvelle version d’application ;
- un changement d’infrastructure ;
- une modification de sécurité ;
- le remplacement d’un outil.
Une fiche peut donc contenir :
- date de création ;
- date de dernière mise à jour ;
- version ;
- auteur ou responsable ;
- environnement concerné.
23. Faire relire les procédures importantes
Pour une procédure sensible ou utilisée par plusieurs techniciens, une relecture peut permettre de vérifier :
- l’exactitude technique ;
- la compréhension ;
- les risques ;
- les droits nécessaires ;
- le résultat attendu.
La méthode de validation dépend de l’organisation.
24. Manipulation pratique – Améliorer un compte rendu
Un technicien inscrit dans un ticket :
« Ça ne marchait plus. J’ai redémarré le PC et maintenant c’est bon. »
1. Quelles informations manquent ?
2. Pourquoi cette formulation est-elle insuffisante ?
3. Quelle différence faut-il faire entre l’action et la validation ?
4. Si le problème revient demain, ce ticket aidera-t-il réellement le prochain technicien ?
✅ Afficher le corrigé
1. Symptôme précis, étendue, contexte, tests éventuels, action détaillée et validation.
2. On ignore ce qui ne fonctionnait pas et pourquoi le redémarrage a été effectué.
3. L’action est le redémarrage. La validation consiste à reproduire l’opération qui échouait auparavant.
4. Peu.
Le prochain technicien ne saura pas quel était le symptôme ni quelles hypothèses envisager.
25. TP – Créer une fiche de base de connaissances
Situation
Plusieurs utilisateurs ont déjà rencontré le même incident.
Environnement : Windows 11
Symptôme : documents bloqués dans la file d’impression.
Étendue : problème limité au poste utilisateur.
Imprimante réseau : joignable.
Observation : service Spouleur bloqué.
Action efficace : redémarrage du service.
Validation : impression d’une page de test puis d’un document utilisateur.
1. Propose un titre pour la fiche.
2. Quel périmètre indiquer ?
3. Quels symptômes documenter ?
4. Quels prérequis préciser ?
5. Quelles étapes de diagnostic inscrire ?
6. Quelle procédure de correction proposer ?
7. Quel résultat attendu indiquer ?
8. Que faire si le problème revient immédiatement ?
9. Quelles informations ne faut-il surtout pas mettre dans la fiche ?
✅ Afficher le corrigé
1. Exemple de titre
« Windows 11 – Diagnostiquer des documents bloqués dans la file d’impression ».
2. Périmètre
Postes Windows 11 utilisant les imprimantes réseau de l’organisation.
3. Symptômes
Documents restant en attente alors que l’imprimante est joignable.
4. Prérequis
Droits nécessaires pour consulter ou redémarrer le Spouleur et accès à l’imprimante.
5. Diagnostic
Vérifier l’étendue, la disponibilité de l’imprimante, la file locale et l’état du service Spouleur.
6. Correction
Redémarrer le service si le diagnostic confirme qu’il est bloqué, puis refaire un test d’impression.
7. Résultat attendu
La file d’impression fonctionne et le document est imprimé correctement.
8. Poursuivre le diagnostic ou escalader plutôt que répéter indéfiniment la même action.
9. Mots de passe, secrets, informations personnelles inutiles ou données confidentielles.
🎓 Point examen
Le technicien doit être capable de produire une trace professionnelle de son intervention.
Un compte rendu de qualité doit répondre à plusieurs questions :
- Quel était le problème ?
- Qui ou quoi était concerné ?
- Quels tests ont été réalisés ?
- Quels résultats ont été obtenus ?
- Quelle action a été effectuée ?
- Comment la résolution a-t-elle été validée ?
Pour une base de connaissances :
Titre → Contexte → Symptômes → Prérequis → Diagnostic → Procédure → Résultat attendu → Escalade → Mise à jour.
✅ À retenir
Traçabilité → permet de comprendre et reprendre une intervention.
Ticket → décrit un incident précis et son traitement.
Compte rendu → symptôme → tests → résultats → actions → validation.
Factuel → documenter les faits sans jugement sur l’utilisateur.
Test négatif → peut être utile car il élimine une hypothèse.
Secrets → aucun mot de passe, token, code MFA ou clé privée dans un ticket.
Base de connaissances → transforme une solution en information réutilisable.
Titre → doit permettre de retrouver facilement la procédure.
Périmètre → précise les systèmes auxquels la procédure s’applique.
Prérequis → droits, outils ou sauvegardes nécessaires.
Résultat attendu → explique comment vérifier le succès de la procédure.
Capture d’écran → utile uniquement si elle est lisible et sans donnée sensible.
Contournement ≠ résolution → préciser clairement la différence.
Documentation → doit être maintenue à jour.
Quiz final
1. Pourquoi documenter les tests réalisés ?
A. Pour éviter que le technicien suivant recommence inutilement les mêmes tests
B. Pour augmenter la RAM
C. Pour changer l’adresse IP
D. Cela ne sert à rien
2. Quel compte rendu est le plus utile ?
A. « Résolu »
B. « Ça fonctionne maintenant »
C. Symptôme, tests, résultats, action et validation
D. Aucun commentaire
3. Un test qui ne révèle pas la panne doit-il être documenté ?
A. Jamais
B. Il peut être utile car il permet d’éliminer une hypothèse
C. Uniquement pour le réseau
D. Seulement si le PC redémarre
4. Peut-on inscrire un mot de passe dans une base de connaissances ?
A. Oui
B. Non
C. Seulement administrateur
D. Uniquement temporairement
5. Quelle différence principale existe entre un ticket et une fiche de connaissance ?
A. Le ticket suit un incident précis, la fiche décrit une information réutilisable
B. Aucune différence
C. La fiche contient des mots de passe
D. Le ticket est toujours public
6. Que doit préciser le périmètre d’une fiche ?
A. Les systèmes ou environnements concernés
B. L’âge du technicien
C. Le mot de passe administrateur
D. La couleur du poste
7. À quoi sert le résultat attendu ?
A. À vérifier que la procédure a fonctionné
B. À changer l’adresse MAC
C. À créer un compte
D. À remplacer le ticket
8. Une capture d’écran contenant des données confidentielles doit :
A. Être publiée telle quelle
B. Être évitée ou nettoyée des informations sensibles
C. Être envoyée à tous les utilisateurs
D. Être utilisée comme mot de passe
9. Une solution temporaire permettant de reprendre le travail est :
A. Un contournement
B. Toujours une résolution définitive
C. Un serveur DNS
D. Une sauvegarde
10. Une fiche créée il y a plusieurs années doit-elle parfois être révisée ?
A. Oui
B. Non, jamais
C. Seulement si son titre change
D. Seulement après un incident réseau
✅ Afficher le corrigé
1. A – Éviter de recommencer les mêmes tests
La documentation facilite la reprise du ticket.
2. C – Symptôme, tests, résultats, action et validation
Ces informations permettent de comprendre réellement l’intervention.
3. B – Il peut éliminer une hypothèse
Un résultat négatif peut être important pour la suite du diagnostic.
4. B – Non
Les secrets doivent être conservés dans les outils prévus à cet effet.
5. A – Ticket précis / fiche réutilisable
Une fiche de connaissance doit pouvoir servir à d’autres incidents similaires.
6. A – Les systèmes ou environnements concernés
Cela évite d’appliquer une procédure dans un contexte incompatible.
7. A – Vérifier que la procédure a fonctionné
Le résultat attendu sert de critère de validation.
8. B – Être évitée ou nettoyée
Les données confidentielles ne doivent pas être exposées inutilement.
9. A – Un contournement
Il permet une reprise temporaire sans nécessairement résoudre la cause.
10. A – Oui
Les systèmes et procédures évoluent ; la documentation doit rester à jour.
📄 Fiche de révision
Retrouvez l’essentiel de ce cours dans une fiche synthétique à conserver ou à imprimer pour vos révisions.