Sept agents IA pour transformer la voix du client en décisions

Les marques reçoivent chaque jour des retours clients dispersés sur des dizaines de canaux : réseaux sociaux, sites e-commerce, enquêtes, e-mails, chatbots. C'est une mine d'information sur les attentes et les frustrations, et elle reste très largement inexploitée faute de pouvoir l'absorber.

Le Challenge Agentic AI Dataiku 2025 portait sur ce sujet. J'en étais lead technique : roadmap, répartition des tâches et arbitrages d'architecture.

Les trois questions à résoudre

• Écouter et analyser la voix du client à grande échelle, de façon fiable et automatisée.
• Mesurer la satisfaction en continu et repérer vite les points de friction.
• Transformer des émotions exprimées en texte libre en leviers d'action opérationnels.

La troisième est la plus difficile. Produire un score de sentiment est à la portée de n'importe quel modèle. Produire quelque chose qu'une équipe SAV peut utiliser lundi matin, beaucoup moins.

L'architecture : sept agents spécialisés

La décision structurante a été de ne pas construire un agent généraliste. Chaque étape du traitement a son propre agent, avec un périmètre étroit et une sortie définie.

Ce découpage n'est pas cosmétique. Un agent qui ne fait qu'une chose peut être évalué sur cette chose, corrigé sans effet de bord, et remplacé si un meilleur modèle arrive. Un agent généraliste ne peut être ni mesuré ni débogué.

Pourquoi pas un seul prompt

La tentation était de tout confier à un appel unique : classification, sentiment, détection d'irritants, rédaction de la réponse. Ça fonctionne, et ça donne une démonstration convaincante en quelques jours.

Le problème apparaît à la première sortie médiocre : impossible de savoir quelle partie a échoué. On se retrouve à modifier un prompt de deux pages en espérant que ça aille mieux, sans rien pouvoir mesurer.

Un agent qui fait sept choses est impossible à déboguer. Sept agents qui font une chose chacun se corrigent un par un.

Traiter les sorties du modèle comme des données douteuses

Chaque sortie passe des contrôles avant d'être intégrée : format attendu, valeurs appartenant à un référentiel connu, cohérence entre le sentiment détecté et la catégorie attribuée. Une sortie qui échoue est isolée, pas silencieusement absorbée par la suite du pipeline.

C'est le même réflexe que sur un pipeline de données classique. Le risque n'est pas l'erreur visible, c'est la sortie plausible et fausse qui traverse toute la chaîne sans rien déclencher.

Orchestration déterministe

Les agents décident quelles analyses lancer selon le contenu reçu et relancent une étape dont la sortie n'a pas passé les contrôles. En revanche, l'enchaînement global reste piloté par le pipeline, pas par un modèle. C'est délibéré : une séquence décidée par un LLM est beaucoup plus difficile à rejouer et à expliquer quand quelque chose se passe mal.

L'API GPT intervient sur les tâches linguistiques, jamais sur l'orchestration.

Ce que ça produit côté métier

Le système alimente un dashboard Voix Client exploitable directement par les équipes. Les usages visés couvraient plusieurs directions.

• Expérience client : identification des points de friction, délais de livraison, qualité produit, service après-vente.
• Réduction du churn : détection automatique des avis négatifs permettant d'agir vite, avant le départ du client.
• Campagnes marketing : adaptation de la communication aux atouts réellement cités par les clients.
• Innovation produit : remontée des causes profondes vers la R&D.
• Gains opérationnels : temps analyste réalloué de la production de reporting vers l'analyse.

Résultat

Workflow livré dans les délais, avec une traçabilité complète du traitement. Il a été conçu dès l'origine pour être supervisé comme n'importe quel autre traitement de production, pas adapté après coup.