Prod Watch : qui sommes-nous et comment on surveille vos parcours critiques 24/7

Vos utilisateurs ne devraient jamais être les premiers à voir un bug. C'est cette conviction qui a donné naissance à Prod Watch : un service de monitoring QA continu qui exécute vos tests Playwright sur votre production, en boucle, et vous alerte au premier signe de défaillance.

1. Notre mission

Prod Watch existe pour répondre à une question simple : est-ce que mon site fonctionne là, maintenant, pour mes vrais utilisateurs ?

Pas en environnement de staging. Pas dans le pipeline CI qui passe au vert depuis trois jours. En production, avec les vraies données, les vrais services tiers, les vrais navigateurs des vrais clients.

Notre travail consiste à détecter les régressions avant qu'elles ne génèrent un ticket support, une perte de chiffre d'affaires, ou un appel d'un client mécontent. Pas à les détecter après.

2. Le problème qu'on résout

La plupart des équipes produit que nous accompagnons ont une suite de tests automatisés. Le problème, c'est qu'elle ne tourne que dans la CI, sur staging, et pas suffisamment souvent en production. Résultat :

• Un déploiement qui passe les tests CI mais casse en prod à cause d'une dépendance externe (API tierce, CDN, paiement).
• Un changement de configuration applicatif (DNS, SSL, header) qui n'est pas couvert par les tests unitaires.
• Un parcours métier critique (signup, paiement, checkout) qui se dégrade silencieusement, et qu'on découvre via un email client trois jours plus tard.

Le coût d'un de ces incidents dépasse largement celui d'un service de monitoring continu. Et le pire, c'est qu'on ne mesure jamais combien de bugs passent sous le radar sans même générer de plainte, simplement parce que l'utilisateur abandonne.

3. Comment ça marche, concrètement

Quatre étapes seulement, du onboarding au monitoring 24/7 :

1. Vous nous donnez vos tests Playwright (ou on les écrit pour vous, à partir de vos parcours critiques). Le format est standard : .spec.ts classique, aucune librairie propriétaire.
2. On les exécute selon votre cadence : toutes les 5 minutes, toutes les heures, à chaque déploiement, ou via webhook depuis votre CI.
3. Chaque exécution génère un rapport complet : screenshots à chaque étape, traces réseau, logs, vidéo en cas d'échec. Tout est centralisé dans un dashboard par client.
4. En cas d'échec, on vous alerte immédiatement via Slack, email ou webhook custom. Vous savez exactement ce qui a cassé, sur quel parcours, depuis quand.

4. L'architecture, en deux mots

Pour les CTO et lead devs qui se demandent ce qui tourne réellement :

• Runner Playwright isolé dans un environnement Docker, avec navigateurs Chromium / Firefox / WebKit à jour.
• Backend Express qui orchestre les runs, stocke les rapports et expose une API REST + webhook.
• Dashboard React avec deux vues séparées : une admin (pour notre équipe) et une client (pour vous).
• Storage : SQLite pour les métadonnées, fichiers locaux pour les artefacts (screenshots, traces, vidéos).
• Alerting branché sur Slack, email SMTP, et n'importe quel webhook entrant (n8n, Zapier, custom).

On ne stocke jamais de données utilisateur sensibles. Les comptes de test que vous nous fournissez sont chiffrés et accessibles uniquement par les runners. Plus de détails dans nos mentions légales.

5. Notre différence vs les outils SaaS classiques

Il existe plusieurs catégories d'outils de monitoring : Pingdom, UptimeRobot pour le ping HTTP, Datadog Synthetic ou Checkly pour les checks scriptés, Sentry pour le frontend. Voici ce qui nous distingue :

La grande différence : les tests qui passent dans votre CI sont exactement ceux qui tournent sur votre production. Pas de divergence, pas de double maintenance, pas de syntaxe à apprendre.

6. À qui on s'adresse

Prod Watch est conçu pour :

• Les e-commerçants qui veulent garantir que checkout, paiement et création de compte fonctionnent en permanence.
• Les SaaS B2B qui ne peuvent pas se permettre une page de login cassée à 9h du matin.
• Les sites éditoriaux à forte audience qui veulent monitorer leurs flows d'inscription, paywall et abonnement.
• Les agences web qui livrent des sites client et veulent leur fournir une garantie de bon fonctionnement post-livraison.

Le point commun : un site où une heure de panne sur un parcours critique coûte plus cher qu'un mois de monitoring.

7. Comment commencer

Le onboarding prend environ une heure :

1. Audit gratuit : on identifie ensemble vos 3 à 5 parcours les plus critiques.
2. Setup des tests Playwright (les vôtres, ou écrits par notre équipe).
3. Configuration des canaux d'alerte (Slack, email, webhook).
4. Mise en route, et premier rapport sous 24h.

Pas d'engagement long, pas de setup fee. On commence par un audit gratuit et un mois d'essai pour mesurer la valeur sur vos vrais parcours.