Données des demandeurs de gros et RGPD : pourquoi supprimer vaut mieux qu'anonymiser

Les demandes de compte de gros collectent exactement les données que le RGPD traite avec le plus de précaution : noms, adresses professionnelles, coordonnées, parfois un identifiant proche d'une pièce d'identité. La plupart des boutiques gèrent bien les approbations et mal les refus — le demandeur que vous avez refusé est celui dont vous n'avez aucune raison légitime de conserver les données, et « nous les anonymisons » n'est généralement pas la réponse que l'on croit. Ce guide couvre ce qu'il faut conserver, combien de temps, et pourquoi la suppression vaut mieux que l'anonymisation pour des demandeurs professionnels.

Le demandeur refusé est le cas difficile

Un demandeur approuvé devient client : il y a un contrat, une fiche société, des commandes et des factures que vous êtes légalement tenu de conserver. La base légale est claire et la durée de conservation est fixée par le droit fiscal, non par préférence.

Un demandeur refusé n'a rien de tout cela. Pas de contrat, pas de relation en cours et, après la communication de la décision, généralement plus aucune finalité. Le principe de limitation de la conservation (art. 5, § 1, e du RGPD) veut que les données ne soient pas conservées plus longtemps que nécessaire au regard des finalités. Dès lors que vous avez décidé de ne pas commercer avec quelqu'un, la demande a rempli sa finalité.

L'objection habituelle : on veut garder une trace au cas où la personne recandidate, ou en cas de litige. Les deux peuvent être légitimes, mais doivent être énoncés comme une finalité assortie d'une durée, non laissés à l'état d'intention vague. Une position défendable ressemble à ceci : « les demandes refusées sont supprimées après 90 jours ; nous conservons la décision et sa date pendant 12 mois pour traiter les nouvelles candidatures et les litiges. » Ce qui n'est pas défendable, c'est de garder la demande complète indéfiniment parce que personne n'a construit le chemin de suppression.

Pourquoi l'anonymisation échoue le plus souvent ici

L'anonymisation séduit parce qu'elle fait sortir les données du champ du RGPD — des données anonymes ne sont pas des données personnelles. Le problème est le critère : des données ne sont anonymes que si la ré-identification n'est pas raisonnablement possible par quiconque, par tout moyen raisonnablement susceptible d'être utilisé.

Les données de demandeurs professionnels franchissent rarement cette barre. Un nom de société plus un numéro de TVA sont à une consultation de registre public d'une personne nommée — c'est précisément à cela que servent les registres. Pour un entrepreneur individuel, le nom de la société est souvent le nom de la personne. Retirez le nom du contact et l'e-mail, gardez « Müller Handel, DE123456789, demande le 4 mars, refusée », et vous détenez un enregistrement qui identifie une personne pour quiconque a un navigateur.

Le schéma « anonymiser plutôt que supprimer » qui fonctionne pour les statistiques web ne se transpose donc pas aux demandes B2B. La suppression est plus simple, plus facile à expliquer et atteint réellement l'objectif. Si vous voulez des statistiques, conservez des compteurs — demandes par mois, taux d'approbation — non des lignes pseudonymisées.

Qui est responsable du traitement ?

Cela s'embrouille dès qu'une application intervient. Le marchand décide de lancer un programme de gros, décide des questions du formulaire et décide qui est approuvé : le marchand est responsable du traitement des données des demandeurs. Une application qui traite ces données pour son compte est sous-traitante et a besoin d'un contrat au titre de l'article 28 pour être licite.

Deux conséquences pratiques. D'abord, la durée de conservation est la décision du marchand, non le réglage par défaut de l'application — elle doit donc être configurable, et l'application ne doit pas conserver silencieusement les données plus longtemps que demandé. Ensuite, l'exercice des droits arrive chez le marchand, et l'application doit pouvoir y répondre : retrouver l'enregistrement, l'exporter, le supprimer. Une application incapable de supprimer un demandeur précis sur demande n'est pas utilisable par un responsable qui doit se conformer.

Consultations de registres et minimisation

La vérification est un endroit où il est facile d'envoyer plus que nécessaire. Contrôler une entreprise auprès de VIES, Zefix ou Companies House requiert un identifiant d'entreprise — un numéro de TVA, un numéro d'immatriculation. Cela ne requiert pas le nom, l'e-mail ou l'adresse du demandeur, et les envoyer à un tiers serait un traitement sans finalité.

Gardez la séparation nette : le registre reçoit l'identifiant et renvoie un statut ; les données personnelles du demandeur ne quittent jamais vos systèmes. C'est de la minimisation au sens de l'article 5, § 1, c, et une réponse bien plus courte quand on vous demande ce que reçoivent vos sous-traitants.

Conservez en revanche la preuve du contrôle. Pour les livraisons intra-UE, la validité du numéro de TVA de l'acheteur est une condition de fond de l'exonération : l'identifiant de consultation VIES et la date appartiennent à vos dossiers — rattachés à la société, non perdus dans un journal. C'est une finalité de conservation avec une véritable base légale, à distinguer de la demande elle-même.

Ce qui doit figurer dans la politique de confidentialité

Le formulaire de gros est un point de collecte : il lui faut son propre paragraphe, pas un lien vers une politique générale. Ce que les demandeurs devraient pouvoir lire avant d'envoyer :

• Ce qui est collecté, et quels champs sont obligatoires ou facultatifs.
• Que les informations d'entreprise sont contrôlées auprès de registres publics, et lesquels.
• Combien de temps une demande est conservée si elle est approuvée, et si elle est refusée — avec des chiffres réels.
• Qui la traite en dehors de vous, et où (la région d'hébergement n'est pas indifférente aux acheteurs européens).
• Comment demander l'accès ou la suppression, et que la décision n'est pas prise sur le seul fondement d'un traitement automatisé — ou, si elle l'est, le dire, car l'article 22 y attache des droits.

Ce dernier point mérite du soin. Les règles d'approbation automatique sont pratiques et défendables pour les cas à faible risque, mais « votre demande a été refusée automatiquement » est une position juridique différente de « nous l'avons examinée ». Si les refus sont automatisés, les demandeurs ont droit à une intervention humaine.

Un modèle de conservation qui tient

Une structure couvrant les cas réalistes :

• Approuvé et devenu client — conservé au titre de la relation client ; les factures suivent le droit fiscal (en Allemagne, 8 ans), non le calendrier de la demande.
• Approuvé mais jamais de commande — une fiche société sans transaction. Donnez-lui une échéance : sans commande sous, disons, 24 mois, c'est un enregistrement dormant sans finalité.
• Refusé — supprimer la demande à brève échéance ; conserver la décision et la date seulement aussi longtemps qu'une raison énoncée existe.
• Retiré ou abandonné — un formulaire à moitié rempli est une donnée dont vous n'avez jamais eu l'usage. À supprimer en premier.

Quels que soient les chiffres, la purge doit réellement s'exécuter. Une politique de conservation qui n'existe que dans une politique de confidentialité est pire que rien : vous avez publié une promesse que vous ne tenez pas.

En bref

Les données des demandeurs sont le risque d'un programme de gros, et c'est sur les refus qu'elles s'accumulent. Supprimer plutôt qu'anonymiser, car un nom de société plus un numéro de TVA ré-identifie un entrepreneur individuel. N'envoyer aux registres qu'un identifiant, mais conserver la preuve de la vérification avec sa propre base légale. Écrire de vraies durées dans la politique de confidentialité, les rendre configurables par le marchand qui est responsable du traitement — et s'assurer qu'un mécanisme automatique les applique.

Résumé en langage clair, pas un conseil juridique : les durées et la base légale de votre programme méritent une demi-heure d'avocat.