Étude d'un agent IA de service client sur les réseaux sociaux

Mission d'étude. Le livrable a été remis ; la mise en œuvre n'est pas engagée à ce jour. Le client n'est pas cité.

Le contexte

Un commerçant recevant un volume important de demandes clients sur ses réseaux sociaux, avec une personne dédiée à leur traitement.

Une entreprise du commerce de détail, dont la relation client se joue désormais majoritairement sur les réseaux sociaux plutôt que par téléphone ou en boutique — une bascule que beaucoup de commerçants vivent aujourd'hui sans avoir eu le temps d'adapter leur organisation en conséquence.

Le problème à résoudre

Les demandes arrivaient sur quatre canaux : Facebook, Instagram, TikTok et WhatsApp. Chacun avec sa boîte de réception, ses notifications, son rythme.

Toutes étaient traitées à la main par la personne en charge. Le problème n'était pas la difficulté des questions — c'était leur répétitivité combinée à leur coût de traitement :

« est-ce que vous avez encore ce modèle ? » → il faut aller vérifier le stock ;
« je peux le rendre si ça ne me convient pas ? » → il faut connaître la règle de retour applicable ;
« c'est garanti combien de temps ? » → il faut connaître les conditions de garantie du produit.

Chaque réponse est simple, mais chacune impose un aller-retour vers le système d'information. Multiplié par le volume, sur quatre canaux, cela occupe une personne à temps plein sur une tâche qui n'exige aucune décision.

C'est un profil de charge caractéristique des tâches candidates à l'automatisation : un volume soutenu, une variété de formulations pour un nombre restreint de questions réelles, et une personne mobilisée en continu sur des réponses qui n'exigent, au fond, aucun jugement.

L'approche étudiée

Un agent connecté au SI, pas un chatbot à réponses figées

C'est le point central de l'étude. Un chatbot classique avec des réponses pré-écrites ne résout rien ici : les questions portent sur des données qui changent — un stock, une règle applicable à un produit précis, une durée de garantie.

L'agent étudié est donc branché sur le système d'information pour consulter :

les stocks et la disponibilité réelle ;
les règles de retour ;
les conditions de garantie.

L'objectif formulé avec le client : répondre comme un employé bien formé. Pas comme une machine qui récite, mais avec la bonne information, au bon niveau de précision, et dans le ton de la marque.

Le point critique de l'étude n'était pas le choix du modèle de langage, mais la faisabilité de ce branchement : quelles données du SI sont réellement exposables sans risque, avec quelle fraîcheur, et avec quelles garanties pour qu'une réponse générée reste toujours alignée sur l'état réel du stock au moment où le client la lit. Un agent qui répond juste à l'instant T mais s'appuie sur une donnée périmée de quelques minutes crée plus de friction qu'il n'en résout.

La semi-automatisation, un choix assumé

Le but n'était pas de retirer l'humain de la boucle mais de lui faire gagner du temps. L'agent absorbe le volume répétitif ; les cas sensibles, ambigus ou commerciaux restent traités par une personne.

La frontière étudiée reposait sur la nature de la question, pas sur sa formulation. Les questions factuelles et vérifiables dans le SI — disponibilité d'un produit, durée de garantie, règle de retour standard — sont traitées directement par l'agent, parce qu'une erreur y est immédiatement détectable et corrigeable. Tout ce qui touche à une réclamation, un geste commercial ou une situation ambiguë est escaladé vers un humain : ce sont des cas où la bonne réponse dépend d'un jugement, pas d'une donnée à consulter, et où une automatisation mal calibrée coûterait plus cher en image qu'elle ne ferait gagner de temps.

Les quatre canaux, très inégaux techniquement

C'est le volet de l'étude qui pèse le plus lourd dans la faisabilité réelle du projet — bien davantage que le choix du modèle de langage, qui est presque un détail d'implémentation en comparaison.

Chaque plateforme impose ses propres règles d'accès à la messagerie, et elles ne sont pas de simples nuances techniques : elles déterminent directement ce qu'un agent peut faire ou non.

WhatsApp Business fonctionne sur une logique de fenêtre de réponse : une fois qu'un client a écrit, l'entreprise dispose d'un délai limité pour répondre librement. Passé ce délai, toute nouvelle prise de contact doit passer par un modèle de message pré-validé par Meta. Un agent conçu pour ce canal doit donc composer avec cette contrainte de temporalité, pas seulement avec le contenu de la conversation.
Messenger et Instagram s'appuient tous les deux sur la Graph API de Meta, avec des règles de messagerie professionnelle proches de celles de WhatsApp mais des politiques d'usage distinctes selon la plateforme, notamment sur ce qui est autorisé en dehors d'une fenêtre de conversation active.
TikTok est de loin le canal le plus limitant pour ce type de projet : l'accès programmatique à la messagerie privée y est beaucoup plus restreint que sur les plateformes Meta, ce qui borne fortement ce qu'un agent peut automatiser sur ce réseau en particulier.

C'est ce paysage de contraintes, canal par canal, qui a structuré l'architecture proposée : un socle de logique commun, connecté au SI, mais avec une couche d'intégration spécifique à chaque plateforme plutôt qu'un connecteur générique — parce qu'un connecteur générique se heurterait immédiatement aux limites du canal le plus contraint.

Le livrable

Une étude est une prestation à part entière, pas une étape gratuite avant un développement — c'est important de le rappeler, parce qu'elle est trop souvent perçue comme un simple préambule commercial. Ce que j'ai remis couvre :

une architecture proposée, détaillant le socle commun et les intégrations spécifiques à chaque canal ;
le périmètre fonctionnel, avec la frontière entre ce que l'agent traite seul et ce qui reste entre les mains d'une personne ;
un chiffrage du projet ;
un phasage de mise en œuvre, pour permettre un déploiement progressif plutôt qu'un big bang sur les quatre canaux à la fois ;
les risques identifiés, notamment ceux liés aux contraintes de chaque plateforme.

Ce livrable donne au client tout ce qu'il faut pour décider, avec ou sans moi, en connaissance de cause plutôt que sur une intuition.

Ce que j'en retiens

Sur ce type de sujet, la valeur ne vient jamais du modèle de langage choisi. Elle vient de la qualité du branchement sur le système d'information et de la compréhension fine des contraintes de chaque canal de diffusion. Un agent conversationnel brillant mais déconnecté des données réelles de l'entreprise est inutile — il donnera de belles réponses, parfois fausses. Un agent plus modeste, mais correctement connecté et respectueux des règles de chaque plateforme, est immédiatement rentable.

Cette mission me rappelle aussi qu'une étude qui ne débouche pas sur un développement n'est pas un échec. Le client dispose aujourd'hui d'une feuille de route claire et chiffrée, qu'il pourra activer quand le moment sera venu — ou ajuster si son contexte change d'ici là. C'est exactement ce qu'une étude de faisabilité est censée produire.