Stripe et RGPD : rôles, paiements et effacement

Pour encadrer Stripe, partez du parcours de paiement réellement utilisé. La conformité dépend notamment des champs transmis, des services activés, des intégrations et des demandes que votre équipe sait traiter.

Le dossier ne peut pas se limiter à « Stripe est conforme » : les responsabilités varient selon les opérations, et une suppression technique peut avoir des effets commerciaux importants sans effacer tout l’historique.

Qualifier les rôles par opération

Le DPA Stripe, version du 18 novembre 2025, prévoit à la fois des traitements comme sous-traitant et des traitements comme responsable. Ces derniers incluent notamment le choix de certains intervenants financiers, la prévention de la fraude, les obligations réglementaires et l’amélioration des produits.

Il serait donc trop simple de qualifier toute l’exécution d’un paiement de traitement exclusivement réalisé sur vos instructions. Relevez les opérations et services utilisés, puis associez-les aux stipulations applicables. Ne présumez pas non plus que toute amélioration de service porte uniquement sur des données déjà anonymes.

Votre entreprise conserve ses propres obligations : choisir une base légale, informer le client, minimiser les données et sécuriser son intégration. La qualification de responsable de traitement doit correspondre aux décisions réellement prises, pas seulement au nom du fournisseur.

Documenter les transferts réellement prévus

Le DPA indique expressément des transferts vers Stripe aux États-Unis et des opérations mondiales avec ses affiliés et prestataires. L’existence d’un cocontractant européen ne signifie donc pas que les flux restent, par principe, dans l’EEE.

L’annexe sur les transferts articule le Data Privacy Framework et les clauses contractuelles types. Vérifiez l’entité destinataire, la portée du mécanisme invoqué et les documents applicables à vos services. Le guide des transferts hors UE présente les questions à consigner.

Évitez de conclure à un « risque faible » uniquement parce qu’un numéro de carte est tokenisé. Les noms, coordonnées, descriptions d’achat et identifiants associés restent aussi à examiner.

Réduire les données de votre intégration

Constituez une liste des champs envoyés par votre application : identité, coordonnées, description de commande, identifiants et métadonnées. Chaque champ doit avoir une utilité précise.

Une métadonnée pratique pour le support peut exposer une information inutile : commentaire libre, motif détaillé d’une prestation ou extrait de dossier. Préférez un identifiant interne permettant de retrouver le dossier dans votre système autorisé plutôt que son contenu complet.

Examinez aussi les données reçues : événements webhook, journaux, exports comptables et tickets. Limitez leur circulation. Un outil de support comme Zendesk ne doit pas devenir une seconde archive de données de carte par copier-coller.

Comprendre la portée de PCI DSS

Le guide de sécurité Stripe décrit une responsabilité partagée : Stripe est audité comme prestataire PCI de niveau 1, mais le marchand doit aussi valider sa conformité selon son intégration.

Les parcours qui transmettent directement les données de carte à Stripe réduisent l’exposition de vos serveurs. Ils ne rendent pas automatiquement tout site éligible à un même questionnaire PCI et ne suppriment pas les risques provenant des scripts, comptes et pages du marchand.

Vérifiez les droits d’administration, les clés API, les connexions sécurisées et la validation des signatures webhook. Séparez les environnements et évitez que les journaux de diagnostic enregistrent les charges utiles complètes sans nécessité. Une certification ne remplace pas ces contrôles locaux.

Ne pas confondre suppression du client et effacement global

La documentation de suppression d’un objet Customer signale deux points essentiels : l’opération est irréversible et annule immédiatement les abonnements actifs associés. Elle précise également que l’objet supprimé reste récupérable pour suivre son historique.

N’utilisez donc pas cet appel comme réponse automatique à toute demande RGPD. Identifiez d’abord ce qui doit être effacé, conservé pour une obligation ou maintenu pour un contrat en cours. Coordonnez les opérations avec la facturation et les abonnements.

Préparez une fiche de réponse : données présentes chez vous, données confiées au prestataire, traitements relevant de ses propres responsabilités et justificatifs de conservation. Les exceptions à l’effacement doivent être expliquées précisément, sans promettre la disparition de tous les enregistrements.

Cas pratique : effacer une consigne sans annuler l’abonnement

Le scénario est hypothétique. Atelier Papier vend une boîte mensuelle de fournitures créatives et utilise Stripe pour le paiement récurrent. Camille demande d’effacer une ancienne consigne de livraison contenant son ancienne adresse et les coordonnées d’un proche. Elle précise qu’elle souhaite conserver son abonnement avec son adresse actuelle.

Le support retrouve cette consigne dans son application et dans une métadonnée envoyée à Stripe lors de la création du client. Elle n’est plus nécessaire à la livraison courante. La demande concerne donc un contenu identifié ; elle ne vaut pas instruction de supprimer le compte client, de résilier le service ou de détruire les factures.

La responsable distingue les données nécessaires au contrat en cours de celles devenues inutiles, au regard des Art. 5(1)(c)(e) et 6(1)(b). Elle applique l’effacement aux informations sans justification et examine séparément les exceptions de l’Art. 17(3), dans leur périmètre. La conservation comptable de certaines pièces ne permet pas de conserver indéfiniment une ancienne consigne dans chaque outil de travail.

La décision d’exécution remplie

La documentation des métadonnées Stripe décrit une suppression ciblée d’une clé. Elle rappelle aussi que les métadonnées sont attachées à des objets : certaines copies sont des instantanés, que la modification de l’objet source ne met pas à jour. L’équipe doit donc établir où sa propre intégration a inscrit la consigne. Une vérification du seul écran affiché au client ne démontre pas que toutes les copies ont été traitées.

Avant l’intervention, le développeur soumet le périmètre de l’opération à la responsable. Le raccourci initial « demande d’effacement = supprimer Customer » est écarté à la lecture de la documentation, en raison de son effet sur les abonnements. Le dossier conserve l’identifiant technique nécessaire au suivi et la clé à retirer ; il ne recopie pas la consigne complète dans un nouveau document partagé.

L’échec : la synchronisation réintroduit la note

Dans le scénario, la première vérification constate que la métadonnée n’est plus présente. Le contrôle suivant la retrouve pourtant après la synchronisation nocturne de l’application. Une ancienne table d’export, distincte du champ déjà vidé, contenait encore la consigne et l’a retransmise. Il s’agit ici d’un défaut de l’intégration fictive du marchand, pas d’un comportement attribué à Stripe sans vérification.

La responsable suspend ce flux de notes et garde le dossier ouvert. Le développeur repère la table qui alimente l’export, corrige la sélection puis traite la copie obsolète. Il ne coupe pas indistinctement les flux nécessaires au paiement : les transmissions concernées sont identifiées pour maintenir le service demandé dans le périmètre justifié.

La reprise est d’abord vérifiée avec une consigne fictive sur un compte d’essai. Le contrôle doit montrer qu’une note retirée ne réapparaît ni dans le prochain export ni après sa synchronisation. La correction est ensuite appliquée au dossier de Camille, et les contrôles prévus dans le tableau sont consignés. Aucune opération réelle sur un compte Stripe n’a été effectuée pour rédiger cet exemple.

Si l’équipe ne peut pas arrêter une retransmission, elle isole le flux concerné et demande l’assistance nécessaire, au lieu de promettre un effacement définitif. Elle informe Camille des mesures prises dans les délais de l’Art. 12(3) ; une difficulté technique ne déclenche pas automatiquement la prolongation légale. Si une partie de la demande n’est pas satisfaite, la réponse précise le motif et les voies de réclamation et de recours de l’Art. 12(4).

La réponse qui correspond au résultat

Dans la branche résolue, le support confirme le retrait de l’ancienne consigne dans les emplacements vérifiés, la correction de la synchronisation et le maintien de l’abonnement. Il précise les catégories de pièces conservées pour une obligation ou une autre justification applicable. Il ne dit pas « Stripe a effacé toutes vos données » : une telle formule dépasserait à la fois les opérations réalisées et les rôles documentés.

Cette distinction protège aussi la continuité du service. Une demande de minimisation ou d’effacement partiel peut être traitée sans imposer la disparition du compte. À l’inverse, une demande portant réellement sur la fin de la relation appelle une coordination supplémentaire avec l’abonnement, les échéances et les archives ; elle ne doit pas être déduite d’un simple mot-clé dans un ticket.

Finaliser le dossier de conformité

Conservez les documents contractuels, la carte des flux, les preuves de configuration et le responsable de chaque opération. Pour les fonctions supplémentaires, relisez leur documentation propre avant activation : vérification d’identité, abonnements, service de paiement accéléré et fiscalité n’ont pas nécessairement le même périmètre.

Une photo d’identité n’est pas automatiquement une donnée biométrique relevant de l’Art. 9 : le traitement technique et la finalité d’identification doivent être examinés. Si un service implique cette catégorie particulière, vérifiez les conditions juridiques et la nécessité d’une analyse d’impact avant utilisation.

Ce qu’il faut retenir

• Qualifiez les rôles selon les opérations, sans réduire Stripe à un sous-traitant unique.
• Le cocontractant européen n’exclut pas les transferts internationaux.
• Minimisez métadonnées, journaux et copies dans les outils connectés.
• Supprimer un Customer peut annuler des abonnements et ne signifie pas effacement de tout l’historique.

FAQ

PCI DSS suffit-il pour respecter le RGPD ?

Non. Il concerne la sécurité des données de paiement dans son périmètre. Les bases légales, l’information, la conservation et les droits restent à traiter.

Un token de paiement est-il nécessairement anonyme ?

Non. S’il reste relié à un client ou à une transaction identifiable, il demeure une donnée personnelle dans ce contexte.

Peut-on supprimer automatiquement un client après sa demande ?

Il faut d’abord examiner la demande et les effets techniques. La suppression de l’objet Customer annule notamment ses abonnements actifs ; elle doit être coordonnée avec les obligations et la relation en cours.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.