Base de connaissances d’un chatbot IA : quels contenus y intégrer et comment les garder à jour

Un vendredi soir, une cliente demande si l’entreprise est ouverte le samedi. Dans l’équipe, il y a trois versions : le site web indique « du lundi au vendredi », une affichette sur la porte promet « le samedi sur rendez-vous », et la collègue de l’accueil sait qu’en été, c’est de toute façon fermé le samedi. Toutes trois estiment que leur réponse est la bonne. Ce scénario est inventé ; le schéma, lui, ne l’est pas.

C’est précisément là qu’intervient un chatbot IA, et c’est précisément là que se décide s’il aide ou s’il nuit. Un modèle de langage ne connaît pas votre entreprise. Il connaît la langue, des liens généraux et des formulations plausibles. Si on ne lui donne rien d’autre, il répond avec ce qui vaut habituellement dans de tels cas. Cela semble convaincant et peut pourtant être faux.

La base de connaissances n’est donc pas une fonction annexe, mais le fondement. Elle définit ce que le bot peut dire au nom de votre entreprise. Qui la néglige obtient une machine polie au savoir inventé. Qui la construit avec soin obtient un assistant qui ne transmet que ce que vous avez expressément validé et qui indique l’endroit où cela figure.

Ce texte s’adresse aux entreprises confrontées à cette décision précise : un assistant doit-il renseigner au nom de la maison et, si oui, sur quelle base ? Il explique comment nous construirions une base de connaissances, quels arbitrages se présentent et où se situent les limites. Les exemples sont construits pour que rien ne ressemble à un projet réel qui n’aurait pas existé.

Le problème central s’appelle l’hallucination : le modèle produit un texte qui correspond à la question sans qu’une source ne l’étaye. Le mécanisme est banal. Un modèle de langage calcule quel mot est susceptible de suivre. Probable n’est pas synonyme de vrai. À « Combien coûte une première consultation ? », il existe d’innombrables réponses plausibles, et le modèle en choisit une lorsqu’il ne dispose d’aucune donnée concrète.

S’y ajoute le problème du vieillissement. Même une base de connaissances exacte au départ se périme. Les prix changent, un collaborateur part, une offre expire, le cabinet ferme entre Noël et le Nouvel An. Un bot qui restitue la situation du printemps paraît aussi sûr de lui en automne que le premier jour. Le client ne peut pas voir la différence, et l’entreprise ne s’en aperçoit souvent que lorsque quelqu’un se retrouve devant une porte close.

Un troisième type d’erreur concerne les engagements. Lorsque quelqu’un demande « Puis-je annuler chez vous ? », il ne s’agit pas d’une information, mais d’une déclaration engageante. Si le bot répond librement, il formule peut-être une règle qui n’existe pas. C’est pourquoi une base de connaissances a besoin non seulement de contenus, mais aussi de limites : à quels sujets le bot répond-il, et pour lesquels transfère-t-il à un humain ?

Avant de construire quoi que ce soit sur le plan technique, un état des lieux des questions que les clients posent réellement s’impose. Les meilleures sources sont la boîte de réception, les notes prises au téléphone, les recherches sur le site web et la question de savoir à quoi l’équipe répond pour la cinquième fois en une semaine. De ces questions découle ce que la base de connaissances doit porter. Toutes les informations qui existent dans l’entreprise n’y ont pas leur place.

Nous classerions les contenus selon deux critères : à quelle fréquence les demande-t-on, et combien coûte une mauvaise réponse ? Les horaires d’ouverture sont souvent demandés, et une erreur agace, mais cause en général peu de dégâts. Les fourchettes de prix sont fréquemment demandées, et une erreur crée des attentes qu’il faudra corriger ensuite. Les détails contractuels sont demandés plus rarement, mais une erreur peut avoir de lourdes conséquences. On en déduit le degré de rigueur de la validation.

Une contre-épreuve est tout aussi instructive : à quoi le bot ne doit-il expressément pas répondre ? Aux questions juridiques ou de santé individuelles, aux prix fermes pour des cas particuliers, aux renseignements sur d’autres clients. Cette limite fait partie de la conception et doit être consignée par écrit avant que la première ligne de contenu ne soit saisie. Elle décidera plus tard si le bot transfère proprement dans les moments critiques.

L’état des lieux comprend aussi un regard sur la forme des sources. Une liste de prix sous forme d’image numérisée, le bot ne peut pas la lire ; un tableau aux cellules fusionnées est facilement déchiqueté à l’import ; et la photo de l’affichette ne sert que d’aide-mémoire. Ces sources sont d’abord converties en texte simple, et c’est précisément alors que ressortent des incohérences que personne n’avait remarquées.

Il existe fondamentalement trois façons de donner à un modèle les connaissances d’une entreprise. La première consiste à tout écrire dans la consigne placée devant chaque requête. Cela fonctionne avec une poignée de paragraphes et échoue dès que le fonds grandit : la consigne devient confuse, coûteuse à chaque requête, et le modèle ne pondère pas de façon fiable les textes longs. Pour une entreprise disposant de dix pages de connaissances, cela peut suffire ; on ne devrait pas bâtir davantage dessus.

La deuxième voie consiste à réentraîner le modèle. Cela paraît rigoureux, mais s’accorde mal avec les connaissances d’une entreprise. Ce qui a été appris se corrige difficilement lorsqu’un prix change, et l’on ne peut pas prouver d’où provient une affirmation. Le réentraînement convient mieux au ton et au format qu’à des faits qui évoluent en permanence. Pour les horaires d’ouverture, c’est le mauvais levier.

La troisième voie s’appelle la recherche documentaire (retrieval), en termes techniques Retrieval-Augmented Generation. À chaque question, le bot cherche d’abord dans vos propres contenus, transmet les passages trouvés au modèle et le laisse répondre uniquement à partir de ceux-ci. Si un prix change, vous modifiez un document, et la réponse suivante est juste. De plus, chaque affirmation peut être rattachée à un passage précis. C’est notre choix, car elle réunit actualité, traçabilité et maîtrise.

La recherche documentaire n’est pas une panacée. Si la recherche trouve le mauvais passage, le modèle répond de manière fiable à partir du mauvais passage. La qualité se joue donc en deux moitiés : dans la recherche et dans la consigne de ne répondre qu’à partir des passages trouvés. Les deux moitiés doivent être testées, et ce n’est pas une tâche ponctuelle.

Une base de connaissances n’est pas un fourre-tout. Qui y charge simplement tous les PDF, brochures et textes du site web obtient des passages contradictoires et un bot qui cite tantôt l’ancienne, tantôt la nouvelle liste de prix. Mieux vaut un fonds réduit, construit délibérément : une page par sujet, courte, sans ambiguïté, avec une date et une personne responsable. Mieux vaut quarante entrées entretenues que quatre cents peu claires.

Le style rédactionnel est plus important qu’on ne le croit. La recherche fonctionne par proximité de sens ; les entrées formulées comme les clients posent leurs questions sont donc utiles. Une entrée intitulée « Annulation de rendez-vous » dont la première phrase est « Les rendez-vous peuvent être annulés gratuitement jusqu’à 24 heures à l’avance » est mieux trouvée qu’un paragraphe des CGV qui dit la même chose en langage juridique. Les extraits des CGV sont conservés comme preuve, la version compréhensible figure à côté.

Chaque entrée porte des métadonnées : sujet, validité, date, interlocuteur, visibilité. La mention « valable jusqu’au » permet de masquer automatiquement le saisonnier. La visibilité sépare ce que le bot peut dire publiquement des notes internes destinées à l’équipe. Et le prix est indiqué sous forme de fourchette assortie de conditions, non comme un chiffre sans contexte, afin que « à partir de » ne devienne pas par inadvertance « exactement ».

Enfin, ce que le bot ne sait pas doit figurer dans la base de connaissances. Une entrée « Offres de prix individuelles » avec le contenu « Le bot ne donne pas de renseignement à ce sujet, mais met en relation avec l’équipe » vaut mieux que le silence. Elle rend la limite repérable et fait en sorte que, pour des questions voisines, la bonne réaction soit choisie.

Nous résolvons les contradictions avant la saisie, non après. Si le site web indique d’autres horaires que la liste de prix, une personne décide quelle version fait foi, et l’autre est corrigée. Un bot qui connaît deux vérités restitue au hasard l’une ou l’autre. Ce rapprochement est inconfortable, mais révèle souvent des erreurs qui figurent aussi sur le site web depuis des mois sans être remarquées.

Techniquement, chaque requête traverse quatre étapes. D’abord, les contenus sont préparés : les textes sont découpés en sections de quelques phrases, et chaque section est traduite en une suite de nombres qui représente son sens. Cette traduction, appelée embedding, permet de mesurer la similarité. Deux phrases aux mots différents mais au même sens sont très proches, par exemple « Quand êtes-vous ouverts ? » et « Horaires d’ouverture ».

Lorsqu’une question arrive, elle est traduite de la même manière, et la recherche renvoie les sections les plus proches. En pratique, nous combinons la recherche par le sens avec une recherche classique par mots-clés, car elle est plus fiable pour les noms propres, les numéros d’article et les termes techniques. Les meilleurs résultats sont classés, et seuls ceux qui dépassent une similarité minimale sont transmis. Ce seuil est le principal réglage du comportement en cas d’incertitude.

À la troisième étape, le modèle de langage reçoit la question, les sections trouvées et une consigne : réponds uniquement sur la base de ces sections, cite la source, et si les sections ne répondent pas à la question, dis-le. À la quatrième étape, un contrôle vérifie si la réponse est étayée par les sections et bloque les affirmations comportant des prix ou des engagements qui n’y figurent pas. Cette étape de contrôle coûte un peu de temps et épargne bien des ennuis.

La qualité la plus difficile d’un chatbot n’est pas le savoir, mais la retenue. Les gens pardonnent bien plus volontiers un aveu honnête que le bot ne sait pas qu’une réponse fausse dont ils devront ensuite assumer les conséquences. Pourtant, les modèles de langage tendent à paraître serviables. Ce comportement doit être réorienté de façon ciblée : par la consigne, par le seuil de la recherche et par des exemples de bonne ignorance.

Une réponse d’ignorance utilisable comporte trois parties : elle dit clairement que le bot n’a rien de fiable à ce sujet. Elle propose l’étape suivante, par exemple une demande à l’équipe, un rappel ou la page de contact. Et elle emporte la question, afin que l’équipe sache de quoi il s’agissait. Cette troisième partie transforme la lacune en indication pour la maintenance : les questions sans résultat sont la liste la plus honnête de ce qui manque dans la base de connaissances.

Les cas limites sont délicats, lorsque la recherche trouve quelque chose qui ne correspond qu’à moitié. La question est « Y a-t-il une remise pour les associations ? », le passage trouvé parle d’une remise sur quantité. Ici, le bot ne doit pas extrapoler. Nous résolvons cela en faisant distinguer à la consigne entre « répondu », « partiellement répondu » et « non répondu », et en faisant nommer, au niveau intermédiaire, ce qui a été trouvé sans combler la lacune.

L’ignorance inclut aussi la conscience de son propre rôle. Si quelqu’un demande un engagement, un diagnostic ou une question juridique, le bot ne doit pas deviner, mais nommer les personnes compétentes. Ce n’est pas une faiblesse, mais la raison pour laquelle les entreprises peuvent offrir à un tel assistant une fenêtre sur leur site web.

Une bonne base de connaissances rend le bot traçable, non infaillible. L’exigence réaliste est que la grande majorité des questions courantes reçoive une réponse correcte à partir des contenus validés, que les réponses citent leur source et que le bot transfère en cas de lacune. Un chiffre à ce sujet ne peut être donné sérieusement qu’après une phase de test avec de vraies questions, ni avant ni de façon générale.

L’utilité se mesure à des indicateurs proches de la cause. Il s’agit notamment de la part des questions ayant reçu une réponse avec source, de la part des transferts dus à l’absence de résultats, des contrôles par échantillonnage où une personne vérifie les réponses par rapport à la source, et des retours des utilisateurs par pouce. Viennent seulement ensuite des indicateurs comme moins de demandes répétées dans la boîte mail ou des délais de traitement plus courts, qui dépendent de nombreux autres facteurs.

Un exemple d’interprétation : si le nombre de transferts dus à l’absence de résultats augmente durant les premières semaines, ce n’est pas un recul ; le bot montre où des contenus manquent. S’il baisse ensuite sans que les échantillons se dégradent, la couverture progresse. S’il baisse alors que les échantillons se dégradent, le bot répond probablement trop largement, et le seuil doit devenir plus strict.

Il faut tout aussi clairement dire ce qui ne peut pas être promis : aucune base de connaissances ne garantit des réponses sans erreur, en particulier pour des questions ambiguës ou des sources contradictoires. Un allègement précis pour l’équipe ne peut pas non plus être chiffré à l’avance. Il dépend du nombre de demandes que votre entreprise reçoit réellement, de leur degré de standardisation et de la constance de la maintenance.

La raison la plus fréquente pour laquelle les chatbots déçoivent après quelques mois n’est pas technique, mais l’absence de responsable. Le déploiement était un projet, la maintenance n’appartient à personne. C’est pourquoi nous définissons dès le départ qui est responsable de quel domaine : les prix à la direction, les horaires d’ouverture à l’accueil, les descriptions de prestations chez le professionnel. Chaque entrée porte un nom et une date de contrôle.

Le rythme comporte trois niveaux. Par événement, on modifie immédiatement lorsque quelque chose change : nouvelle liste de prix, fermeture annuelle, jour férié. Régulièrement, par exemple chaque mois, quelqu’un examine la liste des questions restées sans réponse et des retours négatifs et complète les entrées. Deux fois par an, l’équipe passe en revue l’ensemble de la base de connaissances et supprime ce qui ne s’applique plus. Les dates d’expiration aident : les entrées dont la validité est échue sortent automatiquement des réponses.

Un moyen simple de modifier est important. Si l’adaptation d’une entrée exige une concertation avec l’agence, elle est repoussée. Nous construisons donc une interface dans laquelle des personnes autorisées modifient et valident les entrées, et nous conservons l’historique. À chaque modification, un petit jeu de questions de test est exécuté, afin qu’une nouvelle formulation ne déplace pas à son insu les réponses sur d’autres sujets.

La base de connaissances devient ainsi un document vivant, utile au-delà du seul bot. De nombreuses entreprises constatent qu’elles consignent pour la première fois par écrit ce qui s’applique en cas d’annulation, d’accès ou de paiement. Cela aide aussi les nouveaux collaborateurs et le site web. Cet effet secondaire est réel, mais ne remplace pas l’effort de maintenance, qui demeure.

Un chatbot IA est rentable pour les entreprises qui répondent souvent à des questions similaires et dont les réponses peuvent se formuler en affirmations claires. Sa qualité dépend de la base de connaissances : de quelques entrées bien entretenues, d’une recherche qui trouve de manière fiable, de la source indiquée sous chaque réponse et d’un bot qui reconnaît ses lacunes. Le modèle qui se trouve derrière est interchangeable ; le soin apporté en amont, non.

L’étape suivante est modeste et n’exige pas encore de bot. Notez les vingt questions auxquelles votre équipe a répondu le plus souvent ces dernières semaines et vérifiez si les réponses se trouvent à un seul endroit, à jour. Si cet endroit n’existe pas, c’est là le véritable chantier, et il vaut la peine indépendamment de tout chatbot. Nous regardons volontiers avec vous ce qui existe déjà.

L’honnêteté commande aussi de le dire : pour de très petites entreprises avec peu de questions stables, une page FAQ bien conçue suffit. Le chatbot tire son avantage du fait que les questions sont formulées de multiples façons, que des réponses sont attendues à toute heure et que quelqu’un assure la maintenance. Si ce dernier point manque, mieux vaut reporter le lancement.

Celui qui se lance devrait commencer petit : avec les cinq à dix sujets les plus importants, une phase de test accompagnée et la volonté d’améliorer à partir de vraies questions. La base de connaissances grandit alors avec les besoins, au lieu de prétendre à l’exhaustivité d’emblée. C’est plus lent qu’un gros import, mais les réponses restent vérifiables et l’équipe garde la vue d’ensemble sur ce que le bot dit au nom de l’entreprise.