Ce qui tombe en panne vous est dit, avant que ça vous coûte une semaine

Une vingtaine de sondes réelles, toutes les cinq minutes : compte Beds24, rattachement à chaque plateforme, synchronisation, webhook, flux calendrier, site, devis, paiement, mesure, tâches, base, serveur.

Chaque sonde a son délai et son verdict. Trois états, jamais un vert par défaut : bon, attention (ça tourne, mais pas dans l'état voulu), panne. Le verdict d'ensemble est le pire des verdicts.

Une sonde qui ne peut pas conclure dit « inconnu », pas « bon ».

Parmi les nuits que nous ouvrons, combien la plateforme en montre-t-elle encore ? C'est la seule mesure qui attrape une annonce refermée sans que rien n'ait changé chez nous.

Deux capteurs indépendants : le calendrier public de l'annonce, et le flux hôte. Si l'un est aveugle, l'autre tranche. La mesure est relative à ce que nous avons ouvert : un comptage absolu sonnerait chaque hiver.

Sur une plateforme sans calendrier public, un calendrier vide se lit « tout ouvert » : la veille y détecte une fermeture massive, pas une dépublication. Cette limite est écrite, pas cachée.

Pas dix courriels pour la même panne. L'épisode est marqué avant l'envoi, un délai sépare deux alertes d'un même sujet, et le retour à la normale est annoncé une fois.

Une sonde en panne alerte l'exploitant, jamais le voyageur ni vous par erreur : sinon la panne de l'outil de mesure redevient le silence qu'il corrige.

Les alertes nomment les maisons en clair, jamais un identifiant technique.

Une quarantaine de lignes, chacune prouvée par un appel réel : Beds24, chaque plateforme, flux, site, paiement, mesure, tâches, base, serveur. Avec le reste à faire, et qui le fait.

La checklist se relance à la demande et met à jour un seul chantier, jamais un doublon. Elle est en lecture seule : rien n'est écrit vers une plateforme pendant le contrôle.

« En vente » selon Beds24 n'est pas « en vente » selon la plateforme : seul le calendrier public prouve qu'une annonce vend.

Certains gestes se font chez la plateforme, par vous. La console les liste, avec le lien exact, et vous les cochez : fait, pas marché, sauté, avec une note.

Une étape cochée ferme la tâche correspondante du plan, avec sa preuve. Une étape en échec devient un garde-fou pour la suite.

Les étapes qui engagent de l'argent ou un envoi externe ne se cochent que par vous.

Chaque liaison posée est relue avant d'être déclarée bonne. Un accusé de réception, un code 200, un « succès » renvoyé par une API ne prouvent rien.

Certaines interfaces acceptent un champ qui n'existe pas et répondent « succès ». La console relit toujours ce qu'elle vient d'écrire, et ne dit « ok » qu'après relecture conforme.

Deux passes au même chiffre sans progression sont un refus, pas un quota : la console le dit.