--- title: "Construire un agent de recherche marketing dans Cursor avec Minds MCP" description: "Walkthrough travaillé : construire un agent de recherche marketing custom dans Cursor qui tire de PostHog, fait tourner des panels Minds et poste sur Slack." canonical_url: "https://getminds.ai/blog/fr/build-marketing-research-agent-cursor-minds-mcp" last_updated: "2026-06-22T02:07:00.358Z" --- # Construire un agent de recherche marketing dans Cursor Ce guide est pour quelqu'un qui veut construire un agent de recherche marketing custom plutôt que d'en utiliser un sur étagère. Le résultat final est un agent dans Cursor qui prend un brief de recherche en langage naturel, tire des analytics produit depuis PostHog, lance un panel synthétique avec Minds, croise les deux et poste un résumé sur Slack. Environ 90 minutes de travail de bout en bout si vous avez déjà des comptes sur les trois services. L'idée n'est pas de shipper un produit poli. C'est de rendre la boucle agentique concrète : l'agent reçoit un brief, l'agent appelle plusieurs serveurs MCP en séquence, l'agent raisonne sur le résultat conjoint, l'agent rapporte. Une fois que vous en avez construit un, le pattern compose à n'importe quoi d'autre que vous voulez construire. ## Prérequis Trois comptes et trois clés API : - Un compte Minds avec une clé API (`minds_…`). Inscrivez-vous sur getminds.ai si vous n'en avez pas. - Un compte PostHog avec une clé API personnelle. - Un workspace Slack où vous pouvez poster sur un canal via un webhook ou un app token. Une installation de Cursor (ou n'importe quel éditeur avec support MCP : VS Code avec Copilot fonctionne pareil). Environ 30 minutes de temps de configuration concentré, puis 60 minutes d'itération sur le brief et le prompt de l'agent. ## Étape 1 : connecter les trois serveurs MCP Chacun des trois services expose un serveur MCP. On va connecter les trois à Cursor. Dans Cursor, ouvrez Settings → MCP et ajoutez trois serveurs. *Minds.* Ajoutez un nouveau serveur avec l'URL `https://getminds.ai/mcp` et autorisez via OAuth. Les 12 outils Minds (`create_panel`, `ask_panel`, `export_panel`, etc.) apparaissent dans votre tool picker. La documentation produit commence dans la [vue d’ensemble du serveur Minds MCP](/mcp/overview) ; pour les étapes par client, utilisez le [guide de configuration Minds MCP](/mcp/setup). *PostHog.* PostHog shippe son propre serveur MCP. La configuration recommandée est l'endpoint distant à `https://app.posthog.com/mcp`, également avec OAuth. Vous obtenez 55 outils couvrant événements, funnels, cohorts et dashboards. *Slack.* Le serveur MCP Slack est disponible via npm. Ajoutez-le comme serveur stdio avec `npx -y @modelcontextprotocol/server-slack` et votre Slack bot token dans le env. Deux outils suffisent : `slack_post_message` et `slack_list_channels`. Redémarrez Cursor. Les trois serveurs devraient apparaître dans la liste d'outils de l'agent. Testez chacun en demandant à l'agent de lister les panels (Minds), les cohorts (PostHog) et les channels (Slack). ## Étape 2 : choisir un workflow de recherche qui mérite d'être automatisé L'agent n'est aussi utile que le workflow que vous lui donnez. Choisissez quelque chose de spécifique. L'exemple qu'on va construire : > Prends un nom de feature, trouve les utilisateurs qui ont utilisé la feature dans les 30 derniers jours dans PostHog, caractérise-les comme persona synthétique via Minds, demande à cette persona pourquoi elle recommanderait ou non la feature, et poste un résumé dans #product-research sur Slack. Ce pattern (ancrage avec des données réelles plus enrichissement synthétique plus distribution à l'équipe) est réutilisable à travers de nombreuses décisions. Substituez votre propre. ## Étape 3 : écrire le prompt de l'agent Mettez le prompt de l'agent dans un fichier `.cursorrules` Cursor ou comme system message de votre session d'agent. La structure qui marche : ```text You are a marketing research agent. Your job is to take a feature name as input and return a recommendation summary, posted to Slack. For each request, do the following in order: 1. Use PostHog tools to find users who triggered the feature event in the last 30 days. Get a count and basic properties (plan tier, account age, region). 2. Build a Minds persona that matches the dominant cohort from step 1. Use `create_mind` with a description that captures the cohort's plan tier, tenure, and likely role. 3. Create a panel of three personas matching that profile, using `create_panel` then `ask_panel`. Ask: "Would you recommend this feature to a colleague? Why or why not? What would have to change for it to be a yes?" 4. Cross-reference the panel response against the PostHog data. Look for alignment (do the panel's stated reasons match the actual usage patterns?) and gaps (does the panel surface concerns the metrics don't show?). 5. Post a summary to #product-research in Slack with three sections: - Cohort profile (who used it) - Panel verdict (recommend or not, top stated reasons) - Recommended action (what to do next) Keep the Slack summary under 500 words. Link back to the full panel export. ``` Ce prompt fait trois choses délibérément : - Il ordonne les étapes de manière dure pour que l'agent ne prenne pas de raccourcis. - Il dit à l'agent comment composer les résultats à travers les outils, pas seulement comment les appeler. - Il borne la sortie pour que le message Slack soit effectivement lisible. ## Étape 4 : tester contre une feature réelle Choisissez une feature que votre produit a vraiment shippée. Lancez l'agent. La séquence attendue : 1. L'agent appelle une query `events` PostHog pour `feature_used` filtrée sur le nom de la feature et les 30 derniers jours. Renvoie un compte et un échantillon. 2. L'agent appelle `cohorts` PostHog pour caractériser les utilisateurs. Identifie le plan tier dominant et l'âge moyen de compte. 3. L'agent appelle `create_mind` Minds avec une description de persona comme "Client payant mid-tier, 6 à 18 mois sur la plateforme, utilisateur principal de catégorie de feature ". 4. L'agent appelle `create_panel` Minds avec trois de ces personas. 5. L'agent appelle `ask_panel` Minds avec la question de recommandation. 6. L'agent lit les réponses. Appelle `export_panel` Minds pour sauver la session complète pour le lien Slack. 7. L'agent appelle `slack_post_message` Slack avec le résumé structuré et le lien d'export. Temps de bout en bout : 60 à 120 secondes selon la taille du cohort et la longueur de la réponse du panel. Coût de bout en bout : environ 0,15 dollar en coûts d'appels MCP plus 0,05 dollar en inférence d'agent. Si une étape échoue, l'agent retentera généralement une fois ou pivotera. S'il se coince, la cause la plus commune est un prompt fragile à l'étape 4 (la description de persona ne fitte pas proprement le cohort). Réécrivez la description de persona pour être plus flexible et relancez. ## Étape 5 : le planifier L'agent ne génère de la valeur que s'il tourne sans vous. Deux chemins : *Trigger manuel via Slack.* Ajoutez une commande slash `/research [nom-feature]` qui déclenche l'agent Cursor. C'est le chemin le plus simple et marche pour la recherche ad-hoc. *Trigger cron.* Utilisez un workflow CI (GitHub Actions, automation Linear, n'importe quoi qui peut tourner sur un planning) pour envoyer une liste de noms de features à l'endpoint d'agent chaque lundi. L'agent lance le workflow une fois par feature et poste chaque résumé. L'équipe reçoit un digest de recherche du lundi matin sans overhead humain. Le chemin cron est où la valeur compose. Une équipe qui lance de la recherche au niveau feature sur chaque feature shippée pendant un trimestre apprend plus sur son produit qu'une équipe qui lance une grosse étude par an, et à moins de 5 pour cent du coût. ## Où les agents custom battent ceux sur étagère L'argument pour construire ceci plutôt que d'utiliser un outil de recherche packagé : *Spécificité de workflow.* Les outils sur étagère optimisent pour le cas le plus commun. Le workflow de recherche de votre équipe est rarement le cas le plus commun. Un agent custom fitte exactement votre rythme de décision. *Composition d'outils.* Les mouvements intéressants se passent quand la recherche synthétique est ancrée contre des données produit réelles, puis distribuée dans le canal de votre équipe. Aucun outil sur étagère ne fait la chaîne complète. Un agent custom enchaînant trois MCPs si. *Contrôle de coût.* Vous payez par appel, par service. Pas de licences par siège, pas de frais de plateforme par-dessus. L'usage lourd revient moins cher que les outils packagés à l'échelle d'équipe ; l'usage léger est essentiellement gratuit. *Vélocité d'itération.* Changer le workflow c'est changer le prompt. Pas de roadmap fournisseur, pas de demandes de feature. La contrainte est votre propre attention, pas le cycle de release de quelqu'un d'autre. ## Pièges communs Quelques arêtes vives de faire tourner ça en production : - *Drift de persona à travers les appels.* Si vous créez un nouveau Mind à chaque run, le profil de persona se déplace subtilement à chaque fois. Persistez le Mind une fois (cachez l'ID) et réutilisez-le. Le MCP Minds expose `list_minds` pour exactement ça. - *Timeouts de query PostHog.* Les gros cohorts font timeout l'agent. Cappez la taille du cohort dans le prompt ou pré-filtrez à un échantillon représentatif. - *Limites de taille de message Slack.* Slack tronque les messages au-dessus de 4000 caractères. Le cap de 500 mots dans le prompt est largement en dessous, mais si l'agent l'ignore, postez en thread plutôt qu'en message unique. - *Rotation de tokens OAuth.* Les trois services font tourner les tokens périodiquement. Si l'agent s'arrête soudain de fonctionner, ré-autorisez chaque connecteur avant de débugger le prompt. ## Vers où ça va Le workflow de recommandation single-feature est le point de départ. Une fois qu'il marche, le même agent généralise à : - Boucles hebdomadaires d'efficacité de campagne (lancer des réactions synthétiques aux annonces avant que la campagne ne parte en live, valider contre le click-through réel après) - Positionnement concurrentiel mensuel (lancer des panels synthétiques contre la messagerie du concurrent, croiser contre vos propres données de conversion) - Refresh trimestriel de personas (mettre à jour les personas synthétiques basé sur les déplacements de comportement produit observés) Chacune est la même forme : ancrage avec données réelles, enrichissement synthétique, distribution à l'équipe. Construisez le premier. Le reste sont des variations. Pour plus sur ce qui mérite d'être connecté à côté, voir [les meilleurs serveurs MCP pour les agents marketing et recherche en 2026](/blog/best-mcp-servers-marketing-research-agents-2026). Pour la catégorie sous-jacente, voir [la recherche marché agentique, définie](/blog/agentic-market-research-definition). Pour la question de confiance sur la sortie synthétique, voir [valider la sortie de recherche agentique](/blog/validating-agentic-research-output-eval-frameworks).