Concevoir l'envoi d'e-mails groupés pour les PME sans s'enfermer dans un service spécifique

« Nous voulons envoyer des e-mails d’information à des dizaines ou des centaines de destinataires en utilisant notre domaine et notre site existants, sans ajouter un nouveau service de newsletter dédié. » La réponse réaliste à cette demande n’est pas un envoi groupé en Cci, mais une petite infrastructure d’envoi réunissant envoi individuel par destinataire, gestion des abonnements, désabonnement et SPF / DKIM / DMARC.

Ici, « ne pas utiliser de service spécifique » ne signifie pas « ne rien utiliser du tout ». Cela signifie conserver de son côté le standard SMTP, la liste des abonnés, les modèles et le parcours de désabonnement, et structurer les choses de sorte que seul le mécanisme d’envoi puisse être remplacé plus tard.

Par ailleurs, cet article part du principe qu’il s’agit d’e-mails envoyés à des personnes avec lesquelles existe une relation ou un consentement quelconque — clients existants, membres, personnes ayant demandé de la documentation, abonnés à la newsletter. Il ne s’agit pas de collecter des adresses publiques pour envoyer sans discernement. Les e-mails publicitaires et promotionnels sont soumis à des conditions légales préalables, et cette approche ne tient pas non plus dans la durée du point de vue de la délivrabilité.¹²

Ce qui suit s’appuie sur les informations publiques du gouvernement japonais relatives à la loi sur la réglementation de l’envoi de courrier électronique spécifié, ainsi que sur les directives d’expéditeurs de Google / Yahoo / Outlook, vérifiables en date d’avril 2026.¹²³⁴⁵

1. La conclusion d’abord

La forme réaliste pour une PME qui envoie des e-mails groupés à l’externe tient globalement en ces quatre points.

1. Envoyer individuellement, par destinataire Plutôt que d’empiler des adresses en Cci, construire la file d’attente sur la base d’un envoi message par message.
2. Posséder soi-même l’état des abonnements Conserver une gestion d’état explicite — active, unsubscribed, bounced — dans sa propre base de données ou un CSV.
3. Accepter automatiquement les désabonnements Ne pas gérer manuellement les demandes « ne m’envoyez plus rien ». Inclure un lien visible dans le corps du message et, si possible, un en-tête List-Unsubscribe.³⁴⁵
4. Authentifier le domaine d’envoi Mettre en place SPF / DKIM / DMARC, PTR inverse et TLS. Même si l’e-mail part, sans cela il a du mal à arriver.³⁴⁵

En résumé, ce n’est pas une question de manipulation du logiciel de messagerie, mais une question d’infrastructure d’envoi.

Si l’on interprète l’exigence « nous voulons envoyer à tout le monde d’un coup » comme « empiler beaucoup d’adresses dans À / Cc / Cci », cela s’effondre. Ce dont on a réellement besoin, c’est d’un mécanisme pour déterminer :

• Qui peut être contacté
• Qui ne doit plus être contacté
• Dans quel but le consentement a été obtenu
• Comment les désabonnements sont reçus
• Si la configuration vous rend fiable en tant qu’expéditeur

2. Pourquoi un envoi groupé en Cci ne suffit pas

Ce qui rend le Cci pénible pour un envoi groupé vers l’extérieur, c’est que malgré son apparente simplicité, il ne fournit aucune substance opérationnelle.

Ce qui est particulièrement dangereux, c’est que « l’envoi » fonctionne, donc cela ressemble à un système opérationnel. En réalité, sans exclusion, sans contrôle des rebonds, sans traces de consentement et sans journaux d’envoi, l’opération manuelle s’effondre dès que la liste grossit un peu.

Le Cci n’est pas entièrement mauvais. Pour une communication interne, une très petite annonce à un groupe fermé de membres, ou une note ponctuelle à des parties prenantes, cela peut très bien fonctionner. Le point est qu’il est faible comme fondation d’un système qui envoie en continu à des clients externes et des prospects.

3. Ce que signifie réellement « ne pas utiliser de service spécifique »

L’erreur d’interprétation fréquente ici est de croire que « ne pas utiliser de service spécifique » équivaut à « tout faire à la main ».

En pratique, si vous possédez ces trois éléments de votre côté, vous évitez la majeure partie du verrouillage fournisseur.

3.1 Ce que vous devez posséder

• Les données des abonnés
  • Adresse e-mail
  • Date et heure du consentement
  • Source du consentement
  • Catégorie d’envoi
  • État du désabonnement
• Les règles d’envoi
  • Quoi envoyer à qui
  • À quel débit
  • Comment les rebonds et désabonnements sont répercutés
• L’identité de l’expéditeur
  • Domaine d’envoi
  • SPF / DKIM / DMARC
  • Une adresse capable de recevoir des réponses
  • L’URL de désabonnement

3.2 Ce qui peut être remplacé

• Le relais SMTP qui transmet réellement les messages
• La façon dont l’écran d’administration est implémenté
• L’endroit où la file d’attente d’envoi est implémentée
• L’endroit où les journaux sont stockés

Autrement dit, l’essence de « ne pas utiliser de service » est de ne pas céder entièrement vos règles et votre état d’envoi à l’autre partie.

• La liste des destinataires réside dans votre propre base de données
• L’URL de désabonnement réside sous votre propre domaine
• Vous possédez les modèles d’objet et de corps de message
• Seule la sortie SMTP peut être remplacée plus tard

Sous cette forme, vous pouvez démarrer avec votre infrastructure de messagerie existante et migrer plus tard vers un autre mécanisme d’envoi.

4. Une configuration réaliste pour une PME

4.1 Les composants minimaux

À l’échelle de dizaines à centaines de messages par envoi, rien de grandiose n’est nécessaire dès le départ. Mais il est plus stable de séparer au minimum les éléments suivants.

1. Table des abonnés
2. Table d’exclusion
   • Désabonnements
   • Rebonds définitifs (hard bounces)
   • Plaintes
3. Modèles d’envoi
   • Objet
   • Corps (HTML / texte)
   • Catégorie d’envoi
4. File d’attente d’envoi
   • État par destinataire
   • Résultat de l’envoi
   • Nombre de tentatives
5. Relais SMTP
   • Utiliser l’infrastructure de messagerie existante, ou
   • exploiter son propre serveur
6. Journaux
   • Quand et à qui vous avez envoyé
   • Succès / échec
   • Mises à jour de l’exclusion / des rebonds

Une mesure sophistiquée des taux d’ouverture et de clic n’est pas indispensable dès le premier jour. Ce qu’il faut en priorité, c’est la capacité d’envoyer en sécurité, de s’arrêter et de pouvoir s’expliquer.

4.2 Champs que la table des destinataires doit contenir

L’ensemble minimal ressemble à ceci.

Même si votre fichier maître initial est une feuille Excel ou un fichier clients existant, il vaut la peine de séparer les choses à ce niveau. Ce qui compte le plus, c’est que l’information d’exclusion l’emporte toujours.

Par exemple, même si l’adresse de la personne subsiste dans le fichier commercial, ne pas envoyer si la table d’exclusion indique unsubscribed. Sans cette règle, les adresses reviennent par une autre voie après un désabonnement et cela cause un incident.

4.3 Schéma d’architecture

flowchart LR
    A[Site web / formulaire d'abonnement] --> B[Table des abonnés]
    A2[Fichier clients existant / fichier membres] --> B

    C[Modèles d'envoi<br/>objet / HTML / texte] --> D[File d'attente d'envoi]
    B --> D
    E[Table d'exclusion<br/>désabonnements / rebonds / plaintes] --> D

    D --> F[Relais SMTP<br/>infrastructure existante ou relais maison]
    F --> G[Destinataires]

    G --> H[URL de désabonnement]
    G --> I[Réponses]
    G --> J[Rebonds / plaintes]

    H --> E
    J --> E
    I --> K[Contact opérationnel]

    L[SPF / DKIM / DMARC / PTR / TLS] --> F

Le point clé de ce schéma est que le mécanisme d’envoi n’est pas le centre. Le centre, c’est la table des abonnés, la table d'exclusion et la file d'attente d'envoi.

Le relais SMTP n’est que la sortie. Grâce à cette séparation, vous pouvez changer de mécanisme d’envoi à l’avenir sans perdre les désabonnements et l’historique de consentement passés.

5. Jusqu’où aller selon l’échelle

5.1 Une fois par mois, quelques dizaines de destinataires

À cette échelle, la configuration minimale suffit souvent.

• Un modèle de publipostage dédié à l’envoi
• Un envoi individuel par destinataire
• Une URL de désabonnement
• La conservation des journaux d’envoi
• SPF / DKIM / DMARC en place

Le point ici est de ne pas revenir au Cci simplement parce que la liste est petite. Même en dessous de 50 destinataires, pour un envoi continu vers l’extérieur, il vaut mieux adopter dès maintenant la forme envoi individuel + gestion d'état.

5.2 Plusieurs fois par mois, quelques centaines de destinataires

À ce stade, quelques ajouts rendent les choses plus stables.

• Une file d’attente d’envoi
• Un contrôle du débit d’envoi
• Le traitement des rebonds
• L’application immédiate des désabonnements
• Un sous-domaine dédié à l’envoi
• Un circuit de validation
  • Envoi de test
  • Envoi en production
  • Vérification des résultats

Il importe également de séparer les e-mails humains du quotidien des e-mails promotionnels et d’information. Google décrit la séparation des adresses From et des IP par type de message, et Yahoo conseille de même de ne pas mélanger le bulk / marketing avec le transactionnel / les alertes sur la même IP ou le même domaine DKIM.³⁴

Par exemple, simplement séparer les adresses par usage structure déjà considérablement l’exploitation.³⁴⁵

• Confirmations de commande et facturation : billing@example.com
• Notifications de panne et informations de maintenance : notice@example.com
• Newsletter et annonces : news@example.com

5.3 À l’approche de plusieurs milliers de messages par jour

À ce stade, « ne pas utiliser de service spécifique » devient facilement une fin en soi.

Pour Gmail, Google détaille des exigences pour les expéditeurs de plus de 5 000 messages par jour : SPF / DKIM / DMARC, alignement du domaine From, désabonnement en un clic, et davantage. Outlook exige de même SPF / DKIM / DMARC pour les domaines envoyant plus de 5 000 messages par jour et prévient que les messages non conformes peuvent être classés comme indésirables ou rejetés.³⁵

À cette échelle, les sujets opérationnels changent également.

• Réputation IP
• Taux de plaintes
• Taux de rebond
• Traitement des désabonnements
• Façon de monter en volume
• Surveillance

À ce stade, il existe de nombreux cas où un service dédié est effectivement moins cher.

Ainsi, la conclusion de cet article n’est pas « tout construire soi-même quelle que soit l’échelle », mais plutôt : à l’échelle de dizaines à centaines de messages par envoi, une petite infrastructure d’envoi où vous possédez l’état et les règles est tout à fait adaptée.

6. Le minimum incontournable en matière juridique et de délivrabilité

6.1 Le consentement

Les e-mails publicitaires et promotionnels requièrent en principe un consentement préalable. Les recommandations du centre de consultation anti-spam japonais indiquent également que l’envoi d’e-mails publicitaires sans consentement préalable n’est en principe pas autorisé.²

Google et Yahoo exigent de même de n’envoyer que les e-mails explicitement demandés par le destinataire, de ne pas utiliser de listes achetées et d’éviter les cases d’opt-in précochées.³⁴

Ce qu’il faut conserver au minimum en pratique est ceci :

• La date et l’heure du consentement
• La source du consentement
• L’objet de l’envoi
• Le texte explicatif
• L’écran ou le texte par lequel le consentement a été obtenu

Notez que la loi prévoit bien une exception pour l’envoi à des adresses professionnelles publiées sur un site web. Cependant, il est déconseillé de construire son infrastructure d’envoi en s’appuyant sur cette exception. Que l’on considère les réclamations, la délivrabilité, la réputation ou le taux de réponse réel, cela ne tient pas dans la durée.²

6.2 Les obligations d’affichage et le désabonnement

Même en envoyant à des destinataires consentants, l’expéditeur a des obligations d’affichage. Selon les recommandations du centre de consultation anti-spam, au moins les informations suivantes sont requises.²

• Le nom ou la dénomination de l’expéditeur
• Une adresse e-mail ou une URL permettant de recevoir les notifications de refus de réception
• Une mention indiquant que le destinataire peut refuser de recevoir les envois
• L’adresse postale de l’expéditeur
• Un point de contact pour les réclamations et les demandes

Le pied de page doit donc au minimum contenir ceci.

Expéditeur : Société ○○
Désabonnement : https://example.com/unsubscribe/xxxxx
Pour vous désabonner, veuillez utiliser l'URL ci-dessus.
Adresse : Tokyo, ...
Contact : support@example.com

Par ailleurs, les principaux récepteurs accordent une grande importance à la facilité de désabonnement.

• Google : exige un désabonnement en un clic pour les expéditeurs en volume³
• Yahoo : exige / recommande List-Unsubscribe accompagné d’un lien dans le corps, à honorer sous 2 jours⁴
• Outlook : recommande un désabonnement facile à trouver et fonctionnel⁵

Le minimum naturel est donc un lien visible dans le corps du message, ainsi que, si possible, les en-têtes suivants.³⁴

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxxx>

6.3 Authentification et délivrabilité

Les principaux récepteurs partent désormais du principe non plus de « pouvoir envoyer » mais d’« être authentifié ».

Les directives publiques de Google exigent ce qui suit.³

• Tous les expéditeurs : SPF ou DKIM, PTR (correspondance DNS directe / inverse), TLS
• Expéditeurs en volume : SPF + DKIM + DMARC, alignement du domaine From
• Un faible taux de spam
• Désabonnement en un clic pour les expéditeurs en volume

Les exigences de Yahoo sont les suivantes.⁴

• SPF / DKIM / DMARC
• Alignement DMARC
• DNS direct / inverse valide
• Désabonnement
• Taux de spam inférieur à 0,3 %
• Opt-in
• Séparation entre bulk et transactionnel

Outlook publie également des exigences pour les expéditeurs à fort volume.⁵

• SPF pass
• DKIM pass
• DMARC (au moins p=none, aligné avec SPF ou DKIM)
• Un From / Reply-To authentique
• Désabonnement
• Hygiène de la liste

Les contrôles opérationnels minimaux, sous forme de tableau :

Google recommande de monter en volume en partant bas, vers des destinataires engagés, à un rythme régulier. Les pics soudains et les doublements du jour au lendemain tendent à provoquer une limitation et une perte de réputation.³

7. Comment procéder à l’implémentation

Pour un démarrage minimal, un ordre réaliste ressemble à ceci.

1. Séparer les types de messages envoyés
   • E-mails de notification
   • Newsletter
   • Annonces de séminaires
   • Annonces aux clients existants
2. Construire un formulaire d’abonnement ou un flux de recueil du consentement Rendre possible le recueil du consentement sur le site web, accompagné d’un texte explicatif. Il importe que le texte précise clairement « ce qui arrive, et à quelle fréquence ».⁴
3. Séparer la table des abonnés de la table d’exclusion Séparer ces éléments dès le départ permet à l’exploitation de rester intacte quel que soit le système vers lequel vous migrez plus tard.
4. Choisir un domaine / sous-domaine dédié à l’envoi Par exemple news.example.com ou mail.example.com. Au minimum, ne pas mélanger les responsabilités avec le trafic de commandes du quotidien et les boîtes aux lettres personnelles.³⁴
5. Mettre en place SPF / DKIM / DMARC / PTR / TLS Si vous envoyez vous-même, c’est la priorité absolue. Ne faites pas d’un environnement sans DNS inverse votre infrastructure d’envoi.³⁴
6. Construire un écran d’administration — même petit, cela suffit Ce qu’il faut, ce n’est pas une interface sophistiquée, mais les fonctions suivantes :
   • Édition de l’objet
   • Édition du corps
   • Envoi de test
   • Envoi en production
   • Aperçu des destinataires
   • Réglage de la taille des lots
   • Vérification des résultats
7. Commencer par de petits volumes Se limiter aux clients existants et aux abonnés engagés, et envoyer à un rythme régulier. Si rien ne pose problème, élargir l’audience.³
8. Appliquer les désabonnements et les rebonds en priorité absolue Vérifier que cela fonctionne avant de se préoccuper des taux d’ouverture.

Dans cet ordre, on arrive non pas à « on peut techniquement envoyer » mais à « on peut continuer sans incident ».

Si la revue s’étend au formulaire d’abonnement, au texte de consentement et à la page de désabonnement, il est plus simple de l’organiser en même temps que la création de site web. Si, en revanche, la prémisse est de se connecter à un fichier clients existant, à des systèmes internes ou à des outils Windows, il est plus sûr de partir de la répartition des responsabilités dans le cadre d’une consultation technique / revue de conception.

8. Les erreurs fréquentes

Voici les cas habituels.

• Faire tourner les e-mails humains du quotidien et les e-mails promotionnels/d’information depuis le même expéditeur
• Gérer le consentement uniquement via des notes en texte libre
• Traiter les désabonnements manuellement par réponse e-mail
• Déverser en bloc une ancienne liste de cartes de visite
• Se mettre soudainement à envoyer au plus grand volume jamais atteint
• Mélanger du texte promotionnel dans les e-mails de notification
• S’arrêter à « l’API d’envoi a renvoyé un succès » comme résultat d’envoi
• Une table d’exclusion plus faible que le fichier clients existant

Le dernier point en particulier provoque de véritables incidents.

Une adresse subsiste dans le fichier Excel du service commercial. Mais cette personne s’est déjà désabonnée de la newsletter. À moins que la règle ne soit que l’information d’exclusion l’emporte toujours, elle sera renvoyée encore et encore par d’autres voies.

9. Résumé

Si une PME souhaite envoyer un e-mail à une audience raisonnablement large sans service spécifique, la question à se poser n’est pas « quel bouton presser ».

Ce qui est réellement nécessaire tient en ces cinq points.

• L’envoi individuel par destinataire, et non un envoi groupé en Cci
• Une table des abonnés et une table d’exclusion
• Un parcours qui accepte les désabonnements automatiquement
• SPF / DKIM / DMARC / PTR / TLS
• Une exploitation qui sépare les notifications des promotions

En définitive, posséder les règles d’envoi passe avant posséder le mécanisme d’envoi.

À l’échelle de dizaines à centaines de messages par envoi, on peut parfaitement se passer d’un service dédié. Mais même dans ce cas, le raccourci consiste à le concevoir comme une petite infrastructure d’envoi — et non à « envoyer en masse depuis un client de messagerie ».

Articles connexes

• Les trois points à corriger en priorité sur un site qui ne génère aucune demande
• Comment relier les articles et les pages de services - Les bases de la conception des liens internes

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi l'envoi groupé d'e-mails en Cci est-il une mauvaise idée ?

Un envoi en Cci en un seul coup paraît simple, mais ne fournit aucune substance opérationnelle. Les désabonnements ne peuvent pas être suivis, les rebonds ne sont pas gérés, il n'existe aucune trace du consentement, il n'y a aucun contrôle sur le débit d'envoi, et les e-mails commerciaux finissent mélangés aux e-mails de notification du quotidien. Ce qui rend cette pratique dangereuse, c'est que l'envoi fonctionne, donc cela ressemble à un système opérationnel — mais sans liste d'exclusion, sans traces de consentement et sans journaux d'envoi, l'opération manuelle s'effondre dès que la liste grossit un peu.

Faut-il SPF, DKIM et DMARC pour envoyer des e-mails groupés ?

Oui. Les grands récepteurs comme Google, Yahoo et Outlook partent désormais du principe que l'expéditeur est authentifié, et un e-mail sans SPF, DKIM et DMARC a du mal à arriver même s'il part bien. Google exige des expéditeurs en volume qu'ils configurent SPF, DKIM et DMARC avec un alignement du domaine From, ainsi qu'un désabonnement en un clic, et Google comme Outlook détaillent des exigences pour les expéditeurs de plus de 5 000 messages par jour. Un enregistrement PTR inverse résolvable et le TLS font également partie du socle minimal.

Le consentement est-il nécessaire avant d'envoyer un e-mail publicitaire ?

En règle générale, oui. En vertu de la loi japonaise anti-spam (loi sur la réglementation de l'envoi de courrier électronique spécifié), l'envoi d'e-mails publicitaires sans consentement préalable n'est en principe pas autorisé, et Google comme Yahoo exigent de même de n'envoyer que les e-mails explicitement demandés par le destinataire, sans listes achetées ni cases d'opt-in précochées. En pratique, il faut conserver la date et l'heure du consentement, la source du consentement, l'objet de l'envoi consenti et le texte explicatif. La loi prévoit une exception pour les adresses professionnelles publiées sur un site web, mais construire son infrastructure d'envoi sur cette exception ne tient pas la route en termes de réclamations, de délivrabilité ni de taux de réponse.

À partir de quelle échelle un service d'e-mailing dédié devient-il plus pertinent ?

À l'échelle de dizaines à centaines de destinataires par envoi, une petite infrastructure d'envoi maison avec envoi individuel par destinataire, une table des abonnés, une table d'exclusion et une authentification correcte est tout à fait adaptée. À l'approche de milliers d'e-mails par jour, les sujets opérationnels changent pour se concentrer sur la réputation IP, les taux de plaintes, les taux de rebond et la montée en volume, et à ce stade un service dédié est souvent effectivement moins cher. La clé est de posséder ses données d'abonnés, ses règles d'envoi et son identité d'expéditeur, de sorte que seule la sortie SMTP ait besoin d'être remplacée plus tard.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.