Déboguer des problèmes de production depuis votre téléphone

Il est 19h un vendredi. Vous dînez avec des amis quand votre téléphone vibre avec une alerte PagerDuty : le taux d'erreur de votre service de paiement a grimpé à 15%. Votre ordinateur portable est chez vous. Vos coéquipiers sont hors ligne. L'incident est le vôtre.

Ce scénario est la raison d'être de Tactic Remote. Ce tutoriel parcourt un workflow réaliste de débogage en production en utilisant uniquement votre iPhone, démontrant comment investiguer, diagnostiquer et corriger des problèmes de production à distance.

Configuration du scénario

Pour ce tutoriel, nous travaillerons avec un scénario réaliste :

• Service : API de traitement de paiements Node.js
• Symptôme : Erreurs 500 sur le endpoint /api/payments/process
• Impact : 15% des tentatives de paiement échouent
• Environnement : Logs de production disponibles via SSH, base de code sur votre Mac

Votre Mac est allumé chez vous, exécutant l'application compagnon Tactic Remote. Vous vous connectez depuis votre iPhone et commencez l'investigation.

Phase 1 : Triage (5 minutes)

Le premier objectif est de comprendre la portée et l'urgence. Lancez une session Claude Code pointant vers votre répertoire de projet :

We have a production incident. The /api/payments/process endpoint
is returning 500 errors for ~15% of requests. This started approximately
30 minutes ago.

Help me investigate:
1. Check the git log for any recent deployments (last 24 hours)
2. Look at the payment processing code in src/api/payments/
3. Check if there were any dependency updates recently

Claude Code examinera le code et les changements récents. Pendant ce temps, ouvrez votre tableau de bord de monitoring dans le navigateur de votre téléphone pour vérifier :

• Le taux d'erreur est-il stable, en hausse ou en baisse ?
• Toutes les instances sont-elles affectées ou seulement certaines ?
• Y a-t-il un pattern dans les requêtes échouées ?

Ce que Claude Code pourrait trouver : Un commit d'il y a 3 heures a mis à jour la dépendance Stripe SDK de v12.1.0 à v13.0.0, qui incluait des changements d'API incompatibles.

Phase 2 : Diagnostic (10 minutes)

Avec une hypothèse (la mise à jour du SDK Stripe), creusez plus profond :

Compare the Stripe SDK v12 and v13 changelog.
Check our payment processing code for any API calls that changed
between versions. Focus on the payment intent creation and
confirmation flow in src/api/payments/processor.ts.

Claude Code analysera le code et identifiera les incompatibilités spécifiques. Un résultat typique :

Found the issue. In Stripe SDK v13, the `payment_intents.create()` method
changed its error handling behavior:

- v12: Returns { error: { type, message } } for card declines
- v13: Throws StripeCardError exception for card declines

Our code in processor.ts:45-52 checks for `result.error` but doesn't
catch the new exception type. When a card is declined, the uncaught
exception propagates as a 500 error.

This explains the 15% error rate — approximately 15% of payment
attempts involve card declines (expired cards, insufficient funds, etc.)
that now throw uncaught exceptions.

Ce diagnostic est spécifique, vérifiable et explique le comportement observé. Depuis votre téléphone, vous pouvez vérifier qu'il est cohérent avant de continuer.

Phase 3 : Correction (10 minutes)

Maintenant, implémentez la correction. Vous avez deux options :

Option A : Rollback rapide

Si la situation est urgente et la version précédente était stable :

Revert the Stripe SDK update. Change package.json to pin
stripe at v12.1.0. Create a commit with message:
"hotfix: revert Stripe SDK to v12 (fixes payment 500 errors)"

Étape d'approbation : Claude Code demandera l'approbation pour modifier package.json et exécuter npm install. Vérifiez les changements et approuvez.

Option B : Correction en avant

Si vous voulez corriger le code pour fonctionner avec v13 (évitant un revert qui perd d'autres améliorations) :

Fix the payment processing code to handle both the legacy error
response format and the new exception-based error handling in
Stripe SDK v13.

Specifically:
1. Wrap the payment_intents.create() call in a try/catch
2. Catch StripeCardError and convert it to our standard error format
3. Keep the existing result.error check as a fallback
4. Add a test case for the card decline scenario

Commit with: "hotfix: handle Stripe v13 exception-based card decline errors"

Claude Code fera les modifications et exécutera les tests. Surveillez la vue terminal pour les résultats.

Flux d'approbation : Vous verrez probablement plusieurs demandes d'approbation :

1. Modifier src/api/payments/processor.ts — Approuver (c'est la correction)
2. Modifier src/api/payments/__tests__/processor.test.ts — Approuver (ajout du test)
3. Exécuter npm test — Approuver (vérifier la correction)

Phase 4 : Déploiement (5 minutes)

Avec la correction committée et testée :

Push this commit to the main branch.
Then trigger the deployment pipeline by running our deploy script:
./scripts/deploy.sh production

Approbation critique : Claude Code demandera l'approbation pour la commande de déploiement. C'est l'action la plus risquée du workflow. Vérifiez soigneusement :

• Vérifiez que le message de commit correspond à votre correction
• Confirmez que la cible de déploiement est correcte (production)
• Assurez-vous que les tests ont réussi à l'étape précédente

Après approbation, Claude Code exécute le déploiement. Surveillez la sortie terminal.

Phase 5 : Vérification (5 minutes)

Après la fin du déploiement :

Check the deployment status. Then help me verify:
1. Run a test request against the production payment endpoint
2. Check if the error rate has started decreasing
3. Look for any new error patterns in the last 5 minutes

Simultanément, vérifiez votre tableau de bord de monitoring. Le taux d'erreur devrait commencer à baisser dans les minutes suivant la fin du déploiement.

Post-incident : Rédiger le rapport

Tant que l'incident est frais en mémoire (toujours au dîner, entre les plats) :

Write a post-incident report based on our investigation:

Include:
- Timeline of events
- Root cause (Stripe SDK v13 breaking change)
- Impact (15% payment failure rate for ~1 hour)
- Resolution (code fix to handle new exception type)
- Action items to prevent recurrence

Format as a markdown document in docs/incidents/

Cela donne à votre équipe un rapport d'incident complet avant lundi matin. Vos compagnons de table ont à peine remarqué l'interruption.

Conseils pour un débogage à distance efficace

Commencez large, puis affinez. Ne sautez pas immédiatement aux hypothèses. Laissez Claude Code explorer le paysage (changements récents, patterns d'erreur, état du système) avant de vous concentrer sur une cause spécifique.

Utilisez les portes d'approbation comme points de contrôle. Chaque demande d'approbation est un point de contrôle naturel où vous vérifiez ce que fait Claude Code.

Séparez diagnostic et correction. Obtenez un diagnostic clair et confirmez qu'il est cohérent avant d'implémenter des changements. Cela empêche la « chasse aux corrections » où vous faites des changements sans comprendre la cause racine.

Communiquez pendant le débogage. Si votre équipe a un canal d'incidents, postez des mises à jour depuis votre téléphone :

• « Investigation des erreurs 500 paiements. Suspect : mise à jour SDK Stripe. »
• « Confirmé : SDK v13 a changé la gestion d'erreurs pour les refus de carte. Déploiement du correctif. »
• « Correctif déployé. Taux d'erreur en cours de normalisation. »

Connaissez vos limites. Certains problèmes de production nécessitent un accès à l'infrastructure, des requêtes base de données ou du débogage système qui ne peut pas se faire via Claude Code. Si vous êtes bloqué, escaladez.

Construire votre kit d'outils d'incident

Préparez-vous aux incidents avant qu'ils ne surviennent :

1. Pré-configurez une session de débogage production avec accès à vos scripts de déploiement et outils de monitoring.
2. Créez des prompts de réponse aux incidents dans votre bibliothèque de prompts.
3. Testez le workflow dans une situation non critique.
4. Assurez l'accès Cloudflare Tunnel pour pouvoir déboguer de n'importe où.

Les incidents de production n'attendent pas un moment opportun. Tactic Remote garantit que, où que vous soyez, vous disposez des outils pour répondre efficacement.