---
title: "Checklist PCI DSS pour startups"
slug: "pci-dss-compliance-checklist-startups"
url: "https://mvp-development.io/fr/blog/pci-dss-compliance-checklist-startups"
type: post
lang: fr
date: "2026-05-21"
last_modified: "2026-05-21"
version: "1.0"
summary: "Checklist PCI DSS pour startups fintech : 12 exigences simplifiées, types de SAQ expliqués, réduction du scope et nouveautés de PCI DSS 4.0 à connaître."
author: "MVP Development"
tags: ["checklist conformité pci dss", "à qui s'applique le pci dss", "qu'est-ce que le cde en pci dss", "pci dss 4.0", "logiciel de conformité pci dss", "saq", "réduire le scope pci"]
use:
  training: allow
  rag: allow
  embedding: allow
attribution: required
---

# Checklist PCI DSS pour startups

Tous les fondateurs fintech finissent par se poser la question : faut-il vraiment se soucier du PCI DSS, ou est-ce le problème de quelqu'un d'autre une fois qu'on utilise Stripe ? La réponse honnête se situe entre les deux. Si votre application touche aux données de carte, même via une passerelle validée PCI, le PCI DSS s'applique à vous. Attendre qu'un partenaire bancaire pose la question, c'est la meilleure façon de tout gérer dans l'urgence, quelques semaines avant le lancement.

Ce guide présente une checklist PCI DSS concrète : à qui elle s'applique, ce que signifient les 12 exigences, comment fonctionnent les types de SAQ, et ce qui a changé avec PCI DSS 4.0. Rien ne remplace un Qualified Security Assessor pour une validation formelle, mais ce guide devrait vous en apprendre bien plus qu'une page marketing d'éditeur.

## Qu'est-ce que le PCI DSS

PCI DSS signifie Payment Card Industry Data Security Standard : un ensemble d'exigences conçues pour protéger les données de titulaires de carte, maintenu par le PCI Security Standards Council (fondé par Visa, Mastercard, American Express, Discover et JCB en 2006).

Voici ce qui surprend la plupart des fondateurs : le PCI DSS est une obligation contractuelle, pas une loi. Elle est inscrite dans les accords que vous signez avec votre banque, votre processeur ou votre passerelle de paiement. Ne pas s'y conformer expose à des amendes des réseaux de cartes, à des frais de traitement plus élevés ou, dans le pire des cas, à la perte du droit d'accepter les cartes.

La norme s'applique à votre environnement de données de titulaires de carte, ou CDE : les personnes, les processus et les technologies qui stockent, traitent ou transmettent des données de titulaires de carte, ainsi que tout ce qui y est suffisamment connecté pour affecter leur sécurité.

## À qui s'applique le PCI DSS

Le PCI DSS s'applique à toute organisation qui stocke, traite ou transmet des données de titulaires de carte, ou qui pourrait affecter la sécurité d'un environnement de données de titulaires de carte. Le filet est volontairement large : marchands, processeurs, passerelles et éditeurs de logiciels dont le produit touche aux données de carte à un moment ou un autre en font tous partie.

La taille ne vous exempte pas : une startup de deux personnes qui traite ses cent premières transactions via Stripe entre dans le périmètre dès qu'un vrai numéro de carte circule dans son système. La taille et le volume changent la façon dont vous prouvez votre conformité, ce qu'on aborde juste après.

Si vous cadrez déjà les [exigences KYC et AML](https://mvp-development.io/blog/kyc-aml-compliance-fintech-mvp) pour un MVP fintech, le PCI DSS est le chantier parallèle pour les données de carte. Les deux sujets surgissent en général dans la même conversation avec un partenaire bancaire, ou dans une planification plus large de [développement logiciel fintech](https://mvp-development.io/fintech).

## Les niveaux de conformité et les types de SAQ

Les réseaux de cartes répartissent les marchands en quatre niveaux de conformité, principalement selon le volume annuel de transactions (les seuils varient légèrement d'un réseau à l'autre). Le niveau 1 correspond aux marchands qui dépassent six millions de transactions par an, ou à ceux qui ont déjà subi une violation de données. Le niveau 2 va d'un à six millions, le niveau 3 couvre vingt mille à un million de transactions e-commerce, et le niveau 4 regroupe tout le reste. Presque toutes les startups démarrent au niveau 4.

Ce que vous devez faire pour prouver votre conformité dépend de votre niveau. Les marchands de niveau 1 ont généralement besoin d'une évaluation annuelle sur site réalisée par un Qualified Security Assessor (QSA). Tous les autres procèdent en général à une auto-évaluation via un Self-Assessment Questionnaire, ou SAQ : une série de questions fermées, oui ou non, associées aux exigences qui correspondent à votre configuration.

Le SAQ à remplir dépend de la façon dont les données de carte vous parviennent, pas de votre secteur d'activité ou de votre effectif. Il existe aussi quelques types plus spécifiques (B, B-IP, C, P2PE) ; le tableau ci-dessous couvre ce que rencontrent la plupart des startups.

### Les types de SAQ en un coup d'œil

| Type de SAQ | Pour qui | Ce que ça implique pour vous |
| --- | --- | --- |
| SAQ A | Paiement entièrement externalisé et hébergé ; les données de carte ne touchent jamais vos serveurs | Le questionnaire le plus court ; l'objectif visé par la plupart des startups |
| SAQ A-EP | Paiement partiellement hébergé, mais votre code touche encore la page de paiement | Un contrôle renforcé, avec des protections contre les altérations |
| SAQ C-VT | Transactions saisies manuellement via un terminal virtuel, sans stockage | Fréquent pour les remboursements gérés par téléphone |
| SAQ D (Marchand) | Ne correspond à aucune catégorie plus restreinte, ou stocke directement les données de carte | Le questionnaire le plus long ; les 12 catégories dans leur intégralité |

Un test rapide : si vous n'avez jamais saisi le numéro de carte d'un client ailleurs que dans un champ hébergé par la passerelle, vous êtes probablement dans le périmètre du SAQ A. Dès que votre propre code touche ou stocke un numéro de carte en clair, votre scope grimpe d'un cran. Vérifiez quel SAQ s'applique réellement, ne partez pas du principe que c'est forcément le plus simple.

## La checklist PCI DSS (12 exigences simplifiées)

Une fois le jargon juridique retiré, la checklist PCI DSS se résume à douze exigences réparties en six objectifs. Vous n'implémenterez pas personnellement les douze : une bonne partie revient à votre passerelle, votre fournisseur cloud ou votre partenaire BaaS. Connaissez quand même ce que chacune exige. « Notre prestataire s'en occupe » ne tient que jusqu'au jour où on vous demande de le prouver.

### Les 12 exigences PCI DSS, simplifiées

| # | Exigence | Ce que ça signifie concrètement |
| --- | --- | --- |
| 1 | Installer et maintenir des contrôles de sécurité réseau | Des pare-feux ou contrôles équivalents entre les systèmes et les réseaux non fiables |
| 2 | Appliquer des configurations sécurisées | Aucun mot de passe par défaut ni paramètre d'origine du fournisseur laissé en place |
| 3 | Protéger les données de compte stockées | Ne stockez pas les données dont vous n'avez pas besoin ; ne stockez jamais le CVV après autorisation |
| 4 | Protéger les données de titulaires de carte en transit | Un chiffrement fort pour les données de carte qui traversent des réseaux publics |
| 5 | Se protéger contre les malwares | Des outils anti-malware sur les systèmes susceptibles d'être touchés |
| 6 | Développer et maintenir des systèmes et logiciels sécurisés | Application des correctifs, code sécurisé et gestion des changements pour le CDE |
| 7 | Restreindre l'accès selon le besoin d'en connaître | Un accès limité à ce que chaque rôle exige réellement |
| 8 | Identifier les utilisateurs et authentifier les accès | Des identifiants uniques et une authentification multifacteur pour accéder au CDE |
| 9 | Restreindre l'accès physique | Des contrôles physiques autour du matériel qui traite les données de carte |
| 10 | Journaliser et surveiller les accès | Des journaux d'audit couvrant l'accès aux données de carte, conservés et examinés |
| 11 | Tester régulièrement la sécurité | Des scans de vulnérabilités et, le cas échéant, des scans ASV trimestriels |
| 12 | Soutenir l'ensemble par des politiques organisationnelles | Une politique de sécurité documentée et une analyse de risque formelle |

## Réduire le scope PCI (tokenisation, champs hébergés)

Le levier le plus rapide pour réduire le scope PCI : ne jamais laisser les données de carte en clair toucher vos propres serveurs. Les champs hébergés (une iframe ou une redirection contrôlée par la passerelle) et la tokenisation font exactement ça. Le numéro de carte du client part directement vers la passerelle ; votre backend ne voit qu'un token, inutilisable pour quiconque le volerait.

Bien fait, ça vous fait passer du questionnaire le plus lourd, le SAQ D, au plus court, le SAQ A. On détaille ce mécanisme, tokenisation comprise, dans notre [guide d'intégration de passerelle de paiement](https://mvp-development.io/blog/payment-gateway-integration-guide).

La réduction de scope a ses limites. La segmentation réseau reste importante même avec un paiement hébergé ; un réseau mal segmenté peut réintégrer des systèmes sans rapport dans le périmètre. Externaliser le paiement n'externalise pas tout : un outil de remboursement ou un tableur contenant un numéro de carte collé peut discrètement annuler ce bénéfice.

## Ce qui a changé avec PCI DSS 4.0

La version 3.2.1 du PCI DSS a pris fin en mars 2024. Si un prestataire ou un vieil article de blog en parle encore, c'est le signe que le conseil est dépassé. La version en vigueur est la 4.0.1, une mise à jour de clarification de la 4.0, et toutes les exigences sont désormais obligatoires, y compris celles qui n'étaient au départ que de « bonnes pratiques » (cette période de tolérance s'est terminée le 31 mars 2025).

Quelques changements comptent plus que les autres pour une startup. L'authentification multifacteur s'applique désormais à tout accès à l'environnement de données de titulaires de carte, bien au-delà du seul accès distant ou administrateur, et la longueur minimale des mots de passe est passée de sept à douze caractères. Vous gérez un paiement e-commerce ? Les nouvelles exigences sur la gestion des scripts côté client et la protection contre l'altération des pages de paiement, pensées contre les attaques de skimming JavaScript, méritent votre attention, même derrière une passerelle hébergée.

La norme introduit aussi une « approche personnalisée » pour répondre aux exigences autrement, appuyée sur une analyse de risque documentée. Flexible sur le papier, la plupart des startups s'en sortent encore mieux avec l'approche standard définie, au stade MVP.

Un logiciel de conformité ne remplira pas votre SAQ à votre place, mais des outils comme Vanta, Drata ou Secureframe font gagner un temps réel sur la collecte des preuves : revues d'accès et documents de politique suivis automatiquement plutôt que traqués à la main. Certains proposent désormais une revue des preuves assistée par IA pour repérer les lacunes plus vite. Utile pour les tâches répétitives, mais ça ne remplace pas le jugement d'un QSA.

## Les erreurs courantes des startups avec le PCI DSS

Une poignée d'erreurs revient sans cesse quand on cadre la pile de paiement d'un MVP fintech.

Stocker le CVV après autorisation arrive en tête de liste, en général dans un outil support conçu pour accélérer les remboursements. Le stockage du CVV n'est jamais autorisé après autorisation, chiffré ou non, un point c'est tout.

Les numéros de carte collés dans des logs, des outils de suivi d'erreurs ou un tableur partagé arrivent juste derrière, rarement de façon intentionnelle : une stack trace capture le corps brut d'une requête, ou un agent colle un numéro dans un fil de discussion pour dépanner un paiement refusé.

Supposer qu'une passerelle validée PCI vous rend automatiquement conforme est une autre erreur fréquente. Ça réduit le scope de façon significative, un vrai bénéfice, mais vous devez quand même remplir le SAQ correspondant et l'attester.

Il y a aussi le scope creep : un CDE qui démarre propre et qui, quelques mois plus tard, partage son réseau avec la moitié des outils de l'entreprise parce que personne n'a tracé de frontière.

Pour les pratiques de sécurité plus larges autour de tout ça, consultez notre [guide sécurité et scalabilité MVP](https://mvp-development.io/blog/mvp-security-scalability-guide).

Une erreur qu'on voit souvent : une équipe part du principe que son SAQ n'a besoin d'être revu qu'une fois par an, au renouvellement. C'est en réalité un document vivant. Ajoutez un outil de remboursement, changez de passerelle, ou laissez un prestataire externe toucher au CDE sans mettre à jour qui en est responsable, et votre environnement s'est déjà éloigné de ce que vous aviez attesté.

## Les priorités PCI au stade MVP

Toutes les exigences ne méritent pas la même attention dès le premier jour. Si vous cadrez les paiements d'un MVP fintech, voici à peu près où concentrer votre temps limité en priorité :

- **Faites transiter toutes les données de carte par des champs hébergés ou une redirection dès le premier jour.** Corriger ça après que votre propre code a touché des numéros en clair coûte bien plus cher que de bien le construire dès le départ.
- Confirmez quel SAQ s'applique avant que votre partenaire bancaire ne le demande.
- **Fixez dès maintenant une base commune de MFA et de mots de passe à l'échelle de l'organisation**, même à trois personnes. Peu coûteux tôt, coûteux à ajouter après coup.
- Gardez les données de carte hors des logs, des outils support et des tableurs : une règle stricte dès la première ligne de code de paiement.
- **Documentez la frontière de votre CDE**, même s'il ne s'agit que d'un simple schéma.
- Revoyez le scope chaque fois qu'une fonctionnalité touche aux paiements différemment : abonnements, versements ou remboursements manuels l'élargissent tous discrètement.
- Mettez en place une relation avec un QSA avant d'en avoir besoin, surtout si votre croissance pourrait vous rapprocher du niveau 1.

Réussissez les trois premiers points et le reste devient nettement plus simple.

## FAQ

**Le PCI DSS s'applique-t-il à une startup qui n'a pas encore traité la moindre transaction ?**

Pas encore, dans la pratique. Les obligations démarrent dès que de vraies données de titulaires de carte commencent à circuler dans vos systèmes, même en bêta limitée. La plupart des startups s'en sortent quand même mieux en concevant leur conformité avant la première transaction plutôt qu'en corrigeant après coup un tunnel de paiement construit sans penser au PCI DSS.

**Qu'est-ce qui compte exactement dans le CDE si j'utilise une passerelle hébergée ?**

Un pipeline CI/CD qui déploie votre tunnel de paiement, un tableau de bord de remboursement, ou l'ordinateur portable d'un prestataire utilisé pour déboguer un paiement refusé peuvent tous entrer dans le scope, alors qu'aucun d'eux n'héberge de numéro de carte. Tout ce qui peut affecter la sécurité des systèmes qui en hébergent compte aussi. Une passerelle hébergée réduit cette surface sans l'effacer complètement.

**Mon QSA a mentionné des exigences de la version 3.2.1 dans un vieux document. Faut-il s'inquiéter ?**

Ça vaut le coup de vérifier, oui. Cette version a pris fin en mars 2024, donc toute évaluation qui la mentionne encore est dépassée. Ça ne veut pas forcément dire que le conseil est faux : une bonne partie des contrôles fondamentaux a été reprise dans la version 4.0, avec seulement des changements mineurs de formulation.

**Que faut-il vraiment rechercher dans un logiciel de conformité PCI DSS ?**

Évitez tout outil qui promet de vous rendre « automatiquement conforme ». Aucun logiciel ne fait ça. Ce qui compte davantage : est-ce que l'outil correspond au SAQ précis que vous remplissez, et fait-il la différence entre des outils de sécurité génériques et l'accréditation Approved Scanning Vendor (ASV) nécessaire pour les scans externes. Confondre les deux fait perdre un temps réel aux équipes lors de leur premier cycle d'évaluation.

**Qu'est-ce qu'un SAQ, en termes simples ?**

Un dirigeant de votre entreprise le signe et le soumet à votre banque acquéreuse ou à votre processeur, selon qui l'a demandé. Cette signature vaut attestation formelle : traitez-la comme n'importe quel document que vous signeriez juridiquement. L'auto-évaluation cesse d'être suffisante une fois que vous atteignez le volume du niveau 1, où un audit mené par un QSA prend le relais.

**Quel est le moyen le plus rapide de réduire le scope PCI si on est en plein développement et qu'on touche déjà à des données de carte en clair ?**

Basculez d'abord votre tunnel de paiement vers des champs hébergés ou une redirection. C'est un refactoring plus lourd en plein développement, mais ça reste plus rapide que de sécuriser un CDE géré en interne jusqu'aux standards du SAQ D. Chaque semaine passée sur une gestion maison des données de carte est une semaine qui n'est pas passée sur le produit.

**Faut-il engager un QSA si je me contente de remplir une auto-évaluation ?**

Ce n'est pas requis pour la plupart des types de SAQ : seuls les marchands de niveau 1 ont besoin d'une évaluation menée par un QSA. Cela dit, quelques heures d'un QSA pour revoir votre configuration avant de vous auto-attester restent un bon investissement, surtout pour un premier SAQ.

**Que se passe-t-il concrètement si une startup subit une violation de données et se révèle non conforme au PCI DSS ?**

Ça varie selon la gravité et la façon dont la violation s'est produite, donc méfiez-vous de tout chiffre précis trouvé en ligne. Attendez-vous à des amendes des réseaux de cartes transmises via votre banque, proportionnelles au volume et à l'ampleur du manquement, à des frais de traitement plus élevés, et à un vrai risque de perdre le droit de traiter des cartes si l'écart était sérieux ou si vous aviez déjà attesté faussement. Le coût le plus lourd reste souvent le moins visible : notification de la violation, investigation forensique et heures de fondateurs consacrées aux conséquences plutôt qu'au produit. Prévenir coûte nettement moins cher.