Déboguez avec des hypothèses vérifiables

Décrivez la défaillance avant de proposer une correction

Une demande de débogage utile précise le comportement attendu, le comportement observé et le périmètre affecté. Incluez la version, l’entrée pertinente et l’erreur. Retirez des logs les identifiants secrets et les enregistrements privés avant de les fournir à un outil d’IA.

« L’export ne marche pas » donne peu d’indications. Une meilleure description serait : « L’export réussit localement. En staging, la même requête de manager renvoie 403 depuis le dernier déploiement. Les autres routes fonctionnent encore. »

Cette description n’établit pas la cause. Elle identifie des différences qui peuvent guider l’investigation.

Gardez plusieurs explications possibles

Demandez à l’agent quelques causes plausibles et les preuves de chacune. Ne lui demandez pas de s’en tenir à la première explication convaincante.

Pour cet échec d’export fictif, les causes possibles comprennent une permission manquante de l’identité de service, une modification de la correspondance des rôles ou une requête envoyée au mauvais environnement. Chaque explication prédit des observations différentes.

Le tableau est un point de départ. Une réponse 403 peut provenir de différentes couches. Identifiez le composant qui l’a produite avant de supposer un échec de l’autorisation applicative.

Choisissez une observation sûre

Commencez par une observation qui départage les explications à faible coût. Comparez la version déployée et la configuration non secrète. Inspectez l’erreur pertinente et l’identifiant de requête. Reproduisez si possible le problème dans un environnement de test autorisé.

N’accordez pas des permissions étendues simplement pour voir si l’erreur disparaît. Cela change la limite de sécurité et peut masquer la permission réellement manquante. Ne collez pas un log complet de production dans le modèle lorsqu’une erreur expurgée et le chemin de requête suffisent.

Précisez ce qui affaiblirait chaque hypothèse. Cela aide l’agent à réviser son explication plutôt qu’à défendre sa première réponse.

Corrigez une cause à la fois

Lorsque les preuves désignent une cause probable, faites une correction ciblée. Évitez de combiner un changement de permissions, une mise à jour de bibliothèque et une réécriture du gestionnaire. Si le symptôme disparaissait, vous ne sauriez pas quelle modification a compté.

Vérifiez la condition de défaillance initiale. Contrôlez aussi la limite voisine. Si vous corrigez l’accès d’un manager, confirmez qu’un utilisateur non autorisé reçoit toujours un refus.

Pour un défaut récurrent, ajoutez un contrôle de régression à la couche capable de le détecter. Un test unitaire ne détecte pas toutes les erreurs de configuration de déploiement. Certaines défaillances exigent un contrôle d’intégration ou une vérification contrôlée après déploiement.

Arrêtez les tentatives sans nouvelles preuves

Un agent peut générer de nombreuses variantes d’une correction. Davantage de tentatives n’améliore pas nécessairement le diagnostic. Si le même échec se répète, demandez quelle observation nouvelle apportera la tentative suivante.

Fixez une limite de temps ou de tentatives pour une investigation incertaine. À cette limite, rapportez les preuves actuelles, les hypothèses rejetées et la question non résolue. Cette trace permettra à une autre personne de continuer sans répéter les mêmes expériences.

Après rétablissement, consignez la cause et la condition qui a permis au défaut d’atteindre l’environnement affecté. Une correction retire le défaut immédiat. Un suivi utile réduit le risque de récidive.