« Votre commande sera livrée sous 24 heures. » Le message, envoyé par le chatbot installé sur le portail client HubSpot, a fini par remonter jusqu’au service client sous forme de réclamation : la commande en question n’était même pas encore expédiée cinq jours après cette promesse. Le délai réel de cette référence, en stock partiel, tournait plutôt autour de 3 à 10 jours selon l’entrepôt d’expédition.
Ce n’était pas un cas isolé. Sur les deux semaines précédentes, sept tickets similaires avaient été ouverts, tous avec des délais différents, tous inventés avec la même assurance. Ce billet ne traite que ce symptôme précis et sa correction ; la configuration marketing de HubSpot dans son ensemble reste hors sujet.
Le symptôme observé
Le chatbot, construit à partir d’un LLM relié à la base de connaissances HubSpot, répondait à toute question sur un délai de livraison avec un chiffre précis et une formulation confiante, quelle que soit la référence demandée. Aucun signal d’incertitude, aucune formule du type « selon le produit » : toujours un nombre rond, souvent 24 ou 48 heures, quel que soit le stock réel.
En creusant les journaux de conversation, le même motif revenait : dès que le client mentionnait un numéro de commande ou une référence produit, le modèle générait un délai plausible statistiquement — la majorité des commandes de ce site partent effectivement sous 24 à 48 heures — sans jamais vérifier si la référence demandée faisait partie de cette majorité.
Le diagnostic : aucune source vérifiée
Le prompt système du chatbot ne contenait qu’une instruction générale : « Réponds aux questions sur les délais de livraison de manière rassurante. » Aucun appel à l’API HubSpot pour récupérer le statut réel de la commande, aucune requête vers l’ERP qui gère les stocks par entrepôt. Le modèle n’avait tout simplement aucun moyen de savoir si la commande était en stock, en rupture partielle ou en attente de réapprovisionnement fournisseur.
Dans ces conditions, la réponse générée n’est pas un bug au sens classique : le modèle fait exactement ce qu’on lui demande, produire une réponse plausible et rassurante. Le problème vient de l’absence de contrainte factuelle, pas d’un dysfonctionnement du LLM lui-même.
Le correctif : ancrer sur les données réelles
La correction a consisté à intercaler un appel systématique à l’API HubSpot avant toute réponse chiffrée, via un point de terminaison interne exposé par le CRM :
function get_delai_livraison_reel( $numero_commande ) {
$response = wp_remote_get(
'https://api.hubapi.com/crm/v3/objects/deals/' . $numero_commande,
array(
'headers' => array(
'Authorization' => 'Bearer ' . HUBSPOT_TOKEN,
),
)
);
if ( is_wp_error( $response ) ) {
return null;
}
$body = json_decode( wp_remote_retrieve_body( $response ), true );
return $body['properties']['delai_estime_jours'] ?? null;
}Le prompt a ensuite été réécrit pour interdire explicitement toute réponse chiffrée sans ce résultat : si l’appel échoue ou renvoie une valeur nulle, le chatbot doit répondre « Je transmets votre question au service client » plutôt qu’inventer un chiffre.
Les garde-fous ajoutés
- Interdiction explicite dans le prompt système de tout délai chiffré sans donnée source associée.
- Journalisation systématique des réponses contenant un chiffre, pour audit a posteriori.
- Message de repli standardisé vers un conseiller humain en cas d’absence de donnée.
La prévention à long terme
Un contrôle hebdomadaire a été mis en place : extraction de toutes les réponses du chatbot contenant un nombre suivi de « heures » ou « jours », puis vérification manuelle sur un échantillon de dix conversations. Ce contrôle a permis de repérer une deuxième dérive trois semaines plus tard, cette fois sur les délais de remboursement, avant qu’elle ne génère de nouvelles réclamations.
Un chatbot qui répond avec assurance n’est pas un chatbot fiable : c’est un chatbot qui n’a pas encore rencontré la question à laquelle il ne sait pas répondre.
En résumé
Un LLM sans accès aux données réelles produira toujours une réponse statistiquement plausible plutôt qu’une réponse vraie. Sur un sujet aussi sensible qu’un délai de livraison, l’ancrage sur une source vérifiée n’est pas une option de confort : c’est la condition minimale pour que le chatbot ne devienne pas lui-même une source de réclamations.
