Externaliser ses tests E2E : le guide tech (architecture, sécurité, intégration CI)

Externaliser ses tests E2E ne veut pas dire abandonner le contrôle technique. Cet article explique comment intégrer un service de monitoring Playwright managé dans votre stack : format des tests, gestion des secrets, hooks CI/CD, isolation et alerting. Pour CTO, lead devs et SRE.

1. L'architecture cible, en une vue

Voici comment se branche un service externalisé sur votre stack existante :

# Flux nominal d'un run programme

  +-----------+         +----------+         +----------+
  | Cron / CI | ----->  | Webhook  | ----->  | Runner   |
  +-----------+   POST  +----------+         | Playw.   |
                                             +----------+
                                                  |
                  +---------+    rapport          |
                  | Storage | <-------------------+
                  +---------+
                       |
            screenshots, traces, video
                       |
                       v
                +-------------+      alerte echec
                |  Dashboard  | ---> Slack / email / webhook
                +-------------+

Trois entrées possibles pour déclencher un test :

• Planification (cron interne au service) - pour le monitoring continu, par exemple toutes les 15 minutes.
• Webhook depuis votre CI/CD - pour valider chaque déploiement.
• Webhook depuis un outil externe (n8n, Zapier, Lambda) - pour des cas d'usage custom.

2. Format des tests : pas de magie propriétaire

La règle d'or : vos tests doivent rester portables. Si demain vous changez de prestataire ou re-internalisez, vous ne devez pas avoir à réécrire votre suite.

Concrètement, un service sérieux accepte des fichiers .spec.ts Playwright standard, avec la même config playwright.config.ts que celle utilisée en CI :

// signup.spec.ts - exactement le meme code qu'en CI
import { test, expect } from "@playwright/test";

test("signup happy path", async ({ page }) => {
  await page.goto("/signup");
  await page.getByTestId("email").fill("qa+monitor@example.com");
  await page.getByTestId("password").fill(process.env.PW_TEST_PWD!);
  await page.getByTestId("submit").click();
  await expect(page).toHaveURL("/welcome");
});

Les tests passent en lecture seule sur la prod, ou utilisent des comptes de test dédiés (cf section sur les secrets).

3. Secrets & authentification

C'est le point qui inquiète le plus les CTO, à juste titre. Trois principes :

1. Comptes de test dédiés, pas de comptes utilisateur réels

Vous créez sur votre application un ou plusieurs comptes qa-monitor-*@votredomaine.com avec des permissions limitées. Ces comptes sont les seuls que le runner utilise.

2. Secrets chiffrés au repos, déchiffrés à l'exécution

Les credentials sont stockés chiffrés dans la base du service (typiquement avec une clé KMS) et déchiffrés uniquement par le worker qui exécute le test, en mémoire.

3. Rotation simple

Vous devez pouvoir changer un mot de passe ou une clé API depuis le dashboard, sans avoir à déclencher un re-déploiement. Un service correctement architecturé propose une UI de gestion des secrets par client.

4. Intégration CI/CD

Le pattern classique : déclencher un run après chaque déploiement réussi en production. Voici un exemple GitLab CI :

# .gitlab-ci.yml
deploy_prod:
  stage: deploy
  script: ./scripts/deploy.sh prod

smoke_test_prod:
  stage: post-deploy
  needs: [deploy_prod]
  script: |
    # 1. Declencher le run de monitoring
    JOB=$(curl -sS -X POST \
      "https://prod-watch.com/api/webhook/run/$PW_SLUG" \
      -H "Authorization: Bearer $PW_TOKEN" | jq -r .jobId)

    # 2. Attendre le resultat (max 5 min)
    for i in $(seq 1 30); do
      sleep 10
      STATUS=$(curl -s \
        "https://prod-watch.com/api/webhook/status/$JOB" \
        -H "Authorization: Bearer $PW_TOKEN" | jq -r .status)
      if [ "$STATUS" != "running" ]; then break; fi
    done

    # 3. Faire echouer le pipeline si le smoke test casse
    [ "$STATUS" = "passed" ] || exit 1

Avec ce pattern, un déploiement qui casserait un parcours critique fait échouer la CI, ce qui peut déclencher un rollback automatique. Vous pouvez voir notre documentation webhook pour les détails.

Mode callback (push)

Si vous préférez ne pas faire de polling depuis votre CI, le service peut vous notifier sur une URL de callback :

curl -X POST "https://prod-watch.com/api/webhook/run/$PW_SLUG" \
  -H "Authorization: Bearer $PW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "callback_url": "https://ci.example.com/hooks/qa" }'

5. Isolation & sécurité

Un service multi-tenant doit garantir trois niveaux d'isolation :

• Réseau - chaque runner est isolé dans son propre conteneur, sans accès aux autres clients.
• Stockage - les rapports, screenshots et vidéos sont scopés par client. Une fuite cross-tenant doit être impossible par construction.
• API - les tokens sont scopés à un client. Aucune route ne doit retourner de données d'un autre tenant, même avec un token valide.

Côté Prod Watch, les sessions admin et client utilisent deux middlewares différents (requireClientContext). Une requête authentifiée comme client A ne peut techniquement pas accéder aux données du client B, même avec un bug d'autorisation.

6. Alerting & webhook

L'alerting doit être configurable par parcours et par canal. Notre stack par défaut :

• Slack via webhook entrant - le canal #qa-alerts reçoit les échecs avec lien direct vers le rapport.
• Email SMTP - utile pour le on-call et les escalades automatiques.
• Webhook custom - pour brancher PagerDuty, Opsgenie, ou un outil interne.

Le payload d'alerte type ressemble à ça :

{
  "event": "run_failed",
  "client": "acme-corp",
  "runId": "r_2026_05_01_03h12_4f8",
  "failedTests": [
    {
      "name": "signup happy path",
      "file": "signup.spec.ts",
      "error": "Timeout 5000ms exceeded waiting for [data-testid=submit]",
      "reportUrl": "https://prod-watch.com/report/r_2026_05_01_..."
    }
  ],
  "timestamp": "2026-05-01T03:12:44Z"
}

7. Observabilité côté client

Vous devez avoir accès, depuis votre dashboard :

• L'historique de tous les runs (succès / échec) avec filtres par parcours et plage de dates.
• Les rapports détaillés : screenshots étape par étape, traces réseau, console logs, vidéo.
• Les métriques : durée moyenne par parcours, taux de succès, MTTD (mean time to detect).
• L'export CSV ou API pour intégrer ces données dans votre BI interne (Grafana, Metabase).

8. Checklist d'évaluation d'un prestataire

Avant de signer, posez ces 10 questions :

1. Acceptez-vous mes tests Playwright actuels sans réécriture ?
2. Comment sont stockés et chiffrés mes credentials de test ?
3. Puis-je rotater mes secrets depuis l'UI ?
4. Avez-vous une isolation réseau / stockage / API entre clients ?
5. Comment se fait l'intégration avec ma CI (webhook, polling, callback) ?
6. Quelle est la latence d'alerte entre l'échec et la notification ?
7. Puis-je configurer plusieurs canaux d'alerte (Slack, email, webhook) ?
8. Combien de temps gardez-vous mes rapports / vidéos ?
9. Quelle est votre politique de SLA et de RGPD ?
10. Comment puis-je récupérer mes données et tests si je quitte le service ?