Agent IA WhatsApp : organiser les demandes clients

Un client écrit sur WhatsApp : demande de suivi, réclamation, question sur une facture. Sans structure, ces messages s'empilent dans une boîte partagée et le suivi repose sur la mémoire de l'équipe. Un agent IA WhatsApp bien conçu ne remplace pas vos conseillers : il transforme un flux de messages en file de demandes identifiables, catégorisées, datées et transférables. Cette page décrit comment organiser cette file, de la capture de l'identité à la preuve de prise en charge.

Pourquoi structurer la file change tout

Un message WhatsApp brut contient rarement toutes les informations nécessaires pour agir : qui écrit, de quoi il s'agit exactement, depuis quand, avec quelle urgence. Un assistant WhatsApp qui se contente de répondre laisse cette charge d'interprétation à vos équipes, à chaque message.

Structurer la file, c'est décider dès la conception quelles informations chaque demande doit porter avant d'atteindre un humain. L'objectif n'est pas de tout automatiser, mais de garantir qu'aucune demande ne reste floue : chaque élément de la file a une identité, une catégorie, un état et un propriétaire. C'est cette discipline qui rend le transfert humain fiable et la preuve de prise en charge possible.

App WhatsApp ou WhatsApp Business Platform : une distinction à trancher tôt

Avant de parler de file de demandes, il faut choisir le canal technique. L'application WhatsApp Business classique, utilisée sur un téléphone, convient à un usage artisanal : un numéro, quelques réponses rapides, pas d'automatisation sérieuse. La WhatsApp Business Platform, elle, s'appuie sur l'API de Meta et permet de construire un agent IA qui lit, qualifie et route les messages de façon programmatique.

La différence n'est pas cosmétique. Sur la Platform, la fenêtre de service de 24 heures est réouverte par chaque message de l'utilisateur : tant que le client a écrit dans les dernières 24 heures, votre agent peut répondre librement. Au-delà, seuls des modèles approuvés par Meta peuvent être envoyés. Ce cadre conditionne directement la conception de votre file : une demande ouverte depuis trois jours ne peut pas relancer le client par un simple message libre, il faut un modèle approuvé. La conformité, les permissions et les conditions de sortie du canal se vérifient dans les règles officielles de WhatsApp Business, et la tarification de la Platform fonctionne au message livré, par catégorie et par marché — tous les messages ne sont pas payants, notamment les réponses dans la fenêtre de service. Ne bâtissez pas votre modèle économique sur un tarif fixe : vérifiez les catégories applicables à vos marchés.

Attention enfin : un QR code ou un lien de connexion ne prouve pas que vous utilisez la Business Platform officielle. De nombreux outils branchent des numéros sans passer par l'API, ce qui expose à la suspension. De même, ne présumez pas qu'une même entreprise peut faire coexister librement une application Business et une Platform sur le même numéro, ni que des fonctionnalités comme les Flows ou un catalogue sont disponibles dans tous les cas : à vérifier numéro par numéro.

Assistant spécifique entreprise ou assistant généraliste

Un second choix structure votre agent : s'agit-il d'un assistant généraliste qui répond à tout, ou d'un assistant spécifique à votre entreprise, limité à votre périmètre ? Pour organiser une file de demandes, l'assistant spécifique est presque toujours le bon point de départ.

Un assistant généraliste doit improviser sur des sujets qu'il ne maîtrise pas ; un assistant d'entreprise connaît ses catégories, ses règles de transfert et ses limites. Quand un client pose une question hors périmètre, il ne fabrique pas une réponse plausible : il classe la demande comme « hors sujet » et la route. Cette frontière explicite est ce qui rend la file exploitable. Vous pouvez consulter notre guide sur l'assistant IA WhatsApp pour le service client pour approfondir cette distinction, et notre article sur les permissions d'un agent IA pour cadrer ce que l'agent a le droit de faire seul.

Capturer l'identité sans bloquer la conversation

La première donnée de toute demande est l'identité du demandeur. Sur WhatsApp, vous disposez déjà du numéro, mais un numéro ne dit pas qui parle : un même téléphone peut servir à plusieurs personnes, un client peut changer de numéro.

Une conception robuste demande, tôt dans la conversation, une identification légère : nom, référence client ou commande, selon votre activité. L'erreur classique consiste à exiger une identification complète avant toute réponse, ce qui frustre et fait abandonner. Mieux : répondre d'abord utilement, puis demander l'identité au moment où elle devient nécessaire — par exemple avant de consulter un dossier ou de transférer à un conseiller.

Points de conception à retenir :

• Ne jamais considérer le numéro comme une preuve d'identité suffisante pour des actions sensibles.
• Demander l'identité en une seule étape courte, pas en cinq questions successives.
• Conserver l'identité déclarée avec le message d'origine, pas dans une note séparée.

Détecter et gérer la langue

Si vos clients écrivent dans plusieurs langues, la langue doit être une donnée de la file, pas une improvisation du modèle. Un agent IA WhatsApp peut détecter la langue du premier message et l'attacher à la demande : toutes les réponses, tous les transferts et tous les modèles de relance s'alignent ensuite sur cette langue.

Deux précautions. D'abord, la détection automatique se trompe sur les messages courts : « ok », « bonjour », un emoji. Dans le doute, demandez à l'utilisateur de confirmer la langue plutôt que de deviner. Ensuite, le transfert humain doit tenir compte de la langue : router une demande en wolof vers un conseiller qui ne le parle pas crée une rupture pire qu'un délai. Si vous servez des clients entre Paris et Dakar, la langue et le fuseau horaire se traitent ensemble — le 20 octobre 2026, 10 h à Paris correspond à 8 h à Dakar, mais le 3 novembre 2026, 10 h à Paris correspond à 9 h à Dakar : un relancier horaire mal calibré réveillera vos clients à l'aube.

Catégoriser les demandes : peu de catégories, bien définies

La catégorisation est le cœur de la file. Une erreur fréquente consiste à multiplier les catégories fines (« problème de livraison international », « problème de livraison national ») jusqu'à ce que ni l'agent ni les équipes ne s'y retrouvent.

Trois à six catégories suffisent généralement au départ, avec des définitions écrites et des exemples. Pour un service après-vente fictif — appelons-le « Atelier Noro », un vendeur d'électroménager — la file pourrait reposer sur quatre catégories :

Catégorie	Exemple de message	Priorité indicative	Destination
Suivi de commande	« Où en est ma commande ? »	Basse	Réponse automatique avec statut
Panne / SAV	« Mon lave-linge fuit »	Haute	Transfert conseiller + création de ticket
Facturation	« J'ai été débité deux fois »	Haute	Transfert conseiller
Hors sujet	« Vous vendez des vélos ? »	Basse	Réponse courte, pas de ticket

Chaque catégorie définit aussi ce que l'agent a le droit de faire seul : répondre, demander une pièce, ou transférer. Cette matrice décisionnelle évite le piège inverse — un agent qui transfère tout — et celui de l'agent qui répond au-delà de son périmètre. Notre guide sur les bots WhatsApp Business, menus et parcours détaille comment structurer ces parcours sans enfermer l'utilisateur dans un menu rigide.

Donner un état à chaque demande

Une demande sans état est une demande perdue. À minima, chaque élément de la file porte un état parmi : nouveau, en cours de qualification, en attente client, transféré à un humain, résolu, clos. Le passage d'un état à l'autre doit être déclenché par des événements précis, pas par une impression.

Par exemple, une demande passe en « en attente client » quand l'agent a posé une question dont la réponse bloque la suite, et revient en « nouveau » quand le client répond. Elle passe en « transféré » au moment où un conseiller l'accepte, pas au moment où la notification part. Cette rigueur d'événements est ce qui rend la file auditable : vous pouvez dire, à un instant donné, combien de demandes attendent un humain et depuis combien de temps.

Le transfert humain : une règle, pas une exception

Le transfert à un conseiller est le moment le plus fragile de la chaîne. Un transfert réussi transmet trois choses : le contexte (identité, langue, catégorie, historique de la conversation), l'état (ce que l'agent a déjà fait ou promis), et la raison du transfert. Un conseiller qui reçoit « transfert depuis le bot » sans contexte repart de zéro, et le client doit tout répéter — la panne la plus fréquente et la plus évitable.

Concevez le transfert comme une règle explicite : quelles catégories se transfèrent toujours (une réclamation, par exemple), quels signaux déclenchent un transfert immédiat (un client qui exprime une insatisfaction forte, une demande répétée trois fois — exemple fictif, à calibrer selon votre activité), et que se passe-t-il si aucun conseiller n'est disponible. Notre article sur le transfert humain dans les chatbots de service client traite ce point en détail, y compris la reprise de conversation quand le conseiller clôt.

Preuve de prise en charge : ce que vous devez pouvoir montrer

La preuve de prise en charge répond à une question simple : quand une demande a-t-elle été vue, par qui, et qu'en a été fait ? Ce n'est pas une formalité administrative, c'est ce qui permet de répondre à un client qui dit « personne ne m'a répondu », et d'analyser honnêtement où la file se bouche.

Concrètement, chaque demande devrait permettre de reconstituer :

• l'horodatage du premier message du client et de la première réponse de l'agent ;
• l'identité déclarée et la langue détectée ou confirmée ;
• la catégorie attribuée et, si elle a changé, la raison du changement ;
• les transitions d'état avec leurs horodatages ;
• le transfert éventuel : destinataire, acceptation, clôture.

Un point de vigilance : ces éléments constituent une trace d'activité, pas une conformité automatique. La conservation des données clients obéit à des principes de protection des données que vous devez cadrer — durée, finalité, accès. Les recommandations de conception ci-dessus sont des choix d'ingénierie, pas des obligations légales ni une preuve de conformité.

Procédure : mettre en place la file en cinq étapes

1. Choisir le canal. Tranchez app versus Business Platform. Si vous voulez un agent IA qui qualifie et route, la Platform s'impose ; préparez la connexion du numéro en suivant notre guide de création d'un chatbot WhatsApp et de connexion du numéro, et vérifiez consentement et modèles avant tout envoi sortant.
2. Écrire la matrice. Listez vos catégories, pour chacune : exemple de message, destination, ce que l'agent fait seul, ce qui se transfère. Quatre à six lignes suffisent pour commencer.
3. Définir les états et leurs déclencheurs. Pour chaque transition, écrivez l'événement qui la provoque. Si une transition dépend du jugement d'un humain, notez-le : ce sera un point de friction.
4. Concevoir le transfert. Contexte transmis, règle d'acceptation, comportement en cas d'indisponibilité. Testez-le avec une demande réelle avant la mise en service.
5. Vérifier la preuve. Reprenez une demande passée et reconstituez sa chronologie à partir de votre trace. S'il manque une donnée, c'est une lacune de conception, pas un oubli ponctuel.

Exemple principal commenté : le service après-vente d'Atelier Noro

Scénario entièrement fictif. Mardi 14 h 05, un client écrit : « Bonjour, mon réfrigérateur acheté le mois dernier fait un bruit bizarre et la porte ne ferme plus bien. » L'agent détecte le français, classe en « Panne / SAV » et répond : il s'excuse brièvement, demande la référence de commande et précise qu'un conseiller prendra le relais. Le client répond à 14 h 09 avec sa référence. L'agent passe la demande en « en cours de qualification », attache l'identité déclarée, et transfère à l'équipe SAV avec le contexte complet.

14 h 22, un conseiller accepte : la demande passe en « transféré ». Il propose un créneau d'intervention ; le client répond qu'il préfère le jeudi. La demande passe en « en attente client » le temps de confirmer, puis le conseiller confirme et clôt. Le jeudi suivant, l'agent envoie un modèle approuvé — la fenêtre de 24 heures est depuis longtemps dépassée — pour demander si l'intervention a résolu le problème.

Ce scénario illustre trois décisions. Un, l'agent n'a pas tenté de diagnostiquer la panne : sa matrice prévoit que les pannes se transfèrent toujours, car un mauvais conseil aggraverait la relation. Deux, l'état « en attente client » a évité que la demande soit relancée côté équipe pendant que le client choisissait son créneau. Trois, la relance post-intervention passe par un modèle approuvé, pas par un message libre, parce que la fenêtre de service était fermée. Chaque étape laisse une trace : à la fin, Atelier Noro peut montrer qui a vu la demande, quand, et ce qui a été fait.

Limites et erreurs fréquentes

Trois pièges reviennent systématiquement. Le premier : croire que l'agent IA « comprend » la demande alors qu'il applique une matrice que vous avez écrite. Si vos catégories sont floues, la file le sera. Le deuxième : négliger la tarification au message livré de la Platform. Des relances mal calibrées, envoyées hors fenêtre de service via des modèles, coûtent par message — dans un scénario fictif, une PME qui relance mille clients par mois sans vérifier ses catégories de tarification peut voir sa facture doubler sans que la qualité de service bouge. Le troisième : traiter la preuve de prise en charge comme un export mensuel plutôt que comme une donnée structurée dès la capture.

Enfin, rappelez-vous que la conformité du canal — consentement, modèles approuvés, conditions d'usage — se vérifie dans les règles officielles de WhatsApp Business, et que rien de ce que décrit cette page ne remplace cette vérification.

Questions fréquentes

Faut-il un chatbot WhatsApp avec menus, ou un agent IA en langage libre ?

Les deux approches se combinent. Les menus conviennent aux parcours prévisibles (choisir une catégorie, confirmer un créneau) ; le langage libre convient à la qualification initiale, où le client décrit son problème avec ses mots. L'important est que le résultat alimente la même file structurée, quel que soit le mode d'entrée.

Comment gérer un client qui change de langue en cours de conversation ?

Traitez le changement comme un événement : l'agent confirme la nouvelle langue, met à jour la demande, et les réponses suivantes s'alignent. Si un transfert humain est en cours, prévenez le conseiller plutôt que de changer la langue en silence.

Que faire quand aucun conseiller n'est disponible pour un transfert ?

Prévoyez le cas dès la conception : la demande reste dans la file avec un état explicite (« en attente conseiller »), le client reçoit une réponse honnête sur le délai, et une relance par modèle approuvé peut être programmée si la fenêtre de service se ferme. Ne laissez jamais un transfert échouer en silence.

Le numéro WhatsApp du client suffit-il comme identifiant ?

Non. Le numéro identifie une conversation, pas une personne. Pour toute action qui consulte ou modifie un dossier, demandez une confirmation d'identité légère et conservez-la avec la demande. C'est une règle de conception, pas une obligation légale.

Peut-on démarrer sans la WhatsApp Business Platform ?

Oui, pour tester des parcours simples avec l'application Business, mais sans automatisation fiable ni file structurée côté système. Dès que vous voulez qualifier, router et tracer, la Platform devient nécessaire — et avec elle, la vérification du consentement, des modèles et de la tarification au message livré.

Si vous souhaitez définir une mission pour structurer votre file de demandes WhatsApp, vous pouvez consulter nos offres d'agents sur edeverse.com/fr#agent-offers.