Méthodologie

Résumé

Cette page publie ce que des sondes automatisées observent depuis le réseau Cloudflare. Aucune valeur n’est saisie à la main, aucune histoire n’est reconstituée après coup, aucun pourcentage n’est arrondi.

Le document ci-dessous décrit la mesure assez précisément pour que vous puissiez la contester. Si vous constatez quelque chose qui contredit ce qui est affiché, la marche à suivre est à la fin.

Surveillance active depuis le 3 août 2026.

D’où partent les mesures

Les sondes s’exécutent dans un Cloudflare Worker déclenché par tâche planifiée. Elles partent donc du réseau Cloudflare, pas d’un poste de travail, pas d’un serveur chez Webryk, pas de votre bureau.

Trois conséquences, à retenir avant de lire le moindre chiffre :

1. Le point de sortie n’est pas épinglé à un centre de données précis. Cloudflare choisit où exécuter la tâche. Nous ne publions pas le lieu d’exécution parce que nous ne le contrôlons pas.
2. Le chemin réseau entre un point de présence Cloudflare et une origine n’est pas le chemin entre votre fournisseur d’accès et cette même origine. « Opérationnel » ici veut dire « joignable depuis le réseau Cloudflare », pas « joignable depuis chez vous ». Une panne de peering, un DNS d’entreprise, un pare-feu local ou un opérateur mobile peuvent vous couper d’un service que cette page déclare opérationnel. Les deux affirmations peuvent être vraies en même temps.
3. Les requêtes proviennent d’espaces d’adresses Cloudflare. Certains fournisseurs tiers traitent ce trafic différemment du trafic résidentiel, notamment pour la limitation de débit et la détection de robots.

Il n’y a pas de mesure côté navigateur réel. Cette page ne collecte rien chez les visiteurs.

Ce qui est mesuré, et à quelle cadence

Trois de ces six instruments ne sont pas en service aujourd’hui. Les raisons sont détaillées dans les sections correspondantes ci-dessous, et la conséquence est la même dans les trois cas : là où un instrument manque, rien n’est mesuré, et rien n’est mesuré veut dire « indéterminé », jamais « opérationnel ».

Quatre lignes sont dans ce cas : « Connexion et MFA », « Paiements », « Tâches planifiées » et « Stripe ». Aucune ne publie de pourcentage, et l’emplacement du chiffre le dit en toutes lettres au lieu d’annoncer un décompte qui n’avancerait jamais. Une vérification réelle qui échoue sur l’une d’elles reste affichée telle quelle : la mesure l’emporte toujours sur une déclaration d’absence, et « la surveillance n’est pas en service » ne sera jamais affiché par-dessus une panne constatée.

Les tâches planifiées sont un cas à part : elles ne sont pas sondées, elles se déclarent. Voir plus bas.

Vérification HTTP en boîte noire (60 s)

Requête GET depuis le Worker, ou HEAD sur les cibles où l’en-tête suffit, sans cache, avec un abandon à 8 secondes. Au-delà, la requête est abandonnée et la mesure compte comme un échec, pas comme une absence de mesure : la cible a eu son temps et n’a pas répondu.

Les redirections ne sont pas suivies. Une redirection est un signal sur la cible, pas un détour à emprunter, et elle est jugée telle quelle : une surface qui devait répondre 200 et répond 301 n’est pas conforme. Certaines cibles acceptent une redirection comme réponse conforme parce que c’est leur comportement normal ; c’est déclaré cible par cible, jamais par une règle générale.

La vérification réussit si le code de réponse est celui attendu pour la cible et si le corps de la réponse contient le marqueur attendu quand un marqueur est défini pour cette cible. Un code 200 servi par une page d’erreur générique ne compte pas comme une réussite. La connexion se fait en HTTPS et le runtime refuse un certificat invalide, ce qui fait échouer la requête ; cela ne veut pas dire que le certificat est mesuré, et la section TLS plus bas dit pourquoi.

Le temps de réponse total est enregistré. Il ne déclenche pas à lui seul une panne, et il n’existe pas un seuil unique : chaque vérification porte le sien. Les surfaces HTTP publiques passent à « dégradé » au-delà de 2 000 ms, les points de santé applicatifs au-delà de 1 500 ms, et la sonde observée de GitHub au-delà de 3 000 ms. Un seuil unique annoncé pour toutes serait faux pour deux familles sur trois.

Pour ce type de vérification, la règle publiée est qu’une seule mesure en échec ne change pas l’état affiché : il en faut trois consécutives, soit trois minutes à cette cadence, et le retour à « opérationnel » en exige autant. Ce seuil de trois vaut pour les vérifications à 60 s, et pour elles seulement : TLS, DNS et les battements de tâches planifiées changent d’état sur une seule observation. Les deux règles sont énoncées en entier dans la section suivante.

Cette temporisation n’est pas encore appliquée à l’affichage, et le dire vaut mieux que de laisser croire à un lissage qui n’existe pas. Aujourd’hui, une ligne présente le verdict le plus récent de chacune de ses vérifications : une seule mesure en échec peut donc la faire passer au rouge, et une seule mesure conforme peut l’en faire revenir. Les seuils ci-dessus sont déclarés à l’avance et publiés ici pour être vérifiables le jour où ils gouverneront l’affichage. L’écart va dans le sens de la sensibilité, pas de la flatterie : l’affichage actuel peut montrer une panne qu’une temporisation aurait absorbée, il ne peut pas cacher une panne qu’elle aurait retenue.

Quand un changement d’état sera publié, l’horodatage de début sera celui de la première vérification en échec, pas de la troisième. Nous ne repousserons pas le début d’une panne pour la raccourcir. Aucun instant de changement d’état n’est publié aujourd’hui.

Point de santé applicatif (60 s)

Chaque capacité applicative expose un point de santé qui répond par un état structuré de ses dépendances. Il permet de distinguer « la page se charge » de « la page se charge mais la fonction derrière ne marche pas ».

Le contenu de cette réponse n’est jamais publié. Ni nom de service interne, ni message d’erreur, ni code de diagnostic, ni latence de base de données. Ce sont des renseignements sans valeur pour un visiteur et de valeur certaine pour un attaquant. Seul l’état public consolidé de la ligne est affiché.

Flux d’état des fournisseurs (5 min)

Nous lisons la page ou le flux d’état public de chaque fournisseur toutes les 5 minutes et nous transposons sa sévérité déclarée vers nos cinq états. Un document plus vieux que 30 minutes ne produit aucun verdict plutôt que de reconduire sa dernière valeur : un flux figé n’est pas un fournisseur opérationnel, c’est un flux illisible.

Le décalage est réel et nous ne le corrigeons pas : à nos 5 minutes de sondage s’ajoute le délai que met le fournisseur à publier, souvent de 5 à 30 minutes, parfois plusieurs heures, parfois jamais pour un incident partiel. Ce que nous affichons dans la colonne du fournisseur est donc ce que le fournisseur disait au moment de la lecture, pas ce qui se passait réellement.

Nous prenons un instantané à chaque lecture. Si un fournisseur modifie ou supprime après coup son propre historique, notre instantané reste tel quel.

Parcours d’authentification synthétique (15 min) : pas en service

Ce parcours ne s’exécute pas aujourd’hui. Il demande un compte témoin dédié, muni des droits les plus restreints possibles, et ce compte n’existe pas encore. Tant qu’il n’existe pas, rien n’est mesuré sur les lignes qu’il gouverne, et cette page ne publie ni état conclu ni pourcentage pour elles. Ce paragraphe décrit donc l’instrument tel qu’il est déclaré, pas une mesure en cours.

Tel que déclaré : un compte d’essai dédié, créé pour cette seule fin, exécute toutes les 15 minutes la séquence complète en quatre étapes : chargement de la page de connexion, envoi des identifiants, résolution du deuxième facteur, arrivée sur une page authentifiée. Budget total de 25 s pour la séquence, avec un abandon ferme à 30 s. L’échec de n’importe quelle étape fait échouer le parcours.

Ce compte n’appartiendra à aucun client, ne contiendra aucune donnée client et n’aura accès à aucune donnée client.

Conséquence directe à ne pas perdre de vue, le jour où il tournera : la ligne « Connexion et MFA » aura une résolution de 15 minutes. Une interruption de connexion de 10 minutes peut passer entièrement entre deux exécutions et ne laisser aucune trace. Deux exécutions en échec consécutives étant exigées pour publier un changement, soit 30 minutes à cette cadence, une panne de connexion peut n’apparaître sur cette page que 30 minutes après son début.

Résolution DNS (60 min)

Toutes les heures, par DNS sur HTTPS : résolution de l’enregistrement A du domaine surveillé et des enregistrements MX du courriel, avec vérification que les réponses correspondent aux enregistrements attendus. Abandon à 10 s.

Une seule observation suffit à publier un changement d’état : un enregistrement DNS n’est pas un signal instable, et exiger une seconde mesure coûterait une heure entière sans rien prouver. Une absence de résolution est une panne qui a lieu maintenant, et elle est traitée comme telle.

Expiration TLS (60 min) : pas mesurable, et l’état publié le dit

Cette vérification ne peut pas répondre à la question qu’on lui pose, et enregistre « indéterminé » à chaque exécution. Rien à l’intérieur d’un Cloudflare Worker n’observe le certificat d’une requête sortante : une réponse fetch() n’expose aucun certificat de pair, et la seule paire de dates que le runtime documente décrit le certificat du client entrant sur une connexion mutuellement authentifiée, ce qui n’a rien à voir. Il n’existe donc aujourd’hui aucune mesure des jours restants sur un certificat ni de l’intégrité d’une chaîne.

Enregistrer une réussite parce qu’une connexion s’est ouverte serait publier une mesure d’expiration que personne n’a prise. Chaque exécution enregistre donc « indéterminé » avec sa raison, honnêtement et par construction. Une poignée de main qui échoue enregistre aussi « indéterminé » plutôt que « panne », pour la même discipline dans l’autre sens : la plateforme rend une seule erreur indifférenciée pour un échec DNS, un refus de connexion et un rejet de certificat, alors cette sonde ne peut pas conclure que c’est le certificat qui a lâché.

Ce que cela ne coûte pas : un certificat réellement expiré est déjà une panne que la vérification HTTP de 60 secondes rapporte à 60 secondes de résolution, parce que la plateforme refuse la poignée de main. Ce que cela coûte : l’avertissement à l’avance. Le silence de cet instrument est écarté du calcul des lignes qu’il accompagne, parce que « personne n’a mesuré le certificat » n’est pas une réponse à « est-ce que le site répond ». C’est la seule vérification dans ce cas, et elle est la seule parce qu’elle est la seule à poser une question sur un risque futur plutôt que sur le présent.

Tâches planifiées (battements quotidiens) : pas en service

Aucun battement ne peut arriver aujourd’hui, parce que la porte n’est pas ouverte. La route de réception est écrite et livrée dans le Worker, et elle n’est pas publiée : l’atteindre demande un domaine que le jeton de déploiement n’a pas le droit de créer. « Aucun battement n’est jamais arrivé » et « aucun battement ne peut arriver » sont deux aveux différents, et c’est le second qui est vrai. La ligne « Tâches planifiées » ne mesure donc rien.

Tel que déclaré : trois traitements quotidiens émettent un battement à la fin de leur exécution. La mesure porte sur l’absence de battement, pas sur une requête sortante, et elle est évaluée toutes les heures.

Le délai est compté depuis le dernier battement reçu, jamais depuis un horaire : 24 heures d’intervalle attendu, plus 2 heures de tolérance. Au-delà, la ligne passe en panne sur une seule observation, parce qu’un traitement quotidien manquant n’est pas du bruit. Cette tolérance est délibérément large, et ce qu’elle change mérite d’être dit plutôt que découvert : cet instrument détecte un traitement qui n’a pas tourné, il ne détecte pas un traitement qui a tourné en retard. Un instrument plus serré publierait des pannes qui n’en sont pas tant que la précision de l’ordonnanceur n’est pas mesurée, et une fausse panne coûte plus cher ici qu’une heure d’ignorance sur un traitement quotidien. Les identifiants, horaires exacts et noms de ces traitements ne sont pas publiés.

Une tâche planifiée en échec n’affecte aucune surface interactive. Les deux lignes sont indépendantes et le resteront.

Seuils de publication : deux règles, pas une

Combien d’observations non conformes faut-il avant qu’un changement d’état soit publié ? La réponse dépend du type de vérification. Il n’existe pas de règle unique, et cette page n’en annonce plus une.

Les deux règles, énoncées :

• Les vérifications rapides, à 60 s de cadence (HTTP et points de santé), exigent trois échecs consécutifs avant tout changement d’état publié. À cette cadence, cela fait trois minutes d’accord entre trois mesures : assez pour qu’un seul paquet perdu ne fasse pas rougir une ligne, assez peu pour qu’une vraie panne soit affichée avant qu’un client ait fini d’écrire le courriel qui la signale.
• Les vérifications lentes (TLS, DNS, battements de tâches planifiées) changent sur une seule observation. Ce ne sont pas des signaux instables. Une date d’expiration de certificat ne clignote pas, un enregistrement DNS non plus, et un traitement quotidien manquant n’est pas du bruit. Attendre une seconde observation coûterait 60 minutes et ne prouverait rien.
• Les flux de fournisseurs et le parcours synthétique se situent entre les deux, à deux observations, soit 10 et 30 minutes respectivement.

Les durées de la quatrième et de la sixième colonne ne sont pas saisies à la main : elles valent la cadence multipliée par le nombre de mesures exigées. C’est la seule façon honnête de les énoncer.

Les trois instruments qui ne sont pas en service figurent dans ce tableau parce que leurs seuils sont déclarés à l’avance. Tant qu’ils ne mesurent rien, ils ne publient aucun changement d’état, et aucune de ces durées ne s’écoule.

Le nombre de réussites exigé pour publier un retour à « opérationnel » est égal au nombre d’échecs exigé pour publier une panne. Une paire asymétrique poserait la question de savoir dans quel sens Webryk se montre généreux ; la symétrie répond : dans aucun.

Les cinq états

L’état n’est jamais signalé par la couleur seule. Chaque état porte une forme distincte et une étiquette en toutes lettres, y compris à l’intérieur de la barre des 90 jours, et reste lisible en niveaux de gris.

Une intervention non annoncée, ou annoncée à moins de 48 heures d’avis, n’est pas une maintenance. Elle est comptée comme une panne. Sinon, il suffirait d’annoncer tardivement pour effacer une interruption.

L’état global affiché en haut de page reflète uniquement les capacités Webryk. Les lignes de fournisseurs tiers ne le modifient jamais, ni vers le haut ni vers le bas.

Résolution : ce que l’intervalle ne peut pas voir

Une interruption plus courte que l’intervalle de vérification peut passer entièrement entre deux mesures et ne laisser absolument aucune trace. La plus courte panne que cet instrument puisse voir dure 60 secondes, parce que c’est la cadence la plus rapide qu’il exécute.

Concrètement : une panne de 40 secondes sur une surface vérifiée toutes les 60 secondes est probablement invisible ici. Une panne de connexion de 10 minutes sur un parcours exécuté toutes les 15 minutes est probablement invisible ici. Cela ne veut pas dire qu’elle n’a pas eu lieu, cela veut dire que ce dispositif ne la voit pas.

Les redémarrages, les basculements rapides et la plupart des erreurs intermittentes qui touchent une fraction des requêtes tombent dans cet angle mort. Une sonde qui échantillonne ne mesure pas un taux d’erreur : elle mesure des instants. Si 2 % des requêtes échouent en continu, il y a environ 2 % de chances que la sonde tombe dessus à un instant donné, et la ligne restera très probablement « opérationnel ».

Ce n’est pas un défaut à corriger dans une prochaine version, c’est la limite structurelle de la méthode. Vous devez en tenir compte pour interpréter tout ce qui est affiché.

Périodes indéterminées

Un intervalle est marqué « indéterminé » quand nous n’avons pas de verdict auquel se fier : instrument pas encore en service, exécution du Worker en échec, écriture dans l’historique en échec, ou flux d’un fournisseur injoignable ou illisible.

Toute période antérieure au début de la surveillance est indéterminée pour la même raison : personne ne regardait.

La surveillance a commencé le 3 août 2026.

Le temps non mesuré est toujours indéterminé. Il n’y a ni tolérance, ni marge, ni paramètre pour l’atténuer : une mesure parle pour sa propre cadence, à partir de l’instant où elle a été prise, et pas une milliseconde de plus dans un sens ou dans l’autre. Peindre un trou de mesure avec le verdict de la mesure suivante serait un remplissage rétroactif, et c’est interdit.

Arithmétique appliquée :

• Les minutes indéterminées sont exclues du numérateur et du dénominateur. Elles ne comptent ni comme disponibles, ni comme indisponibles.
• Le total des minutes indéterminées de la fenêtre est publié à côté du pourcentage. Il n’est pas caché dans une note de bas de page.
• Si les minutes indéterminées dépassent 5 % de la fenêtre, le pourcentage n’est pas publié du tout et la raison est affichée à sa place, avec la part mesurée : « Pourcentage retenu - P % de la fenêtre sans mesure, au dessus du plafond de 5 % ». P est la part réelle de temps indéterminé, tronquée à la deuxième décimale comme tout autre pourcentage de cette page. Seuls les décomptes bruts restent affichés.

Ce plafond de 5 % porte sur la fenêtre entière. Il ne se confond pas avec le plancher de couverture quotidienne de 90 %, qui décide seulement si une journée compte pour la barre des 30 jours. Trente journées franchissant tout juste 90 % de couverture passeraient le seuil quotidien alors qu’un dixième de la fenêtre assemblée n’aurait jamais été observé, et un pourcentage calculé là-dessus serait un pourcentage sur une période que Webryk n’a pas regardée.

Traiter l’indéterminé comme du temps disponible serait le choix flatteur. C’est aussi le choix qui rend un chiffre invérifiable.

Disponibilité : deux chiffres, pas un

Fenêtre glissante de 90 jours, granularité à la minute. Deux figures sont publiées côte à côte :

• Disponibilité incluant les maintenances planifiées. Toute minute pendant laquelle la capacité n’a pas rendu le service attendu compte comme indisponible, y compris les maintenances annoncées.
• Disponibilité hors maintenances planifiées. Les minutes situées dans une fenêtre annoncée au moins 48 heures à l’avance sont retirées du dénominateur.

Ce que chaque état devient dans le calcul, sans exception ni option :

Le temps dégradé est exclu du numérateur. Dit en toutes lettres, parce qu’une exclusion non documentée est un défaut de la même famille qu’un chiffre faux : une capacité qui répond hors seuils n’est pas une capacité disponible, et ces minutes ne sont donc pas comptées comme du temps disponible. Elles restent au dénominateur : elles ne sont pas effacées, elles sont comptées comme du temps où le service n’a pas été rendu tel qu’attendu. Il n’existe aucun réglage pour en décider autrement, parce que le seul effet d’un tel réglage serait d’embellir un mauvais mois.

Ne publier que le second chiffre serait trompeur, pour deux raisons. La première : la personne qui n’a pas pu se connecter à 2 h du matin un dimanche n’a pas pu se connecter, que ce soit annoncé ou non ; l’annonce change la courtoisie, pas la disponibilité. La seconde : si la maintenance sort du dénominateur, il devient possible d’améliorer son chiffre en planifiant davantage d’interruptions. Toute mesure qu’on peut améliorer sans améliorer le service cesse d’être une mesure.

Ne publier que le premier serait injuste envers une maintenance faite correctement. D’où les deux.

Les pourcentages sont tronqués vers zéro à la deuxième décimale, jamais arrondis. Deux exemples travaillés : une disponibilité mesurée à 99,994 % s’affiche 99,99 % ; une disponibilité mesurée à 99,999 % s’affiche elle aussi 99,99 %, et jamais 100,00 %. L’arrondi est la seule opération arithmétique de cette page capable de faire paraître une mesure meilleure qu’elle ne l’a été, alors elle n’est disponible nulle part. « 100 % » ne s’affiche jamais s’il y a eu la moindre interruption enregistrée dans la fenêtre.

Pourquoi le pourcentage est retenu pendant 30 jours

Tant qu’il n’existe pas 30 jours de données réelles, l’emplacement du pourcentage affiche « Collecte en cours - N jours sur 30 », où N est le nombre de jours qualifiés. Aucun pourcentage n’est publié avant.

La raison est arithmétique. Une même interruption de 10 minutes vaut 0,23 % sur une fenêtre de 3 jours (4 320 minutes) et 0,007 % sur une fenêtre de 90 jours (129 600 minutes). Le même incident produirait donc « 99,76 % » ou « 99,99 % » selon la seule longueur de la fenêtre. Un pourcentage calculé sur quelques jours mesure la fenêtre, pas le service.

Il y a aussi un biais de départ : une fenêtre courte et récente est très probablement vierge, ce qui produit un chiffre magnifique qui ne dit rien. Publier « 100 % » après quatre jours serait vrai au sens strict et malhonnête au sens utile.

Les deux retenues sont évaluées dans cet ordre : d’abord les 30 jours qualifiés, ensuite le plafond de 5 % de temps indéterminé décrit plus haut. L’ordre compte. Une fenêtre qui en est à sa première semaine affiche « Collecte en cours », pas « Pourcentage retenu ».

Le compteur de jours qualifiés, lui, est visible dès la première journée mesurée. Il n’y a rien à cacher dans le fait de commencer.

Avant cela, il n’y a pas de compteur, et c’est délibéré. « Collecte en cours - 0 jours sur 30 » affirmerait qu’une collecte est en cours, ce qui est une affirmation sur un système que personne n’a vu tourner. Tant qu’aucune sonde n’a rendu de verdict, l’emplacement dit que rien n’a été mesuré, et il le dit sans chiffre. Une ligne dont l’instrument n’est pas en service n’affiche pas ce compteur non plus, jamais : sur elle, le décompte resterait à zéro pour toujours, et un chiffre qui ne peut pas avancer est une promesse que personne ne tient.

Fournisseurs tiers : deux signaux indépendants

Chaque ligne de fournisseur porte deux valeurs qui ne sont jamais fusionnées :

• Le fournisseur déclare : ce que sa page d’état publique affichait à notre dernière lecture, au plus 5 minutes plus tôt.
• Webryk observe : ce que nos propres sondes constatent sur le point d’accès de ce fournisseur que Webryk utilise réellement.

Ces deux signaux divergent, dans les deux sens. Un fournisseur peut se déclarer opérationnel alors que nous constatons des échecs, parce que la panne est régionale, partielle, limitée à une API précise, ou simplement pas encore publiée. Il peut aussi se déclarer en incident alors que tout fonctionne pour nous, parce que l’incident touche une région ou un produit que nous n’utilisons pas.

Quand les deux signaux divergent, la ligne est marquée « signaux divergents » et les deux valeurs restent affichées. Nous ne choisissons pas la version qui nous arrange, et nous n’écrasons pas la déclaration du fournisseur par notre observation. La divergence est elle-même l’information la plus utile de la ligne.

Nous n’avons aucun accès privilégié à l’infrastructure de ces fournisseurs. Notre observation vaut ce que vaut une mesure en boîte noire faite depuis l’extérieur.

Incidents

L’ouverture automatique n’est pas encore en service. Aucun composant en production n’ouvre, ne met à jour ni ne referme un incident aujourd’hui. Tout incident publié d’ici là est écrit par une personne et publié par une reconstruction du site. Les règles ci-dessous sont celles qui s’appliqueront, et elles sont écrites ici à l’avance pour qu’elles soient vérifiables de l’extérieur le jour où elles s’appliqueront.

L’ouverture d’un incident sera automatique quand une panne est confirmée, c’est-à-dire quand le nombre d’observations en échec exigé par le type de vérification a été atteint. Le système publiera alors une seule phrase pré-rédigée, identique en français et en anglais, qui ne dit que ce qui est constaté.

Tout ce qui suit cette première phrase est écrit par une personne. Aucune mise à jour d’incident n’est générée automatiquement.

Un incident se refermera automatiquement après une reprise soutenue. Cette durée n’est pas la même partout : elle vaut la cadence de la vérification multipliée par le nombre de mesures conformes exigées, soit 3 minutes pour les vérifications à 60 s, 10 minutes pour les flux de fournisseurs, 30 minutes pour le parcours de connexion, et 60 minutes pour TLS, DNS et les battements. Un chiffre unique annoncé pour les sept types serait faux pour six d’entre eux. Un incident ne peut de toute façon pas se refermer moins de 5 minutes après son ouverture, pour qu’un service instable ne produise pas une série de courts incidents qui masquerait la gravité de l’heure écoulée.

Une suite de périodes indéterminées n’ouvre jamais d’incident public. Ne pas voir n’est pas la même chose que constater une panne, et publier l’un à la place de l’autre serait une invention. Après cinq évaluations indéterminées consécutives, une alerte interne part vers l’exploitation.

La fermeture automatique ferme l’état, pas le dossier : les analyses post-incident sont toujours écrites par une personne et publiées séparément.

Les horodatages d’un incident sont ceux des mesures, pas ceux de la rédaction.

L’infrastructure de cette page

Cette page est délibérément construite sur une pile qui ne recoupe pas celle des services qu’elle surveille.

• Site statique compilé à l’avance, servi par Cloudflare Pages.
• Sondes exécutées dans un Cloudflare Worker sur tâche planifiée.
• Historique conservé dans Cloudflare D1.

Elle n’utilise ni Vercel, ni Supabase, ni Resend, ni aucun composant de la plateforme applicative Webryk. Aucun appel à la base de données du portail, aucune authentification, aucune API applicative.

La panne précise qu’elle est conçue pour survivre : une indisponibilité totale de Vercel, de Supabase ou de Resend rend des services Webryk inutilisables et laisse cette page en ligne, à jour, et capable de dire que ces services sont tombés. C’est exactement le moment où une page d’état sert à quelque chose, et c’est exactement le moment où une page d’état hébergée sur la même plateforme que le produit disparaît avec lui.

Deux dépendances résiduelles, énoncées franchement :

1. Une panne globale de Cloudflare emporte cette page avec elle. Il n’y a pas de second hébergeur.
2. status.webryk.ca partage la zone DNS de webryk.ca. Une défaillance au niveau du registraire ou de la zone touche donc les deux en même temps.

Nous ne prétendons pas être indépendants de tout. Nous sommes indépendants de ce que nous mesurons.

Ce que cette page ne mesure pas

À lire avant de conclure quoi que ce soit d’une ligne opérationnelle.

• La livraison réelle des courriels. Nous vérifions la joignabilité de l’API d’envoi, la résolution des enregistrements MX et les flux d’état des fournisseurs. Nous n’envoyons pas de message de test de bout en bout vers une boîte de réception tierce à chaque cycle. Un courriel peut donc partir correctement et finir en indésirable, ou être retenu par le destinataire, sans que rien n’apparaisse ici.
• Les paiements réels. Nous vérifions la joignabilité du chemin de paiement et l’état déclaré par le fournisseur. Nous n’exécutons aucune transaction de test. Un refus lié à une banque émettrice ou à une règle antifraude ne se voit pas ici.
• Votre expérience depuis votre réseau. Voir plus haut. C’est la limite la plus fréquemment mal comprise.
• La performance perçue. Nous enregistrons un temps de réponse serveur, pas un temps de rendu dans un navigateur, pas un parcours utilisateur complet, pas une mesure terrain.
• L’exactitude des données. Une application qui répond vite et affiche des données fausses est « opérationnelle » au sens de cette page.
• La posture de sécurité. Une page d’état n’est pas un tableau de bord de sécurité.
• Les systèmes appartenant aux clients. Webryk surveille aussi des systèmes qui ne lui appartiennent pas. Ils ne sont pas publiés ici, parce que leur état appartient à leur propriétaire, pas à nous. L’inventaire publié couvre l’intégralité des capacités exploitées par Webryk : aucune capacité Webryk n’est retirée de cette page parce qu’elle se comporte mal.

Ce que ces chiffres ne sont pas

Ce sont des mesures observées par des sondes automatisées. Ce ne sont ni un engagement de niveau de service, ni une garantie, ni une clause contractuelle, ni une promesse sur l’avenir.

Cette page décrit ce qui s’est passé. Elle ne décrit pas ce qui est promis. Les engagements contractuels, quand il en existe, figurent dans le contrat signé et sont indépendants de ce qui est affiché ici : rien sur cette page ne les crée, ne les élargit et ne les restreint.

Nous le disons franchement plutôt que défensivement, parce que c’est la seule lecture honnête d’une mesure en boîte noire faite par la partie mesurée.

Conservation et corrections

Ce qui est conservé, et pour combien de temps :

La fenêtre publiée est de 90 jours ; la conservation brute est de 14 jours. Ce ne sont pas deux versions du même chiffre. Deux semaines de mesures à pleine résolution suffisent à l’analyse d’un incident, et au-delà l’espace coûterait six fois plus pour une valeur d’enquête qui s’effondre. Ce qui alimente la fenêtre de 90 jours après la purge, ce sont les résumés quotidiens, qui ne sont jamais supprimés et dont chaque journée scellée est protégée en écriture par la base elle-même.

Une conséquence à énoncer plutôt qu’à laisser découvrir : une journée plus ancienne que l’horizon de 14 jours ne peut plus être attestée à partir des mesures brutes, alors elle ne peut pas être comptée comme journée qualifiée par cette voie. Un pourcentage que personne ne peut étayer n’est pas publié.

L’historique n’est pas réécrit. Aucune donnée n’est ajoutée rétroactivement pour combler une période indéterminée, ni pour combler une période antérieure au début de la surveillance.

Si un chiffre publié se révèle faux, la correction est ajoutée et datée, et la valeur d’origine reste visible avec la mention de ce qui a changé. Une correction silencieuse serait indiscernable d’une falsification.

Pour contester une mesure, écrivez à contact@webryk.ca avec : l’horodatage en UTC, la capacité concernée, ce que vous avez observé, et le réseau depuis lequel vous étiez. Si notre relevé est erroné, nous le disons sur cette page.

La correction que nous n’avons pas faite : GitHub, le 3 août 2026

Le 3 août 2026, sept vérifications ont été enregistrées comme « panne » pour la ligne GitHub. GitHub n’était pas en panne. Ces sept mesures sont fausses.

La cause : la vérification à 60 secondes visait api.github.com, un point d’accès dont le quota est de 60 requêtes par heure et par adresse IP source, et les Workers Cloudflare sortent par un ensemble d’adresses partagé et tournant. La sonde a donc dépensé un quota déjà entamé par des inconnus, a reçu une réponse HTTP 403 de limitation de débit, et l’a classée comme un échec du service. Au même moment, github.com répondait 200 depuis la même machine. La règle qui devait reconnaître une limitation de débit n’a pas fonctionné, parce qu’elle exigeait un en-tête que GitHub n’envoie pas dans ce cas. La cible de cette vérification est maintenant github.com.

Les sept lignes restent en place, telles qu’elles ont été écrites. Nous ne corrigeons pas, ne reclassons pas et n’effaçons pas une mesure enregistrée en production, y compris quand nous sommes certains que sa conclusion est fausse. Corriger l’état en « indéterminé » aurait été défendable ; supprimer les lignes ne l’aurait pas été. Les deux options ont été écartées pour ce qu’elles auraient établi : la première fois qu’on touche à l’historique pour qu’une barre paraisse mieux, l’immuabilité du relevé cesse d’être une propriété et devient une préférence.

Ce que cela coûte, sans atténuation : la ligne GitHub porte un segment rouge visiblement faux pour le 3 août 2026, et l’arithmétique de disponibilité de cette ligne compte sept vérifications d’indisponibilité qui n’ont pas eu lieu. La barre de cette journée est fausse et le restera jusqu’à ce qu’elle sorte de la fenêtre de 90 jours. Ces sept lignes n’atteindront aucun pourcentage publié : le 3 août 2026 est le premier jour d’un seuil de 30 jours, et elles quittent la fenêtre avant qu’un chiffre puisse être publié pour cette ligne.

La décision et ses raisons sont consignées dans la décision d’architecture 0004, « Le relevé n’est pas modifié, même quand nous sommes certains qu’il est faux » (docs/adr/0004-the-record-is-not-edited.md).