Un simple contrôle de disponibilité pose une seule question : cette page répond-elle ? Or l’essentiel de ce qui rapporte se trouve quelques étapes plus loin. La page produit se charge, mais le formulaire d’ajout au panier envoie vers un endpoint qui renvoie une erreur. La page de connexion répond 200, mais la session ne démarre jamais. La page de commande s’affiche, mais l’étape de paiement dépasse le délai. Chaque page semble correcte isolément ; c’est le parcours qui est cassé.
Un moniteur de parcours suit le chemin comme le ferait un client, étape par étape, et vérifie chacune d’elles au passage.
Les étapes disponibles
Open page : accéder à une adresse.Follow link : cliquer sur un lien d’après son texte, comme « Checkout ».Submit form : remplir et envoyer un formulaire de la page. Les champs masqués, comme les jetons de sécurité, sont conservés.API request : GET, POST, PUT, PATCH ou DELETE, avec en-têtes et corps, pour les séquences d’API.Click : cliquer sur un bouton ou tout autre élément d’après son texte, dans le vrai navigateur.
Chaque étape peut vérifier le code de statut, un texte que la page doit ou ne doit pas contenir, ou des champs JSON. La première étape en échec arrête le parcours, et l’incident vous indique laquelle et ce qu’elle a renvoyé.
Des valeurs d’une étape réutilisées dans la suivante
Les vrais parcours dépendent de ce qui précède. Enregistrez une valeur issue d’une étape, comme un jeton d’accès dans une réponse de connexion ou un identifiant de commande dans un panier, et réutilisez-la plus loin sous la forme {{name}} dans une adresse, un en-tête, un corps ou un champ de formulaire. Les cookies sont transmis automatiquement d’une étape à l’autre : une session connectée le reste.
Les mots de passe et autres secrets sont scellés : chiffrés en AES-256-GCM et plus jamais affichés en entier, pas même à vous. Utilisez un compte de test dédié, et les identifiants restent aussi sûrs que le reste de votre configuration.
Requêtes simples ou vrai navigateur
Par défaut, un parcours s’exécute sous forme de simples requêtes HTTP. C’est rapide, et cela peut tourner jusqu’à une fois par minute. Certains sites demandent davantage : un panier construit en JavaScript, un bouton qui n’est pas un lien, une application monopage. Activez « Run in a real browser » et le parcours s’exécute dans un navigateur qui exécute le JavaScript et clique comme un visiteur. Quand une étape échoue, vous obtenez une capture d’écran de la page telle qu’elle s’affichait.
Un vrai navigateur prend bien plus de temps qu’une requête : les parcours en navigateur s’exécutent donc au plus toutes les 15 minutes. Utilisez des requêtes simples quand c’est possible, et le vrai navigateur pour les parcours qui l’exigent.
Un parcours de commande pour northwind.shop
Ouvrir la page produit et vérifier qu’elle contient « Add to cart ».Envoyer le formulaire d’ajout au panier.Suivre le lien « Checkout » et vérifier la présence du récapitulatif de commande.Vérifier que l’étape de paiement se charge. Sinon, le parcours échoue ici, et l’incident affiche l’étape 4 avec une capture d’écran.
Arrêtez-vous avant tout paiement ou envoi. Un parcours qui vérifie que l’étape de paiement se charge détecte la plupart des pannes du tunnel de commande sans passer de vraies commandes. La démo en direct contient un parcours de commande comme celui-ci, consultable sans inscription.
Connexion et séquences d’API
Pour un produit SaaS, le parcours le plus important est souvent la connexion. Un parcours peut ouvrir la page de connexion, envoyer le formulaire avec un mot de passe scellé et vérifier que le tableau de bord affiche le nom de l’utilisateur de test. Pour une API, enchaînez les requêtes : obtenir un jeton, créer un objet de test avec, le relire et vérifier un champ JSON. La checklist de surveillance d’API liste les séquences qui méritent d’être couvertes.
Des alertes preuves à l’appui
Un parcours en échec est confirmé comme n’importe quel autre contrôle : les parcours s’exécutent depuis Stockholm, en Suède, et chaque échec est revérifié avant l’ouverture d’un incident. L’incident affiche l’étape en échec et sa réponse, plus une capture d’écran si le parcours s’est exécuté dans un vrai navigateur. Les alertes partent par e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks et notifications push sur votre téléphone.
La place des parcours
Gardez des moniteurs de disponibilité simples pour la page d’accueil et les endpoints clés, vérifiés toutes les minutes, et ajoutez des parcours pour les cheminements qui rapportent. Chaque parcours compte comme un moniteur de disponibilité : 15 avec Start, 100 avec Professional et 250 avec Business. Les boutiques en ligne commencent généralement par le tunnel de commande ; voir la surveillance pour les boutiques en ligne.
Les offres commencent à 9 € par mois en facturation annuelle ou 12 € en facturation mensuelle, HT. Comparez les limites sur la page des tarifs, ou commencez un essai gratuit de 14 jours sans carte bancaire.