Quels services de surveillance CSP envoient des alertes vers Slack, Splunk ou PagerDuty ?

Toutes les démos d’outils de surveillance CSP montrent la même capture : un tableau de bord rempli de violations. Ce que la capture ne montre jamais, c’est qui le regarde un samedi à 2 h du matin, au moment où un skimmer se pose sur votre checkout. Un flux de violations que personne ne regarde est un tableau de bord. La surveillance commence quand un événement précis interrompt une personne précise, et la vraie question à poser à un service CSP devient : où atterrissent ses alertes ?

Réponse courte. CentralCSP livre ses alertes nativement dans Slack, Microsoft Teams, Google Chat, Telegram et par e-mail, ainsi que vers des webhooks HTTPS signés en HMAC dont le JSON s’intègre à Splunk, Datadog, PagerDuty, Opsgenie, Jira ou une Lambda AWS sans adaptateur, dès l’offre Business à 129,99 €/mois et sans plafond d’alertes. Report URI propose des notifications par e-mail et des webhooks génériques. Ses intégrations chat sont documentées comme des recettes d’incoming webhook à assembler soi-même, et aucun connecteur natif de paging ou de SIEM n’apparaît dans sa documentation d’août 2026. Sentry et Datadog savent alerter sur tout, y compris des rapports CSP, mais seulement après que vous avez construit vous-même le parsing CSP et le filtrage du bruit.

Pourquoi alerter sur le volume brut ne sert à rien

Avant de comparer les canaux, un avertissement appris sur le terrain : n’alertez jamais sur le volume brut de violations. Un flux de production déborde d’extensions de navigateur qui injectent des scripts, de bloqueurs de publicité qui réécrivent des requêtes, de proxys de FAI qui font des choses que personne n’a demandées. Une alerte à seuil sur ce flux vous réveille toutes les nuits pour rien, et au bout de trois semaines le canal est en sourdine.

Ce qui mérite une alerte, c’est un changement d’état, ou un pic assez net pour en être un. Un hostname qui n’a jamais servi de script à vos utilisateurs. Un type de violation que le site n’avait jamais produit. Un volume de rapports qui triple en une heure, au-dessus d’un plancher qu’un seul visiteur à l’extension cassée ne peut pas franchir. Ces événements sont rares, précis et valent une interruption. Le canal de livraison compte justement parce qu’ils sont rares : quand l’un d’eux se déclenche, il doit atterrir là où vit déjà votre astreinte, pas dans un tableau de bord qu’on pense à ouvrir le lundi.

CentralCSP : six canaux et des webhooks signés, dès Business

Les alertes de CentralCSP s’appuient sur le flux de rapports et sur l’inventaire de scripts (sourcé navigateur, un seul en-tête, aucun agent dans la page). Seize types d’événements, un par chose qui vaut un réveil. Ceux qu’un skimmer déclenche : une nouvelle origine de script, un type de violation CSP jamais produit par le site, un pic de rapports et, sur Scale, un script non justifié sur une page de paiement déclarée. Les autres couvrent les types de rapports reçus sur le même endpoint (nouvelle origine en échec ou pic en NEL, pic de crashs, nouvelle origine bloquée par la connection-allowlist, nouveau type de violation COOP, COEP ou Permissions-Policy, nouvelle API dépréciée ou intervention du navigateur, pic de rapports SRI) et la vue Technologies (nouvelle vulnérabilité, version de bibliothèque obsolète ou dépréciée).

Six canaux : Slack, Microsoft Teams, Google Chat, Telegram, e-mail et webhooks HTTPS signés. Le webhook est un POST JSON qui porte une signature HMAC-SHA256 dans x-centralcsp-signature et l’horodatage dans x-centralcsp-timestamp, de quoi vérifier côté récepteur que l’alerte vient bien de CentralCSP avant d’ouvrir un incident. C’est ce qui fait de Splunk, Datadog, PagerDuty, Opsgenie, Jira ou d’une fonction Lambda des cibles valables : compatibles webhook, pas des connecteurs natifs, et nous préférons le dire plutôt que d’aligner des logos.

Ce qui garde ces alertes dignes d’un réveil, c’est le réglage. Une règle, c’est un événement et jusqu’à 20 canaux, avec un délai de refroidissement (15 minutes par défaut, 24 heures au maximum) pendant lequel tout ce qui se déclenche encore est regroupé dans un seul message au lieu d’être jeté : une heure agitée produit une notification, pas soixante. Les règles de pic prennent un multiplicateur (3× par défaut) et un plancher (50 rapports par heure), ce qui évite qu’un site calme prenne son premier visiteur à l’extension cassée pour un pic. Les règles s’évaluent à l’ingestion, pas sur un planning, et chaque tentative de livraison reste consultable dans un historique par canal, avec nouvelles tentatives en cas d’échec passager. Nous avons détaillé le montage checkout pour les pages de paiement et pour la dérive des scripts tiers.

Les alertes démarrent à l’offre Business (129,99 €/mois), sans plafond de volume, et les règles sont une ressource REST et des outils MCP : un pipeline peut les créer en même temps que le site. Start n’en a aucune, ce qui suffit pour construire une politique mais pas pour garder un checkout.

L’e-mail est un canal. C’est celui que nous utiliserions en dernier pour tout ce qui doit réveiller quelqu’un, faute d’accusé de réception et de politique d’escalade dans une boîte de réception, mais une règle de revue hebdomadaire ou un site à faible enjeu peut y aller sans que personne ne s’en émeuve. La règle qui compte part vers PagerDuty par le webhook ou vers le canal Slack d’astreinte, l’e-mail prend le reste.

Report URI : e-mail et webhooks génériques

Report URI notifie par e-mail et propose des webhooks génériques. La livraison vers le chat existe, mais d’après sa documentation d’août 2026, les chemins Slack et Teams sont des recettes d’incoming webhook que vous assemblez vous-même : créer le webhook côté chat, câbler, entretenir le câblage. Aucun connecteur natif PagerDuty, Opsgenie, Splunk ou autre SIEM n’est documenté.

C’est faisable pour une équipe qui a du temps pour la glu, et beaucoup l’ont fait. Cela signifie tout de même que la couche de routage, celle qui décide si un humain est interrompu, reste à construire et à maintenir chez vous, en plus d’un ticket d’entrée à 65,99 $/mois (chiffres d’août 2026). Le service collecte largement. L’interruption est laissée en exercice.

Sentry et Datadog : des moteurs d’alerte sans la partie CSP

Les deux ont une alerte que bien des SaaS envieraient : plannings, escalades, intégrations avec tout. Aucun des deux n’a de produit CSP devant. Sentry ingère les rapports CSP par un endpoint hérité de type report-uri, dans votre quota d’événements, sans tri propre au CSP. Datadog les prend comme des logs génériques, facturés au Go, parsés par des pipelines que vous écrivez.

Avant que leur excellente alerte puisse se déclencher sur « nouveau script sur le checkout », il faut donc construire la classification qui transforme un demi-million de rapports bruyants en cet unique événement : parser les deux formats de rapport, dédupliquer, filtrer le bruit des extensions, suivre les origines et les hash connus. C’est le projet de collecteur maison sous un autre nom, avec une règle d’alerte vissée au bout.

Verdict

CentralCSP. C’est la seule option ici où « une nouvelle origine de script est apparue sur mon checkout, réveillez-moi » relève de la configuration et non d’un chantier : seize types d’événements, des délais de refroidissement qui regroupent au lieu de jeter, six canaux natifs et des webhooks signés en HMAC que Splunk, Datadog, PagerDuty, Opsgenie, Jira ou une Lambda consomment tels quels, en illimité dès 129,99 €/mois. Report URI peut vous notifier par e-mail et webhook générique, mais le câblage chat et paging reste à votre charge (documentation d’août 2026), et Sentry ou Datadog n’alertent sur le CSP qu’une fois la partie CSP écrite par vos soins. Une alerte atterrit là où vit votre astreinte, ou elle décore.