Ship Score

Chaque déploiement de production part de 100 et perd des points selon ce qui a échoué. Une seule note à la place d'un pass / fail, parce qu'un déploiement qui a cassé le checkout et un déploiement qui a perdu sa carte sociale ne sont pas la même nouvelle. Le calcul est déterministe : aucun modèle, aucune pondération cachée, le barème ci-dessous et rien d'autre.

Le barème

Les catégories s'additionnent : 2 pages de paiement en échec coûtent 80. Seule l'hygiène du site est plafonnée — 4 hygiènes manquantes ne doivent pas coûter 40 points à un site qui vend très bien ; une note que tout le monde rate ne dit rien. La note ne descend jamais sous 0.

Ce que vous voyez

• Sur l'Aperçu du projet : le score du dernier déploiement, et une ligne d'explication qui nomme la catégorie qui a le plus coûté, avec ce qu'elle a réellement retiré — −15 carte OG, −40 page de paiement. Rien quand le score est 100.
• Sur la page du déploiement (diff du déploiement) : « Ship Score · −15 carte OG », à côté du commit et des passages T+0 / T+2 / T+8.
• Dans le titre du Check GitHub : PostShip · 85.
• Sur la carte de déploiement publique.

Quand il est calculé

Une fois, à T+0, pour chaque déploiement de production connu (webhook ou empreinte). Les reprises T+2 et T+8 alertent mais ne renotent pas. Une preview n'a pas de note : la moitié de ce qui la compose — certificat, indexabilité, dérive DNS — n'a pas de sens sur un hôte de preview.

Le score est d'abord calculé sur les vérifications et la dérive DNS, puis, quand PageSpeed a répondu, recalculé avec les catégories « budget » et « rendu ». C'est ce second score qui part dans le Check GitHub.

Ce qui déclenche une alerte

Le score lui-même n'alerte pas : ce sont les vérifications qui le composent qui ouvrent des incidents, aux conditions habituelles (règles). 2 exceptions le rendent bloquant :

• En Pro Plus, le score plancher fait passer le Check GitHub au rouge sous le seuil (80 par défaut), même sans échec franc.
• Un gel de déploiement fait rougir le Check quel que soit le score.

Limites et plans

Sur Découverte, la note est calculée à chaque déploiement, mais la mesure PageSpeed n'y est pas rattachée. Voir les plans.

Dépannage

Pourquoi la ligne d'explication ne fait pas le compte avec le score ?

Elle ne nomme que la catégorie qui a le plus coûté, avec ce qu'elle a retiré. Un score de 55 avec « −25 asset manquant » a perdu 20 points ailleurs : la page du déploiement liste chaque URL et son verdict.

Pourquoi le score est à 90 alors que tout est vert ?

Le certificat expire dans moins de 14 jours. La vérification SSL passe encore ; la catégorie « SSL bientôt expiré » est indépendante du verdict, parce qu'un certificat à 10 jours de la fin est une information même quand tout marche. Voir Sitemap & SSL.

Pourquoi le score du dernier déploiement vaut « — » ?

Le déploiement n'a pas été noté : la fonction a été interrompue avant la fin, ou la ligne date d'avant l'existence du score. Le déploiement suivant en aura une.

T+2 / T+8

Les 2 re-vérifications automatiques programmées deux et huit minutes après chaque déploiement de production, et pourquoi elles existent.

Un webhook qui dit « OK » à T+0 n'attrape pas le CDN ou le DNS qui cassent quelques minutes plus tard. Après chaque déploiement de production, PostShip programme donc 2 re-vérifications complètes : une à T+2 minutes, une à T+8 minutes. Elles attrapent ce qui casse une fois le cache CDN et le edge stabilisés — un problème invisible à la vérification immédiate, et que le cycle n'aurait relié à aucun déploiement.

Ce que PostShip fait

Dès que la ligne du déploiement est écrite dans Déploiements, 2 jobs sont posés dans la même file que le cycle, avec pour seule différence leur heure d'exécution : maintenant + 2 minutes et maintenant + 8 minutes. La file est ramassée toutes les 2 minutes : chaque reprise part au premier passage qui suit son heure. Le passage qui la ramasse fait exactement ce qu'il fait d'habitude — toutes les URL du projet — avec l'indice T+2 ou T+8 à la place de « deploy Vercel 14:32 ».

Un même déploiement ne peut porter qu'une reprise de chaque sorte : un webhook rejoué n'en programme pas une troisième.

Les reprises sont programmées pour toutes les voies qui enregistrent un déploiement de production : Vercel, Netlify, Cloudflare Pages, le webhook générique et la détection par empreinte. Une preview n'en reçoit pas : rien n'est en ligne.

Ce que vous voyez

La ligne du déploiement, dans Déploiements et sur la page du déploiement, affiche les 3 passages : « T+0 OK · T+2 OK · T+8 OK ». Chaque case vaut :

Le verdict T+0 est celui de la ligne elle-même ; T+2 et T+8 sont lus sur les deux jobs. Un déploiement détecté par empreinte a un T+0 qui est le passage de cycle où l'empreinte a changé.

Ce qui déclenche une alerte

Les reprises alertent aux mêmes conditions que le cycle (règles) : un fail qui ouvre un incident, un retour au vert qui le ferme. Le message porte la mention « Depuis le dernier déploiement : … », parce qu'un indice de déploiement est passé — c'est ce qui vous dit, à 14:40, que le 500 vient du ship de 14:32 et pas d'ailleurs.

Le ce qui a changé sonne aussi sur ces passages : ce sont des passages de déploiement, et un titre qui disparaît à T+8 parce qu'un cache s'est vidé est exactement ce qu'il cherche.

Une reprise ne recalcule pas le Ship Score et ne repose pas de Check GitHub : le score et le Check sont ceux de T+0. Les reprises alertent, elles ne renotent pas.

Limites et plans

Les reprises sont comprises dans tous les plans : elles suivent les déploiements reçus par webhook, ou détectés par empreinte de build. Voir les plans.

Dépannage

Pourquoi T+2 reste « en attente » longtemps ?

Les reprises passent par la même file que le cycle, ramassée toutes les 2 minutes : T+2 part donc entre deux et quatre minutes après le déploiement, T+8 entre huit et dix. Un passage chargé les décale encore un peu ; « en attente » au-delà d'un quart d'heure signale un ralentissement de la file, pas un problème sur votre site.

Pourquoi T+8 est en échec alors que T+0 et T+2 sont OK ?

C'est précisément le cas pour lequel les reprises existent : une invalidation de cache, une bascule DNS ou un déploiement échelonné qui finit d'arriver entre deux et huit minutes après. Ouvrez l'incident : l'URL en échec et le motif y sont.

Pourquoi les reprises n'apparaissent pas sur une preview ?

Volontaire. Une preview est vérifiée une fois, sur sa propre adresse ; elle n'a ni CDN de production ni DNS à stabiliser.

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.

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 — à 2 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). 2 pages qui chargent les mêmes fichiers versionnés viennent du même build. Sur Next.js, l'identifiant de build tranche à lui seul.

3 verdicts :

Avant de conclure « ancienne », PostShip relit le domaine une seconde fois, 20 secondes plus tard : à la seconde où l'hébergeur dit « prêt », l'alias peut être en train de basculer. 20 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 et Slack 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 3 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.

Diff du déploiement

Ce que ce déploiement a changé sur chaque page surveillée, comparé au déploiement précédent, et le résumé à coller dans un ticket.

Un verdict vert dit que la page répond. Il ne dit pas que le titre est devenu « Untitled », que la meta description a disparu ou que le bouton Stripe ne se charge plus. À chaque déploiement de production, PostShip enregistre l'état de chaque page ; la page du déploiement met cet état en face de celui du déploiement précédent et dit ce qui a bougé, le pire en premier.

Ce que PostShip compare

Pour chaque URL surveillée en HTTP, dans l'ordre où la page les montre :

Chaque cellule reçoit un verdict :

• identique — rien n'a bougé.
• modifié — le champ a changé, sans lire comme cassé : une retouche de titre, un 200 devenu 301.
• perdu — le champ avait un contenu et n'en a plus, ou il est devenu un texte qui ne peut être qu'une page cassée : « coming soon », « under construction », « lorem ipsum », « erreur » seul ou suivi d'un code (« erreur 500 »), « erreur serveur », « erreur interne », « error 5xx ». Un statut qui passe sous 400 à 400 ou plus est aussi « perdu », comme un token de prix présent devenu absent.

Les lignes sont triées du pire au moins grave : celle qui a perdu son H1 est la raison d'avoir ouvert la page.

Les domaines tiers

PostShip relève aussi les origines tierces chargées par chaque page — scripts, feuilles de style, iframes, images — et dit en une phrase ce que le déploiement leur a fait : « js.stripe.com ne se charge plus sur /checkout. » ou « cdn.segment.com est apparu sur /. ».

Aucune liste de domaines « critiques » en dur : ce qui compte, c'est ce que l'historique du projet montre comme stable. Une origine présente sur les 3 derniers déploiements est tenue pour installée, et sa disparition est signalée ; avec moins de 3 déploiements comparables, rien n'est déclaré disparu. Le contrôle continu est sur Scripts tiers.

Ce que la page montre

Ouvrez Déploiements, puis un déploiement : « Ce que ce déploiement a changé ». De haut en bas :

1. Le fournisseur (Vercel, Netlify, Cloudflare Pages, Webhook générique, Détecté sans webhook) et la date, suivis de « premier déploiement suivi, rien à comparer » s'il n'y a rien avant.
2. Un bandeau si le ship est arrivé pendant un gel, un autre si le domaine a bougé.
3. Carte sociale — avant / après : les deux og:image côte à côte quand elle a changé.
4. La mesure PageSpeed et le diff visuel des pages mesurées.
5. La ligne des domaines tiers, seulement quand quelque chose a bougé.
6. Le Ship Score et sa raison, le commit (lien vers GitHub si le dépôt est connu), la ligne des liens de la page d'accueil, et les passages « T+0 OK · T+2 OK · T+8 OK » (T+2 / T+8).
7. Le tableau Champ / Avant / Après, une section par URL.

Dans la liste Déploiements, chaque ligne porte déjà « Cassé depuis : … » et « Rétabli depuis : … » — les URL passées de vert à rouge, ou l'inverse, par rapport au déploiement précédent.

Le résumé copiable

Copier le résumé met dans le presse-papiers un texte brut, sans tableau ni image, prêt pour Slack ou un ticket client :

Acme — déploiement du 11 sept. 2026 14:32 · commit 3f2a9c1 · Ship Score 85/100

https://www.acme.fr/tarifs
  Titre : Tarifs — Acme → (vide)
  Token prix : présent → absent

Sans changement : « Aucun changement de contenu détecté sur les URLs surveillées. »

Ce qui déclenche une alerte

La page de diff n'alerte pas ; elle explique. Ce qui réveille quelqu'un, c'est le ce qui a changé, qui applique la même règle « perdu » aux 4 champs de texte au moment du déploiement, et les vérifications elles-mêmes (règles). Une origine tierce disparue est signalée sur la page du déploiement ; l'alerte sur un script tiers qui change vient de Scripts tiers.

Limites et plans

Voir les plans.

Dépannage

Pourquoi « premier déploiement suivi, rien à comparer » ?

Il n'existe pas de déploiement de production précédent pour ce projet. Le diff commence au deuxième.

Pourquoi une URL n'apparaît pas dans le tableau ?

Le diff ne montre que les URL dont l'état a pu être lu : une page HTML vérifiée en HTTP. Un sitemap, un certificat, un formulaire ou un parcours n'ont ni titre ni H1 ; ils apparaissent dans « Cassé depuis » s'ils échouent.

Pourquoi « modifié » et pas « perdu » alors que le titre est faux ?

« Perdu » est réservé à un champ vidé ou remplacé par un texte de page cassée. Une faute, une traduction, un titre remplacé par un autre titre sont « modifié » : visibles, pas alarmants.

Archive du déploiement

L'image de partage de chaque déploiement, gardée pour montrer l'avant une fois que l'URL d'origine a disparu.

Le diff du déploiement dit « og:image : modifié ». Il ne peut pas montrer ce que vous avez perdu : une fois le ship passé, l'URL d'avant renvoie le plus souvent un 404, et la preuve s'évapore avec elle. PostShip garde donc l'image elle-même, et affiche les deux côte à côte sur la page du déploiement quand elle a changé.

Ce que PostShip garde

À chaque déploiement de production reçu par webhook, une fois les vérifications passées, PostShip télécharge l'og:image de chaque page HTML surveillée et la range dans un stockage privé, rattachée à ce déploiement.

• Jusqu'à 5 images par déploiement, dans l'ordre des URL du projet.
• 2 Mo maximum par image ; au-delà, elle n'est pas gardée.
• Formats acceptés : PNG, JPEG, WebP, GIF.
• 6 secondes au total, 4 secondes par image : une image de partage lente n'a aucune raison de retarder la ligne de déploiement et le Check GitHub.

Sans navigateur sans tête, donc sans capture de page : le coût n'est pas le même, et l'image de partage est précisément celle dont la disparition ne se voit nulle part ailleurs — le site continue de répondre 200, et c'est le lien posté sur LinkedIn qui est vide. La capture de page, elle, vient de PageSpeed et sert à la régression visuelle.

L'URL de l'image est celle que votre page déclare : si elle pointe hors de votre domaine, elle est téléchargée quand même, avec les mêmes gardes que toute requête sortante de PostShip.

Ce que vous voyez

Sur la page du déploiement, la section Carte sociale — avant / après n'apparaît que si l'og:image d'au moins une page a changé. Chaque paire montre l'URL de la page, l'image « Avant » (archivée au déploiement précédent — à défaut, PostShip tente son URL d'origine) et l'image « Après ». « aucune » signale un côté sans image : un og:image retiré par ce déploiement se voit ainsi immédiatement.

Le contrôle d'Open Graph reste le juge du contenu de la balise ; l'archive n'ajoute que la mémoire visuelle.

Combien de temps

La fenêtre est celle du plan : au-delà, l'image est effacée par une purge quotidienne, par petits lots. Le diff, lui, continue de dire que l'og:image avait changé — il ne peut simplement plus le montrer.

Sur Découverte, « dernier déploiement seulement » signifie que tout ce qui n'est pas le déploiement de production le plus récent est effacé, quel que soit son âge. L'archive est alimentée par les webhooks de déploiement, sur tous les plans ; les déploiements détectés par empreinte n'archivent pas d'image. La purge suit la même fenêtre que le reste de vos données (rétention). Voir les plans.

Ce qui déclenche une alerte

Rien ici. L'archive est une mémoire, pas un contrôle. Une og:image absente ou injoignable est détectée par la vérification Open Graph, et un og:title perdu par le ce qui a changé.

Dépannage

Pourquoi l'image « Avant » manque alors que le diff dit « modifié » ?

3 raisons possibles : l'image du déploiement précédent dépassait 2 Mo ou n'était pas dans un format accepté ; elle n'a pas répondu dans les 4 secondes ; ou elle a été purgée parce que le déploiement précédent est sorti de la fenêtre du plan.

Pourquoi seules mes 5 premières pages ont une image archivée ?

Le plafond est de 5 images par déploiement, prises dans l'ordre des URL. Placez en tête de liste les pages dont la carte sociale compte le plus : l'accueil, les tarifs, la page produit phare.

Pourquoi la section n'apparaît pas alors que j'ai changé mon image ?

L'archive compare l'URL de l'og:image d'un déploiement à l'autre. Si vous avez remplacé le fichier derrière la même URL, la balise n'a pas changé, et rien n'est montré. C'est aussi le cas où le lien partagé garde l'ancienne image en cache chez les réseaux sociaux — changez le nom du fichier.

Ce qui a changé

Être prévenu quand un titre, un H1, une description ou un og:title disparaît ou devient « coming soon » juste après un déploiement.

La disponibilité dit 200. Elle ne dit pas que la page de tarifs a perdu son H1, que le titre est devenu « Coming soon » ou que la meta description a été vidée par un rendu à moitié cassé. Le ce qui a changé regarde ces 4 champs à chaque vérification HTTP, et ne vous réveille que quand un déploiement les a abîmés — jamais pour une retouche.

Ce que PostShip vérifie

À chaque vérification HTTP d'une page HTML, PostShip lit et garde 4 champs : le title, le premier h1, la meta description et l'og:title. Il les compare à ce qu'il avait gardé pour cette URL au passage précédent.

Un champ compte comme muté seulement si, à la fois :

• il était rempli avant ;
• et maintenant il est vide, ou son nouveau contenu contient « coming soon », « under construction », « erreur » ou « error 5xx ».

Un titre remplacé par un autre titre, une faute corrigée, une traduction : rien. Le radar cherche ce qui est cassé, pas ce qui est différent — le « différent » est sur la page du diff du déploiement.

Quand il sonne, quand il se tait

Le radar n'alerte que sur un passage de déploiement : la vérification T+0 déclenchée par un webhook ou par l'empreinte de build, et les reprises T+2 et T+8. Sur le cycle ordinaire ou sur un « Vérifier maintenant », les champs sont relevés et mémorisés, mais aucune alerte ne part, même si le titre disparaît — seul un ship peut être mis en cause, et c'est ce qui rend l'alerte lisible : vous savez déjà quel déploiement regarder.

L'état mémorisé est toujours celui du dernier passage. Une page qui perd son H1 un mardi soir sur le cycle ne sonnera donc pas jeudi au déploiement suivant : le champ était déjà vide « avant ».

Ce qui déclenche une alerte

Une alerte de sorte Contenu modifié, indépendante du verdict de la page : elle peut répondre 200 et être signalée. Elle part sur les mêmes canaux que les pannes (canaux), avec une ligne par champ touché :

Titre : « Tarifs — Acme » → vide
H1 : « Nos offres » → « Coming soon »

Dans l'email, l'entête compte « 1 modifié » à côté des échecs et des rétablissements, et le message porte la mention « Depuis le dernier déploiement : … ».

Le radar ne fait pas baisser le Ship Score et n'ouvre pas d'incident : la page répond, c'est son contenu qui a bougé.

Régler

• Compte → Notifications, section « Alertes par email » : l'interrupteur Le contenu a changé après un déploiement (« Un titre, une image de partage ou un prix modifié sans que rien ne casse ») coupe cette alerte par email, pour vous seul. Elle est cochée par défaut.
• Discord, Slack et le webhook sortant se règlent projet par projet dans Intégrations ; ils reçoivent les mutations comme les pannes.
• Les règles de silence — heures calmes, maintenance, URL en sourdine — s'appliquent aussi aux mutations.

Il n'y a rien d'autre à régler : la liste des champs et des mots suspects n'est pas modifiable.

Limites et plans

Le radar n'est pas réservé à un plan : ce qui change avec le plan, c'est la façon dont PostShip apprend vos déploiements (plans).

Dépannage

Pourquoi aucune alerte alors que mon titre a disparu ?

Soit la disparition n'a pas eu lieu sur un passage de déploiement ; soit le champ était déjà vide au passage précédent ; soit la page n'est pas vérifiée en HTTP (un sitemap, un formulaire ou un parcours n'ont pas de surface de page).

Pourquoi une alerte pour le mot « erreur » dans un titre légitime ?

Le motif est volontairement large : « erreur » seul suffit. Une page dont le titre contient ce mot par nature (« Gestion des erreurs ») sonnera si ce titre remplace un autre au déploiement. Décochez l'alerte email si elle gêne ; le diff du déploiement, plus strict, ne la classera pas en « perdu ».

Pourquoi l'alerte arrive à T+8 et pas à T+0 ?

Parce que le champ a disparu entre les deux : un cache qui s'est vidé, un rendu différent selon le nœud. C'est la raison d'être des reprises.