Bêta privéeMailbeam est en bêta privée : l'API publique n'est pas encore ouverte.Rejoindre la liste d'attente

Mailbeam
ConformitéPar The Mailbeam Team6 min de lecture10 juin 2025

Vérification d'e-mails et RGPD : ce qu'une équipe européenne doit savoir

La plupart des développeurs voient la vérification d'e-mails comme un outil de délivrabilité. C'en est un, mais c'est aussi un mécanisme de conformité au RGPD. L'article 5.1.d) exige que les données personnelles soient « exactes et, si nécessaire, tenues à jour ». Une adresse e-mail est une donnée personnelle. Si vous conservez des adresses que vous savez invalides, vous ne respectez pas cette exigence.

Ce guide couvre les dispositions concrètes du RGPD qui s'appliquent à la vérification d'e-mails, la relation de sous-traitance à comprendre avant de choisir une API, et ce que « résidence des données dans l'UE » veut dire en pratique.

Le principe d'exactitude

L'article 5.1.d) est sans ambiguïté :

Les données à caractère personnel doivent être exactes et, si nécessaire, tenues à jour ; toutes les mesures raisonnables doivent être prises pour que les données inexactes, eu égard aux finalités pour lesquelles elles sont traitées, soient effacées ou rectifiées sans tarder.

Pour des adresses e-mail, cela signifie :

  1. Vous ne devriez pas conserver des adresses que vous savez invalides
  2. Si une adresse que vous détenez devient invalide (hard bounce, changement côté utilisateur), vous devriez la mettre à jour ou la supprimer
  3. Si « l'exactitude compte pour la finalité » — et pour un service qui communique par e-mail, c'est presque toujours le cas — une vérification périodique est une mesure raisonnable

Le mot-clé est « raisonnable ». Le RGPD n'exige pas de vérifier chaque adresse en temps réel. Il exige des mesures raisonnables et proportionnées à la finalité du traitement. Pour un produit SaaS qui communique exclusivement par e-mail, vérifier à l'inscription et nettoyer les listes périodiquement est difficile à contester.

Base légale pour utiliser une API de vérification

Quand vous appelez une API de vérification avec l'adresse d'un utilisateur, vous partagez une donnée personnelle avec un tiers. Cela a deux conséquences.

1. Il vous faut une base légale

Pour une vérification à l'inscription, la base légale est typiquement l'article 6.1.b) — « le traitement est nécessaire à l'exécution d'un contrat ». Vérifier que l'adresse de contact est valide avant d'envoyer un e-mail de confirmation est une étape raisonnable de la formation du contrat. À défaut, l'article 6.1.f) — « intérêts légitimes » — couvre la vérification comme mesure de sécurité et de qualité des données.

2. Le prestataire de vérification est un sous-traitant

Au titre de l'article 28, si vous partagez des données personnelles avec un tiers qui les traite pour votre compte, il vous faut un accord de sous-traitance (DPA) avec lui. Le DPA doit préciser :

  • Quelles données sont traitées
  • Pour quelle finalité
  • Pendant combien de temps elles sont conservées
  • Quelles mesures de sécurité s'appliquent
  • Si des sous-traitants ultérieurs interviennent, et où

Avant d'utiliser une API de vérification en production, vérifiez que le prestataire propose un DPA et signez-le. Les prestataires sérieux le mettent à disposition depuis leur tableau de bord ou leurs pages légales.

Quelles données partent vers l'API de vérification ?

Quand vous appelez POST /v1/verify avec { "email": "user@example.com" }, vous envoyez :

  • L'adresse e-mail elle-même (donnée personnelle au sens du RGPD)
  • Des métadonnées dans les en-têtes (votre IP, l'horodatage de la requête)

Le prestataire traite tout cela pour effectuer les résolutions DNS, le dialogue SMTP et le scoring. La question du point de vue du RGPD est : où ce traitement a-t-il lieu, et combien de temps la donnée est-elle conservée ?

Résidence des données dans l'UE face aux sous-traitants américains

Si vous traitez des données de résidents européens, les envoyer à un sous-traitant établi aux États-Unis déclenche le chapitre V du RGPD — les restrictions sur les transferts vers des pays tiers.

Un transfert vers les États-Unis exige l'un des éléments suivants :

  • Une décision d'adéquation (le EU-US Data Privacy Framework couvre certaines entreprises américaines depuis 2023, mais reste juridiquement contesté)
  • Des clauses contractuelles types (CCT)
  • Des règles d'entreprise contraignantes

Les CCT fonctionnent, mais elles ajoutent une charge juridique et imposent une analyse d'impact du transfert (TIA) — l'examen du point de savoir si les lois américaines de surveillance rendent le transfert dangereux malgré les clauses.

Un sous-traitant hébergé dans l'UE élimine tout cela. Si l'API de vérification traite les données dans l'UE — précisément, dans un État membre — aucune analyse au titre du chapitre V n'est nécessaire. La donnée ne quitte jamais le cadre juridique européen.

Pour la plupart des équipes européennes, la voie de conformité la plus simple consiste à retenir un sous-traitant dont l'infrastructure est dans l'UE. Cela évite les CCT, les TIA et l'incertitude juridique qui entoure les successeurs du Privacy Shield.

Mailbeam traite toutes les données à Francfort, en Allemagne (AWS eu-central-1). Aucune donnée ne quitte l'UE.

Conservation des données — ce qu'il faut demander à votre prestataire

Posez ces questions à toute API de vérification :

  • Combien de temps conservez-vous les adresses que je vous soumets ?
  • Utilisez-vous les adresses soumises pour améliorer votre modèle de scoring ?
  • Les adresses soumises sont-elles partagées avec des sous-traitants ultérieurs, et où sont-ils situés ?

La vérification elle-même est quasi instantanée. Rien ne justifie techniquement qu'un prestataire conserve les adresses soumises au-delà du temps nécessaire pour renvoyer le résultat. Si un prestataire les garde des semaines ou des mois, vous devriez comprendre pourquoi — et si c'est compatible avec vos propres obligations de conservation.

Mailbeam conserve les adresses soumises pendant 24 heures à des fins de cache (pour éviter de refaire des sondes SMTP identiques dans une courte fenêtre), puis les supprime.

Le droit à l'effacement

L'article 17 donne aux personnes le droit d'obtenir l'effacement de leurs données. Si un utilisateur demande la suppression de son compte, son adresse doit disparaître de :

  1. Votre base de données principale
  2. Votre prestataire d'envoi d'e-mails (désinscription et mise en liste de suppression)
  3. Tout outil d'analytics qui stocke l'adresse
  4. Tout journal de vérification où l'adresse a été enregistrée

Si votre prestataire de vérification conserve des adresses, vous devez pouvoir lui adresser des demandes de suppression. Cela doit figurer dans votre DPA.

Liste de contrôle pratique pour une vérification conforme au RGPD

☐ Signer un DPA avec votre prestataire de vérification ☐ Choisir un prestataire hébergé dans l'UE (ou documenter vos CCT et votre TIA pour un prestataire américain) ☐ Vérifier à l'inscription pour éviter de stocker des adresses connues comme invalides ☐ Traiter les webhooks de bounce et retirer les hard bounces sans tarder ☐ Intégrer les données de vérification à votre procédure de suppression ☐ Documenter votre base légale pour le traitement des adresses e-mail ☐ Relire votre politique de confidentialité pour y mentionner la vérification

Ce qu'il faut regarder dans le DPA d'un prestataire

Un DPA bien rédigé pour une API de vérification devrait préciser :

  • Finalité du traitement : la vérification d'adresses e-mail, et rien d'autre
  • Durée de conservation : la plus courte durée raisonnable (des heures, pas des semaines)
  • Sous-traitants ultérieurs : la liste des tiers utilisés, avec leur localisation
  • Mesures de sécurité : chiffrement en transit et au repos, contrôles d'accès
  • Droits des personnes : comment les demandes de suppression sont traitées
  • Droit d'audit : votre droit de contrôler la conformité

Si un prestataire n'a pas de DPA ou le rend difficile à trouver, prenez-le comme un signal d'alarme.

En résumé

Vérification d'e-mails et conformité au RGPD se renforcent mutuellement :

  • Le principe d'exactitude (art. 5.1.d)) vous donne une raison de conformité de vérifier les adresses, pas seulement une raison de délivrabilité
  • Un prestataire hébergé dans l'UE fait disparaître la complexité des transferts du chapitre V
  • Un DPA signé est nécessaire avant de traiter des données personnelles avec une API tierce

Pour une équipe européenne, l'assemblage le plus propre est : vérifier à l'inscription, traiter les bounces sans tarder, retenir un prestataire hébergé dans l'UE avec un DPA clair, et documenter sa base légale.

Prochaines étapes

Articles liés

← Retour au blog