Previews

Le webhook de production arrive après coup : le 500 est déjà en ligne. Une preview, elle, se vérifie avant. Avec la vérification des previews, chaque preview Vercel, chaque deploy-preview ou branch-deploy Netlify et chaque preview Cloudflare Pages est vérifiée sur sa propre adresse, jamais contre votre production, et le résultat est posé sur le commit de la pull request.

Régler

Sur Projet → Paramètres → Surveillance, section « Ce qui est vérifié, en plus de la production », 2 interrupteurs — parce que ce sont 2 décisions :

1. Vérifier les previews. Les checks tournent contre l'URL de preview. Le résultat est visible dans Déploiements (badge « Preview ») et sur le Check GitHub du commit.
2. Alerter sur les previews en échec, visible seulement une fois le premier allumé. Désactivé par défaut : 6 pull requests dans l'après-midi feraient 6 messages pour des pages qui ne sont pas en ligne, et c'est ce bruit-là qui fait couper les alertes — production comprise.

Le webhook de l'hébergeur doit être branché (Connecter votre hébergeur) : c'est lui qui annonce la preview et son adresse.

Ce que PostShip vérifie

Chaque URL surveillée est réécrite sur l'hôte de la preview — https://www.acme.fr/tarifs devient https://acme-git-feature-x.vercel.app/tarifs — puis vérifiée comme d'habitude :

Puis, après les vérifications, la mesure PageSpeed et la comparaison visuelle de la preview contre la dernière capture de production — ce que la pull request va changer, avant qu'elle parte. Sans budget, sans note et sans alerte : rien n'est en ligne.

Comment PostShip reconnaît une preview dépend de l'hébergeur : target différent de production chez Vercel, context en deploy-preview ou branch-deploy chez Netlify, environment à preview ou un sous-domaine <label>.<projet>.pages.dev chez Cloudflare. L'adresse vérifiée doit être en *.vercel.app, *.netlify.app ou *.pages.dev ; sinon la preview est ignorée (skipped: "invalid_preview_url"), jamais rabattue sur la production.

Ce que vous voyez

• Dans Déploiements : une ligne par preview, badge « Preview », avec l'adresse et le verdict. Pas de Ship Score, pas de reprises T+2 / T+8.
• Sur le commit GitHub : un Check PostShip qui raconte la preview — Preview vérifiée · score 94 · checkout OK — avec, dans son corps, l'heure de la vérification, l'hôte, un tableau des pages (✅ / ❌ et la raison), l'état du checkout et le lien vers Déploiements. Le score est le Ship Score appliqué à ce qui a été vérifié sur la preview : il ne déduit que ce qu'on a regardé, et ne prétend rien sur le certificat ou le DNS, qui n'ont pas de sens sur *.vercel.app. Le même récit est posé en commentaire de la pull request — un seul, mis à jour à chaque preview — si l'app GitHub a la permission Pull requests : Read and write ; sans elle, le Check seul est posé. Il suit le réglage de production Exiger un déploiement vert / Ne bloquer que sur les pages de paiement (bloquer un merge) : sans cela, une carte sociale cassée sur une preview bloquait le merge d'une équipe réglée pour ne bloquer que sur l'argent.
• Sur la page de la preview : l'avant / après visuel contre la production.

Ce qui déclenche une alerte

Rien, tant que Alerter sur les previews en échec est éteint. Une fois activé, une URL en échec sur la preview part sur vos canaux comme une panne, avec le nom du projet préfixé « Preview — Acme ». Les mêmes règles de silence s'appliquent (règles). Aucun incident n'est ouvert et rien n'est dédoublonné d'une preview à l'autre : 2 pushes sur la même branche font 2 messages.

Limites et plans

Une preview compte comme un passage complet sur le projet ; elle ne consomme pas de quota d'URL. Voir les plans.

Dépannage

Pourquoi ma preview n'est pas vérifiée ?

Dans l'ordre : la vérification des previews n'est pas activée (skipped: "preview_checks_disabled") ; l'adresse de la preview n'est pas sur un hôte reconnu ; ou votre hébergeur a envoyé l'événement sans adresse exploitable. La réponse du webhook, dans les journaux de l'hébergeur, porte la raison.

Pourquoi toutes mes previews échouent sur une page protégée ?

Si la page exige un en-tête privé, il est envoyé sur la preview comme en production. Si la preview elle-même est protégée par un mot de passe ou une authentification de l'hébergeur (Vercel Deployment Protection, par exemple), PostShip reçoit un 401 : désactivez cette protection pour les previews, ou ajoutez-la comme en-tête privé sur la cible.

Pourquoi le Check bloque la pull request alors que la page tombée n'est pas importante ?

Vous êtes en mode Exiger un déploiement vert pour merger. Passez sur Ne bloquer que sur les pages de paiement : le Check devient vert, avec le titre « Preview : 1 pages en échec, hors pages de paiement » pour que l'information reste visible, et seule une page de paiement le fait encore rougir.

Budget de performance

Disponible avec les plans Pro et Pro Plus.

Mesurer 3 pages avec PageSpeed Insights après chaque déploiement, et faire perdre des points au déploiement qui ralentit le site.

Un déploiement qui double le poids du bundle ne casse rien : toutes les pages répondent 200. Après chaque déploiement de production, PostShip demande à PageSpeed Insights de charger jusqu'à 3 de vos pages dans un vrai navigateur, garde le score Lighthouse et les métriques, et les compare au déploiement précédent. Si vous posez un budget, le franchir coûte 15 points au Ship Score et se voit dans le Check GitHub.

Ce que PostShip mesure

Pour chaque déploiement de production reçu par webhook, une fois les vérifications passées :

• Quelles pages : les 3 premières URL surveillées dont la vérification a relevé un title, dans l'ordre des cibles du projet (celui de leur ajout). Un title prouve que c'est une page HTML — mesurer un sitemap n'aurait pas de sens — et l'ordre fixe permet de comparer d'un déploiement à l'autre. 3 et pas 50 : chaque appel fait tourner un Chrome chez Google pendant une dizaine de secondes.
• Comment : l'API PageSpeed Insights v5, stratégie mobile, catégorie performance. Mobile parce que c'est là que Google juge, et là où un déploiement lourd se voit ; mesurer en desktop rassurerait à tort.
• Quoi : le score de performance (0–100), le LCP, le CLS, le TBT et le FCP. Une seule métrique manquante et la mesure entière est ignorée — un écart calculé sur une valeur absente lue comme zéro annoncerait une amélioration spectaculaire à chaque panne de mesure.
• En prime : la capture d'écran de fin de chargement rendue par Lighthouse, qui alimente la régression visuelle.

Pourquoi PageSpeed et pas les données de terrain de Chrome : celles-ci sont fenêtrées sur 28 jours et demandent un millier de visites par mois. Un déploiement qui casse la performance ce matin n'y apparaîtrait pas avant un mois, et jamais sur un site jeune.

Régler

Projet → Déploiements → Réglages, carte Budget de performance, 2 champs indépendants et facultatifs :

Laissez les deux vides (« aucun ») pour mesurer sans jamais alerter : les chiffres restent visibles sur la page du déploiement. Un projet peut n'exiger qu'un LCP, ou qu'un score. Un budget est un seuil que vous avez posé vous-même : le franchir est un fait, pas une opinion.

Ce que vous voyez

Sur la page du déploiement (diff du déploiement), une section par page mesurée : score, LCP, CLS, TBT, et l'écart avec le déploiement précédent quand il a été mesuré lui aussi. « Non mesuré » quand PageSpeed n'a pas répondu — et jamais un zéro inventé.

Ce qui déclenche une alerte

Le budget n'envoie pas de message sur vos canaux. Ce qu'il fait quand une des pages mesurées le franchit :

• Le Ship Score perd 15 points, une seule fois quel que soit le nombre de pages en dépassement — le budget est une décision du projet, pas une par URL, et le retirer 3 fois ferait tomber la note à zéro pour un site simplement lent. La raison affichée est « budget de performance dépassé ».
• Le Check GitHub reçoit ce score recalculé : en Pro Plus, un score plancher fait alors rougir le commit.

Un dépassement isolé sur une preview ne compte pas : une preview est mesurée et comparée à la production, sans budget ni note.

Limites et plans

La carte est repliée sur Découverte avec un lien vers les tarifs. Les déploiements détectés par empreinte ne sont pas mesurés : seuls les webhooks le sont. Voir les plans.

Dépannage

Pourquoi « non mesuré » sur toutes mes pages ?

PageSpeed n'a pas répondu dans les 45 secondes, a refusé l'URL, ou son quota est épuisé pour l'heure. PostShip ne retente pas : le déploiement suivant remesurera. Une page protégée par un en-tête privé n'est pas mesurable non plus — PageSpeed ne l'envoie pas.

Pourquoi mon score varie de 10 points entre 2 déploiements identiques ?

Lighthouse charge la page pour de vrai, sur une machine partagée : la variance est connue et normale. Posez un budget avec de la marge (un score minimum à 60 plutôt qu'à 89), et lisez la tendance sur plusieurs ships plutôt qu'un écart isolé.

Pourquoi la page mesurée n'est pas celle que je voulais ?

Ce sont les 3 premières pages HTML dans l'ordre des URL du projet, c'est-à-dire en pratique l'ordre dans lequel elles ont été ajoutées. Il n'y a pas de réordonnancement : si une page décorative passe devant la page produit, supprimez-la et ajoutez-la de nouveau pour qu'elle passe derrière.

Pourquoi le budget a fait baisser le score sans que le Check GitHub rougisse ?

Sur Découverte et Pro, le score n'est qu'informatif dans le Check ; seul un échec de vérification le fait rougir. Le plancher de score est une promesse Pro Plus.

Régression visuelle

Disponible avec les plans Pro et Pro Plus.

Comparer pixel à pixel la capture de chaque page mesurée avec celle du déploiement précédent, et alerter au-delà du seuil que vous choisissez.

La page blanche, le CSS qui n'est pas parti, le bloc de prix qui a disparu : tout cela répond 200. Après chaque déploiement de production, PostShip compare la capture d'écran de chaque page mesurée à celle du déploiement précédent, surligne ce qui a changé, et — si vous posez un seuil — vous prévient comme pour une panne quand une page n'a plus la même tête.

Ce que PostShip compare

La capture vient de la mesure PageSpeed : Lighthouse rend une image de fin de chargement, en mobile, pour jusqu'à 3 pages par déploiement. Un seul appel donne donc le budget de performance et l'avant / après visuel.

• L'avant est la capture de la même page au déploiement de production précédent qui en porte une — PostShip remonte jusqu'à 10 déploiements, pour qu'une mesure ratée ne fasse pas perdre la comparaison.
• La comparaison est faite pixel à pixel, avec une sensibilité qui absorbe le bruit JPEG et écarte les bords anti-crénelés. 2 captures de tailles différentes sont comparées sur leur zone commune, et chaque pixel qui n'existe que d'un côté compte comme changé : une page qui s'allonge de 300 px a changé de 300 px.
• Le résultat est un ratio de pixels changés, une image des différences (le changement en rouge sur la page grisée, absente quand le rendu est identique), et une phrase : « Rendu identique » sous 0,5 %, sinon « Rendu modifié de 34 % (haut de page, milieu) », les zones nommées de la plus touchée à la moins touchée, « toute la page » quand les 3 tiers sont concernés.

Une preview est comparée à la dernière capture de production : ce que la pull request va changer, avant qu'elle parte. Sans note ni alerte.

Régler

Projet → Paramètres → Surveillance, section « Ce qui compare », ligne Régression visuelle, un seul réglage :

4 valeurs et pas un champ libre : le pourcentage n'a de sens qu'en ordre de grandeur. Le seuil est inclusif ; un rendu strictement identique ne dépasse jamais rien.

Les zones ignorées

Un carrousel, une horloge, un flux d'avis : ces zones changent à chaque chargement sans que la page ait changé, et feraient sonner le seuil à chaque déploiement. Sur la page d'une URL, carte Zones ignorées du diff visuel, dessinez jusqu'à 10 rectangles en pourcentage de la capture (x, y, largeur, hauteur), puis Ajouter la zone. Un rectangle qui déborde est ramené au bord.

Le masque est peint en gris sur les 2 images avant la comparaison : 2 zones grises identiques ne comptent pas, et le gris se lit sur l'image des différences comme « ici, on ne regarde pas ». Sans zone : « Aucune zone ignorée : toute la capture est comparée. »

Ce que vous voyez

Sur la page du déploiement (diff du déploiement), pour chaque page mesurée : la capture d'avant, celle d'après, l'image des différences et la phrase. Les captures vivent dans un stockage privé et suivent la rétention du plan (données).

Ce qui déclenche une alerte

Quand au moins une page de production dépasse le seuil choisi :

• Un message part sur vos salons Discord et Slack (canaux) et par email si vos alertes email sont actives — pas sur le webhook sortant : « Acme : une page n'a plus la même tête depuis le déploiement » — ou « 2 pages n'ont plus la même tête » — avec une ligne par page (« https://www.acme.fr/tarifs — Rendu modifié de 34 % (haut de page) ») et le lien Voir l'avant / après.
• Le Ship Score perd 15 points, une seule fois quel que soit le nombre de pages, raison « rendu modifié au-delà du seuil ». Le Check GitHub reçoit ce score.

Sans seuil, rien ne part, jamais. Aucun incident n'est ouvert : la page répond.

Limites et plans

Voir les plans. Les déploiements détectés par empreinte ne sont pas capturés.

Dépannage

Pourquoi « rien à comparer » sur ce déploiement ?

C'est le premier déploiement mesuré pour cette page, ou aucun des 10 précédents ne porte de capture (PageSpeed n'a pas répondu). Le prochain déploiement aura un avant.

Pourquoi ça alerte à chaque déploiement alors que rien n'a changé ?

Une zone de la page change à chaque chargement : carrousel, compteur, publicité. Ouvrez l'image des différences, repérez le rouge, et dessinez une zone ignorée dessus. Si le rouge est partout, une bannière de consentement apparaît sur une capture et pas sur l'autre.

Pourquoi la capture ne ressemble pas à mon site ?

Lighthouse capture en mobile, après le chargement, sans faire défiler ni cliquer. Une page qui dépend d'une interaction est capturée dans son état initial — stable d'un déploiement à l'autre, ce qui est tout ce dont la comparaison a besoin.

Retour arrière

Remettre en production le dernier déploiement vérifié bon — à la main depuis Déploiements, ou tout seul quand une page de paiement casse à la mise en ligne.

Un déploiement vient de passer, la page de paiement ne répond plus. PostShip l'a vu et vous l'a dit ; jusqu'ici, il s'arrêtait là, et vous alliez chercher dans Vercel quel déploiement remettre en ligne — le moment où l'on se trompe de ligne. Le retour arrière fait ce geste depuis PostShip, vers le dernier déploiement que PostShip a vérifié bon, pas seulement le précédent dans la liste de l'hébergeur.

Vercel seulement pour l'instant, par l'intégration — pas par le webhook collé à la main, qui n'a pas de jeton pour parler à Vercel.

À la main

Projet → Déploiements. Le bouton Revenir au déploiement précédent est toujours là, en haut de la liste et sur la page du déploiement en production — en rouge quand celui-ci a cassé une vérification, discret sinon : un bug que les vérifications ne voient pas se défait aussi. Un dialogue dit vers quel déploiement on revient et ce qui se passe ; vous confirmez.

Vercel redéploie alors le déploiement choisi en production : il reconstruit le même commit, et la mise en ligne se fait en quelques minutes. L'équipe est prévenue sur les salons et le propriétaire par email.

C'est une mise en ligne ordinaire : votre prochain push reprend sa place en production comme d'habitude. D'ici là, un bandeau le dit en haut de Déploiements, avec le bouton Annuler le retour : il redéploie de la même façon le déploiement retiré.

Le retour part toujours du dernier déploiement de production et remet le plus récent vérifié bon avant lui. Une fois fait, le bouton attend le déploiement suivant. Il faut être propriétaire ou éditeur du projet.

Tout seul

Même page, carte Retour arrière automatique. Activée, elle fait le geste sans demander quand, à la mise en ligne (T+0), une page de paiement — un parcours ou une page avec des assertions — tombe. Un contrôle SEO qui rougit, une page ordinaire en 500, une dérive DNS : PostShip alerte, mais ne revient pas. Les revérifications T+2 et T+8 non plus : 8 minutes après, une panne peut venir d'ailleurs, et un retour automatique ferait plus de mal que de bien.

Désactivée par défaut. Remettre une ancienne version en production est une décision qu'on prend une fois, pas une qu'on subit.

Vers quoi on revient

Le déploiement de production Vercel le plus récent, avant celui qui a cassé, dont la vérification PostShip était bonne, et dont Vercel a encore l'URL. S'il n'y en a pas — premier déploiement suivi, ou tous les précédents étaient déjà rouges — PostShip le dit et ne fait rien.

Chaque déploiement ne fait l'objet que d'un seul retour, même si 2 personnes cliquent, même si l'automatique et la main se croisent.

Ce que PostShip envoie

Sur les salons Discord et Slack du projet (canaux) et par email au propriétaire, un message « Retour arrière sur Acme » : quel déploiement a été retiré, lequel est de retour, et si c'était une décision du projet ou d'une personne. Une ligne apparaît aussi sous le déploiement, dans Déploiements.

Dépannage

« Vercel a refusé : l'intégration n'a pas la permission… »

Le retour passe par le jeton de l'intégration PostShip. Si elle a été installée avec un accès en lecture seule aux déploiements, Vercel refuse. Réinstallez-la depuis Paramètres → Intégrations, carte Vercel en accordant l'accès aux déploiements ; la ligne du déploiement garde la raison, et le bouton reste disponible pour réessayer.

« Aucun déploiement précédent vérifié bon »

PostShip ne revient que vers un déploiement qu'il a lui-même vu passer ses vérifications. Après le premier déploiement suivi, il n'y en a pas encore : cette fois, le retour se fait dans Vercel.

Le retour a eu lieu, mais la page est toujours rouge

Vercel bascule en quelques secondes ; PostShip revérifie au passage suivant et aux revérifications T+2 et T+8. Si la page reste rouge, la panne ne venait pas du déploiement — regardez la cause probable et les fournisseurs.