La prod sert bien ce déploiement
Après chaque déploiement, PostShip vérifie que votre domaine sert la nouvelle version, et pas celle d'avant restée dans un cache.
Plan Pro et au-delàMis à jour le 12 septembre 2026
Sur cette page
L'hébergeur dit « prêt », PostShip vérifie vos pages, tout est vert. Mais vert sur quelle version ? Un cache CDN qui n'a pas été purgé, un alias qui n'a pas basculé, un DNS qui pointe encore sur l'ancien hébergeur : le domaine sert la version d'avant pendant que toute l'équipe regarde la nouvelle sur l'URL du déploiement. Les vérifications passent — elles vérifient l'ancien site — et le client ne voit jamais ce qui vient d'être livré.
Cette vérification répond à la seule question qui compte à ce moment-là : ce que voient vos visiteurs, est-ce bien ce qui vient d'être déployé ?
Comment PostShip le sait
À chaque déploiement de production reçu par webhook Vercel, Netlify ou Cloudflare Pages, PostShip lit la même page — la racine du site — à deux adresses : l'URL propre au déploiement (mon-site-abc123.vercel.app, deploy-id--mon-site.netlify.app, abc123.mon-site.pages.dev) et votre domaine. Puis il compare les fichiers versionnés que chacune charge : les scripts et feuilles de style dont le nom porte une empreinte de build (/_next/static/…, /assets/index-9f2e1c.js). Deux pages qui chargent les mêmes fichiers versionnés viennent du même build. Sur Next.js, l'identifiant de build tranche à lui seul.
Trois verdicts :
| Verdict | Ce que ça veut dire |
|---|---|
| Servie | Le domaine charge les fichiers du nouveau déploiement. La ligne « Le domaine sert bien ce déploiement » apparaît sous le déploiement. |
| Ancienne | Vingt secondes après la mise en ligne, le domaine chargeait encore les fichiers d'avant. Alerte. |
| Inconnue | PostShip n'a pas pu comparer, et le dit plutôt que de deviner : URL de déploiement protégée par un mot de passe, site sans fichiers versionnés, hébergeur qui n'a pas donné d'URL propre. Rien n'est affiché. |
Avant de conclure « ancienne », PostShip relit le domaine une seconde fois, vingt secondes plus tard : à la seconde où l'hébergeur dit « prêt », l'alias peut être en train de basculer. Vingt secondes après, ce n'est plus une bascule, c'est un cache.
Les previews ne sont pas concernées : une preview n'a pas de domaine à comparer.
Ce qui déclenche une alerte
Un verdict « ancienne » envoie, sur les salons Discord, Slack et Telegram du projet (canaux) et par email au propriétaire, un message « Acme : le domaine sert encore l'ancienne version » : quel déploiement est prêt chez l'hébergeur, quel domaine charge encore les fichiers d'avant, et les trois causes à regarder — cache CDN non purgé, alias pas basculé, DNS qui pointe ailleurs. Pas de webhook sortant, pas d'incident : la page répond, c'est la version qui n'est pas la bonne.
Ce qu'il faut faire
- Cache CDN (Cloudflare devant Vercel, un cache applicatif) : purgez-le, ou réglez-le pour ne pas mettre en cache le HTML.
- Alias : chez Vercel, vérifiez que le domaine est bien assigné à la production et que le déploiement a été promu ; chez Netlify, que le déploiement est bien « published ».
- DNS : si le domaine pointe encore sur un ancien hébergeur, la dérive DNS l'aura vu aussi.
Dépannage
Le verdict est « inconnue » sur tous mes déploiements
Sur Vercel, si la protection des déploiements (Vercel Authentication) couvre les URL de déploiement, PostShip reçoit un 401 et ne peut pas lire la page. Autorisez le contournement pour PostShipBot ou désactivez la protection sur les déploiements de production. Sur un site dont les scripts n'ont pas d'empreinte dans le nom (/main.js plutôt que /main-9f2e1c.js), il n'y a rien à comparer : la plupart des outils de build en ajoutent une par défaut.
Une alerte alors que le site est bien à jour
Si votre page d'accueil charge des scripts qui changent à chaque requête (un identifiant de session dans le nom, un test A/B), les deux lectures diffèrent sans que la version diffère. Écrivez-nous depuis Aide avec l'adresse du site : nous regardons ce que la page charge.