--- title: "Alertes CSP et changement de script dans Slack ou Teams" description: "Alertes CSP et changement de script dans Slack, Teams, Telegram, e-mail ou webhook signé, dès l'arrivée du rapport. Détection et alerte PCI DSS 11.6.1." url: "https://centralcsp.com/fr/platform/alerting/" lang: "fr" --- Alertes # Votre site a changé. Votre équipe le sait déjà. Ajoutez une règle une fois. Quand le navigateur d'un vrai visiteur signale le changement, le message est déjà dans le canal responsable de cette page. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Voir ce que nous surveillons](https://centralcsp.com/fr/platform/monitoring/) - Se déclenche à l'arrivée Pas un balayage nocturne - Six destinations Chat, e-mail ou webhook - Routage par site Et par équipe - Aucun agent Un en-tête de réponse [Créer votre première règle d'alerte](https://centralcsp.com/fr/docs/platform/features/alerting/get-started) prend une dizaine de minutes. Déclencheurs ## Ce qui mérite de déranger quelqu'un. Une règle d'alerte, c'est un événement rapporté par un navigateur, un périmètre de pages, un ou plusieurs canaux et une temporisation. Nouvelle origine, changement de script détecté par hash, altération d'une page de paiement : la source est toujours le rapport du navigateur lui-même, jamais un crawler ni un agent injecté. - ### Une nouvelle origine apparaît Un script chargé depuis un hôte jamais vu. Les skimmers Magecart et de formjacking commencent exactement ici : un nouvel hôte, puis un formulaire de carte qui lui transmet discrètement les données. - ### Un script a changé Un fichier que vous exécutez ne correspond plus au hash d'hier. Votre build l'a fait, ou quelqu'un d'autre. - ### Quelque chose a touché une page de paiement Les pages porteuses de données de carte ont leurs propres règles, parce que [l'exigence PCI DSS 11.6.1 demande d'alerter sur leurs modifications](https://centralcsp.com/fr/platform/pci-dss/). - ### Une CVE connue apparaît Une bibliothèque que vous chargez fait l'objet d'un avis publié. Vous l'apprenez avec la version et l'identifiant CVE. [Voir comment l'inventaire des scripts les repère](https://centralcsp.com/fr/platform/supply-chain/). - ### Les rapports s'envolent Les violations ont bondi après le déploiement de 16 h. Quelque chose a cassé à grande échelle, et les navigateurs l'ont dit en premier. - ### Un signal silencieux se réveille Une directive muette tout le trimestre se met à parler. À regarder avant que cela ne devienne un incident. Ces six-là valent qu'on interrompe quelqu'un. Le catalogue complet des événements est plus large : [tous les événements qu'une règle peut surveiller, avec périmètre et temporisation](https://centralcsp.com/fr/docs/platform/features/alerting/rules). Canaux ## Voilà à quoi ressemble une alerte. La même règle, qui atteint trois équipes là où elles travaillent déjà. Chaque règle choisit sa destination : un incident sur le checkout et une alerte du site vitrine n'atterrissent jamais dans le même fil. - - - Toutes les destinations qu'une règle peut atteindre - Slack - Microsoft Teams - Google Chat - Telegram - E-mail - Webhooks Mise en place ## Configuré une fois, puis ça tourne sans vous Canaux, règles et historique des envois tiennent sur un seul écran. Connectez une destination, dirigez-y vos règles, puis vérifiez après coup ce qui est réellement parti. ### Chaque règle atteint l'équipe qui possède la page Ajoutez un canal, Slack, Teams, Google Chat, Telegram, e-mail ou webhook, puis choisissez les événements qui y arrivent. Une nouvelle origine sur le checkout part vers l'équipe paiement, une directive cassée sur le blog vers ceux qui publient le blog. [Démarrer l'essai gratuit](https://app.centralcsp.com) ![L'écran d'alerting : les canaux connectés d'un côté, et les règles qui décident quels événements arrivent dans quel canal.](https://centralcsp.com/assets/cta-alerts-D_o4f2qB.webp) ### Un message, pas quatre cents Les rapports arrivent dédupliqués et regroupés, et chaque règle accepte une temporisation : un mauvais déploiement n'interrompt quelqu'un qu'une fois. ### Historique des envois par canal Chaque tentative est enregistrée avec son statut et la raison de l'échec, et les échecs transitoires sont réessayés. Plus besoin de deviner si un message est parti. ### API et MCP Les règles sont une ressource REST, et les mêmes opérations passent par le serveur MCP intégré. Intégrer cent sites devient une boucle. Pour aller plus loin ## Créez votre première règle Tous les événements qu'une règle peut surveiller, tous les canaux qu'elle peut atteindre, et ce qui se passe quand un envoi échoue. - [Créer votre première règle d'alerte](https://centralcsp.com/fr/docs/platform/features/alerting/get-started) - [Événements, périmètre et temporisation](https://centralcsp.com/fr/docs/platform/features/alerting/rules) - [Tous les canaux d'alerte et l'URL requise](https://centralcsp.com/fr/docs/platform/features/alerting/channels) - [Vérifier un webhook signé](https://centralcsp.com/fr/docs/platform/features/alerting/channels/webhook) - [Historique des envois et comportement de relance](https://centralcsp.com/fr/docs/platform/features/alerting/deliveries) - [Détecter un skimmer Magecart côté client](https://centralcsp.com/fr/blog/magecart-formjacking-detection) FAQ ## Questions fréquentes Canaux, rapidité, bruit et conformité : les réponses. ### Puis-je recevoir les alertes de violation CSP dans Slack ? Oui, ainsi que dans Microsoft Teams, Google Chat, Telegram, par e-mail ou vers n'importe quel webhook que vous hébergez. Connectez le canal une fois, puis dirigez-y vos règles. Une règle peut publier dans plusieurs canaux, et deux règles sur le même site peuvent atteindre des équipes différentes. ### Pourquoi alerter plutôt que simplement bloquer le script ? Les skimmers Magecart et de formjacking sont la raison. Bloquer, c'est le rôle de la Content Security Policy, et vous devriez en avoir une. Ce qu'une politique ne sait pas faire, c'est distinguer un bon changement d'un mauvais à l'intérieur d'un prestataire que vous avez déjà approuvé : c'est exactement ainsi que British Airways a été compromis. La politique ferme les portes ; les alertes vous préviennent quand quelque chose bouge dans une pièce où vous avez déjà laissé entrer quelqu'un. ### En combien de temps une alerte arrive-t-elle ? Les règles sont évaluées à mesure que les rapports arrivent, et les navigateurs les envoient peu après le chargement de la page. En pratique, vous êtes prévenu d'un nouveau script dès la prochaine page vue qui le charge, pas lors d'un balayage nocturne. À titre de comparaison, Cloudflare Page Shield regroupe ses alertes de nouvelle ressource par jour et ses alertes de changement de code jusqu'à toutes les 24 heures. ### Ne vais-je pas être noyé sous le bruit CSP ? C'est le mode d'échec habituel, et il vient du fait d'alerter sur des rapports bruts. Les vôtres arrivent dédupliqués, regroupés par directive et par origine, et les faux positifs d'extensions de navigateur sont déjà signalés. Vous pouvez aussi limiter chaque règle aux pages qui comptent : le checkout et le blog ne partagent jamais la même règle. Par-dessus tout cela, chaque règle accepte une temporisation : indiquez combien de temps elle doit rester silencieuse après s'être déclenchée, et un mauvais déploiement produit un message, pas quatre cents. ### Que se passe-t-il si Slack ou mon webhook est indisponible ? L'envoi est réessayé, et chaque tentative est enregistrée dans l'historique des envois avec son canal, son statut et la raison de l'échec. Les échecs transitoires, comme un timeout ou une erreur 5xx de votre endpoint, sont réessayés. Les échecs permanents ne le sont pas : une URL de webhook révoquée, un canal Slack qui n'existe plus ou une erreur 4xx indiquant que la requête elle-même est mauvaise ne passeront pas à la seconde tentative, et l'historique les affiche comme échoués plutôt que de réessayer indéfiniment. Vous lisez le résultat par règle et par canal, au lieu de deviner si un message est parti. ### Cela répond-il à l'exigence PCI DSS 11.6.1 ? C'est la moitié détection et alerte de l'exigence. La 11.6.1 demande un mécanisme de détection des changements et des altérations qui alerte le personnel en cas de modification non autorisée des pages de paiement et de leurs en-têtes HTTP, telles que reçues par le navigateur du consommateur, au moins tous les sept jours. Les rapports CentralCSP viennent du navigateur du consommateur et ses règles se déclenchent à leur arrivée. Associez-la à l'inventaire de scripts pour la 6.4.3 et exportez les deux comme preuves. ### Faut-il un agent ou un script sur la page ? Non. Les alertes s'appuient sur le même en-tête de réponse que la surveillance. Les navigateurs génèrent eux-mêmes les rapports : rien à installer, rien à maintenir à jour, et aucun script tiers ajouté aux pages que vous cherchez justement à protéger. ### Les alertes fonctionnent-elles quand ma CSP est encore en Report-Only ? Oui, et c'est en général là qu'elles sont le plus utiles. Les règles s'appuient sur les rapports envoyés par le navigateur, pas sur les blocages qu'il effectue, et Content-Security-Policy-Report-Only envoie exactement les mêmes rapports de violation sans rien bloquer. Vous pouvez donc surveiller une nouvelle origine ou un script modifié pendant toute la phase report-only, avant d'appliquer quoi que ce soit. ### Puis-je créer des règles d'alerte via l'API ? Oui. Les règles sont une ressource REST, et les mêmes opérations sont disponibles via le serveur MCP intégré : intégrer cent sites devient une boucle plutôt qu'un après-midi. Une clé API agit au nom de la personne qui l'a créée, avec ses rôles, et la révoquer coupe l'intégration immédiatement. ## Créez une règle aujourd'hui. Oubliez-la jusqu'à ce qu'elle compte. Ajoutez l'en-tête, connectez un canal, choisissez le changement qui mérite un message. 14 jours d'essai gratuit, aucun agent à déployer. [Démarrer l'essai gratuit](https://app.centralcsp.com) [Vérifiez votre configuration de reporting](https://centralcsp.com/fr/tools/reporting-api/) --- Disponible en : [en](https://centralcsp.com/en/platform/alerting/), [fr](https://centralcsp.com/fr/platform/alerting/)