Transformer sa veille en contenu avec n8n : le workflow

Le coût le plus discret de la veille n’est ni l’abonnement à un outil, ni l’appel à un modèle. C’est la pile d’informations lues, jugées intéressantes, puis oubliées. Tu apprends qu’une fonction arrive, qu’une règle change ou qu’un problème devient fréquent. Tu fermes l’onglet avec l’impression d’avoir travaillé. Trois semaines plus tard, quelqu’un publie le guide que tu aurais pu écrire, avec les mêmes sources et un angle moins précis.

Une veille automatisée résout la collecte et le tri. Elle ne transforme pas spontanément une information en décision éditoriale. Il manque une deuxième chaîne, plus petite, qui regroupe les signaux, mesure leur potentiel et crée un brief au bon moment. C’est cette chaîne que je construis ici.

Le regroupement des signaux, le calcul des scores, la fenêtre d’opportunité et les pannes du système sont expliqués ici, avec les prompts et les formules.

Une archive rassemble le workflow n8n importable et la structure du backlog avec ses statuts et ses sous-scores. Elle est dans l’espace ressources de la communauté, l’accès est gratuit : récupérer l’archive du backlog éditorial.

Le workflow est inactif et ne contient aucun identifiant. Il utilise une Data Table, DataForSEO et un modèle Anthropic à configurer. Il produit des idées et des briefs, jamais des articles.

Ce que le système transforme, et ce qu’il laisse à l’humain

L’entrée n’est pas un flux RSS brut. C’est la sortie qualifiée du système de veille : titre, URL, date, source, résumé, catégorie et note. Les doublons et le bruit ont déjà été écartés. Refaire ce travail ici multiplierait les règles et créerait deux vérités différentes.

La sortie n’est pas davantage un calendrier rempli au mois près. C’est un backlog priorisé où chaque ligne répond à six questions :

1. quel problème précis ce sujet permet-il de résoudre ;
2. combien de signaux distincts l’ont fait émerger ;
3. les premiers résultats francophones répondent-ils déjà correctement ;
4. existe-t-il une demande de recherche observable ;
5. pourquoi es-tu légitime pour le traiter ;
6. jusqu’à quand l’angle conserve-t-il son intérêt.

La machine rassemble des preuves. L’humain choisit ce qui mérite sa signature, apporte son expérience et décide du moment de publication.

Préparer une entrée stable

Le workflow lit les quatorze derniers jours de la table veille_archive. Il conserve les informations dont la note atteint 6 sur 10 et élimine les catégories bruit et cosmetique. Adapte les noms de champs dans le premier nœud Code si ta table diffère.

Quatorze jours constituent une fenêtre de départ. Elle permet de voir une répétition sans laisser un sujet ancien dominer le mois suivant. Pour un secteur réglementaire lent, trente jours seront plus cohérents. Pour une actualité logicielle quotidienne, sept peuvent suffire.

Le corpus est limité à quatre-vingts items avant l’appel au modèle. Cette limite protège le contexte et force le système à travailler sur les signaux récents. Si ta veille dépasse ce volume, traite chaque catégorie séparément au lieu d’envoyer davantage de texte dans un seul prompt.

Regrouper les informations qui répondent à la même question

Compter des mots-clés ne suffit pas. « n8n 2.0 retire MySQL », « préparer sa base pour n8n v2 » et « migrer MariaDB vers PostgreSQL » appartiennent au même sujet pratique. À l’inverse, deux annonces contenant « agent IA » peuvent traiter de problèmes sans rapport.

Le premier agent reçoit les titres, résumés, dates et URL. Il doit produire une clé stable en ASCII, une requête française naturelle et une liste de sources. Sa règle principale est stricte : deux informations ne forment un sujet que si elles répondent à la même question.

Le nœud suivant refuse une réponse qui n’est pas un tableau JSON. Il recalcule également le nombre d’URL distinctes. Le modèle peut proposer un regroupement, mais il ne décide pas combien de preuves existent.

Une clé comme migrer-n8n-mysql-postgresql permet l’upsert dans le backlog. Si le même sujet revient demain, la ligne est mise à jour au lieu d’être dupliquée.

Mesurer la fréquence sans compter dix reprises du même communiqué

Le premier critère vaut quarante points. Il combine le nombre d’occurrences et le nombre de sources distinctes :

Dans cette équation, S_f est le score de fréquence, n_s le nombre de sources distinctes et n_o le nombre total d’occurrences.

Cette formule est un réglage, pas une vérité scientifique. Son intérêt tient à sa lisibilité. Un sujet cité par quatre sources indépendantes monte plus vite qu’un communiqué repris dix fois avec la même URL.

Conserve les sources dans la ligne du backlog. Si un score semble trop élevé, tu dois pouvoir constater que huit items proviennent en réalité d’un seul éditeur. Une métrique sans ses preuves devient rapidement un chiffre décoratif.

Observer le vide francophone sans prétendre prouver une absence

Le deuxième critère vaut trente points. Le workflow interroge les dix premiers résultats organiques en France et en français, puis conserve leur rang, leur titre et leur URL.

Je parle de « vide observé », jamais d’absence absolue. Un moteur ne montre pas tout le Web, les résultats changent et la détection de langue par le workflow reste approximative. Le score sert à ordonner une revue humaine :

Un résultat francophone n’annule pas automatiquement le sujet. Ouvre les pages. Un article peut dater de trois versions, omettre le problème opérationnel ou ne proposer aucune procédure testable. À l’inverse, trois excellents guides récents imposent un angle vraiment différent.

L’API SERP avancée de DataForSEO permet de fixer le pays, la langue et la profondeur. Elle est payante. Si tu la retires, crée une tâche manuelle serp_a_verifier plutôt que de demander au modèle d’imaginer les résultats.

Croiser avec une requête réellement recherchée

Un sujet fréquent peut n’intéresser que les éditeurs qui le commentent. Le workflow envoie donc la requête proposée à l’endpoint de volume de recherche Google Ads de DataForSEO. Sa documentation officielle précise que le volume est approximatif et que des requêtes proches peuvent être regroupées. Ne lis pas 40 comme quarante personnes exactes.

Le volume n’entre pas directement dans le score de base. Il joue le rôle de contrôle :

• volume supérieur à zéro : une demande est observable ;
• volume nul : vérifie les variantes et Search Console ;
• volume élevé : ne conclus pas que le sujet correspond à ton audience.

Pour un site déjà indexé, les requêtes réelles de Search Console sont plus proches de ton public. L’API officielle searchAnalytics.query renvoie clics, impressions, CTR et position par requête, mais Google indique qu’elle ne garantit pas toutes les lignes. Utilise-la comme une deuxième source, pas comme un recensement exhaustif.

Un sujet sans volume peut rester prioritaire s’il évite une panne à tes lecteurs. La demande SEO complète l’utilité, elle ne la remplace pas.

Formaliser ta légitimité avant que l’agent ne choisisse

Le troisième critère vaut trente points. Dans le workflow, le nœud Mesurer la légitimité contient une matrice simple :

const pillars = [
  {
    pattern: /n8n|workflow|automatisation|webhook|data table/i,
    score: 30,
    reason: "Tutoriels et workflows n8n déjà publiés",
  },
  {
    pattern: /make|no-code|routeur|scénario/i,
    score: 25,
    reason: "Couverture Make et no-code existante",
  },
  {
    pattern: /agent|ia|prompt|claude|mcp/i,
    score: 25,
    reason: "Couverture agents IA et prompts existante",
  },
  {
    pattern: /crm|email|marketing|lead/i,
    score: 20,
    reason: "Couverture CRM et marketing en développement",
  },
];

Remplace cette matrice par tes sujets réellement pratiqués. Une catégorie commerciale ne prouve aucune expertise. Associe chaque pilier à des articles, projets, tests ou responsabilités vérifiables.

Cette étape protège le site contre le contenu opportuniste. Google recommande un contenu utile qui démontre une expérience et une expertise réelles, et cite comme signal d’alerte le fait d’écrire sur une tendance sans rapport avec son audience. La documentation people-first de Google rejoint ici une règle éditoriale de bon sens : un trou dans les résultats ne te donne pas automatiquement une voix crédible.

Faire décroître le score avec le temps

Les trois critères donnent un score de base sur cent. Je lui applique ensuite une décroissance linéaire selon la nature du sujet :

Le score de base additionne les trois dimensions mesurées :

La décroissance et la priorité actuelle se calculent ensuite ainsi :

Ici, S_b désigne le score de base, S_v le vide francophone, S_l la légitimité, a l’âge du dernier signal en jours, h l’horizon associé au type de sujet et S_p la priorité actuelle.

Une information urgente perd ainsi sa valeur éditoriale rapidement. Un tutoriel durable reste disponible, mais il ne doit pas monopoliser éternellement la première place. Les horizons sont visibles dans la sortie score_explanation, donc modifiables après observation.

Générer un brief, jamais l’article

À partir de 50 points, un second agent crée :

• un angle précis ;
• le problème du lecteur ;
• un plan de six à dix sections ;
• les faits à vérifier ;
• les URL du corpus ;
• la raison de publier maintenant ;
• la part réactive estimée.

Le parseur refuse le texte libre et stocke le JSON complet. Le prompt interdit l’ajout de sources. L’agent peut organiser la matière, mais une URL inventée ou une donnée non vérifiée ne doit jamais entrer dans le brief.

Cette séparation complète la chaîne de rédaction SEO avec n8n. Le workflow présent choisit et documente un sujet. La chaîne de rédaction analyse l’intention, fait valider le plan, rédige par sections et s’arrête en brouillon. Les fusionner rendrait impossible de corriger un mauvais choix sans générer un article entier.

Construire un backlog qui ne se duplique pas

La Data Table editorial_backlog utilise topic_key comme clé de correspondance. Elle conserve les sous-scores, le volume, l’échéance, l’angle, le brief, les sources et quatre dates.

Les statuts recommandés sont :

Le workflow n’écrase jamais un statut éditorial pour remettre une ligne publiée en idee. En production, protège les champs humains lors de l’upsert ou sépare les mesures automatiques des décisions. Le JSON fourni montre la structure générale, mais tu dois contrôler le mapping après avoir sélectionné ta table réelle.

Notion peut offrir une vue calendrier plus agréable. Il ajoute toutefois une synchronisation, des identifiants de page et un autre point de panne. Commence avec la Data Table. Ajoute Notion seulement si une équipe utilise réellement ses commentaires et ses vues.

Reconstitution sur cinq jours : de la breaking change au guide de migration

Le dossier contient un cas exploitable : l’article sur la migration de MySQL vers PostgreSQL avant n8n v2, publié le 2 mai 2026, s’appuie sur la page officielle des breaking changes de n8n. Nous ne possédons pas la date à laquelle l’information a été découverte. Je ne vais donc pas présenter les cinq jours suivants comme un journal historique.

Voici la reconstitution vérifiable du chemin que le workflow aurait imposé :

Ce cas montre la fonction de la fenêtre, pas un record de vitesse. Je ne peux pas démontrer rétroactivement que le guide a précédé toute concurrence francophone, car aucune capture datée de la SERP n’a été conservée. Le workflow résout précisément cette faiblesse pour les prochains cas : il archive les résultats observés au moment du choix.

Éviter que l’actualité mange toute la ligne éditoriale

Un backlog rempli uniquement par la veille devient un journal de réactions. Tu dépends des annonces des autres, les articles vieillissent vite et ton expertise se réduit au commentaire.

Ajoute un plafond à la part réactive. Par exemple, sur quatre publications mensuelles :

• une réponse à une fenêtre courte ;
• deux guides de fond issus de problèmes récurrents ;
• une mise à jour d’un contenu existant.

Ce ratio n’est pas universel. Il oblige seulement à regarder la composition avant de choisir le meilleur score. Un sujet à 82 ne doit pas remplacer automatiquement le guide structurant prévu depuis un mois.

La veille peut aussi conclure qu’il ne faut pas écrire. Si une source officielle répond parfaitement à la question et que tu n’apportes ni test, ni traduction opérationnelle, ni retour d’expérience, conserve l’information dans le digest. Partager une bonne source est parfois plus utile que fabriquer une page.

Ce qui va te bloquer dans le workflow

Le premier blocage arrive quand l’agent change de clé pour le même sujet. Lundi, il produit migration-n8n-postgresql ; mardi, migrer-n8n-mysql-postgres. Deux lignes apparaissent alors avec les mêmes sources. Une clé générée par un modèle ne constitue pas à elle seule un identifiant fiable. Ajoute une table d’alias ou cherche, avant l’upsert, un candidat existant dont la requête et les sources sont proches. Lorsqu’un humain fusionne deux sujets, conserve l’ancienne clé dans aliases_json pour que les prochains passages retrouvent la ligne canonique.

Le deuxième blocage concerne les réponses partielles des API. Une erreur DataForSEO ne signifie ni volume nul, ni vide francophone. Elle signifie « mesure indisponible ». Stocke donc un champ measurement_status avec complete, partial ou error. Un candidat dont la SERP a échoué doit attendre une nouvelle mesure, pas recevoir trente points par défaut.

Le troisième vient des annonces répétées. Un éditeur publie une release, un billet, une newsletter et trois posts qui pointent vers la même nouveauté. Les domaines sont différents si les réseaux sociaux servent d’intermédiaires, mais la source primaire reste unique. Ajoute origin_url lorsque la veille peut l’identifier et calcule la fréquence sur cette origine. Sans cela, le budget marketing d’un éditeur devient artificiellement un signal éditorial.

Le quatrième blocage est le sujet trop large. « Intelligence artificielle » apparaîtra partout, possédera du volume et correspondra peut-être à ta ligne éditoriale. Il ne donne pourtant aucune promesse d’article. Le regroupement doit produire une question actionnable, par exemple « comment empêcher un agent n8n d’envoyer une donnée sensible à un modèle ». Refuse les candidats dont topic ne contient ni problème, ni décision, ni tâche identifiable.

Enfin, le calendrier peut se remplir plus vite que ta capacité de rédaction. La priorité ne résout pas la capacité. Ajoute un champ estimated_effort avec trois valeurs simples, puis limite le nombre de sujets passant à planifie selon les créneaux disponibles. Une fenêtre courte qui exige trois jours de tests ne rentre pas dans une journée libre. Le bon choix peut être de publier une note courte, de repousser un guide complet ou de laisser passer l’occasion.

Les limites à garder visibles

Le regroupement sémantique peut fusionner deux intentions différentes. Le volume de recherche est approximatif. La SERP est une photographie partielle. La légitimité dépend d’une matrice déclarative. La décroissance choisit arbitrairement des horizons. Aucun de ces défauts n’interdit le système, mais tous interdisent la publication automatique.

Un score élevé ne mesure pas la qualité future de l’article. Il mesure la convergence de signaux définis. L’angle, les tests, les exemples, les vérifications et la clarté restent du travail éditorial.

Enfin, surveille les coûts. Deux appels DataForSEO par candidat deviennent inutiles si cinquante variations du même sujet passent le regroupement. Déduplique avant les API, limite le corpus et archive les réponses pour ne pas interroger deux fois la même requête le même jour.

Démarrer par deux semaines d’observation

Importe le workflow, crée la table, puis sélectionne veille_archive et editorial_backlog dans les nœuds marqués A CONFIGURER. Adapte la matrice de légitimité et renseigne les credentials Anthropic et DataForSEO. Laisse la notification désactivée.

Pendant deux semaines, examine chaque candidat :

• les sources parlent-elles réellement du même problème ;
• le score de fréquence résiste-t-il aux reprises ;
• les résultats francophones ont-ils été correctement interprétés ;
• la requête correspond-elle au langage des lecteurs ;
• l’échéance semble-t-elle réaliste ;
• le brief contient-il uniquement des sources observées.

Corrige d’abord les regroupements, puis les seuils. Au terme de la période, active seulement la notification des fenêtres inférieures à cinq jours. Le reste attendra dans le backlog.

Le système réussit lorsqu’il t’aide à dire « maintenant », « plus tard » ou « jamais » avec des preuves. S’il remplit simplement une colonne d’idées supplémentaires, il reproduit le problème de départ : beaucoup de choses intéressantes, aucune décision.