Moniteurs de chemin critique

Fonctionnalité Pro

Un moniteur de chemin critique est un garde-fou métier, pas une garantie de disponibilité ni une certification de fiabilité. Il surveille la seule séquence de routes qui compte le plus pour le 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'il fait

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éduit la séquence de routes la plus courante que ces visiteurs ont empruntée. Cette séquence est votre chemin critique, et elle est accompagnée d'un score de confiance fondé sur la constance avec laquelle les vrais convertisseurs l'ont suivie.

Une fois le parcours confirmé, Zenovay le rejoue de façon planifiée sous forme d'une série de requêtes GET légères, en enregistrant le statut, le temps par étape et la première étape ayant échoué. Il corrèle ensuite ce résultat synthétique avec votre volume de conversions réel dans la même fenêtre temporelle. Lorsque les vérifications synthétiques échouent et que les conversions réelles chutent ensemble, il déclenche un incident de dérive.

Cette double porte de signaux est tout l'intérêt : une vérification synthétique qui échoue seule est bruitée (une route peut renvoyer une 404 à un robot et fonctionner quand même pour les utilisateurs) ; une baisse de conversion seule est ambiguë (cela peut être une journée de ventes lente). Lorsque les deux bougent ensemble, quelque chose ne va vraiment pas avec le parcours qui rapporte de l'argent.

---

Comment le chemin critique est déduit

1. Zenovay examine les sessions récentes qui se sont terminées par une inscription ou un paiement réussi pour le site web.
2. Il extrait la séquence ordonnée de routes (motifs de chemin d'URL) que chaque convertisseur a visitée jusqu'à ce succès.
3. Il trouve la séquence la plus courante parmi ces convertisseurs et calcule un score de confiance — à quel point cette unique séquence est dominante parmi tous ceux qui ont converti.
4. Il présente le parcours suggéré, le score de confiance et le type de conversion qu'il représente (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 ; la suggestion apparaît dès que de vrais convertisseurs lui donnent un motif stable.

La déduction s'exécute sur un calendrier quotidien, mais si vous avez déjà des conversions vous n'avez pas à attendre : l'onglet Configuration dispose d'un bouton « Rechercher un chemin critique maintenant » qui exécute la déduction immédiatement (avec limitation de débit). Il ne fait que proposer un chemin candidat — vous le confirmez avant que la surveillance commence.

---

Configuration

L'onglet Golden Path se trouve sous le groupe COMPORTEMENT dans le tableau de bord de votre domaine.

1. Ouvrez l'onglet Golden Path → Configuration

Zenovay affiche la séquence de routes suggérée qu'il a déduite de vos vrais convertisseurs, avec le score de confiance.

2. Choisissez inscription ou paiement

Si un parcours d'inscription et un parcours de paiement se qualifient tous deux avec une confiance suffisante, vous 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é.

3. Confirmez le parcours

Vérifiez les étapes et confirmez. À partir de ce point, Zenovay planifie les ré-exécutions synthétiques.

---

Calendrier des vérifications (configurable)

La fréquence à laquelle Zenovay rejoue le parcours confirmé est contrôlée depuis l'onglet Configuration de chaque moniteur actif via le contrôle « Vérifier toutes les » :

• Pro — verrouillé à 60 minutes (toutes les heures).
• Scale & Enterprise — choisissez 5, 10, 15, 30 ou 60 minutes par moniteur.

5 minutes est le plancher : le planificateur interroge toutes les 5 minutes et ne peut pas s'exécuter plus souvent. La valeur par défaut lors de la première confirmation d'un parcours est 60 minutes. Un intervalle plus court donne un signal plus rapide en cas de panne, mais ne modifie pas la sensibilité de la double porte de signal de dérive — cette logique reste inchangée quelle que soit la fréquence d'exécution synthétique.

Chaque exécution envoie des requêtes GET aux routes du parcours dans l'ordre, et enregistre pour chaque étape :

• Statut — la route a-t-elle répondu comme joignable ?
• Temps — combien de temps l'étape a pris.
• Première étape ayant échoué — la première étape de la séquence qui a échoué, le cas échéant.

---

L'onglet Health

L'onglet Health résume le moniteur d'un coup d'œil :

• 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 — temps de relecture total moyen sur les ré-exécutions récentes.
• Étape la plus lente — la route qui prend systématiquement le plus de temps.
• Première étape ayant échoué — où le parcours a cassé le plus récemment.
• Résumé de dérive — si un échec synthétique et une baisse de conversion réelle se produisent en ce moment ensemble.

Lire la vue Health

L'onglet Health affiche également un graphique des temps de réponse — une ligne verte de la durée totale de relecture (somme de tous les temps d'étapes) par ré-exécution planifiée. L'ambre marque une ré-exécution dégradée ou lente ; le rouge marque un échec. Sous le graphique se trouve une liste des ré-exécutions récentes montrant environ les 50 dernières ré-exécutions avec les détails de réussite/échec, durée et première étape ayant échoué.

Un sélecteur de plage de dates en haut de la vue Health délimite tout ensemble — le graphique, les statistiques récapitulatives et la liste des ré-exécutions récentes. Les plages disponibles dépendent de la durée de conservation de l'historique d'exécution de votre forfait :

Les plages plus longues que ce que votre forfait conserve sont affichées mais verrouillées. Conservation de l'historique d'exécution : Pro conserve 30 jours, Scale 90 jours, Enterprise 180 jours.

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 du parcours a répondu à un GET ; il ne signifie pas qu'un vrai utilisateur peut terminer l'inscription ou le paiement (le JS 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).

---

Dérive et incidents

La dérive est le signal qui transforme cela d'une page de statut en un garde-fou métier.

La dérive ne se déclenche que lorsque les deux conditions sont vraies dans la même fenêtre :

1. Les vérifications synthétiques planifiées échouent, et
2. les conversions réelles pour ce parcours ont chuté.

Lorsque la dérive se déclenche, Zenovay crée un incident, visible dans l'onglet Incidents aux côtés des Conversion Incidents. L'incident est classé dans l'une des trois classes d'échec :

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.

---

Ce que la V1 fait et ne fait pas

Pour rester honnête sur les attentes :

La V1 fait :

• Déduire un unique chemin critique à partir de vraies sessions réussies, avec un score de confiance.
• Surveiller un parcours par projet — inscription ou paiement.
• Rejouer ce parcours à un intervalle configurable (Pro : 60 min fixe ; Scale/Enterprise : 5–60 min) sous forme de vérifications de joignabilité GET.
• Enregistrer le statut, le temps par étape et la première étape ayant échoué.
• Déclencher un incident de dérive uniquement lorsque les vérifications synthétiques échouent et que les conversions réelles chutent ensemble.
• Classer les échecs en infra, flow_drift ou business_flow.

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 POST aux 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 simultanément.
• 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.

---

Liens connexes

• Conversion Incidents — baisses détectées automatiquement dans vos objectifs et entonnoirs définis
• Page Flows — voyez les vraies séquences de routes que les visiteurs empruntent
• Conversion Funnels — définissez des parcours de conversion multi-étapes