Introduction

PostShip vérifie votre site comme un vrai visiteur, juste après chaque déploiement puis toutes les 5 à 30 minutes : statut HTTP, fichiers JS et CSS, aperçu Open Graph, sitemap, certificat, formulaires, parcours de paiement, contrats d'API. Vous êtes prévenu seulement quand quelque chose casse — silence quand tout est vert.

Comment ça s'articule

Un projet représente un site : son domaine de production. À l'intérieur, des URL surveillées — la page d'accueil, le checkout, une page de connexion — chacune avec sa propre sorte de vérification. À chaque passage, PostShip demande chaque URL et écrit un résultat : pass, fail ou error. Un fail ouvre un incident ; le retour au vert le ferme.

Par où commencer

1. Créer votre premier projet et ajouter une URL : la première vérification part immédiatement.
2. Brancher votre hébergeur pour que chaque déploiement soit vérifié à la seconde.
3. Choisir où être prévenu : email par défaut, Discord ou Slack.
4. Laisser tourner. Les contrôles du site et la page Performance se remplissent seuls.

Ce que ce guide contient

• Vérifications : chaque sorte d'URL, ce qu'elle regarde, ce qui la met en échec.
• Déploiements : le ship vérifié, le Ship Score, le diff, les previews, le gel.
• Alertes & incidents : les canaux, les règles de silence, la prise en charge, la cause probable.
• Performance & visiteurs : le temps de réponse, les vitals réels, les erreurs de vos visiteurs, les 5 continents.
• Sécurité & intégrité : scripts tiers, en-têtes, fichiers exposés, certificats, DNS.
• Pages publiques : la page de statut, le badge, les rapports.
• Automatisation : l'API, la CI et la CLI.
• Compte & plans : ce que chaque plan permet.

Vocabulaire

Les 10 mots que l'application emploie partout, et ce qu'ils désignent exactement.

PostShip a un vocabulaire court et l'emploie de façon stricte : un « passage » n'est pas une « vérification », un « incident » n'est pas une « alerte ». Cette page définit chaque mot une fois, tel qu'il apparaît à l'écran, dans les emails et dans l'API.

Projet

Un site : son nom et son domaine de production (https://acme.fr). Tout ce que PostShip surveille vit dans un projet, et toute URL ajoutée doit appartenir à ce domaine ou à un sous-domaine. Les réglages d'alerte, l'hébergeur branché, la page de statut publique sont attachés au projet. Voir Premier projet.

URL surveillée (cible)

Une adresse que PostShip demande, avec une sorte de vérification. L'application dit « URL surveillée » ; l'API et le code disent « cible » (target). Une cible a un dernier verdict, une série d'échecs consécutifs, et peut être désactivée : elle garde alors son dernier résultat comme une trace, sans compter comme une panne.

Sorte

Ce qu'on vérifie sur une cible. Celles que vous ajoutez vous-même : HTTP, OG / Twitter, Sitemap, SSL, Formulaire, Contrat d'API, Parcours, Battement, et la vérification Paiement. Celles que PostShip crée pour vous, une par projet : Indexabilité, Sécurité, Cookies, Redirections, Balises, Fuites, Fichiers exposés, Scripts tiers — ce sont les contrôles du site.

Passage

Une exécution d'une cible, à un instant donné. Chaque passage écrit un résultat :

Un passage porte aussi le statut HTTP, le temps de réponse (TTFB) et une empreinte : la signature de la panne (verdict + statut + manques). 2 passages qui échouent pour la même raison ont la même empreinte ; c'est ce qui évite de vous réalerter à chaque cycle pour la même chose, et ce qui vous réalerte quand la panne change de nature (un 503 devenu 404).

Les passages sont déclenchés par le cycle (toutes les 5 min sur Découverte, 2 sur Pro, 1 sur Pro Plus), par la sonde de 30 secondes de Pro Plus quand une page change d'état, par un déploiement, par T+2 et T+8, ou par « Vérifier maintenant ».

Incident

Une cible active dont le dernier passage est fail ou error. Il s'ouvre au premier verdict rouge et se ferme au retour du vert ; la page Incidents du projet liste ceux qui sont ouverts, avec une phrase qui nomme la cause. Une cible désactivée n'a jamais d'incident ouvert.

L'alerte est autre chose : c'est le message envoyé. Par défaut elle part au premier échec ; avec la confirmation (Projet → Alertes → Règles, « Alerter après 2 échecs d'affilée » ou 3), l'incident existe dès le premier échec mais l'alerte attend la confirmation. Le journal distingue 4 événements : « En échec », « Rétabli », « Contenu modifié », « Dérive DNS ». Voir Incidents et Règles.

Ship

Un déploiement en production, et la vérification qui l'accompagne. Quand votre hébergeur prévient PostShip (webhooks), toutes les cibles du projet sont repassées immédiatement, puis deux et huit minutes plus tard. La page Déploiements garde chaque déploiement avec son verdict, son diff et son score.

Ship Score

Une note sur 100 après chaque déploiement, calculée sans modèle de langage : on part de 100 et on retire des points par catégorie de manque.

2 pages de paiement en échec coûtent 2 fois 40 ; 4 contrôles du site en échec coûtent 10 en tout — un site qui vend bien ne doit pas rater son ship pour 4 balises. Sur Pro Plus, le Check GitHub peut exiger un score plancher. Détail sur Ship Score.

Hors quota

Les cibles que PostShip crée lui-même (les contrôles du site) ne comptent pas dans le quota d'URL du plan : vous ne les avez pas demandées, les facturer reviendrait à réduire votre forfait sans le dire. Tout ce que vous ajoutez compte — y compris un parcours (une URL, pas 4) et un battement.

Contrôles du site

Les 13 vérifications posées sur l'origine du site et qui ne tournent qu'au déploiement (webhook, T+2 / T+8, « Vérifier maintenant ») : ce que robots.txt autorise, les en-têtes de sécurité, les cookies, les redirections ne changent qu'à la mise en ligne, et les redemander toutes les 5 minutes referait la même requête pour la même réponse. Ils se lisent, et s'éteignent un par un, dans Projet → URLs, où chacun a sa ligne. Sur Découverte, leur verdict est calculé et affiché, mais l'alerte n'est pas envoyée. Voir Contrôles du site.

Manque et avertissement

Dans un contrôle du site, un manque met la cible en échec et déclenche l'alerte ; un avertissement est noté sur la page de la cible sans rien déclencher. Un <title> absent est un manque pour les balises ; un <title> trop court est un avertissement. Chaque page de contrôle liste les deux séparément.