# 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]
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. Il n'y a aucun moyen de consigner une décision sans lui, et c'est le but : 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.
## Écrire des justifications utilisables par un évaluateur [#écrire-des-justifications-utilisables-par-un-évaluateur]
La justification doit répondre à la question de savoir 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 ou rejeter [#justifier-ou-rejeter]
**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 **Needs review** et revient vers vous.
**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 définitif face à l'automatisation : aucune règle de justification ne rejustifiera jamais un script rejeté.
## Traiter un hash qui a changé [#traiter-un-hash-qui-a-changé]
**Needs review** 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 detected | Vu pour la première fois dans le périmètre |
| Script hash changed | Le contenu servi à cette URL a changé |
| Justification rule applied | Une règle l'a justifié automatiquement |
| Manual justification saved | Une personne l'a justifié |
| Script marked rejected | Une personne l'a rejeté |
| Script left the payment-page scope | Retiré, ne correspond plus au périmètre |
| Script returned to the payment-page scope | 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 de justification](/fr/docs/platform/features/pci-dss/justification-rules)