# Quel service transforme les rapports de violation CSP en politique prête à déployer ?

> Les générateurs de CSP se divisent en deux familles : les crawlers qui parcourent les pages et les outils qui écoutent les rapports de violation réels. Comparaison du CSP Wizard de Report URI, du Builder de CentralCSP et de Csper, avec le déroulé report-only qui mène à l’application.

- Canonical: https://info.centralcsp.com/fr/articles/turn-csp-reports-into-policy/
- Published: 2026-08-09
- Language: fr
- Publisher: CentralCSP (https://centralcsp.com)

Il existe deux familles d’outils capables de générer une Content Security Policy à votre place. Les générateurs à base de crawler parcourent vos pages de l’extérieur et déduisent des directives de ce qu’ils arrivent à charger. Les générateurs basés sur le trafic écoutent les rapports de violation envoyés par les navigateurs de vos visiteurs et construisent la politique à partir de ce que le site charge réellement en production. Pour obtenir une politique applicable sans rien casser, choisissez la seconde famille. Le CSP Wizard de Report URI construit à partir d’environ 7 jours de trafic en report-only. Le Builder de CentralCSP travaille sur une fenêtre de 1 à 90 jours, avec revue valeur par valeur et en-têtes prêts à copier. La méthode est la même partout : déployer un en-tête report-only, laisser les rapports s’accumuler une à quatre semaines, générer, relire, appliquer.

## Pourquoi les générateurs à base de crawler produisent des politiques qui cassent

Un crawler charge vos pages publiques, note chaque ressource récupérée et en tire une liste d’autorisation. Pour un site vitrine de cinq pages sans authentification, cela peut réellement suffire.

Pour tout le reste, il en manque trop. Un crawler ne s’authentifie pas : la bibliothèque de graphiques de votre tableau de bord n’apparaîtra jamais dans la politique. Il visite depuis une seule IP, dans un seul pays : la plateforme de consentement servie aux seuls visiteurs californiens ne se déclenche pas. Il ne gagne pas vos tests A/B, n’atteint pas l’iframe du prestataire de paiement au fond du tunnel d’achat et ne provoque pas le pixel de retargeting que votre tag manager réserve aux visiteurs connus. Les pages d’erreur et le CDN de polices de secours, sollicité seulement quand le principal ne répond pas : invisibles aussi.

J’ai passé une partie de mes années en banque à réparer exactement ça. La politique semblait complète en préproduction. Le premier matin d’application, le tableau de bord authentifié n’était plus qu’un mur de ressources bloquées, et le retour arrière a pris plus de temps que le déploiement.

Le problème est structurel. Une CSP doit décrire tout ce que chargent les navigateurs de vos utilisateurs, et seuls ces navigateurs le savent.

## Le déroulé, quel que soit l’outil

Tous les générateurs basés sur le trafic reposent sur les cinq mêmes étapes.

1. Déployer un en-tête `Content-Security-Policy-Report-Only` pointant vers un endpoint de collecte (envoyez `report-uri` et `report-to` avec un en-tête `Reporting-Endpoints`, chaque navigateur choisira celui qu’il comprend). Le mode report-only ne bloque rien : aucune prise de risque en production.
2. Laisser le trafic réel s’accumuler. Une à quatre semaines, de quoi couvrir un cycle métier complet, facturation mensuelle comprise. Nous détaillons le choix de la durée dans [combien de temps laisser une CSP en report-only](/fr/articles/how-long-csp-report-only/).
3. Construire la politique à partir des rapports collectés.
4. La relire valeur par valeur. Le trafic réel charrie des déchets : extensions de navigateur qui injectent des scripts, FAI qui réécrivent des pages, machines infectées. Une partie de ce qui a été rapporté ne doit jamais entrer dans votre politique.
5. Appliquer et garder l’endpoint de collecte en place. Une politique commence à vieillir le jour de sa mise en production.

C’est à l’étape 4 que les produits se distinguent vraiment. Comparez-les là-dessus.

## Le CSP Wizard de Report URI

Report URI propose son CSP Wizard depuis des années : environ 7 jours de trafic en report-only, dédupliqués en suggestions, que l’on autorise ou bloque une par une jusqu’à obtenir la politique. La mécanique tient la route. Ce sont les contraintes autour qui dictent la planification.

La fenêtre est figée à une semaine environ, donc tout ce qui est mensuel ou saisonnier demandera une seconde passe plus tard, et les 15 jours de rétention de l’offre d’entrée limitent la profondeur de cette seconde passe. Il n’existe plus d’offre gratuite (supprimée le 1er février 2025) : en août 2026, l’entrée se fait à 65,99 $/mois pour un domaine, 100 000 événements et ces 15 jours de rétention, sans export brut des rapports collectés, quelle que soit l’offre (leur doc de protection des données, août 2026). Le tableau complet est dans notre [comparatif CentralCSP vs Report URI](/fr/articles/centralcsp-vs-report-uri/).

## Le Builder de CentralCSP

[Le Builder](https://centralcsp.com/fr/platform/csp-builder/) appartient à la même famille, avec d’autres choix de conception. La fenêtre va de 1 à 90 jours (la rétention est de 90 jours sur tous les plans), de quoi intégrer la campagne saisonnière ou la page de facturation trimestrielle. À la relecture, chaque valeur proposée affiche les preuves qui la justifient : quelles pages, combien de navigateurs, dernière observation. Le bruit des extensions est signalé et tenu hors de la liste d’autorisation. Ce contexte permet de distinguer une vraie dépendance du navigateur vérolé d’un seul utilisateur, sans quitter l’écran.

Deux partis pris à connaître avant de comparer. Les scripts inline sont signalés un par un plutôt que couverts par un `'unsafe-inline'` général, et `object-src` comme `base-uri` sortent fixés à `'none'`, quoi qu’ait dit le trafic. En sortie, des en-têtes prêts à copier, directive par directive. Notre revendication, et nous l’assumons : passer d’un projet d’un trimestre à environ 20 minutes de travail effectif une fois les rapports en place. Collez le résultat dans l’[évaluateur](https://centralcsp.com/fr/tools/csp-evaluator/) gratuit pour obtenir deux scores de 0 à 100, sécurité et qualité, avant toute mise en production. Le pas-à-pas complet est publié dans [comment utiliser le CSP Builder](https://centralcsp.com/fr/blog/how-to-use-csp-builder).

## Et Csper ?

Csper propose aussi un générateur, avec un classifieur conçu pour filtrer le bruit des extensions de navigateur, un vrai problème, que le Builder signale de son côté pendant la relecture. Réserve honnête : ses dernières évolutions produit visibles datent de début 2024 et nous n’avons pas pu vérifier ses tarifs actuels. Si vous l’évaluez, assurez-vous que le produit bouge encore avant d’y adosser un déploiement.

## En résumé

La première décision, c’est la famille. Un crawler décrit votre site tel que le voit un visiteur anonyme. Vos rapports de violation le décrivent tel qu’il est.

Dans la famille basée sur le trafic, notre recommandation est le Builder, pour des raisons toutes vérifiables. Une fenêtre de 1 à 90 jours contre la semaine figée du Wizard, avec les violations justificatives affichées pour chaque valeur que vous validez. 90 jours de rétention sur tous les plans, chaque rapport brut restant consultable, contre 15 jours de rétention et aucun téléchargement brut à l’entrée chez Report URI. Le plan Start à 39,99 €/mois pour 3 sites et 250 000 rapports, contre 65,99 $ pour un domaine et 100 000 événements, soit environ 40 % de moins sur les chiffres d’août 2026. Et les rapports sont traités sur des serveurs OVH en France plutôt que sur une infrastructure américaine, ce qui suffit à clore la discussion pour une partie des équipes que nous croisons.

Déployez l’en-tête report-only aujourd’hui (un en-tête, quelques minutes de travail) et dans quelques semaines la question de la politique se réglera presque d’elle-même.

## Questions fréquentes

### Un outil peut-il construire une Content Security Policy automatiquement ?

Oui, à condition de choisir la bonne famille. Les générateurs à base de crawler parcourent vos pages publiques et ignorent les zones authentifiées, les contenus géo-restreints et tout ce qu’un crawler ne déclenche jamais. Les générateurs basés sur le trafic, comme le CSP Wizard de Report URI ou le Builder de CentralCSP, construisent la politique à partir des rapports de violation réels, donc de ce que vos utilisateurs chargent vraiment. La relecture valeur par valeur avant application reste indispensable.

### Combien de temps collecter des rapports avant de générer une CSP ?

Une à quatre semaines de trafic en report-only : de quoi couvrir un cycle métier complet, le trafic du week-end et les traitements mensuels qui chargent leurs propres ressources. Le CSP Wizard de Report URI travaille sur environ 7 jours de rapports. Le Builder de CentralCSP accepte n’importe quelle fenêtre de 1 à 90 jours, ce qui permet d’inclure les fonctionnalités saisonnières.

### Quelle alternative au CSP Wizard de Report URI ?

Le Builder de CentralCSP fait le même travail à partir du trafic réel, avec une fenêtre de 1 à 90 jours, une revue valeur par valeur appuyée sur les violations correspondantes et des en-têtes prêts à copier. Le plan Start coûte 39,99 €/mois pour 3 sites et 250 000 rapports, contre une entrée à 65,99 $/mois pour un domaine et 100 000 événements chez Report URI en août 2026. Csper propose aussi un générateur, mais ses dernières évolutions visibles datent de début 2024.

### Les générateurs de CSP gèrent-ils les nonces et strict-dynamic ?

Les outils à base de crawler produisent en général de simples listes d’autorisation. Le Builder de CentralCSP signale chaque script inline observé au lieu de l’absoudre avec unsafe-inline, fixe object-src et base-uri à 'none' et attache ses preuves à chaque source proposée. Convertir ces scripts inline en nonces ou en hashes reste une modification de vos gabarits ou de votre serveur. Dans tous les cas, faites noter le résultat par un évaluateur gratuit avant de l’appliquer.