# Justifier les scripts (/fr/docs/platform/features/pci-dss/justifying-scripts)
Chaque script du périmètre a besoin d'une décision : justifié, autrement dit il a sa place et voici pourquoi, ou rejeté, autrement dit il n'en a pas. Les deux sont consignés avec votre nom, l'horodatage, et le hash auquel la décision s'appliquait.
Nécessite le rôle **Analyste** sur le site, ou supérieur.
## Prendre une décision [#prendre-une-décision]
Parcourez la file d'examen ainsi :
1. Ouvrez **PCI DSS** > **Inventaire de scripts** puis l'onglet **Action requise**.
2. Cliquez sur un script pour ouvrir son panneau.
3. Sous **Décision de revue**, choisissez **Justifier** ou **Marquer comme rejeté**.
4. Écrivez la raison et enregistrez.
Le champ de texte est obligatoire, jusqu'à 4096 caractères. Impossible de consigner une décision sans ce texte, et c'est voulu : le texte est la preuve.
Une décision peut être révisée ensuite. Chaque révision est une nouvelle entrée de registre, pas un remplacement.
La décision se prend dans le bloc Décision de revue du panneau du script :
## Écrire des justifications utilisables par un évaluateur [#écrire-des-justifications-utilisables-par-un-évaluateur]
La justification doit expliquer pourquoi ce code a le droit de s'exécuter là où des données de carte sont saisies. Les bonnes nomment la fonction métier, le responsable, et la revue effectuée.
Bien : `Stripe.js tokenise les champs de carte. Nécessaire au paiement. Due diligence fournisseur faite en 2026-02, responsable équipe Paiements.`
Sans intérêt : `nécessaire`, `ok`, `tiers`.
Vous écrivez pour quelqu'un qui ne connaît pas votre stack et qui va en lire quelques centaines.
## Justifier, rejeter ou sortir du périmètre [#justifier-rejeter-ou-sortir-du-périmètre]
**Justifier** consigne que le script a sa place, et épingle la décision au hash actuel du script. Si le contenu servi à cette URL change plus tard, le script passe en **À réexaminer** et revient vers vous, même si une [règle d'inventaire](/fr/docs/platform/features/pci-dss/justification-rules) couvre la même URL. Une règle ne peut pas approuver un hash que vous n'avez pas lu.
**Rejeter** consigne qu'il n'a pas sa place.
Marquer un script comme rejeté est l'enregistrement de votre décision, rien de plus. Le script continue de se charger. Retirez-le de la page ou bloquez-le dans votre CSP dans une action distincte, puis confirmez qu'il cesse d'apparaître.
Le rejet est une décision humaine, et rien d'autre. Aucune règle d'inventaire ne rejette un script, et aucune ne réapprouve celui que vous avez rejeté. Une règle qui correspond à un script déjà décidé le laisse tranquille, dans un sens comme dans l'autre.
Rejeter n'est pas non plus la même chose que sortir un script du périmètre. Si le script n'est pas le vôtre du tout, une [règle Exclure](/fr/docs/platform/features/pci-dss/justification-rules) est l'enregistrement honnête, parce que rejeter affirme qu'un script non autorisé s'exécute sur votre page de paiement.
## Traiter un hash qui a changé [#traiter-un-hash-qui-a-changé]
**À réexaminer** signifie qu'un script que vous aviez justifié sert désormais un contenu différent.
Ne rejustifiez pas par réflexe. La question est de savoir si le changement était attendu :
* Votre propre bundle après un déploiement : attendu, rejustifiez.
* Un script fournisseur qui correspond à une version qu'il a annoncée : vérifiez, puis rejustifiez.
* Un script fournisseur qui change sans version correspondante : enquêtez avant de décider. C'est le cas pour lequel l'exigence existe.
L'onglet **Historique des hashes** du script donne la séquence complète des hashes avec première et dernière apparition, et c'est ainsi que vous distinguez une cadence de routine d'une anomalie.
## La piste d'historique [#la-piste-dhistorique]
La section **Historique** enregistre chaque événement sur le script :
| Événement | Signification |
| ------------------------------------------------------------ | ------------------------------------------------ |
| Script détecté | Vu pour la première fois dans le périmètre |
| Empreinte du script modifiée | Le contenu servi à cette URL a changé |
| Règle de justification appliquée | Une règle Approuver l'a justifié automatiquement |
| Exclu du périmètre par une règle | Une règle Exclure l'a sorti du périmètre PCI |
| Justification manuelle enregistrée | Une personne l'a justifié |
| Script marqué comme rejeté | Une personne l'a rejeté |
| Le script a quitté le périmètre des pages de paiement | Retiré, ne correspond plus au périmètre |
| Le script est revenu dans le périmètre des pages de paiement | De retour dans le périmètre |
Chaque entrée porte l'horodatage, qui a agi, le texte écrit, et le hash du moment. Les événements automatiques s'affichent comme tels au lieu de nommer une personne.
Le registre est **en ajout seul**. Rien dans le produit ne modifie ni ne supprime une entrée, et l'historique survit à un script qui quitte le périmètre puis y revient. Il n'est pas scellé ni signé cryptographiquement, décrivez-le donc à un évaluateur comme un journal applicatif en ajout seul plutôt que comme inaltérable.
Supprimer un utilisateur anonymise son identifiant sur les entrées passées. Les événements, eux, restent.
## Tags [#tags]
Les Managers peuvent attacher des tags pour classer les scripts, par exemple par responsable ou par catégorie de fournisseur. L'enregistrement remplace tout le jeu de tags de ce script. Voir [Tags](/fr/docs/platform/features/pci-dss/tags).
## Étapes suivantes [#étapes-suivantes]
* [Inventaire de scripts](/fr/docs/platform/features/script-inventory)
* [Export de preuves](/fr/docs/platform/features/pci-dss/evidence-export)
* [Règles d'inventaire](/fr/docs/platform/features/pci-dss/justification-rules)