# Rejouer un parcours utilisateur en continu avec un monitoring synthétique

> Apprendre une panne par un appel client plutôt que par une alerte n'est jamais confortable. Voici comment programmer un scénario de test rejoué en continu contre la production.

- Auteur : Clément Hadrot
- Publié le : 2025-03-17
- Mis à jour le : 2025-03-17
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/rejouer-parcours-monitoring-synthetique/

## L’essentiel

- Un scénario critique rejoué toutes les cinq minutes contre le site réel
- Une alerte envoyée avant que le client ne s'en aperçoive
- Un historique des temps de réponse conservé pour repérer une dérive lente

Le formulaire de prise de rendez-vous a cessé de fonctionner un vendredi à seize heures. Ce n'est pas une alerte technique qui l'a signalé, mais un appel téléphonique d'un client agacé de ne plus pouvoir réserver de créneau. Entre la panne réelle et sa détection, plus de trois heures se sont écoulées, pendant lesquelles chaque visiteur du site a rencontré la même erreur silencieuse.

Les outils de surveillance déjà en place remontaient bien les erreurs applicatives, les journaux PHP et les temps de réponse serveur. Mais aucun d'eux ne rejouait le parcours exact qu'un visiteur suit pour prendre rendez-vous : ouvrir le formulaire, choisir un créneau, valider. Un monitoring synthétique comble précisément ce manque, en simulant un utilisateur réel à intervalles réguliers.

## La différence entre surveiller des erreurs et surveiller un comportement

Un système d'observation des erreurs applicatives réagit à ce qui se produit : une exception levée, un code HTTP 500 retourné. Un monitoring synthétique, à l'inverse, provoque activement une action et vérifie que le résultat attendu se produit bien, même quand aucune exception n'est levée. Dans le cas du formulaire de rendez-vous, la panne venait d'un script JavaScript tiers qui bloquait silencieusement la soumission sans jamais déclencher d'erreur serveur : rien à observer côté journaux, tout à observer côté comportement.

## Écrire le scénario critique avec Playwright

Le scénario surveillé reprend exactement les étapes qu'un visiteur suit, sans raccourci technique qui contournerait l'interface réelle :

```
import { test, expect } from '@playwright/test';

test('prise de rendez-vous depuis la page publique', async ({ page }) => {
  await page.goto('https://www.exemple-cabinet.fr/rendez-vous');
  await page.getByLabel('Type de consultation').selectOption('premiere-visite');
  await page.getByRole('button', { name: 'Voir les créneaux' }).click();
  await page.getByRole('button', { name: /Créneau du/ }).first().click();
  await page.getByLabel('Adresse e-mail').fill('surveillance@exemple-cabinet.fr');
  await page.getByRole('button', { name: 'Confirmer le rendez-vous' }).click();

  await expect(page.getByText('Votre rendez-vous est confirmé')).toBeVisible();
});
```

Ce scénario s'exécute contre le site de production réel, avec un compte de test dédié et un créneau réservé spécifiquement à la surveillance, pour ne jamais interférer avec un vrai créneau destiné à un patient.

### Programmer l'exécution régulière

Une tâche planifiée déclenche ce scénario toutes les cinq minutes, indépendamment de la pipeline d'intégration continue habituelle, qui elle ne s'exécute qu'au moment des déploiements :

```
*/5 * * * * cd /var/www/surveillance && npx playwright test rendez-vous.spec.js
```

> L'essentiel à retenir : Un scénario critique rejoué toutes les cinq minutes contre le site réel ; Une alerte envoyée avant que le client ne s'en aperçoive ; Un historique des temps de réponse conservé pour repérer une dérive lente

## Déclencher une alerte avant que le client ne s'en aperçoive

L'intérêt du monitoring synthétique tient entièrement à la rapidité de l'alerte. Un échec du scénario déclenche immédiatement une notification, avec la capture d'écran automatique que Playwright produit au moment de l'échec, jointe au message pour accélérer le diagnostic :

```
if (testInfo.status !== testInfo.expectedStatus) {
  await envoyerAlerte({
    message: `Échec du parcours rendez-vous à ${new Date().toISOString()}`,
    capture: testInfo.attachments.find(a => a.name === 'screenshot'),
  });
}
```

## Suivre la dérive lente, pas seulement la panne franche

Au-delà de la panne binaire, conserver le temps d'exécution de chaque passage du scénario permet de repérer une dégradation progressive : un formulaire qui répond en huit cents millisecondes un lundi et en trois secondes le vendredi suivant, sans jamais franchir un seuil d'échec explicite, révèle souvent un problème naissant, comme une base de données qui grossit sans index adapté.

| Type de signal | Détecté par | Délai typique |
| --- | --- | --- |
| Erreur PHP journalisée | Observation des erreurs applicatives | Quasi immédiat |
| Blocage silencieux côté interface | Monitoring synthétique | Selon l'intervalle programmé |
| Dérive lente du temps de réponse | Historique du monitoring synthétique | Sur plusieurs jours |

### Choisir un nombre restreint de scénarios critiques

Surveiller ainsi chaque page du site serait coûteux à maintenir et peu utile. Le choix se limite volontairement aux deux ou trois parcours dont l'interruption a un impact direct sur l'activité : la prise de rendez-vous ici, ailleurs ce serait un tunnel d'achat ou un formulaire d'inscription à un service payant.

> Un scénario de monitoring synthétique n'a de valeur que s'il échoue vraiment quand quelque chose casse. Un scénario trop permissif rassure à tort ; mieux vaut le tester en cassant volontairement le parcours en environnement de recette avant de le déployer en production.

## En résumé

Rejouer un parcours utilisateur critique toutes les cinq minutes contre la production ne remplace ni les tests automatisés classiques ni l'observation des erreurs applicatives : cela comble l'angle mort qui existe entre les deux, celui d'un comportement silencieusement cassé sans exception levée. La différence se mesure en heures, parfois en clients qui n'ont jamais eu à appeler pour signaler une panne que le site avait déjà détectée lui-même.