Le guide du fondateur pour la checklist de conformité PCI DSS

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.

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é.

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 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.

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.

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.

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. 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.

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.

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.

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.