Email transactionnel et application : ce qu’une PME doit exiger

Une application envoie des e-mails sans que personne n’appuie sur « envoyer » : confirmation de compte, lien de nouveau mot de passe, récapitulatif de commande, confirmation d’inscription à la newsletter. Ces messages ne partent pas tout seuls depuis l’outil d’emailing : ils se déclenchent et se codent dans l’application elle-même, et c’est donc un sujet à cadrer avec l’agence de développement web et mobile qui la construit, à l’image de Cybalgo, installée à Longueuil et à Port-au-Prince. Voici ce qu’une PME peut exiger, point par point, pour que ces e-mails arrivent vraiment en boîte de réception.

Le sujet paraît technique, mais il a des effets très concrets : un client qui ne reçoit pas son lien de connexion n’utilise pas l’application, et un inscrit qui ne confirme jamais son adresse ne lira jamais la newsletter.

Email transactionnel ou marketing : deux familles de messages

Un email transactionnel répond à une action de la personne : elle crée un compte, réserve, remplit un formulaire, oublie son mot de passe. Google cite lui-même ces exemples : réinitialisation de mot de passe, confirmation de réservation, confirmation d’envoi de formulaire.

Un e-mail marketing, lui, part à l’initiative de l’entreprise : newsletter, promotion, relance commerciale. Les deux peuvent sortir du même outil, mais ils ne répondent pas aux mêmes règles, ni techniques ni juridiques.

Une nuance compte beaucoup : selon Google, ce sont les destinataires, et non l’expéditeur, qui déterminent la nature des messages qu’ils reçoivent. Glisser une offre promotionnelle dans une confirmation d’achat est d’ailleurs une pratique que Google demande explicitement d’éviter.

Ce qui se code dans l’application

Dans une application, l’envoi suit toujours le même chemin. Un événement se produit (inscription, commande, demande de mot de passe), l’application appelle l’outil d’emailing, qui compose le message à partir d’un modèle et l’expédie. Cet appel passe le plus souvent par une API, une interface qui permet à deux logiciels de dialoguer ; nous détaillons ce que coûte ce type de service dans notre page sur l’API email.

C’est à ce niveau que se joue la qualité du travail. Un prestataire sérieux prévoit ce qui se passe quand l’outil d’emailing ne répond pas : l’envoi est-il retenté, ou le message est-il perdu sans que personne ne le sache ?

Il prévoit aussi la gestion des adresses invalides. Une adresse qui renvoie une erreur définitive doit sortir des envois suivants, sous peine d’abîmer la réputation de l’expéditeur ; les différents types de bounce email sont expliqués sur une page dédiée.

Dernier point à demander : un journal d’envoi consultable. Savoir quel message est parti, à quelle heure et avec quelle réponse du serveur destinataire évite de longues recherches le jour où un client affirme n’avoir rien reçu.

Formulaire d’inscription et double opt-in

Le formulaire d’inscription à la newsletter fait partie de l’application, et c’est lui qui recueille le consentement. Pour les particuliers, la CNIL rappelle que la prospection par e-mail exige un consentement préalable, libre, spécifique, éclairé et univoque, donné par une action positive, par exemple une case à cocher dédiée. Pour les professionnels, la règle est différente : ils doivent être informés et pouvoir s’y opposer.

Le double opt-in ajoute une étape : après l’inscription, la personne reçoit un e-mail et clique sur un lien pour confirmer son adresse. Aucun texte ne l’impose en tant que tel, mais le RGPD demande à l’entreprise d’être en mesure de démontrer le consentement, et Google conseille de vérifier l’adresse de chaque destinataire avant de l’abonner. Le cadre juridique est détaillé dans notre article sur le double opt-in.

Concrètement, vous pouvez exiger une case non cochée par défaut, un lien de confirmation qui expire, la conservation de la date et de l’heure de chaque consentement, et une désinscription faite dans l’outil d’emailing qui se répercute bien dans l’application, et inversement.

Cette règle peut surprendre une entreprise qui ajoute une application à une newsletter déjà existante : les confirmations de compte et la lettre d’information s’additionnent. D’où l’intérêt de régler l’authentification du domaine dès le départ, avant que les volumes ne montent.

SPF, DKIM, DMARC : un domaine authentifié

Trois enregistrements publiés dans la zone du domaine permettent aux messageries de vérifier que l’e-mail vient bien de vous. SPF liste les serveurs autorisés à envoyer pour votre domaine, DKIM signe chaque message, et DMARC indique quoi faire d’un message qui échoue à ces contrôles.

Chez Gmail, tout expéditeur doit au minimum configurer SPF ou DKIM. Au-delà de 5 000 messages par jour, les trois deviennent obligatoires, une politique DMARC réglée sur « none » étant acceptée, et le domaine affiché dans le champ « De » doit correspondre à celui de SPF ou de DKIM.

Côté DKIM, Google demande une clé d’au moins 1 024 bits et en recommande une deux fois plus longue si votre hébergeur de domaine le permet. C’est un réglage que le prestataire doit vérifier, pas seulement cocher.

Outlook.com applique des règles proches depuis le 5 mai 2025 pour les domaines qui dépassent 5 000 e-mails par jour : SPF et DKIM doivent passer, DMARC doit être publié au moins en « p=none », et les messages non conformes sont rejetés. Le rôle exact de chaque enregistrement est expliqué dans notre page SPF, DKIM, DMARC.

Ce que Gmail et Outlook exigent des expéditeurs, date par date

Relevé le 28/09/2026 sur les pages officielles de Google et de Microsoft

Février 2024

Gmail pose ses règles

SPF ou DKIM pour tous ; SPF, DKIM et DMARC au-delà de 5 000 messages par jour.

Juin 2024

Désabonnement en un clic

Attendu dans les messages commerciaux ; au-delà de 0,3 % de spam signalé, plus de mesures d’atténuation.

Mai 2025

Outlook.com suit

SPF, DKIM et DMARC exigés au-delà de 5 000 e-mails par jour, rejet des messages non conformes.

Nov. 2025

Gmail durcit l’application

Rejets temporaires et permanents pour le trafic qui ne respecte pas les consignes.

Taux de spam signalé, mesuré dans Postmaster Tools

Objectif : sous 0,10 %Seuil à ne jamais atteindre : 0,30 %

Ces dates montrent une tendance nette : ce qui relevait de la bonne pratique est devenu une condition d’accès aux boîtes de réception. Pour une application, l’enjeu est simple : les e-mails de création de compte et de mot de passe doivent partir d’un domaine correctement authentifié dès le premier jour.

DMARC protège aussi votre marque. Sans politique DMARC de quarantaine ou de rejet, rien n’indique aux messageries de refuser un faux message qui affiche votre domaine dans le champ « De » en imitant vos e-mails de commande ou d’alerte de compte.

Séparer les flux marketing et transactionnels

Google recommande d’utiliser la même adresse d’expéditeur pour tous les messages d’une même catégorie : une adresse pour les confirmations d’achat, une autre pour les promotions, une autre pour les notifications de compte. Si vous envoyez depuis plusieurs adresses IP, il conseille aussi une IP par type de message.

Cette séparation des flux a un intérêt pratique : une campagne marketing mal reçue ne doit pas entraîner dans sa chute le message qui permet à un client de se connecter. Demandez donc à votre prestataire comment les deux familles de messages sont distinguées dans l’application et dans l’outil d’emailing.

Les obligations diffèrent aussi. Le désabonnement en un clic, décrit par la norme RFC 8058, est exigé par Google pour les messages marketing et promotionnels des expéditeurs en masse, mais pas pour les transactionnels. Rappelez-vous enfin que les deux flux s’additionnent dans le calcul du seuil d’expéditeur en masse.

Suivre la délivrabilité après la mise en ligne

Le travail ne s’arrête pas à la mise en production. Google demande de maintenir le taux de spam signalé, visible dans son outil gratuit Postmaster Tools, sous 0,10 %, et de ne jamais atteindre 0,30 %. Depuis novembre 2025, Gmail applique des rejets temporaires et permanents au trafic qui ne respecte pas ses consignes.

Côté Outlook.com, un message refusé pour défaut d’authentification revient avec un code d’erreur explicite (5.7.515). Encore faut-il que l’application enregistre ces retours et que quelqu’un les lise. Les exigences des grandes messageries sont regroupées dans notre fiche sur la délivrabilité email.

Les questions à poser avant de signer

Avant de valider un devis de développement, quelques questions simples suffisent à voir si l’e-mail a été pensé.

Quels messages l’application enverra-t-elle, et lesquels sont transactionnels ou marketing ? Par quel outil d’emailing et par quelle API partiront-ils, et qui paiera l’abonnement ?

Qui configurera SPF, DKIM et DMARC sur le domaine, et quand ? Que se passe-t-il si l’outil d’envoi est indisponible, et où consulter le journal des envois ?

Comment le consentement à la newsletter est-il recueilli, horodaté et conservé ? Une désinscription faite d’un côté est-elle bien reprise de l’autre ?

Un prestataire qui répond clairement à ces questions vous évite de découvrir le problème par vos clients, le jour où leurs e-mails de connexion n’arrivent plus.

Questions fréquentes

Sources citées dans cette page

1. cybalgo.comhttps://cybalgo.com