Une base de connaissances IT que les techniciens utilisent vraiment
Pourquoi la plupart des bases de connaissances IT meurent en six mois, et comment en construire une qui réduit réellement le volume de tickets.
Le cimetière documentaire
Presque tous les services IT ont une base de connaissances. Presque aucune n'est consultée. Le scénario est toujours le même : un effort initial important, quelques dizaines d'articles rédigés, puis plus rien. Six mois plus tard, la moitié du contenu est faux et les techniciens ont cessé d'y aller.
L'échec ne vient pas du manque de rigueur. Il vient d'une erreur de conception : on écrit ce qu'on sait, au lieu d'écrire ce qui est demandé.
Partir des tickets, pas du savoir
La bonne liste d'articles à écrire est déjà dans votre outil de ticketing. Extrayez les motifs des trois derniers mois, classez-les par fréquence, et regardez les vingt premiers. Dans la plupart des organisations, ces vingt motifs représentent plus de la moitié du volume.
Vous savez maintenant quoi écrire, et dans quel ordre. Tout le reste peut attendre.
Un article utile tient en une page
Le format qui fonctionne est resserré et toujours identique :
- Symptôme tel que l'utilisateur le décrit, pas tel qu'un technicien le diagnostiquerait
- Vérifications préalables, deux ou trois maximum
- Procédure de résolution numérotée
- Quand escalader, avec le critère précis
- Date de dernière vérification
Cette dernière ligne est celle qui sauve la base. Un article dont la date remonte à deux ans se signale seul comme suspect.
La règle qui change tout
Adoptez un principe simple : un ticket résolu dont le motif n'existe pas encore dans la base donne lieu à un article avant clôture. Pas un document séparé, pas un projet documentaire : trois paragraphes rédigés à chaud, pendant que la solution est fraîche.
L'objection habituelle est le temps. Elle ne tient pas à l'examen : rédiger l'article prend cinq minutes, retrouver la solution six mois plus tard en prend trente.
Écrire pour celui qui cherche
Les techniciens ne lisent pas une base de connaissances, ils y cherchent quelque chose. Cela impose deux contraintes :
- Titrer avec les mots de l'utilisateur. Personne ne cherche « Réinitialisation du profil Outlook » ; on cherche « Outlook demande le mot de passe en boucle ».
- Répéter les termes dans le corps du texte. Les messages d'erreur exacts, les noms de logiciels tels qu'ils apparaissent à l'écran.
Un article introuvable n'existe pas.
Ouvrir aux utilisateurs, mais pas tout
Une partie des articles peut être publiée en libre-service. Le tri est simple : est publiable ce qui ne demande aucun droit particulier et ne présente aucun risque en cas d'erreur. Réinitialiser un mot de passe, connecter une imprimante, configurer sa messagerie sur mobile.
Le reste demeure interne. Une base publique remplie de procédures inapplicables détruit la confiance plus vite qu'une absence de base.
Mesurer, mais la bonne chose
Le nombre d'articles ne veut rien dire. Deux indicateurs suffisent :
- Le taux de consultation avant résolution : les techniciens s'en servent-ils réellement ?
- L'évolution du volume sur les motifs documentés : la base fait-elle baisser les tickets ?
Si le second indicateur ne bouge pas après six mois, c'est que les articles ne sont pas trouvés, ou pas exploitables. Dans les deux cas, la réponse est de réécrire les vingt premiers, pas d'en ajouter cent.
Le seuil de bascule
Une base de connaissances devient un actif le jour où un technicien la consulte par réflexe plutôt que par consigne. Ce basculement ne s'obtient pas par une politique interne : il s'obtient quand la base a répondu juste trois ou quatre fois de suite. D'où l'importance de commencer par les vingt motifs les plus fréquents.