# Construire un chatbot de support IA pour WordPress sans base de connaissances fantôme

> La plupart des chatbots de support IA échouent non pas sur la génération de texte, mais sur la fraîcheur de leur base de connaissances. Voici une architecture qui évite ce piège.

- Auteur : Clément Hadrot
- Publié le : 2024-08-13
- Mis à jour le : 2024-08-13
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/construire-chatbot-support-ia-wordpress/

## L’essentiel

- Un chatbot sans contexte fiable invente des réponses avec assurance
- La génération augmentée par récupération limite ce risque
- La synchronisation du contenu WordPress doit être automatique, pas manuelle

Les premiers chatbots de support IA déployés sur WordPress en 2023 souffraient souvent d'un même défaut : livrés à eux-mêmes, sans accès au contenu réel du site, ils répondaient à partir des seules connaissances générales du modèle sous-jacent, avec un risque élevé d'inventer une politique de retour, un tarif ou une procédure qui n'existait pas. La technique qui a permis de fiabiliser ces assistants s'appelle la génération augmentée par récupération, plus connue sous son acronyme anglais RAG (Retrieval-Augmented Generation) : avant de répondre, le modèle reçoit en contexte les passages du site les plus pertinents pour la question posée.

Cet article détaille l'architecture d'un chatbot de support basé sur cette approche, directement branché sur le contenu WordPress, avec une attention particulière portée à la fraîcheur de la base de connaissances utilisée.

## Le principe du RAG appliqué à WordPress

Plutôt que de laisser le modèle répondre uniquement à partir de son entraînement général, l'architecture RAG ajoute une étape intermédiaire : la question du visiteur est d'abord utilisée pour rechercher, dans une base indexée du contenu WordPress (pages, FAQ, articles), les passages les plus proches sémantiquement. Ces passages sont ensuite injectés dans le prompt envoyé au modèle, avec une consigne explicite de répondre uniquement à partir des informations fournies. Cette contrainte réduit fortement, sans l'éliminer totalement, le risque d'invention de faits absents du contenu réel du site.

## Les trois briques de l'architecture

Concrètement, un chatbot RAG branché sur WordPress repose sur trois composants distincts :

- Un index vectoriel du contenu du site, construit via des embeddings, comme décrit dans l'approche de recherche sémantique
- Un point de terminaison REST WordPress qui reçoit la question, interroge l'index, puis appelle l'API du modèle avec le contexte récupéré
- Une interface de chat côté visiteur, généralement un widget JavaScript chargé de façon différée pour ne pas pénaliser les performances

> L'essentiel à retenir : Un chatbot sans contexte fiable invente des réponses avec assurance ; La génération augmentée par récupération limite ce risque ; La synchronisation du contenu WordPress doit être automatique, pas manuelle

Le point de terminaison REST joue un rôle charnière : il assemble le prompt final envoyé au modèle, en combinant l'historique de la conversation, les passages récupérés et une consigne système qui fixe les limites de ce que le chatbot doit et ne doit pas affirmer.

## Garder la base de connaissances à jour

Le piège le plus fréquent sur ce type de projet n'est pas technique, il est organisationnel : une base de connaissances constituée une fois lors du lancement, puis jamais resynchronisée, finit par contenir des informations obsolètes que le chatbot continue à restituer avec la même assurance qu'un fait à jour. Un changement de tarif publié sur une page produit, sans réindexation, laisse le chatbot répondre avec l'ancien prix pendant des semaines.

La parade consiste à automatiser entièrement la synchronisation, via le hook `save_post`, complété d'une tâche planifiée quotidienne qui vérifie les contenus modifiés récemment et régénère leur embedding correspondant :

```
add_action( 'save_post', function ( $post_id ) {
    if ( wp_is_post_revision( $post_id ) || 'publish' !== get_post_status( $post_id ) ) {
        return;
    }
    wp_schedule_single_event( time() + 60, 'mon_extension_reindexer_contenu', array( $post_id ) );
} );
```

Le délai de soixante secondes évite de réindexer un contenu encore en cours de rédaction, tout en garantissant une prise en compte rapide après publication effective. Sur les projets que nous suivons, viser un délai maximal de vingt-quatre heures entre une modification de contenu et sa répercussion dans le chatbot constitue un objectif raisonnable pour la plupart des sites de support.

## Poser des limites explicites au chatbot

Au-delà de l'architecture technique, la consigne système envoyée au modèle doit fixer des limites claires : refuser de répondre en dehors du périmètre couvert par le contenu récupéré, orienter vers un contact humain en cas d'incertitude, et ne jamais inventer une information absente du contexte fourni. Ces consignes réduisent le risque sans le supprimer totalement : un contrôle qualité régulier, par échantillonnage des conversations, reste nécessaire pour détecter les dérives.

> Un chatbot de support n'est fiable que si sa base de connaissances l'est ; le modèle n'est que le porte-voix de ce qu'on lui a donné à lire.

## En résumé

Un chatbot de support IA bien conçu sur WordPress repose moins sur la puissance du modèle de langage utilisé que sur la qualité et la fraîcheur de la base de connaissances qui l'alimente. L'architecture RAG, couplée à une synchronisation automatique du contenu via les hooks WordPress natifs, reste l'approche la plus fiable pour éviter le piège classique des réponses obsolètes ou inventées.