Une entreprise ne perd pas de l’argent au service client uniquement lorsqu’elle répond trop tard. Elle en perd aussi lorsqu’elle répond vite à la mauvaise personne, clôt un dossier qui n’était pas réglé, ou laisse un client en colère tourner dans une boucle de réponses correctes mais inutiles.
L’automatisation échoue moins à cause de l’IA qu’à cause d’une mauvaise politique d’escalade.
Voilà la thèse inconfortable : dans le service client, le vrai travail ne commence pas par le chatbot. Il commence par la reprise humaine. D’abord, vous décidez ce qu’une machine peut répondre en sécurité, quand elle doit demander de l’aide et quels signaux obligent à passer à une personne. Ce n’est qu’ensuite que l’automatisation mérite d’être construite.
L’erreur classique : vouloir que l’IA “fasse le support” avant de fixer les règles
L’idée courante est facile à comprendre. Si l’IA peut répondre aux questions fréquentes, pourquoi ne pas la laisser parler au client dès le premier message ? Parce que le support n’est pas un exercice de rédaction ; c’est une chaîne de décisions qui ont un coût.
Si un colis est en retard, une réponse générique peut calmer la situation. Si le client parle d’un remboursement, d’un paiement en double ou d’un sujet contractuel, la mauvaise réponse automatique augmente la friction. Le problème n’est pas seulement le contenu. C’est le moment.
Le meilleur point de départ est plus sobre. Dessinez trois cases :
- les cas que l’IA peut résoudre seule ;
- les cas que l’IA peut préparer mais doit transmettre ;
- les cas qui doivent aller directement à une personne.
Cette répartition compte plus que l’outil. Et elle doit être revue avec le support, les opérations et le commerce, pas seulement avec la technologie.
Le scénario à imaginer avant d’acheter quoi que ce soit
Prenons une PME qui vend des pièces détachées et reçoit des demandes par e-mail, formulaire et WhatsApp. L’équipe répond sur les commandes, les factures, le stock et les garanties. Le dirigeant veut “mettre de l’IA” pour réduire le temps de réponse.
L’entreprise lance un assistant qui répond vite. Pendant une semaine, tout semble fonctionner. Puis trois problèmes apparaissent : des clients rouvrent les tickets parce que la réponse ne fermait pas réellement le sujet, les agents perdent du temps à corriger les messages, et des demandes sensibles sont traitées comme des questions ordinaires.
Ce qui manquait n’était pas un meilleur modèle, mais une meilleure conception opérationnelle :
- une politique claire sur les données que l’IA peut utiliser ;
- des limites pour ne pas improviser sur les prix, les remboursements ou les engagements contractuels ;
- une règle simple d’escalade quand un signal de risque apparaît ;
- un historique complet pour que la personne qui reprend le dossier voie le contexte.
En pratique, l’IA ne remplace pas le support. Elle dégage le chemin pour qu’une personne résolve plus vite.
La bonne métrique n’est pas “réponses automatiques”
C’est ici que le pilotage se trompe souvent. Beaucoup d’entreprises célèbrent le pourcentage de messages répondus par l’IA. C’est une métrique séduisante et assez faible.
Ce qu’il faut mesurer, c’est plutôt :
- la résolution : le dossier est-il clos sans réouverture ?
- la récurrence : le même client revient-il avec le même problème ?
- le risque : y a-t-il des cas qui auraient dû être escaladés plus tôt ?
- le temps jusqu’à la bonne personne : combien de temps faut-il pour atteindre quelqu’un qui peut vraiment décider ?
Si le système répond beaucoup mais résout peu, vous avez amélioré le théâtre, pas l’opération. Et si l’automatisation fait gagner des minutes mais augmente les réclamations, le bilan peut être négatif.
La lecture d’OpenAI sur l’entreprise va dans ce sens plus large : passer de l’assistance à l’exécution exige de connecter le contexte, les outils, les permissions et les règles d’escalade pour faire du travail utile sans perdre le contrôle. C’est particulièrement vrai dans le support, où la qualité dépend autant de la réponse que de la décision de transmettre à temps. (openai.com)
Le compromis inconfortable : parfois, il faut laisser plus de cas aux humains
Cela heurte souvent les attentes commerciales. Plus d’automatisation ne signifie pas toujours un meilleur service. Dans certains métiers, cela veut dire plus de vitesse sur les cas simples et plus de dégâts sur les cas sensibles.
Il existe des situations où une “bonne friction” est le bon choix :
- commandes à forte valeur ;
- clients avec un historique d’incidents ;
- remboursements hors délai ;
- changement d’adresse après expédition ;
- messages avec colère, menace juridique ou risque réputationnel.
Dans ces cas, la meilleure décision peut être que l’IA ne clôture rien. Elle peut collecter les informations, classer le motif et préparer le résumé. Mais la clôture doit revenir à une personne.
Cette retenue partielle n’est pas un échec. C’est de la gouvernance.
Un test simple pour savoir si vous êtes prêts
Si vous voulez savoir si votre entreprise est prête, ne commencez pas par le modèle. Posez ces trois questions :
- Savons-nous ce que le support peut promettre sans casser les opérations ?
- Avons-nous des signaux clairs pour escalader avant que le dossier ne s’aggrave ?
- Pouvons-nous revoir chaque semaine la récurrence et les erreurs de reprise ?
Si la réponse est non, commencer par un chatbot public est une mauvaise idée. Si la réponse est oui, l’IA peut entrer comme une couche utile de classification, de préparation et de réponse partielle.
La frontière entre automatisation utile et automatisation dangereuse tient rarement à l’intelligence du système. Elle tient à la discipline avec laquelle une entreprise définit quand répondre et quand escalader.
Trois actions pour cette semaine :
- Listez dix motifs réels de contact et classez ceux qui peuvent être clos, préparés ou escaladés.
- Reprenez trois dossiers réouverts récemment : la réponse, le contexte ou la transmission ont-ils échoué ?
- Définissez une métrique hebdomadaire de risque, de récurrence et de résolution avant d’étendre l’automatisation.
Votre équipe mesure-t-elle combien de cas l’IA résout réellement, ou seulement combien de messages elle parvient à répondre ? Chez Codefuente, c’est souvent la première question que nous posons avant de concevoir la solution.