Votre marque vend en ligne au Japon, souvent par l’intermédiaire d’une agence locale qui exploite le site ? Au moment d’ouvrir un compte chez un prestataire de paiement (PSP) japonais, ou chez Stripe pour un compte japonais, il vous sera demandé de remplir une déclaration sur les mesures de sécurité de votre site. Sur le marché, on l’appelle encore la « Security Checklist ».
Pour une entreprise française, le réflexe est de penser à PCI DSS et à son questionnaire d’auto-évaluation (SAQ). La démarche japonaise est voisine, mais elle ne se superpose pas. Elle s’applique aussi aux sites qui ne stockent aucune donnée de carte, elle repose sur une loi japonaise et elle porte sur une liste courte de mesures précises : accès à l’interface d’administration, tests de vulnérabilité, antivirus, protection contre les tests de cartes volées.
Cet article explique d’où vient cette déclaration, ce qu’elle contient depuis avril 2025, en quoi elle diffère d’un SAQ et ce qu’il faut vérifier avec votre agence. Il s’agit d’une présentation générale : le formulaire et les exigences exactes dépendent de votre acquéreur ou de votre PSP au Japon.
L’essentiel en trois points
- Tous les e-commerçants sont concernés, y compris ceux qui ne stockent aucune donnée de carte. Depuis avril 2025, la Credit Card Security Guideline japonaise (version 6.0) attend d’eux cinq mesures de sécurité du site, au moins une mesure contre les connexions frauduleuses et EMV 3-D Secure.
- La déclaration est le moyen de contrôle : l’acquéreur ou le PSP la demande à la signature du contrat, puis lors de ses contrôles périodiques. Si une mesure manque, l’activation des paiements par carte peut être refusée. En dernier recours, le contrat peut être résilié.
- Ce n’est pas un SAQ PCI DSS : un site qui relève du SAQ A en Europe doit tout de même, au Japon, faire tester son application, restreindre l’accès à son interface d’administration et installer un antivirus sur ses serveurs.
D’où vient la « Security Checklist »
Une obligation légale, une ligne directrice sectorielle
La loi japonaise sur les ventes à tempérament (Installment Sales Act) oblige les commerçants qui acceptent la carte à gérer correctement les numéros de carte (article 35-16) et à prévenir leur usage frauduleux (article 35-17-15). La loi ne dit pas comment.
Le mode d’emploi est la Credit Card Security Guideline, rédigée par le conseil japonais pour la sécurité des transactions par carte, dont le secrétariat est assuré par la Japan Consumer Credit Association (JCA). Le ministère de l’Économie, du Commerce et de l’Industrie (METI) la désigne, dans ses principes de supervision, comme la référence pratique : appliquer ses mesures, ou des mesures au moins équivalentes, revient à remplir l’obligation légale.
Du questionnaire expérimental au formulaire de déclaration
La « Security Checklist » est née en 2021 comme document d’essai, puis a été intégrée à la ligne directrice en 2024. Depuis la version 6.0 de mars 2025, elle n’existe plus en tant que document distinct. Son contenu a été repris dans le guide de mise en œuvre des mesures de sécurité pour les e-commerçants (annexe 20 de la ligne directrice). Un formulaire type a été ajouté pour la déclaration : la « déclaration de l’état de mise en œuvre des mesures de sécurité du site e-commerce ». Le nom « Security Checklist » reste toutefois d’usage courant, y compris chez certains PSP.
Le changement de fond date d’avril 2025 : les mesures de sécurité du site et la protection contre les connexions frauduleuses, qui faisaient jusque-là l’objet de déclarations à titre d’essai, sont devenues des mesures de référence au sens de la loi. La version 6.1, publiée le 11 mars 2026, n’ajoute ni ne modifie aucune mesure. Elle précise le formulaire (version 1.1) et l’accompagne d’une FAQ.
Pourquoi les sites « sans données de carte » sont visés
Pendant des années, la réponse japonaise aux fuites de données de carte a été la « non-conservation » : confier la saisie de la carte au PSP, par redirection ou par JavaScript (tokenisation), pour que les données ne passent jamais par les serveurs du commerçant. La ligne directrice constate que la plupart des fuites actuelles se produisent désormais chez des commerçants qui ont déjà adopté ce modèle. L’attaquant entre par une faille, un accès d’administration mal protégé ou un logiciel malveillant, puis modifie le site pour capter les données saisies par les clients. D’où l’obligation de sécuriser le site lui-même, que les données de carte y transitent ou non.
Ce que contient la déclaration
Le formulaire type compte deux parties. La première détermine les mesures applicables selon votre mode de vente. La seconde recueille, pour chaque mesure, une réponse « conforme » ou « non conforme ». Il demande aussi d’indiquer les sous-traitants qui mettent en œuvre les mesures à votre place, par exemple votre agence ou votre hébergeur.
1. Les mesures contre les vulnérabilités (toutes obligatoires)
Mesure | Ce qui est attendu |
|---|---|
Accès à l’interface d’administration | Restriction par adresse IP (à défaut, authentification HTTP Basic), authentification à deux facteurs ou multifacteur, verrouillage du compte après 10 échecs de connexion au maximum (seuil repris de PCI DSS v4.0.1), URL et identifiants non devinables |
Exposition des répertoires | Aucun fichier sensible dans les répertoires publics ; limitation des extensions et des fichiers téléversables |
Vulnérabilités de l’application web | Test de vulnérabilité ou test d’intrusion périodique, suivi des corrections ; mises à jour des logiciels et des extensions contre l’injection SQL et le cross-site scripting ; revue de code ou vérification du développement sécurisé si l’application est développée ou personnalisée, y compris le contrôle des saisies dans les formulaires |
Logiciels malveillants | Antivirus sur les serveurs et les postes de travail, avec mises à jour des signatures et analyses complètes régulières |
Tests de cartes (card testing, générateurs de numéros) | Au moins une mesure parmi : blocage des adresses IP suspectes (en particulier depuis l’étranger si cet accès n’est pas nécessaire), limitation des tentatives par compte, masquage du motif de refus d’autorisation, authentification du porteur (EMV 3-D Secure, SMS) |
2. Les mesures contre les connexions frauduleuses (au moins une)
Si votre site comporte des comptes clients, vous devez mettre en place au moins une mesure adaptée à chacun des trois moments à risque : la création de compte, la connexion et la modification des informations du compte. Le formulaire propose une liste : blocage des IP suspectes, authentification à deux facteurs, vérification des informations à l’inscription, limitation des tentatives de connexion, notification par e-mail ou SMS lors d’une connexion ou d’une modification, analyse comportementale, empreinte de l’appareil.
3. EMV 3-D Secure
La troisième partie porte sur EMV 3-D Secure, attendu de tous les e-commerçants depuis fin mars 2025. Les exceptions sont étroites : impossibilité technique (consoles de jeu, enceintes connectées), sites réservés à des clients identifiés (vente entre entreprises limitée aux cartes professionnelles, accès restreint), factures de services publics, impôts, assurances ou frais de scolarité. Nous les détaillons dans notre article sur EMV 3-D Secure au Japon.
Le formulaire ne pose pas de question sur la non-conservation des données de carte ni sur PCI DSS. Ces points restent pourtant des mesures de référence. Votre acquéreur ou votre PSP peut les vérifier par ailleurs.
Comment la déclaration est déposée
Au Japon, la conclusion d’un contrat d’acceptation de la carte relève d’acquéreurs enregistrés auprès du METI. La loi leur impose d’enquêter sur chaque commerçant avant de signer, puis à intervalles réguliers. Les principes de supervision du METI leur demandent d’utiliser les mesures de la ligne directrice comme critère. La déclaration est l’outil de ces contrôles :
- nouveau commerçant : vous vérifiez que toutes les mesures requises sont en place, puis vous joignez la déclaration à votre dossier de demande ;
- commerçant existant : vous la remplissez lors du contrôle périodique et, si une mesure manque, vous la corrigez avant de confirmer.
Le formulaire de la JCA n’est qu’un modèle. Chaque acquéreur ou PSP l’adapte, sur papier, en tableur ou dans son parcours d’inscription. Stripe, par exemple, pose ces questions pendant l’ouverture du compte et ne permet pas d’accepter les paiements par carte si les réponses montrent des mesures insuffisantes.
Deux précisions de la FAQ officielle comptent pour une marque étrangère. D’abord, c’est le commerçant qui déclare, pas le PSP : la sécurité du PSP couvre le traitement du paiement, pas votre site, vos comptes clients ou votre interface d’administration. Ensuite, une mesure alternative, comme un pare-feu applicatif (WAF), peut être acceptée, mais c’est l’acquéreur ou le PSP qui juge si elle est équivalente, et il peut vous demander de le justifier.
La loi ne prévoit pas d’amende contre le commerçant pour ces mesures. Le METI peut en revanche exiger des rapports et mener des inspections. L’acquéreur, de son côté, vous demande de corriger dans un délai raisonnable. Sans correction, il peut suspendre l’acceptation de la carte ou résilier le contrat.
Déclaration japonaise et SAQ PCI DSS : les différences
Si vous êtes habitué à PCI DSS v4.0.1, voici ce qui change.
Point | France et UE | Japon |
|---|---|---|
Base | PCI DSS, norme des réseaux de cartes imposée par contrat via l’acquéreur ; obligation générale de sécurité de l’article 32 du RGPD ; recommandation de la CNIL de 2018 sur les données de carte dans la vente à distance | Obligation légale (Installment Sales Act), précisée par la Credit Card Security Guideline |
Outil de déclaration | SAQ et attestation de conformité, dont le type dépend de l’intégration du paiement | Formulaire unique de déclaration, adapté par chaque acquéreur ou PSP |
Site qui délègue entièrement la page de paiement | SAQ A : questionnaire réduit. Depuis le 31 mars 2025, le commerçant doit confirmer que son site n’est pas exposé aux attaques par script susceptibles d’affecter son système e-commerce | Mêmes mesures que pour tous : cinq mesures contre les vulnérabilités, mesures contre les connexions frauduleuses, EMV 3-D Secure |
Intégration par JavaScript | Peut relever du SAQ A-EP, plus étendu, selon la manière dont la page de paiement est construite | Classée parmi les modes de « non-conservation », au même titre que la redirection |
Contenu | Sous-ensemble des 12 exigences de PCI DSS, selon le SAQ | Liste courte et ciblée, issue de l’analyse des fuites et fraudes japonaises |
Comptes clients | Non traités par PCI DSS ; relèvent de l’analyse de risque au titre du RGPD | Au moins une mesure par moment à risque : inscription, connexion, modification |
Langue et interlocuteur | Acquéreur, et parfois un évaluateur qualifié (QSA) | Acquéreur ou PSP japonais ; formulaire en japonais |
Trois conséquences pratiques.
Votre SAQ ne remplace pas la déclaration. Il peut servir de pièce justificative, mais il ne répond pas aux questions japonaises sur l’antivirus, l’exposition des répertoires ou les tests de cartes.
Le travail sur les scripts sert dans les deux cadres. La nouvelle condition du SAQ A et les mesures japonaises visent la même menace : une intrusion sur le site, suivie de la modification du parcours de paiement pour capter les données saisies. Une seule démarche, avec un inventaire des scripts, la surveillance des modifications et un accès d’administration renforcé, peut alimenter les deux dossiers.
Le RGPD pose un principe, le Japon une liste. L’article 32 du RGPD exige des mesures adaptées au risque et une procédure pour tester régulièrement leur efficacité, sans les énumérer. La ligne directrice japonaise énumère les mesures et fait vérifier leur présence par l’acquéreur.
Ce que doit vérifier une marque française au Japon
Dans beaucoup de montages, l’agence japonaise construit et exploite le site, parfois sur une plateforme open source comme EC-CUBE, que cite le guide de la JCA. La filiale ou un distributeur est le commerçant inscrit au contrat. Le siège en France, lui, ne voit souvent jamais la déclaration. Or c’est le commerçant qui en porte la responsabilité.
1. Récupérer la déclaration et savoir qui l’a remplie
Demandez une copie de la dernière déclaration envoyée à l’acquéreur ou au PSP, avec les réponses mesure par mesure, et la liste des sous-traitants qui y figure. Vérifiez qu’une réponse « conforme » correspond à une mesure réellement en place, et pas à une intention.
2. Contrôler l’interface d’administration
Restriction par IP, authentification multifacteur, verrouillage après 10 échecs au maximum, URL et identifiants non devinables. Point propre aux groupes internationaux : si les équipes en France administrent aussi le site, leurs adresses doivent figurer dans la liste autorisée. Évitez qu’un compte partagé sans second facteur serve de solution de contournement.
3. Exiger des tests de vulnérabilité et leur suivi
La ligne directrice dit « périodiquement » sans fixer de fréquence. Une pratique courante consiste à tester au moins une fois par an et après chaque modification importante, en particulier du parcours de commande ou de l’espace client. Conservez le rapport et la preuve des corrections : c’est ce qui justifie la réponse « conforme ». Si le site est personnalisé, prévoyez aussi une revue du code.
4. Vérifier les mises à jour, l’antivirus et l’hébergement
Versions de la plateforme, du thème et des extensions, application des correctifs, antivirus sur les serveurs et sur les postes qui administrent le site. Sur un hébergement mutualisé, la FAQ officielle rappelle que les mesures restent dues : vérifiez ce que prévoit le contrat de l’hébergeur.
5. Mettre le contrat de l’agence à niveau
La ligne directrice demande au commerçant qui sous-traite son site d’exiger du prestataire qu’il connaisse et applique ces mesures. Le guide de la JCA observe que les contrats-cadres couvrent souvent mal l’exploitation après la mise en ligne, comme l’application des correctifs : ces points relèvent alors de contrats particuliers. Vérifiez que le contrat couvre trois points : les mesures de sécurité dues, la réponse aux incidents et le partage des responsabilités. Pour aller plus loin sur la gestion des prestataires, voir notre article sur les attaques par la chaîne d’approvisionnement.
6. Préparer le scénario de fuite
En cas de fuite de données de carte, la ligne directrice prévoit de prévenir immédiatement l’acquéreur ou le PSP, d’isoler les systèmes, de suspendre les paiements par carte si nécessaire et de faire mener une investigation numérique. La reprise des paiements se négocie ensuite avec l’acquéreur, qui peut exiger un SAQ et des mesures correctives. La loi japonaise sur la protection des informations personnelles (APPI) peut aussi imposer une notification. Voir notre article sur la notification des fuites au Japon et au titre du RGPD.
Questions fréquentes
Q1. Notre site ne stocke aucune donnée de carte. Sommes-nous concernés ?
Oui. La FAQ officielle est explicite : les commerçants qui ont adopté la non-conservation doivent aussi mettre en œuvre les mesures et les déclarer. La non-conservation protège les données de carte stockées, mais pas votre site, qui reste la porte d’entrée des attaques actuelles.
Q2. Notre PSP ou notre agence ne peut-il pas déclarer pour nous ?
Le PSP non : sa sécurité couvre le traitement du paiement, pas votre site. Votre agence peut préparer les réponses et doit être mentionnée comme sous-traitant, mais la déclaration engage le commerçant. Certains PSP prévoient des règles particulières pour les plateformes qui gèrent les comptes de plusieurs marchands : renseignez-vous auprès du vôtre.
Q3. Nous sommes conformes à PCI DSS avec un SAQ A. Cela suffit-il ?
Non. Le SAQ A couvre un périmètre réduit, centré sur la délégation de la page de paiement. La déclaration japonaise ajoute des mesures sur l’ensemble du site : test de vulnérabilité, interface d’administration, antivirus, tests de cartes, comptes clients. Les deux démarches se complètent.
Q4. Que se passe-t-il si une mesure n’est pas en place ?
Pour un nouveau commerçant, l’activation des paiements par carte peut être refusée ou reportée. Pour un commerçant existant, l’acquéreur demande une correction dans un délai raisonnable. Sans correction, il peut suspendre l’acceptation de la carte, voire résilier le contrat. Une mesure alternative peut être proposée, mais son acceptation dépend de l’acquéreur ou du PSP.
Q5. Un scanner gratuit suffit-il pour la mesure sur les vulnérabilités ?
Un scanner automatique est un bon premier contrôle, mais il couvre mal les pages accessibles après connexion, la logique métier et les API. Pour un site qui encaisse des paiements, un test manuel réalisé par un tiers, avec un rapport et un suivi des corrections, est la preuve la plus solide face à l’acquéreur.
Parler à AEVUS
AEVUS est une entreprise de cybersécurité basée au Japon. Nous réalisons des tests de vulnérabilité d’applications web et des tests d’intrusion sur des sites marchands : parcours de paiement, espaces clients, interfaces d’administration et API. Nos rapports peuvent servir de pièce justificative pour la déclaration demandée par votre acquéreur ou votre PSP. Nous pouvons aussi vous aider à relire, avec votre agence, les réponses déjà déposées. Si votre marque exploite ou prépare un site marchand au Japon, contactez-nous.
En résumé
- La « Security Checklist » est aujourd’hui une déclaration de l’état des mesures de sécurité du site, fondée sur la Credit Card Security Guideline et exigée par les acquéreurs et les PSP au Japon.
- Depuis avril 2025 (version 6.0), tous les e-commerçants, y compris sans données de carte, doivent appliquer cinq mesures contre les vulnérabilités, au moins une mesure contre les connexions frauduleuses et EMV 3-D Secure. La version 6.1 de mars 2026 ne change pas ces mesures.
- Elle ne remplace pas un SAQ PCI DSS et n’est pas remplacée par lui : les périmètres diffèrent.
- Si une agence exploite votre site, récupérez la déclaration, vérifiez chaque réponse et adaptez le contrat de l’agence.
- Faites tester le site périodiquement et après chaque modification importante, et conservez les preuves des corrections.
Sources
- Conseil pour la sécurité des transactions par carte, Credit Card Security Guideline, version 6.1, mars 2026 (en japonais, PDF)
- Conseil pour la sécurité des transactions par carte, points de révision de la version 6.0, mars 2025 (en japonais, PDF)
- Guide de mise en œuvre des mesures de sécurité pour les e-commerçants (annexe 20), version 2.1 (en japonais, PDF)
- Annexe 20, document a : liste des mesures de sécurité pour les e-commerçants (en japonais, PDF)
- Annexe 20, document c : formulaire type de déclaration, version 1.1 (en japonais, fichier Excel)
- FAQ sur le formulaire type de déclaration, mars 2026 (en japonais, PDF)
- FAQ de la Credit Card Security Guideline, mise à jour du 4 mars 2025 (en japonais, PDF)
- METI, révision de la Credit Card Security Guideline (version 6.0), 5 mars 2025 (en japonais)
- METI, principes de supervision au titre de l’Installment Sales Act (paiement différé), septembre 2025 (en japonais, PDF)
- Stripe, Japan Security Checklist (en anglais)
- PCI SSC, mise à jour du SAQ A v4.0.1, 30 janvier 2025 (en anglais)
- PCI SSC, FAQ sur le choix entre SAQ A et SAQ A-EP (en anglais)
- Règlement (UE) 2016/679 (RGPD), article 32
- CNIL, le paiement à distance par carte bancaire (délibération n° 2018-303)
