Comment choisir une solution d’IA pour le service client selon la tâche, les données et le risque

Commencez par le résultat que vous voulez obtenir

Choisir une solution d’IA pour le service client ne commence pas par le choix d’un modèle. Il faut d’abord décrire le travail que l’on souhaite faire évoluer et le résultat qui sera considéré comme satisfaisant. « Améliorer le support » est une formulation trop générale pour guider une décision : il peut s’agir de classer les messages avec moins d’interventions, de trouver plus facilement des informations à jour, de préparer des brouillons pour un agent ou d’effectuer une action demandée par un client. Chaque objectif appelle des données, des contrôles et des essais différents.

Délimitez le cas à l’aide de cinq questions : quelles demandes arrivent, par quels canaux et dans quelles langues ; qui les reçoit aujourd’hui ; quel résultat le système doit produire ; quelles exceptions sont exclues ; et qui prend le relais lorsque le système ne peut pas résoudre le cas. Définissez également ce que signifie résoudre un contact : envoyer une réponse ne signifie pas nécessairement apporter une solution correcte, et clôturer un ticket ne prouve pas à lui seul que le besoin a été satisfait.

Distinguez l’objectif opérationnel de l’objectif d’automatisation. Réduire le temps nécessaire à la préparation d’une réponse peut être utile même si une personne continue de la vérifier. À l’inverse, réduire le nombre d’agents mobilisés ne doit pas être considéré comme une réussite si les réponses erronées, les rectifications ou les demandes répétées augmentent. Ces critères sont des recommandations pour concevoir une évaluation ; ils doivent être adaptés aux politiques, au service et aux engagements de chaque organisation.

Classez la tâche avant de choisir la technologie

Une même conversation peut faire intervenir plusieurs tâches, mais il est préférable de les évaluer séparément. Classer et orienter consiste à attribuer une catégorie ou une destination ; rechercher des informations consiste à trouver un contenu pertinent ; rédiger consiste à proposer une réponse ; résumer consiste à condenser un échange ; exécuter une action implique de modifier un élément en dehors de la conversation, par exemple dans un compte ou un système de tickets. Plus la tâche se rapproche d’un changement de l’état d’un compte, plus l’autorisation, la vérification et la possibilité d’annuler la modification deviennent importantes.

Toutes ces tâches ne nécessitent pas de génération de texte. Si une demande est repérable au moyen de champs stables et de règles claires, une automatisation classique peut être plus simple à tester et à maintenir. Un classificateur spécialisé peut être utile lorsque le langage varie d’une manière que les règles gèrent mal ; un système génératif peut convenir lorsqu’il faut interpréter une question et formuler une réponse. Le choix dépend du contexte : le fait qu’une interaction se déroule par chat ne suffit pas à conclure qu’un modèle génératif est la meilleure option.

Les sources disponibles présentent l’IA pour le service client comme un domaine d’automatisation et d’assistance, mais les informations fournies ne comparent pas de façon indépendante l’efficacité de chaque approche et ne permettent pas d’affirmer que l’une est supérieure aux autres. Considérez donc cette comparaison comme une hypothèse à tester sur des demandes représentatives de votre propre service, et non comme une promesse de résultat.

Adaptez le niveau de délégation aux conséquences d’une erreur

Le niveau d’autonomie ne devrait pas dépendre uniquement de la difficulté technique. Demandez-vous ce qui peut se passer si la réponse est erronée ou incomplète, ou si elle est appliquée au mauvais compte. Une explication générale, facile à vérifier et sans effet durable, ne présente pas le même type de risque qu’une décision qui modifie un compte, affecte un paiement ou conditionne l’accès à un service. La réversibilité, le temps disponible pour corriger le problème et la capacité réelle d’une personne à intervenir comptent également.

À titre de cadre opérationnel, distinguez trois niveaux. Au premier, le système organise ou recherche des informations, mais ne répond pas au client et ne modifie pas son compte. Au deuxième, il prépare une réponse ou une recommandation qu’une personne valide avant l’envoi. Au troisième, il peut répondre ou exécuter des actions dans des limites explicites. Le passage d’un niveau au suivant suppose de disposer d’éléments montrant que le niveau précédent satisfait aux critères convenus, ainsi que de contrôles adaptés au nouveau niveau ; il n’est pas nécessaire d’automatiser davantage pour démontrer une utilité.

Prévoyez une possibilité visible de s’abstenir et de transmettre le cas. S’il manque des données, si la demande est ambiguë, si les sources divergent ou si le client conteste une décision, le système devrait pouvoir renoncer à proposer une résolution automatique. Pour les cas délicats, la possibilité pour une personne de vérifier le résultat ne doit pas se limiter à la conservation d’une trace : cette personne doit disposer d’un contexte suffisant, de l’autorité nécessaire pour corriger le résultat et d’une procédure permettant d’interrompre l’action.

L’Agence espagnole de protection des données inclut dans ses ressources un guide sur l’IA agentique, un sujet pertinent lorsqu’un système peut effectuer des tâches. La note disponible confirme cette pertinence générale, mais ne fournit pas assez de détails pour attribuer à ce guide des règles précises en matière d’autorisation, de supervision ou de conception. Les contrôles de cette section sont donc des critères de décision proposés, à confronter aux politiques et obligations applicables au cas concerné.

Examinez les données avant de les connecter

Dressez l’inventaire des sources qu’utiliserait chaque approche : messages entrants, historique des conversations, dossiers de compte, documentation d’aide, politiques internes ou informations sur les produits. Pour chaque source, indiquez qui en est responsable, sa date de mise à jour, les personnes autorisées à la consulter et la présence éventuelle de données personnelles, confidentielles ou qui ne devraient pas sortir de l’environnement prévu. Ne partez pas du principe qu’une base documentaire est sûre ou à jour simplement parce qu’elle est déjà utilisée par le service client.

Limitez les informations au strict nécessaire pour la tâche. Pour classer une demande, il n’est peut-être pas nécessaire de transmettre tout l’historique du compte ; pour répondre à partir d’une documentation, il peut suffire de retrouver le contenu pertinent plutôt que d’intégrer de grandes quantités de données dans l’instruction. Évaluez s’il est possible d’exclure, de masquer ou de remplacer les informations permettant d’identifier une personne, puis vérifiez à partir de documents primaires récents le traitement proposé par tout service externe envisagé. Les informations disponibles ici ne permettent pas d’affirmer quelles sont les politiques de conservation, de sécurité ou d’utilisation des données des fournisseurs.

Consignez également les conditions d’utilisation et les responsabilités internes. Le guide de bonnes pratiques de PwC recensé parmi les sources aborde des questions de confidentialité et les décisions relatives à la collecte et à l’utilisation des données, mais les éléments disponibles se limitent à un extrait et non à un examen complet de ses recommandations. Considérez-le comme un signe que la confidentialité doit faire partie de l’évaluation, et non comme un substitut à un examen juridique, de sécurité ou des politiques applicables à l’organisation.

Si les connaissances évoluent fréquemment, désignez une personne ou une équipe chargée de vérifier les documents, leurs dates de validité et les contenus retirés. Concevez un essai qui vérifie non seulement si le système trouve une réponse, mais aussi s’il distingue les informations à jour, incomplètes et contradictoires. Si vous ne pouvez pas déterminer quelle source fait autorité sur chaque sujet, il est prématuré de demander au système de répondre sans vérification.

Choisissez l’approche minimale suffisante pour la tâche

Pour le classement et l’orientation, comparez les règles existantes à une solution de classification. Évaluez les deux sur des messages variés, notamment ceux qui contiennent plusieurs questions, des fautes de frappe ou des informations insuffisantes. La question ne consiste pas seulement à savoir quelle proportion de demandes est correctement orientée, mais aussi quelles catégories concentrent les erreurs, comment les corriger et ce qui se passe lorsque le système n’a pas assez confiance. Si les règles résolvent déjà le problème clairement et à un coût opérationnel acceptable, les remplacer par de la génération de texte peut ajouter de la complexité sans valeur démontrée.

Pour rechercher des réponses dans la documentation, délimitez d’abord la collection consultable et définissez comment reconnaître une réponse étayée. Un essai utile comprend des questions dont la réponse figure dans la documentation, des questions qui n’y sont pas traitées, ainsi que des questions pour lesquelles le contenu est obsolète ou contradictoire. Vérifiez que le système peut indiquer la source utilisée et s’abstenir lorsqu’il ne dispose pas de preuves suffisantes. Afficher une citation ou un extrait ne garantit pas à lui seul que la réponse soit correcte : une personne doit vérifier si la source correspond à la question et est toujours à jour.

Pour rédiger ou résumer, traitez le résultat comme un brouillon. Définissez ce que l’agent peut modifier avant l’envoi et vérifiez les erreurs de contexte, les omissions, le ton inadapté et les promesses non autorisées. Si l’équipe ne peut pas consacrer du temps à la vérification et à la correction, l’économie supposée de la production de davantage de brouillons risque de disparaître. Mesurez l’utilité en évaluant le travail réellement économisé et la qualité, plutôt qu’en comptant les textes générés.

Pour exécuter des actions, limitez les opérations disponibles et séparez l’interprétation de la demande de l’autorisation d’effectuer une modification. Avant toute action, vérifiez l’identité et les autorisations conformément aux procédures en vigueur dans l’organisation. Pour un premier essai, envisagez des actions réversibles et de portée réduite, en consignant ce qui a été demandé, autorisé et exécuté. La vérification après l’action doit confirmer l’état réel du système ; elle ne doit pas simplement se fier au message renvoyé par le modèle.

Ces approches peuvent être combinées, mais cela multiplie les éléments à tester : recherche d’informations, interprétation, génération, intégration et exécution. Commencez par un flux limité, consignez ses échecs et n’ajoutez des composants que s’ils répondent à un problème observé.

Comparez les coûts et les conditions d’exploitation

Comparez le coût par cas résolu, et pas seulement le prix d’un appel ou d’une licence. Incluez, le cas échéant, l’intégration au système de tickets, l’infrastructure, la maintenance des règles ou de la documentation, la supervision, le temps consacré à la vérification humaine, la correction des erreurs et le traitement des cas transmis à une personne. Le coût doit être mesuré sur un volume et avec une définition de la résolution comparables à ceux du processus actuel ; sinon, la comparaison risque de porter sur des tâches différentes.

L’exploitation quotidienne influe également sur le choix. Vérifiez si l’intégration peut présenter à l’agent le contexte nécessaire, si la latence convient au canal, qui entretient la base de connaissances, ce qui se passe lorsqu’une dépendance devient indisponible et qui est chargé de vérifier les résultats. Si le service est assuré en dehors des heures ouvrées, définissez clairement ce qui peut être résolu sans intervention humaine et ce qui doit attendre ou être transmis. Ne supposez pas que « disponible » signifie « résolu ».

Le guide de Softeng destiné aux entreprises recensé parmi les sources aborde les cas d’usage, la gouvernance des données, la sécurité et le retour sur investissement. Cette description justifie d’inclure ces dimensions dans l’évaluation, mais ne fournit pas à elle seule de données comparables sur les coûts ou les performances d’une équipe précise. De même, le contenu général d’IBM sur l’IA dans le service client peut servir de repère contextuel sur le sujet, mais pas de preuve indépendante de l’efficacité ou des résultats attendus.

Concevez un essai susceptible de faire évoluer la décision

Avant le déploiement, préparez un échantillon représentatif des demandes réelles, mais qui inclut aussi des cas difficiles : messages ambigus, demandes hors périmètre, changements de politique, conversations comportant plusieurs besoins et absence d’informations clés. Déterminez qui vérifiera chaque résultat et selon quels critères. Si seuls des exemples simples, choisis pour présenter le système sous son meilleur jour, sont testés, le résultat ne donnera pas une bonne idée de son fonctionnement au quotidien.

Convenez à l’avance des indicateurs et des seuils qui conduiront à poursuivre, revoir ou arrêter l’essai. Selon la tâche, il peut être pertinent de mesurer la justesse du classement par catégorie, les réponses étayées par des sources à jour, la pertinence des transmissions, les erreurs graves, le temps nécessaire pour obtenir une réponse utile, le temps de vérification et le coût par cas résolu. Ne transformez pas un indicateur général en décision automatique : une moyenne favorable peut masquer des erreurs concentrées dans une catégorie ou un groupe de demandes.

Comparez l’essai au processus actuel en utilisant les mêmes catégories de demandes et une définition commune d’un résultat correct. Consignez les erreurs et leurs conséquences, et pas uniquement leur fréquence. Distinguez une erreur qu’un agent peut corriger avant l’envoi d’une action déjà exécutée qui a modifié un compte. En cas d’incident ou de résultat inattendu, désignez la personne chargée de décider si le flux doit être suspendu et définissez comment revenir à la procédure précédente.

Une fiche de décision utile documente le cas, l’approche retenue, les données autorisées, les cas exclus, les vérifications requises, les indicateurs, les seuils et la personne responsable. Elle consigne également les questions qui restent ouvertes. Ainsi, comparer les solutions ou découvrir de nouveaux cas d’usage n’oblige pas à reprendre depuis le début l’examen des risques et des conditions d’exploitation.

Décidez à partir d’éléments probants et gardez la révision ouverte

La décision ne consiste pas simplement à adopter l’IA ou à la rejeter. Il peut être préférable de conserver une automatisation classique, de tester la classification pour une seule catégorie, d’utiliser une recherche avec des brouillons vérifiés ou de suspendre le projet jusqu’à ce que les données et le processus soient mieux organisés. Si la principale incertitude concerne la qualité de la documentation, un essai de recherche peut être plus instructif que l’automatisation des réponses. S’il n’existe aucun moyen de vérifier une action ou de remédier à une erreur, gardez l’exécution sous contrôle humain.

Pour explorer les possibilités, séparez trois questions : quelle solution convient à la tâche ; comment comparer les approches possibles dans les mêmes conditions ; et quels autres cas d’usage pourraient être pertinents ensuite. Cette séquence aide à choisir un périmètre concret, à comparer les solutions selon des critères cohérents et à découvrir des possibilités sans les confondre avec des cas déjà validés.

Les sources fournies apportent des repères contextuels sur l’IA en entreprise, le service client, la confidentialité et les systèmes agentiques. Elles ne suffisent pas à déterminer quel fournisseur répond à des exigences particulières, quel sera le prix d’une mise en œuvre, comment un service conservera les données ni quelles règles en vigueur s’appliquent à un secteur ou à un pays donné. Vérifiez ces points dans la documentation primaire et auprès des fonctions responsables avant de transmettre des données, de souscrire un service ou d’automatiser une décision.

Le principe pratique final est simple : commencez par une tâche bien délimitée, maintenez l’intervention humaine lorsque les conséquences l’exigent et n’élargissez l’usage que lorsqu’un essai représentatif montre que le résultat est acceptable, exploitable et durable. Si les éléments probants sont insuffisants, s’abstenir ou conserver le processus actuel peut être la bonne décision.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.