Analyser les feedbacks utilisateurs avec l’IA : rendre la connaissance client requêtable

Misha Mirzai, Senior Product Manager chez Kolecto, conçoit des produits à fort enjeu dans des environnements complexes (Core Banking, SaaS B2B, IA). Fort d’une vision entrepreneuriale, il intègre l’IA et le « vibe coding » au Product Management pour accélérer l’innovation, optimiser l’UX et maximiser l’impact business.

A retenir

• L’IA permet d’unifier et d’exploiter la connaissance client (tickets, verbatims, calls sales), traditionnellement fragmentée, en la rendant requêtable par les équipes grâce à des agents autonomes.
• La combinaison technologique du RAG (pour l’exploration sémantique) et du SQL (pour la recherche exhaustive) permet à l’agent de lire et d’analyser les données de façon déterministe, réduisant ainsi drastiquement le risque d’hallucinations.
• La condition de succès principale ne réside pas dans l’IA elle-même, mais dans la structuration en amont de la donnée : il faut cartographier, qualifier et lier les feedbacks aux enjeux business (segments, revenus, etc.).
• Industrialiser ce processus transforme la donnée client en un actif produit durable, permettant de justifier les priorités stratégiques sur des données réelles (ex: croiser un irritant avec le revenu généré) plutôt que sur de simples impressions.

Troisième session du Grand Rattrapage, la série de talks organisée par Converteo et Le Ticket, et un sujet qui a fait réagir : l’exploitation des feedbacks utilisateurs. Romain Deschamps, AI & Product Ops freelance spécialisé dans les workflows agentiques de connaissance client, a mis le doigt sur un paradoxe que presque toutes les organisations connaissent, puis l’a démonté avec trois cas d’usage. Un cas réel (BPI France), un cas fictif pédagogique (Mayflow) pour montrer le détail du setup, et un cas réel avancé (Semji).

Le paradoxe : l’information existe, mais elle est introuvable

Les feedbacks ne manquent pas. Ils sont partout : tickets support, notes CSM, verbatims CSAT, commentaires CES, entretiens utilisateurs, calls sales, CRM, Slack, Notion, Google Sheets. L’information est là, mais fragmentée, et rarement exploitable au bon moment. La conséquence est bien connue des PM : à chaque nouveau sujet, on refait une partie du travail de recherche. On demande autour de soi, on fouille dans les outils, on sollicite les équipes customer-facing, puis on tente de reconstituer une vision fiable. La même archéologie recommence à chaque fois.

Cas 1 – BPI France : de 1 000 commentaires ignorés à des QBR data-driven

BPI France reçoit environ 10 000 réponses à son enquête CES (Customer Effort Score) par mois, dont environ 10 % assortis de commentaires : plus de 1 000 verbatims mensuels, largement sous-exploités. Résultat : lecture manuelle chronophage, vision cloisonnée par squad sans vue transverse pour les heads, et à terme désengagement des utilisateurs qui cessent de donner du feedback faute d’en voir l’effet.

La réponse : un agent construit sur Dust, capable de comprendre la structure de la base de données (noms techniques, IDs des surveys) et de répondre à des questions produit précises. Résultat concret : une quarantaine de sessions Dust par mois côté équipes produit et design, qui permettent de préparer les quarterly business reviews avec des données réelles plutôt que des impressions.

C’est l’occasion d’une définition posée par Fred : un agent, c’est un LLM qui a des « mains », capable d’agir sur des systèmes (aller chercher ou créer de la donnée via MCP), contrairement à un chat qui ne fait que répondre en texte. Deux briques techniques structurent ces agents : le RAG (le texte est vectorisé pour permettre une recherche par proximité sémantique plutôt que par mot-clé exact) et les requêtes SQL générées par le LLM (le modèle comprend l’intention, planifie ses requêtes, lit les schémas de la base, s’auto-corrige et interprète les résultats). À distinguer d’un skill, un fichier texte, généralement en Markdown, qui enseigne une tâche précise à un agent et se réutilise d’un agent à l’autre.

Cas 2 – Mayflow (fictif) : anatomie d’un agent Dust, pas à pas

Pour montrer le détail du setup, Romain a construit en direct l’agent d’un SaaS B2B fictif d’email marketing (3 500 clients répartis en segments Starter / Business / Enterprise), dont les données vivent dans plusieurs sources : feedbacks CSM dans Notion, extract CRM dans un Google Sheet (segment, plan, MRR, usage), réponses CES dans un troisième fichier.

L’anatomie de l’agent révèle la mécanique : un prompt system décrivant le rôle, les outils et le processus (reformuler la question, identifier le périmètre fonctionnel via une table de correspondance, rechercher, analyser, formater), enrichi de garde-fous ajoutés au fil des cas limites ; des tools (SQL sur la base CES, récupération des feedbacks CSM, recherche sémantique) ; et des capabilities (un skill « contexte Mayflow » réutilisable, la génération de « frames », des artefacts HTML, l’appel à un sous-agent, l’accès Analytics).

Trois démonstrations illustrent la montée en puissance : l’évolution du CES sur six mois génère un dashboard HTML complet (tendance, distribution, découpage par segment) ; le croisement des problématiques d’une squad avec l’ARR permet de prioriser selon l’enjeu stratégique et non le seul volume de plaintes ; enfin, un irritant (« trop d’étapes pour construire une campagne ») déclenche une recherche sémantique des verbatims, l’identification d’un client à risque de churn mentionnant un concurrent, puis la rédaction d’un brouillon d’email d’invitation à un test utilisateur pour les comptes Enterprise concernés, jusqu’au message prêt à envoyer.

Cas 3 – Semji : la version industrialisée

Chez Semji (SaaS B2B SEO/GEO), le système passe de 240 à environ 4 000 feedbacks par an en connectant en plus les calls sales et CSM, une source souvent négligée côté acquisition, via l’outil de transcription Fireflies. Le vrai cœur du dispositif est le pipeline data : un webhook déclenché à chaque nouveau call (orchestration via n8n), l’extraction et l’analyse du transcript pour détecter des feedbacks actionnables, l’enrichissement avec les données client depuis BigQuery/CRM, le stockage dans une base vectorielle enrichie en métadonnées (Supabase), puis l’exposition via un serveur MCP custom offrant trois modes de récupération : RAG large, RAG avec re-ranking, et requêtes SQL pour l’exhaustif. Côté Claude, un skill « feedback » appelle ce MCP, parfois plusieurs fois, en combinant RAG et SQL, pour produire une synthèse et un artefact.

L’impact mesuré parle de lui-même : plus de 500 appels MCP le mois précédent, pour seulement 2 PM dans l’équipe. Les verbatims remontent désormais jusque dans les présentations stratégiques du CPO et directement dans les tickets Linear, pour justifier les priorités par des données plutôt que des impressions.

Point notable sur les hallucinations, question posée deux fois en séance : Romain en observe beaucoup moins qu’un an plus tôt, pour deux raisons. Les modèles se sont améliorés, et surtout l’architecture a changé. Le LLM n’est plus utilisé pour générer du texte mais pour lire des données et exécuter des scripts déterministes (du computing plutôt que de la génération), ce qui réduit mécaniquement le risque, sauf quand la donnée source est vide.

La condition de succès : la structuration de la donnée

Le point le plus important de la session est peut-être là : le sujet ne se limite pas à « faire analyser les feedbacks par l’IA ». La véritable condition de succès est la structuration de la donnée en amont. Où vivent les feedbacks ? Comment sont-ils qualifiés ? Quels champs sont nécessaires ? Comment relier les verbatims à des segments clients, des parcours, des produits ou des enjeux business ? Sans cette base, l’IA produit des synthèses intéressantes mais fragiles, qui ne résisteront pas à une décision engageante. Avec elle, elle devient un véritable levier de décision.

C’est aussi ce qui éclaire la complémentarité RAG / SQL : le RAG sert à explorer une problématique et à identifier le vocabulaire et les thèmes pertinents (résultats sémantiquement proches, non exhaustifs) ; le SQL sert ensuite à aller chercher l’exhaustivité une fois les bons termes identifiés.

Pour démarrer, Romain recommande un plan d’action en deux temps : cartographier ses données existantes (où sont-elles, sont-elles accessibles, peut-on les consolider ?), puis identifier les données à créer (quelles sources manquent, par exemple les enregistrements de calls sales, et quelles collaborations engager pour les capter à la source). Son message de conclusion : les organisations sont assises sur une mine d’or de données sous-exploitées, et l’enjeu est la capitalisation dans le temps. Commencer aujourd’hui, c’est disposer de six mois de feedback exploitable dans six mois ; attendre, c’est perdre du feedback et des insights de façon cumulative.

Pourquoi c’est un sujet structurel pour les équipes Product

Ce cas d’usage cristallise l’un des enjeux majeurs du Product Building : le rapport entre IA et data. On mesure souvent la maturité IA d’une organisation au nombre d’outils testés. La session suggère un autre critère, plus exigeant : la capacité à structurer sa connaissance client pour la rendre exploitable. C’est un chantier moins spectaculaire qu’une démo d’agent, mais c’est lui qui fait la différence entre une IA qui impressionne et une IA qui aide réellement à décider. Pour le Product Builder, cela signifie une compétence nouvelle : penser la donnée client comme un actif produit, avec ses schémas, sa qualité et sa gouvernance.