Détection sans webhook
Comment PostShip reconnaît un déploiement en lisant l'empreinte de build de votre page d'accueil, sans rien brancher.
Mis à jour le 11 septembre 2026
Sur cette page
PostShip télécharge déjà la page d'accueil de chaque projet à chaque cycle. Un déploiement y laisse une trace : le nom des fichiers compilés change. En la lisant, PostShip sait qu'un build est passé sans qu'un webhook ait été configuré — et le passage suivant devient la vérification T+0 de ce déploiement. C'est le repli quand rien n'est branché ; un webhook reste mieux, parce qu'il connaît le commit.
Ce que PostShip lit
À chaque passage du cycle, une requête de plus sur l'URL de production du projet, dont on ne garde que ce qui ne bouge qu'au build, dans cet ordre de préférence :
| Source | Ce qui est retenu | Frameworks |
|---|---|---|
next | Le buildId de Next.js, lu dans __NEXT_DATA__ ou dans le chemin /_next/static/<buildId>/ | Next.js |
nuxt | Le buildId de Nuxt | Nuxt |
actifs | L'ensemble trié des fichiers JS et CSS portant une empreinte : index-D3f8Kw2a.js, main-1a2b3c.css, chunk-A1B2C3D4.js | Vite, Astro, SvelteKit, Remix, Gatsby, et la plupart des chaînes de build |
Ce qui est refusé, et pourquoi : x-vercel-id et x-nf-request-id sont des identifiants de requête, ils changent à chaque appel et annonceraient un déploiement toutes les cinq minutes ; ETag et Last-Modified varient sur une page rendue à la demande. Une empreinte de fichier doit contenir des chiffres et des lettres, de 8 à 64 caractères : /assets/main.js n'en est pas une.
Quand aucun signal n'est présent — un site en HTML écrit à la main — l'empreinte est nulle et aucun déploiement n'est jamais annoncé. La fonctionnalité doit être invisible quand elle ne sait pas.
Quand un déploiement est conclu
Deux relevés consécutifs sont comparés. Quatre façons de répondre « non », chacune ferme un faux positif :
- Premier relevé : on pose une référence, on ne constate rien. Sans cette règle, la mise en service aurait annoncé un déploiement sur tous les projets à la fois.
- Identique : le cas courant.
- Lecture douteuse : l'empreinte reposait sur dix-huit fichiers et n'en compte plus que la moitié ou moins. Un déploiement change les noms, il ne fait pas disparaître le JavaScript d'un site : c'est une page d'erreur, une page de garde d'hébergeur, une réponse tronquée. Seules les réponses 2xx en HTML sont d'ailleurs comparées.
- Ajout seul : des fichiers sont apparus, aucun n'a disparu. Une bannière, un test A/B, un carrousel conditionnel font apparaître des fichiers sans déploiement ; une compilation, elle, remplace. Un ajout seul n'est pas un déploiement.
Reste le cas où au moins un fichier relevé a disparu : c'est un déploiement. Un anti-rebond de 10 minutes empêche ensuite qu'un seul git push en produise cinq pendant qu'un CDN sert alternativement l'ancienne et la nouvelle version.
Ce que ça déclenche
Le déploiement est enregistré dans Déplois avec le fournisseur « Détecté sans webhook », sans commit ni URL de déploiement — c'est le seul aveu de faiblesse de cette voie. Le passage de cycle en cours devient sa vérification T+0 : les alertes portent l'indice « déploiement détecté », et le mot compte — on ne sait ni l'hébergeur ni l'heure de mise en ligne, seulement le moment où on s'en est aperçu. Puis, comme pour un webhook : dérive DNS, Ship Score, état des pages pour le diff de ship, reprises T+2 et T+8.
Pas de Check GitHub : il n'y a pas de commit à annoter. Pas d'archive de carte sociale ni de mesure PageSpeed sur cette voie.
Quand elle se coupe
La détection ne tourne que sur les projets où aucun webhook — Vercel, Netlify, Cloudflare ou générique — n'a jamais livré quoi que ce soit, et qui ne sont pas en pause. On regarde ce qui a été reçu, pas ce qui a été configuré : un secret collé dans un champ et jamais branché côté hébergeur est exactement le cas où l'on croit être couvert sans l'être. Dès qu'un webhook a livré, l'hébergeur sait mieux que PostShip ce qu'il a déployé, et deux sources pour un même événement écriraient deux lignes dans l'historique.
Limites et plans
La détection par empreinte tourne sur tous les plans, Free compris : c'est ce qui remplit Déplois sans rien demander. Elle coûte une requête HTTP par projet et par passage, dans la limite de 512 Ko lus par page.
| Free | Pro | Team | |
|---|---|---|---|
| Détection par empreinte | Oui | Oui | Oui |
| Fréquence des relevés | Toutes les 30 min | Toutes les 5 min | Toutes les 5 min |
| Webhooks, qui prennent le relais | Non | Oui | Oui |
Dépannage
Pourquoi mes déploiements n'apparaissent jamais ?
Votre page d'accueil ne porte aucun signal retenu (HTML sans fichiers empreintés), ou elle ne répond pas en 2xx avec un Content-Type HTML, ou vos déploiements n'ont fait qu'ajouter des fichiers. Branchez un webhook : c'est la voie normale, celle-ci n'est qu'un repli.
Pourquoi un déploiement a été détecté alors que je n'ai rien déployé ?
Un fichier relevé a disparu de la page d'accueil entre deux passages : un script retiré par une expérimentation, un bundle renommé par un rebuild automatique chez l'hébergeur. Le verdict dit ce qui a changé ; c'est votre page qui a changé de build.
Pourquoi la détection s'est arrêtée après avoir branché Vercel ?
C'est prévu : dès la première livraison du webhook, la détection s'efface, et elle ne reprend pas après un débranchement.