Les investigations de support sont avant tout des problèmes de recherche. C'est pourquoi, pendant longtemps, la partie la plus lente de la réponse aux problèmes des clients a été de réunir le bon contexte. En regroupant code, logs, connaissances de l'équipe et conversations passées dans une seule session Cursor, nous avons éliminé ce goulot d'étranglement pour l'essentiel de notre travail.

Aujourd'hui, plus de 75 % des interactions de support chez Cursor passent par Cursor lui-même, ce qui multiplie par 5 à 10 la productivité des ingénieurs du support. Cela a profondément changé ce qu'il est possible de faire pour les ingénieurs du support par rapport à il y a seulement un an.

#À partir de la base de code

Lorsque nous enquêtons, nous commençons généralement en mode Ask. Nous l’orientons vers le symptôme et le laissons remonter jusqu’au comportement pertinent du produit. Comme l’intégralité de notre base de code est disponible localement, Cursor peut indexer et utiliser la recherche sémantique dans le code du produit, la documentation et les outils internes au cours d’une même session.

C’est là que les espaces de travail multi-racines prennent tout leur sens. Le contexte produit s’étend presque toujours sur plusieurs dépôts. Répondre à la question de l’utilisateur, « Pourquoi ce bouton est-il désactivé ? », peut impliquer la logique frontend, des vérifications des règles côté backend et la documentation décrivant le comportement attendu. Nous conservons les dépôts associés dans un même espace de travail afin que ce type de question puisse trouver une réponse dans un seul fil.

#Intégration des sources de support avec MCP

Nous utilisons des serveurs MCP pour récupérer du contexte et l’intégrer à nos investigations. Nos ingénieurs du support n’ont plus besoin de chercher du contexte pertinent dans plusieurs outils pour le récupérer, car il est disponible dans Cursor.

Les serveurs MCP nous permettent d’intégrer :

• Des bases de données contenant des informations sur les clients, comme le niveau d’abonnement, les paramètres de l’équipe et les paramètres de confidentialité
• Des log d’événements en continu contenant des détails sur les services utilisés, les erreurs de télémétrie et les problèmes réseau
• Des plateformes de communication comme Slack, remplies de fils et de conversations qui enrichissent notre compréhension de la manière dont les clients interagissent avec le produit.
• Des plateformes de tickets d’ingénierie regroupant potentiellement des dizaines d’équipes distinctes, chacune avec son propre mode de fonctionnement
• Un service interne de documentation contenant des run books et des guides de dépannage
• Un service de gestion des comptes contenant des informations clients cruciales qui peuvent changer le ton de votre approche d’un client

Avec Cursor et les serveurs MCP, nos ingénieurs du support peuvent rapidement récupérer les informations nécessaires directement dans leurs investigations de la base de code.

#Identifier où la défaillance s’est produite

Lorsqu’un client signale une erreur, nous devons comprendre si le problème qu’il rencontre est reproductible ou ponctuel, et où exactement Cursor a échoué (côté client, au niveau de l’edge API, d’un service en aval ou de l’authentification). Datadog MCP nous permet de récupérer directement les logs et les traces pertinents dans le fil d’investigation, afin de commencer à cerner les causes possibles.

#Retrouver des cas similaires

Lorsqu'un nouveau ticket de support arrive, il est probable que le problème ait déjà été rencontré par un autre client ou par quelqu'un de notre équipe. Un MCP qui s'intègre à votre plateforme de support ainsi qu'à Slack nous permet de rechercher directement dans ce contexte et de faire ressortir les fils les plus pertinents pour l'enquête. Nous recherchons d'abord des identifiants précis (chaînes d'erreur, ID de requête), puis nous élargissons si nécessaire et cherchons le fil le plus récent qui inclut un statut actuel, une solution de contournement et un responsable.

#Déterminer s’il s’agit d’un bug

Bien souvent, les investigations se résument à « bug ou comportement attendu ? ». Notion MCP nous permet d’intégrer le runbook pertinent au fil, de le recouper avec ce que nous observons, puis soit de confirmer le comportement, soit de faire remonter le problème avec un signalement de bug bien plus clair.

#Signaler un bug

Une fois l’investigation terminée dans Cursor, nous avons réuni tous les éléments nécessaires pour créer un ticket pour l’équipe d’ingénierie si une correction est nécessaire. Le MCP Linear nous permet de reprendre tout ce contexte et d’en faire une remontée mise en forme directement depuis le même fil.

#Mises à jour de la documentation

Lorsque plusieurs clients se posent les mêmes questions, c'est souvent le signe que nous devons améliorer notre documentation. Le support technique est particulièrement bien placé pour apporter directement ce type de correctifs. Il nous suffit de mentionner @Cursor dans Slack en indiquant ce qui doit être mis à jour, et un agent cloud ouvrira une PR sur notre dépôt de documentation.

#Automatisation du processus

#Commandes pour les étapes courantes

Nous utilisons des slash commands pour les étapes les plus souvent répétées du workflow :

# Créer un ticket de support
Créer un ticket Linear pour le bug ou le problème utilisateur signalé.

## Format
- **Informations sur l’auteur du signalement :** e-mail, ID de compte, plateforme, version de l’application
- **Résumé :** brève description en 1 à 2 phrases
- **Comportement attendu vs réel :** ce qui devrait se passer vs ce qui se passe
- **Étapes pour reproduire :** liste numérotée

## Notes
- Recueillir les informations utilisateur à partir des logs avant de créer le ticket
- Inclure les ID de requête ou de trace s’ils sont disponibles
- Ajouter un lien vers les requêtes de logs ou les tableaux de bord associés
- Utiliser par défaut la priorité Medium, sauf indication contraire

# Rédiger une réponse au client
Rédiger une réponse au client au sujet de son problème.

## Directives
- Utiliser uniquement le nom public du produit
- Éviter les noms de services internes, les noms de code ou les détails d’infrastructure
- Ne pas partager les codes d’erreur internes, les chemins de fichier ou les variables d’environnement
- S’en tenir aux fonctionnalités documentées publiquement et aux étapes de dépannage standard

## En cas de doute
Demander : « Un client pourrait-il découvrir cela dans le cadre d’une utilisation normale du produit ? »
Sinon, reformuler en utilisant des approches générales de débogage.

# Rechercher des problèmes connus
Rechercher dans Slack pour déterminer si un problème est déjà connu.

## Workflow
1. Rechercher avec des identifiants (ID de ticket, code d’erreur, message d’erreur exact)
2. Affiner par canal et plage horaire
3. Trouver les fils avec des informations sur le statut, une solution de contournement ou un responsable

## Sortie
- **Verdict :** Connu / Peut-être connu / Non trouvé
- **Meilleur fil :** permalien + résumé
- **Recherche suivante :** requête à essayer si les résultats sont faibles

# Rechercher dans les logs
Interroger les logs Datadog pour la requête, l’utilisateur ou l’erreur indiqués.

## Patterns courants
- @requestId:{id} — trouver une requête précise
- @userId:{id} ou @email:{email} — trouver l’activité d’un utilisateur
- status:error — filtrer uniquement les erreurs
- service:{name} — filtrer par service

## Notes
- Toujours spécifier une plage horaire (par défaut : 7 derniers jours)
- Les noms de champ varient selon la source — essayer plusieurs patterns
- Commencer par une recherche large, puis affiner selon les résultats

#Rules et Skills pour les patterns récurrents

Nous utilisons les Rules et les Skills pour automatiser les processus courants lors des investigations de support.

# Skill: Réponse au client (sûre + exploitable)

## Entrées requises
- Symptôme côté client (ce qu'il voit)
- Ce que nous avons trouvé (résumé factuel)
- Étape suivante/solution de contournement (le cas échéant)
- 0–2 informations manquantes à demander

## Format de sortie
- Bref accusé de réception
- Ce que nous avons trouvé (sans détails internes)
- Ce qu'il faut essayer ensuite (étapes numérotées)
- Si nécessaire : deux questions maximum (pour débloquer l'investigation)
- Conclure avec ce que nous allons faire ensuite de notre côté

## Garde-fous
- Éviter les détails d'implémentation internes et le jargon interne
- Préférer des étapes concrètes à la spéculation
- Rester concis ; viser une « première réponse utile »

# Skill: Rédiger un ticket de bug de haute qualité

## Entrées requises
- Symptôme (visible par le client)
- Période concernée
- Tous les identifiants pertinents (ID de requête, ID utilisateur/équipe)
- Extraits d'éléments probants (anonymisés)

## Format de sortie
## Résumé
## Attendu vs réel
## Étapes pour reproduire
## Éléments probants
## Portée/gravité
## Prochaine étape de débogage suggérée

## Niveau de qualité
- Aucun langage vague (« parfois », « ne fonctionne pas ») sans condition concrète
- Aucun jargon exclusivement interne dans le titre
- Masquer les informations spécifiques au client sauf approbation explicite

# Skill: Recherche de problèmes connus (Slack + Notion)

## Entrées requises
- Texte exact de l'erreur (ou la meilleure approximation)
- Mots-clés de la fonctionnalité concernée
- Période concernée (par défaut : 30 derniers jours)

## Workflow
- Rechercher d'abord dans Slack les expressions exactes et les identifiants.
- Si les résultats sont insuffisants, élargir avec des mots-clés de fonctionnalité et des filtres temporels.
- Rechercher dans Notion des runbooks/FAQ pour la même fonctionnalité.

## Format de sortie
- Verdict : connu / possiblement connu / non trouvé
- Meilleur(s) fil(s) : 1 à 3 liens avec une brève explication de leur pertinence
- Solution de contournement / atténuation (si présente)
- Affinage de recherche suivant : requête exacte à exécuter ensuite

#Sous-agents pour exécuter des étapes en parallèle

Les sous-agents permettent d’exécuter en parallèle les étapes courantes du processus de support, plutôt que les unes après les autres.

• LogInvestigator recherche dans Datadog le point de défaillance et les éléments probants associés.
• KnownIssueMiner analyse Slack et Notion à la recherche de discussions antérieures et de solutions de contournement.
• TicketWriter met en forme les éléments recueillis dans un dossier d’escalade complet.
• CustomerReplyDrafter rédige la réponse au client en retirant les détails internes.

Les résultats sont fusionnés en un résultat unique que nous examinons avant de l’envoyer.

supportInvestigationPack:
  goal: >
    Produce a grounded investigation summary, a draft bug ticket,
    and a customer reply by running specialized agents in parallel.
  inputs:
    - customer_symptom
    - time_window
    - identifiers:
        request_id: ""
        user_or_team_id: ""
        error_text: ""
    - investigation_notes
  agents:
    - name: LogInvestigator
      focus: "Datadog: identify the most likely failure point and supporting evidence."
      output:
        - suspected_root_cause
        - strongest_evidence
        - disconfirming_checks
        - open_questions
    - name: KnownIssueMiner
      focus: "Slack/Notion: find prior art, current status, and workaround."
      output:
        - verdict
        - best_links
        - workaround
        - next_search_query
    - name: TicketWriter
      focus: "Write an engineering-facing bug ticket from evidence + notes."
      output:
        - title
        - summary
        - expected_vs_actual
        - steps_to_repro
        - evidence
        - suggested_next_debug_step
    - name: CustomerReplyDrafter
      focus: "Draft a customer reply: clear, safe, and actionable."
      constraints:
        - "Do not include internal implementation details."
        - "Ask for at most two missing data points."
      output:
        - reply_text
        - questions_for_customer
  final_assembler:
    merges:
      - LogInvestigator
      - KnownIssueMiner
      - TicketWriter
      - CustomerReplyDrafter
    produces:
      - investigation_summary
      - ticket_draft
      - customer_reply

#Support technique nativement axé sur l’IA

En combinant ces outils, nous intégrons directement l’investigation du code au processus de support technique. Nous estimons que cela permet à notre équipe d’être jusqu’à dix fois plus productive que les approches traditionnelles, qui nécessitent davantage d’allers-retours entre les outils et les équipes. Ce gain de productivité permet à notre petite équipe d’ingénieurs support (mais en pleine croissance) d’accompagner efficacement notre base d’utilisateurs en forte expansion.

Si vous souhaitez en savoir plus sur la façon d’intégrer Cursor à votre workflow CX, contactez-nous.