Rédiger des articles SEO avec un agent n8n : chaîne complète

Tout le monde a essayé le même workflow, ou vu quelqu’un le vanter : un mot-clé entre d’un côté, un nœud envoie « écris un article de 3 000 mots sur ce sujet » à un modèle, et l’article sort de l’autre côté. Trois nœuds, cinq minutes de montage. Et un résultat que tu reconnais au premier paragraphe : de la bouillie interchangeable, sans angle, sans fait précis, que personne ne lira jusqu’au bout. Du texte au kilomètre, prix usine, goût carton.

La faute revient au raccourci, bien plus qu’à l’IA. Un article qui tient la route sort d’une chaîne de travail complète : comprendre ce que cherchent les lecteurs, choisir un angle, construire un plan, rédiger, relire, vérifier. Un rédacteur humain enchaîne ces étapes sans forcément les formaliser, et c’est leur absence qui condamne le workflow à trois nœuds : en les sautant, il fabrique du texte au kilomètre là où on attendait un article.

Ce guide construit la chaîne complète pour rédiger des articles SEO avec n8n : huit étapes séparées, deux points de validation humaine placés là où ils rapportent le plus, un contrôle qualité automatisé, et une publication qui s’arrête toujours au stade de brouillon. Avec, en fin de parcours, les deux sections que les tutoriels éludent : le coût réel par article, calculé en euros, et la ligne exacte que Google trace entre ce montage et ce qu’il considère comme du spam.

Une chose est posée d’entrée, parce qu’elle cadre tout le reste : cette chaîne ne remplace pas un rédacteur. Elle supprime les 70 % de travail mécanique qui entourent la rédaction, la collecte, la structure, les vérifications de forme, et concentre l’humain sur les 30 % qui font la valeur : l’angle, les faits, la voix, la décision de publier.

Ce qu’il te faut

• une instance n8n, peu importe où elle tourne
• une clé d’API d’un modèle de langage
• un accès à une API de données de résultats de recherche (SerpApi, DataForSEO ou équivalent)
• une source de mots-clés : un fichier, une Data Table, ou Search Console
• environ 2 heures de montage, hors rédaction des prompts

Pourquoi un seul appel ne produira jamais 3 000 mots publiables

Avant de construire quoi que ce soit, il faut comprendre pourquoi le workflow à trois nœuds échoue, parce que c’est cette compréhension qui justifie chaque étape de la chaîne. Le problème tient à la manière dont un modèle de langage produit un long texte en un seul passage.

Sur les premiers paragraphes, tout va bien. Puis la dérive s’installe : les sections commencent à se ressembler, les exemples se font génériques, la structure annoncée en introduction s’affaisse, et les derniers H2 sont expédiés en trois phrases là où les premiers en avaient quinze. Le modèle n’a pas de plan qu’il consulte, il continue une trajectoire, et une trajectoire de 3 000 mots finit rarement où elle avait annoncé aller. Ajoute à ça le tout-venant du texte généré sans matière première : aucun fait daté, aucun chiffre sourcé, aucune position, puisque rien dans le prompt n’en fournissait. On récolte ce qu’on a semé, et personne n’avait rien semé.

La correction se joue donc un cran au-dessus du prompt, dans l’architecture de la chaîne : découper le travail en étapes spécialisées, où chaque appel au modèle fait une seule chose, reçoit exactement la matière dont il a besoin, et produit une sortie qu’on peut évaluer avant de passer à la suivante. C’est le même principe de séparation des responsabilités qui structure un système multi-agents : des spécialistes étroits plutôt qu’un généraliste débordé.

L’architecture de la chaîne en huit étapes

Ce principe posé, voici la chaîne entière, avant de détailler chaque maillon. Deux losanges y figurent, et ce sont les décisions les plus importantes du montage : les deux endroits où un humain reprend la main.

Pourquoi ces deux points de validation et pas d’autres ? Le premier, après le plan, obéit à une logique de coût : corriger un plan prend cinq minutes de lecture, corriger un article entier demande une réécriture. Tout ce qui peut être rejeté tôt doit l’être tôt. Le second, avant la publication, obéit à une logique de responsabilité : la machine vérifiera la longueur et la densité, jamais la véracité, et c’est un humain qui signe. Entre les deux, aucune validation : les étapes intermédiaires produisent des artefacts que le contrôle final attrapera s’ils déraillent.

En pratique, n8n offre plusieurs mécanismes pour suspendre une exécution en attendant l’humain, dont le nœud Wait et les variantes « envoyer et attendre la réponse » de certains nœuds de messagerie. Le workflow envoie le plan, s’endort, et reprend au clic d’approbation. Cette plomberie est standard ; ce qui compte vraiment, c’est d’avoir placé l’arrêt au bon endroit.

Collecter le mot-clé depuis une vraie source

La chaîne démarre par une file d’attente, et cette file mérite mieux qu’une cellule de tableur : chaque mot-clé porte un état qui évolue, exactement le cas d’usage d’une Data Table n8n. Sa structure :

La colonne statut fait deux métiers. Elle pilote la chaîne : le déclencheur planifié prend le prochain a_traiter par priorité, et chaque étape franchie met la ligne à jour. Et elle rend la chaîne idempotente : une exécution qui replante à mi-chemin ne reprendra pas un mot-clé déjà passé à plan_propose, donc pas d’article en double.

Pour alimenter la file automatiquement, Search Console est la meilleure source : les requêtes où ton site apparaît en page 2 sont des articles à écrire. Il n’existe pas de nœud n8n natif pour Search Console, mais le nœud HTTP Request avec une credential OAuth2 fait le travail, en suivant exactement la méthode de la credential propre décrite dans le guide pour brancher un outil sans intégration native : la clé dans une credential chiffrée, jamais dans le nœud.

Si tes idées viennent plutôt de flux RSS, de sites métier ou de newsletters, ne mélange pas leur collecte avec la rédaction. Le workflow de veille automatisée avec n8n montre comment conserver les URLs d’origine, dédupliquer les nouvelles et ne transmettre à la file éditoriale que les sujets qui dépassent un seuil de pertinence.

Analyser la SERP et construire le brief

Un mot-clé sort de la file, et la tentation est de l’envoyer directement à la rédaction. C’est le raccourci qui produit la bouillie : le modèle écrirait sans savoir ce que cherchent les gens ni ce que la concurrence couvre déjà. L’étape d’analyse fournit cette matière : un appel à une API de données SERP renvoie, pour le mot-clé, les dix premiers résultats avec titres et descriptions, les questions « autres questions posées », et les recherches associées.

Ces données brutes deviennent un brief, et le brief est le contrat de tout ce qui suit : l’intention de recherche, ce que les concurrents couvrent, ce qu’ils ratent, les questions à traiter. C’est un appel au modèle, avec un prompt qui mérite d’être long :

Tu prepares un brief de redaction SEO. Tu recois : le mot-cle vise,
les titres et descriptions des 10 premiers resultats de recherche,
les questions "autres questions posees" et les recherches associees.

Produis un brief structure en six points :

1. Intention de recherche : ce que la personne qui tape ce mot-cle
   veut obtenir, en une phrase.
2. Angles deja couverts : ce que la majorite des 10 resultats
   traitent.
3. Angle manquant : ce qu'aucun resultat ne couvre correctement et
   qui aurait de la valeur pour le lecteur. C'est le point le plus
   important du brief.
4. Questions a couvrir : les questions posees pertinentes,
   reformulees ; elimine celles qui sont hors sujet.
5. Entites a mentionner : les outils, noms et concepts que les
   resultats citent et que l'article devra connaitre.
6. La promesse de l'article, en une phrase commencant par
   "A la fin de cet article, le lecteur saura".

Interdictions :
- ne rien inventer : si les donnees fournies ne contiennent pas une
  information, ne la suppose pas
- aucune promesse que l'article ne pourra pas tenir avec les
  donnees disponibles

Le point 3 est celui qui sépare un article utile d’un article de plus : si l’angle manquant est vide ou faible, c’est un signal honnête que le sujet est saturé, et la bonne décision est parfois de remettre le mot-clé en file avec une priorité basse plutôt que d’ajouter une onzième page identique aux dix premières. Onze clones sur une même page de résultats, personne n’a demandé ça. Le brief en main, le plan peut se construire dessus.

Le plan, premier point de validation humaine

Le plan est un appel court : le brief entre, une structure de H2 et H3 sort, avec pour chaque section une ligne sur ce qu’elle contient. Et c’est ici que la chaîne s’arrête pour la première fois et t’attend.

Cinq minutes suffisent pour juger un plan : l’angle est-il le bon, les sections sont-elles dans le bon ordre, manque-t-il la question que ton audience pose toujours, y a-t-il une section que tu sais indéfendable faute de sources. Un rejet renvoie au plan avec ton commentaire, une approbation lance la rédaction. Ce moment est aussi celui où ton expertise métier entre dans la chaîne : la machine a analysé la SERP, toi tu sais ce que la SERP ignore.

Résiste à la tentation de sauter cette étape quand les plans deviennent bons. C’est précisément quand tu ne lis plus les plans que la chaîne dérive, un mot-clé ambigu, un brief qui a mal interprété l’intention, et tu découvres le problème sur un article fini au lieu d’un plan de dix lignes. Cinq minutes de lecture, et tu dors tranquille.

Rédiger section par section avec Loop Over Items

Le plan validé, la rédaction peut commencer, et c’est ici que la chaîne règle le problème posé en ouverture : plutôt qu’un appel de 3 000 mots, une boucle d’appels courts, un par section du plan. La pièce n8n qui porte cette boucle s’appelle Loop Over Items, avec un Batch Size de 1 : chaque tour traite une section, la sortie « loop » repart vers l’appel au modèle, la sortie « done » se déclenche quand toutes les sections sont écrites. La documentation du nœud porte un avertissement à prendre au sérieux : sans condition de terminaison valide, l’exécution boucle à l’infini. Ici, la terminaison est naturelle, la liste des sections s’épuise, mais garde ce réflexe pour toute boucle que tu ajouteras.

Reste le point dur, celui qui fait la différence entre des sections cohérentes et des sections juxtaposées : que transmettre d’un tour à l’autre. Tout envoyer, le texte intégral des sections déjà écrites, explose le nombre de tokens à chaque tour et finit par dépasser le contexte. Ne rien envoyer produit des sections qui s’ignorent, se répètent et se contredisent. La solution intermédiaire est le résumé roulant : chaque section, en plus de son texte, produit un résumé de deux phrases de ce qu’elle a établi, et la section suivante reçoit le plan complet plus la pile des résumés, jamais les textes. Le pense-bête voyage, le roman reste au vestiaire.

Le prompt de section met cette mécanique en musique, et il est volontairement strict :

Tu rediges la section "[TITRE_H2]" d'un article dont voici le plan
complet : [PLAN]

Ce que les sections precedentes ont etabli : [RESUMES]

Regles de redaction :
- redige uniquement cette section, sans introduction generale
  d'article ni conclusion d'article
- ta premiere phrase reprend le resultat ou la question laissee par
  la section precedente, indique dans les resumes
- 250 a 450 mots, des H3 uniquement si le plan les prevoit
- aucune invention : si une affirmation demanderait une source que
  tu n'as pas, ecris [A VERIFIER : quoi verifier] a la place
- ta derniere phrase ouvre vers la section suivante du plan, sans
  la resumer d'avance

Apres la section, sur une ligne separee commencant par RESUME :
ce que ta section vient d'etablir, en deux phrases, pour la section
suivante.

Deux règles de ce prompt travaillent pour les étapes d’après. Le marqueur [A VERIFIER] transforme les inventions potentielles en points de contrôle visibles : le contrôle qualité les comptera, et la validation finale les résoudra. Et la ligne RESUME est extraite par un nœud Code après chaque tour pour alimenter la pile des résumés, ce qui maintient le contexte de chaque appel autour de quelques milliers de tokens, quelle que soit la longueur de l’article. Cette logique de contraintes vérifiables dans un prompt vaut bien au-delà de la rédaction : c’est la même qui fait tenir un fichier d’instructions CLAUDE.md face à un agent de code.

Humaniser, puis contrôler automatiquement

La boucle terminée, un nœud d’assemblage concatène les sections, et l’article existe. Il est structuré, cohérent, et il sent encore le généré : transitions mécaniques, phrases de longueur régulière, tics de langage de modèle. La passe d’humanisation est un appel dédié, sur le texte complet, avec un prompt qui ne touche ni aux faits ni à la structure : varier le rythme des phrases, retirer les formules creuses, casser les listes de trois, injecter la voix de la marque si tu en as formalisé une. Une passe de style, pas une réécriture.

Puis la machine vérifie ce que la machine sait vérifier. Un nœud Code fait le contrôle qualité en quelques millisecondes, et sa liste de contrôles est extensible à volonté :

// Noeud Code, apres l'assemblage et l'humanisation.
const article = $json.article_complet;
const motCle = ($json.mot_cle || '').toLowerCase();

const mots = article.split(/\s+/).filter(Boolean);
const echapper = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
const occurrences =
  (article.toLowerCase().match(new RegExp(echapper(motCle), 'g')) || []).length;
const densite = (occurrences / mots.length) * 100;

const problemes = [];
if (mots.length < 1500) problemes.push(`trop court : ${mots.length} mots`);
if (occurrences === 0) problemes.push('mot-cle absent du texte');
if (densite > 2.5) problemes.push(`densite excessive : ${densite.toFixed(1)} %`);
if (!article.includes('](')) problemes.push('aucun lien dans le corps');
if (/\[A VERIFIER/.test(article))
  problemes.push('marqueurs A VERIFIER non resolus');

// Deux H2 identiques signalent une boucle qui a derape
const titres = article.split(/^## /m).slice(1)
  .map((s) => s.split('\n')[0].trim().toLowerCase());
if (new Set(titres).size < titres.length)
  problemes.push('titres de section dupliques');

return {
  json: {
    conforme: problemes.length === 0,
    problemes,
    stats: { mots: mots.length, densite: Number(densite.toFixed(2)) },
  },
};

Un article non conforme repart en correction avec la liste des problèmes, un article conforme part vers toi. Remarque ce que cette liste ne contient pas : aucune vérification de véracité. Cette absence est structurelle : un script sait compter des mots, mais il ne saura jamais si un chiffre est vrai. La frontière entre ce que la machine contrôle et ce que l’humain contrôle passe exactement là. Un script compte les mots ; la vérité, c’est ton rayon.

Publier en brouillon, jamais en ligne

L’article conforme arrive au second point de validation, et la règle de sortie de la chaîne tient en une phrase : le workflow ne publie jamais directement. La dernière étape crée un brouillon dans le CMS via son API, statut draft, ou committe un fichier Markdown sur une branche du dépôt si le site est statique. Dans les deux cas, l’acte de publication reste un geste humain, postérieur à une relecture qui a résolu les marqueurs [A VERIFIER], vérifié les faits saillants et validé que l’article dit quelque chose.

Ce garde-fou te protège du scénario qui tue les blogs : la chaîne qui dérive silencieusement, et trois semaines de textes médiocres publiés avant que quelqu’un ne s’en aperçoive. Un brouillon qui attend n’abîme rien. Un article faux en ligne, signé de ton nom, si.

La revue finale comprend aussi la couverture : son sujet doit correspondre à la promesse du titre, son alt doit décrire ce qu’elle montre et aucune fausse interface ne doit servir de preuve. La méthode des prompts d’images de cuisine africaine détaille une structure en six briques qui se transpose à une couverture d’article, du sujet central jusqu’aux contraintes de cadrage.

Le coût réel d’un article, en euros

La chaîne fonctionne, reste à savoir ce qu’elle coûte, et cette section fait le calcul en montrant chaque hypothèse, plutôt que d’asséner un chiffre. Les estimations de tokens sont des ordres de grandeur pour un article de huit sections, environ 2 500 mots ; tes prompts et tes sujets feront varier les volumes, la méthode reste.

Au tarif public d’Anthropic relevé en juillet 2026, Claude Sonnet 5 coûte 3 $ le million de tokens en entrée et 15 $ en sortie : soit 0,14 $ d’entrée et 0,21 $ de sortie, environ 0,35 $ par article, autour de 0,32 € au cours approximatif du moment. Avec Claude Opus 5 (5 $ et 25 $ le million), le même article revient à environ 0,58 $, autour de 0,53 €. Retiens la fourchette : entre 0,30 et 0,60 € de modèle par article, et la variable qui domine est le nombre de sections, chaque section ajoutant son appel avec le plan et les résumés en entrée.

Ce chiffre appelle deux lectures honnêtes. La première : le coût du modèle est négligeable, et c’est précisément ce qui rend la tentation du volume dangereuse, on y revient juste après. La seconde : les vrais coûts sont ailleurs. L’abonnement à l’API de données SERP, dont le prix dépend du fournisseur et du volume de requêtes. Et surtout ton temps : les deux validations, la résolution des [A VERIFIER], la relecture finale. Ce temps est un coût voulu, assumé dès la conception de la chaîne, parce que c’est précisément la part qui fait la valeur de l’article.

Ce que Google appelle du spam, et la ligne à ne pas franchir

Un article à 0,35 $, la question arrive toute seule : pourquoi pas mille articles ? C’est exactement la question que la politique spam de Google anticipe, et sa réponse mérite d’être lue au mot près. Le « scaled content abuse » y est défini comme la génération de nombreuses pages « dans le but premier de manipuler les classements de recherche et non d’aider les utilisateurs », et parmi les exemples explicites : « utiliser des outils d’IA générative ou d’autres outils similaires pour générer de nombreuses pages sans ajouter de valeur pour les utilisateurs ».

Lis bien ce que la politique dit, et ce qu’elle ne dit pas. Le critère retenu tient dans l’échelle sans valeur et dans l’intention de manipuler plutôt que d’aider ; la méthode de création, elle, n’apparaît nulle part comme un motif de sanction. Un article produit par cette chaîne, un mot-clé travaillé, un angle choisi parce que la SERP le laissait vacant, deux validations humaines, des faits vérifiés avant publication, est l’exact opposé de « many pages without adding value ». La même chaîne, validations retirées, file de mille mots-clés et publication directe, devient précisément ce que la politique décrit. L’outil est identique, l’usage fait toute la différence, et c’est toi qui règles le curseur.

Ce blog assume d’être un exemple de la première catégorie : les articles que tu lis ici sont produits avec une chaîne assistée par IA, recherche sur sources primaires, plan validé par un humain avant rédaction, relecture et publication humaines. La transparence fait partie de la méthode, et tu es en train d’en juger le résultat sur pièce.

Une conviction pour finir cette section, parce qu’elle tranche avec ce que vendent les formations au contenu automatisé : si ta stratégie repose sur le volume, cette chaîne ne te sauvera pas, elle accélérera ta chute. Le volume sans valeur est détectable, il est visé nommément par la politique, et il brûle un domaine. Et un domaine cramé se pleure longtemps. La chaîne est faite pour écrire mieux et plus régulièrement, pas pour écrire plus que tout le monde.

Ce qui va te bloquer

Cinq points de friction reviennent sur ce montage, avec leur parade.

Le résumé roulant qui enfle. Chaque section ajoute son résumé, et vers la douzième section d’un article pilier, la pile de résumés pèse plus lourd que la section à écrire. Borne le mécanisme : au-delà de six résumés, demande au modèle de compacter la pile en un seul paragraphe avant de continuer. C’est un appel de plus, il coûte moins cher que la dérive.

La boucle sans fin. Tu ajoutes une boucle de correction, l’article non conforme repart en rédaction, échoue encore, repart encore. Sans borne, le workflow tourne toute la nuit et consomme en silence. Ajoute un compteur de tentatives dans les données de la boucle : trois échecs de contrôle qualité, et l’article part en validation humaine avec ses problèmes listés, au lieu de retenter éternellement. Docteur Strange, chez Marvel, a piégé un dieu dans une boucle temporelle infinie ; lui, au moins, l’avait fait exprès.

L’OAuth Search Console qui expire. L’alimentation automatique de la file s’arrête sans bruit, et tu t’en aperçois quand la file est vide. Le refresh token de la credential OAuth2 se renouvelle normalement seul, mais une révocation ou un changement de mot de passe le casse : ajoute un chemin d’erreur sur ce nœud qui te notifie, plutôt que de découvrir le silence trois semaines plus tard.

Le quota de l’API SERP. Chaque mot-clé consomme une requête d’analyse, et les plans d’entrée des fournisseurs se comptent en centaines de requêtes par mois. Stocke le résultat d’analyse dans la file avec le mot-clé : si le même sujet repasse, brief régénéré sans rappeler l’API. Une requête SERP par mot-clé, jamais par tentative.

Le contrôle qualité qui rassure à tort. Le nœud Code dit conforme: true et tout semble vert, mais rappelle-toi ce qu’il mesure : la forme. Un article peut être conforme et faux, conforme et creux, conforme et hors sujet. Le vert du contrôle automatique signifie « bon pour relecture humaine », jamais « bon pour publication ». Si tu ne devais retenir qu’une phrase de ce guide, c’est celle-là.

Les limites

La première limite est éditoriale, et elle est structurelle : cette chaîne produit des articles d’information solides, elle ne produira jamais tes meilleurs articles. Le retour d’expérience vécu, l’opinion qui engage, l’angle que seule ton expertise voit : tout ça entre dans la chaîne par le brief et la validation du plan, ou n’y entre pas. La chaîne est ton ghostwriter, comme dans le rap, où celui qui écrit dans l’ombre laisse l’artiste signer le morceau : le texte peut être bon, mais le style et la responsabilité restent à celui qui signe.

La deuxième est technique : le non-déterminisme. Deux exécutions sur le même mot-clé produiront deux articles différents, et la qualité varie d’une exécution à l’autre. Les validations humaines et le contrôle qualité bornent le bas de la fourchette, rien ne garantit le haut.

La troisième est stratégique : les 70 % de travail mécanique supprimés ne valent que si les 30 % restants sont réellement faits. Une chaîne dont les validations deviennent des formalités cliquées sans lire produit du contenu médiocre avec une bonne conscience d’industriel. L’outil laisse la paresse parfaitement intacte ; il se contente de la rendre plus productive.

Matrice de contrôle avant de laisser la chaîne tourner

Chaque ligne se vérifie en une exécution de test, l’ensemble sépare une démo d’une chaîne de production.

La dernière ligne mérite une vérification de l’extérieur : ouvre le site en navigation privée et confirme que rien n’est publié. C’est le test de la promesse centrale de la chaîne, la machine prépare, l’humain publie.

Une fois la chaîne en route, son meilleur sous-produit se révèle être la file elle-même : une liste vivante de ce que ton audience cherche et que ton site ne couvre pas encore, alimentée par tes propres données de recherche. Et si tu montes ta version, avec un autre modèle, un autre fournisseur SERP ou un autre point de validation, viens la décrire sur le hub lesnocodeurs : les chiffres de coût réels constatés, en particulier, gagneraient à être comparés à plusieurs. Viens avec tes tickets de caisse, on compare.