Fatigue d'alerte : 82 e-mails en un jour de mon moniteur de sécurité

Combien d’alertes un moniteur de sécurité tenu par une seule personne devrait-il envoyer ? D’après mes chiffres, environ un e-mail par jour, plus le rare qui me demande d’agir. Le 1er novembre, entre minuit et 13:32 heure du Pacifique, mon moniteur a remis 74 e-mails au service d’envoi : 55 pour des blocages déjà effectués, 16 alertes critiques, deux alertes horaires de volume et une provenant du scanner de mon Mac.¹² Ma lecture, cet après-midi-là, était que chacun décrivait un balayage de routine que l’edge avait déjà arrêté ;³ pour les rafales critiques, la section 6 montre que cette lecture était trop généreuse. La solution a été une politique, pas un seuil : un récapitulatif quotidien qui sert aussi de signal de vie, les blocages envoyés sur le chat plutôt que par e-mail, une alerte critique intégrée au récapitulatif quand l’edge l’a déjà traitée, et le sort inscrit sur chaque alerte critique du cloud. Le lendemain, un scanner a déclenché quatre alertes critiques en moins de six minutes sur mes sites, et mon moniteur n’a envoyé aucun e-mail à ce sujet.⁴ La journée a tout de même produit 19 e-mails, pas un seul, et la raison en est la partie la plus utile de l’histoire.⁵

Je suis le seul lecteur du courrier de mon moniteur. Quand la boîte de réception affichait 74, je me suis demandé s’il s’agissait de routine ou de menaces réelles, et la réponse honnête était que le moniteur ne pouvait pas me le dire à travers ses objets, parce que chaque objet disait la même chose à un volume différent.¹ Un moniteur dont l’unique lecteur cesse de le lire a cessé de surveiller, quoi que ses détecteurs attrapent encore. Voici le décompte, la politique qui l’a remplacé, un cas d’essai, et les trois endroits où la version propre de l’histoire se fissure.

En bref

• 74 e-mails à 13:32, 82 à minuit. Mon propre tableau et le décompte tiré des journaux s’accordent sur 74 avant ma plainte (55 par blocage, 16 critiques, deux horaires, un local) ; l’ensemble du 1er novembre a totalisé 81 e-mails journalisés plus un récapitulatif envoyé à la main.¹²⁵
• 22 des 74 ne sont pas prouvés. Ils venaient d’un code qui journalisait « sent » (envoyé) sans vérifier la réponse du service d’envoi ; le journal prouve donc qu’une remise a été tentée, pas qu’un message est arrivé.²⁶
• La littérature avait déjà la règle. Le livre SRE de Google admet trois sorties (alertes, tickets et journalisation), dit « Every page should be actionable » (chaque page doit appeler une action) et qualifie les alertes par e-mail d’« alert spam » ; l’alerte de The Joint Commission (l’organisme américain d’accréditation des hôpitaux) cite une estimation selon laquelle « between 85 and 99 percent of alarm signals do not require clinical intervention » (85 à 99 % des signaux d’alarme ne nécessitent aucune intervention clinique).⁷⁸⁹¹⁰
• Le cas d’essai a fonctionné. Le 2 novembre, une seule adresse d’un hébergeur néerlandais a déclenché quatre alertes critiques en 5 minutes 51 secondes sur mes sites ; le moniteur l’a bloquée une fois, a publié le blocage sur le chat, a intégré chaque alerte critique au récapitulatif et n’a envoyé aucun e-mail.⁴¹¹¹²
• Le lendemain a tout de même envoyé 19 e-mails, pas un. Quatorze étaient des alertes critiques de rafale WAF dans lesquelles certains événements n’avaient ni blocage ni challenge enregistré, et leurs objets disaient « WAF blocks » (blocages WAF) même quand l’edge n’avait bloqué aucun des événements (deux fois ce jour-là ; la veille au soir, l’un disait « 104 WAF blocks » alors que l’edge n’avait rien bloqué ni soumis à un challenge) ; ma première reformulation, le jour même du décompte, mélangeait encore deux comptages sur une ligne, et la relecture de cet article l’a repéré.⁵¹³¹⁴
• Deux signaux étaient faux. Une vérification de signature de code sur mon Mac a pris le propre démon Spotlight d’Apple pour un mineur de cryptomonnaie non signé, et le « RUNS SHORT 162/207 » (exécutions manquantes) du récapitulatif s’est révélé être en partie la veille, en partie une cadence réelle plus lente et en partie, d’après la chronologie, trois exécutions tuées par le watchdog.¹⁵¹⁶¹⁷
• Ce qui a changé : un récapitulatif par jour porte le signal de vie, chaque blocage et le sort de chaque alerte critique du cloud, tandis que seules une alerte critique qu’aucune des deux intégrations ne couvre, l’alerte horaire de volume et le scanner local envoient encore un e-mail immédiat ; les 82 e-mails du 1er novembre sont devenus 19 le 2 novembre.¹⁸⁵

1. La boîte de réception du 1er novembre

À 13:32 heure du Pacifique le 1er novembre, j’ai écrit à la session d’agent qui gère mon infrastructure : les e-mails du moniteur inondaient ma boîte ; y avait-il quelque chose à changer, et s’agissait-il de routine ou de menaces réelles ?¹ Le tableau que j’ai tenu cet après-midi-là comptait 74 e-mails depuis minuit par expéditeur : 55 notifications par blocage, 16 alertes critiques, deux alertes horaires de volume et une alerte critique du scanner de mon Mac.¹

Le décompte repose sur une règle, la voici donc avant les chiffres. Un e-mail, dans cet article, est une ligne du journal du moniteur qui enregistre une remise au service d’envoi. Un script a parcouru les six fichiers journaux du 31 octobre au 2 novembre et a classé chacune de ces lignes par flux et par issue.⁵ Arrêté à 13:32, le script concorde avec mon tableau flux par flux : 55, 16, deux et un, soit 74.² La journée locale entière, jusqu’à minuit, a totalisé 81 e-mails journalisés (55 par blocage, 22 critiques, trois horaires, un local), plus un récapitulatif envoyé à la main à 13:48, qui n’a pas de ligne d’envoi dans le journal du moniteur, soit 82.⁵¹

Deux détails comptent dans cette concordance. Mon tableau indiquait pour les alertes critiques « 9 before the fold went live at 00:30 PT; the 7 after » (9 avant la mise en service de l’intégration à 00:30 PT, 7 après) ; le journal compte 11 lignes critiques « sent » avant 00:30 et cinq après, et la première alerte critique intégrée à une notification de blocage apparaît à 00:54:43, après l’entrée en vigueur du changement d’intégration à 00:46 PDT, et non à 00:30 comme l’indiquait mon tableau.²¹⁸ Les totaux concordent ; la répartition que j’avais notée à la main était fausse de deux. Le second détail pèse davantage. Sur les 74, 22 (10 par blocage, 11 critiques, un horaire) venaient d’expéditeurs qui jetaient la réponse du service d’envoi puis journalisaient « sent » quoi qu’il revienne.²⁶ Un correctif à 01:04 PDT ce matin-là, avant le recul des horloges, a fait journaliser par les expéditeurs de la moitié cloud le statut HTTP du service, et n’écrire « sent » que sur un 2xx ; l’expéditeur du scanner local écrit une simple ligne « Critical email sent », et seulement quand la requête n’a levé aucune erreur.⁶ Les 22 lignes antérieures prouvent que le moniteur a essayé ; elles ne prouvent pas que le service d’envoi a accepté quoi que ce soit. Mon journal du 31 octobre jugeait que les e-mails cloud « most likely were » (avaient très probablement été) remis, ce qui est une supposition raisonnable, mais reste une supposition.¹⁹

Même un 2xx prouve moins que ne le laisse entendre le mot « sent ». La documentation de Resend définit son événement email.sent comme « Occurs whenever the API request was successful. Resend will attempt to deliver the message to the recipient’s mail server » (se produit chaque fois que la requête API a réussi ; Resend tentera alors de remettre le message au serveur de messagerie du destinataire), et présente la remise comme un événement distinct et ultérieur.²⁰ L’appel d’envoi lui-même répond par un id.²¹ Chaque décompte ci-dessous est un décompte de remises acceptées par le service d’envoi ou, pour les 22 du 1er novembre et les 10 du 31 octobre, soit 32 en tout, de remises tentées par le moniteur.⁵ Aucun n’est un décompte de messages que j’ai lus.

Heure par heure, la journée ressemble à une falaise suivie d’un plateau.

1er novembre, heure locale : e-mails par heure face aux alertes qui ne sont pas devenues des e-mails, avec le changement de politique de 13:50 marqué.²²

La première heure a porté 22 e-mails, tous issus du code non vérifié (10 par blocage, 11 critiques, un horaire).²² Ensuite, les notifications par blocage ont continué au rythme d’une à cinq par heure, parce que l’edge ne cessait de bloquer des scanners et que chaque blocage m’écrivait une lettre. Le dernier e-mail par blocage est parti à 13:25:57 ; la première notification de blocage intégrée au récapitulatif apparaît à 14:20:35.²² Après le changement de 13:50, les e-mails tombent à zéro à deux par heure, tandis que les alertes intégrées et supprimées grimpent jusqu’à 23 par heure.²² Le trafic n’a pas baissé. Les e-mails, si.

La veille est une mauvaise base de comparaison. Mon journal du 1er novembre indique « Yesterday had 10 » (hier, il y en a eu 10), et le script est d’accord, mais le journal du 31 octobre commence à 22:31, le soir où j’ai réarmé le moniteur ; ces 10 e-mails couvrent donc 89 minutes.¹⁵ Selon ma lecture, les 74 mesuraient le détecteur au travail sur une journée complète de bruit de fond d’Internet, pas un changement dans le comportement des scanners.

2. À quoi servaient les alertes

Le moniteur a deux moitiés. La moitié cloud est programmée pour s’exécuter sur mon Mac toutes les cinq minutes et demande à Cloudflare les événements de pare-feu et les comptes de requêtes groupés de chacune de mes zones : quelles adresses ont visé quels chemins, à quelle fréquence, et quelle action l’edge a prise sur chaque événement.¹⁸²³ La propre description de ces données par Cloudflare en donne le bon cadre : « Security Events displays information about requests actioned or flagged by Cloudflare security products, including features such as Browser Integrity Check. » (Security Events affiche des informations sur les requêtes traitées ou signalées par les produits de sécurité de Cloudflare, y compris des fonctionnalités comme Browser Integrity Check.)²⁴ La moitié locale est un scanner qui vérifie le Mac lui-même par paliers toutes les 10 minutes : les processus et leurs signatures de code, les hooks d’agent présents sur la machine, les outils qui masquent des binaires système dans le chemin d’accès, et ainsi de suite.¹²

Ce que la moitié cloud fait de ces données se résume simplement. Elle produit des constats par gravité (critical, high, medium) et par catégorie, et pour un constat critique, elle tente d’agir avant de prévenir qui que ce soit : quand une adresse est à l’origine d’assez d’événements, elle l’ajoute pour sept jours à une liste de blocage à l’échelle du compte, que chaque zone applique à l’edge.¹²⁴ Jusqu’aux changements du 1er novembre, chacune de ces actions produisait aussi un e-mail, tout comme chaque alerte critique qu’une limite de deux heures par site et par catégorie ne supprimait pas, la fin de chaque session et chaque heure de blocages nombreux.¹⁸⁵ Le scanner local produit ses propres constats et envoie lui-même ses alertes critiques par e-mail.²⁵ Les Alerts de Cloudflare existent en deux types, « Monitors that you define yourself, and Platform Notifications » (des Monitors que vous définissez vous-même, et des Platform Notifications) : des requêtes SQL API planifiées et des alertes produit préconfigurées, toutes deux paramétrées dans son tableau de bord.²⁶ Le mien n’est ni l’un ni l’autre : c’est un script sur mon Mac qui lit lui-même les événements de pare-feu, ce qui veut aussi dire que le bruit, c’est à moi de le corriger.

3. Ce que la littérature disait déjà

Rien de ce qui suit n’est nouveau, et c’est bien là le malaise. J’en avais lu l’essentiel et j’ai tout de même construit un moniteur qui envoyait un e-mail par événement.

Trois sorties, et l’e-mail n’en fait pas partie. L’introduction de Site Reliability Engineering de Google (l’ouvrage de référence de Google sur l’exploitation des systèmes de production) affirme « There are three kinds of valid monitoring output » (il existe trois types de sorties de supervision valables) : les alertes, qui « Signify that a human needs to take action immediately » (signifient qu’un humain doit agir immédiatement) ; les tickets, qui « Signify that a human needs to take action, but not immediately. » (signifient qu’un humain doit agir, mais pas immédiatement) ; et la journalisation, où « No one needs to look at this information, but it is recorded for diagnostic or forensic purposes. » (personne n’a besoin de regarder ces informations, mais elles sont enregistrées à des fins de diagnostic ou d’analyse forensique).⁷ La même page est sans détour sur le design que j’avais : « a system that requires a human to read an email and decide whether or not some type of action needs to be taken in response is fundamentally flawed. » (un système qui oblige un humain à lire un e-mail et à décider si une action quelconque s’impose est fondamentalement défaillant).⁷ Classés ainsi, mes 55 e-mails par blocage étaient de la journalisation livrée sous forme d’alertes. L’edge avait agi ; il ne restait rien à faire pour un humain.

Chaque page doit appeler une action. Le chapitre de Rob Ewaschuk sur la supervision, dans le même livre, définit une alerte comme « A notification intended to be read by a human and that is pushed to a system such as a bug or ticket queue, an email alias, or a pager » (une notification destinée à être lue par un humain et poussée vers un système tel qu’une file de bugs ou de tickets, un alias e-mail ou un pager), et sa note sur le type e-mail se lit « Sometimes known as “alert spam,” as they are rarely read or acted on. » (parfois appelées « spam d’alertes », car elles sont rarement lues ou traitées).⁹ Les règles du chapitre pour les pages tiennent en trois lignes : « Every page should be actionable. » « I can only react with a sense of urgency a few times a day before I become fatigued. » « If a page merely merits a robotic response, it shouldn’t be a page. » (Chaque page doit appeler une action ; je ne peux réagir dans l’urgence que quelques fois par jour avant de m’épuiser ; si une page ne mérite qu’une réponse machinale, elle ne devrait pas être une page.)⁸ Ma réponse machinale à un e-mail par blocage était de le supprimer. Le chapitre nomme aussi le coût du bruit : « When pages occur too frequently, employees second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a “real” page that’s masked by the noise. » (Quand les pages sont trop fréquentes, les employés doutent, survolent ou ignorent les alertes entrantes, au point parfois d’ignorer une « vraie » page masquée par le bruit.)²⁷ Et il décrit une équipe qui « spent significant amounts of time triaging the alerts to find the few that were really actionable » (passait énormément de temps à trier les alertes pour trouver les rares qui appelaient vraiment une action), ce qui décrit assez bien mon après-midi du 1er novembre.²⁸

Les symptômes avant les causes, et un test pour une page. L’essai antérieur d’Ewaschuk, qui selon lui a servi de fondation à ce chapitre, condense le test en une phrase : « Pages should be urgent, important, actionable, and real. » (Les pages doivent être urgentes, importantes, actionnables et réelles.)²⁹ Sur les causes, il écrit « Include cause-based information in symptom-based pages or on dashboards, but avoid alerting directly on causes » (incluez les informations sur les causes dans des pages fondées sur les symptômes ou dans des tableaux de bord, mais évitez d’alerter directement sur les causes), sous un intertitre « Cause-based alerts are bad (but sometimes necessary) » (les alertes fondées sur les causes sont mauvaises, mais parfois nécessaires).²⁹ Je lis un blocage de pare-feu comme un fait de niveau cause : un scanner a touché une règle. Le symptôme qui m’importe, c’est un chemin sensible servi ou un site en panne, et selon ma lecture, aucun des 74 ne signalait ni l’un ni l’autre ; les requêtes de ce jour-là sur les chemins sondés ne montraient aucun 2xx sur un chemin sensible.³ L’essai anticipe aussi le récapitulatif : « A daily (or more frequent) report can work too » (un rapport quotidien, ou plus fréquent, peut aussi fonctionner), avec l’avertissement que « without a system of accountability this amounts to less-spammy email alerts » (sans système de responsabilité, cela revient à des alertes e-mail un peu moins envahissantes).³⁰ Son remède est une personne : « make sure the oncall person (or someone else) is designated to triage these every day » (veillez à ce que la personne d’astreinte, ou quelqu’un d’autre, soit désignée pour les trier chaque jour).³⁰ Sur un moniteur tenu par une seule personne, cette personne ne peut être que moi. Le champ d’issue de la section 4 est mon propre mécanisme d’appui, pas le sien : il donne au tri quotidien quelque chose à vérifier, ce qu’il est advenu de chaque alerte critique, mais il ne fait pas le tri.

Précision et rappel. Le chapitre sur l’alerte de The Site Reliability Workbook (le volume pratique qui accompagne le livre SRE) fournit le vocabulaire de ce qui a mal tourné. La précision est « The proportion of events detected that were significant. » (la proportion d’événements détectés qui étaient significatifs). Le rappel est « The proportion of significant events detected. » (la proportion d’événements significatifs détectés).³¹ Je n’ai pas mesuré le rappel de mon moniteur, ce qui exigerait un décompte des événements significatifs qu’il a manqués, et la section 5 en décrit un qu’il a manqué. En tant que flux de courrier, sa précision était proche de zéro : 74 e-mails et, selon ma lecture, aucun message parmi eux ne me demandait de faire quoi que ce soit. Le même chapitre nomme le temps de réinitialisation, « How long alerts fire after an issue is resolved. Long reset times can lead to confusion or to issues being ignored. » (combien de temps les alertes continuent de se déclencher après la résolution d’un problème ; des temps longs peuvent semer la confusion ou faire ignorer des problèmes).³¹ Le temps de réinitialisation est défini pour des alertes qui continuent de se déclencher ; un e-mail par blocage se déclenche une fois puis n’apporte aucune mise à jour de résolution : il ne dit jamais que le scanner est parti.

La version hospitalière du même échec. Le chapitre SRE lui-même pointe hors du logiciel, vers la gestion des alarmes cardiaques, « for an example of alert fatigue in another context. » (comme exemple de fatigue d’alerte dans un autre contexte).²⁸ La Sentinel Event Alert (alerte sur les événements sentinelles) de The Joint Commission consacrée à la sécurité des alarmes des dispositifs médicaux, publiée le 8 avril 2013, chiffre le phénomène : « The number of alarm signals per patient per day can reach several hundred » (le nombre de signaux d’alarme par patient et par jour peut atteindre plusieurs centaines), et « It is estimated that between 85 and 99 percent of alarm signals do not require clinical intervention » (on estime que 85 à 99 % des signaux d’alarme ne nécessitent aucune intervention clinique).¹⁰ L’alerte est rigoureuse d’une manière qui mérite d’être imitée : les 85 à 99 % couvrent les alarmes qui ne demandent aucune intervention, pas seulement les fausses, et l’alerte ne sépare pas les deux. La conséquence qu’elle consigne est celle dans laquelle je m’engageais déjà à moitié : les soignants « become desensitized or immune to the sounds » (deviennent insensibles ou immunisés aux sons), et « may turn down the volume of the alarm, turn it off, or adjust the alarm settings outside the limits that are safe and appropriate for the patient » (peuvent baisser le volume de l’alarme, la couper ou régler ses paramètres hors des limites sûres et appropriées pour le patient).¹⁰ Elle recense 98 événements liés aux alarmes de janvier 2009 à juin 2012, dont 80 « resulted in death » (ont entraîné un décès), et, au-delà des facteurs signalés à sa base de données, désigne la fatigue d’alarme comme « the most common contributing factor. » (le facteur contributif le plus courant).¹⁰ Mes enjeux sont bien moindres. Le mécanisme est le même : une personne qui apprend que les alarmes n’ont pas besoin d’elle l’apprend aussi pour la prochaine vraie.

Le NIST, hier et aujourd’hui. La révision de 2012 du guide de traitement des incidents du NIST, SP 800-61r2, avertissait qu’« it is not uncommon for an organization to receive thousands or even millions of intrusion detection sensor alerts per day. » (il n’est pas rare qu’une organisation reçoive des milliers, voire des millions d’alertes de capteurs de détection d’intrusion par jour).³² La révision d’avril 2025, SP 800-61r3, qui « supersedes SP 800-61r2 » (remplace SP 800-61r2), supprime cette phrase ; la plus proche est une recommandation : « The volume of potentially adverse events to be analyzed is generally quite high, so organizations should rely on technical solutions that filter large event datasets down to a subset that is suitable for human viewing and analysis. » (Le volume d’événements potentiellement indésirables à analyser est généralement élevé ; les organisations devraient donc s’appuyer sur des solutions techniques qui filtrent de grands ensembles d’événements jusqu’à un sous-ensemble adapté à l’examen et à l’analyse humains.)³³ Je prends le filtre comme consigne, et le récapitulatif comme l’un de ces filtres.

Une enquête de fournisseur, présentée comme telle. L’enquête 2023 de Vectra AI, menée par Sapio Research auprès de 2 000 analystes en sécurité, rapporte que « SOC teams receive an average of 4,484 alerts per day, and over two-thirds (67%) of them are ignored. » (les équipes SOC reçoivent en moyenne 4 484 alertes par jour, et plus des deux tiers, 67 %, sont ignorées).³⁴ C’est une enquête d’opinion commandée par un fournisseur, et les 67 % sont ce que les répondants ont déclaré, pas une mesure. Je ne la cite que pour un point : l’échec se transpose aussi vers le bas. Des analystes disent ignorer les deux tiers de 4 484 alertes par jour, et un lecteur seul, sans équipe, a cessé de lire à 74.

4. La refonte, sous forme de règles

Le changement est entré en vigueur à 13:50 le 1er novembre, 18 minutes après mon message, et un second changement à 14:00 a resserré l’une de ses conditions.¹⁸ Je l’ai écrit sous forme de règles, chacune avec sa raison d’être.

Règle 1 : un récapitulatif par jour, et c’est lui le signal de vie. La première exécution du moniteur après 07:00 heure locale envoie un e-mail couvrant la fenêtre écoulée depuis le récapitulatif précédent.¹⁸³⁵ La description du récapitulatif dit elle-même ce que cet e-mail remplace : « One email a day … in place of an email per auto-block and per WAF-handled CRITICAL. » (un e-mail par jour… au lieu d’un e-mail par blocage automatique et par alerte critique traitée par le WAF).³⁵ Il s’ouvre sur l’état des exécutions (exécutions enregistrées, exécutions lancées et terminées, échecs, e-mails critiques envoyés et supprimés), puis viennent les blocages automatiques avec zone, motif et opérateur réseau, chaque alerte critique et ce qu’il en est advenu, les constats par gravité et par catégorie, les chemins sondés et les constats non résolus du scanner local.¹² La raison d’être du récapitulatif, c’est la boîte de réception. La raison de l’envoyer chaque jour figure dans la même description : « The digest is also the heartbeat: it goes out on a quiet day too » (le récapitulatif est aussi le signal de vie, le heartbeat : il part aussi les jours calmes).³⁵ Un flux d’alertes qui ne parle que lorsqu’il se passe quelque chose ne peut pas me faire distinguer une journée calme d’un moniteur mort. Un récapitulatif qui arrive toujours le peut : le silence signifie une panne, pas le calme. Les notes du programme consignent pourquoi j’y tiens : plus tôt en 2026, le moniteur est resté mort pendant des mois, et rien ne l’a remarqué.³⁵

Règle 2 : les blocages vont sur le chat, pas par e-mail. Les notes de conception tiennent en quatre mots : « Per block: Slack only. » (par blocage : Slack uniquement).³ Un blocage, c’est l’edge qui agit en mon nom. Dans les termes du livre SRE, c’est de la journalisation : enregistré, utile plus tard, et rien sur quoi un humain doive agir.⁷ Le chat garde le flux en direct pour les moments où je veux en suivre un, et le récapitulatif garde la trace.

Règle 3 : intégrer une alerte critique quand l’edge l’a déjà traitée. Une alerte critique tente toujours de bloquer d’abord ; ensuite, le moniteur décide si elle mérite un e-mail.³ Deux conditions l’intègrent plutôt au récapitulatif, vérifiées dans cet ordre. La première : l’adresse propre au constat, et chaque adresse qu’il contient éligible au blocage automatique, figure déjà sur la liste de blocage active, si bien que l’edge arrête ces adresses en ce moment même.³¹⁴ Cette vérification n’examine aucune autre adresse et s’exécute avant l’examen de l’échantillon ; une rafale intégrée par elle peut donc encore contenir des événements sans blocage ni challenge enregistré, issus d’adresses sous le seuil de blocage ; cette branche dit que les cibles du répondeur sont bloquées, pas que chaque événement a été atténué. La seconde s’applique à une rafale WAF, une salve d’événements de pare-feu sur une zone : elle n’intègre que si chaque événement de l’échantillon, bot ou non, a un blocage ou un challenge enregistré, et si l’échantillon est complet. « A solved or bypassed challenge, log, allow and skip all count as unmitigated. » (Un challenge résolu ou contourné, log, allow et skip comptent tous comme non atténués.)³ Les définitions de Cloudflare expliquent pourquoi ces quatre jouent contre l’intégration : après un challenge, « If successful, Cloudflare accepts the matched request » (en cas de réussite, Cloudflare accepte la requête concernée), et une action log ne fait que « Records matching requests in the Cloudflare Logs. » (consigner les requêtes correspondantes dans les Cloudflare Logs).³⁶ Un constat de scanner persistant, qui ne compte que les événements que l’edge a bloqués ou soumis à un challenge, est intégré pour cette raison par l’intégration WAF, ou par l’intégration par liste de blocage lorsque son adresse figure déjà sur la liste, comme ce fut le cas pour celui du 2 novembre.³ Tout le reste part immédiatement par e-mail.

Règle 4 : l’issue est inscrite sur le constat. La politique veut que chaque alerte critique de la moitié cloud porte une issue enregistrée : intégrée parce que l’adresse est sur la liste de blocage, intégrée parce que l’edge a bloqué ou soumis à un challenge chaque événement échantillonné, envoyée par e-mail, supprimée (dans la limite d’un e-mail par site et par catégorie toutes les deux heures), ou envoi échoué.³³⁷ L’enregistrement reste en deçà de la politique. Parmi les alertes critiques datées du 1er novembre en UTC, 118 ne portent aucune issue : 117 ont été produites avant l’existence du champ, et une alerte critique cloud, à 14:13 PST, est venue après ; son exécution était l’une des trois de la section 7 qui se sont terminées environ quatre minutes après leur lancement, et elle s’est arrêtée pendant le blocage automatique, avant qu’une issue soit écrite. Les alertes critiques du scanner local n’en portent jamais ; les trois du 2 novembre n’en ont pas.³⁷³⁸ Depuis le 3 novembre, le moniteur inscrit « pending » (en attente) sur une alerte critique avant l’exécution du blocage automatique, de sorte qu’une exécution interrompue en cours de route laisse un état visible au lieu d’un blanc.¹⁴ Le récapitulatif imprime l’issue à côté de chaque alerte critique cloud, sous un intitulé qui le promet : « Every CRITICAL and what became of it » (chaque alerte critique et ce qu’il en est advenu).¹² Le champ d’issue est mon mécanisme, pas celui d’Ewaschuk. Sa condition pour un rapport quotidien est une personne désignée pour le trier chaque jour, et ici cette personne, c’est moi ; le champ donne à ce tri quelque chose à vérifier.³⁰ Avec l’issue sur chaque ligne, le récapitulatif répond à la question que j’ai posée le 1er novembre, routine ou menace réelle, une alerte critique à la fois, même si « emailed » (envoyée) ou « folded » (intégrée) dit où est allée une alerte critique, pas que quoi que ce soit a été résolu.

Règle 5 : l’alerte horaire de volume reste. Les notes, encore : « Hourly volume alert (responder): still immediate, at most once an hour » (alerte horaire de volume du répondeur : toujours immédiate, au plus une fois par heure).³ Un blocage isolé relève de la routine ; une soudaine pile de blocages en une heure est ce que la moitié cloud a de plus proche d’un symptôme, un changement dans ce qu’Internet me fait subir. Elle s’est déclenchée une fois le 2 novembre.⁵

Règle 6 : les alertes critiques du scanner local partent toujours immédiatement. Les notes de conception les gardent immédiates parce qu’elles sont censées être rares.³ Je les garde pour une seconde raison : rien ne s’interpose entre mon Mac et un constat local comme l’edge s’interpose entre mes sites et un scanner. Une liste de blocage peut arrêter une adresse ; rien hors du Mac n’arrête un processus qui tourne dessus. Le coût de cette règle apparaît dans la section 7.

Le jour où les règles sont entrées en vigueur, elles ont réduit le flux de 74 e-mails avant 13:32 à sept journalisés pour le reste de la journée (six alertes critiques et une alerte horaire), plus le récapitulatif envoyé à la main.⁵² La prévision que j’ai écrite cet après-midi-là disait « Under today’s traffic that would have been 0 immediate emails instead of 16. » (Avec le trafic d’aujourd’hui, cela aurait donné 0 e-mail immédiat au lieu de 16.)¹ Elle ne s’est pas vérifiée, et la section 6 explique pourquoi.

5. Le cas d’essai : 2 novembre, de 11:03 à 11:21

Le premier vrai test des règles est arrivé le lendemain matin : une adresse appartenant à un hébergeur néerlandais a lancé un scanner de vulnérabilités sur mon site.¹² Voici ce que le moniteur a écrit, mot pour mot depuis son journal en heure locale du Pacifique, l’adresse remplacée par « [the address] » et les lignes intermédiaires omises.⁴

[2026-11-02 11:03:53] [INFO] New finding [critical]: Request flood from [the address] on blakecrosley.com
[2026-11-02 11:04:02] [RESPOND] [INFO] Block notification: Slack posted, email folded into the daily digest
[2026-11-02 11:04:03] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Request flood from [the address] on blakecrosley.com
[2026-11-02 11:04:04] [INFO] New finding [critical]: Scanner from [the address] on blakecrosley.com
[2026-11-02 11:04:05] [RESPOND] [INFO] Skip: [the address] already has active real block in blakecrosley.com (dedup)
[2026-11-02 11:04:05] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Scanner from [the address] on blakecrosley.com
[2026-11-02 11:09:22] [INFO] New finding [critical]: 726 WAF blocks in 5 minutes
[2026-11-02 11:09:23] [INFO] Critical alert folded into the daily digest (IP on the block ledger): 726 WAF blocks in 5 minutes
[2026-11-02 11:09:44] [INFO] New finding [critical]: Persistent scanner: [the address] blocked 743 times today
[2026-11-02 11:09:47] [RESPOND] [INFO] Block notification: Slack posted, email folded into the daily digest
[2026-11-02 11:09:47] [INFO] Critical alert folded into the daily digest (IP on the block ledger): Persistent scanner: [the address] blocked 743 times today

Minute par minute :

• 11:03:53. Le détecteur de rafales de requêtes produit une alerte critique contre l’adresse. Huit secondes plus tard, à 11:04:01, le répondeur l’ajoute à la liste de blocage, et à 11:04:02 la notification de blocage part sur le chat, son e-mail intégré au récapitulatif.⁴
• 11:04:03. L’alerte critique elle-même est intégrée : l’adresse figure désormais au registre de blocage, l’edge fait donc déjà le travail qu’un e-mail me demanderait de faire.⁴
• 11:04:04. Un second détecteur, la vérification de scanner, produit sa propre alerte critique pour la même adresse. La demande de blocage du répondeur est ignorée comme doublon, et l’alerte critique est intégrée une seconde plus tard.⁴
• 11:09:22. Le détecteur de rafales WAF produit une troisième alerte critique pour la zone. Son auteur figure au registre, et elle est intégrée.⁴¹¹ Seule l’intégration par liste de blocage en décide : huit des événements échantillonnés n’avaient ni blocage ni challenge enregistré, et l’échantillon était plafonné ; l’intégration WAF seule l’aurait donc envoyée par e-mail.¹¹
• 11:09:44. La vérification de scanner persistant, qui compte les événements d’une adresse que l’edge a bloqués ou soumis à un challenge sur l’ensemble de mes zones, produit la quatrième, enregistrée sur un autre de mes sites : 743 événements bloqués ou soumis à un challenge pour l’adresse ce jour-là.¹² Le répondeur inscrit l’adresse une seconde fois sur la liste (un défaut, voir plus bas), publie sur le chat et intègre l’alerte critique à 11:09:47.⁴¹¹
• 11:14:58 et 11:20:40. Deux autres alertes critiques de rafale WAF pour la même zone ; toutes deux sont intégrées de la même façon.¹¹

Quatre alertes critiques en 5 minutes 51 secondes, six à 11:20, toutes enregistrées sur leurs constats comme intégrées parce que l’adresse était bloquée.¹¹ Une adresse bloquée, son entrée de liste écrite deux fois parce que la vérification des doublons fonctionnait alors par site (corrigé le 3 novembre), quatre autres demandes de blocage ignorées comme doublons.⁴¹⁴ E-mails : zéro. Le journal n’enregistre aucun e-mail envoyé entre 11:03 et 11:21 ; la seule alerte critique de cette fenêtre ni intégrée ni envoyée, supprimée à 11:03:13, était une rafale sur un autre site, venant d’une autre adresse.⁴

Le récapitulatif suivant l’a présentée en deux lignes dans le tableau des blocages automatiques (le premier blocage, avec sa zone, son motif et son opérateur réseau, et le nouvel ajout par le scanner persistant) et six lignes dans le tableau de toutes les alertes critiques, chacune marquée « blocked » (bloquée) ou « blocked earlier » (bloquée plus tôt).¹² Selon ma lecture, c’est le bon poids pour un scanner que le moniteur a bloqué huit secondes après son premier constat, huit minutes après le début du balayage : quelques lignes que je peux lire avec mon café, pas une page qui me réveille.⁴

Il y a une chose que le cas d’essai ne montre pas, découverte le 3 novembre. Le même scanner envoyait aussi des soumissions au formulaire de contact de mon site, soumissions auxquelles mon application a répondu 200, soit au plus 31 e-mails à elles seules, et qui font l’objet de l’article compagnon, et la vérification de rafale de formulaire du moniteur n’a produit aucun constat en direct ; rejouée sur des données complètes pour les cinq minutes jusqu’à 11:03:23, la même vérification produit le constat, en gravité high (une ligne du récapitulatif, ni e-mail ni blocage), à partir de 39 soumissions, dont 23 refusées.³⁹ L’exécution en direct avait demandé à Cloudflare une fenêtre se terminant à l’instant de la demande, 37 secondes après le début de l’exécution, avant que les événements les plus récents soient entièrement arrivés : elle a compté 1 914 requêtes de l’adresse dans cette fenêtre, là où la rejouée sur données complètes en compte 2 143.⁴³⁹ Ce retard est mesuré sur l’ensemble des requêtes de l’adresse, pas sur les soumissions de formulaire que compte la vérification ; selon ma lecture, le même retard a maintenu ces soumissions sous le seuil de la vérification en direct. Et chaque exécution regardait exactement cinq minutes en arrière alors que les exécutions démarraient à environ 5,6 à 5,8 minutes d’intervalle, si bien qu’une partie de chaque intervalle n’était jamais balayée.³⁹¹⁷ Le correctif est entré en vigueur le jour même : chaque fenêtre commence désormais là où la précédente s’est terminée et se termine 90 secondes avant l’exécution, sauf si l’enregistrement précédent manque, date de moins d’une minute ou de plus de 15 minutes, comme après une mise en veille du Mac, auquel cas l’exécution revient à un simple regard de cinq minutes en arrière.³⁹ Rejouer la fenêtre du 2 novembre à travers le code modifié donne les mêmes constats ; le changement n’a donc pas perturbé la détection sur une fenêtre fixe. Une rejouée ne peut pas mettre à l’épreuve l’enchaînement des fenêtres ni le retard, qui n’agissent que sur les exécutions en direct ; les exécutions en direct à partir du 3 novembre en sont le test.³⁹

6. Ce qui part encore par e-mail, et pourquoi

Le 2 novembre a été la première journée complète sous les nouvelles règles, et elle a envoyé 19 e-mails, pas un : 14 alertes critiques, une alerte horaire de volume, un récapitulatif et trois du scanner local.⁵ Aucun e-mail par blocage n’est parti ; 108 notifications de blocage ont été intégrées au récapitulatif à la place, 177 alertes critiques ont été intégrées, et 37 autres ont été supprimées par la limite de deux heures, le tout compté par jour local. Les décomptes d’issues plus loin dans cet article suivent la date UTC, d’où l’écart entre ces chiffres.⁵

E-mails par jour local et par flux ; le 31 octobre ne couvre que les 89 minutes suivant le début du journal.⁵

Chaque alerte critique cloud envoyée par e-mail après le changement de 13:50 et jusqu’à la fin du 2 novembre, 20 en tout (six dans le reste du 1er novembre, quatorze le 2 novembre), était une rafale WAF sur resumegeni.com ou blakecrosley.com dans laquelle au moins un événement n’avait ni blocage ni challenge enregistré.¹³ L’intégration WAF a correctement refusé chacune selon sa propre règle : un événement non atténué figurait dans l’échantillon, le moniteur ne pouvait donc pas affirmer que l’edge l’avait traité.³ Dans ces rafales, aucune adresse n’avait assez d’événements pour être éligible au blocage automatique, si bien que l’intégration par liste de blocage n’avait aucune adresse à vérifier.¹³ Le récapitulatif nomme ce groupe de la même façon : « a CRITICAL that was neither blocked nor already handled by the WAF » (une alerte critique ni bloquée ni déjà traitée par le WAF).¹²

Les objets de ces e-mails racontaient une autre histoire, et c’était un défaut. Le résumé de rafale indiquait « N WAF blocks in 5 minutes » (N blocages WAF en 5 minutes), mais N comptait chaque événement de pare-feu non-bot de la fenêtre, quelle que soit l’action prise par l’edge.¹³ Deux exemples tirés des constats, en heure locale :

Le premier e-mail annonçait 104 blocages alors que l’edge n’avait rien bloqué.¹³ Selon ma lecture, un objet qui dit « blocks » à propos d’événements sans blocage enregistré est pire que du bruit : il dit à l’unique lecteur que le système a traité ce qu’il n’a peut-être pas traité. Mon premier correctif, le 3 novembre, le jour même de ces décomptes, était lui-même faux. Il gardait le compte non-bot pour N et comptait bloqués, soumis à un challenge et le reste sur tous les événements, si bien que la salve de 16:51 aurait affiché 104 WAF events in 5 minutes: 0 blocked, 0 challenged, 117 through, deux populations sur une seule ligne. La relecture de cet article l’a repéré, et je l’ai corrigé une nouvelle fois le même jour.¹⁴ Le résumé de rafale, et avec lui l’objet de l’e-mail, compte désormais une seule population, chaque événement de pare-feu échantillonné, et se lit N WAF events in 5 minutes: B blocked, C challenged, U unmitigated (S from non-bot user agents) ; un challenge JavaScript compte comme challenge, et le motif du blocage automatique se lit N WAF events from this address in 5 min.¹⁴ Pour la salve de 16:51, cela donne 117 WAF events in 5 minutes: 0 blocked, 0 challenged, 117 unmitigated (104 from non-bot user agents).¹³¹⁴ L’intégration WAF reposait déjà sur les événements non atténués ; l’objet et la décision comptent donc désormais la même chose. Le correctif change ce que disent les 14 objets. Il ne change pas combien ont été envoyés, et 19 reste le chiffre honnête pour le 2 novembre.

La prévision que j’ai écrite le 1er novembre a manqué sa cible parce que sa prémisse était fausse. Elle affirmait que les nouvelles règles « would have been 0 immediate emails instead of 16 » (auraient donné 0 e-mail immédiat au lieu de 16), en partant du principe que, pour les sept alertes critiques postérieures à 00:30 ce matin-là, « Cloudflare had already blocked every one of those requests. » (Cloudflare avait déjà bloqué chacune de ces requêtes).¹ Les constats disent autre chose pour celles-là aussi : les cinq que le journal montre envoyées après 00:30 enregistrent chacune au plus un blocage et neuf challenges, face à 76 à 89 événements dans leurs résumés.¹³ Et dans chacune des six alertes critiques envoyées cet après-midi-là et ce soir-là, l’edge n’avait bloqué ou soumis à un challenge qu’une partie des événements (aucun dans la salve de 16:51) ; même la règle de 13:50, qui n’intégrait que lorsque blocages et challenges couvraient chaque événement non-bot, les aurait donc toutes envoyées.¹³¹ Dix minutes après le changement de 13:50, un second changement a fait compter à l’intégration WAF chaque événement, user agent de bot ou non, et ne faire confiance qu’à un échantillon complet ; il a rendu la règle plus stricte, mais ce n’est pas pour cela que la prévision a manqué.¹⁸³ La prévision comptait les blocages auxquels je croyais ; la règle comptait les événements qui étaient là.

Ce que je ne sais pas, c’est si ces 14, les alertes critiques du 2 novembre parties par e-mail, méritaient un e-mail. Les constats enregistrent combien d’événements étaient non atténués, c’est-à-dire sans blocage ni challenge enregistré, mais pas quelles actions ils portaient : une règle log, un skip, un allow, ou un challenge résolu par un client.¹³ Un événement non atténué n’est pas non plus une requête qui a atteint mon site. Cloudflare indique que « A single HTTP request can generate one or more security events when it triggers security features » (une seule requête HTTP peut générer un ou plusieurs événements de sécurité lorsqu’elle déclenche des fonctionnalités de sécurité), et classe log et skip parmi les actions qui ne mettent pas fin à l’évaluation des règles comme le fait un blocage ; selon ma lecture, une autre règle peut donc encore agir sur la même requête.²⁴³⁶ Le tutoriel GraphQL de Cloudflare montre le champ action et des valeurs d’exemple comme "log" et "block", mais ne liste pas toutes les valeurs que le champ peut prendre.²³ Le tableau de bord Security Events de Cloudflare échantillonne lui aussi : « For large volumes of traffic, Cloudflare uses sampling to return results faster. » (Pour de gros volumes de trafic, Cloudflare utilise l’échantillonnage afin de renvoyer les résultats plus vite.)²⁴ Tant que le moniteur n’enregistre pas les actions derrière chaque événement non atténué et ne relie pas les événements aux requêtes, je ne peux pas dire lesquels de ces e-mails décrivaient un trafic que l’edge a laissé passer, et c’est cette réponse qui décide s’ils méritent un e-mail.

Les trois e-mails locaux du 2 novembre sont l’autre point en suspens. Ils signalent à 13:50 une « Browser -> shell chain » (chaîne du navigateur vers un shell) dans laquelle un shell a lancé curl, et ils restent non résolus dans les constats.⁴⁰ Je n’ai pas vérifié s’il s’agissait de l’outillage d’agent que je faisais tourner cet après-midi-là ou d’autre chose ; je ne les compte donc pas comme de fausses alertes.

7. Deux faux signaux

Le mineur de cryptomonnaie qui était Spotlight

À 10:03 le 1er novembre, le scanner local a produit une alerte critique, « High CPU unsigned process - possible crypto miner » (processus non signé à forte consommation CPU, possible mineur de cryptomonnaie), contre spotlightknowledged, le propre démon Spotlight d’Apple, à 74,9 % de CPU, et deux secondes plus tard a journalisé « Critical email sent. »¹⁵ Le bug était le mien. La vérification cherchait l’expression « valid on disk » dans la sortie de la commande d’affichage de la signature de code, codesign -d. Les notes du scanner consignent désormais le défaut en une proposition : l’expression est une expression « which only codesign -v prints, so every process read as unsigned » (que seul codesign -v affiche, si bien que chaque processus apparaissait comme non signé).²⁵ Une liste d’exclusion avait masqué le défaut jusqu’à ce qu’un démon d’un framework Apple s’emballe, et mon journal de ce jour-là le dit.¹ Le constat porte maintenant sa résolution : « false positive, Apple platform binary » (faux positif, binaire de la plateforme Apple).⁴¹

Cela a coûté un e-mail, le seul e-mail local du 1er novembre.⁵ Les 16 alertes critiques locales qui l’ont précédé, le 31 octobre et le 1er novembre, ont signalé Xcode, le Python de Homebrew, mes propres builds d’applications, des modifications de hooks, des shims de gestionnaires de versions dans le chemin d’accès, un motif de ver IA qui correspondait aux instructions d’agent d’un autre projet, et une vérification d’event tap qui correspondait à sa propre requête ; elles ont produit 15 tentatives d’envoi, et chacune a échoué.^5251915 Le service d’envoi se trouve derrière Cloudflare, qui répondait au user agent par défaut de Python par l’erreur 1010 avant même que la clé soit lue ; je l’ai reproduit avec une clé volontairement erronée.¹⁹ La page de Cloudflare consacrée à cette erreur nomme ce client directement, dans sa note sur les hôtes Pages et Workers : « a User-Agent header that Browser Integrity Check treats as a non-browser client (for example, the default Python urllib user agent). » (un en-tête User-Agent que Browser Integrity Check traite comme un client non navigateur, par exemple le user agent par défaut de Python urllib).⁴² Un expéditeur cassé m’a épargné 15 e-mails sur mes propres outils et mes propres changements.¹⁵ Les notes du scanner énoncent la leçon plus large sans détour : « most of the CRITICALs it raised in its first live days were its own noise. » (la plupart des alertes critiques de ses premiers jours en service étaient son propre bruit).²⁵ Je garde malgré tout les alertes critiques locales immédiates, et je corrige chaque fausse alerte dans sa vérification plutôt que de couper le flux.

RUNS SHORT 162/207

Le premier récapitulatif planifié, le matin du 2 novembre, portait l’objet « Mon Nov 2: 71 blocks on 15 zones, 11 criticals emailed, RUNS SHORT 162/207 » (lun. 2 nov. : 71 blocages sur 15 zones, 11 alertes critiques envoyées, exécutions manquantes 162/207).¹⁶ La règle du récapitulatif était de l’arithmétique simple : le nombre d’exécutions attendu est le nombre de minutes de la fenêtre divisé par cinq, et l’objet signale un déficit.³⁵ La fenêtre allait du 1er novembre 13:48 au 2 novembre 07:05, soit 1 036,5 minutes, donc 207 créneaux de cinq minutes ; le journal a enregistré 162 exécutions.¹⁷

Mon journal du 2 novembre expliquait l’écart en une ligne : « The RUNS SHORT line is the Mac asleep » (la ligne RUNS SHORT, c’est le Mac en veille), sans défaillance du moniteur.⁴³ Cette ligne a raison de dire que le moniteur n’a pas failli (aucune exécution du 2 novembre n’est restée inachevée) et tort sur la cause, le 2 novembre comme sur la fenêtre que décrivait le chiffre. L’analyse des écarts entre exécutions répartit approximativement les 45 créneaux manquants : environ 25 perdus à la cadence, environ 16 à la veille, environ un de plus dans un long écart après une exécution terminée prématurément, et trois exécutions qui ne se sont jamais enregistrées.¹⁷

Le journal d’alimentation montre une veille d’inactivité à 23:21:30 et un réveil complet à 00:30:05, puis de nouveau une veille d’inactivité à 06:01:20 et un réveil complet à 06:30:28.⁴⁴ Les trois exécutions ont démarré à 14:09, 14:19 et 23:10 le 1er novembre ; chacune s’est terminée environ quatre minutes plus tard sans ligne de fin journalisée, ce qui, selon ma lecture, est le watchdog de 240 secondes. Une quatrième exécution s’est terminée 28 secondes après son démarrage sans cause visible.¹⁷³⁸ Sur la journée calendaire du 2 novembre, 242 exécutions ont démarré face à 288 créneaux de cinq minutes, soit 46 de moins, et aucune n’est restée inachevée ; seuls deux écarts ont dépassé 10 minutes, 35,8 minutes en tout ; ce jour-là aussi, l’essentiel du déficit venait donc de la cadence, pas de la veille.¹⁷

L’hypothèse fausse était la mienne, dans le récapitulatif : un planificateur réglé sur cinq minutes livrait une exécution environ toutes les 5,6 à 5,8 minutes même Mac éveillé, si bien que l’arithmétique à cinq minutes qualifierait de déficitaire une journée saine.¹⁷ Je n’ai pas établi pourquoi la cadence en éveil est plus lente. J’ai remplacé l’arithmétique le 3 novembre. L’état des exécutions indique désormais les exécutions enregistrées, la médiane des minutes qui les séparent et le plus long écart avec son heure, et l’objet ne signale qu’un écart de plus de 20 minutes. L’aperçu de ce matin-là indiquait « about one every 5.6 min » (environ une toutes les 5,6 minutes), et son objet se terminait par « RUN GAP 31 min at 05:56 » (écart d’exécution de 31 minutes à 05:56).¹⁴ Un écart est un symptôme sur lequel je peux agir : le Mac s’est mis en veille, ou le moniteur s’est arrêté. Un ratio rapporté à une cadence que le planificateur n’a jamais tenue n’était ni l’un ni l’autre.

Les règles que j’ai gardées

1. Comptez le courrier avant de le changer, par flux, avec une règle énoncée. Mon tableau et le décompte du journal ne se sont accordés sur 74 que parce que j’avais d’abord écrit ce qui comptait comme un e-mail.¹²
2. Ne journalisez « sent » que lorsque le service d’envoi dit oui. Pour 22 de mes 74 e-mails, je peux prouver une tentative et rien de plus.²⁶
3. Un blocage déjà effectué par l’edge est une ligne de journal, pas une alerte. Les trois sorties du livre SRE l’y rangent, et déplacer 55 e-mails par blocage vers le chat ne m’a rien fait perdre sur quoi j’aurais agi.⁷⁵
4. Envoyez un récapitulatif quotidien même quand rien ne s’est passé. Un récapitulatif qui arrive toujours est le signal de vie ; son absence est l’alerte.³⁵
5. N’intégrez une alerte critique que sur une condition que l’edge prouve. Les miennes sont : les adresses blocables du constat déjà sur la liste de blocage, et un échantillon complet dans lequel chaque événement a un blocage ou un challenge enregistré ; la seconde explique pourquoi 14 alertes sont encore parties par e-mail le 2 novembre.³¹³
6. Inscrivez l’issue sur chaque alerte critique du cloud. Un rapport quotidien dont personne n’est responsable revient, selon les mots d’Ewaschuk, à des « less-spammy email alerts » (alertes e-mail un peu moins envahissantes) ; l’issue sur chaque ligne est ce que vérifie mon tri quotidien.³⁰¹²
7. Faites dire à l’objet ce que l’edge a fait. « 104 WAF blocks » sur une salve sans aucun blocage a été ma pire ligne de la semaine.¹³
8. Signalez des écarts, pas des ratios rapportés à un calendrier. Une minuterie de cinq minutes livrait une exécution environ toutes les 5,6 minutes ; 162/207 ressemblait donc à une panne et n’était, pour l’essentiel, qu’une horloge.¹⁷
9. Corrigez une fausse alerte dans sa vérification, pas dans la boîte de réception. Une sortie de commande mal lue a fait du démon Spotlight d’Apple un mineur de cryptomonnaie ; le correctif est allé dans la vérification.²⁵

Ce qui pourrait changer

• Si les événements non atténués se révèlent être des challenges résolus, cela seul ne ferait pas du bruit des alertes critiques de rafale WAF qui partent encore par e-mail. Quand un client réussit un challenge, « Cloudflare accepts the matched request » (Cloudflare accepte la requête concernée) : la requête poursuit son chemin, ce qui ne montre ni qu’elle était inoffensive ni que rien n’appelle de réponse. Intégrer ces alertes critiques exigerait des preuves au niveau des requêtes, rattachées aux mêmes événements, montrant que rien en elles ne demandait une personne, et la réussite d’un challenge ne constitue pas à elle seule une telle preuve. S’il s’agit de règles log ou skip, la question est de savoir si ces règles font ce que je voulais, et chaque e-mail mérite d’être lu tant que je ne le sais pas. Le moniteur n’enregistre pas encore lequel des deux.¹³³⁶
• Si les e-mails critiques d’une journée remontent vers plusieurs dizaines, c’est que la limite de deux heures par site et par catégorie fait le travail qu’une règle devrait faire, et la règle mérite d’être revue.³
• Si le récapitulatif cesse d’arriver, quelque chose s’est arrêté entre le moniteur et ma boîte de réception : le moniteur, le Mac sur lequel il tourne, l’expéditeur ou le chemin de remise, puisqu’un envoi accepté n’est pas encore un envoi remis. C’est le seul silence que la conception traite comme une invitation à aller voir.³⁵²⁰
• Si le scanner local produit une alerte critique que je ne peux pas expliquer par mon propre outillage, l’e-mail immédiat était le bon choix ; les trois constats de chaîne vers un shell non résolus du 2 novembre en sont le test en cours.⁴⁰
• Si j’ajoute un lecteur, les pages et les tickets ne sont plus la même personne, et la distinction du livre SRE entre alertes et tickets exigerait une file de tickets, pas ma boîte de réception.⁷

Points clés

Si vous faites tourner un moniteur pour vous-même

• J’ai cessé de lire quelque part en deçà de 74 e-mails en une demi-journée, un chiffre que ma boîte de réception a atteint en début d’après-midi.¹
• Un récapitulatif quotidien qui arrive aussi les jours calmes est un signal de vie gratuit ; un moniteur qui ne parle que lors d’événements ne peut pas vous dire qu’il est mort.³⁵
• Vos journaux disent peut-être « sent » pour du courrier qui n’est jamais parti. Vérifiez le code avant de vous fier au décompte.⁶¹⁹

Si vous en construisez un

• Agissez d’abord, décidez ensuite s’il faut prévenir : bloquez, puis intégrez l’alerte si la liste de blocage ou l’edge la couvre déjà.³
• Enregistrez l’issue de chaque alerte critique sur le constat et imprimez-la dans le récapitulatif, afin que la personne qui, selon Ewaschuk, doit trier un rapport quotidien ait quelque chose à vérifier ; sur mon moniteur, cette personne, c’est moi.³⁰¹²
• Nommez les événements d’après ce que l’edge a enregistré pour eux (bloqués, soumis à un challenge, non atténués), comptez une seule population par ligne, et ne les nommez jamais d’après ce que vous espériez que l’edge ait fait.¹³¹⁴
• Mesurez le planificateur que vous avez réellement. Le mien tournait toutes les 5,6 minutes avec une minuterie de cinq minutes.¹⁷

Si c’est vous qui lisez la boîte de réception

• Demandez de chaque alerte si elle est « urgent, important, actionable, and real » (urgente, importante, actionnable et réelle) ; tout ce qui échoue à ce test relève d’un récapitulatif ou d’un journal.²⁹
• Ma prévision du premier jour a manqué sa cible : elle annonçait zéro alerte critique immédiate, et le lendemain en a envoyé 14.¹⁵

Questions fréquentes

Qu’est-ce que la fatigue d’alerte ?

La fatigue d’alerte, c’est ce qui arrive aux personnes qui reçoivent trop d’alarmes ne leur demandant rien : elles deviennent, selon les mots de The Joint Commission, « desensitized or immune to the sounds » (insensibles ou immunisées aux sons), et se mettent à baisser ou à couper les alarmes.¹⁰ Le livre SRE de Google décrit la même chose en exploitation, où les gens « second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a “real” page that’s masked by the noise. » (doutent, survolent ou ignorent les alertes entrantes, au point parfois d’ignorer une « vraie » page masquée par le bruit).²⁷ Mon propre cas a pris une journée : 74 e-mails à 13:32, dont aucun, selon ma lecture de cet après-midi-là, ne me demandait d’agir.¹

Combien d’alertes de sécurité par jour, c’est trop ?

Pour une personne, la réponse honnête du chapitre SRE est : quelques-unes. « I can only react with a sense of urgency a few times a day before I become fatigued. » (Je ne peux réagir dans l’urgence que quelques fois par jour avant de m’épuiser.)⁸ L’enquête du fournisseur Vectra rapporte des équipes qui reçoivent en moyenne 4 484 alertes par jour et qui, de leur propre aveu, en ignorent 67 %.³⁴ Pour mon moniteur tenu par une seule personne, la réponse de travail est un récapitulatif par jour plus les alertes qui ont besoin d’un humain maintenant ; le 2 novembre, cela faisait encore 19, et je traite les 14 alertes critiques de rafale WAF parmi elles comme une question ouverte plutôt que comme un coût acquis.⁵¹³

Les alertes de sécurité doivent-elles passer par un récapitulatif quotidien ou en temps réel ?

Les deux, réparties selon ce que l’humain doit faire. Tout ce que le moniteur considère comme déjà traité (une adresse qu’il a placée sur la liste de blocage, ou une rafale dont chaque événement échantillonné a été bloqué ou soumis à un challenge) va dans le récapitulatif ; le reste part immédiatement, dans la limite de deux heures.³ Ewaschuk admet qu’un rapport quotidien « can work too » (peut aussi fonctionner), à une condition : sans responsabilité, il « amounts to less-spammy email alerts » (revient à des alertes e-mail un peu moins envahissantes), et il veut quelqu’un de « designated to triage these every day » (désigné pour les trier chaque jour).³⁰ Sur mon moniteur, c’est moi, et mon récapitulatif imprime ce qu’il est advenu de chaque alerte critique cloud pour que le tri ait quelque chose à vérifier.¹²

Qu’est-ce qu’une alerte de type heartbeat ?

Un heartbeat (signal de vie) est un message qui arrive selon un calendrier, qu’il se soit passé quelque chose ou non, de sorte que son absence signifie qu’une chose s’est cassée. Mon récapitulatif quotidien est ce signal de vie : « it goes out on a quiet day too » (il part aussi les jours calmes) ; un moniteur qui a cessé de tourner se manifeste donc par un e-mail manquant.³⁵ Il en va de même d’un envoi échoué ou d’une remise perdue ; un récapitulatif manquant invite donc à vérifier le moniteur, l’hôte sur lequel il tourne, l’expéditeur et le chemin de remise.²⁰ Sa section sur l’état des exécutions indique aussi le plus long écart entre exécutions et signale dans l’objet tout écart de plus de 20 minutes.¹⁴

Pourquoi les alertes WAF de Cloudflare inondent-elles ma boîte e-mail ?

La mienne a été inondée parce que chaque blocage et chaque alerte critique devenait un message à part entière, et qu’Internet balaie chaque zone publique toute la journée.⁵ Les Alerts de Cloudflare, « Monitors that you define yourself, and Platform Notifications » (des Monitors que vous définissez vous-même, et des Platform Notifications), peuvent être remises par e-mail et se paramètrent dans son tableau de bord ; un moniteur que vous construisez vous-même sur son API, comme le mien, n’est ni l’un ni l’autre et hérite de tout envoi par événement que vous y avez écrit.²⁶ Vérifiez aussi ce que compte une alerte : les actions de Cloudflare incluent log et skip, qui ne mettent pas fin à l’évaluation des règles comme un blocage, et un challenge résolu par un client se termine par l’acceptation de la requête par Cloudflare ; « WAF events » (événements WAF) et « WAF blocks » (blocages WAF) sont donc des chiffres différents.³⁶ Mes objets ont confondu les deux jusqu’au 3 novembre.¹³¹⁴

Un 2xx de l’API d’e-mail signifie-t-il que l’alerte a été remise ?

Non. L’événement email.sent de Resend « Occurs whenever the API request was successful. Resend will attempt to deliver the message to the recipient’s mail server » (se produit chaque fois que la requête API a réussi ; Resend tentera alors de remettre le message au serveur de messagerie du destinataire), et la remise est un événement distinct.²⁰ Un 2xx signifie que le service a accepté le message. Journalisez le code de statut, et traitez la remise comme une autre question.⁶

À lire aussi sur ce site : Pourquoi le spam a battu mon formulaire de contact à débit limité suit le même scanner du 2 novembre du côté du formulaire de contact ; Ce que je lance avant de dormir est la vérification nocturne de la production, l’autre routine qui tourne pendant que je ne regarde pas ; Ce qui casse vraiment quand des agents IA tournent sans supervision nomme les modes de défaillance des sessions d’agent sans surveillance, chacun avec un signal de détection ; Chaque hook est une cicatrice relie chacun de mes hooks d’agent à l’échec qui l’a fait naître, la même habitude que corriger une fausse alerte dans sa vérification ; Le mode auto de Claude Code n’est pas une frontière de sécurité soutient que le mur autour d’un agent compte plus que son classificateur ; et L’observabilité des agents IA plaide pour voir ce que les agents font au disque, au CPU et au réseau.

Sources

Toutes les heures des données propres à l’auteur sont en heure locale du Pacifique sauf mention UTC ; le 1er novembre, l’heure est passée de PDT à PST à 02:00. Les pages publiques ont été consultées le 3 novembre 2026, aux heures UTC indiquées.