Monitoring de production : surveillez vos parcours

En bref

Le monitoring de production rejoue en continu vos parcours critiques sur l'environnement réel, à intervalle régulier, pour détecter une panne avant vos utilisateurs. Il repose sur les mêmes scénarios que les tests fonctionnels, et chaque échec est qualifié avant de devenir une alerte, ce qui évite le bruit.

Ce sont les mêmes scénarios que vos tests fonctionnels, votre mesure de performance et votre tir de charge. Un parcours écrit une fois sert aux quatre usages.

monitoring de production, MTTD et MTTR, criticité : les définitions sont dans le glossaire QA.

Une panne de parcours ne déclenche aucune alarme technique

Les serveurs répondent, les taux d’erreur sont normaux, la supervision d’infrastructure est au vert. Et pourtant plus personne ne peut payer depuis la mise à jour du prestataire de paiement, cette nuit. Ce type de panne ne se lit dans aucune métrique système. Elle se voit en rejouant le parcours, comme un client le ferait.

Un réseau de concessions automobiles nous fait ainsi vérifier chaque jour le délai réel avant le premier rendez-vous disponible. Aucun outil de supervision ne sait répondre à cette question, parce que ce n’est pas une question de disponibilité.

Le parcours, pas le serveur

Un scénario complet joué en production à intervalle régulier. C’est la seule façon de savoir que le service marche vraiment, et pas seulement qu’il répond.

Une alerte par niveau de gravité

E-mail, Slack, SMS ou webhook vers votre outil. Le paiement réveille l’astreinte, le formulaire de contact attend le matin.

La preuve de ce qui s'est passé

Capture d’écran, étape exacte, horodatage. L’équipe part d’un constat daté, pas d’une tentative de reproduction.

Un seul scénario, trois usages

Vous ne réécrivez rien. Le scénario qui valide une recette mesure ensuite les temps de réponse, puis surveille la production, avec ses propres données.

Ce que l’on surveille, côté métier

Vos outils de supervision répondent à une question technique : le service répond-il. Le métier en pose une autre : ce que le client lit à l’écran est-il vrai. Entre les deux, il y a tout ce qui casse une promesse sans casser une page.

Le délai annoncéPremier créneau de rendez-vous, délai de livraison, temps de traitement d’un dossier. On mesure ce que le client lit, pas ce que la base contient.

La disponibilité réelleStock affiché, produit réellement commandable, créneau réservable jusqu’au bout. Un article visible qui bloque au panier compte comme indisponible.

Le prix et les fraisPrix affiché, frais de port, remise appliquée, mention obligatoire présente. Un écart entre la fiche et le panier se voit immédiatement.

La cohérence entre canauxSite, application mobile, espace client. Le même parcours joué sur chaque canal, pour repérer les promesses qui divergent d’un support à l’autre.

Voir l'aperçu complet de la sécurité

L'alerte arrive là où votre équipe la lit

Vos parcours sont joués à la fréquence que vous choisissez, depuis l’extérieur, comme un utilisateur réel. L’alerte part là où votre équipe la verra.

1 Déclenchement Vos outils gardent la main

GitLab
Jenkins
Microsoft Azure
Appel API
Planification

2 Exécution

vos scénarios tournent sur vos environnements réels

Parcours web
Applications natives iOS et Android
Fermes de mobiles réelles
API et flux internes

3 Restitution Le résultat arrive où vous travaillez

Jira
Slack
SMS
Webhook
API

Et une maintenance qui tient dans le temps

Blocs réutilisablesune modification met à jour tous les scénarios qui l'utilisent
Réparation assistée par IAdes correctifs proposés sur les scénarios en erreur
Regroupement des incidentsles anomalies similaires sont traitées une seule fois

Ce que change la surveillance de parcours, ligne par ligne

Supervision d'infrastructure seuleAvec le monitoring de parcours

Supervision d'infrastructure seule

Avec le monitoring de parcours

On sait que le serveur répond.

On sait que le client peut acheter.

La panne est signalée par un client mécontent.

Elle est signalée par le scénario, avant lui.

Le délai de détection se compte en heures.

Il se compte en minutes.

L'équipe commence par essayer de reproduire.

Elle part d'une capture et d'une étape précise.

Une panne chez un prestataire tiers reste invisible.

Elle ressort au premier échec du parcours.

Le week-end, personne ne regarde.

Le scénario tourne quand même, et l'alerte part.

RésultatUne panne de parcours détectée en quelques minutes, avec la capture et l'étape exacte, plutôt qu'un appel du service client.

Qualifié avant de devenir une alerte

Un échec est d’abord rejoué automatiquement, ce qui écarte les aléas passagers avant toute alerte

Ce qui résiste au rejeu ouvre un incident, avec son état et sa criticité

Les échecs qui partagent la même cause sont regroupés dans un seul incident, pas une alerte par exécution

L’origine est renseignée, ce qui distingue une panne applicative d’une indisponibilité extérieure

La visibilité indique si le problème touche tous les utilisateurs ou un cas particulier

Un humain tranche entre vrai problème et indéfini : c’est cette étape qui décide de ce qui vous réveille

Ce que ce tri évite

L’alerte déclenchée par un aléa réseau qui aurait disparu au rejeu suivant

L’alerte déclenchée par une zone de la page qui change toute seule

Les dizaines de notifications identiques provoquées par une seule et même cause

Le canal d’alerte que l’équipe finit par couper parce qu’il crie trop

Le temps passé à requalifier un sujet déjà connu

GUIDE PRATIQUEParcours client online : les bases d’un parcours fluideCe qui casse un parcours en production, où le détecter, et comment l’apprendre avant vos clients.

Télécharger le guide

“ Mr Suricate est une évidence, car il donne l'assurance qu'il n'y a pas de problème. Un seul bug découvert suffit à rentabiliser la solution pendant une année entière ! ”

Anthony CornevinE-commerce Platform Manager, Vertbaudet

Qui regarde les incidents la nuit, vous ou nous ?

Avec Mr Suricate, votre équipe QA n’est pas remplacée, elle est renforcée. Vous choisissez ce que vous internalisez et ce que vous déléguez : la définition des parcours à surveiller, le suivi des alertes, ou la maintenance des scénarios.

1Identification des parcours critiques, front et back
2Écriture des tests, sans code
3Supervision continue et alertes
4Maintenance et évolution des scénarios

Résultatvous gagnez en couverture sans alourdir la charge de vos équipes. Et si vous préférez tout déléguer, l'externalisation QA prend le relais.

ALLER PLUS LOIN

Les autres types de tests

Quinze types de tests, quatre familles. Chacun répond à une question différente sur votre application.

Tests de performanceLe temps de réponse réel de vos parcours, mesuré en continu et comparé à vos seuils.En savoir plus Tests de non-régressionRejouer l'ensemble des parcours validés avant chaque mise en production.En savoir plus Tests end-to-endLe parcours complet, d'un bout à l'autre de la chaîne, y compris les systèmes tiers.En savoir plus Tests d'APILes échanges entre vos services, testés directement, sans passer par l'interface.En savoir plus Tests de tir de chargeLe point de rupture de votre infrastructure, en simulant un afflux massif d'utilisateurs.En savoir plus Tests fonctionnelsVérifier qu'une fonctionnalité produit bien le résultat attendu, du point de vue de l'utilisateur.En savoir plus Tests de sécuritéVérifier ce qu’un utilisateur peut réellement atteindre : droits par profil, sessions, authentification, HTTPS.En savoir plus Les 15 types de testsLa vue d'ensemble : quatre familles, quinze types, et par quoi commencer selon votre situation.En savoir plus

Un terme vous échappe ? Le glossaire du test automatisé le définit.

VOS QUESTIONS

Questions fréquentes

Ce qu'on nous demande le plus souvent sur la surveillance en production.

Quelle différence avec un monitoring d'infrastructure classique ?

Un monitoring d'infrastructure surveille des composants : disponibilité d'un serveur, temps de réponse d'une URL, taux d'erreur. Le monitoring de parcours joue le scénario métier complet. C'est ce qui permet de détecter une panne fonctionnelle alors que toute la chaîne technique est au vert.

À quelle fréquence les scénarios sont-ils joués ?

Vous choisissez la fréquence scénario par scénario, du cycle de quelques minutes sur un parcours de paiement à une exécution quotidienne sur un formulaire secondaire. Le bon réglage se déduit du coût d'une heure de panne sur le parcours concerné.

Comment est-on prévenu en cas de panne ?

L'alerte part sur le canal défini pour le scénario : e-mail, Slack, SMS ou webhook vers votre propre outil. Les scénarios critiques peuvent avoir un canal, un destinataire et un délai différents des autres, ce qui évite de réveiller l'astreinte pour un incident mineur.

Comment évitez-vous les fausses alertes ?

Un échec est d’abord rejoué automatiquement : ce qui tenait à un aléa passager disparaît sans avoir alerté personne. Ce qui résiste au rejeu ouvre un incident, et les échecs qui partagent la même cause sont regroupés dans un seul incident plutôt qu’une alerte par exécution. Un humain qualifie ensuite l’incident avant qu’il ne devienne une alerte.

Faire tourner des tests en production, est-ce risqué ?

La règle est simple : en production, on n'utilise que des données créées pour les tests. Les scénarios s'appuient sur des comptes et des jeux de données dédiés, et les étapes qui produiraient un effet réel indésirable sont bornées à la conception du scénario.

Peut-on réutiliser les scénarios de recette ?

Oui, et c’est le mode de démarrage le plus rapide. Un scénario de non-régression déjà écrit devient une sonde de production en changeant son environnement et ses données, et le même scénario sert aussi à mesurer les temps de réponse étape par étape. Vous n’entretenez qu’un seul cahier de tests, là où un outil de test, un outil de charge et un outil de supervision vous en feraient entretenir trois.

Est-ce un outil d’APM ou de RUM ?

Non, et c’est une limite qu’il vaut mieux poser d’emblée. Mr Suricate fait du monitoring synthétique : il rejoue des parcours complets à intervalle régulier. Il ne mesure pas les sessions réelles de vos visiteurs et n’instrumente pas votre code applicatif.

Que surveille-t-on exactement ?

Des parcours métier de bout en bout, pas seulement la disponibilité d’une page. Un site peut répondre en 200 et avoir un tunnel d’achat cassé à l’étape du paiement : c’est précisément ce cas que le monitoring de parcours détecte.

Comment éviter de polluer les mesures analytics ?

Les exécutions sont identifiables et s’excluent de vos rapports, par adresse IP ou par paramètre selon votre outil. Le cadrage se fait au lancement, avant la première campagne.

Faut-il ouvrir des accès particuliers en production ?

Des comptes de test dédiés suffisent dans la plupart des cas. Pour les étapes sensibles, on définit ensemble jusqu’où le scénario va et ce qu’il ne déclenche pas.

Quels indicateurs métier pouvez-vous suivre ?

Tout ce qui est lisible dans une interface : un délai, un prix, un stock, un créneau, un frais, une mention obligatoire. Si un client peut le voir, nous pouvons le relever et le comparer à ce qui est attendu.

Calculez-vous un revenu à risque ?

Non, et nous préférons le dire. Nous établissons un impact métier qualifié : quel parcours est touché, à quelle étape, depuis quand. Le chiffrage en euros dépend de vos données de conversion, il se fait avec votre équipe analytics.

Monitoring de production : vos parcours surveillés en continu

Ils nous font confiance