Ce que je lance avant de dormir
Chaque soir, avant de fermer mon ordinateur portable, je lance une seule commande. Elle vérifie 15 000 pages sur mon site de production : chaque article de blog, chaque page entreprise, chaque guide programmatique, chaque variante locale. Pour chaque page, elle contrôle le statut HTTP, mesure le TTFB, vérifie le statut du cache Cloudflare et enregistre les éventuelles erreurs. La vérification complète prend environ 6 heures. Elle tourne en arrière-plan pendant que je dors.
Je lance également une vérification rapide du chemin critique, qui se termine en 2 minutes : endpoints de santé, sitemaps, pages de revenus, hubs entreprise S-tier, pages marché, index de contenu programmatique, archives blog i18n. Celle-là, je la surveille. Si quoi que ce soit échoue, j’enquête avant de dormir.
La routine produit un rapport qui ressemble à ceci :
NIGHTCHECK -- 2026-03-27 (morning)
Overnight comprehensive: 16,228/16,602 ok (97.7%)
Avg TTFB: 715ms
S-tier companies: ALL PASS, ALL HIT
Markets: ALL PASS (89-175ms HIT)
i18n blogs: es 95ms HIT | ja 196ms HIT | de 181ms HIT
Personne ne me demande de faire ça. Aucun ticket ne l’exige. Aucun sprint n’inclut « lancer le nightcheck ». Cette routine existe parce que je tiens à ce que le site fonctionne quand je ne le regarde pas.
Pourquoi chaque nuit
Le site change tous les jours. En une seule journée, je peux déployer 87 commits : traductions i18n, mises à jour de fournisseurs de crawl, expériences CRO, corrections de performance, remédiations de logos. Chaque commit est testé individuellement. Mais la composition de 87 commits peut produire des défaillances qu’aucun commit isolé ne révèle.
Un lot de traductions peut pousser le sitemap du blog au-delà d’un seuil de rendu. Un nouveau fournisseur peut introduire une page entreprise qui met 14 secondes à s’afficher. Un changement d’en-tête de cache peut amener Cloudflare à ne plus mettre en cache une route qui était rapide auparavant. Un refactoring CSS peut casser un template dans une locale sans affecter les autres.
Le nightcheck détecte les défaillances de composition. Non pas « est-ce que ce commit a cassé quelque chose », mais « est-ce que le site fonctionne après que tout ce qui a atterri aujourd’hui ». La distinction compte, car les défaillances de composition sont invisibles en CI. Chaque commit réussit ses propres tests. Le comportement agrégé de 87 commits réussissant chacun leurs tests ne garantit pas que le système global fonctionne.
Ce qui est mesuré
La vérification comporte quatre niveaux :
P0 Infrastructure. L’endpoint de santé renvoie un état sain avec la base de données connectée. Les sitemaps retournent du XML valide. robots.txt et llms.txt sont présents. Le flux RSS est valide. Ce sont les éléments qui, s’ils sont cassés, rendent le site invisible pour les moteurs de recherche.
P0 Revenus. La page d’accueil, le générateur de CV, l’analyseur et la page de tarification se chargent tous correctement. Ce sont les pages qui, si elles sont cassées, coûtent directement de l’argent. Le générateur de CV est historiquement la page la plus lente et dispose d’un seuil d’avertissement à 5 secondes.
P1 Surface SEO. L’archive du blog, les pages hub piliers, l’annuaire entreprise, la navigation emploi, les cinq index de contenu programmatique (guides de CV, guides de salaires, guides de lettres de motivation, questions d’entretien, mots-clés ATS), quatre échantillons blog i18n et les 20 hubs entreprise S-tier. Ce sont les pages qui génèrent le trafic organique. Un 404 sur la page Google est un incident SEO.
P2 Exhaustif. Chaque URL dans les sitemaps blog et entreprise. C’est la vérification de fond de 6 heures. Elle attrape les défaillances de longue traîne : un article de blog isolé qui renvoie une erreur 500 à cause d’une citation mal formée, une page entreprise qui expire à cause d’une requête N+1 sur une grande entreprise.
Chaque page est vérifiée avec curl en utilisant un en-tête User-Agent réaliste. Un curl brut se fait bloquer par un 403 de Cloudflare. L’en-tête de statut du cache est capturé en même temps que le statut HTTP et le TTFB. Une page peut retourner 200 tout en affichant DYNAMIC alors qu’elle devrait être HIT, ce qui signifie que la règle de cache est mal configurée. La mesure du TTFB correspond à la latence réelle côté serveur, pas au temps de rendu du navigateur.
La tendance TTFB
Je lance cette vérification depuis mars 2026. La tendance TTFB raconte l’histoire de la performance :
| Date | TTFB moyen | Page la plus lente | Statut cache |
|---|---|---|---|
| 21 mars (post-purge) | 1 156 ms | Austin market 14 290 ms | ALL DYNAMIC |
| 23 mars (cache actif) | 958 ms | markets 2-3s | Most HIT |
| 25 mars (correction requête) | 715 ms | ats-optimization 6,3s | All HIT |
| 27 mars (stable) | 715 ms | zh-hans/blog 3,7s | 34/36 HIT |
La tendance capture le parcours de performance des pages marché : la purge du cache a exposé le problème (14,3s), la mise en cache edge l’a masqué (89-175 ms HIT), la correction de la forme de requête a résolu la cause sous-jacente (108 ms origin). Sans la tendance nocturne, j’aurais cru que le cache edge était la solution. Les mesures de TTFB ont prouvé que le rendu d’origine était encore lent lors de la revalidation, ce qui a justifié le refactoring de la requête.
Le nightcheck n’a pas corrigé le problème de performance. Il a rendu le problème de performance mesurable, ce qui l’a rendu corrigeable.
Ce que personne ne voit
L’aspect le plus précieux du nightcheck, c’est qu’il tourne quand personne ne regarde. Il n’y a pas de notification Slack pour « 16 228 pages passées cette nuit ». Il n’y a pas de tableau de bord qui passe au vert. Le rapport existe dans un fichier de log que je lis le lendemain matin avec mon café.
L’absence de cérémonie, c’est précisément l’essentiel. Le nightcheck n’est pas de la qualité performative. Ce n’est pas une métrique pour un standup. C’est une discipline privée : est-ce que tout a fonctionné pendant que je dormais ? Si oui, très bien. Si non, je sais exactement ce qui a échoué et quand.
La discipline se cumule. La vérification de chaque nuit établit une référence pour la comparaison du lendemain. Une augmentation de TTFB de 50 ms sur une page spécifique déclenche une investigation, non pas parce que 50 ms comptent pour les utilisateurs, mais parce que l’augmentation indique que quelque chose a changé. Peut-être qu’une nouvelle dépendance a ajouté de la latence. Peut-être qu’une règle de cache a expiré. Peut-être qu’une requête de base de données a grandi avec le jeu de données. La référence nocturne rend la dérive visible avant qu’elle ne devienne un problème.
C’est le contexte composé appliqué aux opérations. Chaque vérification nocturne dépose un point de données. Les points de données s’accumulent en une tendance. La tendance rend visibles des problèmes qu’aucune vérification isolée ne révélerait.
La routine est le standard
Je pourrais automatiser le nightcheck dans un cron job et consulter un tableau de bord. Je choisis de le lancer manuellement parce que l’acte de le lancer entretient l’habitude d’en avoir quelque chose à faire. À l’instant où la vérification devient le travail de quelqu’un d’autre, ou une notification que je balaie, ou un tableau de bord que je ne consulte plus, le standard s’érode.
Le standard n’est pas « le site passe des vérifications automatisées ». Le standard est « j’ai personnellement vérifié que le site fonctionne avant d’aller dormir ». La différence, c’est la responsabilité. Une vérification automatisée qui échoue silencieusement est un bug de l’automatisation. Une vérification manuelle que je saute est un choix que j’ai fait sur ce qui m’importe.
Je le lance chaque soir parce que l’alternative est de faire confiance au fait que tout fonctionne encore. La confiance sans vérification, c’est de l’espoir. L’espoir n’est pas une stratégie opérationnelle.
FAQ
Combien de temps dure la vérification complète ?
La vérification rapide du chemin critique prend 2 à 3 minutes (36 pages avec mesure du TTFB et du cache). La vérification exhaustive des sitemaps prend 5 à 7 heures (plus de 15 000 pages). La vérification rapide s’exécute de manière synchrone ; la vérification exhaustive tourne en arrière-plan.
Pourquoi ne pas utiliser un service de surveillance de disponibilité ?
Les services de disponibilité vérifient si une page retourne 200. Le nightcheck vérifie si une page retourne 200 avec le statut de cache correct, un TTFB acceptable et la structure de contenu attendue. Une page qui retourne 200 mais met 14 secondes avec un cache DYNAMIC est techniquement en ligne et opérationnellement cassée.
Que se passe-t-il quand quelque chose échoue ?
J’enquête avant de dormir si la défaillance concerne une page de revenus ou d’infrastructure. Pour les défaillances de la vérification exhaustive, je consulte le log le lendemain matin et je priorise par type de page. Un article de blog défaillant est moins prioritaire qu’un hub entreprise défaillant. Un cache DYNAMIC sur une page à fort trafic est plus prioritaire qu’un TTFB lent sur une page à faible trafic.
Est-ce que ça passe à l’échelle ?
15 000 pages, c’est l’échelle actuelle. La vérification exhaustive est limitée par les I/O (requêtes curl séquentielles), pas par le calcul. Doubler le nombre de pages double la durée. À 30 000 pages, la vérification prendrait 12 heures, ce qui tient encore dans une fenêtre nocturne. Au-delà, une vérification parallèle avec limitation de débit serait nécessaire.