Aller au contenu
Collabor-IA · Technique Un site du réseau Collabor-IA

Guide

Base de connaissances du support technique : la méthode

Structurer la base de connaissances d'un support technique : la fiche problème, environnement, solution, cause, et sa mise à jour au fil des tickets.

Mis à jour le

Une base de connaissances de support technique rassemble, sous une forme courte et toujours identique, les problèmes déjà rencontrés et leur solution. Elle sert d'abord à l'équipe de support et aux techniciens ; quand elle est bien tenue, elle devient aussi la matière d'un assistant d'intelligence artificielle (IA) qui répond à partir d'elle.

Pourquoi une structure fixe

Un support technique accumule des réponses partout : tickets, courriels, carnets, notes sur un téléphone. Le problème n'est pas le manque de savoir, c'est qu'on ne le retrouve pas. Une structure fixe règle deux choses : elle oblige à écrire l'essentiel, et elle permet à un moteur de recherche, ou à un assistant, de distinguer deux pannes qui se ressemblent.

Le Consortium for Service Innovation, qui publie la méthode KCS (Knowledge-Centered Service, « service centré sur la connaissance »), propose une structure simple, utilisée par de nombreux supports.

La fiche en quatre rubriques

Rubrique Ce qu'on y écrit Exemple pour un équipement
Problème La situation dans les mots du demandeur « Le compresseur s'arrête au bout de dix minutes »
Environnement Équipement, modèle, version du logiciel, configuration, changement récent Compresseur modèle X, armoire de commande version 2, filtre changé la veille
Solution Les étapes qui ont résolu le problème Vérifier le sens de montage du filtre, purger, relancer
Cause (facultative) L'origine du problème, quand elle est connue Filtre monté à l'envers après la maintenance

À cela s'ajoutent un titre qui combine le problème principal et l'environnement principal, et des métadonnées : date de création, date de dernière modification, auteur, public visé, degré de confiance.

Le guide KCS insiste sur deux points utiles pour un service technique :

  • Écrire le problème avec les mots du demandeur. Un client ou un opérateur ne dit pas « défaut de pression d'huile », il dit « le voyant rouge clignote ». Si la fiche ne contient que le vocabulaire du technicien, personne ne la retrouve.
  • Soigner l'environnement. Le guide le décrit comme l'un des principaux leviers pour retrouver une fiche. C'est aussi lui qui sépare deux pannes au symptôme identique mais à la solution différente selon le modèle ou la version.

Écrire pendant le ticket, pas après

La méthode KCS recommande de saisir l'information dans cette structure dès le début de la demande, plutôt que sur papier ou dans des notes libres. En pratique :

  1. Le technicien ouvre une fiche « en cours » dès qu'il prend le ticket et note le problème tel qu'il est formulé.
  2. Il complète l'environnement en posant ses questions de diagnostic.
  3. Il écrit la solution au moment où elle fonctionne.
  4. Il précise l'environnement une fois la solution connue : c'est souvent là qu'il comprend quel détail comptait.
  5. La fiche est relue par un pair ou par le responsable avant publication à tous.

Une fiche écrite à chaud reste courte et exacte. Une fiche écrite « quand on aura le temps » s'écrit rarement.

Ce que dit déjà le Code du travail

L'article R4323-1 du Code du travail demande à l'employeur d'informer les personnes chargées de l'utilisation ou de la maintenance des équipements de travail, notamment sur la conduite à tenir face aux situations anormales prévisibles et sur les enseignements tirés de l'expérience. L'Institut national de recherche et de sécurité (INRS), de son côté, préconise des retours d'expérience réguliers et rappelle que les documents de maintenance doivent être mis à jour et accessibles aux techniciens. Une base de connaissances bien tenue est une façon concrète de répondre à ces attentes ; elle ne les remplace pas.

Les sources à verser dans la base

  • Les notices des constructeurs, en particulier les chapitres entretien, réglage et dépannage.
  • Les procédures internes de dépannage et les gammes de maintenance.
  • Les fiches issues des tickets résolus.
  • Les réponses du constructeur ou du fournisseur à vos demandes d'assistance.
  • Les comptes rendus de retour d'expérience après une panne longue ou un incident.

À exclure ou à isoler : les données personnelles de clients non nécessaires, les documents périmés, les brouillons non validés.

Faire vivre la base

Signal Action
Une fiche est réutilisée telle quelle Rien, ou une précision dans l'environnement
Une fiche est réutilisée mais la solution a changé Corriger et dater la modification
Deux fiches décrivent la même panne Fusionner, garder les deux formulations du problème
Une question revient sans fiche Créer la fiche au prochain ticket
Un équipement est retiré du parc Archiver ses fiches, ne pas les supprimer

L'article de RingCentral sur la résolution au premier contact cite la base de connaissances parmi les leviers pour résoudre une demande dès le premier échange ; c'est l'indicateur à suivre pour savoir si la base sert (voir le taux de résolution au premier contact).

Et l'assistant IA ?

Un assistant qui répond à partir de documents fonctionne d'autant mieux que les fiches sont courtes, datées et structurées de la même façon. Avec la structure ci-dessus, il peut retrouver une fiche à partir des mots d'un opérateur, la résumer et citer la fiche d'origine. Ce qu'il faut vérifier lors des essais :

  • il cite la fiche et sa date ;
  • il dit qu'il ne sait pas quand aucune fiche ne correspond ;
  • il ne mélange pas deux environnements (deux modèles, deux versions).

Pour le premier contenu, commencez par les procédures de dépannage des pannes les plus fréquentes.

Questions fréquentes

Quelle structure donner à une fiche de support technique ?

Quatre rubriques : le problème dans les mots du demandeur, l'environnement (équipement, version, configuration), la solution pas à pas et, si elle est connue, la cause. Plus un titre et une date.

Faut-il tout écrire avant d'ouvrir la base ?

Non. La méthode la plus robuste consiste à écrire la fiche pendant la résolution du ticket, puis à la corriger à chaque réutilisation.

Sources

Pages consultées pour écrire cet article :

  1. https://library.serviceinnovation.org/KCS/Knowledge-Centered_Success_Practices_Guide/201-Solve_Loop/Practice_4_Structure/Technique_4.1
  2. https://code.travail.gouv.fr/code-du-travail/r4323-1
  3. https://www.inrs.fr/risques/maintenance/prevention.html
  4. https://www.ringcentral.com/us/en/blog/pourquoi-le-taux-de-resolution-au-premier-contact-est-un-kpi-essentiel/

À lire aussi