Base de connaissances : réduire le volume de tickets

La demande la moins coûteuse est celle qui n'arrive jamais. Une base de connaissances ne sert pas à décorer un portail : elle sert à ce qu'un client, ou un collègue, trouve seul la réponse qui aurait sinon mobilisé quelqu'un de votre équipe. Encore faut-il écrire les bonnes fiches, les placer là où la demande se forme, et accepter que certaines demandes n'aient aucune vocation à être documentées. Voici la méthode, et ses limites.

Commencez par vos tickets, pas par ce que vous imaginez

Le sommaire d'une base de connaissances ne s'invente pas en réunion : il se lit dans l'export de vos tickets des trois derniers mois.

Ce que votre équipe croit recevoir et ce qu'elle reçoit vraiment sont deux listes différentes. La première est faite de sujets marquants, la seconde de sujets répétitifs et sans relief, qui sont précisément ceux qui coûtent. Quatre manipulations suffisent à obtenir une liste défendable :

1. Exportez une période représentative. Trois mois au minimum, douze si votre activité est saisonnière ou si vos sorties de version sont espacées.
2. Regroupez par motif réel, pas par catégorie d'outil. Les catégories que cochent vos agents servent votre reporting, rarement le demandeur. Relisez les objets et nommez le motif avec les mots du client.
3. Comptez, puis triez par volume décroissant. Vous obtenez une poignée de motifs lourds et une longue traîne de cas uniques. Les premiers méritent une fiche, les seconds non.
4. Ajoutez le temps de traitement moyen. Un motif fréquent qui mobilise vingt minutes passe devant un motif fréquent réglé en trente secondes.

Si vos demandes arrivent dans une boîte partagée ou se suivent dans un classeur, vous n'obtiendrez ni ce comptage ni ces durées. C'est déjà une information en soi, et l'un des signaux qu'un tableur a atteint ses limites.

Quelles demandes méritent une fiche, et lesquelles n'en méritent pas

Une demande mérite une fiche quand elle réunit trois conditions : elle revient, sa réponse est stable dans le temps, et le demandeur peut l'appliquer seul.

Si l'une des trois manque, la fiche sera au mieux inutile, au pire nuisible. Quatre familles de motifs, quatre traitements différents :

La deuxième ligne est la plus difficile à accepter, parce qu'écrire une fiche est presque toujours plus rapide que corriger l'écran fautif. Documenter un contournement, c'est pourtant graver le défaut dans le marbre : la fiche devient une dette que vous maintiendrez pendant des années. Quand un motif remonte semaine après semaine parce qu'un bouton est mal nommé, la bonne réponse est de renommer le bouton.

À quoi ressemble une fiche qu'on lit jusqu'au bout ?

Une fiche utile donne la réponse dès la première phrase, puis déroule des étapes numérotées : tout le reste est du décor.

Six règles suffisent, et elles tiennent en une page :

• Un titre qui reprend la question du demandeur. « Comment réinitialiser mon mot de passe ? » se trouve dans une recherche, « Gestion des accès utilisateurs » ne se trouve pas.
• La réponse avant le contexte. Votre lecteur est déjà bloqué : il n'a pas besoin d'un rappel sur le fonctionnement général du module.
• Des étapes numérotées, une action par étape. Avec le libellé exact des boutons, tel qu'il apparaît à l'écran, y compris ses fautes de frappe s'il en a.
• Les conditions préalables annoncées au début. Rien n'agace plus que découvrir à l'étape 5 qu'il fallait un droit administrateur.
• Une porte de sortie explicite. Un lien pour ouvrir un ticket quand la procédure n'a pas fonctionné. Il rend service au lecteur, et chaque clic vous signale une fiche à revoir.
• Une date de dernière vérification, visible. Elle vaut mieux qu'une date de publication : le lecteur ne veut pas savoir quand vous avez écrit, il veut savoir si c'est encore vrai.

Reste le jargon, qui fait échouer plus de fiches que la mise en page. Vos noms de modules et vos abréviations maison n'existent pas dans la barre de recherche du demandeur : écrivez avec ses mots, quitte à mentionner le terme officiel entre parenthèses.

Placez la base sur le chemin du ticket, pas à côté

Une base que personne ne croise ne réduit rien : la fiche doit apparaître au moment précis où la demande se forme, c'est-à-dire pendant la saisie du ticket.

Trois points d'exposition font l'essentiel du travail. Le formulaire de demande, qui propose deux ou trois fiches dès que l'objet est saisi. La réponse de l'agent, qui colle le lien accompagné de deux lignes de résumé plutôt qu'un lien sec. Et l'écran concerné dans votre logiciel, quand la question naît toujours au même endroit du parcours.

Ce deuxième point a un effet secondaire précieux : il teste la fiche à chaque usage. Si vos agents rouvrent systématiquement la fiche pour la reformuler avant de l'envoyer, elle est incomplète ou fausse, et vous le savez sans enquête. Tout cela suppose un outil de ticketing capable de rattacher chaque demande à un motif et d'afficher un lien au bon moment. Si le vôtre ne sait faire ni l'un ni l'autre, c'est le premier chantier : nous décrivons le nôtre sur la page de notre plateforme de tickets multi-organisations.

Comment savoir si votre base de connaissances sert vraiment ?

Le seul indicateur qui tranche est le nombre de tickets sur un motif documenté, comparé avant et après la publication de la fiche.

Les pages vues, elles, ne prouvent rien : une fiche très consultée peut être une fiche qu'on relit trois fois sans rien y comprendre. Suivez plutôt trois signaux. Le volume par motif, mois par mois, sur les motifs documentés uniquement. Les tickets ouverts juste après la consultation d'une fiche, qui pointent les fiches ratées. Et les recherches internes sans résultat, qui constituent votre prochaine liste de sujets, écrite gratuitement par vos utilisateurs.

Un mois de baisse ne prouve rien non plus : le volume dépend aussi de vos mises en production et de votre saisonnalité. Comparez un motif documenté à un motif comparable qui ne l'est pas encore, sur la même période : c'est le seul moyen honnête d'attribuer la baisse à votre travail.

Le vrai risque : la base qui devient un cimetière

Une base mal tenue coûte plus cher qu'une absence de base, parce qu'une fiche fausse produit un ticket de plus, avec un client déjà agacé d'avoir suivi une procédure qui ne marchait pas.

Trois habitudes évitent le cimetière. Chaque fiche a un responsable nommé, pas une équipe en général. La revue se déclenche sur événement, mise en production, changement de tarif, refonte d'un écran, plutôt que sur un calendrier que personne ne tient. Et les fiches périmées se suppriment ou se fusionnent sans état d'âme, avec une redirection vers celle qui les remplace. Dix fiches justes valent mieux que cent fiches approximatives.

Par honnêteté : si votre support tient en quelques demandes par semaine, ne construisez pas de base de connaissances. Une page de questions fréquentes et deux corrections dans votre outil feront mieux, pour zéro coût de maintenance. Chez Cloudyva, à Montpellier, un tiers des cadrages conclut qu'un outil du marché suffit, et la même prudence vaut ici : avant de construire quoi que ce soit, prenez cinq minutes pour comparer un outil du marché et du sur-mesure.

Vous voulez savoir quels motifs documenter en premier chez vous ? Sortez l'export de vos tickets des trois derniers mois, puis décrivez-nous en quelques lignes votre support actuel : réponse sous 24 h, cadrage de 30 minutes offert, à Montpellier ou chez vous.