Service client et IA : automatiser les réponses simples sans perdre les réclamations sensibles

Une demande client traverse rarement un seul logiciel. Elle arrive par e-mail, formulaire, messagerie ou téléphone ; elle doit être rattachée à un compte ; elle dépend d’un contrat, d’une commande, d’un stock, d’une procédure ou d’un historique ; puis elle déclenche une réponse, une action ou une escalade.

Installer une IA au milieu de ce flux sans préciser quelles données font foi revient à accélérer l’improvisation. Le modèle peut rédiger une réponse plausible, mais il ne sait pas naturellement si la politique de retour vient du site public, du contrat signé ou d’une exception accordée à ce client.

La CNIL rappelle que les modèles génératifs ne sont pas des bases de connaissance et peuvent produire des résultats inexacts qui paraissent plausibles. Le profil du NIST consacré à l’IA générative décrit le même risque sous le terme de « confabulation ». Pour le service client, la conséquence est concrète : une phrase fluide n’est pas une preuve que la réponse respecte le contrat ou l’état réel du dossier.

Avant de connecter un modèle au canal client, classez les demandes selon leur conséquence si la réponse est fausse. Cette matrice fixe le niveau d’autonomie avant tout choix technique.

Cette matrice évite un faux choix entre « chatbot autonome » et « aucune automatisation ». L’IA peut être très utile sur les deux premières catégories sans recevoir le pouvoir de trancher les deux dernières.

1. Prélever des demandes représentatives

Constituez un jeu de demandes historiques couvrant les volumes courants, les formulations inhabituelles, les dossiers incomplets et les cas sensibles. Anonymisez ou pseudonymisez les données lorsque cela est nécessaire et ne placez pas des informations client dans un service grand public non autorisé.

Le jeu de test doit refléter le trafic réel. Un pilote évalué uniquement sur vingt questions faciles donnera une confiance artificielle. Les recommandations d’OpenAI sur les évaluations insistent sur des tests propres à la tâche, des cas réels et des situations limites plutôt que sur une appréciation générale du type « cela semble fonctionner ».

2. Écrire la taxonomie et les règles d’escalade

Définissez dix à vingt catégories compréhensibles par les équipes. Pour chacune, précisez le propriétaire, le délai attendu, les données nécessaires, les motifs d’escalade et les actions interdites.

Une règle utile est observable. « Escalader les sujets importants » est inexploitable. « Escalader toute mention de mise en demeure, fraude, fuite de données, préjudice corporel, résiliation contestée ou demande de geste supérieur au seuil autorisé » peut être testée.

3. Désigner les sources qui font foi

Créez une liste courte : base de connaissances approuvée, commandes, contrats, catalogue, incidents et règles commerciales. Chaque réponse doit pouvoir indiquer quelle source et quelle version ont été utilisées.

Le modèle ne doit pas combler une information absente. Si la date de livraison n’est pas disponible, la bonne sortie est une demande de vérification, pas une estimation persuasive.

4. Séparer le texte reçu des instructions du système

Une demande client est un contenu externe, pas une commande technique. Cette séparation devient indispensable lorsqu’un message, une pièce jointe ou une page web peut contenir des instructions destinées à détourner l’agent.

L’OWASP classe l’injection de prompt parmi les principaux risques des applications fondées sur les grands modèles. Les mesures utiles sont concrètes : limiter le rôle du modèle, valider les formats de sortie, isoler les contenus externes, appliquer le moindre privilège et exiger une approbation humaine pour les actions sensibles.

5. Lancer en mode brouillon

Pendant la première phase, l’IA classe et prépare, mais une personne relit avant l’envoi. Enregistrez pour chaque dossier la catégorie proposée, les sources consultées, le brouillon, la correction humaine, le temps de revue et la décision finale.

Cette phase n’est pas une simple recette éditoriale. Elle produit les données nécessaires pour savoir quelles catégories peuvent devenir plus autonomes et lesquelles doivent rester sous contrôle.

6. Ouvrir l’envoi automatique catégorie par catégorie

Une catégorie ne passe en envoi automatique que si les tests montrent un niveau acceptable sur quatre critères : exactitude factuelle, respect des règles, détection des cas à escalader et qualité de l’expérience client.

Gardez un mécanisme d’arrêt, un historique exploitable et un retour simple vers la validation humaine. Une mise à jour de la base de connaissances, du modèle ou du processus doit déclencher une nouvelle série de tests.

Le temps moyen de réponse ne suffit pas. Une automatisation peut répondre plus vite tout en créant davantage de reprises ou en laissant passer les mauvais dossiers.

Suivez au minimum :

1. le taux de classification correcte, mesuré sur un échantillon relu ;

1. le taux d’escalade manquée, c’est-à-dire les cas sensibles que l’IA aurait dû transmettre ;

1. le taux de réponse exacte et sourcée, sans information ajoutée par le modèle ;

1. le temps humain par dossier, y compris les corrections et les reprises ;

1. le taux de réouverture, lorsqu’un client revient parce que la première réponse n’a pas résolu sa demande ;

1. les incidents par catégorie, avec leur gravité et leur cause.

Pour Atalas, le critère prioritaire avant l’autonomie n’est pas la proportion de réponses acceptées sans modification. C’est la capacité du système à ne pas franchir la limite de son mandat et à rendre visibles ses incertitudes.

Le coût dépend moins du nombre de réponses produites que de la dispersion des canaux, de la qualité des sources et des actions autorisées. Construisez le budget avec six postes :

1. cartographie des catégories et des exceptions ;

1. préparation des données et des sources de référence ;

1. intégration aux canaux, au CRM et aux outils opérationnels ;

1. développement des règles, droits, journaux et écrans de validation ;

1. constitution du jeu de tests et recette métier ;

1. exploitation : consommation des modèles, surveillance, corrections, mises à jour et traitement des incidents.

Un pilote peut être borné à un canal, deux ou trois catégories et un mode brouillon. Le délai ne se déduit pas d’une moyenne de marché : il dépend du temps nécessaire pour obtenir des demandes représentatives, désigner les sources qui font foi et rendre les règles d’escalade testables. Si ces prérequis ne sont pas prêts, accélérer le développement ne raccourcit pas le chemin vers une production fiable.

Pour comparer des devis, utilisez la méthode détaillée dans Projet IA sur mesure : comment construire un budget réaliste avant de demander des devis.

Imaginons un distributeur qui reçoit chaque jour des demandes sur les délais, les pièces manquantes, les retours et les remises. Son pilote commence sur l’e-mail et ne couvre que les demandes de disponibilité et de suivi de commande.

L’IA rattache le message au compte, classe la demande et consulte deux sources approuvées. Elle prépare une réponse avec les références utilisées. Si les systèmes se contredisent, si la commande dépasse un seuil ou si le client mentionne une pénalité, le dossier est transmis sans envoi automatique.

Après plusieurs semaines, l’entreprise peut décider d’automatiser les réponses dont les données concordent et dont le risque est faible. Les demandes de remise, de remboursement, de litige ou d’exception restent validées par les équipes.

Cet exemple est fictif. Il illustre la méthode ; il ne constitue ni un cas client Atalas ni une promesse de résultat.

• Confidentialité : les tickets peuvent contenir des données personnelles, contractuelles ou stratégiques. Le choix du service, les paramètres de réutilisation, les transferts et les droits d’accès doivent être examinés.

• Information du client : l’article 50 du règlement européen sur l’IA s’applique depuis le 2 août 2026 à certains systèmes interactifs. Lorsqu’une personne échange directement avec une IA, vérifiez avec le fournisseur et vos conseils la manière dont l’information doit être présentée dès le début de l’interaction, sauf lorsque le caractère artificiel est évident.

• Injection de prompt : un texte ou une pièce jointe peut chercher à modifier le comportement du système. Les contenus clients doivent rester non fiables par défaut et ne jamais élargir les droits du modèle.

• Dérive de la connaissance : une procédure périmée peut produire une réponse parfaitement fidèle mais fausse. Chaque source doit avoir un propriétaire et une date de révision.

• Biais d’automatisation : une interface fluide peut pousser les agents humains à accepter trop vite. Montrez les sources, les incertitudes et les règles qui ont déclenché l’escalade.

• Perte de contexte relationnel : une réponse correcte peut être inadaptée à un client stratégique ou à une situation émotionnelle. Le niveau de service ne se réduit pas à l’exactitude d’une FAQ.

Le protocole Atalas pour les documents clients complète ces contrôles lorsque le système exploite contrats, tickets ou pièces jointes.

Prenez cent demandes récentes et classez-les selon les quatre niveaux de la matrice. Pour chaque catégorie, notez la source qui fait foi, l’action interdite et le motif d’escalade.

Si vous ne pouvez pas remplir ces trois colonnes, le projet n’est pas prêt pour l’envoi automatique. Il peut néanmoins commencer en mode tri et brouillon afin de rendre les règles visibles.

Le Studio IA Atalas peut concevoir ce flux, le relier aux outils existants et préparer les tests, les droits et les conditions d’exploitation nécessaires à une mise en production progressive.

Faut-il commencer par un chatbot sur le site ?

Pas nécessairement. Pour beaucoup de PME, le meilleur point de départ est le canal déjà utilisé par les clients, souvent l’e-mail ou le formulaire de support. Le pilote doit réduire une friction existante plutôt qu’ajouter un nouveau canal.

Une base de connaissances suffit-elle à empêcher les hallucinations ?

Non. Elle améliore l’ancrage, mais elle ne supprime ni les erreurs de récupération, ni les sources périmées, ni les réponses ajoutées par le modèle. Il faut des tests, des règles de refus et une validation des catégories sensibles.

Quand autoriser l’envoi automatique ?

Quand une catégorie possède des sources stables, des erreurs détectables, une faible conséquence en cas d’échec et des résultats suffisants sur un jeu représentatif. L’autorisation se donne catégorie par catégorie, pas à l’ensemble du service client.

Faut-il informer le client qu’il parle à une IA ?

L’article 50 du règlement européen sur l’IA prévoit une information pour certains systèmes qui interagissent directement avec des personnes, sauf lorsque cela est évident. L’application exacte dépend du rôle de l’entreprise, du système et du parcours ; elle doit être vérifiée dans le dispositif retenu.

Quels dossiers doivent toujours être escaladés ?

Au minimum, ceux qui engagent juridiquement ou financièrement l’entreprise, concernent la sécurité ou les données personnelles, signalent un préjudice important ou sortent des règles documentées. Chaque entreprise doit compléter cette liste selon son activité.