Ce que réparer du hardware vintage m'a appris sur le debugging logiciel

La scène : une machine morte, zéro doc

Imaginez l'établi. Une machine de trente ans est posée là, capot ouvert, silencieuse. Elle s'allumait hier, plus aujourd'hui. Aucune notice, le fabricant n'existe plus depuis vingt ans. Pas de schéma électronique, pas de Stack Overflow, pas de README. Juste un système physique, des composants jaunis par le temps, et la conviction tranquille que tout défaut a une explication.

Je fais ça pour le plaisir. Le vrai. Cette montée de dopamine quand, après des heures, la bête se rallume, c'est exactement la même que lorsqu'un incident de prod tombe enfin, à 2h du matin, parce que j'ai compris la chaîne complète et pas juste contourné le symptôme. Ce sont les mêmes mains, le même amour. Et avec les années, j'ai fini par voir que c'était la même méthode.

Un système qui ne marche plus n'est jamais magique. Il est juste un endroit où je n'ai pas encore regardé d'assez près.

La méthode qui transfère 1:1 au logiciel

Avec le temps, j'ai réalisé que ma façon de réparer une carte électronique était identique, mouvement pour mouvement, à ma façon de traquer un bug en production. Quatre principes, hardware comme software.

1. Observer avant de toucher

Le réflexe du débutant, c'est de toucher. Resouder au hasard, remplacer un composant « qui a l'air suspect », redémarrer le serveur, vider le cache. C'est de la superstition. Le réparateur patient, lui, commence par ne rien faire, sauf regarder.

Sur le hardware : où ça chauffe ? Quel condensateur a gonflé ? Qu'est-ce qui sent le brûlé ? Sur quel rail la tension s'effondre-t-elle ? Sur le logiciel : c'est exactement pareil. Avant de modifier une ligne, je veux reproduire la panne de façon fiable. Une panne que je ne sais pas reproduire est une panne que je ne saurai jamais prouver corrigée.

2. Une hypothèse, puis on isole les variables

Une fois la panne observée, je formule une seule hypothèse à la fois et je l'isole. La grande erreur, c'est de changer trois choses d'un coup : si ça remarche, on ne sait pas pourquoi, et on n'a rien appris. Le défaut reviendra, et on sera aussi démuni qu'avant.

La technique reine, c'est la bissection, diviser le système en deux et déterminer de quel côté vit le défaut. Sur une carte : je débranche la moitié des sous-circuits, je remesure. Sur le logiciel : git bisect entre la dernière version saine et la version cassée, ou je commente la moitié d'un pipeline. À chaque coupe, l'espace de recherche est divisé par deux. Une panne perdue dans dix mille lignes tombe en treize coupes. C'est de la dichotomie, pas de la chance.

# bisection logicielle : acculer le commit fautif
git bisect start
git bisect bad                 # HEAD : l'incident est là
git bisect good v2.3.0         # cette version-là tournait

#   git checkoute automatiquement le milieu
#   je teste → bon ou mauvais → il recoupe
#   ~13 étapes pour 8000 commits, le coupable tombe seul

3. Quand il n'y a pas de doc, on lit le système lui-même

C'est ici que beaucoup abandonnent. « Y'a pas de doc, on peut pas savoir. » Faux. Le système est sa propre documentation, pour qui accepte de la lire.

• Sur le hardware : je trace le circuit à la main. Je suis les pistes au multimètre, je reconstitue le schéma piste par piste, je déduis le rôle de chaque composant par sa place dans la chaîne. La carte me raconte son intention.
• Sur le logiciel : je lis la source, pas la doc qui ment. Je lis les logs réels, pas ceux que j'imagine. Au besoin, je lis les octets eux-mêmes, un dump réseau, une requête SQL brute, un cœur de dump mémoire. La vérité est toujours dans ce qui s'exécute, jamais dans ce qu'on raconte sur ce qui s'exécute.

On appelle ça parfois « reverse engineering » avec un frisson d'interdit. En réalité, ce n'est que de la curiosité avec méthode. La même qui fait qu'on rouvre un réveil à six ans pour voir ce qu'il y a dedans, sauf qu'on a appris à le refermer en marche.

Il n'existe pas de système indéchiffrable. Il existe des systèmes qu'on n'a pas encore eu la patience de lire.

4. La cause racine, pas le symptôme

C'est le principe le plus important, et le plus négligé. On peut presque toujours faire disparaître un symptôme sans comprendre le défaut. Sur une vieille machine, taper sur le boîtier rétablit parfois le contact. Sur un serveur, un redémarrage planifié « règle » la fuite mémoire. Dans les deux cas, on n'a rien réparé, on a déplacé l'incident dans le futur, en plus gros.

Le réparateur ne se contente pas de faire remarcher. Il veut savoir pourquoi ça s'était arrêté. Parce qu'un défaut compris est un défaut mort ; un défaut contourné est un défaut qui reviendra au pire moment, avec des intérêts.

Une vraie histoire de prod qui en est le miroir

Chez un SaaS B2B, un bug fantôme : les transactions échouaient parfois en 500, au hasard, sous charge. Pas reproductible en local, pas reproductible en staging. Aucune erreur évidente dans le code de facturation, qui n'avait pas bougé depuis des mois. Le genre de bug devant lequel beaucoup haussent les épaules : « ça arrive, on relance le job ».

Méthode hardware. Pas de pari. J'ai d'abord reproduit : un test de charge qui génère des factures en parallèle, jusqu'à voir les 500 apparaître. Puis des jours à lire les logs de production réels, pas une version romancée, la séquence exacte, horodatée, des requêtes qui échouaient. Et là, le motif a émergé : les erreurs n'arrivaient que quand plusieurs factures se généraient en même temps.

La cause racine était délicieusement bête. La génération du PDF de facture, son upload vers le stockage, puis l'écriture en base tenaient une transaction ouverte. Sous concurrence, ce temps total dépassait le innodb_lock_wait_timeout par défaut de MySQL, 50 secondes. Au-delà, MySQL tuait la transaction en attente : deadlock, transaction avortée, 500. Le défaut n'était pas dans le code de facturation. Il était dans une valeur par défaut, à la frontière entre deux systèmes que personne ne regardait ensemble.

-- le symptôme, côté base
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout';
-- → 50  (défaut MySQL)

-- sous charge : génération PDF + upload + write > 50s
--   → Lock wait timeout exceeded; transaction rolled back
--   → l'API renvoie 500, "au hasard"

-- le correctif, une seule ligne
SET GLOBAL innodb_lock_wait_timeout = 120;

N'importe qui aurait pu écrire cette ligne. Presque personne n'aurait su qu'il fallait l'écrire. C'est toute la différence, et c'est exactement la valeur que je vends.

Pourquoi ça compte, à l'ère de l'IA

On vit un moment particulier. N'importe qui peut générer en quelques secondes du code qui marche. Il marche en démo, il marche au premier test, il passe la revue. Puis il casse en production, sous charge réelle, sur un cas limite que personne n'avait imaginé, et là, le code généré ne s'explique plus tout seul.

La compétence qui devient rare, et donc précieuse, n'est plus d'écrire du code. C'est de diagnostiquer pourquoi un système a cassé quand plus personne ne le comprend vraiment. Je suis massivement augmenté par l'IA, elle écrit, elle suggère, elle accélère. Mais c'est moi qui tiens la cause racine. IA pour la vitesse, méthode d'établi pour la vérité.

Les mêmes mains

Au fond, c'est une seule et même histoire. Les mains qui rallument une machine de trente ans et celles qui éteignent un incident de prod sont les mêmes. La rigueur est la même : observer, isoler, lire le système, viser la cause racine. Le plaisir est le même : ce moment précis où l'opaque redevient clair, où le « pourquoi » se révèle enfin.

Je ne me contente pas de faire marcher les choses. Je veux comprendre pourquoi elles marchent, c'est valable pour un condensateur de 1994 comme pour un timeout MySQL en 2026. C'est le même amour des systèmes. Et c'est, j'imagine, ce que vous cherchez vraiment quand vous appelez quelqu'un face à un problème que personne d'autre n'arrive à expliquer.