Support client : construire une base de connaissances qui tient la charge

Quand un assistant de support répond mal, l'accusé désigné est toujours le modèle. Dans les faits, la base de connaissances IA qui l'alimente explique la quasi totalité des écarts de qualité. Un modèle moyen sur une base excellente donne de bonnes réponses. Un excellent modèle sur une documentation lacunaire produit des réponses fluides et fausses, ce qui est bien pire.

Ce constat est démoralisant pour une raison simple : réécrire une documentation de support est un travail long, peu gratifiant, et qui ne se délègue pas à un prestataire, parce qu'il exige de connaître les produits et les clients. Aucun outil ne le fera à votre place.

La bonne nouvelle, c'est que le travail est fini. Une base bien construite se maintient ensuite à raison de quelques heures par mois, et elle sert autant aux humains qu'à la machine. Cet article détaille le format d'article qui fonctionne, la granularité à viser, la gestion des versions, et la méthode pour repérer les trous à partir des questions restées sans réponse.

Pourquoi la base compte plus que le modèle

Un assistant de support fonctionne en deux temps : il cherche dans votre documentation les passages pertinents, puis il rédige une réponse à partir de ces passages. Le second temps est très bien maîtrisé par les modèles actuels. Le premier dépend entièrement de la façon dont votre contenu est découpé et écrit.

Trois défauts documentaires produisent l'essentiel des mauvaises réponses :

• Le contenu implicite. Un article qui dit « comme indiqué plus haut » ou « cette procédure » perd tout son sens une fois découpé en fragments. La machine ne lira pas le paragraphe précédent.
• Les contradictions non arbitrées. Deux articles disent l'inverse parce que l'un date d'avant un changement de politique. La recherche remontera les deux, et la réponse sera un compromis inventé.
• Les procédures sans conditions. Un article explique comment faire, sans préciser dans quels cas cela s'applique. L'assistant l'appliquera à des situations où c'est faux.

Le mécanisme technique sous jacent, découpage et recherche par similarité, est décrit dans notre article sur la recherche augmentée sur des documents d'entreprise. Retenez ici la conséquence : chaque fragment doit se suffire à lui même.

Le format d'article qui alimente bien une base de connaissances IA

Un article de base de connaissances exploitable par un assistant tient en un gabarit stable. Le même pour tous, sans exception, ce qui facilite aussi la rédaction.

1. Un titre qui reprend la question du client, pas le vocabulaire interne. « Je n'arrive pas à me connecter après un changement de mot de passe » vaut mieux que « Procédure de réinitialisation SSO ».
2. Une phrase de contexte d'application. À qui cela s'adresse, dans quelle situation, sur quelle version ou quelle offre. C'est la ligne la plus importante du document.
3. La réponse courte en deux ou trois phrases, immédiatement après. Beaucoup de demandes s'arrêtent là.
4. La procédure détaillée, en étapes numérotées, une action par étape.
5. Les cas particuliers et ce qui ne marche pas, explicitement nommés.
6. Le point d'escalade. Que faire si cela ne fonctionne toujours pas, et vers qui.

Deux règles d'écriture complètent le gabarit. D'abord, pas de renvoi interne implicite : chaque article se lit seul, quitte à répéter deux phrases. Ensuite, le vocabulaire du client apparaît au moins une fois, même s'il est techniquement impropre : si vos utilisateurs disent « code d'accès » et que votre documentation dit « jeton d'authentification », la recherche ne trouvera rien.

La bonne granularité

Un article traite une question, une seule. L'erreur la plus répandue consiste à produire de gros articles fourre tout couvrant tout un domaine fonctionnel, parce que c'est plus confortable à maintenir. Pour la recherche, c'est désastreux : le fragment retenu contient alors autant d'information non pertinente que de réponse.

Un repère utile : entre 200 et 800 mots par article. En dessous, l'article manque de contexte pour être trouvé. Au dessus, il traite probablement plusieurs questions et gagne à être scindé. Une base de 150 articles courts vaut mieux qu'une base de 40 articles longs, à contenu égal.

Versions et cycle de vie : le point qui casse tout

La documentation de support d'une entreprise en activité est fausse en permanence sur une partie de son contenu. C'est normal. Ce qui ne l'est pas, c'est que l'assistant traite avec la même confiance un article revu la semaine dernière et un article oublié depuis trois ans.

Quatre métadonnées obligatoires sur chaque article règlent la question :

La distinction entre date de modification et date de revue mérite qu'on s'y arrête. Une correction de faute de frappe met à jour la date de modification et ne prouve rien. La date de revue signifie qu'une personne compétente a relu et confirmé que le contenu est toujours exact. C'est elle qu'il faut afficher et surveiller.

Fixez ensuite une règle de péremption par catégorie : six mois pour les articles liés aux tarifs et aux procédures commerciales, douze mois pour les procédures techniques stables, trois mois pour tout ce qui touche à une fonctionnalité en évolution. Un article dépassé passe automatiquement en statut « en revue » et sort de la base servie à l'assistant. Cette sortie automatique est plus efficace que n'importe quel rappel : elle rend l'obsolescence visible immédiatement, côté client comme côté équipe.

Détecter les trous à partir des questions sans réponse

C'est le mécanisme qui transforme une base statique en base vivante, et il coûte très peu à mettre en place. Chaque interaction où l'assistant n'a rien trouvé, ou a produit une réponse jugée insuffisante, est une indication précise de ce qui manque.

La boucle, en pratique :

1. Journalisez les questions non résolues : aucune source pertinente trouvée, retour négatif de l'utilisateur, ou escalade vers un humain dans la minute qui suit la réponse.
2. Regroupez les par thème, une fois par semaine. Le regroupement automatique par proximité sémantique fait gagner beaucoup de temps ici.
3. Classez chaque groupe. Trois causes possibles : le contenu n'existe pas, il existe mais n'est pas trouvable, ou la question est hors périmètre et il faut le dire.
4. Traitez par volume décroissant. Cinq articles écrits sur les cinq thèmes les plus fréquents font plus de bien que cinquante articles écrits au hasard.
5. Vérifiez que le trou est bouché en rejouant les questions du groupe sur la nouvelle base.

La distinction entre « n'existe pas » et « n'est pas trouvable » est essentielle. Dans les bases que nous avons vues, la seconde cause représente souvent la moitié des échecs : l'information est là, mais elle est enfouie dans un article dont le titre parle un autre langage que le client. Le correctif est alors de reformuler un titre, pas d'écrire une page.

La question ouverte des questions fréquentes

Structurer une page de questions fréquentes avec un balisage standard aide à la fois les moteurs de recherche et vos propres outils d'extraction. Mais ne transformez pas votre base en page unique de questions fréquentes : le format sert la lecture rapide, pas la procédure détaillée. Gardez les deux, avec la page de questions fréquentes en vitrine et les articles complets derrière.

Combien ça coûte, et par où commencer

Ordres de grandeur constatés sur une base de départ de 80 à 150 articles : comptez 15 à 25 jours de travail pour la reprise initiale, puis 2 à 4 heures par semaine pour le maintien, réparties entre une personne qui pilote et les experts métier qui valident.

La séquence qui fonctionne le mieux :

• Semaine 1 : extraire les 40 motifs de contact les plus fréquents des six derniers mois. C'est votre plan de rédaction, et il est fondé sur des faits.
• Semaines 2 à 5 : écrire ou réécrire les 40 articles correspondants au gabarit, en supprimant sans état d'âme tout ce qui les contredit.
• Semaine 6 : brancher l'assistant sur cette base réduite, en interne uniquement, avec l'équipe support comme premier utilisateur.
• À partir de la semaine 7 : lancer la boucle de détection des trous, et n'ouvrir au client qu'une fois le taux de non réponse stabilisé sous 15 %.

Le passage par un usage interne d'abord est fortement recommandé : les agents repèrent les erreurs bien plus vite que les clients, et sans conséquence commerciale. Le même principe vaut pour les assistants documentaires internes, comme nous l'expliquons dans construire un assistant interne sur sa documentation, et il s'articule avec l'automatisation du premier niveau décrite dans automatiser son service client de premier niveau.

Une base de connaissances IA qui tient la charge n'est pas une base exhaustive. C'est une base où chaque article se suffit, où l'obsolète sort tout seul, et où les questions sans réponse alimentent la liste de rédaction de la semaine suivante. Ces trois propriétés valent mieux que trois cents articles que plus personne ne relit.