Agents IA pour le support client

Un agent de support se différencie considérablement d'un chatbot lorsqu'il peut combiner trois éléments: une récupération fiable, un appel d'outil et des limites de décision explicites. La récupération maintient les réponses aux politiques et aux produits fondées sur le contenu approuvé. L'appel d'outil permet au système de rechercher une commande, de vérifier l'inventaire, de créer une note interne ou de lancer une demande de retour via une API définie au lieu de faire semblant de mémoire. Les limites de décision indiquent à l'agent quand répondre, quand demander des preuves d'identité supplémentaires, quand mettre une action en file d'attente pour approbation et quand s'arrêter.

OpenAI et Anthropic documentent tous deux des modèles d'outils/fonctions permettant aux modèles d'appeler des systèmes externes, mais le défi de production ne consiste pas simplement à exposer une fonction. Chaque outil nécessite un schéma typé avec des champs obligatoires, des valeurs d'énumération, des règles de validation, des contrôles d'autorisation et des formes de retour claires afin que l'orchestrateur puisse décider de ce qui s'est passé. Un outil `create_return_request`, par exemple, devrait nécessiter un client authentifié, un identifiant de commande, des identifiants d'articles de ligne, un code de motif et une clé d'idempotence. Il doit renvoyer un statut tel que « créé », « déjà_existant », « needs_review » ou « refusé », et non un vague message de réussite.

La couche d'orchestration est le produit. Il décide quelle invite de modèle s'exécute, quel index de récupération est interrogé, quels outils sont disponibles pour le client actuel, comment fonctionnent les nouvelles tentatives, quand une file d'attente d'approbation humaine est requise et ce qui est écrit dans la piste d'audit. Un agent de commerce électronique utile doit être capable d'expliquer pourquoi il a choisi un outil et quelle source ou quel résultat d'API prend en charge la réponse destinée au client.

Il existe trois modèles d'architecture pratiques. Une conception à agent unique utilise un chemin d'orchestration de modèle pour la classification, la récupération, le choix des outils et la réponse. Il est plus facile à utiliser et fonctionne bien lorsque la portée du support est étroite. Une conception multi-étapes ou multi-agents sépare la détection d'intention, la récupération, l'exécution du flux de travail et la composition des réponses. Il peut être plus facile de déboguer car chaque étape a une tâche plus petite, mais cela ajoute de la latence et davantage de lieux de dérive de l'état.

Les systèmes de production ajoutent généralement une porte politique autour du modèle. La porte peut vérifier le canal, l'état d'authentification du client, la propriété de la commande, les autorisations des outils, le niveau de risque, les paramètres régionaux et les règles métier avant que le modèle ne soit autorisé à appeler tout ce qui change d'état. Ceci est important car la même phrase peut avoir des autorisations différentes selon le contexte: « annuler ma commande » présente un faible risque avant l'exécution, un risque plus élevé après la sortie de l'entrepôt et souvent impossible après le retrait du transporteur.

L'humain dans la boucle n'est pas une solution de repli; c'est un choix de conception. Utilisez-le pour les remboursements, les changements d'adresse après le début de l'exécution, l'accès au compte, les problèmes de fraude, les clients de grande valeur, les comptes de gros, le langage juridique, les problèmes médicaux ou de sécurité et toute action qui ne peut pas être facilement annulée. La meilleure architecture est généralement mixte: autonome pour le travail factuel à faible risque, files d’attente d’approbation pour les changements financiers ou opérationnels et prise de contrôle humaine immédiate pour les cas émotionnels ou ambigus.

La gestion du contexte est l'endroit où de nombreuses démos s'interrompent après le lancement. Un modèle ne peut raisonner qu'en fonction du contexte qui lui est donné, et le contexte de support change au fil du temps: le client revient quelques jours plus tard, la commande est expédiée, un remboursement est effectué, un humain laisse une note interne ou la même personne envoie des messages depuis WhatsApp au lieu d'un chat Web. L'agent a besoin d'un état persistant en dehors du modèle.

Recherchez quatre capacités. Premièrement, la résolution de l'identité: le système doit correspondre aux clients par courrier électronique, par téléphone, par session de connexion, par numéro de commande et par identité de canal sans exposer trop tôt les données privées. Deuxièmement, la conception de la session: la plate-forme doit stocker un identifiant de conversation durable, un identifiant client, un identifiant de canal, un état d'authentification, des références de commande actives et un état de transfert séparément de l'invite du modèle. Troisièmement, des résumés durables: les conversations passées doivent être compressées dans des enregistrements précis des numéros de commande, des promesses faites, des actions prises et des problèmes non résolus. Quatrièmement, actualisation de la source: les données de commande et de politique en direct doivent être revérifiées lorsque la réponse dépend de l'état actuel.

L'authentification fait partie du contexte et non une case à cocher distincte. Une session Web connectée, un lien d'assistance signé, une réponse par e-mail et un numéro de téléphone WhatsApp n'apportent pas la même assurance. L’agent ne doit exposer que des informations à faible risque jusqu’à ce qu’il dispose de preuves suffisantes, et un résumé de conversation obsolète ne doit jamais prendre le pas sur la plateforme commerciale.

Un client envoie un message sur WhatsApp: « Je dois retourner la veste bleue de la commande n° 2204. » Un agent de production ne doit pas passer directement à une étiquette. Il doit identifier le client, vérifier que la commande appartient à cette personne, récupérer la commande depuis Shopify ou WooCommerce, vérifier la politique d'exécution et de retour, inspecter les règles au niveau de l'article telles que la vente finale ou les exclusions d'hygiène, et déterminer si l'action est autorisée.

Le schéma de l'outil doit rendre ces vérifications explicites. Un flux sécurisé peut appeler `lookup_customer`, `lookup_order`, `check_return_eligibility`, puis `create_return_request`. Chaque appel doit recevoir des entrées saisies, utiliser des informations d'identification de moindre privilège et renvoyer des résultats lisibles par machine que l'orchestrateur peut évaluer. L'outil d'action doit inclure une clé d'idempotence dérivée de la conversation, de la commande, de l'élément de campagne et de l'action demandée afin que les messages répétés ou les tentatives de webhook ne créent pas d'étiquettes en double, de tickets en double ou de remboursements en double.

Si la commande est éligible, l'agent peut créer une demande de retour, générer ou demander une étiquette via le système de retours ou d'expédition, ajouter une note interne et indiquer au client ce qui se passe ensuite. Si la commande ne respecte pas la politique, est partiellement remboursée, a déjà été retournée, fait l'objet d'un examen pour fraude ou n'a pas fait l'objet d'une vérification d'identité, la situation doit être transmise avec un résumé concis. Chaque action d'écriture doit laisser un enregistrement d'audit avec le message de l'utilisateur, les entrées de l'outil, le résultat de l'outil, la source de la politique et la réponse finale du client.

Les démos montrent le chemin heureux. Évaluez ces dimensions pour trouver les modes de défaillance. Un: la fiabilité des appels d’outils. À quelle fréquence l’agent sélectionne-t-il la mauvaise fonction? Comment récupère-t-il lorsqu'un appel API échoue? Testez avec des demandes ambiguës telles qu'un numéro de commande manquant ou une description de produit vague. Deuxièmement: la qualité de la récupération des connaissances. L’agent récupère-t-il la bonne section de stratégie lorsque plusieurs documents se chevauchent? Si votre page de retour indique 30 jours et qu'une page produit indique 14 jours pour les articles en vente, l'agent résout-il ou fait-il apparaître le conflit? Troisièmement: le taux d'hallucinations. Posez des questions avec des prémisses délibérément fausses (« J'ai commandé un produit que vous ne vendez pas »). L'agent fabrique-t-il une commande ou dit-il qu'il ne la trouve pas? Quatrièmement: les renseignements sur l'escalade. L'agent s'intensifie-t-il quand il le devrait, ou persiste-t-il avec de mauvaises réponses? Testez avec un langage de client frustré.

Cinquièmement: la cohérence à plusieurs tours. Posez une question, changez de sujet, revenez à la question d'origine et vérifiez que l'agent conserve le bon état de session sans exposer de données privées. Six: authentification et autorisation. Testez les scénarios de connexion, de déconnexion, de courrier électronique, de WhatsApp et de téléphone partagé. Septièmement: l’idempotence de l’action. Répétez la même demande d'annulation ou de retour et confirmez qu'un seul workflow est créé. Huit: gestion de la langue et des paramètres régionaux. Testez dans les langues utilisées par vos clients, y compris dans les conversations multilingues. Neuf: modes d'échec de l'intégration de la plateforme. Que se passe-t-il lorsque l'API Shopify Admin renvoie une erreur de limite de débit 429? Que se passe-t-il lorsque l'API REST WooCommerce est inaccessible? L'agent informe-t-il le client qu'il y a un retard ou échoue-t-il silencieusement?

Dix: observabilité et évaluations. Vous devriez pouvoir voir chaque étape du modèle, la source récupérée, l'appel de fonction, l'entrée de l'outil, la sortie de l'outil, la décision d'autorisation, la nouvelle tentative, l'escalade et la réponse finale. Exécutez un ensemble d'évaluations hors ligne de tickets historiques avant le lancement, puis suivez les mesures de production par intention: taux de résolution correcte, tentatives d'actions dangereuses, prévention des actions en double, exposition aux ordres erronés, précision des escalades, contacts répétés, CSAT et taux de remplacement humain. Si la plateforme ne peut pas afficher ces preuves, vous ne pouvez pas la déboguer ou la gérer.

Déploiement par phases. Commencez par des flux de travail en lecture seule: récupération des politiques, recherche de commandes, statut d'expédition et questions sur les produits. Avant que les clients ne le voient, exécutez des évaluations préliminaires et hors ligne avec des conversations historiques, des cas extrêmes prédéfinis, des échecs d'API simulés, des messages en double, une identité faible, une politique obsolète et des conflits de politique. Examinez quotidiennement les premières conversations avec les clients et corrigez la source de connaissances, le schéma de l'outil ou la règle d'orchestration lorsque la réponse est fausse. N’ajoutez l’exécution d’actions qu’une fois que l’agent a prouvé qu’il identifie correctement les clients et fait remonter les cas extrêmes.

La préparation de l’équipe compte autant que la qualité du modèle. Les responsables du support ont besoin d'une boucle de révision hebdomadaire pour les mauvaises réponses, les articles manquants, les appels d'outils ayant échoué, les tentatives d'actions dangereuses, les blocages d'actions en double et les raisons d'escalade. Les agents ont besoin d’une formation sur la façon de prendre le relais des résumés de l’IA et sur la façon de marquer les résultats afin que le système puisse être évalué. L'ingénierie ou les opérations doivent être propriétaires des informations d'identification de l'API, des règles de session/d'authentification, des clés d'idempotence, des tentatives de webhook, des journaux, des modifications de politique, des modifications de campagne et des exceptions d'exécution. Sans ce rythme de fonctionnement, l’IA s’éloignera lentement du fonctionnement réel du magasin.