Mailbeam
ConformitéPar The Mailbeam Team6 min de lectureMis à jour le 16 septembre 2026

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 ne conserve pas les adresses soumises une fois la réponse renvoyée. Ce qui est mis en cache, c'est la résolution MX du domaine, indexée par domaine et jamais par adresse : une seconde vérification sur ce même domaine évite ainsi l'aller-retour DNS sans qu'aucune adresse ne soit stockée. Les traitements par lots sont la seule exception : la liste et ses résultats sont conservés 72 heures pour que vous puissiez les télécharger, puis supprimés.

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 ☐ Ajouter le prestataire à votre registre de l'article 30, en notant le lieu de traitement ☐ Refléter la vérification dans vos schémas de flux de données

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.

Ce qu'il faut demander à tout prestataire de vérification

Utilisez ces questions pour évaluer n'importe quel fournisseur, pas seulement Mailbeam :

  1. Où les données sont-elles traitées et stockées ? (Un traitement strictement européen évite les analyses de transfert.)
  2. Fournissez-vous un DPA, et sur quelles offres ? (Ce devrait être toutes.)
  3. Conservez-vous les adresses que je vérifie ? (Un traitement à la volée, sans conservation, est l'idéal.)
  4. Qui sont vos sous-traitants ultérieurs, et où sont-ils ?
  5. Quelles mesures de sécurité et quelles certifications avez-vous ?
  6. Comment traitez-vous la notification de violation au titre de l'article 33 ?

Comment Mailbeam y répond

ExigenceMailbeam
Lieu de traitementFrancfort, UE uniquement
Transfert vers un pays tiersAucun — pas de clauses contractuelles types pour la vérification
DPAInclus sur chaque offre
Conservation des donnéesAucune après la réponse ; les lots sont supprimés au bout de 72 heures
Principe d'exactitudeVérification temps réel et en masse pour le soutenir

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