Diagnostiquer un bug en production : la méthode que je suis

« Ça marche chez moi. » Cette phrase marque le début d’une catégorie de problèmes particulière : ceux qui n’existent qu’en production, sur des données réelles, avec de vrais utilisateurs.

Ces bugs se traitent mal à l’intuition. Voici l’ordre que je suis, et pourquoi cet ordre compte plus que la compétence technique.

Étape 1 — Établir les faits, sans interpréter

Avant toute hypothèse, je réponds à quatre questions, avec des réponses précises.

Que s’est-il passé exactement ? Pas « la page ne marche pas », mais le message affiché, le code d’erreur, l’écran concerné, l’action déclenchante.

Quand, à la minute près ? C’est l’information la plus précieuse et la plus souvent absente. Elle permet de retrouver la trace dans les journaux en quelques secondes plutôt qu’en une heure.

Pour qui ? Un utilisateur, plusieurs, tous ? Un profil particulier ? Cette réponse oriente immédiatement : si c’est un seul utilisateur, on regarde ses données et ses droits ; si c’est tout le monde, on regarde ce qui a changé.

Depuis quand ? Un bug qui existe depuis toujours et un bug apparu mardi ne se cherchent pas au même endroit.

Cette étape paraît bureaucratique. Elle prend dix minutes et elle divise le temps de résolution par deux, parce qu’elle élimine d’emblée les trois quarts des hypothèses.

Étape 2 — Regarder ce qui a changé

Un système qui fonctionnait et qui ne fonctionne plus a été modifié. Presque toujours.

Je regarde dans cet ordre : les déploiements récents, les changements de configuration, les montées de version d’une dépendance ou du système, et les modifications de données — un import, une reprise, une correction manuelle en base.

Ce dernier point est le plus souvent oublié. Le code n’a pas bougé, donc on cherche dans le code. Alors qu’un enregistrement créé avec une valeur inattendue suffit à faire tomber un traitement qui tournait depuis trois ans.

Un cas particulier mérite d’être cité parce qu’il revient : rien n’a changé chez nous, quelque chose a changé ailleurs. Un service tiers a modifié son format de réponse, un certificat a expiré, une adresse a été redirigée. Le symptôme est interne, la cause est externe.

Étape 3 — Chercher une reproduction, même partielle

Tant qu’un bug ne se reproduit pas, on ne le corrige pas — on suppose l’avoir corrigé, ce qui n’est pas la même chose.

L’objectif n’est pas nécessairement de reproduire le bug complet. C’est de trouver la plus petite condition qui le déclenche. On part du cas réel et on retire des éléments un par un jusqu’à ce que le problème disparaisse ; le dernier élément retiré est la piste.

Quand la reproduction résiste, quatre différences expliquent l’essentiel des écarts entre un poste de développement et la production : le volume de données, la concurrence entre utilisateurs, la configuration — variables d’environnement, fuseau horaire, encodage — et les droits réels de l’utilisateur concerné.

Reproduire avec un compte administrateur alors que le bug touche un utilisateur restreint est l’erreur la plus fréquente de toutes. Je commence désormais par emprunter le profil exact.

Étape 4 — Chercher la cause, pas une explication

C’est ici que la discipline compte le plus.

Le piège est de trouver une explication plausible et de s’arrêter. « C’est probablement un problème de cache. » Peut-être. Mais tant que je n’ai pas montré le mécanisme complet — cette donnée, ce chemin de code, cette condition, ce résultat — je n’ai qu’une histoire.

Le test que je m’impose : suis-je capable de provoquer le bug à volonté, et de le faire disparaître en modifiant une seule chose ? Si oui, j’ai la cause. Sinon, j’ai une hypothèse, et je continue.

Ce critère évite le scénario le plus démoralisant du métier : un correctif livré, un problème qui semble résolu, et le même incident trois semaines plus tard.

Photo : domaine public (CC0).

Ce que je fais quand je bloque

Trois techniques, dans cet ordre.

Expliquer le problème à voix haute à quelqu’un. L’obligation de formuler fait apparaître l’hypothèse implicite qu’on n’avait pas remise en question. Cela fonctionne même quand l’interlocuteur ne connaît pas le sujet.

Chercher par dichotomie. Le problème est-il présent à mi-chemin de la chaîne ? On coupe l’espace de recherche en deux à chaque fois, plutôt que de suivre le code linéairement. Sur une chaîne de traitement longue, on converge en quelques essais.

Revenir aux faits de l’étape 1. Quand je tourne en rond, c’est presque toujours parce que je travaille sur une reformulation du problème plutôt que sur le problème. Relire les faits bruts remet en cause une interprétation faite trop tôt.

Photo : domaine public (CC0).

Après la correction : deux choses à ne pas sauter

Un test qui reproduit le bug. Écrit avant le correctif si possible : il échoue, on corrige, il passe. C’est la seule garantie que le problème ne reviendra pas silencieusement dans six mois, et c’est ce qui distingue une correction d’un colmatage.

Une note courte, quelque part. Trois lignes : le symptôme, la cause réelle, la correction. Pas un rapport formel — une trace consultable. Les bugs se ressemblent, et retrouver « on avait déjà eu ça, c’était l’encodage des fichiers importés » fait gagner une journée.

Ce qu’il faut avoir mis en place avant l’incident

La rapidité du diagnostic dépend moins de la méthode que de ce qui a été instrumenté avant. Trois éléments changent tout, et ils se posent en une journée.

Un identifiant de corrélation par requête, transmis à tous les composants et affiché à l’utilisateur en cas d’erreur. Quand quelqu’un signale un problème avec ce code, on retrouve la trace complète immédiatement — plus besoin de deviner l’heure ni le compte.

Des messages d’erreur qui portent du contexte. « Erreur lors du traitement » ne sert à rien. « Traitement du dossier 4821 : champ montant absent » désigne la cause avant même d’ouvrir le code.

La possibilité d’emprunter le profil d’un utilisateur, dans un cadre tracé et réservé au support. C’est le raccourci le plus efficace pour reproduire un problème lié aux droits ou aux données — à condition que chaque usage soit journalisé et visible, parce que c’est un accès sensible.

Le cas du bug qui ne se produit qu’une fois sur cent

Celui-là résiste à la méthode, parce que l’étape de reproduction échoue par construction.

Trois causes couvrent la quasi-totalité de ces cas : deux traitements qui écrivent la même donnée en même temps, un délai d’attente sur un appel externe qui n’échoue que sous charge, et une dépendance à l’heure — un traitement qui se comporte différemment au changement de journée ou d’heure d’été.

Ce que je fais alors : plutôt que de chercher à reproduire, j’ajoute de la trace autour des trois suspects et j’attends la prochaine occurrence. C’est frustrant, et c’est beaucoup plus rapide que d’essayer de recréer une condition de concurrence à la main.

Ce que cette méthode change

Elle ne rend pas les bugs plus faciles. Elle évite les deux façons de perdre du temps que j’observe le plus.

Chercher dans le code avant d’avoir établi les faits, ce qui revient à explorer au hasard une base de code de cent mille lignes. Et livrer un correctif fondé sur une hypothèse non vérifiée, ce qui coûte deux fois : le temps passé, et la confiance perdue quand l’incident revient.

L’ordre est plus important que la vitesse. Un diagnostic méthodique en trois heures vaut mieux que quatre tentatives d’une heure.