Conformité PCI pour les développeurs d'applications : la version courte et sans filtre

La conformité PCI (les règles de sécurité du secteur des cartes de paiement pour quiconque manipule des données de carte) est le prix à payer pour proposer l'option « accepte les cartes de crédit ». Pour faire court : si des données de carte touchent un jour au code que vous avez écrit ou aux serveurs que vous gérez, vous héritez d'une norme de sécurité comprenant des centaines de contrôles, une attestation annuelle (une déclaration formelle signée attestant de votre conformité) et des conséquences financières répercutées par votre prestataire de paiement. La version pénible de la conformité PCI pour les développeurs : la plupart le découvrent une fois le passage en caisse déjà codé.

Une remarque avant d'entrer dans les détails. Les numéros de version, dates et règles relatives aux questionnaires ci-dessous sont exacts à la date de publication ; la norme évoluant, considérez ces informations comme une photographie à un instant T.

Qu'est-ce que la conformité PCI, au juste ?

PCI DSS (Payment Card Industry Data Security Standard) est une obligation contractuelle, pas une loi. Les réseaux de cartes l'imposent aux banques et aux prestataires de paiement, qui l'imposent à leur tour aux commerçants et aux logiciels qu'ils utilisent. La version actuelle est la 4.0.1, et la dernière vague de ses nouvelles exigences est devenue obligatoire le 31 mars 2025¹. La norme couvre 12 familles d'exigences, de la sécurité réseau au chiffrement, en passant par le contrôle d'accès et la journalisation, qui se subdivisent en plusieurs centaines de contrôles individuels².

Aucun organisme de réglementation ne viendra frapper à votre porte. Les conséquences sont d'ordre commercial : amandes répercutées par votre banque acquéreuse (la banque qui traite les paiements par carte pour un commerçant), frais de traitement plus élevés et, dans le pire des cas, perte de la capacité d'accepter les cartes. En cas de fuite de données, les frais d'expertise judiciaire et de réémission des cartes suivent le même chemin.

Pourquoi l'ajout de la fonction « paiement » fait-il basculer toute votre application dans le périmètre PCI ?

Le périmètre (scope) fait toute la différence. La norme PCI DSS s'applique à tout système qui stocke, traite ou transmet des données de porteurs de carte, ainsi qu'à tout ce qui y est connecté. L'évaluation fonctionne comme une échelle, où chaque échelon est considérablement plus lourd que le précédent² :

• SAQ A (Auto-questionnaire A) : les paiements sont entièrement sous-traités à un prestataire conforme et les données de carte ne touchent jamais vos systèmes. C'est le questionnaire le plus court.

• SAQ A-EP : votre site ne touche jamais aux données bancaires, mais contrôle la manière dont les clients accèdent au formulaire de paiement. Une part importante de la norme complète s'applique désormais à vos serveurs web.

• SAQ D : les données de carte transitent par votre code, même brièvement, même sans être stockées. Cela implique dans les faits la quasi-totalité de la norme, documentée et attestée chaque année.

Le premier échelon n'est pas insignifiant pour autant. En janvier 2025, le PCI Security Standards Council a retiré les exigences relatives aux scripts sur les pages de paiement du SAQ A, mais a ajouté une condition d'éligibilité : vous devez confirmer que votre site n'est pas vulnérable aux attaques par script pouvant affecter votre système d'e-commerce¹. Même le niveau entièrement sous-traité exige que vous sécurisiez la page qui héberge le formulaire de paiement d'un tiers.

Au-delà de six millions de transactions par carte par an, l'auto-évaluation prend fin et laisse place à un audit sur site réalisé par un QSA (un auditeur externe certifié)².

Pouvez-vous contourner par le code les contraintes du paiement de proximité ?

Non. Pour les paiements en personne, l'échelle devient un mur. Les transactions physiques (carte présente) nécessitent du matériel certifié : des lecteurs physiques ayant validé le programme de laboratoire PTS du Conseil, exécutant un firmware approuvé et configurés via un prestataire de paiement. Transformer un smartphone en lecteur uniquement par logiciel relève d'une autre norme, Mobile Payments on COTS (MPoC), qui certifie le fournisseur de la solution, pas votre propre développement.

C'est une limite que la génération de code par IA ne peut pas franchir. Un modèle peut générer un écran d'encaissement convaincant en un après-midi ; les articles Peut-on créer un POS avec Lovable ou Replit ? et Vibe coding d'un point de vente décrivent où ces projets bloquent. Aucun code généré ne fournit un lecteur certifié, un contrat d'affiliation bancaire ni une attestation de conformité, peu importe combien de temps le modèle code sans supervision. La conformité est d'ailleurs une raison récurrente pour laquelle les applications de paiement codées au feeling se font rejeter de l'App Store.

Comment les développeurs réduisent-ils concrètement le périmètre PCI ?

Il ne s'agit pas d'en faire plus pour la conformité, mais de concevoir une architecture avec moins d'éléments soumis à contrôle :

• Ne laissez jamais un PAN (le numéro de carte principal) toucher votre code. Utilisez les champs de paiement hébergés de votre prestataire pour que les données circulent directement du navigateur du client vers le prestataire.

• Stockez des jetons (tokens), pas des cartes. La tokenisation (remplacer le numéro de carte par une chaîne de référence inutilisable en cas de vol) évite que les cartes enregistrées et les remboursements ne font basculer votre base de données dans le périmètre PCI.

• Pour les ventes physiques, utilisez des lecteurs certifiés fournis par votre prestataire afin que les données transitent du lecteur vers le prestataire sans passer par votre application.

• Gardez la page de paiement la plus simple possible. Chaque script tiers ajouté devient un élément supplémentaire que vous devez justifier.

Si c'est bien fait, votre application orchestre la vente sans jamais détenir de données bancaires, et le questionnaire reste très court. Si c'est mal fait, une simple fonctionnalité de confort (« journaliser l'intégralité du corps de la requête ») vous fait basculer discrètement vers le SAQ D.

Alors, à quel point la conformité PCI est-elle pénible pour les développeurs ?

Pénible proportionnellement au volume de données bancaires qui touchent votre code, c'est pourquoi la meilleure stratégie consiste à n'en toucher aucune. La norme ne se soucie pas de savoir si une équipe de développeurs a écrit votre application ou si une IA l'a générée en un après-midi : le périmètre reste le périmètre. Avant de déployer la moindre fonction acceptant les cartes, posez-vous une question : un numéro de carte peut-il transiter par le code que j'ai écrit ? Si oui, prévoyez le budget pour un audit. Si non, ne changez rien.

C'est également ainsi que Final aborde cette architecture. Un passage en caisse conçu sur Final, qu'il soit généré dans Build ou créé par votre propre IA via MCP, traite ses paiements via Final Pay : un prestataire de paiement et des terminaux matériels certifiés gèrent les données bancaires, de sorte que le flux lui-même ne détient jamais de numéro de carte. La page Où Final Pay est-il disponible ? en détaille les aspects pratiques, et l'article Connecter le Tap to Pay à un flux POS IA montre ce qu'implique l'acceptation des cartes lorsque la couche de conformité est déjà intégrée.