Un client éditeur d’un site de documentation technique nous a demandé un chatbot capable de répondre aux questions des visiteurs sans recruter une équipe de support. Il n’avait ni budget ni envie de rédiger une base de connaissances séparée : ses 300 articles existants contenaient déjà les réponses, encore fallait-il les retrouver.
Voici la recette que nous avons suivie pour un premier chatbot fonctionnel en une journée de développement, sans infrastructure lourde ni base vectorielle dédiée.
Étape 1 : indexer les articles existants
Nous récupérons le contenu texte de chaque article via get_the_content(), nettoyé du balisage HTML avec wp_strip_all_tags(), puis découpé en blocs d’environ 500 mots. Chaque bloc est envoyé à l’API d’embeddings d’OpenAI (text-embedding-ada-002) qui renvoie un vecteur numérique représentant son sens.
foreach ( $chunks as $chunk ) {
$response = wp_remote_post( 'https://api.openai.com/v1/embeddings', array(
'headers' => array(
'Authorization' => 'Bearer ' . get_option( 'mon_plugin_openai_key' ),
'Content-Type' => 'application/json',
),
'body' => wp_json_encode( array(
'model' => 'text-embedding-ada-002',
'input' => $chunk,
) ),
'timeout' => 20,
) );
// stocker le vecteur avec l'ID de l'article et le texte du bloc
}
Les vecteurs, accompagnés de l’identifiant de l’article et du texte source, sont stockés dans une table personnalisée créée via dbDelta(). Pas besoin d’un moteur vectoriel externe pour 300 articles, une table MySQL classique suffit largement à ce volume.
Étape 2 : chercher les extraits pertinents à la question
Quand un visiteur pose une question, on calcule d’abord l’embedding de sa question avec le même modèle, puis on compare ce vecteur à tous les vecteurs stockés grâce à une similarité cosinus calculée en PHP.
- Calcul de la similarité entre le vecteur de la question et chaque bloc indexé
- Tri décroissant et sélection des trois à cinq blocs les plus proches
- Récupération du texte source de ces blocs pour construire le contexte
Sur 300 articles découpés en environ 1 200 blocs, cette boucle de comparaison reste rapide, de l’ordre de quelques dizaines de millisecondes en PHP, sans nécessiter d’extension vectorielle particulière.
Étape 3 : demander la réponse au LLM, avec les extraits comme seule source
Le troisième appel API envoie au modèle de complétion (GPT-3.5 Turbo) un prompt qui contient la question du visiteur et les extraits retrouvés, avec une consigne stricte : répondre uniquement à partir de ces extraits, et dire explicitement ne pas savoir si la réponse n’y figure pas.
$prompt = "Réponds uniquement à partir des extraits suivants. "
. "Si la réponse n'y figure pas, dis que tu ne sais pas.\n\n"
. "Extraits :\n" . $contexte . "\n\n"
. "Question : " . $question;
Cette contrainte est essentielle : sans elle, le modèle a tendance à compléter les trous avec des informations plausibles mais absentes du site, ce qui donnerait de fausses réponses à vos visiteurs.
Les limites à connaître avant de généraliser
Ce chatbot répond correctement aux questions dont la réponse existe littéralement, ou presque, dans un article. Il échoue en revanche sur les questions qui demandent de croiser plusieurs articles ou de raisonner sur des cas non couverts. Sur nos tests, environ 15 % des questions posées par de vrais visiteurs sortaient de ce périmètre, et le message « je ne sais pas » du chatbot, bien formulé, s’est révélé préférable à une improbable improvisation.
Un chatbot qui dit « je ne sais pas » à bon escient inspire plus confiance qu’un chatbot qui invente une réponse fluide et fausse.
En résumé
Trois appels API bien enchaînés, indexation, recherche par embeddings, puis génération contrainte, suffisent pour un premier chatbot FAQ exploitable sur un site de contenu existant, sans base de connaissances séparée à écrire ni infrastructure vectorielle dédiée. La qualité de la réponse dépend directement de la qualité du découpage des articles et de la rigueur du prompt final : mieux vaut un chatbot honnête sur ses limites qu’un chatbot qui bluffe.
