Skip to main content

Déboguer un bug de bout en bout à partir d’un rapport

Confiez à Devin un rapport de bug avec des logs Datadog et un accès à la base de données, et obtenez une analyse de la cause racine et une PR de correctif.
AuthorCognition
CategoryRéponse aux incidents
FeaturesMCP
1

Connecter Datadog

Devin a besoin d’accéder à vos journaux Datadog pour rechercher des erreurs liées au bug. Si ce n’est pas déjà fait, activez le MCP Datadog :
  1. Allez dans Settings > MCP Marketplace et recherchez Datadog
  2. Cliquez sur Enable et fournissez deux secrets :
  3. Si votre instance Datadog utilise un site personnalisé (par exemple, datadoghq.eu), définissez également DATADOG_SITE
Une fois connecté, Devin peut rechercher dans les journaux, récupérer des traces d’erreurs et corréler les problèmes avec les déploiements — le tout directement depuis la session. Consultez MCP Marketplace pour tous les détails de configuration.
2

Donnez à Devin un accès en lecture seule à la base de données

Pour les bugs de données — mauvaises valeurs, champs manquants, requêtes défaillantes — Devin est beaucoup plus efficace lorsqu’il peut vérifier directement l’état des données. Fournissez une chaîne de connexion en lecture seule en tant que Secret :
  1. Allez dans Settings > Secrets et ajoutez un nouveau secret :
    • Name : DATABASE_READ_REPLICA_URL
    • Value : postgresql://readonly_user:password@read-replica.internal:5432/production
  2. Ajoutez une note du type : “Connexion en lecture seule à la réplique de lecture de production. À utiliser uniquement pour les requêtes SELECT.”
Vous pouvez aussi connecter une base de données MCP (PostgreSQL, MySQL, etc.) dans Settings > MCP Marketplace — Devin peut utiliser l’une ou l’autre approche pour interroger vos données.
Utilisez toujours une réplique de lecture ou un utilisateur avec des permissions en lecture seule (SELECT uniquement). Devin n’a jamais besoin d’un accès en écriture pour analyser un bug. Si vous êtes préoccupé par l’impact de requêtes coûteuses sur les performances, orientez Devin vers une réplique de lecture dédiée ou une réplique analytique existante, distincte de votre base de données de production.
3

Envoyez le rapport de bogue à Devin

Collez directement le rapport de bug dans une session Devin. Incluez autant de contexte que la personne qui l’a signalé en a fourni — quand le problème a commencé, qui est concerné, ce qui ne va pas et où. Pour une analyse structurée, utilisez le !triage template playbook — dupliquez-le et personnalisez les étapes pour votre stack.Plus le rapport est précis, plus rapidement Devin trouve la réponse. « Since Friday’s deploy » permet à Devin de restreindre la plage temporelle dans Datadog. « Pro plan users » lui indique exactement quels enregistrements interroger.
4

Devin diagnostique et corrige

Avec Datadog et l’accès à la base de données connectés, Devin mène une enquête complète :Récupère les logs Datadog — Recherche des erreurs sur le service de facturation depuis vendredi, en filtrant par nom de service et statut d’erreur. Trouve un pic de TypeError: Cannot read property 'name' of undefined à partir de 18:12 UTC le jour du déploiement.Interroge la base de données — Exécute SELECT id, company_name, plan FROM users WHERE plan = 'pro' LIMIT 20 sur la réplique de lecture. Confirme que les utilisateurs Pro ont bien des valeurs company_name — les données sont correctes, donc le bug vient du code.Retrace la modification de code — Vérifie git log --since="2026-02-13" et trouve le commit a1b2c3d qui a remanié la réponse de l’API utilisateur, en renommant company en organization. La page de facturation à src/pages/billing/BillingHeader.tsx fait encore référence à user.company.name.Écrit la correction — Met à jour BillingHeader.tsx pour utiliser user.organization?.name ?? 'Your Company' et ajoute un test de non-régression qui affiche le composant avec l’ancienne et la nouvelle structure de réponse de l’API.Vérifie dans le navigateur — Démarre le serveur de développement, ouvre la page de facturation dans le navigateur intégré de Devin, et confirme que le nom de l’entreprise s’affiche désormais correctement pour un utilisateur de test.Ouvre une PR avec la correction, le test et une description expliquant la cause première et l’impact (tous les utilisateurs Pro et Enterprise, ~350 comptes).
5

Suivi

Une fois la PR de correction fusionnée, vous pouvez demander à Devin de rechercher les problèmes associés ou d’ajouter de la surveillance :Si vous voulez que Devin se souvienne de quelque chose tiré de cette investigation pour la prochaine fois, dites-le-lui simplement — par exemple : “Souviens-toi que l’API utilisateur utilise user.organization, et non user.company.” Devin proposera une entrée Knowledge que vous pourrez examiner et enregistrer. Ainsi, les sessions futures commenceront avec le contexte que votre équipe a déjà acquis.