La connaissance est déjà là. Dans votre FAQ, bien sûr. Mais aussi dans des milliers de tickets résolus, de réponses validées par les agents et de cas particuliers accumulés au fil des années.
Le mauvais réflexe consiste à vouloir tout réécrire dans une base documentaire parfaite avant de lancer un projet d'IA. Puis à ajouter toujours plus de documents dès qu'une réponse est mauvaise.
L'IA générative propose une autre logique : exploiter la connaissance existante, à condition de savoir la retrouver. Car dans le service client, le nombre de documents est souvent un faux débat. Ce qui compte, c'est la qualité des sources remontées pour chaque demande.
Pendant longtemps, une base de connaissance service client désignait surtout un ensemble d'articles propres, structurés et régulièrement mis à jour.
Cette documentation reste indispensable. Elle porte les règles officielles, les procédures et les réponses que l'entreprise veut rendre accessibles. Mais elle ne contient pas toujours la totalité de l'expérience du support.
La connaissance vit aussi dans :
Cette matière est moins propre qu'une FAQ. Elle est aussi beaucoup plus proche des problèmes réellement rencontrés par les clients.
Le sujet n'est donc plus seulement : comment écrire davantage de documentation ?
Il devient : comment retrouver la bonne connaissance dans tout ce qui existe déjà ?
Le RAG, ou Retrieval-Augmented Generation, combine la recherche d'informations dans une source externe et la génération d'une réponse par un modèle de langage. Le principe a été formalisé dans un article de recherche publié en 2020.
Un modèle généraliste sait rédiger. Il ne connaît pas forcément votre politique de retour, les exceptions liées à un pays, le statut d'une commande ou la procédure réellement appliquée par vos équipes.
Le RAG lui apporte cette connaissance au moment où il en a besoin. Notre guide du RAG pour le support client détaille cette mécanique.
Dans sa version la plus simple, le parcours ressemble à ceci :
question client -> recherche de connaissance -> sources pertinentes -> génération de la réponse
L'Agentic RAG va plus loin : il peut reformuler la recherche, récupérer un contexte manquant, vérifier ce qu'il a trouvé et décider s'il doit continuer ou s'arrêter. Notre article sur les impacts concrets de l'Agentic RAG dans le service client explique cette évolution à travers des cas d'usage, des boucles de contrôle qualité et des diagrammes techniques.
Ici, la question est différente : quelle connaissance faut-il réellement fournir au système ?
Quand une réponse est mauvaise, ajouter des documents semble rassurant. On se dit que l'information finira bien par apparaître dans le lot.
Mais chaque document supplémentaire apporte potentiellement du signal et du bruit : doublons, versions anciennes, règles appliquées à une autre zone, réponses proches mais incompatibles avec le cas du client.
Chez Klark, nous comparons notamment des variantes qui présentent six ou huit documents au système afin de mesurer, cas par cas, l'effet du contexte supplémentaire sur le retrieval.
Selon la demande, le client et la structure de la connaissance, deux documents supplémentaires peuvent aider, ne rien changer ou diluer l'information décisive.
Le bon indicateur n'est donc pas le volume injecté. Il faut mesurer si la bonne source remonte assez haut, si elle couvre vraiment la question et si les autres documents renforcent ou brouillent la réponse.
Cette distinction change le diagnostic. Avant d'ajouter du contenu, il faut se demander :
Ajouter vingt pages de FAQ ne répare pas un filtre mal configuré.
Une même marque peut gérer plusieurs pays, produits, boutiques, canaux ou politiques commerciales. Deux documents peuvent être corrects tout en étant incompatibles parce qu'ils ne concernent pas le même contexte.
Le filtrage de la base de connaissance permet de réduire le corpus avant même le classement. Une demande française sur un produit précis ne devrait pas être arbitrée à partir d'une politique américaine ou d'une documentation destinée à une autre gamme.
Mais les filtres doivent eux-mêmes être testés.
Un filtre trop large laisse entrer du bruit. Un filtre trop strict peut exclure le seul document utile. La qualité d'un système ne se mesure donc pas seulement à ce qu'il retrouve, mais aussi à ce qu'il écarte.
Cette mécanique peut alimenter un copilote, une automatisation ou une solution d'IA intégrée au service client. Dans chaque cas, le périmètre de connaissance doit suivre le contexte réel du ticket.
Les tickets contiennent une quantité considérable de connaissance opérationnelle.
Ils montrent comment une politique est réellement appliquée, quelles formulations fonctionnent, quelles exceptions reviennent et quels cas posent problème aux agents.
Cela ne signifie pas qu'il faut injecter tout l'historique sans contrôle. Un ticket peut contenir :
Les conversations doivent donc être sélectionnées, contextualisées, nettoyées et évaluées. Le ticket est une source possible, pas une règle officielle par défaut.
Cette nuance est importante. Le gain ne vient pas d'un gigantesque copier-coller du helpdesk vers le modèle. Il vient de la capacité à extraire les bons exemples et à les confronter aux sources de référence.
Une équipe internationale connaît bien ce problème : une procédure évolue, puis il faut la réécrire dans plusieurs langues, la décliner par pays et vérifier que chaque copie reste à jour.
Cette duplication crée mécaniquement des divergences.
L'IA générative rend exploitable une connaissance trop volumineuse et dispersée pour être parcourue manuellement à chaque ticket.
Une équipe peut partir de sources de référence, leur associer le contexte géographique pertinent, puis adapter la réponse dans la langue du client sans recopier systématiquement chaque contenu.
Le multilingue ne supprime pas la gouvernance. Il évite simplement de confondre gouvernance et multiplication infinie des fichiers.
Une démonstration réussie sur trois questions ne prouve pas qu'un système est prêt pour le support réel.
Il faut construire un jeu de demandes représentatif : questions fréquentes, formulations ambiguës, produits différents, politiques locales, informations manquantes et cas où l'IA doit s'arrêter.
Pour chaque demande, l'évaluation doit séparer au moins quatre sujets :
Cette séparation évite de changer de modèle quand le problème vient du corpus, ou de réécrire la base de connaissance quand le problème vient du classement.
Elle permet aussi de tester plusieurs technologies sans dépendre d'un fournisseur unique. Klark est LLM-agnostique : nous regardons les nouveaux modèles et les nouvelles méthodes, puis nous testons ce qu'ils apportent réellement au service client.
La supervision humaine reste essentielle. Elle sert à valider les sources, détecter les erreurs récurrentes et décider où l'automatisation peut progresser. C'est aussi le principe détaillé dans notre article sur l'Agentic AI et la supervision humaine.
Une base de connaissance service client ne se résume plus à une bibliothèque d'articles parfaitement rangés.
La connaissance existe déjà dans les FAQ, les procédures, les notes internes et les milliers de tickets traités par les équipes. Le RAG permet de l'exploiter sans demander au modèle de tout connaître à l'avance.
Mais la course au nombre de documents mène vite à l'inflation. Une source bien choisie, correctement filtrée et placée au bon moment vaut mieux qu'un contexte rempli de documents proches, anciens ou contradictoires.
Votre connaissance est probablement déjà dans vos tickets. Le vrai travail consiste désormais à la retrouver avec suffisamment de précision pour qu'elle devienne utile.
Votre base de connaissance est probablement déjà plus riche que vous ne le pensez.
Klark aide les équipes support à retrouver la bonne source, dans le bon contexte, sans réécrire tout leur historique.
À propos de Klark
Klark est une plateforme d'IA générative qui aide les agents du service client à répondre plus vite, plus précisément, sans changer leurs outils ni leurs habitudes.
