Quels outils CSP permettent de surveiller plusieurs sites depuis un seul tableau de bord ?

Un site avec une CSP, c’est un projet. Quinze sites avec quinze CSP, c’est un métier. En général celui d’une agence, ou d’une équipe plateforme dans un groupe qui fait tourner une dizaine de marques sur une dizaine de stacks. Les politiques ne peuvent pas être partagées (le monolithe de paiement et le site vitrine WordPress ne chargent rien en commun), les rapports ne doivent pas se mélanger, et le chef de projet veut quand même un seul écran qui dit si tout est au vert. Quand ces sites appartiennent à des clients et non à votre propre groupe, le montage pour agences traite ce qui en découle : la segmentation par client, le rapport mensuel et qui finit par payer les sièges.

Réponse courte : CentralCSP est l’outil conçu pour ce cas. Ses offres couvrent 3 sites en Start (39,99 €/mois), 10 en Business (129,99 €) et 30 en Scale (349,99 €), avec des quotas sur mesure en Enterprise. Chaque site porte sa propre politique, son propre sous-domaine de collecte et son propre flux de violations, le tout dans un seul tableau de bord. Report URI plafonne à 5 domaines sur son offre à 329,99 $/mois (chiffres d’août 2026) : dix sites clients, c’est déjà un contrat Enterprise. URIports accepte beaucoup de domaines pour pas cher, jusqu’à 400, mais se contente de collecter les rapports : il ne vous aidera à construire aucune politique.

Ce qu’exige vraiment la surveillance CSP multi-site

Toutes les agences et équipes multi-marques qui nous parlent arrivent avec les trois mêmes besoins.

Des politiques par site, d’abord. Une CSP est l’empreinte des dépendances d’une application précise. Dès que deux sites partagent une politique, celle-ci devient l’union des deux listes d’autorisation, autrement dit elle ne protège ni l’un ni l’autre.

Des rapports par site, ensuite. Quand les violations de douze propriétés tombent dans le même bac, chaque tri commence par vingt minutes de filtrage avant de savoir quel client est touché. Il faut un flux par site, un endpoint par site, un historique par site.

Et une visibilité partagée. La personne qui corrige la politique, celle qui répond au client et celle qui reçoit l’alerte de nuit sont rarement la même. Un seul siège sur le compte ne survit pas au contact d’une vraie équipe.

CentralCSP : le site est l’unité de tout

Chez CentralCSP, chaque site web est un site dans un espace de travail. Chacun reçoit son propre sous-domaine de collecte (https://MyEndpoint.report.centralcsp.com, un par site), donc les rapports ne se contaminent jamais entre eux. Il a son flux de violations indexé (filtrable par type de rapport, directive, navigateur et origine), son inventaire de scripts et son travail de politique dans le Builder. Le tableau de bord les affiche côte à côte.

Trois détails pèsent plus que le tableau ne le laisse voir. Les sièges arrivent avec des rôles sur toutes les offres, et ces rôles s’attribuent site par site : Viewer, Analyst, Manager ou Admin sur le site A ne dit rien du site B, et les groupes regroupent ces attributions pour que l’arrivée du cinquième collègue tienne en un clic. Toute l’équipe (et celle du client, si vous voulez) lit les mêmes données au lieu de se transférer des captures d’écran, et le client ne voit que son site. Le quota de rapports de l’espace de travail se découpe en plafonds par site : la marque qui refond en mars ne peut pas manger le quota des onze autres. Et dès Business, l’API REST couvre tout ce que montre le tableau de bord, en lecture comme en gestion : créer des sites depuis un pipeline, tirer les compteurs de violations par site vers votre propre page de synthèse ou le PDF mensuel du client, gérer les règles d’alerte. Nous connaissons des agences dont tout le reporting client sort de là. Le serveur MCP arrive avec, pour les équipes qui préfèrent demander à un assistant lequel des trente sites a vu une nouvelle origine de script cette semaine.

À partir de Business, les règles d’alerte se définissent site par site et se routent règle par règle : celle qui vous réveille pour les pages de paiement du client A poste dans votre Slack d’exploitation et ne dit rien du blog du client B, dont les règles partent vers une liste e-mail que personne ne lit le week-end. La grille complète est sur la page tarifs.

Report URI : les plafonds de domaines mordent vite

Report URI compte les domaines par offre : 1 à 65,99 $/mois, puis 2, puis 3, puis 5 sur l’offre haute à 329,99 $ (tous les chiffres datent d’août 2026). Faites le calcul d’agence. Dix sites clients n’entrent dans aucune offre en libre-service, à aucun prix. La réponse s’appelle un rendez-vous Enterprise. Même cinq sites vous placent à 329,99 $/mois pour 2 millions d’événements, là où CentralCSP Business couvre les mêmes 2 millions de rapports pour 129,99 €, environ 40 % du prix, et loge dix sites. Le produit reste sérieux, dix ans de service et la couverture de types de rapports la plus large de la catégorie, mais son packaging a été pensé pour une entreprise qui surveille son propre domaine, et c’est en multi-site que ça se voit. Le tableau complet est dans notre comparatif des alternatives à Report URI.

URIports : beaucoup de domaines, mais de la collecte seulement

URIports est l’option budget honnête pour le volume : jusqu’à 400 domaines sur ses grandes offres, hébergé en UE, activement développé. C’est aussi strictement un collecteur. Les rapports CSP, NEL et DMARC arrivent, des graphiques s’affichent, et le produit s’arrête là. Pas de générateur de politique, pas d’inventaire de scripts, pas d’alertes par site sur les changements de scripts. Pour une agence, la partie coûteuse du travail, écrire et maintenir quinze politiques, reste donc entièrement manuelle. Très bien si vous comptiez seulement regarder. Insuffisant si le livrable est une politique appliquée.

La mise en place par site qui fonctionne

Ce que nous recommandons aux agences qui embarquent un portefeuille :

1. Créez un site distinct par propriété cliente, même les petites. Des données segmentées dès le premier jour ne coûtent rien, les démêler plus tard est une corvée. Réglez le filtre d’ingestion sur les vraies origines du client pour qu’un en-tête recopié sur un clone de préproduction ne pollue pas le flux.
2. Attribuez les rôles site par site plutôt qu’à tout l’espace de travail, et mettez dans un groupe les personnes qui touchent à tous les clients. Le développeur du client reçoit Viewer sur son site, et rien d’autre.
3. Dès Business, définissez les règles d’alerte site par site et routez les préproductions bruyantes vers un autre canal que les tunnels de paiement en production. Laissez le délai de repos à ses 15 minutes par défaut pour qu’un déploiement donne un seul message groupé.
4. Automatisez le rapport client depuis l’API plutôt que depuis le tableau de bord. Le tableau de bord sert au tri, l’API sert au PDF que personne dans l’équipe ne veut assembler à la main.

Le verdict n’est pas serré. S’il vous faut de nombreux sites, chacun avec sa politique, ses rapports, ses rôles et ses alertes, sous un seul login et une seule facture, CentralCSP est le seul des trois à traiter ce besoin comme le cas normal plutôt que comme une exception Enterprise ou un tas de rapports bruts.