Base de connaissances du support : des fiches utilisables

Le support répond à une question déjà traitée, mais personne ne retrouve la procédure. Elle existe peut-être dans un ticket clos, une conversation ou un document nommé avec le vocabulaire de son auteur. Demander à l’équipe de documenter davantage ne règle pas ce problème : il faut d’abord comprendre pourquoi la réponse disponible ne sert pas.

Je partirais d’une demande réelle et du chemin suivi pour y répondre. Où cherche le technicien ? Quels mots emploie-t-il ? À quel moment appelle-t-il un collègue ? Ce parcours donne un cahier des charges plus utile qu’une liste de fonctions de gestion documentaire.

Choisir un périmètre à partir des demandes traitées

Je commencerais par une famille de demandes que le support sait résoudre, mais pour laquelle il reconstruit régulièrement la réponse. Le périmètre doit être assez précis pour reconnaître une situation commune : retrouver un document dans une application, comprendre un rejet d’import ou préparer un accès distant, par exemple.

Relire les échanges permet de distinguer ce qui manque. Parfois, la solution est connue mais introuvable. Parfois, elle dépend d’une condition jamais écrite. Parfois encore, les techniciens donnent des réponses différentes parce que le fonctionnement attendu n’a pas été décidé. Ce dernier cas demande un arbitrage avant une fiche.

Je ne commencerais pas par reprendre tout le stock documentaire. Je conserverais les références existantes et sélectionnerais les contenus nécessaires au périmètre choisi. Une ancienne procédure peut rester utile ailleurs ; elle ne mérite pas automatiquement une place dans le premier ensemble proposé aux utilisateurs.

Le chantier doit avoir un résultat observable : un collègue retrouve la réponse et sait si elle s’applique. Je n’annoncerais aucun objectif de baisse des tickets avant d’avoir observé cet usage. Pour commencer, rendre une réponse réutilisable est déjà un engagement concret.

Décrire les conditions d’application dans chaque fiche

Une fiche doit annoncer le problème auquel elle répond, le contexte nécessaire et le résultat attendu. Le guide KCS sur les règles de contenu recommande notamment de définir la structure des articles, leurs métadonnées et leur public. Je traduirais ce principe en un modèle court, adapté aux demandes retenues.

Ce tableau illustre un modèle, pas une procédure applicable à votre application. Je demanderais au rédacteur de remplacer chaque formulation générique par les conditions effectivement vérifiées. Si le comportement varie selon une version, cette version doit être indiquée.

Les captures complètent le texte sans porter seules l’explication. Je retirerais les informations personnelles et les données de production inutiles. Une fiche destinée à un salarié ne doit pas lui proposer une action d’administration. Elle doit expliquer jusqu’où aller et quoi transmettre au support si le résultat attendu n’apparaît pas.

Vérifier la recherche dans les conditions du lecteur

Je ferais rechercher la fiche par quelqu’un qui ne l’a pas écrite, depuis son compte habituel. Le test commence par la formulation du besoin, sans donner le titre du document. S’il faut connaître le nom technique d’un composant pour trouver la réponse, le contenu reste difficilement accessible à son public.

Je noterais les mots employés et les résultats affichés. Un titre corrigé, une expression métier ajoutée ou un doublon retiré peut résoudre le défaut. Une recherche infructueuse ne justifie pas, à elle seule, l’achat d’un nouveau moteur. Il faut distinguer l’absence de contenu, un problème de vocabulaire et une limite de l’outil.

Le test doit aussi vérifier les droits. Une page trouvable par le support peut être invisible au salarié. À l’inverse, une recherche ne doit pas exposer un titre confidentiel à un lecteur non autorisé. Je contrôlerais les pièces jointes et les liens directs avec le même soin que la page.

Je conserverais une adresse de référence par réponse. Les copies envoyées en pièce jointe se détachent de leurs corrections. Le support peut donner une explication adaptée dans le ticket, mais doit pouvoir renvoyer vers le contenu maintenu, accessible au destinataire.

Intégrer la correction au traitement des demandes

Une base se dégrade si les erreurs repérées repartent dans une conversation privée. Le principe signaler ou corriger de KCS propose de corriger lorsque la compétence et les droits le permettent, ou de signaler le défaut pour qu’il soit traité. Je retiendrais cette règle dans le fonctionnement du support.

Concrètement, le technicien doit pouvoir joindre à la fiche le symptôme rencontré et ce qui ne fonctionne plus. Le signalement rejoint une file attribuée à un référent du domaine, avec un relais. Un bouton de retour sans destinataire ni suivi ne fait qu’ajouter une boîte oubliée.

Je distinguerais une précision de vocabulaire d’une modification susceptible de changer le résultat d’une opération. La première peut être rapide ; la seconde exige une vérification adaptée avant diffusion. Si une instruction risque de provoquer une mauvaise manipulation, je la retirerais de l’usage en attendant sa correction, tout en conservant l’historique.

Ce travail doit entrer dans la charge du support. Demander une mise à jour tout en évaluant seulement la vitesse de clôture crée une contradiction. L’organisation des interruptions dans une petite DSI aide à réserver cette capacité, mais ne dispense pas de retirer d’autres tâches quand le planning est plein.

Mesurer les recherches et les résolutions obtenues

Je regarderais les recherches sans résultat, les fiches signalées comme inapplicables et les demandes où une réponse existante a dû être réexpliquée. Ces éléments servent à choisir la prochaine correction. Leur interprétation exige de regarder les cas concernés : un document très consulté peut être utile ou incompréhensible.

Le Consortium for Service Innovation présente sa liste de contrôle des contenus comme un outil d’apprentissage, et non comme un score à optimiser. C’est aussi la limite que je fixerais au tableau de bord : il doit aider à discuter du travail, sans transformer les contributeurs en producteurs de fiches.

Pour le libre-service, je proposerais un retour simple sur le résultat obtenu et un accès visible au support. Un utilisateur qui n’ouvre pas de ticket a peut-être résolu son problème ; il a peut-être aussi renoncé. Je ne convertirais donc pas les consultations en tickets évités.

Une fiche vaut par la réponse qu’un lecteur peut en tirer, pas par sa présence dans le catalogue.

Je compléterais les indicateurs par l’observation de recherches réelles avec des lecteurs volontaires. Cela permet de comprendre un obstacle que les compteurs ne montrent pas : vocabulaire inconnu, étape ambiguë ou absence de solution correspondant au contexte.

Lancer le premier périmètre et organiser son entretien

Pour démarrer la semaine prochaine, je choisirais une famille de demandes avec l’équipe, puis je ferais transformer une réponse déjà vérifiée en fiche. Un collègue testerait sa recherche et son application. Les défauts constatés serviraient à ajuster le modèle avant de produire d’autres contenus.

Je vérifierais ensuite que l’outil disponible permet de consulter l’historique, de limiter les lecteurs et de suivre les signalements. Une fonction absente doit devenir un besoin précis, assorti d’un exemple bloquant. Changer d’outil avant cette vérification risque de déplacer les mêmes documents sans améliorer leur utilisation.

À chaque changement de l’application concernée, le responsable de l’intervention doit identifier les fiches affectées. Pour les contenus peu consultés mais importants, je prévoirais une revue ciblée : l’absence de retour ne prouve pas leur validité. Une fiche devenue inutile sort des résultats courants, avec une indication de remplacement lorsqu’il existe.

Enfin, je fixerais un rendez-vous de bilan du périmètre initial. L’équipe y apporterait les recherches échouées, les corrections en attente et les réponses effectivement réutilisées. L’extension à d’autres sujets dépendrait de cette capacité d’entretien. Si personne ne peut traiter les retours, je limiterais le catalogue jusqu’à ce que cette responsabilité soit assurée.