Dans un jeu de test, une mauvaise réponse ajoute une erreur dans la moyenne. En service à la clientèle, elle peut envoyer la mauvaise information ou obliger quelqu’un à répéter sa demande à un robot qui ne comprend pas mieux la deuxième fois.

Le même modèle prend donc beaucoup plus de risque dès qu’on le place en première ligne. Pour comprendre où il peut casser, il faut séparer le chatbot en composantes plutôt que de le traiter comme une seule IA.

Ce qui se passe après le message

Pour un bot de suivi de commande, le trajet peut ressembler à ceci :

1. le canal reçoit « Où est ma commande 8472? » et crée une session;
2. un classificateur associe le texte à l’intention suivi_commande;
3. un extracteur trouve l’entité numero_commande=8472;
4. le gestionnaire de dialogue vérifie les renseignements encore manquants;
5. une API confirme l’identité et lit le statut dans le système de commandes;
6. un gabarit produit une réponse avec la date et la prochaine action;
7. la session conserve l’intention, les paramètres, les appels et le résultat.

Un état de dialogue pourrait être enregistré comme ceci :

{
  "sessionId": "c-10482",
  "intent": "suivi_commande",
  "confidence": 0.91,
  "slots": { "numeroCommande": "8472" },
  "identityVerified": false,
  "lastStep": "ask_postal_code",
  "apiCalls": []
}

Le modèle de langage naturel ne devrait pas lire directement la base ni décider seul ce qu’il peut révéler. Le gestionnaire de dialogue applique les règles : demander un code postal, limiter le nombre d’essais, appeler une API autorisée et choisir un gabarit. Cette séparation rend le comportement testable et évite qu’une phrase inattendue contourne l’authentification.

La confiance sert à choisir une route

Le classificateur retourne un score pour plusieurs intentions. Si suivi_commande=0,55 et annuler_commande=0,42, répondre directement est risqué. Le seuil ne doit pas seulement maximiser une moyenne; il doit tenir compte du coût de la confusion.

Je définirais trois routes :

confiance >= 0,85 et paramètres complets  → exécuter le scénario
0,60 à 0,85                              → poser une question de clarification
confiance < 0,60 ou intention sensible   → transférer à une personne

Une demande « je veux changer l’adresse » peut toucher une commande déjà expédiée, un risque de fraude et plusieurs systèmes. Même avec un bon score, la règle peut imposer une vérification ou un transfert. Le modèle reconnaît une intention; il ne remplace pas les contrôles du processus.

Le contexte doit aussi expirer. Une session laissée ouverte sur un appareil partagé ne devrait pas permettre de revenir deux heures plus tard et d’afficher une adresse. Les renseignements sensibles doivent être masqués dans les logs, les appels API limités au compte vérifié et les messages protégés contre une entrée qui essaie de faire exécuter du contenu inattendu.

Transférer sans repartir à zéro

Le transfert est une sortie normale du système, pas un échec qu’on doit cacher. Il devrait envoyer à l’agent :

• le texte complet de la conversation;
• l’intention et les entités détectées;
• ce qui a été vérifié et ce qui ne l’a pas été;
• les appels API, leurs résultats et leurs erreurs;
• la raison du transfert, comme confiance_faible ou client_demande_agent.

Le client voit alors « Je vous transfère avec le numéro 8472 et le statut déjà vérifié », pendant que l’agent reçoit la même session. Si le client doit répéter son nom, son numéro et toute l’histoire, on a seulement ajouté une file d’attente.

Une API peut être lente ou indisponible. Le bot ne doit pas transformer un timeout en « commande introuvable ». Il enregistre l’erreur technique, explique qu’il ne peut pas vérifier maintenant et offre une reprise ou un transfert. La session doit aussi rendre les appels idempotents : répéter « annuler » après une coupure ne devrait pas annuler deux fois ou produire deux remboursements.

Mesurer la résolution plutôt que le silence

Le taux d’automatisation peut donner un portrait trop beau. Le robot peut fermer plusieurs conversations sans régler grand-chose. Je regarderais plutôt quatre cohortes :

1. demandes résolues sans retour dans les 48 heures;
2. transferts reçus avec un contexte complet;
3. abandons avant une réponse utile;
4. clients qui reviennent par téléphone ou courriel pour le même motif.

Il faut échantillonner les conversations de chaque catégorie, corriger les intentions mal étiquetées et surveiller si leur distribution change. Une nouvelle promotion peut créer en une journée une demande que le modèle n’a jamais vue. Sans boucle de revue, le taux d’automatisation reste haut pendant que l’expérience se dégrade.

Je commencerais avec quelques intentions fréquentes, une API en lecture seule et un transfert facile. Le test de succès serait simple : le système comprend-il assez bien pour résoudre la demande ou passer le dossier complet à quelqu’un? Répondre à toute heure est utile. Savoir quand arrêter de répondre l’est tout autant.