Skip to main content
Blog
Blog security

Qu'est-ce qu'un Approved Scanning Vendor (ASV) ? Les scans ASV PCI expliqués

Un Approved Scanning Vendor (ASV) est une entreprise certifiée par le PCI Security Standards Council pour exécuter les scans externes de vulnérabilités que l'exigence 11.3.2 de PCI DSS impose chaque trimestre. Ce guide explique ce que couvre un scan ASV, en quoi il diffère des scans internes et des tests d'intrusion, et ce qu'il ne peut pas voir.

Aug 18, 2026 4 min read
Qu'est-ce qu'un Approved Scanning Vendor (ASV) ? Les scans ASV PCI expliqués
Table des matières

Un Approved Scanning Vendor (ASV) est une entreprise certifiée par le PCI Security Standards Council pour réaliser les scans externes de vulnérabilités que PCI DSS exige au moins chaque trimestre. Les scans ASV sondent vos systèmes exposés à internet à la recherche de vulnérabilités connues depuis l'extérieur, et le rapport réussi fait partie des preuves de conformité que les marchands soumettent avec leur SAQ ou Report on Compliance.

En bref : le scan externe trimestriel de PCI

  • Ce que c'est : Un ASV est un prestataire certifié par le PCI SSC qui exécute les scans de vulnérabilités externes que l'exigence 11.3.2 de PCI DSS impose au moins chaque trimestre.
  • En quoi il diffère : Les scans ASV sont automatisés et menés depuis l'extérieur, contrairement aux scans internes (à l'intérieur du réseau) et aux tests d'intrusion (exploitation manuelle, au moins annuelle).
  • Son angle mort : Un scan ASV ne rend jamais votre page de paiement, si bien qu'un script de skimming injecté dans celle-ci passe chaque scan ; ce risque relève des exigences 6.4.3 et 11.6.1 de PCI DSS.

Peu de temps ? Découvrez cside PCI Shield. Il produit l'inventaire des scripts au niveau du navigateur et les preuves de détection d'altération que les scans ASV ne peuvent pas fournir.

Que vérifie réellement un scan ASV ?

Un scan ASV s'exécute depuis l'infrastructure du fournisseur contre votre empreinte publique : serveurs web, services exposés, configurations TLS, versions logicielles vulnérables connues et erreurs de configuration courantes. Le fournisseur opère selon l'ASV Program Guide du Council, qui standardise la notation, les vulnérabilités notées CVSS 4.0 ou plus font généralement échouer le scan, et impose que l'ASV atteste les résultats.

Sous PCI DSS 4.0.1, l'exigence 11.3.2 impose ces scans au moins une fois tous les trois mois et après tout changement significatif. En cas d'échec, vous remédiez et rescannez jusqu'à réussir.

Scan ASV vs scan interne vs test d'intrusion

Scan ASVScan interne de vulnérabilitésTest d'intrusion
Qui l'exécuteFournisseur certifié PCI SSCVotre équipe ou tout outil qualifiéTesteurs qualifiés (internes ou externes)
Point de vueExtérieur, exposé à internetIntérieur du réseauL'un ou l'autre, orienté objectif
MéthodeScan automatiséScan automatiséExploitation manuelle
Exigence PCI11.3.2, trimestriel11.3.1, trimestriel11.4, au moins annuel
LivrableRapport attesté réussite/échecConstats hiérarchisés à remédierRapport narratif des chemins exploités

Les trois sont des contrôles au niveau réseau et systèmes. Aucun n'exécute votre site web comme le fait le navigateur d'un client.

Ce qu'un scan ASV ne peut pas voir

Un scan ASV ne rend jamais votre page de paiement. Il ne peut pas observer le JavaScript qui s'exécute réellement dans le navigateur d'un client, précisément là où se produit l'e-skimming. Un script Magecart injecté via un tiers compromis réussit tous les scans trimestriels, car du point de vue de la bordure réseau, rien n'a changé sur vos serveurs.

Cet angle mort est la raison pour laquelle PCI DSS 4.0.1 a ajouté deux exigences au niveau du navigateur : le 6.4.3, un inventaire autorisé de chaque script des pages de paiement avec justification métier, et le 11.6.1, la détection de manipulation des en-têtes et du contenu des scripts reçus par le navigateur du consommateur. Ces exigences demandent des preuves issues de sessions réelles, pas de sondes réseau, ce que produit le PCI Shield de cside, dans le format que les QSA acceptent réellement.

Comment les pièces s'assemblent

Voyez le scan ASV trimestriel comme l'hygiène du périmètre, le test d'intrusion comme un exercice adversarial, et le 6.4.3/11.6.1 comme la protection à l'exécution de la page de paiement elle-même. Une posture PCI DSS 4.0.1 complète a besoin des trois couches, et le coût de chacune évolue différemment : le scan ASV est banalisé et bon marché ; les preuves au niveau du navigateur sont l'endroit où les marchands découvrent le plus souvent une lacune lors de leur première évaluation 4.0.1.

Simon Wijckmans
Founder & CEO

Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks, web security is not an enterprise-only problem.

FAQ

Frequently Asked Questions

Au moins tous les trois mois, et après tout changement significatif de l'environnement exposé à internet, selon l'exigence 11.3.2 de PCI DSS 4.0.1. Un scan en échec signifie remédier et rescanner jusqu'à obtenir un rapport réussi ; le rapport trimestriel réussi fait partie du dossier de preuves pour votre SAQ ou Report on Compliance.

Non. Un scan ASV est automatisé : il sonde les systèmes exposés à internet à la recherche de vulnérabilités connues depuis l'extérieur et il est requis chaque trimestre. Un test d'intrusion est un exercice manuel et orienté objectif où les testeurs tentent activement d'exploiter les faiblesses, requis au moins une fois par an au titre de l'exigence 11.4. Les deux sont requis pour la plupart des marchands ; réussir l'un ne remplace pas l'autre.

Non. C'est la lacune la plus courante. Les scans ASV regardent les services exposés et les configurations serveur depuis la bordure du réseau. Ils n'exécutent pas vos pages dans un navigateur : un script de skimming injecté dans votre paiement leur est invisible. Ce risque est couvert par les exigences 6.4.3 (inventaire et autorisation des scripts) et 11.6.1 (détection de manipulation) de PCI DSS, qui demandent des preuves au niveau du navigateur.

Surveillez et sécurisez vos scripts tiers

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Commencez gratuitement, ou essayez Business avec un essai de 14 jours.

Interface du tableau de bord cside affichant la surveillance des scripts et les analyses de sécurité
Related Articles
Réserver une démonstration

Envie de passer tout ça en revue avec un ingénieur ?

Trente minutes, sur votre propre site. Pas de slides.

Réservez une démo personnalisée pour voir :

Comment atteindre la conformité PCI DSS 6.4.3 et 11.6.1 en 1 jour
Pourquoi les scripts tiers représentent un risque de sécurité pour vous et vos visiteurs
Comment surveiller les fuites de confidentialité et de consentement (RGPD, CCPA) sur chaque tiers
Comment stopper l'abus d'inscriptions, le partage de comptes et la fraude aux rétrofacturations grâce au device intelligence
Comment détecter et contrôler les agents IA et les bots qui atteignent votre site en temps réel

Vous préférez simplement poser une question ?

Recherche de créneaux…

Humains uniquement. On le saurait.

Un problème pour réserver ? Ouvrir le calendrier dans un nouvel onglet

Quel problème cherchez-vous à résoudre ?

Dites-le-nous en une ligne et nous reviendrons vers vous avec quelque chose d'utile, pas un discours générique.

Nous aidons souvent sur :

Voir quels scripts tiers s'exécutent sur votre site
Les preuves pour PCI DSS 6.4.3 et 11.6.1
Les bots, les agents IA et le vol de comptes

Vous préférez réserver un créneau ? Choisir un créneau