Déployer un agent IA de support client sans sacrifier la qualité

80 % de résolution automatique, c'est séduisant, jusqu'à ce que votre agent donne une mauvaise réponse confiante à 2h du matin. Voici l'architecture qui l'évite.

Le mode d'échec dont personne ne parle

La plupart des déploiements d'agents IA échouent non pas parce que l'IA est mauvaise, mais parce que la logique de transfert est cassée. L'agent répond avec confiance sur des sujets où il ne devrait pas, et escalade sur des choses qu'il pourrait gérer. Les utilisateurs perdent confiance rapidement.

L'architecture qui fonctionne

Trois composants, non négociables :

1. Une base de connaissances délimitée : l'agent ne répond qu'à partir de contenu vérifié et structuré. Pas d'hallucination depuis les données d'entraînement. Génération augmentée par récupération (RAG) avec vos docs produit, FAQ et politiques.
2. Des seuils de confiance avec escalade stricte : en dessous d'un certain score de similarité, l'agent ne devine pas. Il route vers un humain avec le contexte complet.
3. Une piste d'audit : chaque conversation est enregistrée, scorée et revue chaque semaine. Les lacunes dans la base de connaissances remontent vite.

Ce que les chiffres donnent

Avec cette architecture, les clients Cypheria voient typiquement 75-85 % de résolution automatique la première semaine. À la quatrième semaine, après deux mises à jour de la base de connaissances, ils atteignent 85-92 %. Les 8-15 % restants sont de vrais cas complexes qui bénéficient d'un traitement humain.

Sur l'OWASP LLM Top 10

Tout agent orienté client nécessite des mesures contre l'injection de prompt. Les utilisateurs tenteront de le détourner. Construisez le durcissement du prompt système dès le départ, pas comme une réflexion après coup.

La checklist avant la mise en production

1. Nettoyer la base de connaissances : supprimer les documents obsolètes ou contradictoires. L'agent répétera fidèlement une politique de retour périmée si elle est encore dans l'index.
2. Constituer un jeu de questions de test : des questions réelles tirées de l'historique du support, avec la bonne réponse attendue. C'est votre référence pour mesurer chaque changement.
3. Définir un périmètre explicite : la liste des sujets que l'agent traite, et celle des sujets qu'il transfère toujours (litiges, remboursements au-delà d'un montant, questions juridiques ou médicales).
4. Régler le seuil de confiance sur le jeu de test : trop bas, l'agent invente ; trop haut, il escalade tout et n'apporte rien.
5. Concevoir le transfert : l'humain qui reprend la conversation reçoit l'historique complet et les documents consultés, sans que le client ait à se répéter.
6. Prévoir un mode dégradé : si le modèle ou la base vectorielle tombe, le client doit arriver sur un formulaire ou un humain, pas sur un message d'erreur.

Les erreurs les plus fréquentes

Lancer sur tous les canaux à la fois. Commencez par un canal (le chat du site, par exemple) et un volume limité, puis élargissez quand les indicateurs sont stables.

Mesurer uniquement le taux de résolution. Un agent peut « résoudre » une conversation en décourageant le client. Suivez aussi la satisfaction, le taux de recontact et un échantillon de conversations relues par un humain.

Cacher qu'il s'agit d'une IA. Les clients acceptent un assistant automatisé quand c'est annoncé et qu'un humain reste accessible. Ils l'acceptent beaucoup moins quand ils le découvrent après coup.

Ne jamais mettre à jour la base. Les lacunes identifiées lors de la revue hebdomadaire doivent devenir de nouveaux contenus. Sans cette boucle, la qualité stagne.

Les conversations sont des données personnelles

Un agent de support traite des noms, des courriels, des numéros de commande, parfois des informations sensibles que le client écrit spontanément. Ces journaux relèvent du RGPD en Europe, de la loi 09-08 au Maroc et de la Loi 25 au Québec.

Concrètement : une durée de conservation définie pour les transcriptions, un accès restreint aux personnes qui les relisent, et des engagements clairs du fournisseur du modèle sur l'usage des données. Au Québec, la Loi 25 exige une évaluation des facteurs relatifs à la vie privée (EFVP) avant un projet de système d'information qui traite des renseignements personnels, et avant de communiquer ces renseignements à l'extérieur du Québec, ce qui est le cas si le modèle est hébergé ailleurs. Elle impose aussi d'informer la personne lorsqu'une décision la concernant est fondée exclusivement sur un traitement automatisé.

Les questions à poser à un prestataire

1. Sur quelles sources l'agent répond-il, et comment l'empêchez-vous de répondre en dehors ?
2. Comment le seuil d'escalade est-il fixé, puis ajusté ?
3. Où sont hébergés le modèle, la base vectorielle et les journaux de conversation ?
4. Qui relit les conversations, à quelle fréquence, et comment les corrections sont-elles intégrées ?
5. Quelles protections contre l'injection de prompt avez-vous testées avant la mise en production ?

En résumé

1. Un agent de support échoue rarement à cause du modèle : c'est la logique de transfert vers l'humain qui fait la différence.
2. Trois composants sont non négociables : une base de connaissances délimitée, des seuils de confiance avec escalade stricte, et une piste d'audit.
3. Démarrez sur un seul canal, avec un jeu de questions de test, et mesurez la satisfaction autant que le taux de résolution.
4. Les transcriptions sont des données personnelles : durée de conservation, accès restreint et, au Québec, EFVP avant le projet.
5. La protection contre l'injection de prompt se construit dès le départ, pas après le premier incident.

Un audit gratuit de vos systèmes ?

30 minutes. On identifie vos vrais risques. Sans jargon, sans engagement.