Badge et partage

Un badge SVG par projet, opt-in — pass/fail uniquement, sans historique, sans liste d'URL, sans journal d'incidents. Il répond « introuvable » tant que vous ne l'avez pas explicitement activé depuis la page Rapport (Projet → Public → Rapport). Ce n'est pas une page de statut : pour ça, il y a la page de statut.

Ce que PostShip fait

Le badge vit à postship.fr/badge/<identifiant-du-projet>. Une image de 140 × 20 pixels, dans le style de shields.io : « PostShip » à gauche, l'état à droite, 2 aplats de couleur et rien d'autre — pas de reflet, pas de dégradé, un bit d'information.

Pendant une fenêtre de maintenance annoncée, le badge dit « maintenance » plutôt que « passing » : un lecteur mérite de savoir que les vérifications ne sont pas le sujet en ce moment, et « up » serait une affirmation que personne ne garantit.

Le badge vivant

Même adresse, avec ?ship : postship.fr/badge/<identifiant-du-projet>?ship. À la place de l'état, le Ship Score du dernier déploiement — « ship | 94 » — qui se met à jour tout seul là où on l'a collé : README, pied de page d'un site client, page de statut. Vert à partir de 90, orange à partir de 70, rouge en dessous ; un tiret tant qu'aucun déploiement n'a été suivi. Il obéit au même interrupteur que le badge d'état, et dit « maintenance » pendant une fenêtre annoncée.

L'image est servie avec un cache d'une minute. Elle ne porte aucune URL, aucun détail de vérification, aucune donnée personnelle : seul l'état résumé du projet sort.

Régler

Projet → Public → Rapport, carte Badge public → Activer le badge. La page affiche alors les deux badges et leur Markdown à copier : une image Markdown dont la source est https://postship.fr/badge/<identifiant-du-projet>, entourée d'un lien vers https://postship.fr. Copiez-le depuis la page plutôt que de reconstruire l'adresse. En HTML, la même image dans une balise img avec un lien autour :

<!-- Dans un README HTML, une page d'aide, un pied de page -->
  <a href="https://postship.fr"><img src="https://postship.fr/badge/<identifiant-du-projet>" alt="PostShip" width="140" height="20"></a>

Désactiver fait répondre 404 à l'adresse, immédiatement (au cache près) : un README qui l'affiche encore montre une image cassée, pas un état périmé.

Le reste de la page Rapport

La page Rapport réunit ce que vos visiteurs et vos clients voient de ce projet, sans accès à votre tableau de bord :

• Cartes sociales : l'aperçu réel de chaque page qui a une vérification Open Graph — titre, description, image, tels que les réseaux les afficheront.
• Badge public : cette page.
• Carte de déploiement : une page publique non listée avec le score du dernier déploiement — voir Carte de déploiement.
• Liens de lecture pour un client : un lien psl_… qui ouvre le projet en lecture seule. Une agence qui surveille le site de son client veut le lui montrer sans lui donner un compte collaborateur — qui verrait les jetons d'API, la facturation, les autres projets. Le jeton n'est pas conservé, seule son empreinte l'est : un lien perdu se révoque, il ne se retrouve pas. Il périme au bout de 90 jours, parce qu'un lien de lecture qui ne périme jamais finit par circuler — dans un fil de discussion, dans un ticket, chez le prestataire suivant. Un lien inconnu, révoqué ou périmé répond exactement la même chose. En Pro Plus, ce lien est le portail client : l'en-tête porte votre marque blanche et l'icône du site du client, et la page de statut comme le rapport, quand ils sont publics, sont à un clic. Pas de jeton, pas de facture, rien de ce qui est l'affaire de l'agence.
• Lien magique : la même page, sur tous les plans, pour 7 jours — « montre ça à mon associé ». L'état du site et le dernier déploiement, en lecture seule, sans compte. 3 liens magiques actifs au plus par projet ; en Pro Plus, les liens client durent 90 jours et portent un nom.

Ce qui déclenche une alerte

Rien : le badge et les liens reflètent l'état, ils ne l'évaluent pas. Ce qui change la couleur, ce sont vos vérifications (HTTP et assets, pages de paiement, etc.).

Limites et plans

Voir les plans.

Dépannage

Pourquoi le badge affiche-t-il « pending » alors que mes vérifications tournent ?

Le badge lit l'état résumé du projet, écrit à la fin de chaque passage. Sur un projet tout neuf, le premier passage n'est peut-être pas fini : la première vérification part à l'ajout de l'URL, et le cycle suit, d'une à cinq minutes d'intervalle selon le plan — en Pro Plus, la sonde de 30 secondes relance un passage dès qu'une page change d'état.

Pourquoi le badge reste-t-il vert alors qu'une URL est en échec ?

Une minute de cache. L'état du projet est recalculé après chaque passage — et après chaque « Vérifier maintenant » — sur le dernier verdict de toutes les cibles actives : une seule en fail ou en error suffit à le mettre en rouge. Si le badge reste vert, la cible en cause est désactivée, ou son verdict n'a pas encore été écrit.

Pourquoi mon README affiche-t-il une image cassée ?

Le badge est désactivé (404), ou l'identifiant du projet a été mal copié. Copiez le Markdown depuis la page Rapport plutôt que de reconstruire l'adresse.

Carte de déploiement

Disponible avec les plans Pro et Pro Plus.

La page publique non listée qui répond « est-ce que le site va bien ? » avec le score du dernier déploiement, sans ouvrir le tableau de bord.

Un fondateur envoie le badge à un client et reçoit « c'est tout ? ». La carte de déploiement est la page qui répond à cette question, et à rien d'autre : le nom du projet, le score du dernier déploiement et sa raison, les 8 derniers scores en barres, et le type des points encore ouverts. Jamais une URL, jamais un pourcentage de disponibilité, jamais une donnée personnelle. Pensée pour être envoyée à un client, elle ne donne pas accès au tableau de bord.

Ce que la carte montre

À l'adresse postship.fr/ship/<jeton>, interdite aux robots (noindex) :

• Dernier déploiement vérifié : le Ship Score du dernier déploiement de production — jamais une preview — en vert à partir de 90, orange à partir de 70, rouge en dessous ; la raison de la note (« −25 asset manquant ») ou « Tout est passé. » ; et depuis quand.
• Les 8 derniers déploiements en barres, colorées de la même façon. Un score de 0 reste une barre visible, pas un vide que l'œil lirait comme une donnée manquante.
• Parcours d'achat : « n / n » des pages de paiement au vert — le compte, jamais les adresses, parce que les URL elles-mêmes dessineraient le parcours de paiement. « Paiement, connexion et prix vérifiés. » ou « Une étape du parcours ne répond plus comme attendu. »
• Ce que ce déploiement a changé : le nombre de pages dont le titre, le H1, la description ou la carte sociale ont bougé depuis le déploiement précédent, d'après le diff du déploiement. Le nom des champs, jamais leur contenu.
• Points ouverts : le type des 3 cibles en échec les plus anciennes (« HTTP », « Certificats », « Parcours ») et depuis quand — pas leur URL, qui dirait quelles parties du site existent et lesquelles sont cassées.
• Pendant une fenêtre de maintenance, la carte l'annonce avec la raison, à la place du score.

Un projet sans déploiement vérifié affiche « Aucun déploiement vérifié pour l'instant. »

La page « ce que ce déploiement a changé »

Depuis la carte, « Voir le détail : avant / après » ouvre postship.fr/ship/<jeton>/changes : le diff du déploiement rendu partageable. Page par page, ce qui a bougé entre le dernier déploiement de production et le précédent — le titre, le H1, la description, l'og:title avant / après ; l'og:image avant / après en images (l'image d'avant vient de l'archive, même si son URL ne répond plus) ; les prix avant / après relevés par le canary prix ; et les ressources cassées (scripts, feuilles, images qui ne répondent plus). Les pages inchangées sont repliées en bas. ?d=<identifiant du déploiement> fixe la page sur un déploiement précis — l'identifiant est celui de la page Déploiements, pas une suite qu'on devine.

C'est ce qu'une agence envoie à son client à la place d'un « c'est en ligne », et ce qu'un indie colle dans son changelog. Contrairement à la carte, cette page montre les URL surveillées et leur contenu public — ce qu'un visiteur du site voit déjà — mais rien des réglages, des jetons ni des previews. Même jeton, même interrupteur, même plan que la carte.

Régler

Projet → Public → Rapport, carte Carte de déploiement → Activer. La page affiche l'adresse à copier et un lien pour l'ouvrir.

Le jeton (32 caractères hexadécimaux, tirés au hasard) est frappé une fois et conservé : désactiver puis réactiver la carte garde la même adresse, pour qu'un lien déjà envoyé à un client continue de fonctionner. La carte est non listée plutôt que secrète : le jeton dans l'adresse est la seule chose entre un inconnu et la page, et il n'y a pas de bouton pour le régénérer.

Désactiver fait répondre « introuvable » — la même réponse qu'un jeton faux, pour ne pas confirmer qu'un projet existe derrière une adresse devinée.

Le résumé hebdomadaire par email (Compte → Notifications) inclut le lien de la carte quand elle est active.

Ce qui déclenche une alerte

Rien : la carte reflète les déploiements et les vérifications. Ce qui la fait bouger, ce sont les webhooks de déploiement, le score, et l'état des cibles.

Limites et plans

La même ligne que les autres fonctions de déploiement : un projet Découverte a une poignée d'URL et 7 jours d'historique, la carte serait une page presque vide avec le nom du client dessus. Une carte activée puis rétrogradée en Découverte répond « introuvable » : la carte se paie, donc elle se reprend — et son réglage reste atteignable pour la retirer. Voir les plans.

Dépannage

Pourquoi la carte dit-elle « Aucun déploiement vérifié » alors que je déploie tous les jours ?

Seuls les déploiements de production notés comptent. Sans hébergeur connecté ni détection par empreinte, PostShip ne sait pas qu'un déploiement a eu lieu. Les previews ne sont jamais montrées ici : une preview vérifiée il y a 2 minutes ne dit rien de ce qui est en ligne.

Pourquoi les points ouverts ne nomment-ils pas la page cassée ?

C'est voulu. La carte est faite pour être transférée ; une URL dirait à n'importe quel destinataire quelles parties du site existent et lesquelles sont en panne en ce moment. Le type et l'ancienneté suffisent à répondre « est-ce grave ? ».

Pourquoi le lien a-t-il cessé de fonctionner ?

La carte a été désactivée, ou le plan du propriétaire est repassé en Découverte. Le jeton, lui, ne change jamais : réactiver rend le même lien valide.

Rapport partageable

La page non listée que vous envoyez à un client qui demande « alors, ce mois-ci ? » : disponibilité, incidents, déploiements, budget d'erreur, contrôles du site.

Ce qu'une agence envoie à son client en fin de mois, sans capture d'écran ni export : une page publique, non listée, derrière un jeton. Disponibilité, incidents, déploiements, budget d'erreur, contrôles du site — sur la fenêtre que le plan conserve. Rien qui identifie une personne, aucune URL surveillée autre que le site lui-même, aucun détail d'échec : le client lit un bilan, pas un tableau de bord. Une page qui s'imprime.

Ce que le rapport montre

À l'adresse postship.fr/rapport/<jeton>, interdite aux robots (noindex), sur les N derniers jours (N = la rétention du plan, 30 au plus) :

• Le bilan en une phrase, celle qu'on lit avant les chiffres : « Disponibilité 99,97 % sur 30 jours, 2 incidents, 9 déploiements dont 1 en échec. »
• Disponibilité : le taux de vérifications réussies sur la période, à 2 décimales, avec le nombre total de vérifications. Toutes les cibles du projet comptent, y compris les contrôles du site.
• Incidents : les incidents ouverts sur la période (50 au plus), avec leur résumé, la date de début et la durée (« 12 min », « 1 h 05 », « en cours »). Publiés ou non : ce sont les incidents au sens de l'application, pas seulement ceux racontés sur la page de statut.
• Déploiements : le nombre de déploiements de production sur la période, et combien ont échoué. Jamais une preview.
• Objectif de disponibilité et budget d'erreur, si le projet a un objectif : « X d'indisponibilité estimée sur Y tolérées ». Les objectifs possibles sont 99 %, 99,5 %, 99,9 %, 99,95 % et 99,99 %.
• Contrôles du site : chaque contrôle actif avec son dernier verdict — « au vert », « à corriger », « non concluant », « pas encore vérifié » — et le compte « n sur m au vert ». Le nom du contrôle, jamais le détail de ce qui manque.

Le pied de page dit la méthode : les vérifications ont lieu après chaque déploiement et à intervalle régulier, et la disponibilité est le taux de vérifications réussies.

Régler

Projet → Public → Rapport, carte Rapport partageable : l'interrupteur Activer le lien, qui s'enregistre tout seul. Le lien est affiché en permanence avec un bouton pour le copier ; tant qu'il n'est pas activé, il répond « introuvable ».

Le jeton (32 caractères hexadécimaux) est propre au projet et ne change pas : éteindre puis rallumer le rapport rend le même lien valide, pour que celui déjà envoyé remarche. Un jeton inconnu et un rapport éteint donnent la même réponse.

L'objectif de disponibilité se règle dans Projet → Paramètres → Surveillance, ligne Objectif de disponibilité : sans objectif, le rapport n'a pas de section budget d'erreur.

Ce qui déclenche une alerte

Rien depuis le rapport : il lit ce que les vérifications, les incidents et les déploiements ont écrit.

Limites et plans

La fenêtre est celle de la rétention : un rapport qui prétendrait couvrir un mois avec 7 jours de données serait vide sur sa fin, ce qui se lit comme « aucun incident » plutôt que « pas de données ». Voir les plans.

Dépannage

Pourquoi la disponibilité du rapport diffère-t-elle de celle de la page de statut ?

La page de statut ne compte que les composants affichés ; le rapport compte toutes les vérifications du projet, contrôles du site compris. Un contrôle en erreur pendant 2 jours pèse sur le rapport, pas sur la page de statut s'il n'y figure pas.

Pourquoi un incident apparaît-il ici alors que je ne l'ai pas publié ?

Le rapport est fait pour un client à qui vous devez des comptes, pas pour le public : il liste les incidents réels de la période, publiés ou non. Si un incident ne doit pas y figurer, c'est le lien qu'il faut ne pas envoyer.

Pourquoi le rapport dit-il « Aucune vérification sur la période » ?

Le projet est en pause, ou n'a aucune URL active. La phrase est honnête plutôt que rassurante : sans vérification, il n'y a pas de disponibilité à annoncer.

Rapport mensuel à vos clients

Disponible avec le plan Pro Plus.

Le 1er du mois, le bilan du mois écoulé part par email aux adresses de votre choix — pour les agences qui rendent des comptes à leurs propres clients.

Le rapport partageable est une page qu'on envoie à la main quand le client demande « alors, ce mois-ci ? ». Le rapport mensuel est le même bilan, sans qu'on ait à y penser : le premier de chaque mois, le mois écoulé part par email aux adresses que vous avez données — votre client, son responsable technique, qui vous voulez. Vous n'avez rien à faire le 1er, et le client n'a rien à demander.

Régler

Projet → Public → Rapport, carte Rapport partageable, section Rapport mensuel par email. Une adresse par ligne, 10 au plus, puis Enregistrer. Vider la liste arrête les envois.

M'envoyer un aperçu du mois dernier vous envoie, à vous, tout de suite, exactement ce que les destinataires recevront pour le mois écoulé — pour juger avant que le 1er ne décide. L'aperçu porte « [Aperçu] » dans son objet.

Ce que le client reçoit

Un email « Acme — rapport de août 2026 », de PostShip, auquel répondre écrit au propriétaire du projet — c'est vous que le client connaît, pas nous. Dedans :

• le bilan en une phrase : « Disponibilité 99,93 % sur 31 jours, 1 incident, 14 déploiements dont 1 en échec » ;
• les chiffres : disponibilité, vérifications, incidents, déploiements, budget d'erreur si un objectif est réglé, et l'état des contrôles du site — « 6 au vert » ou « 1 à revoir : Balises SEO » ;
• la liste des incidents du mois, avec leur date et leur durée, tels qu'ils ont été publiés ;
• le lien vers le rapport en ligne, si le rapport partageable est activé.

Comme le rapport partageable : aucune URL surveillée autre que le site, aucun détail d'échec, personne n'est nommé. Le client lit un bilan, pas un tableau de bord.

En marque blanche (Pro Plus)

Sur la page de l'espace, Marque blanche : votre nom et votre logo (une adresse https). Dès lors, l'en-tête de l'email et de la page du rapport porte votre marque à la place de PostShip, et la mention devient « Rapport établi par Studio Corail à partir des vérifications automatiques du site ». Le pied légal de l'email reste : l'expéditeur technique est PostShip, et un email doit le dire. C'est votre livrable du 1er, pas un email de plus signé par un tiers. Une marque, tous les sites de l'espace ; un nom vide la retire ; après une rétrogradation, l'en-tête redevient PostShip sans qu'on touche au réglage.

Le mois

Un mois civil, clos, dans le fuseau du projet (celui des heures calmes, Paris par défaut) : « août 2026 » veut dire du 1er au 31 août, pas « les 30 derniers jours ». L'envoi part au premier passage après 8 h le 1er du mois. Un projet qui active le rapport le 20 reçoit le mois précédent dès le prochain passage — puis les suivants le 1er.

Chaque mois n'est envoyé qu'une fois par projet, même si 2 passages se croisent.

Limites et plans

Plan Pro Plus : c'est le plan de celles et ceux qui rendent des comptes à leurs propres clients. 10 destinataires par projet. Les données remontent aussi loin que le plan les conserve (90 jours pour Pro Plus) : un mois entier tient dedans.

Dépannage

Le rapport n'est pas parti le 1er

Vérifiez que la liste n'est pas vide et que le projet est bien sur le plan Pro Plus (la carte le dit). L'envoi se fait au premier passage après 8 h dans le fuseau du projet : un fuseau réglé sur Nouméa part quand Paris dort encore. La carte indique le dernier mois envoyé.

Un destinataire ne le reçoit pas

L'email part de l'adresse de PostShip, avec le nom du projet en objet. Demandez au destinataire de regarder ses indésirables, puis d'ajouter l'expéditeur à ses contacts. Si l'adresse a rejeté l'email, écrivez-nous depuis Aide : nous regardons la trace de l'envoi.

Post-mortem

Le post-mortem d'un incident en Markdown, prêt à coller, et le lien non listé pour le partager avec un client puis le retirer.

Après une panne, il faut écrire ce qui s'est passé : pour l'équipe, pour un client, pour la prochaine fois. PostShip a déjà la chronologie — le premier échec, les confirmations, le déploiement qui précède, le retour au vert — et une cause probable. Le post-mortem les met dans un document en Markdown, à coller dans un wiki ou un ticket, ou à partager par un lien non listé que vous pouvez retirer. Ce que le client lit est exactement ce que l'équipe a lu.

Ce que le document contient

Heures en UTC, annoncées dans l'en-tête de la chronologie, parce que ce sont celles des journaux qu'on ira lire. Pas d'emoji : ce document est lu à froid.

• L'en-tête : « Post-mortem — » suivi du résumé de l'incident ; le projet et son adresse ; début, fin (ou « en cours ») et durée.
• Impact : l'URL touchée, l'erreur relevée, et les autres cibles au même moment — « aucune des 7 autres en échec, la panne est propre à cette page » ou « 3 sur 7 en échec au même moment ».
• Chronologie (UTC) : une ligne par événement, avec l'heure, le délai relatif au début (« 3 min avant », « au moment de la panne », « 1 h 12 min après ») et le texte : premier échec, déploiement précédent, prise en charge, escalade, retour au vert.
• Cause probable : l'hypothèse principale en gras avec son niveau de confiance (forte, moyenne, faible) et ses preuves, puis les autres hypothèses retenues. Les causes possibles : Déploiement, Fournisseur en incident, Changement DNS, Certificat, Réseau régional, Script tiers, Saturation, Panne du site entier, Maintenance annoncée, Cause inconnue. Les règles qui les départagent sont sur la page Cause probable.
• Ce que PostShip n'a pas vu : la réserve, toujours. PostShip observe depuis l'extérieur ; les journaux du serveur, les métriques internes et les changements de configuration hors déploiement ne sont pas dans cette chronologie. Quand la confiance est faible ou la cause inconnue, le document le dit en toutes lettres : ce qui précède est une corrélation faible, pas une explication.
• Prise en charge : qui a pris l'incident, combien de temps après le début, et l'escalade à toute l'équipe si elle a eu lieu — ou « Personne n'a pris en charge cet incident. »

Régler

Projet → Incidents → l'incident. Sous la chronologie, la carte Post-mortem :

1. Copier : le bouton copie le Markdown entier (la carte affiche son nombre de lignes). Collez-le dans votre wiki, votre ticket, votre canal.
2. Partager par un lien : cochez la case, puis Enregistrer. Le lien postship.fr/pm/<jeton> apparaît avec un bouton de copie. La page publique porte le même contenu, le titre « Post-mortem · nom du projet », et « Généré par PostShip · heures en UTC » en pied.
3. Retirer : décochez, Enregistrer. Le lien répond désormais « introuvable ».

Un jeton neuf à chaque partage : retirer puis remettre change le lien, et l'ancien ne rouvre pas. C'est le contraire de la carte de déploiement, dont le lien est fait pour durer — un post-mortem partagé à un client pour une panne donnée n'a pas vocation à rester ouvert. La page est interdite aux robots.

Un membre en lecture seule peut copier le Markdown mais ne peut pas partager ni retirer le lien.

Ce qui déclenche une alerte

Rien : le post-mortem est un document, il ne surveille pas. Ce qui le nourrit : l'incident lui-même, l'acquittement, l'escalade, et les signaux que la cause probable a relevés.

Limites et plans

Disponible sur tous les plans, pour chaque incident. Les signaux relus pour la cause probable viennent de l'historique du projet, donc de la fenêtre de rétention du plan.

Dépannage

Pourquoi la cause probable est-elle « inconnue » ?

Aucun signal décisif autour du début de la panne : pas de déploiement récent, pas de dérive DNS, pas de fournisseur en incident, pas d'autre cible en échec. Le document dit alors que les journaux du serveur autour de l'heure du début en diront plus. C'est une réponse honnête, pas un défaut.

Pourquoi le lien partagé ne fonctionne-t-il plus ?

Quelqu'un a décoché « Partager par un lien », ou a décoché puis recoché : le jeton change à chaque partage. Copiez le lien affiché maintenant sur la page de l'incident.

Pourquoi les heures du document ne sont-elles pas les miennes ?

Le Markdown et la page publique sont en UTC, pour correspondre aux journaux de votre serveur et de votre hébergeur. Dans l'application, la chronologie de l'incident est affichée dans votre fuseau.