Loi 09-08 et e-commerce : les données personnelles de vos clients dans un paiement en ligne
Loi 09-08 et e-commerce : les données personnelles d'un paiement en ligne, ce que vous ne recevez jamais, la metadata, les accès et le rôle de la CNDP.
Loi 09-08 et e-commerce : les données de vos clients — nom, e-mail, téléphone, historique d'achats — sont des données à caractère personnel au sens de la loi 09-08, dont la CNDP est l'autorité de contrôle. Un paiement en ligne en fait circuler quelques-unes : celles que vous transmettez pour créer une session ou un lien, celles qu'un abonnement exige. Il y en a une que vous ne recevez jamais, le numéro de carte. Ce guide fait l'inventaire, champ par champ, de ce qui passe dans un paiement, puis donne les bons réflexes — metadata sans donnée sensible, libellés neutres, accès par rôles — et les questions à poser à votre conseil.
Loi 09-08 et e-commerce : de quelles données parle-t-on ?
Les données de vos clients — nom, e-mail, téléphone, historique d'achats — sont des données à caractère personnel au sens de la loi 09-08, dont la CNDP est l'autorité de contrôle. La CNDP, Commission nationale de contrôle de la protection des données à caractère personnel, présente sur son site la loi et les démarches qu'elle encadre ; c'est la source officielle à consulter, et nous ne détaillons ici ni les obligations ni les formalités qui en découlent.
Pour une boutique en ligne, ces données ne sont pas une abstraction : elles se trouvent dans la fiche client, l'historique des commandes, les échanges WhatsApp, les exports que vous envoyez à votre comptable. Le paiement n'en est qu'une partie, mais une partie sensible, parce qu'il relie une identité à un achat et à un montant.
ChariPay est une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib ; les données personnelles sont traitées dans le cadre de la loi 09-08. Ce que fait la plateforme pour les protéger est décrit sur notre page sécurité et conformité. Ce guide porte sur l'autre moitié : ce que vous, commerçant, transmettez, recevez et conservez.
Ce qui passe dans un paiement, produit par produit
Chaque façon d'encaisser transmet un jeu de données client différent. Le tableau ci-dessous les reprend tels que l'API les définit :
| Produit | Données client transmises | Qui les saisit |
|---|---|---|
| Session de paiement (checkout hébergé) | config.customer : email, firstName, lastName, phone — requis | Vous, côté serveur, à la création de la session ; la carte, elle, est saisie par le client |
| Lien de paiement | customerName, customerEmail, customerPhone — optionnels | Vous, si vous choisissez de les renseigner ; la carte est saisie par le client |
| Abonnement | Le client (POST /v1/clients) : name requis, email — nécessaire, car c'est là que partent les liens de paiement de chaque échéance —, phone optionnel | Vous créez le client ; à chaque échéance, il saisit lui-même sa carte sur la page hébergée, avec 3-D Secure |
Trois lectures pratiques de ce tableau. Pour une session, les quatre champs client sont requis : prévoyez-les dans votre tunnel de commande, et n'y mettez que ce que le client vous a donné. Pour un lien, les champs client sont optionnels : si vous n'en avez pas besoin, ne les remplissez pas — moins de données transmises, c'est moins de données à protéger. Pour un abonnement, l'e-mail est indispensable, parce que c'est là que partent le lien de paiement de chaque échéance et les rappels ; la carte, elle, est saisie par le client sur la page hébergée, à chaque paiement, avec 3-D Secure.
Pour savoir exactement ce que vous transmettez, voyez-le : Commencer en mode test. Trois champs — nom, e-mail professionnel, entreprise —, un lien d'activation reçu par e-mail pour choisir votre mot de passe, puis le portail, où vous créez votre clé de test après une ré-authentification ; créez une session ou un lien avec des données fictives et payez avec la carte de test, sans argent réel. C'est gratuit, sans limite de durée et sans validation à attendre : la vérification de votre entreprise (KYB) ne conditionne que le passage en production.
Ce que vous ne recevez jamais : les numéros de carte
Il y a une donnée que ce tableau ne contient pas. Votre client saisit sa carte sur le checkout hébergé, dans un périmètre certifié PCI DSS niveau 1 : vous ne voyez jamais de numéro de carte, et votre questionnaire d'auto-évaluation s'en trouve réduit — à confirmer avec votre conseil ou votre acquéreur. Côté plateforme, les numéros de carte ne sont jamais écrits en base de données.
Pour vous, la conséquence est concrète : votre base clients, vos exports et vos messages n'ont aucune raison de contenir un numéro de carte. S'il en apparaît un — un client qui l'envoie par WhatsApp, par exemple —, c'est un accident à corriger, pas une donnée à garder. Les données de carte relèvent d'un cadre propre, le standard PCI DSS, traité dans PCI DSS pour les commerçants.
metadata : un identifiant, jamais une donnée sensible
Le champ metadata vous permet d'attacher vos propres informations à une session, à un lien, à un produit ou à un abonnement. C'est un objet plat — chaînes, nombres, booléens, sans objet imbriqué ni tableau — de 4 Ko au plus, renvoyé tel quel sur les lectures et dans le webhook de paiement. C'est précisément pour cela qu'il faut le remplir avec soin : tout ce que vous y mettez repart vers vos serveurs, vos journaux techniques et vos endpoints de webhooks.
La bonne pratique est d'y mettre un identifiant, et rien d'autre qu'un identifiant :
{
"metadata": { "cartId": "c_987", "source": "web" }
}Un identifiant de panier suffit à retrouver tout le reste dans votre propre système, là où vous en contrôlez l'accès. N'y mettez jamais un nom, une adresse, un numéro de carte nationale d'identité, une information de santé ni un motif intime : ces informations n'ont rien à faire dans un champ qui voyage à chaque événement. La méthode pour retrouver une commande à partir de ses identifiants est détaillée dans relier un paiement à sa commande.
Des libellés neutres
La même prudence vaut pour les textes libres. Un lien de paiement, c'est un montant et une description ; une session porte votre orderId, votre référence métier. Ni l'un ni l'autre n'est l'endroit pour un diagnostic, un motif intime ou un numéro d'identité : la description voyage avec le lien, partagé par WhatsApp ou par e-mail, et la référence vous sert à rapprocher, pas à décrire.
Quelques exemples tirés d'activités marocaines :
| Activité | À éviter dans la description ou la référence | À préférer |
|---|---|---|
| Cabinet dentaire | « Dévitalisation molaire — Amine Bennani » | « Consultation du 14 octobre » |
| Centre de soutien scolaire | « Cours de rattrapage — difficultés en mathématiques » | « Soutien — octobre » |
| Agence immobilière | « Loyer — CIN du locataire » | « Loyer octobre — lot B3 » |
| Boutique en ligne | « Commande d'Amine, taille 44, livraison à Maârif » | « Commande #1042 » |
Le principe est simple : le libellé dit de quoi il s'agit sans dire qui c'est, et le détail reste dans votre propre dossier, derrière vos propres accès. Le parcours de paiement de trois de ces activités est détaillé dans paiement en ligne pour cabinet médical, frais de scolarité en ligne et encaisser les loyers en ligne.
Qui voit quoi : rôles et exports
Dans le portail, chacun ne voit pas tout. Les rôles du portail séparent la consultation de l'action : le comptable lit tout sans rien déclencher, le caissier encaisse sans voir le solde ni les virements. La répartition détaillée est dans rôles et accès du portail.
Côté plateforme, deux protections complètent ces rôles : les données sensibles sont masquées dans les journaux, et l'export de données personnelles est strictement contrôlé. De votre côté, la règle est celle du moindre accès :
- 1Donnez à chaque personne le rôle le plus restreint qui lui suffit : un caissier n'a pas besoin du rôle de comptable.
- 2Réservez le rôle de comptable à ceux qui doivent lire l'historique complet, y compris un cabinet externe si vous en avez un.
- 3Traitez vos exports CSV comme des fichiers clients : où sont-ils stockés, qui les reçoit, quand les supprimez-vous ?
- 4Retirez les accès des personnes qui quittent l'entreprise, le jour même.
Informer vos clients
Vos clients ont intérêt à savoir qui traite leur paiement. Dites-le simplement sur votre site, par exemple dans vos conditions de vente ou sur la page de commande, en reprenant les faits tels qu'ils sont :
Les paiements par carte sont traités par ChariPay, une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Vous saisissez votre carte sur une page de paiement hébergée : nous ne voyons jamais votre numéro de carte.
L'identité de l'entité qui opère ChariPay figure dans nos mentions légales. Votre propre politique de confidentialité, elle, ne se rédige pas à partir d'un article de blog : elle dépend de vos traitements, de vos prestataires et de vos usages, et c'est votre conseil qui peut vous aider à l'écrire.
Les questions sur vos données à poser à votre conseil
Nous ne détaillons aucune obligation de la loi 09-08 : la CNDP est l'autorité de contrôle, et votre situation vous est propre. Voici les questions à préparer, sans réponse toute faite :
- 1Quelles formalités dois-je accomplir auprès de la CNDP pour mes fichiers clients ?
- 2Comment informer mes clients, et à quel endroit de mon site ou de mon parcours de commande ?
- 3Combien de temps conserver mes propres fichiers : commandes, exports, conversations ?
- 4Quelles données puis-je confier à mes prestataires — paiement, livraison, hébergement, messagerie — et dans quel cadre ?
- 5Que répondre à un client qui demande quelles données je détiens sur lui ?
Pour chacune de ces questions, votre conseil reste seul à pouvoir se prononcer : cet article ne constitue pas un avis juridique.
Questions fréquentes
La loi 09-08 s'applique-t-elle aux données d'une boutique en ligne ?
Les données de vos clients — nom, e-mail, téléphone, historique d'achats — sont des données à caractère personnel au sens de la loi 09-08, dont la CNDP est l'autorité de contrôle. Une boutique en ligne en collecte à chaque commande. Pour savoir précisément ce que cela implique pour votre activité, votre conseil reste seul à pouvoir se prononcer.
Qui contrôle l'application de la loi 09-08 ?
La CNDP, Commission nationale de contrôle de la protection des données à caractère personnel : c'est l'autorité de contrôle de la loi 09-08. Son site, cndp.ma, présente la loi et les démarches qu'elle encadre ; c'est la source officielle à consulter. Nous ne détaillons pas les obligations qui en découlent : pour votre activité, votre conseil reste seul à pouvoir se prononcer.
Quelles données client faut-il fournir pour créer une session de paiement ?
Quatre champs, requis dans config.customer : email, firstName, lastName et phone, au format international (par exemple +212600000000). Vous les transmettez côté serveur à la création de la session. La carte, elle, est saisie par le client sur le checkout hébergé : vous ne voyez jamais de numéro de carte. N'ajoutez pas d'autres données personnelles ailleurs dans la requête.
Puis-je mettre le nom ou l'adresse de mon client dans metadata ?
Évitez-le. metadata est renvoyé tel quel sur les lectures et dans le webhook de paiement : tout ce que vous y mettez repart vers vos serveurs et vos journaux à chaque événement. Mettez-y un identifiant — un numéro de panier, par exemple — et gardez le nom, l'adresse ou toute information sensible dans votre propre système, derrière vos propres accès.
Quelles données un abonnement conserve-t-il ?
La fiche du client — son nom, requis, son e-mail, nécessaire parce que c'est là que partent les liens de paiement de chaque échéance et les rappels, et son téléphone si vous le renseignez —, puis, pour l'abonnement lui-même, le montant, la description, la périodicité, votre metadata et la liste des échéances générées, chacune avec son lien et son état. À chaque échéance, le client saisit sa carte sur la page hébergée, avec 3-D Secure : vous ne voyez jamais son numéro.
Mon comptable peut-il voir les données de mes clients ?
Oui. Le rôle de comptable lit tout — transactions, liens, remboursements, virements, solde — et exporte, sans rien déclencher. Réservez-le aux personnes qui en ont besoin, y compris un cabinet externe, donnez aux autres le rôle le plus restreint qui leur suffit, et traitez ses exports CSV comme des fichiers clients.
Que dire à mes clients sur la façon dont leur paiement est traité ?
Dites qui traite le paiement et où la carte est saisie : les paiements par carte sont traités par ChariPay, une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib, et la carte est saisie sur une page hébergée, sans que vous voyiez son numéro. Votre politique de confidentialité, elle, se rédige avec votre conseil.
Prochaine étape
Vérifiez par vous-même ce que chaque produit transmet : Commencer en mode test, créez une session et un lien avec des données fictives, et triez votre metadata pour n'y garder que des identifiants. Soumettez ensuite vos questions à votre conseil. Pour le cadre des données de carte, lisez PCI DSS pour les commerçants.
Sources
Écrit par Équipe ChariPay.