Le jour où vous branchez votre CRM sur une API d’envoi, quelque chose change dans votre organisation. Les emails ne partent plus quand un humain clique sur « envoyer ». Ils partent quand une condition technique est remplie. Un formulaire soumis, un statut d’opportunité modifié, un panier abandonné, une facture émise.
C’est confortable. C’est aussi le moment où la conformité RGPD cesse d’être un sujet marketing pour devenir un sujet d’architecture. Parce qu’un traitement automatisé ne se rattrape pas après coup : il rejoue la même erreur mille fois avant que quelqu’un s’en aperçoive.
Ce que l’API change vraiment dans votre chaîne d’envoi
Une interface web d’emailing impose un rythme. Vous importez un fichier, vous vérifiez la segmentation, vous relisez, vous programmez. Chaque étape est un point de contrôle humain, même informel.
L’API supprime ces points de contrôle. Votre application appelle un endpoint, transmet un destinataire et un contenu, reçoit un identifiant de message. Quelques centaines de millisecondes. Personne n’a relu quoi que ce soit.
Ce mode d’envoi couvre en général trois familles d’usages. Les emails transactionnels d’abord, déclenchés par une action utilisateur : confirmation de commande, réinitialisation de mot de passe, accusé de réception. Les campagnes pilotées depuis un outil tiers ensuite, quand le CRM reste maître de la donnée et que la plateforme emailing ne sert que de moteur d’envoi. Les scénarios de marketing automation enfin, où l’API fait circuler des événements plutôt que des messages.
Dans les trois cas, une chose ne bouge pas. Vous restez responsable de traitement au sens du RGPD. Le fournisseur de l’API, lui, est sous-traitant. Cette répartition ne se négocie pas, elle découle de qui décide des finalités et des moyens. Et c’est vous qui décidez à qui vous écrivez et pourquoi.
La base légale ne s’évapore pas parce que l’envoi est automatisé
Première erreur classique : considérer qu’un email transactionnel échappe au cadre de la prospection. Parfois oui, souvent non. Tout dépend du contenu réel du message, pas de son nom dans votre code.
En prospection B2B française, le régime applicable est celui de l’article L.34-5 du Code des postes et des communications électroniques. Il autorise l’envoi sans consentement préalable, mais sous trois conditions cumulatives. L’adresse doit être professionnelle et nominative, liée à la fonction exercée. L’objet du message doit être en rapport avec l’activité professionnelle du destinataire. Et chaque envoi doit comporter un moyen simple et gratuit de s’opposer aux envois suivants.
Cette troisième condition mérite qu’on s’y arrête, parce qu’elle a une traduction technique directe. Un email envoyé par API avec un template minimaliste, sans pied de page, sans lien de désinscription, est non conforme. Peu importe qu’il ait été déclenché par un webhook interne à trois heures du matin.
Pour tout ce qui relève du B2C ou d’une base collectée via formulaire, le consentement redevient la base légale de référence au titre de l’article 6 du RGPD. Le cadre général est détaillé dans notre article sur la protection des données en emailing, qui pose les fondations juridiques que cet article applique au cas technique.
Transporter la preuve du consentement dans l’appel lui-même
Voilà le point que la plupart des intégrations ratent, et il coûte cher en cas de contrôle.
Vous avez recueilli un consentement quelque part. Un formulaire, un salon, un import qualifié. Cette preuve vit dans votre CRM. Puis votre application appelle l’API d’envoi en transmettant une adresse email, un prénom, un identifiant de campagne. Et c’est tout.
Six mois plus tard, la personne se plaint. Vous devez démontrer que le consentement existait au moment de l’envoi. Vous ouvrez le CRM, où la fiche a peut-être été modifiée entre-temps. Vous ouvrez la plateforme d’envoi, qui ne sait rien de l’origine du contact. Aucun des deux systèmes ne porte l’information complète.
La parade tient en trois champs à faire circuler dans le payload, puis à stocker côté plateforme :
| Champ | Contenu | À quoi il sert |
|---|---|---|
consent_source |
Origine exacte du contact (formulaire livre blanc, import salon 2026, opt-out L.34-5) | Identifier la base légale applicable à ce contact précis |
consent_timestamp |
Date et heure du recueil, en UTC | Prouver l’antériorité du consentement sur l’envoi |
consent_proof_ref |
Référence du log ou de l’enregistrement dans le système source | Remonter à la preuve brute sans dépendre de l’état actuel de la fiche |
Ces champs ne servent pas à l’envoi. Ils servent le jour où quelqu’un vous demande de justifier. Toutes les plateformes acceptent des attributs personnalisés sur les contacts, la seule question est de décider de les remplir avant que le besoin se manifeste.
Ne poussez que les données dont l’envoi a besoin
Le principe de minimisation de l’article 5 du RGPD s’applique champ par champ, y compris dans un corps de requête JSON.
En pratique, les intégrations construites vite transmettent la fiche CRM entière parce que c’est plus simple que de choisir. Le chiffre d’affaires du compte, le score de lead, les notes du commercial, la date du dernier appel, le motif de perte de la dernière opportunité. Tout ça part vers un système tiers qui n’en a aucun usage.
Trois conséquences. Vous augmentez la surface exposée en cas de compromission de la plateforme. Vous créez un transfert de données sans finalité déclarée, difficile à justifier dans votre registre. Et vous multipliez les endroits où exercer un droit à l’effacement.
La règle de tri est simple : un champ ne part que s’il est utilisé dans le template, dans la segmentation, ou dans la logique de déclenchement. Le reste reste chez vous. Une variable de personnalisation qui n’apparaît nulle part dans le message n’a rien à faire dans l’appel.
Ce que votre architecture doit prévoir dès la conception
Un désabonnement qui remonte dans les deux sens
C’est le défaut de synchronisation le plus fréquent, et le plus visible pour le destinataire.
Quelqu’un clique sur le lien de désinscription dans un email. La plateforme d’envoi enregistre l’opposition. Votre CRM, lui, ne sait rien. Quinze jours plus tard, un nouveau scénario se déclenche depuis le CRM, appelle l’API avec cette même adresse, et la personne reçoit un message qu’elle avait explicitement refusé.
Deux mécanismes évitent ce scénario. Un webhook côté plateforme qui notifie votre application à chaque désinscription et met à jour le statut dans le système source. Et un contrôle côté émetteur qui interroge le statut du contact avant d’appeler l’endpoint d’envoi, plutôt que de faire confiance à un cache local.
Un point de vigilance : les plateformes sérieuses bloquent l’envoi vers un contact désinscrit et renvoient un code d’erreur explicite. Encore faut-il que votre code lise ce code d’erreur au lieu de le journaliser silencieusement.
Des logs d’appels API avec une durée de vie décidée
Vos logs d’API contiennent des données personnelles. Adresses email, adresses IP d’appel, contenus personnalisés, parfois des payloads complets conservés pour le débogage. Ce sont des traitements comme les autres, soumis au principe de limitation de la conservation.
Personne ne définit jamais leur durée de rétention. Ils s’accumulent, sont sauvegardés, répliqués, et deviennent le premier endroit oublié lors d’une demande d’effacement.
Fixez une durée, documentez-la, purgez automatiquement. Pour du log technique d’exploitation, quelques mois suffisent dans la plupart des contextes. Si vous conservez plus longtemps pour des raisons de preuve, tronquez les payloads et ne gardez que les métadonnées nécessaires.
Une cartographie des flux pour votre registre
L’article 30 du RGPD impose de tenir un registre des activités de traitement. Une intégration API crée un flux qu’il faut y décrire : quelles données partent, vers quel prestataire, dans quel pays, pour quelle finalité, avec quelle durée de conservation.
L’exercice paraît administratif. Il est surtout révélateur. C’est en dessinant la chaîne CRM vers API vers plateforme vers destinataire que la plupart des équipes découvrent des champs transmis sans raison, ou un environnement de test alimenté avec des adresses de production. Ce dernier point revient très souvent, d’ailleurs. Tester un scénario d’envoi avec de vrais contacts clients constitue un traitement hors finalité, et personne ne le déclare jamais.
Sécuriser l’API : l’article 32 en langage d’intégrateur
L’article 32 du RGPD impose des mesures de sécurité adaptées au risque. Pour une API d’envoi, cela se traduit par une poignée de pratiques concrètes.
La clé API est un secret d’authentification, pas une valeur de configuration. Elle n’a rien à faire dans un dépôt Git, dans un fichier de configuration versionné, ni dans le code d’un front-end. Elle vit dans un gestionnaire de secrets ou une variable d’environnement du serveur, et nulle part ailleurs.
La rotation des clés est le point le plus négligé. Beaucoup d’intégrations tournent depuis des années avec la clé générée le premier jour, connue de trois prestataires successifs et d’un ancien développeur. Prévoyez une rotation périodique et une révocation immédiate à chaque départ ou fin de mission. Une plateforme qui ne permet de générer qu’une seule clé par compte vous condamne à l’interruption de service à chaque rotation, ce qui garantit que personne ne la fera jamais.
Le cloisonnement des droits vient ensuite. Une clé dédiée à l’envoi transactionnel n’a pas besoin de pouvoir exporter la base de contacts. Quand la plateforme propose des permissions granulaires ou des restrictions par plage d’adresses IP, utilisez-les.
Le classement OWASP API Security Top 10, dans son édition 2023, place en tête des risques le défaut d’autorisation au niveau des objets, cette faille qui permet d’accéder aux données d’un autre compte en modifiant simplement un identifiant dans la requête. En deuxième position figure le défaut d’authentification. Deux catégories directement applicables à une API qui manipule des listes de contacts.
Le guide de la sécurité des données personnelles de la CNIL, dans son édition 2024, couvre ces sujets avec des recommandations opérationnelles utiles aux équipes techniques françaises.
Reste l’authentification des envois eux-mêmes. Passer par une API ne dispense pas de configurer correctement vos enregistrements DNS. La configuration SPF, DKIM et DMARC pour authentifier vos envois reste la condition d’arrivée en boîte de réception, quel que soit le mode de déclenchement.
Enfin, un scénario à préparer avant qu’il se produise : une clé compromise qui a permis l’export de votre base constitue une violation de données personnelles. L’article 33 impose une notification à la CNIL dans les 72 heures suivant la prise de connaissance, dès lors qu’un risque existe pour les personnes concernées. Savoir qui appelle, qui décide et sur quelles preuves, ça se prépare à froid.
Votre fournisseur d’API est un sous-traitant, avec un contrat qui va avec
L’article 28 du RGPD encadre la relation entre responsable de traitement et sous-traitant. Elle doit faire l’objet d’un contrat écrit, souvent appelé DPA. Ce document existe presque toujours chez les éditeurs sérieux. Il est presque toujours signé sans être lu.
Quatre points valent une lecture attentive.
La liste des sous-traitants ultérieurs, d’abord. Votre prestataire d’emailing s’appuie lui-même sur un hébergeur, parfois sur un service de détection de bounces, parfois sur un routeur SMS tiers. Cette chaîne doit être documentée et vous devez être informé de ses évolutions.
La localisation effective des traitements ensuite. Un siège social français ne garantit pas des serveurs européens. Vérifiez où les données sont stockées, où les sauvegardes sont répliquées, et depuis quel pays le support technique accède aux comptes clients. Un transfert hors UE non encadré est une non-conformité, même si l’interface est en français.
Les durées de conservation appliquées par la plateforme, ensuite. La CNIL recommande de conserver les données d’un prospect non client pendant trois ans à compter du dernier contact émanant de sa part. Si votre plateforme conserve indéfiniment les contacts supprimés dans une corbeille technique, vous héritez du problème.
Les modalités de restitution et de suppression en fin de contrat, enfin. Format d’export, délai, preuve de suppression effective.
Chez Ediware, ces questions sont traitées par construction : hébergement en France, chaîne de sous-traitance documentée et engagements contractuels détaillés sur la sécurité des données Ediware. Notre API et intégrations Ediware permet de brancher votre CRM ou votre ERP tout en conservant la traçabilité des consentements côté plateforme.
Les erreurs qui reviennent le plus souvent
| Erreur | Ce qu’elle produit | Correctif |
|---|---|---|
| Template API sans lien de désinscription | Non-respect de L.34-5, plaintes, dégradation de la réputation d’expéditeur | Intégrer le lien dans le template par défaut, pas dans chaque appel |
| Aucune preuve de consentement côté plateforme | Impossible de justifier un envoi lors d’un contrôle | Transmettre source, horodatage et référence de preuve dans le payload |
| Payload contenant toute la fiche CRM | Transfert sans finalité, surface d’exposition élargie | Ne transmettre que les champs utilisés par le template ou la segmentation |
| Désinscriptions non répercutées dans le CRM | Réenvoi à des personnes opposées, plaintes légitimes | Webhook de désinscription et vérification du statut avant appel |
| Clé API en dur dans le code ou jamais tournée | Fuite possible, accès résiduel d’anciens prestataires | Gestionnaire de secrets, rotation planifiée, révocation au départ |
| Logs d’appels conservés sans limite | Données personnelles hors durée déclarée, effacement incomplet | Durée définie, purge automatique, troncature des payloads |
| Environnement de test alimenté en données réelles | Traitement hors finalité déclarée | Jeu de données anonymisées ou domaines de test dédiés |
Aucune de ces corrections ne demande un chantier. Ce sont des décisions d’intégration, prises une fois, qui coûtent une demi-journée au moment de la conception et beaucoup plus une fois que dix mille envois quotidiens tournent en production.
Questions fréquentes
Un fournisseur d’API emailing est-il automatiquement mon sous-traitant ?
Oui, dès lors qu’il traite des données personnelles pour votre compte et selon vos instructions. Vous restez responsable de traitement puisque vous décidez des finalités et des destinataires. Cette relation impose un contrat écrit conforme à l’article 28 du RGPD, généralement fourni sous forme de DPA par l’éditeur.
Faut-il un consentement pour envoyer un email B2B via API ?
Pas nécessairement. L’article L.34-5 du Code des postes et des communications électroniques autorise la prospection vers une adresse professionnelle nominative sans consentement préalable, à condition que l’objet du message concerne l’activité professionnelle du destinataire et qu’un moyen d’opposition simple et gratuit figure dans chaque envoi.
Comment prouver un consentement transmis par un appel API ?
En faisant circuler la preuve avec la donnée. Ajoutez dans le payload la source du consentement, son horodatage et une référence vers l’enregistrement d’origine, puis stockez ces attributs côté plateforme. Sans cela, la preuve reste dans un seul système et devient difficile à reconstituer après modification de la fiche.
Les emails transactionnels sont-ils exclus du champ du RGPD ?
Non. Le RGPD s’applique à tout traitement de données personnelles, transactionnel compris. La distinction porte sur la base légale et sur les règles de prospection : un message strictement lié à l’exécution d’un contrat ne relève pas de la prospection, mais reste soumis aux obligations de sécurité, de minimisation et d’information.
Combien de temps conserver les logs d’appels à une API d’envoi ?
Le RGPD ne fixe pas de durée chiffrée, il impose de la définir et de la justifier au regard de la finalité. Pour du log d’exploitation technique, quelques mois suffisent généralement. Au-delà, tronquez les payloads pour ne conserver que les métadonnées nécessaires et purgez automatiquement le reste.
Que faire si une clé API est compromise ?
Révoquez la clé immédiatement, générez-en une nouvelle et analysez les journaux d’accès pour mesurer l’étendue de l’exposition. Si des données personnelles ont pu être consultées ou exfiltrées, la CNIL doit être notifiée dans les 72 heures suivant la prise de connaissance, conformément à l’article 33 du RGPD.
L’hébergement en France suffit-il à rendre mon intégration conforme ?
Non. La localisation des serveurs élimine la question des transferts hors Union européenne, ce qui est déterminant, mais elle ne couvre ni la base légale des envois, ni la minimisation des données transmises, ni la sécurisation des clés d’accès. La conformité d’une intégration API se joue sur l’ensemble de la chaîne.
