Une IA de service client avec une traçabilité vérifiable, pas une belle démo

Imaginez un samedi à onze heures du soir. Un client écrit à l'assistant de son assureur, de sa banque ou de son magasin : « Mon paiement a-t-il été appliqué ? Je vois un prélèvement que je ne reconnais pas ». L'assistant répond avec amabilité, dans une belle rédaction et avec une parfaite assurance : « Votre paiement est en cours de traitement, ne vous inquiétez pas ». Il n'a pas consulté le système de recouvrement, parce qu'il n'y a pas accès. Il a répondu avec ce qu'il savait du sujet en général. Le lundi, le client appelle son conseiller et répète tout depuis le début.

Cette scène n'est pas une défaillance du modèle de langage ; elle illustre un risque de conception : un assistant peut répondre avec aisance et pourtant ne pas disposer de l'accès, de la permission ou du contexte nécessaires pour résoudre un cas réel. Une démonstration, avec son scénario propre, laisse rarement voir ce risque.

Cet article s'adresse à celui ou celle qui répond du service client, des opérations, de la technologie ou de la conformité dans une banque, une fintech, un assureur, une chaîne de distribution ou une entreprise réglementée. Il défend une idée : un assistant d' IA qui répond à toute heure peut résoudre, avec contrôle, lorsqu'au moins cinq capacités existent avant de l'activer, et si vous pouvez montrer à un auditeur ou à un client ce qu'il a fait, avec quelle donnée et pourquoi.

Pourquoi les assistants restent à l'état de démo

Une démonstration fonctionne parce que le scénario est propre : un client de test, trois questions répétées, aucun système réel en jeu. Ce qui se passe ensuite, dans une activité qui a accumulé des décennies de systèmes, a deux façons fréquentes d'échouer.

La première : l'assistant ne touche pas aux systèmes réels. Il répond sur les politiques, les horaires et les questions fréquentes, mais il ne peut pas consulter un solde, un statut de sinistre, une police ou une commande. Quand le client demande des nouvelles de son dossier, l'assistant ne peut que s'excuser ou le transférer. Il devient un moteur de recherche de questions fréquentes avec une belle diction.

La seconde est plus dangereuse : il touche aux systèmes, mais sans contrôle. Quelqu'un lui remet un utilisateur générique avec de larges permissions « pour que cela fonctionne », ou branche un accès temporaire qui reste pour toujours. L'assistant peut désormais consulter et agir, mais personne ne peut dire avec précision à quelles données il a accédé, au nom de qui, ni qui a autorisé cette action. Dans une démonstration, cela ne se voit pas. Dans une plainte devant l'autorité, si.

La donnée du marché va dans le même sens, avec une réserve de méthode. Donnée de Gartner : dans une enquête auprès de 5 728 clients réalisée en décembre 2023, Gartner a rapporté que seulement 14 % des problèmes de service client et de support étaient entièrement résolus en libre-service ; pour ceux que les clients décrivaient comme « très simples », le chiffre était de 36 % [3]. C'est une enquête auprès de consommateurs, pas une base de référence pour le Mexique ni pour un secteur précis ; utilisez-la comme un signal. Ce chiffre distingue répondre de résoudre ; il ne démontre pas à lui seul la cause de chaque échec. Pour les cas qui exigent de consulter une information à jour ou de lancer une démarche, le comité doit vérifier quelles données et quelles actions sont autorisées pour l'assistant.

Ce dont a besoin un assistant qui résout vraiment

Lorsqu'un assistant cesse d'être une démonstration et commence à opérer, il a besoin de cinq capacités. Quatre sont techniques et une relève du processus.

1. Identité : savoir à qui il parle et au nom de qui il agit

Avant d'afficher une donnée, l'assistant doit savoir que celui qui écrit est bien qui il dit être, et avec quel niveau de confiance. Le niveau de confiance n'est pas déterminé par le canal seul : il doit se définir selon les signaux disponibles et le risque de l'action. Une conversation ouverte sur WhatsApp n'équivaut pas automatiquement à une session authentifiée avec les contrôles que définit votre organisation. La règle utile est que l'assistant n'élève pas de lui-même le niveau de confiance : si la demande porte sur un solde ou un changement de données, il demande une vérification proportionnée au risque, et si elle n'aboutit pas, il n'avance pas. Cela vaut aussi dans l'autre sens : l'assistant lui-même doit avoir sa propre identité dans vos systèmes, et non l'identifiant partagé d'une personne.

2. Permissions : le minimum, pour le concret

Un assistant de service client n'a pas besoin d'accéder à tout le système ; il a besoin de consulter le statut d'une opération du client déjà identifié, et peut-être d'engager une démarche limitée. Cette différence, entre « peut tout voir » et « peut faire ces trois choses pour ce client », sépare un risque gérable d'un risque qu'un comité des risques aurait du mal à accepter. Chaque action doit être définie à l'avance, avec une portée limitée et, lorsque c'est possible, avec la possibilité d'être annulée.

3. Données du client : uniquement les nécessaires, et sous les yeux de leur titulaire

C'est ici qu'intervient la loi, et on le verra plus bas. L'idée de fond est opérationnelle : plus les données personnelles passent par l' assistant, plus il y a de surface à protéger. Il convient de savoir quelle donnée il consulte, pour quelle finalité, où elle est traitée, quels prestataires interviennent et combien de temps la conversation est conservée.

4. Journal : pouvoir reconstituer n'importe quelle conversation

C'est la capacité la plus sous-estimée et celle qui pèse le plus quand quelque chose tourne mal. Pour chaque interaction importante, il faut pouvoir reconstituer : qui a posé la question et comment il a été vérifié, quelle donnée a été consultée, ce qu'a répondu l'assistant, quelle action il a exécutée, quelle version des instructions et du modèle était active et quand cela s'est produit. Un journal qui ne conserve que le texte de la conversation ne suffit pas ; celui qui sert enregistre aussi ce que l'assistant a fait dans les systèmes. Et il doit être protégé contre toute altération, car un journal que quelqu'un peut modifier n'est pas une preuve.

5. Passage à un humain : sortir à temps, avec le contexte

L'assistant doit savoir quand il ne doit pas continuer : une plainte formelle, un client mécontent, un cas hors de sa portée, un doute qu'il ne peut pas vérifier. Et lors du transfert, la personne doit recevoir le contexte nécessaire et pertinent pour résoudre le cas (ce qui a déjà été vérifié, ce qui a été consulté et l'historique justifiable), pour que le client n'ait pas à se répéter. Un bon passage à un humain n'est pas un échec de l' assistant ; il fait partie du contrôle. Un assistant qui ne passe jamais la main est souvent un assistant qui répond ce qu'il ne sait pas.

Ce que dit la nouvelle loi sur les données personnelles

La Ley Federal de Protección de Datos Personales en Posesión de los Particulares (loi fédérale sur la protection des données personnelles détenues par les particuliers) qui s'applique aujourd'hui est une loi nouvelle : elle a été publiée au Diario Oficial de la Federación (DOF, le journal officiel mexicain) le 20 mars 2025, a remplacé celle de 2010 et son texte en vigueur comprend une réforme du 14 novembre 2025. L'autorité qui l'applique est désormais la Secretaría Anticorrupción y Buen Gobierno (ministère de la Lutte contre la corruption et du Bon gouvernement) [1]. Cinq points du texte importent à qui exploite un assistant d'IA. Nous les résumons ci-dessous ; leur application à un flux, un canal et un secteur concrets doit être validée avec votre service juridique et de conformité.

• Avis de confidentialité dans les canaux électroniques (art. 16). Lorsque les données sont obtenues par un moyen électronique, l'avis doit être donné sous sa forme simplifiée, avec l'information de base et le site où consulter l'avis intégral. Si des données personnelles sont recueillies par chat ou sur WhatsApp, validez avec votre service juridique comment l'avis simplifié et l'accès à l'avis intégral sont mis à disposition dans ce flux, et prévoyez-les dès le premier contact [1].
• Finalité (art. 11). Le traitement doit se limiter aux finalités de l'avis ; pour une finalité différente, il faut obtenir à nouveau le consentement. Si vous comptez réutiliser des conversations pour entraîner ou améliorer l' assistant, vérifiez si votre avis le prévoit [1].
• Mesures de sécurité et confidentialité (art. 18 et 20). Sont exigées des mesures administratives, techniques et physiques contre la perte, l'altération ou l'accès non autorisé, proportionnées au risque et à la sensibilité des données, ainsi que des contrôles pour que ceux qui interviennent dans le traitement respectent la confidentialité [1]. Les permissions minimales et le journal de la section précédente sont la version pratique de cette exigence.
• Décisions automatisées (art. 26, fraction II). La personne titulaire peut s'opposer, pour un motif légitime, au traitement lorsqu'il est automatisé, lui produit des effets juridiques non désirés ou affecte de manière significative ses intérêts, droits ou libertés, et est destiné à évaluer, sans intervention humaine, certains aspects personnels ou à analyser ou prédire, entre autres, sa situation économique, sa fiabilité ou son comportement ; la loi excepte les cas où le traitement est nécessaire pour respecter une obligation légale [1]. Si le flux peut produire des effets juridiques non désirés ou affecter de manière significative une personne par un traitement automatisé, revoyez le droit d'opposition avec votre service juridique. Définissez aussi, comme contrôle du risque, quelles décisions exigent une révision humaine.
• Droits ARCO et délais (art. 2, fr. VII et VIII ; art. 22 à 31 et 58). La personne titulaire peut demander l'accès, la rectification, la suppression ou l'opposition (droits ARCO). Le responsable doit communiquer sa décision dans un délai maximal de vingt jours à compter de la réception de la demande, et la loi définit les « jours » comme ouvrés ; il peut être prolongé une fois pour une durée égale si les circonstances le justifient. Ne pas donner suite à une demande sans motif fondé constitue une infraction [1]. Il convient que le chat identifie et oriente une éventuelle demande ARCO vers le mécanisme prévu dans l'avis de confidentialité, que l'identité et les exigences soient validées (art. 28) et que la date de réception soit conservée ; et la suppression n'est pas toujours un effacement immédiat, car la loi prévoit une période de blocage (art. 24).

Une note de prudence : la loi renvoie à son Règlement pour plusieurs procédures, et au moment de la rédaction de cet article la compilation de la Chambre des députés ne recensait que le Règlement publié en 2011, pris pour la loi précédente [5]. C'est pourquoi, outre cette loi, confirmez avec votre service juridique le règlement, les dispositions secondaires et la réglementation sectorielle en vigueur à la date où vous lisez ceci ; chacun peut préciser les obligations ci-dessus.

Les plaintes : là où le journal devient une défense

Pour les entités financières qu'énumère l'article 3, fraction IX, de la loi (établissements de crédit, sociétés financières à objet multiple, sociétés financières populaires et communautaires, coopératives d'épargne et de crédit, unions de crédit et institutions de technologie financière), il convient de vérifier si le flux de l'assistant relève de la procédure d'éclaircissement. La Ley para la Transparencia y Ordenamiento de los Servicios Financieros (loi pour la transparence et l'organisation des services financiers, art. 23) dit que, pour les opérations et services conclus par des contrats d'adhésion de masse et jusqu'aux montants maximaux fixés par l'autorité (la CONDUSEF), lorsqu'un client n'est pas d'accord avec un mouvement, il peut présenter une demande d'éclaircissement dans les quatre-vingt-dix jours calendaires à compter de la date d'arrêté ou, le cas échéant, de l'opération ou du service ; que l'entité doit accuser réception, et qu'une fois la demande reçue, elle dispose d'un maximum de quarante- cinq jours pour remettre au client un dictamen avec copie des preuves prises en compte et un rapport détaillé qui réponde à tous les faits exposés [2]. La liste des entités financières de cette loi n'inclut pas les assureurs : si vous êtes un assureur, votre circuit de plaintes est fixé par la Ley de Protección y Defensa al Usuario de Servicios Financieros (son art. 50 Bis impose à chaque institution financière, assureurs compris, une unité spécialisée pour les demandes et réclamations, qui doit les recevoir par tout moyen facilitant leur réception et répondre par écrit dans un délai qui n'excède pas trente jours ouvrables) et par la réglementation de l'assurance [4]. Les nuances de chaque type de plainte et de chaque autorité figurent dans la réglementation sectorielle ; il convient que votre service de conformité les confirme.

Ce qui importe ici pour un assistant est une conséquence pratique. Tout message de chat ne constitue pas, en soi, une demande d'éclaircissement formelle. Si le canal est habilité à la recevoir, ou si le flux identifie et oriente la demande, la conversation peut faire partie du dossier et conserver des preuves utiles. Si l'assistant a dit quelque chose d'incorrect, ou si le client l'a dit et que personne ne l'a enregistré, l'institution arrive au dictamen sans preuve. Un journal complet et consultable transforme cette conversation en un élément pour répondre ; un journal qui n'existe pas la transforme en vide.

C'est pourquoi la question du comité n'est pas « combien de contacts l'assistant absorbe-t-il ? ». C'est : que se passe-t-il quand un contact devient une plainte ? Les dispositions de la CONDUSEF sur les unités spécialisées exigent déjà, quel que soit le moyen de réception, électronique compris, d'accuser réception, d'attribuer un numéro de dossier et d'indiquer le délai de réponse, et de tenir les antécédents à la disposition de la Commission pendant deux ans [6]. Ces dispositions exigent l'accusé de réception, un numéro de dossier et un délai de réponse, ainsi que la conservation des antécédents et des décisions pendant deux ans. Le reste est un objectif interne de service, qu'il convient de fixer et de tester dans des exercices de contrôle : qu'elle soit enregistrée avec un numéro, une date et une heure, qu'elle passe à la bonne personne sans perdre ce qui a été dit et que quelqu'un puisse la retrouver en minutes, non en jours. Cela pèse autant que n'importe quel pourcentage d'absorption.

Scénario (illustratif ; ne correspond à aucun client réel. Les délais de plainte en assurance sont fixés par une autre réglementation ; le principe, arriver au dossier avec des preuves, est le même). Un assureur de taille moyenne habilite un assistant à informer sur le statut des sinistres par WhatsApp. Un assuré demande des nouvelles de sa réclamation et reçoit « en cours d'examen, sans pièce manquante ». Deux semaines plus tard, il dépose une plainte : il dit qu'on lui a demandé un document et que personne ne le lui a communiqué. Si l'assureur peut reconstituer quel statut l'assistant a consulté, à quelle heure et avec quelle réponse, il dispose d'éléments pour confronter le cas et étayer sa réponse. S'il ne conserve qu'un résumé générique, le dossier dépend de la mémoire de l'assuré et de celle de son conseiller.

Cinq questions pour votre prochain comité

1. Avec quelle identité notre assistant agit-il dans chaque système ? Si c'est un compte partagé ou doté de larges permissions, le premier constat est déjà fait.
2. Pouvons-nous reconstituer, en minutes, n'importe quelle conversation ? Avec qui il a parlé, quelle donnée il a consultée, quelle action il a faite, quelle version était active. Essayez avec une conversation choisie au hasard.
3. Où résident les données personnelles qui passent par l'assistant et quels prestataires interviennent ? Notre avis de confidentialité couvre-t-il cette finalité ? Chaque prestataire agit-il comme sous-traitant ou comme tiers, et est-ce documenté ? Comment détecterions-nous et notifierions-nous une atteinte à la sécurité (art. 19) ?
4. Quand une conversation devient une plainte ou une demande ARCO, qui la reçoit, avec quel numéro et en combien de temps ? Comment arrive-t-elle avec tout son contexte ?
5. Si l'assistant donne une information erronée, qui répond, comment est-elle corrigée et comment cela est-il documenté ?

Plus les réponses « je ne sais pas » sont nombreuses, plus il est probable qu'il ne manque pas un meilleur modèle, mais de connecter et de gouverner ce qui existe déjà.

Avant d'approuver un cas d'usage

Pour comparer des propositions, demandez des preuves pour le cas précis que vous voulez activer : les données et les prestataires concernés ; les actions permises et celles exclues ; un échantillon du journal et du passage à une personne ; le responsable métier ; et le critère d'acceptation. Ainsi le comité compare la portée, le risque et les preuves, pas seulement une démonstration.

Par où commencer cette semaine

Nul besoin de lancer un projet de grande ampleur. Choisissez une conversation échantillon dont l'accès est autorisé et contrôlé, idéalement avec les données minimisées, et demandez à votre équipe de reconstituer, sur papier, ces cinq éléments : comment la personne a été vérifiée, quel système a été consulté et avec quelle permission, ce qu'a répondu l'assistant, où cela a été enregistré et qui l'aurait appris s'il s'était agi d'une plainte. Documentez les lacunes constatées et hiérarchisez-les selon le risque : ce qui ne peut pas être reconstitué vous indique par où commencer.

Faites le même exercice avec une conversation que l'assistant a transmise à une personne : tout le contexte est-il arrivé ?

Ce que fait Hábil

Hábil travaille précisément là où un assistant cesse d'être une démonstration : connecter l'IA aux systèmes qui fonctionnent déjà, avec identité, permissions limitées, enregistrement de ce qu'elle fait et passage à une personne quand il le faut. Hábil AI est l'offre qui connecte des capacités d'IA aux systèmes de l'organisation ; Nova est l'assistant virtuel orienté service client. Lorsque le cas exige un traitement sur une infrastructure sous le contrôle de votre organisation, la portée, les prestataires et les contrôles doivent être définis pour ce cas. Pour décider qui accède à chaque système, voyez Maîtriser les accès ; pour unir vos canaux et vos systèmes, Unifier votre activité et vos canaux.

La première conversation de diagnostic est sans frais : vous en repartez avec une première lecture de la carte de vos intégrations et des points où l'on perd probablement de l'argent, du temps ou des preuves. Écrivez-nous sur WhatsApp.