Article · 24 septembre 2026 · 6 min de lecture

Debug Detective : curl me mentait

Le pipeline était vert. Le déploiement était terminé, le health check content, et quelqu'un me disait que la page ne fonctionnait pas. L'un des deux avait tort et j'ai passé quelques heures à supposer que c'était la personne.

La scène

Un déploiement part. Le pipeline lance son smoke test contre la nouvelle version, obtient ce qu'il attendait, et passe au vert. Vingt minutes plus tard, on me dit que la page est blanche.

Blanche. Pas lente, pas en erreur, pas à moitié affichée. Rien dessus.

Mon premier réflexe a été de douter du signalement, et je préfère le dire tel quel plutôt que de l'habiller en triage. Le pipeline avait vérifié. La vérification était passée. L'explication la plus probable, à mes yeux, était un onglet périmé ou un bundle en cache sur une autre machine.

Ce n'était pas ça.

Tout ce que j'ai vérifié allait bien

Le déploiement était terminé. Bon tag d'image, pods prêts, rollout propre. Le endpoint de santé répondait exactement comme il devait.

Alors je suis allé dans les logs, chercher les 5xx qui devaient forcément s'y trouver.

Il n'y en avait aucune. Pas une. Aucune stack trace, aucune erreur, aucun avertissement, rien de levé puis avalé. Des heures à lire un log qui n'avait rien à dire, parce que le serveur n'échouait pas.

C'est la partie sur laquelle il faut s'arrêter. Tout ce que je vérifiais revenait vert, et tout ce que je vérifiais était réellement vert. Le vert ne mentait pas. Le vert était le problème.

Le témoin

Voici ce que faisait mon smoke test :

Il demandait un code de statut au serveur. Le serveur lui en a donné un. Deux cents, honnêtement et correctement, parce que le serveur avait bel et bien un document à remettre et l'a remis.

Ce document était une coquille vide qui se remplit dans le navigateur. Le script chargé de la remplir n'était pas là.

curl ne m'a jamais menti. Il a répondu avec une exactitude parfaite à la question que je posais, et la question que je posais n'était pas celle que je voulais poser. Je voulais savoir si la page fonctionnait. J'ai demandé si le serveur répondait.

Ce qu'a dit un vrai navigateur

Dès que vous exécutez la page au lieu de simplement la récupérer, l'affaire se referme. Le conteneur est vide. Il allait toujours être vide, et il l'aurait été à chaque build vert.

Ceci est une reproduction, réalisée en local sur un serveur jetable, et non une capture du système où c'est arrivé. Le mécanisme est identique et vous pouvez le refaire en une minute, ce qui est précisément l'intérêt.

Le correctif, et son prix

Le smoke test lance désormais un vrai navigateur et cherche une chaîne qui n'apparaît qu'une fois l'application montée. C'est plus lent. Cela ajoute presque une minute à chaque pipeline.

Je prends la minute. L'ancien test m'a coûté quelques heures et, pire, il m'a coûté ma confiance dans le signalement de la personne qui avait raison.

Note du détective

Le témoin était honnête. J'avais posé une question dont la réponse vraie ne m'apprenait rien, puis j'ai lu cette réponse comme une garantie.

• Un code de statut est une affirmation sur la transaction, pas sur la page. Un HTTP 200 signifie que le serveur avait quelque chose à envoyer.
• Si votre vérification ne distingue pas une page qui marche d'une page cassée, elle ne vérifie pas ce qui vous intéresse.
• Quand tout ce que vous inspectez est vert et que quelqu'un dit que c'est cassé, envisagez que vous inspectiez les mauvaises choses plutôt que cette personne se trompe.
• Croyez l'humain devant l'écran blanc. Il regarde l'artefact. Vous regardez un indicateur indirect.
• Un test plus lent qui peut échouer vaut mieux qu'un test rapide qui ne le peut pas.