Veille automatisée avec n8n : filtrer au lieu d'accumuler

La dépréciation de MySQL dans n8n était écrite noir sur blanc, des semaines avant que le couperet tombe, dans une note de migration que tout le monde a survolée. Ceux qui l’ont vue ont migré leur base vers PostgreSQL un dimanche tranquille, à tête reposée. Les autres ont fait un docker compose pull un soir, et leur instance n’est jamais revenue.

La veille existe précisément pour éviter ça. Et elle échoue presque à chaque fois, pour une raison qui n’a rien à voir avec la collecte : les informations arrivent, par dizaines, chaque jour, et personne ne les lit. Un agrégateur RSS bien rempli qui affiche 200 éléments non lus protège exactement autant qu’aucun agrégateur du tout. Ajouter une source de plus à ce tas ne résout rien, ça l’épaissit. Marquer tout comme lu chaque matin pour tout recommencer le lendemain, c’est le rocher de Sisyphe, ce personnage condamné à remonter éternellement sa pierre, que la philosophie de Camus a rendu célèbre.

Ce guide construit donc autre chose qu’un agrégateur : un système qui collecte partout, y compris là où il n’y a pas de flux RSS, qui déduplique, qui élimine 80 % du volume avec un filtre gratuit avant de payer le moindre appel à un modèle, puis qui classe chaque information restante contre ton profil réel, dans une des trois seules catégories qui comptent. Le tout sur n8n, avec le calcul des coûts posé hypothèses comprises, les pannes prévisibles documentées, et le fichier OPML des sources en téléchargement pour démarrer sans repartir de zéro.

Ce qu’il te faut

• une instance n8n, auto-hébergée ou cloud, avec les Data Tables disponibles
• une clé API Anthropic pour le scoring (budget chiffré plus bas, quelques dollars par mois)
• un bot Telegram, ou un canal Slack, pour les alertes
• une demi-journée pour la première version, puis deux semaines de calibrage passif

Les trois catégories d’information qui comptent en veille

Avant le premier nœud, le principe qui structure tout le système : une information de veille appartient à une des trois catégories, et chacune mérite un traitement différent. La première, ce qui va casser ta production : dépréciations, breaking changes, fins de support, failles, changements d’API ou de tarif sur un outil que tu opères. Un changement de règle sur une plateforme publicitaire mérite le même suivi lorsqu’il modifie tes décisions marketing. Cette catégorie exige une interruption, aujourd’hui, parce qu’une information ratée ici se paie en pannes. La deuxième, ce qui devrait changer ta pratique : une nouvelle fonctionnalité d’un outil de ta stack, un nœud qui remplace ton bricolage actuel, une méthode documentée. Cette catégorie mérite une lecture posée, en fin de semaine, jamais une interruption. La troisième, le bruit sectoriel : levées de fonds, opinions, marketing, annonces d’outils que tu n’utiliseras pas. Cette catégorie mérite une archive et le silence.

Trois catégories, donc trois destinations, et c’est toute l’architecture : une alerte immédiate pour la première, un digest hebdomadaire pour la deuxième, une archive muette pour la troisième. Chaque étage du système qui suit, collecte, déduplication, filtre, scoring, existe pour router chaque item vers la bonne destination sans que tu touches à rien. La machine trie, toi tu décides.

Collecter partout, même sans flux RSS

Le routage suppose d’abord d’avoir la matière, et c’est là que la plupart des veilles ratent des informations décisives : les annonces qui cassent la production paraissent d’abord dans des changelogs, des pages de releases et des forums, bien avant les blogs, et une partie de ces endroits n’expose aucun flux visible. Le vrai travail de collecte consiste à fabriquer un flux pour chacun de ces endroits, et il existe une recette pour presque tous les cas. Le tableau les réunit.

Côté n8n, toutes les lignes RSS et Atom de ce tableau se lisent avec le nœud RSS Read, appelé par un Schedule Trigger (il existe aussi un déclencheur RSS Feed Trigger, mais un passage planifié une à deux fois par jour donne un contrôle plus fin du débit). Pour GitHub, vérifie toujours le flux du dépôt ciblé et garde en repli l’API officielle des releases : elle fournit notamment le nom, la version et la date de publication sans dépendre d’une URL de flux non documentée.

Les newsletters demandent un détour : leur canal natif est l’email, pas le flux. Crée un alias dédié, réabonne-toi avec cette adresse, et un nœud Email Trigger (IMAP) de n8n récupère chaque numéro ; le nœud HTML en extrait ensuite le texte utile. L’alias dédié a un double intérêt : il isole la veille de ta vraie boîte, et il transforme chaque newsletter en source structurée, avec expéditeur et date, comme n’importe quel flux.

Reste le cas le plus retors : le changelog sans flux, la page que l’éditeur met à jour sans jamais rien émettre. La solution tient en un mini-workflow : récupérer la page, isoler la zone utile, en calculer l’empreinte, comparer à la dernière empreinte connue.

Concrètement : Schedule Trigger deux fois par semaine, HTTP Request en GET sur la page, un nœud HTML qui extrait le bloc principal (un sélecteur CSS sur le conteneur du changelog, pour ignorer menus et pieds de page), le nœud Crypto de n8n qui en calcule le hash SHA-256, puis une Data Table qui stocke la dernière empreinte par URL surveillée. Empreinte identique, fin de l’exécution ; empreinte différente, le workflow écrit la nouvelle valeur et injecte un item « changelog modifié, va voir » avec l’URL dans le pipeline. Ce flux maison signale seulement qu’un changement a eu lieu, sans dire lequel, et c’est suffisant : l’item traversera le scoring comme les autres, et une modification de changelog d’un outil de ta stack finit rarement en catégorie bruit.

Pour suivre plusieurs entreprises, leurs tarifs et leurs recrutements sans subir les faux changements du HTML dynamique, le guide consacré à la veille concurrentielle automatisée ajoute le nettoyage ciblé, la comparaison des états et une fiche concurrent persistante.

Pour t’éviter de reconstruire cette liste source par source, un fichier OPML la contient déjà : les releases GitHub des outils couverts sur ce blog, les communautés Discourse n8n et Make, les subreddits utiles et les requêtes Hacker News, importables dans n8n ou dans n’importe quel lecteur de flux, à élaguer selon ta stack. Il est dans l’espace ressources de la communauté, l’accès est gratuit : récupérer l’archive des sources de veille.

Dédupliquer, parce que la même annonce arrive cinq fois

Avec une vingtaine de sources en place, un phénomène apparaît dès le premier jour : la même annonce arrive par cinq canaux en quatre heures. La release sort sur GitHub, le forum Discourse la relaie, le subreddit en discute, la newsletter du vendredi la reprend, Hacker News la vote. Sans déduplication, ton système enverra cinq fois le même item au scoring, et potentiellement cinq alertes pour une seule information. À ce régime, tu couperas les notifications, et le système mourra avec.

La parade se joue à l’entrée du pipeline, en trois temps dans un nœud Code. D’abord la normalisation d’URL : suppression des paramètres de tracking (utm_*, fbclid, ref), du slash final et des ancres, passage de l’hôte en minuscules, pour que la même page partagée par trois canaux redevienne la même chaîne de caractères. Ensuite l’empreinte : le nœud Crypto hache cette URL normalisée, et ce hash devient l’identifiant unique de l’item. Enfin le second filet, pour les canaux qui reformulent l’URL (les posts Reddit et les newsletters pointent rarement l’URL d’origine) : un titre normalisé, minuscules, ponctuation et mots vides retirés, stocké à côté du hash. Un item entre dans le pipeline si son hash d’URL et son titre normalisé sont absents de la Data Table veille_vue ; sinon il meurt là, sans consommer un seul appel de plus.

Cette table veille_vue est le premier des trois usages des Data Tables de n8n dans ce système (les deux autres arrivent : l’archive et le suivi des sources). Un rappel utile de cet article : l’espace Data Tables est plafonné, donc la table des vus se purge, les entrées de plus de 90 jours peuvent partir sans risque, une annonce ne revit pas trois mois plus tard. Pas de zombies dans le pipeline.

Le pré-filtre lexical avant tout appel au modèle

Les items uniques qui sortent de la déduplication pourraient partir directement au scoring IA, et c’est l’erreur de conception la plus répandue des systèmes de veille : envoyer 200 items par jour à un modèle coûte de l’argent pour un travail qu’une liste de mots-clés fait gratuitement sur 80 % du volume. Une annonce qui ne mentionne ni un outil de ta stack, ni un de tes sujets de travail, ni un signal de danger générique n’a besoin d’aucune intelligence pour être classée bruit. Payer un modèle pour jeter des levées de fonds, autant glisser les billets directement dans le broyeur.

Le pré-filtre est un nœud Code avec deux listes. La liste d’inclusion contient les mots de ta stack et de tes sujets : les noms d’outils que tu opères (n8n, Make, PostgreSQL, Traefik, Docker…), tes sujets actifs (webhook, MCP, agent, signature…), et les mots de danger transverses (deprecated, breaking, EOL, CVE, vulnerability, pricing). La liste d’exclusion coupe ce qui n’a aucune chance de te concerner (funding, hiring, acquisition, giveaway). La règle : un item passe s’il contient au moins un mot d’inclusion et aucun mot d’exclusion dominant. Une exception assumée : les sources à passe-droit. Une release GitHub d’un outil que tu opères est pertinente par construction, elle saute le filtre lexical et va droit au scoring.

Ce filtre gratuit change l’économie du système, et le calcul mérite d’être posé en entier. Hypothèses : 200 items par jour, un appel de scoring qui consomme environ 700 tokens en entrée (le profil plus l’item) et 120 en sortie, et Claude Haiku 4.5 facturé 1 dollar le million de tokens d’entrée et 5 dollars le million en sortie, d’après la grille tarifaire officielle d’Anthropic vérifiée le 28 juillet 2026.

Huit dollars par mois restent modestes, et c’est le piège de ce tableau : conclure que le pré-filtre est optionnel. Multiplie les volumes par cinq, passe sur un modèle du tier supérieur pour affiner le jugement, et l’écart devient une vraie ligne de budget. Surtout, le pré-filtre rend un second service qui ne se lit pas dans le tableau : le modèle ne voit que des items plausibles, ce qui réduit mécaniquement ses occasions de mal classer du bruit exotique. Filtrer d’abord au lexique, juger ensuite au modèle : le videur vérifie la liste à l’entrée, le patron ne rencontre que les invités.

Le scoring contre ton profil déclaré

Les items survivants méritent maintenant un jugement, et la qualité de ce jugement dépend d’une seule chose : le modèle doit juger pour toi, pas dans l’absolu. La sortie d’un nouveau plugin Bubble est une information majeure pour un développeur Bubble et du bruit intégral pour quelqu’un qui opère trois VPS n8n. Sans profil déclaré, un modèle note l’importance intrinsèque de l’annonce, et tout ce qui est « objectivement notable » remonte, c’est-à-dire à peu près tout. Un juge sans dossier note tout le monde pareil.

Le prompt du nœud d’appel au modèle (le nœud Anthropic Claude, ou le modèle de ton choix) embarque donc ton profil complet et un barème fermé. Le voici, à adapter dans ses deux premiers blocs, le profil étant donné ici en exemple pour un freelance dont la stack ressemble à celle des guides de ce blog.

Tu es le filtre de veille d'un freelance en automatisation no-code.

Son profil, ton seul référentiel de jugement :
- Stack en production : n8n auto-hébergé sur VPS Debian (Docker Compose,
  Traefik, PostgreSQL, MinIO), DocuSeal, Typebot. Make chez certains
  clients. Claude et Mistral via API.
- Clients : PME francophones, e-commerce et services.
- Sujets de travail actifs : agents IA, MCP, webhooks, signature
  électronique, migrations de bases de données.
- Ne l'intéressent jamais : crypto, formations débutant, outils sans
  API ni plan accessible, actualité corporate sans impact produit.

Tu reçois un item de veille (titre, extrait, source, URL).
Classe-le dans UNE des trois catégories :

1. "casse_prod" : peut casser ou compromettre quelque chose qui tourne.
   Signaux : dépréciation, breaking change, fin de support, faille,
   CVE, changement d'API, changement de prix touchant la stack.
   En cas d'hésitation entre casse_prod et pratique : casse_prod.
2. "pratique" : devrait changer une façon de faire. Signaux : nouvelle
   fonctionnalité d'un outil de la stack, nouveau noeud ou module,
   méthode documentée, retour d'expérience substantiel.
3. "bruit" : tout le reste. Levées de fonds, opinions, marketing,
   annonces hors stack, contenus débutant.

Puis attribue une note de 0 à 10 avec ce barème additif, sans
demi-points et sans autre critère :
- +4 si un outil de la stack en production est nommé explicitement
- +3 si une action est requise avant une date ou une version précise
- +2 si la source est un canal officiel (changelog, release, doc)
- +1 si l'information date de moins de 7 jours

Réponds UNIQUEMENT avec ce JSON, sans texte autour :
{
  "categorie": "casse_prod" ou "pratique" ou "bruit",
  "note": 0 à 10,
  "outil_concerne": "<nom de l'outil, ou vide>",
  "resume": "<l'information en une phrase factuelle, version incluse
    si elle est citée>",
  "action": "<l'action concrète suggérée, ou vide>"
}

Item à évaluer :
Titre : {{ $json.titre }}
Extrait : {{ $json.extrait }}
Source : {{ $json.source }} ; URL : {{ $json.url }}

Deux choix de conception portent ce prompt. Le barème additif fermé d’abord : sans lui, un modèle distribue des 7/10 à tout ce qui semble sérieux, et la note ne hiérarchise rien ; avec quatre critères binaires additionnés, deux passages du même item donnent la même note, et tu sais toujours pourquoi un item a 9 (outil de ta stack, action datée, source officielle). La règle d’hésitation ensuite : « en cas de doute, casse_prod ». Un faux positif en alerte coûte dix secondes d’attention ; un vrai positif raté en digest peut coûter une production, l’asymétrie justifie le biais. Pour aller plus loin sur ce type de jugement outillé, la mécanique se prête bien à un système multi-agents, avec un second agent qui contre-vérifie uniquement les items classés casse_prod avant l’alerte.

Trois sorties, deux canaux qui ne se mélangent jamais

Le JSON du scoring en main, il reste à router, et une règle absolue gouverne ce routage : le canal d’alerte ne reçoit rien d’autre que les alertes. Le jour où une dépréciation de base de données atterrit entre une levée de fonds et un fil Reddit, ton cerveau reclasse le canal entier comme ignorable, et le système meurt de la pire mort possible : il tourne, et plus personne ne le regarde. Une information qui peut casser ta production ne partage jamais sa boîte aux lettres avec le reste. Le pipeline complet, de la collecte aux trois destinations, se lit maintenant d’un bloc.

Dans n8n, ce routage final est un nœud Switch sur le champ categorie. La branche casse_prod part vers un nœud Telegram immédiat, dont le message reprend resume, outil_concerne, action et l’URL : tout ce qu’il faut pour décider en dix secondes si tu poses ton café. La branche pratique écrit l’item dans la Data Table veille_digest ; un second workflow, planifié le vendredi à 17 h, lit cette table, groupe les items par outil, trie par note décroissante, envoie l’email de digest et marque les items comme expédiés. La branche bruit va directement à l’archive. Cette sortie pratique a d’ailleurs une seconde vie possible : les items les mieux notés font une excellente matière première pour une chaîne de rédaction SEO, qui transforme ta veille en sujets d’articles documentés à la source.

Le workflow pour transformer la veille en contenu ajoute entre les deux le regroupement des sujets, la mesure de la demande et la fenêtre d’opportunité.

L’archive, troisième Data Table du système (veille_archive), reçoit en réalité tous les items scorés, quelle que soit leur branche : hash, date, titre, URL, source, catégorie, note, résumé. C’est elle qui répond, six mois plus tard, à la question « quand est-ce que cette info est passée » : un filtre sur outil_concerne dans l’interface des Data Tables, et tu retrouves la date exacte où la dépréciation est apparue dans ton système, avec la note qu’elle avait reçue. Le jour où un client demande pourquoi la migration a été faite en mars, la réponse est requêtable. Même consigne de purge que pour la table des vus : le bruit de plus de six mois peut partir, l’archive utile tient alors sans effort sous le plafond.

Ce qui va te bloquer

Ce système tourne, et comme tout ce qui tourne, il va rencontrer ses pannes, dont quatre sont suffisamment prévisibles pour être documentées d’avance. La première est la plus sournoise : les flux qui meurent sans prévenir. Un éditeur refond son site, l’URL du flux change ou disparaît, et ton système ne reçoit simplement plus rien de cette source, silence indiscernable d’une actualité calme. La parade est la troisième table du dispositif : veille_sources garde la date du dernier item reçu par source, et un contrôle quotidien alerte quand une source dépasse son seuil de silence, seuil réglé source par source, 3 jours pour un subreddit actif, 30 pour un dépôt qui publie peu. Un flux mort se détecte alors en jours, au lieu d’être découvert des mois plus tard, en général en même temps que l’information qu’il aurait dû t’apporter.

La deuxième panne t’attend spécifiquement chez Reddit : les flux .rss publics peuvent répondre 429 Too Many Requests. En l’absence de quota officiel stable propre à ces flux, ne construis pas ton workflow autour d’un seuil supposé. Pour de la veille, interroge chaque flux une ou deux fois par jour, ajoute un délai progressif après un 429 et journalise la date du dernier succès. C’est la raison du choix du Schedule Trigger contre le déclencheur RSS au début de ce guide.

La troisième panne vit dans les newsletters : leur HTML est un champ de mines de tableaux imbriqués, de trackers et de styles en ligne, et l’extraction naïve produit des extraits illisibles qui polluent le scoring. Le nœud HTML avec un sélecteur sur le conteneur principal règle la majorité des cas ; pour les récalcitrantes, extraire uniquement les liens et leurs textes d’ancrage donne un signal plus propre que le corps entier, une newsletter étant essentiellement une liste de liens commentés.

La quatrième n’est pas une panne technique : les deux premières semaines, le scoring se trompera, dans les deux sens, parce que ton profil déclaré est encore une approximation de ton vrai jugement. La méthode de calibrage : pendant deux semaines, les alertes casse_prod partent aussi en copie dans le digest, et tu ne changes rien d’autre. Chaque mauvais classement se note (l’item, la catégorie attendue, la catégorie reçue), et en fin de période tu ajustes le profil et les listes du pré-filtre en une seule passe, puis tu actives le canal d’alerte pour de bon. Calibrer sur un lot vaut mieux que retoucher le prompt à chaque erreur : les corrections unitaires se contredisent, le lot révèle les motifs. Une passe, et c’est réglé.

Les limites du système, et ce qu’il ne remplacera pas

Une fois calibré, ce système fait très bien une chose précise : transformer un flot que personne ne lit en trois sorties dont chacune est traitée. Il faut être tout aussi précis sur ce qu’il ne fait pas. Il ne détecte pas ce qui n’est pas publié : la panne en cours discutée dans un Discord privé, le changement annoncé uniquement aux clients entreprise, le signal faible d’un mainteneur qui ralentit. Un système de veille lit le publié, et le publié arrive parfois après le problème.

Il se dérègle aussi lentement, en silence : ta stack évolue, tes sujets changent, et le profil déclaré du prompt, lui, reste figé à sa dernière édition. Un recalibrage trimestriel s’impose, dix minutes pour relire le profil, les listes de mots-clés et les seuils de silence des sources, et les remettre au niveau de ta réalité. Mets-toi un rappel récurrent, sans quoi le système continuera de veiller avec application sur la stack que tu avais il y a un an. Un garde du corps qui surveille ton ancienne adresse.

Et il ne remplace pas la lecture. Une source de référence, la newsletter de fond de ton domaine, la documentation d’un outil central, se lit en entier, pour le raisonnement autant que pour l’information, et aucun score n’en capture la valeur. Le système sert exactement à ça : éliminer les 195 items qui ne méritaient pas ton attention pour rendre leur temps aux 5 qui la méritent, lecture lente comprise. C’est la sixième automatisation à ajouter à la panoplie du freelance : celle qui protège les cinq autres, et tout le reste de ta production, des mauvaises surprises annoncées.