Un moniteur de chemin critique surveille l'unique séquence de routes qui compte le plus pour votre chiffre d'affaires — votre inscription ou votre paiement — et vous prévient lorsque ce parcours et les conversions réelles cassent en même temps.
Ce qu'est (et n'est pas) un moniteur de chemin critique
Un moniteur de chemin critique est un garde-fou métier, pas une garantie de disponibilité ni une certification de fiabilité.
Il rejoue la joignabilité des routes HTTP : il envoie des requêtes GET aux routes de votre parcours et enregistre si chacune répond. Il ne fait pas :
- Exécuter un navigateur headless
- Exécuter des flux JavaScript côté client
- Soumettre des formulaires ni envoyer un
POSTà vos points de terminaison d'inscription/paiement - Garantir que le flux fonctionne de bout en bout
Considérez-le comme un signal d'alerte précoce qui couple la joignabilité synthétique à vos données de conversion réelles — pas comme une preuve que votre entonnoir convertit.
Forfait requis : les moniteurs de chemin critique sont disponibles dans les forfaits Pro, Scale et Enterprise.
Comment le chemin critique est trouvé
Zenovay analyse vos sessions réelles réussies les plus récentes — des sessions où un visiteur a réellement terminé une inscription ou un paiement — et détermine la séquence de routes la plus courante que ces visiteurs ont empruntée :
- Il examine les sessions récentes qui se sont terminées par une inscription ou un paiement réussi.
- Il extrait la séquence ordonnée de routes que chaque convertisseur a visitée jusqu'à ce succès.
- Il trouve la séquence la plus courante et calcule un score de confiance — à quel point cette unique séquence est dominante parmi tous ceux qui ont converti.
- Il présente le parcours suggéré, le score de confiance et le type de conversion (inscription ou paiement) dans l'onglet Golden Path.
S'il n'y a pas assez de sessions réussies pour déduire une séquence dominante, Zenovay le dit clairement — il ne suggérera pas de parcours à faible confiance. Vous verrez à la place un état « pas encore assez de sessions réussies ». Continuez à suivre et la suggestion apparaît dès que de vrais convertisseurs lui donnent un motif stable.
Lancer la déduction maintenant : L'onglet Configuration dispose d'un bouton « Vérifier le chemin critique maintenant » qui déclenche la déduction immédiatement (avec limitation de débit) au lieu d'attendre le calendrier quotidien. Il ne fait que proposer un candidat — vous le confirmez avant que la surveillance commence.
Configuration
L'onglet Golden Path se trouve dans le groupe COMPORTEMENT du tableau de bord de votre domaine.
- Ouvrez l'onglet Golden Path → Configuration. Zenovay affiche la séquence de routes suggérée et son score de confiance.
- Choisissez inscription ou paiement. Si les deux se qualifient avec une confiance suffisante, choisissez celui à surveiller. La V1 surveille un parcours par projet — inscription ou paiement, pas les deux. Choisissez celui qui compte le plus pour votre activité.
- Confirmez le parcours. Vérifiez les étapes et confirmez. À partir de ce point, Zenovay planifie les ré-exécutions synthétiques.
Vous confirmez le parcours déduit ; vous ne rédigez pas les routes à la main en V1. Si le parcours déduit semble erroné, cela signifie généralement que vos vrais convertisseurs empruntent un chemin auquel vous ne vous attendiez pas — ce qui est en soi une observation utile.
À quelle fréquence il se ré-exécute
L'intervalle de ré-exécution est configurable par l'utilisateur pour chaque moniteur via la commande « Vérifier toutes les X minutes » dans l'onglet Configuration d'un moniteur actif.
| Forfait | Intervalles disponibles |
|---|---|
| Free | Non disponible |
| Pro | 60 minutes (fixe) |
| Scale | 5 / 10 / 15 / 30 / 60 minutes |
| Enterprise | 5 / 10 / 15 / 30 / 60 minutes |
L'intervalle minimum est de 5 minutes — c'est la fréquence à laquelle le planificateur effectue ses sondages. La valeur par défaut à la confirmation d'un moniteur est 60 minutes. Choisir un intervalle plus court vous donne un signal plus rapide en cas de problème ; les forfaits Scale et Enterprise peuvent choisir l'une des cinq options par moniteur. Un intervalle plus bas signifie plus de vérifications par jour, mais ne modifie pas le calcul de la sensibilité à la dérive.
Chaque exécution envoie des requêtes GET aux routes dans l'ordre et enregistre, pour chaque étape : le statut (la route était-elle joignable ?), le temps et la première étape ayant échoué (le cas échéant).
Lire l'onglet Health
L'onglet Health s'ouvre avec quatre cartes de synthèse :
- Taux de réussite — part des ré-exécutions planifiées récentes où chaque étape était joignable.
- Dernière exécution — quand le parcours a été rejoué pour la dernière fois.
- Durée moyenne — durée moyenne des ré-exécutions récentes.
- Dérive — si un échec synthétique et une baisse de conversion réelle se produisent en ce moment ensemble (affiché comme « calme » ou « dégradé »).
Sous les cartes, la liste des ré-exécutions récentes montre chaque exécution individuellement. Développez une exécution pour voir le statut par étape, la durée et la première étape ayant échoué (où cette exécution a cassé, le cas échéant).
Graphique des temps de réponse
La vue Health comprend un graphique des temps de réponse montrant la durée de relecture par exécution. Les exécutions sont codées par couleur : vert = normal, orange = lente ou dégradée (terminée mais plus lente que la référence), rouge = échec. Sous le graphique, vous trouverez une liste des exécutions récentes (jusqu'aux 50 dernières) avec le statut et la durée par étape.
Sélecteur de plage de dates
Un sélecteur de plage de dates en haut de la vue Health filtre toutes les données affichées. Les plages disponibles dépendent de la fenêtre de rétention de données de votre forfait :
| Plage | Forfaits |
|---|---|
| 24 dernières heures | Tous les forfaits payants |
| 7 derniers jours | Tous les forfaits payants |
| 30 derniers jours | Pro, Scale, Enterprise |
| 90 derniers jours | Scale, Enterprise |
| 180 derniers jours | Enterprise |
Les plages dépassant la fenêtre de rétention de votre forfait s'affichent comme verrouillées. Le sélecteur s'applique à l'ensemble de la vue Health — taux de réussite, graphique, durée moyenne et liste des exécutions se mettent à jour ensemble.
Le taux de réussite et les temps décrivent uniquement la joignabilité des routes. Un taux de réussite de 100 % signifie que chaque route a répondu à un GET — il ne signifie pas qu'un vrai utilisateur peut terminer l'inscription ou le paiement. Le JavaScript côté client, la validation de formulaire, le traitement du paiement et l'état d'authentification sont tous en dehors de ce qu'une vérification de joignabilité peut voir.
Alertes de dérive et incidents
La dérive est le signal qui fait de ceci un garde-fou métier plutôt qu'une page de statut.
La dérive ne se déclenche que lorsque les deux conditions sont vraies dans la même fenêtre :
- Les vérifications synthétiques planifiées échouent, et
- les conversions réelles pour ce parcours ont chuté.
Lorsque la dérive se déclenche, Zenovay crée un incident et l'onglet Health vous y dirige directement dans l'onglet Incidents.
Chaque exécution qui échoue est également marquée avec l'une des trois classes d'échec (affichée en tant que badge quand vous développez l'exécution dans l'onglet Health). La classe vous indique où se trouve la panne :
| Classe d'échec | Ce qu'elle signifie |
|---|---|
| infra | Une route a expiré, renvoyé un 5xx ou était injoignable — probablement un problème d'hébergement ou réseau, pas votre entonnoir. |
| flow_drift | Une étape intermédiaire retourne maintenant 404, 410 ou une boucle de redirection alors que la route d'entrée va bien — une URL dans le parcours a probablement bougé (par exemple, une route /signup renommée). |
| business_flow | Chaque route a répondu, mais le signal de succès réel (une inscription complétée ou un paiement) n'a pas été corroboré dans la même fenêtre — la panne est derrière les routes (une étape côté client cassée, un échec de paiement, un bug de validation) qu'une vérification de joignabilité ne peut pas voir directement. |
La classe business_flow est exactement la raison pour laquelle la double porte de signaux compte : la joignabilité seule aurait signalé « tout est vert » pendant que votre chiffre d'affaires chutait. La coupler aux données de conversion réelles attrape la panne qu'un moniteur synthétique pur manquerait. Elle garde aussi les alertes silencieuses — un échec synthétique seul n'alerte jamais, car les routes peuvent renvoyer une 404 à un robot et fonctionner quand même pour les utilisateurs.
Ce que la V1 ne fait pas
Pour rester honnête sur les attentes, la V1 ne fait pas :
- Exécuter un navigateur headless ni exécuter de flux JavaScript côté client
- Soumettre des formulaires ni envoyer un
POSTaux points de terminaison d'inscription/paiement - Garantir que le flux fonctionne de bout en bout, ni certifier la disponibilité, la fiabilité ou la conformité
- Surveiller plus d'un parcours par projet, ni inscription et paiement à la fois
- Alerter sur un échec synthétique seul (par conception — ce serait bruité)
C'est un garde-fou qui vous dit quand le parcours qui rapporte de l'argent est en difficulté. Ce n'est pas un substitut aux tests fonctionnels de bout en bout de votre inscription ou de votre paiement.