Un abonné qui reçoit une newsletter automatique où le premier article est en français et le deuxième en anglais, dans le même e-mail : c’est le résultat obtenu par un site d’actualité multilingue qui avait simplement connecté un flux RSS global à Sendinblue, sans se poser la question de la langue au moment de la configuration du flux.
Ce cas se distingue nettement de la configuration technique de l’envoi d’e-mails transactionnels ou du relais SMTP, déjà traité sous l’angle de l’hébergement : ici, le sujet n’est pas de savoir si l’e-mail part correctement, mais de s’assurer que son contenu correspond à la langue de lecture de chaque abonné.
Le piège du flux RSS unique sur un site multilingue
WordPress génère par défaut un flux RSS par langue quand une extension multilingue comme Polylang ou WPML est active, mais uniquement si on va le chercher à la bonne adresse. Le flux générique /feed/ continue souvent, selon la configuration, à mélanger les contenus de toutes les langues, ou à ne suivre que la langue par défaut du site sans que personne ne l’ait explicitement décidé.
La newsletter automatique Sendinblue, configurée pour lire ce flux générique, recopiait donc fidèlement ce mélange, sans qu’aucun réglage Sendinblue ne puisse corriger un problème dont l’origine se trouvait entièrement du côté du flux source WordPress.
Un flux RSS distinct par langue, filtré à la source

La correction consiste à générer un flux RSS filtré par langue, directement dans WordPress, en s’appuyant sur les fonctions de l’extension multilingue pour restreindre la requête du flux à une seule langue :
<?php
add_action( 'pre_get_posts', function( $query ) {
if ( $query->is_feed( 'fr-only' ) && $query->is_main_query() ) {
$query->set( 'lang', 'fr' );
}
if ( $query->is_feed( 'en-only' ) && $query->is_main_query() ) {
$query->set( 'lang', 'en' );
}
} );
add_feed( 'fr-only', 'do_feed_rss2' );
add_feed( 'en-only', 'do_feed_rss2' );
Chaque flux, accessible à une adresse dédiée (/feed/fr-only/, /feed/en-only/), ne contient plus que les articles de sa langue. Trois flux ont ainsi été créés pour les trois langues du site, chacun connecté à une campagne Sendinblue distincte plutôt qu’à une seule campagne automatique générique.
Une liste de contacts par langue, pas une seule liste globale segmentée en aval
Le deuxième changement structurant a porté sur la gestion des contacts dans Sendinblue : plutôt qu’une liste unique avec un attribut de langue utilisé pour filtrer au moment de l’envoi (une approche qui fonctionne mais complexifie chaque campagne), le choix a été fait de créer une liste dédiée par langue, alimentée directement par le formulaire d’inscription du site correspondant.
- Le formulaire d’inscription à la newsletter, affiché sur chaque version linguistique du site, transmet un identifiant de liste Sendinblue différent selon la langue de la page
- Chaque campagne automatique RSS-to-email de Sendinblue est associée à une seule liste et un seul flux, dans la même langue
- Un abonné qui change de préférence de langue doit être déplacé manuellement, ou via une automatisation Sendinblue dédiée, d’une liste à l’autre
Le cas des abonnés inscrits avant la mise en place du multilingue
Les abonnés historiques, inscrits avant que le site ne distingue ses langues, ont posé un problème distinct : impossible de déduire leur langue de lecture réelle a posteriori. Le choix retenu a été de leur envoyer un e-mail ponctuel, dans les deux langues principales du site, leur demandant explicitement de confirmer leur préférence de langue via un lien, plutôt que de deviner et risquer de les inscrire dans la mauvaise liste.
En résumé
Une newsletter automatique générée par flux RSS ne respecte la langue de chaque abonné que si le flux source lui-même est filtré par langue en amont, ce qu’aucun réglage côté Sendinblue ne peut corriger après coup. La bonne architecture repose sur un flux RSS dédié par langue côté WordPress, couplé à une liste de contacts et une campagne automatique distinctes par langue côté outil d’e-mailing.