# Règles de justification (/fr/docs/platform/features/pci-dss/justification-rules)





Une règle de justification justifie tout script dont l'URL correspond à un motif, pour que les approbations de routine ne consomment pas de temps de revue. Utilisez-les pour votre propre origine et pour les prestataires que vous avez déjà validés.

Nécessite le rôle **Manager** sur le site.

## Ajouter une règle [#ajouter-une-règle]

**PCI DSS** > **Règles de justification** > **Ajouter une règle**. Quatre champs :

| Champ                 | Notes                                                                                           |
| --------------------- | ----------------------------------------------------------------------------------------------- |
| Nom                   | Un libellé, par exemple `Prestataire de paiement approuvé`                                      |
| Motif d'URL de script | `*` est le seul joker, il correspond à n'importe quels caractères y compris les barres obliques |
| Justification         | Obligatoire. C'est ce texte que lit un évaluateur                                               |
| Tags                  | Facultatif, appliqués à chaque script capté par la règle                                        |

```text
https://js.stripe.com/*
```

Écrivez la justification comme une raison métier. « Tokenisation de carte pour le paiement, contrat revu en 2026-03 » est une preuve, « de confiance » n'en est pas une.

Jusqu'à **200 règles par site web**.

<img alt="La liste des règles de justification dans leur ordre de création, chaque règle montrant son motif d'URL, sa justification écrite et son étiquette, la dernière règle désactivée" src="__img0" width="1237" height="365" />

## Les motifs doivent correspondre à l'URL entière [#les-motifs-doivent-correspondre-à-lurl-entière]

Même syntaxe que les pages de paiement, et le même piège : le motif est ancré, il doit donc correspondre à l'URL de script entière.

`https://*.stripe.com/*` correspond à `https://js.stripe.com/v3/`. Un simple `stripe.com` ne correspond à rien du tout.

## Les règles s'appliquent rétroactivement [#les-règles-sappliquent-rétroactivement]

Créer ou modifier une règle reconstruit l'inventaire immédiatement, et la règle justifie les **scripts déjà présents dans l'inventaire**, pas seulement ceux détectés plus tard.

C'est ce qui rend les règles utiles à écrire en premier. Ajoutez vos règles avant de commencer la revue à la main, et la liste manuelle sera ce qui reste.

## Priorité [#priorité]

Les règles sont évaluées dans l'ordre de création, de la plus ancienne à la plus récente, et **la première correspondance gagne**. Les règles suivantes ne sont pas évaluées. L'interface n'offre aucun contrôle de priorité, donc si deux règles peuvent capter le même script, c'est la plus ancienne qui s'applique.

Ce qu'une règle écrase et ce qu'elle n'écrase pas :

| État du script                        | La règle s'applique ?                |
| ------------------------------------- | ------------------------------------ |
| Unreviewed                            | Oui                                  |
| Needs review, hash modifié            | Oui                                  |
| Justifié à la main, hash inchangé     | Non, votre formulation est conservée |
| Justifié à la main, puis hash modifié | **Oui**, la règle prend le relais    |
| Rejected                              | Jamais                               |

<Callout type="warn" title="Un changement de hash confie une justification manuelle à une règle">
  Quand un script justifié à la main change de hash, une règle correspondante le reprend à son compte : la justification de la règle remplace la vôtre et l'enregistrement cesse de vous nommer comme relecteur. Si un script précis doit recevoir une décision humaine à chaque changement, assurez-vous qu'aucun motif de règle ne le couvre.
</Callout>

Le rejet est le seul absolu. Un script que vous avez marqué comme rejeté n'est jamais rejustifié par l'automatisation.

## Désactiver et supprimer [#désactiver-et-supprimer]

L'interrupteur **Activé** empêche une règle de capter quoi que ce soit de nouveau. Il **ne dé-justifie pas** les scripts que la règle avait déjà justifiés. Ils gardent leur statut et leur justification jusqu'à ce que quelque chose les rende examinables à nouveau, un changement de hash par exemple.

La suppression se comporte de la même façon, et les entrées existantes restent dans le registre. Une bizarrerie : supprimer une règle ne déclenche pas de reconstruction, même si rien ne changerait de toute façon pour les scripts existants.

## Quand une règle cesse de fonctionner [#quand-une-règle-cesse-de-fonctionner]

Une règle dont le motif stocké ne compile plus est ignorée silencieusement pendant la réconciliation, et ses scripts restent non examinés. Si une règle que vous croyez active laisse des scripts dans **Action requise**, réenregistrez-la pour revalider le motif.

## Étapes suivantes [#étapes-suivantes]

* [Justifier les scripts](/fr/docs/platform/features/pci-dss/justifying-scripts)
* [Tags](/fr/docs/platform/features/pci-dss/tags)
* [Réconciliation](/fr/docs/platform/features/pci-dss/reconcile)