Connecter votre hébergeur

Sans raccordement, PostShip vérifie votre site sur son cycle — toutes les 5 à 30 minutes selon le plan. Avec, la vérification part dès que votre hébergeur annonce la mise en ligne, pendant que vous regardez encore le déploiement : c'est le moment où une régression coûte le moins cher. Cette page est la vue d'ensemble ; chaque hébergeur a la sienne.

Les 5 façons d'apprendre un déploiement

Les 4 premières sont des webhooks : l'hébergeur vous prévient, et apporte le commit. L'empreinte est le repli quand aucun webhook n'a encore livré ; elle s'efface dès que l'un d'eux fonctionne.

Ce qu'un déploiement de production déclenche

À la réception d'un webhook de production authentifié, PostShip enchaîne, dans cet ordre :

1. Toutes les URL du projet, en une passe, avec l'indice « deploy Vercel 14:32 » (ou « déploiement 14:32 » pour le webhook générique) qui apparaît dans les alertes sous la forme « Depuis le dernier déploiement : … ».
2. La dérive DNS : le domaine a-t-il changé d'hébergeur pendant le ship (Domaine & DNS).
3. Le Ship Score, note sur 100 de ce déploiement.
4. L'enregistrement dans Déploiements, avec l'état de chaque page (titre, H1, description, og:title, og:image, statut HTTP, domaines tiers) qui servira au diff du déploiement.
5. Les reprises T+2 et T+8.
6. L'archive de la carte sociale, la mesure PageSpeed et la comparaison visuelle.
7. Les liens de la page d'accueil, en une ligne sur la page du déploiement.
8. Le Check GitHub sur le commit, pour Vercel et Netlify.

Un déploiement pendant un gel est marqué comme tel, annoncé sur vos salons, et fait rougir le Check.

Depuis PostShip, ou à la main

Sur Projet → Paramètres → Intégrations, section Entrant, chaque hébergeur a sa carte. Pour Vercel, le bouton Connecter : vous autorisez PostShip chez Vercel, il retrouve le site dont le domaine correspond au projet, et c'est branché — le webhook est créé pour vous, le secret aussi. Le même bouton devient Débrancher et retire le webhook des deux côtés. Pour Netlify et Cloudflare Pages, le bouton est repoussé depuis le 25 sept. 2026 : on les branche à la main.

Si vous préférez ne rien autoriser, chaque carte affiche L'URL du webhook à copier et un champ de secret. Les étapes exactes côté fournisseur sont sur chaque page « Connecter ».

Vérifier que ça marche

Chaque carte porte une ligne d'état : « Aucun webhook reçu pour l'instant », puis « Dernier webhook reçu il y a … » dès qu'une requête correctement authentifiée arrive. L'horodatage est écrit dès que la signature est vérifiée, avant toute décision sur l'événement : un deployment.created ignoré prouve quand même que la chaîne est bonne, secret compris. Tant que la ligne ne bouge pas après un déploiement, c'est l'URL ou le secret.

Les doublons

Vercel envoie 2 événements par mise en ligne, et tout hébergeur rejoue un webhook auquel on a répondu en erreur. PostShip réserve chaque déploiement par son identifiant pendant 600 secondes : le premier arrivé déclenche, le second est ignoré (skipped: "duplicate_event"). Passé la fenêtre, une promotion tardive est un vrai changement de ce que voient les visiteurs, et elle est vérifiée.

Les previews

Vérifier les previews, dans Projet → Paramètres → Surveillance, étend la vérification aux déploiements de preview : chaque preview est vérifiée sur sa propre adresse, jamais contre votre production. Alerter sur les previews en échec est une seconde décision, désactivée par défaut. Tout est détaillé sur Previews.

Limites et plans

Les webhooks sont compris dans tous les plans, Découverte aussi ; sans eux, la détection par empreinte remplit Déploiements.

Dépannage

Pourquoi la carte dit « Dernier webhook reçu » mais rien n'apparaît dans Déploiements ?

La signature était bonne, mais l'événement n'était pas une mise en ligne : un deployment.created chez Vercel, une notification d'un autre type chez Cloudflare, un doublon dans la fenêtre de 600 secondes. La réponse JSON du webhook, visible dans les journaux de votre hébergeur, porte la raison (skipped).

Pourquoi le déploiement a été vérifié 2 fois ?

2 voies branchées en même temps : 2 webhooks pour le même site, ou une notification Netlify créée en double. L'empreinte de build, elle, se coupe dès qu'un webhook a livré.

Pourquoi la ligne de déploiement manque sur un gros projet ?

Le webhook fait tourner toutes les URL en synchrone, dans une fonction limitée à 60 secondes. Au-delà, l'invocation est tuée : des résultats sont écrits, pas la ligne de déploiement. Si cela se répète, désactivez temporairement les URL les plus lentes (parcours de paiement) pour trouver celle qui déborde.

Connecter Vercel

Vérifier le site dès que Vercel a fini de déployer, depuis PostShip ou avec un webhook collé à la main.

Sans webhook, PostShip vérifie votre site sur son cycle habituel. Avec, la vérification part dans la seconde qui suit la mise en ligne, avec le commit déployé et la distinction entre production et preview. 2 chemins mènent au même traitement : l'intégration depuis PostShip, et le webhook d'équipe que vous créez vous-même.

Depuis PostShip (recommandé)

1. Ouvrez Projet → Paramètres → Intégrations, section Entrant, carte Vercel.
2. Cliquez sur Connecter Vercel. Vercel vous demande d'autoriser PostShip sur votre compte ou votre équipe, avec les seules permissions Deployments: Read et Projects: Read.
3. Au retour, PostShip cherche le projet Vercel dont le domaine correspond à l'URL de production du projet et le branche seul. Si aucun ne correspond, la carte affiche « Autorisation acceptée » et la question « Quel projet Vercel correspond à celui-ci ? » : choisissez-le et cliquez sur Brancher.
4. La carte affiche désormais Débrancher Vercel ; il n'y a plus rien à copier.

C'est le seul chemin qui fonctionne sur un compte Vercel Hobby : les webhooks d'équipe, ci-dessous, demandent un plan Vercel Pro ou Enterprise. Débrancher détache le projet et oublie l'autorisation côté PostShip si plus aucun projet ne s'en sert ; l'intégration elle-même se retire depuis votre tableau de bord Vercel (Integrations).

Depuis la fiche Vercel

Vous pouvez aussi partir de chez Vercel : vercel.com/integrations/postship ↗ → Add Integration, puis l'équipe et les projets à autoriser. Vercel vous amène sur postship.fr/vercel — connectez-vous ou créez votre compte —, où une seule question reste : quel Projet PostShip écoute quel Projet Vercel. Brancher Vercel range l'autorisation et vous ramène chez Vercel. L'installation vous attend 30 minutes ; au-delà, relancez-la depuis la fiche.

Le repli : créer le webhook à la main

Le webhook se crée au niveau de l'équipe Vercel, pas du projet.

1. Sur vercel.com, ouvrez les Settings de votre équipe → Webhooks → Create Webhook. Le lien Ouvrir les webhooks Vercel sur la carte vous y emmène.
2. Cochez Deployment Ready et Deployment Promoted, puis limitez le webhook au projet concerné.
3. Collez L'URL du webhook affichée sur la carte comme endpoint. Elle a la forme https://postship.fr/api/vercel/deploy/<id du projet>.
4. Créez-le : Vercel affiche un secret une seule fois. Copiez-le dans le champ Secret de la carte et cliquez sur Enregistrer.

Ce que PostShip fait de l'événement

• La signature x-vercel-signature (HMAC-SHA1 du corps) est vérifiée en premier ; une signature fausse répond 401 Invalid signature, et rien n'est enregistré.
• payload.target décide : "production" déclenche la vérification complète décrite sur Connecter votre hébergeur. Toute autre valeur (staging, vide) est traitée comme une preview — vérifier une preview par erreur coûte quelques requêtes, l'inverse réécrirait l'état du projet.
• Le commit vient de meta.githubCommitSha, présent seulement sur un déploiement issu de l'intégration Git de Vercel. Sans lui, pas de Check GitHub, et tout le reste tourne.
• Les autres types (deployment.created, error, canceled) répondent skipped: true.

Previews

Avec Vérifier les previews (Projet → Paramètres → Surveillance), chaque déploiement dont l'hôte est en *.vercel.app est vérifié sur sa propre adresse ; les alertes, si vous les activez, sont préfixées « Preview — ». Une preview reçoit aussi un Check GitHub, sans Ship Score, et une comparaison visuelle avec la dernière capture de production. Voir Previews.

Vérifier que ça marche

La carte affiche « Dernier webhook reçu il y a … » dès qu'une requête correctement signée arrive, quel que soit l'événement. Tant qu'elle indique « Aucun webhook reçu pour l'instant » après un déploiement, c'est l'URL ou le secret. Déployez une fois pour trancher.

Limites et plans

Le webhook et l'intégration sont compris dans tous les plans, Découverte aussi ; sans eux, la détection par empreinte prend le relais.

Dépannage

Pourquoi « Aucun webhook reçu » alors que Vercel montre une livraison réussie ?

Vercel affiche le statut HTTP de la livraison : un 401 y apparaît comme une livraison. Ouvrez la livraison dans Vercel et lisez la réponse. Invalid signature : le secret collé n'est pas celui de ce webhook. Not configured : aucun secret enregistré sur la carte.

Pourquoi la production a été vérifiée alors que je n'ai déployé qu'un autre projet Vercel ?

Un webhook d'équipe qui n'est pas limité à un projet reçoit les déploiements de tous les projets de l'équipe : la mise en production d'un site voisin déclenche alors la vérification de celui-ci. Éditez le webhook côté Vercel et restreignez-le au bon projet. Une preview de branche, elle, est bien traitée comme une preview : son target n'est pas production.

Pourquoi le Check GitHub ne s'affiche pas sur le commit ?

Le déploiement doit venir de l'intégration Git de Vercel pour porter githubCommitSha. Un vercel deploy --prod depuis un terminal n'en a pas. Et GitHub doit être connecté sur le projet.

Le bouton Connecter n'apparaît pas

L'intégration n'est proposée que si PostShip a ses clés Vercel en production. Le webhook manuel reste disponible dans tous les cas.

Connecter Netlify

Vérifier le site dès que Netlify a fini de déployer, avec un webhook signé, créé à la main.

Même principe que Vercel : la vérification part à la fin du déploiement au lieu d'attendre le prochain cycle, avec le commit et le contexte du déploiement. Une différence pratique sur le chemin manuel — le secret, c'est PostShip qui le génère, parce que Netlify vous demande d'en inventer un.

À la main : la notification

La voie actuelle, et celle qui garde la signature du corps, la meilleure preuve.

1. Sur la carte Netlify, cliquez sur Générer un secret. Il s'affiche une seule fois : copiez-le avant de quitter la page. Vous pourrez toujours cliquer sur Générer un nouveau secret, mais il faudra alors le mettre à jour côté Netlify.
2. Sur app.netlify.com, ouvrez le site concerné, puis Project configuration → Notifications → Deploy notifications → Add notification → Outgoing webhook.
3. Événement : Deploy succeeded.
4. URL : L'URL du webhook copiée depuis la carte, de la forme https://postship.fr/api/netlify/deploy/<id du projet>.
5. JWS secret token : le secret généré par PostShip.
6. Enregistrez.

Depuis PostShip (repoussé)

1. Ouvrez Projet → Paramètres → Intégrations, section Entrant, carte Netlify.
2. Cliquez sur Connecter Netlify et acceptez l'autorisation chez Netlify.
3. Au retour, PostShip retrouve seul le site dont le domaine correspond à l'URL de production du projet. S'il y en a plusieurs ou aucun, il pose la question « Quel site Netlify correspond à celui-ci ? » : choisissez, puis Brancher.
4. La carte affiche Débrancher Netlify. Rien à générer, rien à coller.

PostShip crée alors 2 notifications sortantes sur le site : deploy_created (ce que l'interface de Netlify appelle « Deploy succeeded ») et deploy_failed. Débrancher les supprime chez Netlify en même temps que l'autorisation — une notification orpheline continuerait d'appeler une adresse que plus personne n'écoute.

Ce que PostShip fait de l'événement

• La preuve est vérifiée en premier : soit la signature X-Webhook-Signature (un JWS HS256 dont PostShip contrôle l'émetteur netlify et le condensat SHA-256 du corps), soit le jeton de l'URL, comparé en temps constant. Sans l'une des deux : 401 Invalid signature.
• Le champ context du corps décide : deploy-preview et branch-deploy sont des previews ; tout le reste, y compris un corps vide ou illisible, est une production. Le doute penche vers la production parce qu'une production prise pour une preview ferait taire une alerte attendue.
• Pour une preview, l'adresse vérifiée est deploy_ssl_url — l'adresse HTTPS propre à ce déploiement, en *.netlify.app. ssl_url désigne le site et pointerait sur la production.
• Le commit vient de commit_ref et alimente le Check GitHub.
• Une production déclenche tout ce que décrit Connecter votre hébergeur : vérification complète, dérive DNS, Ship Score, T+2 / T+8, archive, PageSpeed, Check GitHub.

Vérifier que ça marche

La carte passe à « Dernier webhook reçu il y a … » dès la première requête acceptée. Si elle reste sur « Aucun webhook reçu pour l'instant » après un déploiement, c'est le secret ou l'URL. Netlify garde l'historique des livraisons de chaque notification, avec le statut de réponse.

Limites et plans

Le webhook est compris dans tous les plans, Découverte aussi. Les tarifs détaillent le reste.

Dépannage

Pourquoi une preview a été vérifiée contre ma production ?

Ce n'est plus possible : le contexte du corps est lu, et une deploy-preview sans adresse *.netlify.app exploitable n'est simplement pas vérifiée (skipped: "invalid_preview_url") plutôt que rabattue sur la production. Si vous observez une ligne « production » pour un déploiement de branche, vérifiez que la notification manuelle n'a pas été créée sur un événement autre que « Deploy succeeded ».

Pourquoi « Invalid signature » après avoir régénéré le secret ?

Un nouveau secret invalide l'ancien immédiatement. Reportez-le dans le champ JWS secret token de la notification Netlify. Le branchement depuis PostShip n'est pas concerné : il ne se sert pas de ce secret.

Pourquoi 2 vérifications par déploiement ?

Le branchement depuis PostShip et une notification manuelle coexistent : chacune appelle PostShip. Supprimez la notification manuelle côté Netlify, ou cliquez sur Débrancher Netlify.

Le bouton Connecter n'apparaît pas

L'intégration n'est proposée que si PostShip a ses clés Netlify en production. Le chemin manuel reste disponible dans tous les cas.

Connecter Cloudflare Pages

Vérifier le site dès que Cloudflare Pages a fini de déployer, avec la destination et la notification créées à la main.

Cloudflare sépare le webhook (la destination) de la notification (ce qui le déclenche) : à la main, il faut créer les deux, dans cet ordre, au niveau du compte. Cette intégration ne sert qu'aux sites déployés sur Cloudflare Pages.

À la main : créer la destination

Dans le tableau de bord Cloudflare, au niveau du compte. Le lien Ouvrir les notifications Cloudflare sur la carte y mène.

1. Ouvrez Notifications → Destinations → Webhooks → Create.
2. Collez L'URL du webhook affichée sur la carte, de la forme https://postship.fr/api/cloudflare/deploy/<id du projet>.
3. Cloudflare génère un secret à la création : copiez-le dans le champ Secret de la carte et cliquez sur Enregistrer.

À la main : créer la notification

Le webhook seul ne reçoit rien tant qu'aucune notification ne pointe dessus.

1. Ouvrez Notifications → Add.
2. Choisissez Pages, puis l'événement Pages Deployment Success.
3. Comme destination, sélectionnez le webhook créé juste avant.
4. Enregistrez.

Depuis PostShip (repoussé)

1. Ouvrez Projet → Paramètres → Intégrations, section Entrant, carte Cloudflare Pages.
2. Cliquez sur Connecter Cloudflare. Cloudflare affiche les permissions demandées : lecture des paramètres du compte, lecture de Pages, lecture et écriture des notifications, et offline_access pour pouvoir débrancher des mois plus tard.
3. Au retour, PostShip cherche le projet Pages dont le domaine correspond à l'URL de production du projet. S'il faut choisir : « Quel projet Pages correspond à celui-ci ? », puis Brancher.
4. La carte affiche Débrancher Cloudflare.

PostShip a alors créé dans votre compte une destination webhook (avec un secret qu'il garde) et une règle pages_event_alert filtrée sur le projet Pages choisi. Sans ce filtre, un compte qui héberge 4 sites ferait vérifier celui-ci à chaque déploiement des 3 autres. Débrancher supprime la règle et la destination.

Ce que PostShip fait de l'événement

• Cloudflare ne signe pas le corps : le secret de la destination est renvoyé tel quel dans l'en-tête cf-webhook-auth à chaque livraison. PostShip le compare en temps constant ; sinon 401 Invalid signature.
• Le champ alert_type est lu. Une notification qui n'est manifestement pas un déploiement Pages (une alerte de santé, un changement DNS que vous auriez dirigé vers la même destination) est ignorée et répond triggered: false. Ce qui n'est pas reconnu passe : se tromper dans ce sens coûte une vérification de trop, pas une panne silencieuse.
• Le doute vaut production. PostShip ne bascule en preview que sur un signal explicite : environment égal à preview, ou une adresse de déploiement en <label>.<projet>.pages.dev — un label de plus que la production, qui répond sur <projet>.pages.dev.
• Le commit vient de deployment_trigger.metadata.commit_hash quand Cloudflare le donne. Le webhook Cloudflare ne publie pas de Check GitHub.

Une production déclenche tout ce que décrit Connecter votre hébergeur.

Vérifier que ça marche

La carte passe à « Dernier webhook reçu il y a … » dès la première requête acceptée. Si rien n'arrive après un déploiement réussi, c'est presque toujours la notification qui manque : le webhook peut très bien exister sans que rien ne le déclenche.

Limites et plans

Le webhook est compris dans tous les plans, Découverte aussi. Voir les plans.

Dépannage

Pourquoi une vérification part quand un autre de mes sites Pages déploie ?

La notification créée à la main n'est pas filtrée par projet. Éditez-la dans Cloudflare et limitez-la au projet Pages concerné, ou passez par Connecter Cloudflare, qui pose ce filtre.

Pourquoi « Débrancher » a échoué des mois après ?

Le jeton Cloudflare expire au bout d'une heure environ et se renouvelle grâce à offline_access. Si l'autorisation a été révoquée côté Cloudflare entre-temps, PostShip ne peut plus retirer la règle : supprimez-la vous-même dans Notifications, puis débranchez.

Pourquoi la ligne dans Déploiements n'a pas de commit ?

Cloudflare ne documente pas la forme de data pour les déploiements Pages ; le commit n'est lu que s'il est présent sous deployment_trigger.metadata.commit_hash. Sans lui, la ligne reste juste — elle ne porte simplement pas de sha.

Webhook générique

Prévenir PostShip depuis n'importe quel hébergeur ou pipeline de CI avec une adresse, un secret et une ligne de curl.

Vercel, Netlify et Cloudflare ont chacun leur carte parce que chacun signe et parle à sa façon. Tout le reste — Coolify, Railway, Render, un VPS déployé par rsync, un job de CI — n'a besoin que d'une adresse à appeler après la mise en ligne, avec un secret pour prouver que c'est bien lui. C'est la carte Autre hébergeur de la page Intégrations.

Régler

1. Ouvrez Projet → Paramètres → Intégrations, carte Autre hébergeur.
2. Cliquez sur Générer un secret. Il s'affiche une seule fois : rangez-le dans une variable d'environnement de votre déploiement, par exemple POSTSHIP_HOOK_SECRET. Il ne sera plus réaffiché ; Générer un nouveau secret en fabrique un autre et invalide l'ancien.
3. Copiez L'adresse — https://postship.fr/api/generic/deploy/<id du projet> — ou directement La ligne curl.
4. Appelez cette adresse à la fin de chaque mise en ligne.

La carte affiche « Pas encore branché », puis « Secret généré, aucun appel reçu pour l'instant », puis « Branché — dernier appel il y a … » dès qu'un appel correctement authentifié arrive. Désactiver efface le secret ; les appels suivants répondent 404 Not configured.

L'appel

Le secret voyage dans l'en-tête X-PostShip-Secret, et seulement là : une adresse finit dans les journaux d'accès, les vôtres comme les nôtres, et ce secret ne change pas. Un outil qui ne sait pas poser d'en-tête passe par un petit script (curl, ci-dessous). Le secret est comparé en temps constant. Le corps est facultatif et lu avec bienveillance : un sha (ou commit, commit_sha, COMMIT_SHA, GIT_COMMIT) et une url (ou deployment_url, deploy_url, DEPLOY_URL). Tout le reste est ignoré, et un corps vide ou illisible n'est pas une erreur — c'est un déploiement dont on ne sait rien de plus que « il a eu lieu », ce qui suffit.

curl -fsS -X POST https://postship.fr/api/generic/deploy/<id du projet> \
  -H "X-PostShip-Secret: $POSTSHIP_HOOK_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"sha":"'$(git rev-parse HEAD)'"}'

Le sha n'est retenu que s'il ressemble à un sha (hexadécimal, 7 à 64 caractères) : c'est une valeur affichée dans Déploiements. L'URL n'est retenue qu'en http ou https.

Ce que PostShip fait de l'appel

Production seulement : un hébergeur inconnu n'a pas de notion de preview que PostShip saurait lire. Ce qui arrive ici est une mise en ligne, et déclenche tout ce qu'une mise en ligne déclenche (vue d'ensemble) : toutes les URL du projet avec l'indice « déploiement 14:32 », la dérive DNS, le Ship Score, la ligne dans Déploiements (fournisseur « Webhook générique »), les reprises T+2 / T+8, l'archive, la mesure PageSpeed et le diff visuel, les liens de la page d'accueil.

La réponse résume ce qui s'est passé :

{ "triggered": true, "deployEventId": "…", "checked": 8, "failed": 0, "score": 100 }

Le webhook générique ne publie pas de Check GitHub, même quand un sha est fourni. Un appel qui arrive pendant un gel de déploiement est annoncé sur vos salons comme n'importe quel autre.

Ce qui déclenche une alerte

Le webhook lui-même n'alerte pas. Ce sont les vérifications qu'il lance qui alertent, aux mêmes conditions que sur le cycle (règles), avec la mention « Depuis le dernier déploiement » dans le message. Le ce qui a changé ne sonne que sur ces passages-là.

Limites et plans

Il n'y a pas de quota propre au webhook : chaque appel fait tourner les vérifications du projet, c'est-à-dire exactement ce que fait un cycle. Un pipeline qui appellerait l'adresse en boucle produirait une ligne Déploiements par appel — c'est le webhook qui dédoublonne par identifiant chez Vercel, pas ici.

Dépannage

Pourquoi 401 Invalid secret ?

Le secret envoyé n'est pas celui de la carte, ou il a été régénéré. Vérifiez la variable d'environnement de votre pipeline et l'en-tête exact : X-PostShip-Secret, ou token dans l'URL.

Pourquoi 404 Not configured ?

Aucun secret n'existe pour ce projet : il n'a jamais été généré, ou Désactiver a été cliqué. Générez-en un nouveau.

Pourquoi l'appel prend jusqu'à une minute ?

Il attend la fin des vérifications avant de répondre — c'est ce qui permet de rendre checked, failed et score. Ne le placez pas dans une étape avec un délai plus court, et acceptez son échec sans faire échouer le déploiement : curl -fsS renvoie une erreur sur un 5xx, ajoutez || true si votre pipeline doit continuer quoi qu'il arrive.

Pourquoi la détection par empreinte s'est arrêtée ?

C'est voulu : dès qu'un appel a été reçu, la détection sans webhook s'efface pour ne pas enregistrer 2 déploiements par mise en ligne.

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.

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 :

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 5 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

2 relevés consécutifs sont comparés. 4 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 18 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 5 pendant qu'un CDN sert alternativement l'ancienne et la nouvelle version.

Ce que ça déclenche

Le déploiement est enregistré dans Déploiements 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 du déploiement, 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 2 sources pour un même événement écriraient 2 lignes dans l'historique.

Limites et plans

La détection par empreinte tourne sur tous les plans, Découverte compris : c'est ce qui remplit Déploiements sans rien demander. Elle coûte une requête HTTP par projet et par passage, dans la limite de 512 Ko lus par page. La sonde de 30 secondes de Pro Plus ne relève pas d'empreinte : elle guette les pannes, pas les déploiements.

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 2 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.