{"id":2467,"date":"2026-10-08T22:20:24","date_gmt":"2026-10-08T20:20:24","guid":{"rendered":"https:\/\/procyb.fr\/?p=2467"},"modified":"2026-10-08T22:41:51","modified_gmt":"2026-10-08T20:41:51","slug":"tip-1-12-documenter-une-intervention-et-alimenter-une-base-de-connaissances","status":"publish","type":"post","link":"https:\/\/procyb.fr\/index.php\/2026\/10\/08\/tip-1-12-documenter-une-intervention-et-alimenter-une-base-de-connaissances\/","title":{"rendered":"TIP 1.12 \u2013 Documenter une intervention et alimenter une base de connaissances"},"content":{"rendered":"\n
\n
\n

Niveau : D\u00e9butant<\/p>\n\n\n\n

Dur\u00e9e : 50 \u2013 60 min<\/p>\n\n\n\n

Module : Support utilisateur TIP<\/p>\n<\/div>\n<\/div>\n\n\n\n

R\u00e9soudre un incident informatique ne suffit pas.<\/p>\n\n

Le technicien doit \u00e9galement laisser une trace claire de ce qu\u2019il a observ\u00e9, test\u00e9 et r\u00e9alis\u00e9 afin que l\u2019intervention puisse \u00eatre comprise et \u00e9ventuellement reprise par un autre membre de l\u2019\u00e9quipe.<\/p>\n\n

Lorsqu\u2019une solution est susceptible d\u2019\u00eatre r\u00e9utilis\u00e9e, elle peut ensuite \u00eatre transform\u00e9e en fiche de connaissance<\/strong>.<\/p>\n\n

\n\n

\ud83c\udfaf Objectifs<\/h3>\n\n

\u00c0 la fin de ce cours, tu seras capable de :<\/p>\n\n

    \n
  • comprendre l\u2019int\u00e9r\u00eat de la tra\u00e7abilit\u00e9 ;<\/li>\n
  • r\u00e9diger un compte rendu d\u2019intervention exploitable ;<\/li>\n
  • distinguer sympt\u00f4me, observation, test, action et r\u00e9sultat ;<\/li>\n
  • documenter une intervention chronologiquement ;<\/li>\n
  • r\u00e9diger de mani\u00e8re claire, factuelle et professionnelle ;<\/li>\n
  • \u00e9viter les informations inutiles ou sensibles ;<\/li>\n
  • distinguer un ticket d\u2019une fiche de connaissance ;<\/li>\n
  • structurer une proc\u00e9dure technique ;<\/li>\n
  • documenter les pr\u00e9requis et le r\u00e9sultat attendu ;<\/li>\n
  • utiliser correctement les captures d\u2019\u00e9cran ;<\/li>\n
  • distinguer contournement et solution d\u00e9finitive ;<\/li>\n
  • maintenir une documentation \u00e0 jour ;<\/li>\n
  • capitaliser sur les incidents r\u00e9currents.<\/li>\n<\/ul>\n\n<\/div>\n\n
    \n\n

    1. Pourquoi documenter une intervention ?<\/h2>\n\n

    Un ticket correctement document\u00e9 permet de conserver l\u2019historique de l\u2019incident.<\/p>\n\n

    Cette tra\u00e7abilit\u00e9 permet notamment :<\/p>\n\n

      \n
    • de savoir ce qui a d\u00e9j\u00e0 \u00e9t\u00e9 v\u00e9rifi\u00e9 ;<\/li>\n
    • d\u2019\u00e9viter de recommencer inutilement les m\u00eames tests ;<\/li>\n
    • de transmettre le ticket \u00e0 un autre technicien ;<\/li>\n
    • de comprendre comment l\u2019incident a \u00e9t\u00e9 r\u00e9solu ;<\/li>\n
    • d\u2019identifier les probl\u00e8mes r\u00e9currents ;<\/li>\n
    • d\u2019am\u00e9liorer les proc\u00e9dures de support ;<\/li>\n
    • d\u2019alimenter une base de connaissances.<\/li>\n<\/ul>\n\n
      \n\n

      \ud83d\udd27 R\u00e9flexe technicien<\/strong><\/p>\n\n

      Un autre technicien doit pouvoir comprendre l\u2019intervention sans avoir \u00e0 demander oralement ce qui a \u00e9t\u00e9 fait.<\/p>\n\n<\/div>\n\n

      \n\n

      2. Ce qu\u2019un compte rendu doit contenir<\/h2>\n\n

      Un compte rendu technique peut notamment indiquer :<\/p>\n\n

        \n
      • le sympt\u00f4me initial ;<\/li>\n
      • l\u2019\u00e9tendue de l\u2019incident ;<\/li>\n
      • le contexte utile ;<\/li>\n
      • les tests r\u00e9alis\u00e9s ;<\/li>\n
      • les r\u00e9sultats des tests ;<\/li>\n
      • les actions effectu\u00e9es ;<\/li>\n
      • la solution appliqu\u00e9e ;<\/li>\n
      • la validation avec l\u2019utilisateur ;<\/li>\n
      • une \u00e9ventuelle escalade.<\/li>\n<\/ul>\n\n

        Exemple<\/h3>\n\n
        \n\n

        Sympt\u00f4me :<\/strong> impossible d\u2019imprimer sur IMP-RH-01.<\/p>\n\n

        \u00c9tendue :<\/strong> incident limit\u00e9 \u00e0 PC-RH-014.<\/p>\n\n

        Test :<\/strong> imprimante joignable sur le r\u00e9seau.<\/p>\n\n

        Observation :<\/strong> documents bloqu\u00e9s dans la file d\u2019impression locale.<\/p>\n\n

        Action :<\/strong> red\u00e9marrage du service Spouleur.<\/p>\n\n

        R\u00e9sultat :<\/strong> la file d\u2019impression fonctionne \u00e0 nouveau.<\/p>\n\n

        Validation :<\/strong> impression d\u2019un document r\u00e9ussie avec l\u2019utilisateur.<\/p>\n\n<\/div>\n\n

        \n\n

        3. Distinguer observation, test, action et r\u00e9sultat<\/h2>\n\n

        Ces notions sont souvent m\u00e9lang\u00e9es dans les tickets.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
        \u00c9l\u00e9ment<\/th>\nExemple<\/th>\n<\/tr>\n<\/thead>\n\n
        Sympt\u00f4me<\/strong><\/td>\nL\u2019utilisateur ne peut plus imprimer.<\/td>\n<\/tr>\n\n
        Observation<\/strong><\/td>\nTrois documents sont bloqu\u00e9s dans la file.<\/td>\n<\/tr>\n\n
        Test<\/strong><\/td>\nPing de l\u2019imprimante effectu\u00e9.<\/td>\n<\/tr>\n\n
        R\u00e9sultat du test<\/strong><\/td>\nL\u2019imprimante r\u00e9pond.<\/td>\n<\/tr>\n\n
        Action<\/strong><\/td>\nRed\u00e9marrage du service Spouleur.<\/td>\n<\/tr>\n\n
        R\u00e9sultat<\/strong><\/td>\nLa file se vide normalement.<\/td>\n<\/tr>\n\n
        Validation<\/strong><\/td>\nImpression r\u00e9ussie par l\u2019utilisateur.<\/td>\n<\/tr>\n\n<\/tbody>\n\n<\/table>\n\n
        \n\n

        \ud83d\udd27 R\u00e9flexe technicien<\/strong><\/p>\n\n

        Un test doit toujours \u00eatre accompagn\u00e9 de son r\u00e9sultat.<\/p>\n\n<\/div>\n\n

        \n\n

        4. \u00c9viter les comptes rendus trop vagues<\/h2>\n\n

        \u00c0 \u00e9viter<\/h3>\n\n
        \n

        \u00ab Probl\u00e8me r\u00e9solu. \u00bb<\/p>\n<\/blockquote>\n\n

        Cette formulation ne permet pas de comprendre :<\/p>\n\n

          \n
        • ce qui ne fonctionnait pas ;<\/li>\n
        • ce qui a \u00e9t\u00e9 test\u00e9 ;<\/li>\n
        • ce qui a corrig\u00e9 l\u2019incident ;<\/li>\n
        • comment la r\u00e9solution a \u00e9t\u00e9 valid\u00e9e.<\/li>\n<\/ul>\n\n

          Pr\u00e9f\u00e9rer<\/h3>\n\n
          \n

          \u00ab Incident limit\u00e9 \u00e0 PC-RH-014. Imprimante r\u00e9seau joignable. Documents bloqu\u00e9s dans la file locale. Red\u00e9marrage du Spouleur effectu\u00e9. Impression test valid\u00e9e avec l\u2019utilisateur. \u00bb<\/p>\n<\/blockquote>\n\n

          \n\n

          5. \u00catre factuel et professionnel<\/h2>\n\n

          La documentation ne doit pas contenir de jugement sur l\u2019utilisateur.<\/p>\n\n

          \u00c0 \u00e9viter<\/h3>\n\n
          \n

          \u00ab L\u2019utilisateur a encore fait n\u2019importe quoi dans les param\u00e8tres. \u00bb<\/p>\n<\/blockquote>\n\n

          Pr\u00e9f\u00e9rer<\/h3>\n\n
          \n

          \u00ab L\u2019imprimante IMP-RH-02 \u00e9tait d\u00e9finie comme imprimante par d\u00e9faut. IMP-RH-01 a \u00e9t\u00e9 s\u00e9lectionn\u00e9e puis test\u00e9e avec succ\u00e8s. \u00bb<\/p>\n<\/blockquote>\n\n

          Le compte rendu doit d\u00e9crire des faits techniques.<\/p>\n\n

          \n\n

          6. Utiliser une chronologie<\/h2>\n\n

          Pour un incident complexe ou long, une chronologie facilite la compr\u00e9hension.<\/p>\n\n

          Exemple<\/h3>\n\n
          \n\n

          09:10<\/strong> \u2013 Ticket cr\u00e9\u00e9 : application inaccessible.<\/p>\n\n

          09:18<\/strong> \u2013 V\u00e9rification r\u00e9seau : poste correctement connect\u00e9.<\/p>\n\n

          09:25<\/strong> \u2013 Application inaccessible \u00e9galement depuis deux autres postes.<\/p>\n\n

          09:30<\/strong> \u2013 Incident escalad\u00e9 \u00e0 l\u2019\u00e9quipe applicative.<\/p>\n\n

          10:05<\/strong> \u2013 Service applicatif red\u00e9marr\u00e9 par l\u2019\u00e9quipe concern\u00e9e.<\/p>\n\n

          10:12<\/strong> \u2013 Acc\u00e8s valid\u00e9 avec l\u2019utilisateur.<\/p>\n\n<\/div>\n\n

          Cette chronologie permet de suivre facilement l\u2019\u00e9volution du ticket.<\/p>\n\n

          \n\n

          7. Documenter \u00e9galement les tests n\u00e9gatifs<\/h2>\n\n

          Un test qui ne r\u00e9v\u00e8le pas la cause reste utile.<\/p>\n\n

          Exemple<\/h3>\n\n

          Le technicien recherche un probl\u00e8me r\u00e9seau.<\/p>\n\n

          ping SRV-FICHIERS<\/code><\/pre>\n\n
          R\u00e9sultat :<\/p>\n\n
          \n
          R\u00e9ponse correcte du serveur.<\/p>\n<\/blockquote>\n\n
          Ce r\u00e9sultat permet d\u2019\u00e9liminer certaines hypoth\u00e8ses.<\/p>\n\n
          Il peut donc \u00eatre utile de l\u2019indiquer dans le ticket :<\/p>\n\n
          \n
          \u00ab SRV-FICHIERS joignable depuis le poste. \u00bb<\/p>\n<\/blockquote>\n\n
          \n\n
          8. Ne pas documenter de secrets<\/h2>\n\n
          Un ticket ou une base de connaissances n\u2019est pas un gestionnaire de mots de passe.<\/p>\n\n
          Il ne faut jamais y inscrire :<\/p>\n\n
            \n
          • un mot de passe ;<\/li>\n
          • un code MFA ;<\/li>\n
          • une cl\u00e9 priv\u00e9e ;<\/li>\n
          • un secret API ;<\/li>\n
          • un token d\u2019authentification ;<\/li>\n
          • des identifiants sensibles.<\/li>\n<\/ul>\n\n
            \n\n
            \ud83d\udd27 R\u00e9flexe technicien<\/strong><\/p>\n\n
            Si une proc\u00e9dure n\u00e9cessite un secret, indiquer o\u00f9 le r\u00e9cup\u00e9rer de mani\u00e8re s\u00e9curis\u00e9e plut\u00f4t que d\u2019inscrire le secret dans la documentation.<\/p>\n\n<\/div>\n\n
            \n\n
            9. Limiter les donn\u00e9es personnelles<\/h2>\n\n
            Une documentation technique doit contenir uniquement les informations n\u00e9cessaires \u00e0 l\u2019intervention.<\/p>\n\n
            \u00c9viter d\u2019ajouter :<\/p>\n\n
              \n
            • des informations personnelles sans rapport avec le ticket ;<\/li>\n
            • des commentaires sur la personne ;<\/li>\n
            • des donn\u00e9es confidentielles visibles dans une capture d\u2019\u00e9cran ;<\/li>\n
            • des informations m\u00e9dicales ou priv\u00e9es inutiles.<\/li>\n<\/ul>\n\n
              La documentation doit rester centr\u00e9e sur le probl\u00e8me technique.<\/p>\n\n
              \n\n
              10. Qu\u2019est-ce qu\u2019une base de connaissances ?<\/h2>\n\n
              Une base de connaissances<\/strong> regroupe des informations r\u00e9utilisables par les techniciens ou parfois directement par les utilisateurs.<\/p>\n\n
              Elle peut contenir :<\/p>\n\n
                \n
              • des proc\u00e9dures de d\u00e9pannage ;<\/li>\n
              • des guides d\u2019installation ;<\/li>\n
              • des solutions \u00e0 des erreurs connues ;<\/li>\n
              • des FAQ ;<\/li>\n
              • des proc\u00e9dures internes ;<\/li>\n
              • des guides utilisateurs ;<\/li>\n
              • des informations sur l\u2019environnement informatique.<\/li>\n<\/ul>\n\n
                Contrairement au ticket, la fiche de connaissance n\u2019est pas li\u00e9e uniquement \u00e0 une intervention particuli\u00e8re.<\/p>\n\n
                \n\n
                11. Ticket et base de connaissances<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n
                Ticket<\/th>\nBase de connaissances<\/th>\n<\/tr>\n<\/thead>\n\n
                D\u00e9crit un incident pr\u00e9cis<\/td>\nD\u00e9crit une solution r\u00e9utilisable<\/td>\n<\/tr>\n\n
                Concerne un utilisateur ou un contexte<\/td>\nDoit \u00eatre suffisamment g\u00e9n\u00e9rique<\/td>\n<\/tr>\n\n
                Contient l\u2019historique de l\u2019intervention<\/td>\nContient une proc\u00e9dure structur\u00e9e<\/td>\n<\/tr>\n\n
                Peut contenir des informations propres au ticket<\/td>\n\u00c9vite les informations personnelles inutiles<\/td>\n<\/tr>\n\n
                Suit l\u2019incident jusqu\u2019\u00e0 sa cl\u00f4ture<\/td>\nDoit \u00eatre maintenue dans le temps<\/td>\n<\/tr>\n\n<\/tbody>\n\n<\/table>\n\n
                \n\n
                12. Quand cr\u00e9er une fiche de connaissance ?<\/h2>\n\n
                Une fiche est particuli\u00e8rement utile lorsqu\u2019un probl\u00e8me :<\/p>\n\n
                  \n
                • revient r\u00e9guli\u00e8rement ;<\/li>\n
                • concerne plusieurs utilisateurs ;<\/li>\n
                • n\u00e9cessite toujours les m\u00eames v\u00e9rifications ;<\/li>\n
                • poss\u00e8de une solution connue ;<\/li>\n
                • doit \u00eatre trait\u00e9 de mani\u00e8re homog\u00e8ne ;<\/li>\n
                • est susceptible d\u2019\u00eatre rencontr\u00e9 par d\u2019autres techniciens.<\/li>\n<\/ul>\n\n
                  Exemple<\/h3>\n\n
                  Plusieurs tickets concernent r\u00e9guli\u00e8rement :<\/p>\n\n
                  \n
                  des documents bloqu\u00e9s dans la file d\u2019impression Windows.<\/p>\n<\/blockquote>\n\n
                  Une proc\u00e9dure peut \u00eatre cr\u00e9\u00e9e :<\/p>\n\n
                  \n
                  \u00ab Diagnostiquer une file d\u2019impression Windows bloqu\u00e9e \u00bb.<\/p>\n<\/blockquote>\n\n
                  \n\n
                  13. Choisir un bon titre<\/h2>\n\n
                  Le titre doit permettre de retrouver facilement la fiche.<\/p>\n\n
                  \u00c0 \u00e9viter<\/h3>\n\n
                  \n
                  \u00ab Impression \u00bb<\/p>\n<\/blockquote>\n\n
                  Pr\u00e9f\u00e9rer<\/h3>\n\n
                  \n
                  \u00ab Windows \u2013 Diagnostiquer des documents bloqu\u00e9s dans la file d\u2019impression \u00bb<\/p>\n<\/blockquote>\n\n
                  Le titre doit d\u00e9crire :<\/p>\n\n
                    \n
                  • l\u2019environnement ;<\/li>\n
                  • le sympt\u00f4me ;<\/li>\n
                  • ou l\u2019action recherch\u00e9e.<\/li>\n<\/ul>\n\n
                    \n\n
                    14. Structure d\u2019une fiche de connaissance<\/h2>\n\n
                    Une fiche peut suivre cette structure :<\/p>\n\n
                    \n\n
                    1. Titre<\/strong><\/p>\n\n
                    2. Contexte \/ p\u00e9rim\u00e8tre<\/strong><\/p>\n\n
                    3. Sympt\u00f4mes<\/strong><\/p>\n\n
                    4. Pr\u00e9requis<\/strong><\/p>\n\n
                    5. Diagnostic<\/strong><\/p>\n\n
                    6. Proc\u00e9dure<\/strong><\/p>\n\n
                    7. R\u00e9sultat attendu<\/strong><\/p>\n\n
                    8. Retour arri\u00e8re \u00e9ventuel<\/strong><\/p>\n\n
                    9. Escalade si \u00e9chec<\/strong><\/p>\n\n
                    10. Date \/ version de la fiche<\/strong><\/p>\n\n<\/div>\n\n
                    \n\n
                    15. D\u00e9finir le p\u00e9rim\u00e8tre<\/h2>\n\n
                    Une proc\u00e9dure doit pr\u00e9ciser \u00e0 quels syst\u00e8mes elle s\u2019applique.<\/p>\n\n
                    Exemple<\/h3>\n\n
                    \n
                    P\u00e9rim\u00e8tre :<\/strong> postes Windows 11 g\u00e9r\u00e9s par le service informatique et utilisant les imprimantes r\u00e9seau d\u00e9ploy\u00e9es par l\u2019organisation.<\/p>\n<\/blockquote>\n\n
                    Cela \u00e9vite d\u2019appliquer une proc\u00e9dure \u00e0 un environnement incompatible.<\/p>\n\n
                    \n\n
                    16. D\u00e9crire les pr\u00e9requis<\/h2>\n\n
                    Avant certaines interventions, le technicien doit disposer :<\/p>\n\n
                      \n
                    • de droits sp\u00e9cifiques ;<\/li>\n
                    • d\u2019un acc\u00e8s r\u00e9seau ;<\/li>\n
                    • d\u2019un logiciel ;<\/li>\n
                    • d\u2019un fichier d\u2019installation ;<\/li>\n
                    • d\u2019une sauvegarde ;<\/li>\n
                    • d\u2019informations particuli\u00e8res.<\/li>\n<\/ul>\n\n
                      Exemple<\/h3>\n\n
                      \n
                      Pr\u00e9requis :<\/strong> disposer des droits permettant de red\u00e9marrer le service Spouleur d\u2019impression.<\/p>\n<\/blockquote>\n\n
                      \n\n
                      17. \u00c9crire une proc\u00e9dure \u00e9tape par \u00e9tape<\/h2>\n\n
                      Chaque \u00e9tape doit correspondre \u00e0 une action pr\u00e9cise.<\/p>\n\n
                      Exemple<\/h3>\n\n
                        \n
                      1. Ouvrir la console Services.<\/li>\n
                      2. Localiser le service Spouleur d\u2019impression.<\/li>\n
                      3. V\u00e9rifier son \u00e9tat.<\/li>\n
                      4. Red\u00e9marrer le service si le diagnostic le justifie.<\/li>\n
                      5. Tester une impression.<\/li>\n
                      6. Faire valider avec l\u2019utilisateur.<\/li>\n<\/ol>\n\n
                        Une proc\u00e9dure doit \u00eatre lisible et \u00e9viter les \u00e9tapes implicites lorsque celles-ci sont importantes.<\/p>\n\n
                        \n\n
                        18. D\u00e9finir le r\u00e9sultat attendu<\/h2>\n\n
                        La proc\u00e9dure doit expliquer comment savoir qu\u2019elle a fonctionn\u00e9.<\/p>\n\n
                        Exemple<\/h3>\n\n
                        \n
                        R\u00e9sultat attendu :<\/strong> les documents quittent normalement la file d\u2019impression et une page de test est imprim\u00e9e avec succ\u00e8s.<\/p>\n<\/blockquote>\n\n
                        Sans r\u00e9sultat attendu, il est difficile de d\u00e9terminer si la proc\u00e9dure est r\u00e9ellement termin\u00e9e.<\/p>\n\n
                        \n\n
                        19. Documenter le retour arri\u00e8re<\/h2>\n\n
                        Certaines modifications peuvent n\u00e9cessiter un retour \u00e0 l\u2019\u00e9tat pr\u00e9c\u00e9dent.<\/p>\n\n
                        Par exemple :<\/p>\n\n