Un utilisateur veut résilier. Il tape « arrêtez de me prélever » dans la recherche de votre centre d’aide.
Votre meilleur article s’intitule Gérer votre abonnement. Il ne contient pas le mot « prélever ». Il ne contient pas le mot « arrêtez ». La recherche par mots-clés ne renvoie rien, et l’utilisateur ouvre un ticket de support que votre documentation aurait pu régler.
C’est l’échec classique des centres d’aide, et ce n’est pas un problème de contenu. L’article, vous l’avez écrit. La recherche n’a simplement pas su le trouver.
Deux vocabulaires qui ne se recoupent pas
Les articles d’aide sont écrits par des gens qui connaissent le produit. Ils emploient les termes du produit : abonnement, licence, espace de travail, droits. Les recherches sont tapées par des gens qui ne connaissent pas encore le produit. Ils emploient les leurs : formule, utilisateur, compte, accès.
La recherche par mots-clés a besoin que ces deux vocabulaires se recoupent. Souvent, ce n’est pas le cas, et l’écart est le plus grand justement pour ceux qui ont le plus besoin d’aide : les nouveaux utilisateurs.
La recherche sémantique comble l’écart
La recherche du centre d’aide de Kookee est sémantique. Les articles sont convertis en vecteurs, la requête aussi, et la correspondance se fait sur le sens plutôt que sur les caractères en commun :
const results = await kookee.help.search({ query: 'arrêtez de me prélever', limit: 5 });
results.forEach((result) => {
result.title; // 'Gérer votre abonnement'
result.matchedChunk; // le passage qui correspond à la requête
result.category; // { name, slug }
});En pratique, c’est matchedChunk que je trouve le plus utile. Vous récupérez non seulement l’article, mais aussi le passage qui répond à la requête : votre page de résultats peut donc afficher la réponse directement, au lieu d’une liste de liens bleus à parcourir.
Ensuite, supprimez carrément le champ de recherche
La recherche reste une interface où c’est l’utilisateur qui travaille. Il formule une requête, parcourt les résultats, ouvre un article, puis le parcourt encore pour trouver le paragraphe qui le concerne.
Le widget de chat saute ces étapes. Il répond en langage naturel, en s’appuyant sur vos articles d’aide publiés, et cite les sources qu’il a utilisées :
import { KookeeChatWidget } from '@kookee/react/chat';
import '@kookee/react/chat.css';
<KookeeChatWidget
clientOptions={{ apiKey: 'your-api-key' }}
title="Aide"
greeting="Bonjour ! Comment puis-je vous aider ?"
suggestions={['Comment démarrer ?', 'Quelles sont les formules tarifaires ?']}
onSourceClick={(source) => window.open(`/help/${source.slug}`, '_blank')}
/>C’est toute l’intégration. Le widget est une bulle flottante sur n’importe quelle page, il prend le thème light, dark ou auto, et il accepte une primaryColor pour ne pas ressembler au produit de quelqu’un d’autre greffé sur le vôtre.
Le point important ici, c’est la source des réponses. Le widget répond à partir de vos articles et renvoie vers eux. Quand il ne sait pas, c’est un trou dans votre documentation. Et onSourceClick, avec le nombre de vues de vos articles, vous montre les articles sur lesquels tout repose.
Écrivez pour la question, pas pour la fonctionnalité
Deux conséquences en découlent, et toutes deux portent sur votre façon d’écrire.
La recherche sémantique s’appuie sur le sens : un article qui commence par reformuler le problème de l’utilisateur avec ses mots à lui sera trouvé. Un article qui commence par « Cet article décrit l’interface de gestion des abonnements » ne le sera pas, aussi bon que soit le reste.
Et les chiffres vous disent quand vous vous êtes trompé. Un article très consulté qui continue de produire la même question au support n’est pas un article manquant. C’est un article raté : les gens le trouvent, et il ne les aide pas. C’est le signal le plus exploitable qu’un centre d’aide puisse vous donner.