Générer et envoyer une newsletter automatique depuis un flux RSS avec l'IA dans n8n

Beaucoup d'équipes qui produisent du contenu ou font de la veille savent qu'une newsletter régulière fidélise mieux qu'un flux RSS que personne ne consulte — et savent tout aussi bien pourquoi elles n'en envoient pas : sélectionner les bons articles, les résumer et composer l'email prend une bonne matinée chaque semaine, un temps que peu d'équipes s'accordent durablement. Une étude portant sur le contenu de neuf newsletters de grandes rédactions américaines, Seely & Spillman (2021), Email Newsletters: An Analysis of Content From Nine Top News Organizations, publiée dans Electronic News (Google Scholar), montre que les newsletters qui fonctionnent reposent avant tout sur deux techniques : la synthèse (condenser l'essentiel d'un article) et le commentaire éditorial court qui replace l'information dans son contexte — exactement ce qu'un LLM bien cadré sait produire à partir d'un extrait de flux RSS. Ce guide construit le pipeline complet dans n8n : collecte multi-sources, sélection et résumé par IA, mise en page HTML, envoi via Brevo.

L'architecture en cinq étages

Le pipeline reprend la même colonne vertébrale qu'une veille RSS classique, avec deux étages supplémentaires en sortie :

1. Collecte — lire les flux RSS de vos sources de référence.
2. Déduplication et filtrage — ne garder que le neuf, pertinent pour votre audience.
3. Sélection et résumé par IA — un LLM classe les articles restants et rédige un résumé éditorial court pour les meilleurs.
4. Composition — assembler les blocs retenus en un email HTML propre.
5. Envoi — déclencher la campagne via Brevo, à une cadence fixe (hebdomadaire dans la plupart des cas).

Étage 1 — Collecter plusieurs flux RSS

Un Schedule Trigger (voir notre guide du Schedule Trigger et des fuseaux horaires) démarre le workflow, par exemple chaque lundi à 6 h. Il déroule une liste de flux — stockée dans une Data Table n8n ou un Google Sheet plutôt qu'en dur dans le workflow — via une boucle Loop Over Items qui appelle un node RSS Feed Read par source. Activez « Continue On Fail » sur ce node : un flux temporairement indisponible ne doit pas faire échouer toute la newsletter de la semaine.

Étage 2 — Dédupliquer et filtrer avant tout appel IA

Deux nodes protègent la suite du pipeline :

• Remove Duplicates, en mode « Remove Items Processed in Previous Executions » avec le lien de l'article comme clé, garantit qu'un article déjà envoyé dans une édition précédente ne réapparaît pas. Le fonctionnement détaillé est dans notre guide du node Remove Duplicates.
• Filter écarte ce qui ne correspond manifestement pas à la ligne éditoriale (mots-clés à exclure, date de publication trop ancienne). Ce filtrage mécanique, gratuit, réduit d'autant le volume envoyé au LLM à l'étage suivant — le vrai levier de coût du pipeline.

Étage 3 — Sélectionner et résumer avec un LLM

C'est ici que la newsletter prend forme. Un node Basic LLM Chain (voir la différence avec l'AI Agent node si vous hésitez entre les deux) reçoit la liste des articles filtrés — titre et extrait uniquement, jamais le contenu intégral inventé ou complété — avec une consigne stricte :

• classer les articles par pertinence pour l'audience cible ;
• ne retenir que les 5 à 8 meilleurs ;
• rédiger, pour chacun, un résumé de deux phrases maximum en s'appuyant exclusivement sur le texte fourni, dans un ton éditorial sobre plutôt que promotionnel ;
• ne jamais ajouter de fait, de chiffre ou de citation absent de l'extrait source.

Un Structured Output Parser (détaillé dans notre guide dédié) force la réponse dans un schéma JSON strict — titre, resume, lien, categorie — pour que l'étage de composition n'ait jamais à parser du texte libre. Si vos flux renvoient des articles longs, un node Summarize en amont peut pré-condenser le corps avant de le passer au LLM de sélection, ce qui réduit encore le coût en tokens.

Étage 4 — Composer l'email HTML

Un node Code transforme le tableau JSON structuré en HTML : un bloc par article (titre en lien cliquable, résumé, catégorie en badge), encadré d'un en-tête et d'un pied de page fixes contenant le lien de désinscription — obligatoire, et généré automatiquement par Brevo si vous passez par ses campagnes plutôt que par un envoi transactionnel brut. Gardez ce template simple : une colonne, peu d'images, du texte lisible sans chargement d'images côté client — c'est aussi ce qui limite le risque de finir en spam.

Avant l'envoi, un IF vérifie que le nombre d'articles retenus dépasse un seuil minimal (3 par exemple) : sous ce seuil, le workflow notifie l'équipe sur Slack plutôt que d'envoyer une édition trop maigre.

Étage 5 — Envoyer via Brevo

Le node Brevo natif de n8n couvre les contacts et l'envoi transactionnel, mais pas la création de campagnes marketing : pour ça, un node HTTP Request appelle l'endpoint POST /v3/emailCampaigns de l'API Brevo avec le même credential (header api-key), en lui passant le sujet, l'expéditeur, la liste destinataire et le HTML composé à l'étage précédent. Deux options ensuite : déclencher l'envoi immédiat via POST /v3/emailCampaigns/{id}/sendNow, ou laisser la campagne en brouillon pour une dernière relecture humaine dans l'interface Brevo avant le départ — recommandé pour les premières éditions, le temps de faire confiance au pipeline.

Fiabiliser avant la mise en production

• Relecture humaine au démarrage. Plutôt que d'appeler directement l'envoi, postez le brouillon HTML dans Slack ou envoyez-le à une seule adresse de test, avec un node Wait qui attend une validation avant de déclencher l'envoi réel — le même principe d'approbation humaine décrit pour d'autres automatisations sensibles.
• Traçabilité. Journalisez chaque édition envoyée (date, articles retenus, nombre de destinataires) dans une table Supabase : utile pour mesurer ce qui fonctionne et pour retrouver rapidement ce qui a été envoyé en cas de question d'un abonné.
• Coût maîtrisé. Avec un modèle économique (gpt-4o-mini ou équivalent) et un filtrage mécanique en amont, la sélection et la rédaction d'une édition hebdomadaire de 5 à 8 articles coûte typiquement quelques centimes en appels API.
• Erreurs non bloquantes. Branchez un workflow d'erreur sur l'ensemble : un flux RSS en panne ou un appel Brevo qui échoue doit alerter l'équipe, jamais interrompre silencieusement la newsletter de la semaine.

Aller plus loin avec un pack FlowKit

Le pattern collecte → scoring IA → digest est déjà celui du workflow digest quotidien Slack du Pack Inbox IA (79 €), qui trie et résume vos emails avec la même logique de scoring structuré — directement adaptable si vous préférez livrer votre veille en interne avant de la transformer en newsletter externe. Les deux pipelines partagent la même ossature n8n : LLM Chain, Structured Output Parser, mise en file Supabase.

Check-list de mise en route

• Liste de flux RSS externalisée (Data Table ou Sheet), avec Continue On Fail activé.
• Remove Duplicates en mode « Previous Executions » sur le lien de l'article.
• Prompt de sélection strict : résumer uniquement le texte fourni, jamais inventer.
• Structured Output Parser pour un JSON fiable en sortie du LLM.
• Seuil minimal d'articles avant envoi, avec alerte Slack en dessous.
• Première phase en relecture humaine avant l'envoi automatique complet.
• Journalisation Supabase de chaque édition envoyée.

Une newsletter automatisée de cette façon ne remplace pas un vrai regard éditorial — elle le rend simplement soutenable dans la durée : le LLM fait le tri et le premier jet de rédaction, un humain garde la main sur la validation tant que la confiance dans le pipeline n'est pas établie. C'est la même logique que les packs FlowKit appliquent aux emails ou aux tickets support : automatiser le tri répétitif, garder l'humain sur la décision qui compte.