IA pour le service client : quelle architecture choisir

·

Chatbot, copilote et agent ne sont pas synonymes. Un chatbot répond dans un périmètre défini ; un copilote propose des réponses à une personne qui décide ; un agent peut interroger des systèmes et exécuter des actions par lui-même. L'architecture doit être choisie en fonction de l'impact et de la réversibilité : plus l'autonomie est grande, plus l'identité vérifiée, les permissions, la validation, la supervision, les traces et l'escalade humaine deviennent indispensables.

Comparatif

Avant de décider quoi construire, il convient de situer chaque architecture selon sa fonction et son niveau de risque :

Architecture Fonction Risque Usage adapté
FAQ / chatbot Répond avec des informations Faible / moyen Questions fréquentes
RAG Répond avec des sources Moyen Politiques et produits
Copilote Assiste un agent humain Moyen Résumés et brouillons
Agent Exécute des actions Élevé Rendez-vous ou changements limités

La règle générale est simple : ne pas accorder de droit d'écriture à un système s'il suffit qu'il informe.

Concevoir par intention

La première étape n'est pas de choisir une technologie, mais de classer les contacts que le canal va recevoir :

Chaque intention est associée à ses propres données, à sa propre exigence d'authentification, à sa propre action et à sa propre voie d'escalade. Le modèle ne doit pas improviser en dehors de ce catalogue.

Transparence

L'article 50 du règlement européen sur l'intelligence artificielle (AI Act) impose d'informer les personnes lorsqu'elles interagissent avec un système d'IA dans les cas applicables, sauf si cela est évident. Cette information doit apparaître dès le début de la conversation, et non dissimulée dans une mention légale.

Il faut indiquer :

Protection des données

Le chat peut recevoir des données de santé, des numéros de compte ou de document, des pièces jointes ou des données de tiers. Il convient d'avertir l'utilisateur de ne pas fournir d'informations inutiles et d'appliquer des filtres et une minimisation dès la conception même du système.

Il est nécessaire d'analyser :

Un bot doit reconnaître les demandes d'exercice de droits, ou les orienter vers une personne, et ne doit plus envoyer de communications commerciales après qu'un utilisateur s'y est opposé.

Connaissances et RAG

Les réponses doivent s'appuyer sur des sources faisant autorité, avec une date et une version identifiables. En l'absence de preuve à l'appui, le système doit s'abstenir de répondre.

Il est indispensable de séparer le contenu public, les contrats et les données de chaque client, et d'appliquer les permissions correspondantes avant toute récupération d'information, et non après.

Authentification

Avant d'afficher le statut d'un dossier ou d'exécuter un changement, l'identité de l'interlocuteur doit être vérifiée avec des facteurs proportionnés au risque. Connaître un nom ou un numéro de commande ne constitue pas toujours une preuve suffisante.

L'authentification n'est pas déléguée au modèle de langage : c'est le système d'identité de l'entreprise qui fournit le contexte déjà autorisé.

Outils

Chaque outil mis à la disposition du système doit définir :

Consulter une commande, modifier une adresse et traiter un remboursement sont des capacités distinctes et doivent être traitées comme telles.

Escalade humaine

L'escalade vers une personne doit être déclenchée par :

La personne qui prend le dossier en charge doit disposer d'un résumé, des données déjà confirmées et des étapes déjà effectuées. Le client ne doit pas avoir à répéter toute la conversation.

Qualité

Les indicateurs doivent couvrir plusieurs niveaux :

Niveau Indicateur
Résolution Dossier résolu correctement
Fidélité Réponse appuyée par une source
Sécurité Données ou actions interdites évitées
Expérience Abandon et escalade
Exploitation Latence et disponibilité
Activité Coût par dossier valide

Le « déflection » — le pourcentage de dossiers qui n'atteignent jamais une personne — n'est pas un succès en soi s'il masque la frustration du client ou des réponses incorrectes.

Jeu de test

Avant de mettre en production une architecture, il convient de la valider face à un jeu de test comprenant :

Sécurité

Les menaces les plus pertinentes sur ces systèmes incluent :

Face à ces menaces, on applique des limites de fréquence, une validation des entrées, des permissions par outil et une surveillance continue. Le texte d'instructions (prompt) lui-même ne constitue pas un contrôle de sécurité suffisant.

Copilote pour les agents humains

C'est généralement la première étape la plus sûre pour introduire l'IA dans la relation client. Il peut résumer la conversation, trouver la bonne source et préparer une réponse, mais c'est la personne qui la relit avant de l'envoyer.

Il faut mesurer aussi bien la justesse de ses propositions que le degré de dépendance de l'équipe à leur égard. L'équipe doit toujours conserver la possibilité de ne pas suivre le copilote.

Plan sur 90 jours

Jours 1 à 30

Définition des intentions, des risques, des sources de connaissance et de la ligne de base de départ.

Jours 31 à 60

Construction du chatbot ou du copilote, tests, revue de la confidentialité et conception de l'escalade.

Jours 61 à 90

Pilote en production, mesure des indicateurs et activation d'actions limitées.

Erreurs fréquentes

  1. Choisir l'architecture « agent » par effet de mode, sans la justifier par le risque réel.
  2. Ne pas disposer d'un catalogue d'intentions.
  3. Dissimuler qu'il s'agit d'un système d'IA.
  4. Demander des données excessives à l'utilisateur.
  5. Répondre sans sources pour étayer l'information.
  6. N'authentifier qu'à partir de ce qui est dit dans la conversation.
  7. Accorder trop d'outils au système.
  8. Ne pas prévoir l'escalade vers une personne.
  9. Ne mesurer que la contention des dossiers, pas leur résolution réelle.
  10. Conserver les conversations sans durée de conservation définie.

Checklist

Questions fréquentes

Chatbot ou agent ?

Commencez par un chatbot avec RAG ou par un copilote. Réservez l'agent aux seules actions limitées et réversibles.

Faut-il indiquer qu'il s'agit d'IA ?

Oui, dans les cas prévus par l'article 50 de l'AI Act, sauf si cela est évident, et toujours de façon claire.

Peut-il traiter les réclamations ?

Il peut les recevoir et les classer, mais les cas complexes nécessitent l'intervention d'une personne et une traçabilité complète.

Summum IA peut concevoir l'architecture, le système RAG, les outils, l'évaluation et l'escalade du canal de relation client.