Aller au contenu
Facteur
/ Surveillance de parcours

Vos tests s'arrêtent à la CI. Vos parcours critiques, non.

Un parcours d'inscription qui casse en production ne casse presque jamais au déploiement : il se dégrade un jeudi soir, chez un routeur, sur un domaine. Le seul moyen de le savoir est de le rejouer en continu, code de vérification compris.

datadog · étape 2 Synthetics
// Étape 2 d'un test API multi-étapes Datadog Synthetics.
// L'API attend le message : pas de sleep dans le scénario.
GET https://api.facteur.eu/v1/messages
    ?inbox=p9x4k2ab
    &sentTo=signup%2B{{ RUN_ID }}
    &wait=45000
Authorization: Bearer {{ FACTEUR_READONLY_KEY }}

// Assertions de l'étape
// status                  is 200
// body.messages[0].otp    matches [0-9]{6}
// → extraire body.messages[0].otp dans la variable OTP pour l'étape 3
La clé ne fait que lire. La recherche répond dès que le message arrive, 45 secondes au plus ici.
surveiller-inscription.ts TypeScript
// Un ordonnanceur et deux appels HTTP suffisent.
const auth = { authorization: 'Bearer ' + process.env.FACTEUR_READONLY_KEY };
const address = 'signup+' + Date.now() + '@p9x4k2ab.inbox.facteur.eu';
const started = Date.now();

const search = new URLSearchParams({ inbox: 'p9x4k2ab', sentTo: address, wait: '45000' });
const arrives = fetch('https://api.facteur.eu/v1/messages?' + search, { headers: auth })
  .then((response) => response.json());

await inscrire(address);             // votre parcours, en production
const { messages } = await arrives;

if (messages.length === 0) throw new Error('aucun code en 45 s');
console.log('code reçu en', Date.now() - started, 'ms');
await confirmer(address, messages[0].otp);
Votre monitor mesure lui-même le délai : c'est votre chiffre, dans votre outil.
Le scénario

Ce qu'un parcours surveillé vérifie réellement

Un check HTTP sur votre page d'inscription vous dit qu'elle répond. Il ne vous dit pas qu'un utilisateur peut s'inscrire.

  1. 01

    Le monitor crée un compte sur votre environnement de production, avec une adresse unique dans votre inbox de supervision.

  2. 02

    Il attend le code de vérification. L'API garde la recherche ouverte jusqu'à son arrivée, cinq minutes au plus, et votre monitor mesure le délai.

  3. 03

    Il lit le code, déjà isolé du corps du message, et termine l'inscription.

  4. 04

    Il supprime le compte de test, et recommence dans cinq minutes.

Le jour où votre routeur d'e-mails commence à mettre trois minutes, vous le savez avant vos utilisateurs. Et votre outil de surveillance a le chiffre pour le prouver à votre prestataire.

Ce qu'il faut pour tenir

Surveiller n'est pas tester

01

Cette adresse-là ne change jamais

Une inbox de surveillance vit des mois : son adresse est déclarée dans votre monitor, parfois dans une liste blanche côté expéditeur. Une inbox Facteur n'expire pas : elle garde son adresse jusqu'à ce que vous la supprimiez.

02

Clés en lecture seule

ws:read

Un monitor ne doit pouvoir ni créer ni supprimer quoi que ce soit. Une clé d'API ne fait que lire par défaut, peut être limitée à certains espaces de travail, et expire après la durée que vous fixez, d'un jour à un an. Si elle fuit dans une configuration de surveillance, les dégâts restent bornés.

03

L'attente se fait chez nous

GET /messages?wait=

La recherche attend le message jusqu'à cinq minutes et répond dès qu'il arrive. Le scénario n'a pas de sleep, et le délai mesuré est celui de votre parcours.

04

Le code déjà extrait

message.otp

Le monitor lit le champ otp au lieu de chercher le code dans le corps du message avec une expression régulière.

05

Protéger la surveillance de la CI

Une inbox de supervision n'a pas encore de réserve à elle. D'ici là, posez un plafond sur les inboxes de CI et de test de charge : un test qui s'emballe s'arrête à sa limite, au lieu de vider le volume dont vos monitors ont besoin.

06

La mesure est à vous

Votre outil de surveillance mesure le délai de chaque exécution. Vous le seuillez là où vivent déjà vos astreintes, et c'est cet outil qui décide qui réveiller.

Pas encore

Ce qui n'est pas encore disponible

Chaque ligne décrit l'état d'aujourd'hui.

01
Pas encore

Une capacité réservée à la supervision

Une inbox marquée « supervision » aurait sa propre réserve, et continuerait d'accepter même quand le compte est épuisé. Cette réserve n'existe pas aujourd'hui : une inbox de supervision consomme le même volume que les autres.

02
Pas encore

Le temps de réception en métrique

Facteur ne publie pas encore de métrique de réception à seuiller. Chaque message porte son temps de réception dans le champ deliveryMs, que votre monitor peut lire.

03
Pas encore

Le mode performance

Confirmer la réception, mesurer, et ne rien garder. Ce mode n'est pas proposé aujourd'hui : un message reçu est gardé pendant la durée de votre offre.

04
Pas encore

Une clé limitée à une inbox ou à des adresses IP

Aujourd'hui, une clé se limite à des espaces de travail. Elle ne se limite ni à une seule inbox, ni à des adresses IP.

Intégrations

Depuis l'outil que vous utilisez déjà

Il n'y a rien à installer : une clé en lecture seule et un appel HTTP qui attend.

01

Datadog Synthetics

Un test API multi-étapes : déclencher le parcours, attendre le message, extraire le code, poursuivre.

02

Grafana Synthetic Monitoring

Même principe, avec des vérifications scriptées en k6.

03

Checkly

Des scénarios Playwright joués en continu, avec un appel HTTP à la recherche de messages.

04

StatusCake, Uptrends

Pour les vérifications simples : le message arrive-t-il, et en combien de temps.

05

Votre propre ordonnanceur

Un cron et deux appels HTTP suffisent. L'API attend le message pour vous.

Surveillez ce qui compte vraiment

Un parcours validé par e-mail, rejoué toutes les cinq minutes depuis votre outil de surveillance, avec une clé qui ne fait que lire.