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.
// É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
// 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);
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.
-
01
Le monitor crée un compte sur votre environnement de production, avec une adresse unique dans votre inbox de supervision.
-
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.
-
03
Il lit le code, déjà isolé du corps du message, et termine l'inscription.
-
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.
Surveiller n'est pas tester
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.
Clés en lecture seule
ws:readUn 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.
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.
Le code déjà extrait
message.otpLe monitor lit le champ otp au lieu de chercher le code dans le corps du message avec une expression régulière.
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.
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.
Ce qui n'est pas encore disponible
Chaque ligne décrit l'état d'aujourd'hui.
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.
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.
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.
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.
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.
Datadog Synthetics
Un test API multi-étapes : déclencher le parcours, attendre le message, extraire le code, poursuivre.
Grafana Synthetic Monitoring
Même principe, avec des vérifications scriptées en k6.
Checkly
Des scénarios Playwright joués en continu, avec un appel HTTP à la recherche de messages.
StatusCake, Uptrends
Pour les vérifications simples : le message arrive-t-il, et en combien de temps.
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.