Avril 2026

HTTP 200 mais panier cassé : pourquoi votre monitoring vous ment

Parcours

La supervision est verte, la page d’accueil répond en deux cents millisecondes, et pourtant personne n’a commandé depuis mardi. C’est de cette situation que Pathly est né.

Ce qu’une sonde HTTP regarde vraiment

Une sonde HTTP ouvre une adresse, lit le code de réponse, et referme. Si le serveur répond 200, elle conclut que tout va bien. C’est exact, et c’est très insuffisant : elle n’a rien cliqué, rien rempli, rien validé. Elle a vérifié qu’une machine répond, pas qu’un client peut acheter.

Ce qui casse, en vrai

Aucun de ces quatre incidents ne fait passer une sonde HTTP au rouge. Tous coûtent des commandes, parfois pendant plusieurs jours, jusqu’à ce qu’un client prenne la peine d’écrire — et la plupart n’écrivent pas.

Rejouer le parcours, pas l’adresse

La seule manière de le savoir, c’est de faire ce que fait un client : ouvrir un navigateur, se connecter, ajouter au panier, aller jusqu’à l’écran de paiement, et vérifier que le texte attendu est bien là. Quand une étape casse, on veut la capture de l’étape qui casse, pas un code de retour.

C’est tout le produit : vous enregistrez le parcours une fois dans votre navigateur, nous le rejouons pour vous, et nous vous prévenons quand il ne passe plus. Le reste — les courbes, les seuils, les rapports — n’existe que pour rendre cette alerte crédible.

Et la supervision HTTP, alors ?

Elle reste utile, et Pathly la fait aussi : elle coûte presque rien, elle tourne chaque minute, elle détecte les pannes franches. Nous ne l’opposons pas aux parcours, nous superposons les deux. Un serveur muet se voit en HTTP ; un paiement cassé ne se voit qu’en navigateur.

Voyez ce que ça donne sur votre site

Audit gratuit en 30 secondes — ou enregistrez un parcours et surveillez-le chaque jour.