CI vs monitoring synthétique : pourquoi vous avez besoin des deux (et comment les combiner)

"On a déjà des tests dans la CI." C'est la phrase qu'on entend une fois par semaine. Et elle révèle une confusion fréquente entre deux disciplines complémentaires : les tests CI valident le code, le monitoring synthétique valide l'expérience utilisateur en production. Ce sont deux problèmes différents, et vous avez besoin des deux.

1. La confusion classique

Quand un dirigeant nous demande "pourquoi je paierais pour du monitoring si ma CI passe au vert ?", la réponse tient en une question : est-ce que vous savez si votre site fonctionne là, maintenant, pour vos vrais utilisateurs ?

La CI répond à : "est-ce que mon code source produit l'output attendu dans un environnement contrôlé ?"

Le monitoring synthétique répond à : "est-ce que mon site rend le service attendu en production, avec ses vraies dépendances ?"

Ce ne sont pas les mêmes questions. Ce ne sont pas les mêmes pannes détectées. Ce ne sont pas les mêmes équipes alertées.

2. Le rôle de la CI : valider le code avant qu'il sorte

La CI (Continuous Integration) est votre garde-fou côté code. Son objectif : empêcher qu'une modification cassée n'arrive en production. Elle s'exécute :

• À chaque commit / pull request.
• Sur un environnement contrôlé (staging ou conteneur éphémère).
• Avec des dépendances mockées ou stubées (paiement, services tiers).
• Avec un dataset de test connu.

Ses points forts : rapide (moins de 10 minutes), déterministe (même résultat à chaque run), fournit un feedback immédiat au développeur.

Ses limites : ne voit pas les pannes externes (CDN, paiement, DNS), ne reflète pas la performance réelle, ne tourne pas après le déploiement.

3. Le rôle du monitoring synthétique : valider l'UX en continu

Le monitoring synthétique joue les vrais utilisateurs sur la prod, en boucle. Il s'exécute :

• Toutes les X minutes (typiquement 5 à 30 min selon la criticité).
• Sur la production, avec les vraies API, vraies dépendances tierces, vrais navigateurs.
• Depuis des localisations géographiques variées (Paris, US East, etc.).
• Avec des comptes de test dédiés, jamais des données utilisateur réelles.

Ses points forts : détecte les pannes invisibles depuis le code (DNS, SSL, lenteur d'un PSP, CDN cassé, dépendances tierces dégradées), mesure la performance réelle, alerte 24/7 sans intervention humaine.

Ses limites : ne préviendra pas un bug avant qu'il sorte (c'est le job de la CI). Plus lent à donner un feedback (vous découvrez le problème après le déploiement, pas avant).

4. Tableau de différences

5. Bugs typiques détectés par chacun

Détectés uniquement par la CI

• Bug de logique métier (calcul de TVA incorrect).
• Régression sur un endpoint API quand le code est modifié.
• Mauvaise gestion d'un cas edge dans un formulaire.
• Erreur TypeScript / lint qui casserait le build.

Détectés uniquement par le monitoring synthétique

• Le certificat SSL a expiré pendant le week-end.
• Le PSP (Stripe / Adyen) a un incident, vos paiements échouent.
• Une variable d'environnement de prod a été mal mise à jour.
• Une mise à jour de DNS a cassé un sous-domaine.
• Un CDN a un cache empoisonné qui sert du HTML cassé.
• Une lenteur générale (5s pour charger une page) qui ne casse rien mais fait fuir les visiteurs.
• Un déploiement infra fait par l'équipe ops (pas par la CI applicative) qui casse silencieusement.

Détectés par les deux (avec des angles différents)

• Une régression front qui passe les tests CI mockés mais casse en prod avec les vraies données.
• Un bug d'intégration entre deux services maintenus par deux équipes.
• Une migration de schéma de base qui n'a pas tout couvert.

6. Comment les combiner intelligemment

La meilleure architecture combine les deux disciplines avec un flux clair :

commit -> CI (unit + integration + E2E sur staging)
              |
              v (merge si vert)
         deploy prod
              |
              +-> smoke test post-deploy (E2E rapide, ~3 tests critiques)
              |
              v
         monitoring synthetique 24/7 sur les memes parcours
              |
              v (en cas d'echec)
         alerte Slack / PagerDuty

Quelques principes clés :

1. Réutilisez vos tests Playwright entre CI et monitoring. Pas besoin de réécrire : les mêmes .spec.ts tournent en CI et en monitoring synthétique. C'est exactement le modèle de Prod Watch.
2. Distinguez les fixtures : en CI, vous mockez Stripe et utilisez une fake DB. En monitoring, vous utilisez les vrais endpoints avec des comptes de test.
3. Pareto de couverture : 100% des PRs en CI, 5 à 10 parcours critiques en monitoring. Pas besoin de tout dupliquer.
4. Latence d'alerte : la CI alerte le dev qui a poussé. Le monitoring alerte le on-call et le dirigeant. Deux audiences, deux canaux.

7. Mesurer l'efficacité de votre dispositif

Les métriques à suivre :

• MTTD (Mean Time To Detect) : combien de temps entre l'apparition d'un bug en prod et sa détection ? La CI ne détecte pas les bugs en prod, donc le monitoring est seul juge ici. Cible : moins de 15 minutes.
• MTTR (Mean Time To Resolve) : combien de temps entre la détection et la résolution ? Bonifié par la qualité des rapports d'alerte (screenshots, traces).
• Taux de détection externe : combien de bugs en prod ont été remontés par un client plutôt que par votre monitoring ? Cible : moins de 10%.
• Couverture des parcours critiques : sur vos parcours business, combien sont monitorés en synthétique ? Cible : 100% sur les top 5.