La vérification part avec le déploiement, pas au prochain cycle

Acte 1 · Le push

1. 16:02. Un correctif de style.

   3 lignes de CSS, et un fichier renommé au passage. Rien qui ressemble à un risque.

2. git push.

   Le correctif part sur main, comme des dizaines d'autres avant lui.

3. Le build passe au vert.

   L'hébergeur compile, déploie et répond « Ready ». Rien dans ce journal ne lit la page que vos clients vont ouvrir.

4. Et prévient PostShip.

   Vercel, Netlify ou Cloudflare Pages, branché une fois depuis l'app : l'événement de déploiement arrive dans la seconde, et les pages surveillées partent en file.

styles/header.css
- .header { margin: 0 24px; }
+ .header { margin: 0 auto; }
js/pay-loader.js → js/pay.js

$ git commit -am "fix: marges du header"
[main 9f3c2e1] fix: marges du header
 2 files changed, 1 insertion(+), 1 deletion(-)
$ git push origin main
To github.com:vous/votre-site.git
   4b1d7a0..9f3c2e1  main -> main

Acte 2 · Les passages

1. 16:02:41. T+0.

   La vérification part dans la seconde qui suit la mise en ligne : les 5 URLs surveillées, demandées tout de suite.

2. 5 pages, 6 contrôles chacune.

   La page et ses ressources, l'indexabilité, la carte sociale, le sitemap, le certificat et la lisibilité par les moteurs de réponse.

3. /checkout ne passe pas.

   La page répond 200 en 184 ms. Une sonde de disponibilité s'arrêterait là, au vert.

4. On entre dans la page.

   Le récapitulatif, le prix, le bouton. Et l'emplacement du paiement, qui reste vide.

5. Dans son HTML.

   Tel que le serveur l'envoie. Une ligne charge le script de paiement.

6. /js/pay-loader.js

   PostShip demande aussi chaque ressource que la page appelle.

7. 404.

   Le correctif a renommé le fichier ; la page, elle, l'appelle encore par son ancien nom. Elle s'affiche, le paiement ne se charge plus.

8. Vu à T+0, 1 seconde après la mise en ligne.

   Une sonde voit 5 pages en 200. PostShip voit une ressource en 404 sur la page qui encaisse.

<!doctype html>
<html lang="fr">
<head>
  <title>Paiement · votre-site.com</title>
  <link rel="stylesheet" href="/css/site.css">
  <script src="/js/pay-loader.js" defer></script>
</head>
<body>
  <main class="checkout">
    <h1>Paiement</h1>
    <div id="payment"></div>
    <button>Payer 34 €</button>

GET /js/pay-loader.js HTTP/2
host: votre-site.com
accept: */*

HTTP/2 404
content-type: text/html; charset=utf-8
date: 23 sept. 2026 16:02:41

Acte 3 · Le retour

1. 16:02:42. L'alerte part.

   Sur chaque canal branché, en même temps, une seule fois : pas un message par passage.

2. Avec sa cause probable.

   Un déploiement dans la minute qui précède un échec est le premier suspect : l'alerte le nomme, commit compris.

3. Le retour arrière, à un lien.

   Sur la page Déploiements de l'app : le dernier déploiement que PostShip a vu passer, et un bouton pour le remettre en ligne. Sur Vercel, où l'intégration a la main.

4. Tout repart en arrière.

   Vercel repointe vos domaines vers 4b1d7a0, vérifié bon à 15:41. Rien n'est reconstruit : quelques secondes.

5. 16:04:41. T+2.

   Le passage prévu 2 minutes après la mise en ligne trouve les 5 pages au vert. /checkout charge de nouveau son script.

6. 16:10:41. T+8. C'est tenu.

   Dernier passage prévu, dernier vert. L'incident se referme et garde sa chronologie, de l'échec au retour.

1. 16:02:41échec sur /checkout
2. 16:02:42alerte
3. 16:03:14retour arrière
4. 16:04:41rétabli