Radar de mutation

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 radar de mutation regarde ces quatre 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 quatre 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 de ship.

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 « Lancer 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é(s) » à 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

• Paramètres → Notifications, section « Alertes par email » : la case 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, Telegram 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 de ship, 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.