Vérifications
Un 200 ne veut pas dire que la page marche
Une page de paiement qui répond parfaitement, avec un bouton mort et un prix disparu, renvoie un statut 200. Toute surveillance qui s'arrête là vous dit que tout va bien.
« Le monitoring était au vert pendant que le checkout ne prenait plus les cartes. »
Un code de statut décrit la réponse du serveur, pas ce que le visiteur peut faire.
- types de vérification
- 22
- délai maximum par URL
- 12 s
- corps de page conservé
- 0
- de journal technique
- 90 j
Ce qui est réellement contrôlé
La page répond, et ses ressources arrivent
Statut HTTP, temps de réponse, et le chargement effectif des scripts et feuilles de style déclarés.
Le parcours de paiement
Sur les pages qui encaissent — panier, paiement, confirmation — la présence du prix et du script Stripe est vérifiée explicitement.
Ce que voient les réseaux et les moteurs
Titre et image Open Graph valides, canonical cohérent, sitemap qui répond, indexabilité — un robots.txt ou une balise meta qui bloque tout est une régression silencieuse qu'aucun visiteur ne vous signalera jamais.
Le ce qui a changé
Une page qui existait et qui se retrouve remplacée par « coming soon », par une erreur 5xx ou par une coquille vide : le contenu a changé de nature sans que l'URL bouge.
Les 22 contrôles, un par un
Ce ne sont pas des catégories commerciales : ce sont les noms que l'app affiche sur chaque URL, dans l'ordre où elle les groupe. Un contrôle qui ne concerne pas votre site s'éteint et ne dit plus rien.
La page
- HTTPle code de réponse et les ressources chargées
- Balisestitle, description, canonical, viewport
- OG / Twitterla carte de partage et son image
- Redirectionshttp vers https, avec et sans www
- Poids de pagela page et ses ressources
- Accessibilitélangue, h1, textes alternatifs, étiquettes
L'argent et les parcours
- Stripe healthStripe.js chargé, page de retour en 2xx
- Parcoursun enchaînement de pages, étape par étape
- Formulairel'envoi est accepté, sans erreur serveur
- Contrat d'APIla réponse reste le JSON attendu
- Battementvotre tâche planifiée se signale à l'heure
Le domaine
- SSLl'échéance du certificat
- Certificatsceux qu'on émet pour votre domaine
- Email (DNS)MX, SPF, DKIM, DMARC
- Sitemapses URLs répondent, aucune ne disparaît
- Indexabilitérobots.txt, noindex, canonical
- Visibilité IAce que les robots des IA peuvent lire
Ce qui fuit
- Sécuritéles en-têtes qui protègent vos visiteurs
- Fuitesclé secrète, lorem ipsum, adresse de préprod
- Fichiers exposés.env, .git, sauvegardes
- Cookiestraceurs avant consentement, Secure, HttpOnly
- Scripts tiersun contenu modifié chez le fournisseur
Ce que ça ne fait pas
Un outil qui ne dit jamais ses limites vous les fait découvrir un dimanche. Les voici écrites.
Ce n'est pas un navigateur
Les vérifications lisent le HTML que votre serveur envoie. Une page dont le prix n'apparaît qu'après l'exécution du JavaScript est vue sans son prix — c'est d'ailleurs ce que voit un moteur de recherche, et c'est souvent l'information utile.
Le corps des pages n'est pas conservé
Statut, temps de réponse, quelques métadonnées. Aucun contenu de page n'est stocké, et un extrait de journal est coupé à 500 caractères. Vous ne pouvez pas nous demander ce qu'il y avait sur la page avant : nous ne l'avons pas.
Un passage peut être « non conclu »
Si le pare-feu de votre hébergeur nous barre la route, ce n'est pas une panne de votre site : la cible garde son dernier verdict, rien n'alerte, et une seule alerte part si le barrage dure plus d'une heure.
Nous ne réparons rien
PostShip constate, nomme et alerte. Il ne redéploie pas, ne vide pas votre cache et ne modifie aucune configuration chez votre hébergeur — sauf le retour arrière, que vous armez explicitement.
Pourquoi pas un simple ping
La différence n'est pas une question de fréquence : c'est la question qu'on pose au site.
Un ping demande si le serveur est debout
Il obtient un code de statut. Un serveur peut répondre 200 en servant une page vide, une page « coming soon » ou une page dont le bouton Payer a disparu la nuit dernière.
Nous demandons si la page fait son travail
Le prix est-il affiché, le script de paiement chargé, l'image de partage accessible, le sitemap valide, le certificat encore bon. La réponse est un verdict par contrôle, pas un point vert.
Comparé au dernier état connu
Une page qui change de nature sans changer d'adresse ne déclenche aucune règle écrite d'avance. Elle se voit en comparant ce qui était là au dernier déploiement avec ce qui y est maintenant.
Au moment où ça change, pas toutes les 5 minutes
Le déclencheur principal est votre mise en ligne, pas une horloge : à T+0, T+2 et T+8 minutes après le déploiement, là où une régression a une chance d'apparaître.