# Comment passer une CSP de report-only à appliquée sans casser la production

> Le runbook du passage en mode bloquant : nettoyer le flux de rapports, attendre une vraie période calme, appliquer chemin par chemin avec les deux en-têtes actifs et garder un rollback qui est un changement d’en-tête, pas un déploiement.

- Canonical: https://info.centralcsp.com/fr/articles/report-only-to-enforced-migration/
- Published: 2026-08-09
- Language: fr
- Publisher: CentralCSP (https://centralcsp.com)

Toute migration CSP bute sur le même moment délicat : renommer `Content-Security-Policy-Report-Only` en `Content-Security-Policy`. Un mot change, et le navigateur cesse d’envoyer des rapports et bloque scripts, styles et iframes sur du trafic réel. Nous avons vu des équipes rester un an en report-only parce que personne ne voulait signer ce renommage.

La version sûre est graduelle et sans panache : nettoyez d’abord le flux de violations, attendez qu’il reste plat sur une période représentative, puis appliquez chemin par chemin, en gardant les deux en-têtes actifs (la politique appliquée, plus une candidate plus stricte en report-only). Le rollback est un changement d’en-tête, pas un déploiement. Voilà la stratégie, la suite est le runbook.

## Étape 1 : nettoyer le flux de rapports

Une politique appliquée bloque exactement ce que le report-only signalait. Chaque violation du flux est donc soit une panne future, soit du bruit à classer avant qu’il n’en masque une.

Les violations légitimes se corrigent à la source : le gestionnaire inline ajouté en 2019, le tag analytics déployé sans prévenir par le marketing. Traitez-les maintenant, tant que ce ne sont que des avertissements.

Reste le bruit. Les extensions navigateur injectent des scripts dans les pages de vos utilisateurs, et ces injections remontent comme des violations de votre politique. Ce n’est pas votre bug, et cela ne s’arrêtera jamais : vous ne contrôlez pas les navigateurs de vos visiteurs. Apprenez à les reconnaître (origines `chrome-extension://` ou `moz-extension://`, URL de scripts absentes de vos serveurs) et excluez-les de votre définition du « calme ». C’est sur ce tri qu’une plateforme de reporting gagne sa place : [CentralCSP](https://centralcsp.com/fr/platform/monitoring/) indexe le flux par directive, origine et URL pour séparer « notre checkout est cassé » de « quelqu’un utilise une extension de coupons ».

## Étape 2 : durcir jusqu’au calme plat, assez longtemps

N’attendez pas le calme avec une politique laxiste. Durcissez le report-only par itérations jusqu’à obtenir la politique que vous voulez réellement appliquer, puis attendez le plat.

Combien de temps ? Assez pour couvrir vos vrais schémas de trafic : au moins un cycle de déploiement complet, une campagne marketing si vous en faites, et le trafic périodique propre à votre produit, comme la facturation de fin de mois. Nous détaillons le choix de la fenêtre dans [combien de temps rester en report-only](/fr/articles/how-long-csp-report-only/). La réponse courte : deux à quatre semaines représentatives, pas un trimestre. Sur CentralCSP, la fenêtre de vérification va de 1 à 90 jours : « cette directive est-elle calme depuis la campagne de printemps » devient un filtre plutôt qu’un tableur.

## Étape 3 : appliquer chemin par chemin, pas sur tout le site

Votre CDN, votre reverse proxy ou votre middleware savent poser des en-têtes différents selon la route. Servez-vous-en : appliquez sur un premier chemin, gardez le report-only partout ailleurs.

Commencez là où le risque est faible et la valeur élevée : une page marketing statique sans script tiers, puis les pages authentifiées, en général moins chargées en tags tiers que les pages publiques. Le checkout et les pages de paiement passent en dernier : non que la politique y compte moins, mais vous voulez un processus déjà rodé avant qu’il ne touche au chiffre d’affaires. Le raisonnement vaut aussi application par application quand plusieurs apps vivent derrière un même domaine.

## Étape 4 : garder les deux en-têtes, le schéma à double en-tête

Le jour de l’application n’est pas celui où l’on arrête d’observer. HTTP accepte les deux en-têtes CSP sur la même réponse, évalués indépendamment :

```http
Content-Security-Policy: script-src 'self' https://js.stripe.com; report-to csp-endpoint
Content-Security-Policy-Report-Only: script-src 'nonce-{random}' 'strict-dynamic'; report-to csp-endpoint
```

L’en-tête appliqué est votre politique validée. Le report-only porte la candidate plus stricte de l’itération suivante : moins d’hôtes autorisés, des nonces plutôt qu’une liste d’hôtes. La candidate accumule des preuves face au trafic de production pendant que la politique appliquée le protège. Quand elle s’aplatit, elle est promue, et vous en rédigez une nouvelle.

Construire cette candidate, c’est le rôle du [Builder de CentralCSP](https://centralcsp.com/fr/platform/csp-builder/) : une politique assemblée depuis 1 à 90 jours de rapports réels, avec les violations qui justifient chaque valeur. (Attention à `upgrade-insecure-requests` : elle ne fait rien en report-only, gardez-la dans l’en-tête appliqué. Détails dans [notre article sur cet avertissement console](/fr/articles/csp-upgrade-insecure-requests-ignored-report-only/).)

## Étape 5 : lire le champ disposition

Avec deux en-têtes qui rapportent au même endpoint, il faut savoir lequel a déclenché. Les rapports de violation portent un champ `disposition` : `enforce` pour l’en-tête bloquant, `report` pour le report-only.

Après la bascule, ce champ est votre tableau de bord. Les rapports `enforce` : des utilisateurs bloqués en ce moment, donc des incidents. Les rapports `report` : la candidate qui fait son travail, donc du backlog. Un outillage incapable de séparer les deux finira par ignorer les deux.

## Étape 6 : le rollback est un changement d’en-tête

Avant d’appliquer quoi que ce soit, une question : en combien de temps pouvez-vous repasser l’en-tête en report-only et qui peut le faire à 2 heures du matin ? La bonne réponse est « quelques minutes, via la config CDN ou proxy », pas « quand le pipeline aura fini ». Si l’en-tête est enfoui dans le code applicatif avec un build de 40 minutes, déplacez-le vers l’edge d’abord. C’est l’assurance la moins chère de toute la migration.

## Ce qui casse vraiment au moment de l’application

Quatre causes couvrent l’essentiel des incidents.

Le HTML en cache est la plus sournoise. Des pages mises en cache avant la bascule portent d’anciens nonces, ou référencent un script que la politique finale a retiré. Le report-only était calme parce que politique et HTML étaient déployés ensemble. Le cache brise cet appariement. Purgez, ou baissez les TTL du HTML avant de basculer.

Les extensions continuent d’injecter leurs scripts, exactement comme avant. Les utilisateurs accusent votre site. Rien n’est cassé chez vous.

Les scripts propres à certains chemins sont l’angle mort du report-only : un widget de paiement ou un tag analytics qui ne se charge que sur des routes peu visitées pendant l’observation. D’où l’application chemin par chemin de l’étape 3.

Les outils d’A/B testing injectent des scripts différents selon la variante, parfois inline. Une variante lancée après votre période calme est du code que votre politique n’a jamais vu. D’où l’intérêt de garder l’alerting actif après l’application : à partir du plan Business, CentralCSP peut [alerter](https://centralcsp.com/fr/platform/alerting/) sur toute nouvelle origine de script dans le flux, évaluée à l’arrivée des rapports et non selon un planning, ce qui transforme « l’expérimentation du jeudi a cassé le checkout » en message Slack ou Teams plutôt qu’en ticket support.

Appliquez un premier chemin cette semaine. Le renommage fait moins peur à chaque fois.

## Questions fréquentes

### Quand est-il sûr d’appliquer une CSP ?

Quand le flux report-only est resté plat sur une période qui couvre vos vrais schémas de trafic : au moins un cycle de déploiement complet, une campagne marketing si vous en faites, et idéalement une fin de mois si votre produit en a une. Un mardi calme ne prouve rien. Deux à quatre semaines représentatives sans violation légitime, c’est la barre habituelle.

### Peut-on envoyer Content-Security-Policy et Content-Security-Policy-Report-Only en même temps ?

Oui, et pendant une migration c’est même recommandé. Les deux en-têtes sont évalués indépendamment : l’un bloque, l’autre observe. Le schéma classique consiste à appliquer la politique validée pendant qu’une candidate plus stricte tourne en report-only, si bien que l’étape de durcissement suivante est testée en permanence sur le trafic réel.

### L’application de ma CSP a cassé mon site, que dois-je annuler ?

L’en-tête, pas le code. Renommez Content-Security-Policy en Content-Security-Policy-Report-Only à l’endroit qui le pose (CDN, reverse proxy, configuration edge) et le site refonctionne en quelques secondes, pendant que les rapports continuent d’arriver pour vous montrer ce qui a été oublié. Si votre seul moyen de changer un en-tête de réponse est un déploiement applicatif complet, corrigez cela avant d’appliquer quoi que ce soit.

### Pourquoi des violations apparaissent-elles seulement après l’application, alors que le report-only était calme ?

Le plus souvent, du HTML en cache. Des pages mises en cache avant la bascule portent d’anciens nonces ou référencent des scripts que la nouvelle politique n’autorise plus, et elles ne commencent à échouer que lorsque la politique bloque au lieu d’observer. Les extensions navigateur sont l’autre grand classique : elles injectent des scripts dans les pages de vos utilisateurs, elles généraient déjà des rapports, et elles continuent après la bascule, désormais avec une disposition enforce.