Publier automatiquement sur WordPress avec n8n et l'IA (sans sacrifier la qualité)

Un blog qui publie régulièrement est un actif SEO ; un blog qui publie du texte généré à la chaîne sans relecture est un passif. Entre les deux, il y a un pipeline bien conçu : n8n récupère une source de contenu (veille, transcript de réunion, données produit), un LLM rédige et met en forme, et l'article atterrit sur WordPress en brouillon, jamais en ligne, jusqu'à ce qu'un humain l'ait lu et approuvé. Ce guide monte ce pipeline pièce par pièce — node WordPress natif, API REST wp-json, Application Passwords, image à la une, catégories, champs SEO et planification — en gardant le garde-fou éditorial au centre plutôt qu'en option.

Le node WordPress natif et l'API REST wp-json

n8n embarque un node WordPress natif qui couvre l'essentiel du cycle de vie d'un article : créer, lire, mettre à jour un post, avec le titre, le contenu, le statut (draft, publish…), le slug, les catégories et les tags. Sous le capot, il parle à l'API REST que tout WordPress expose depuis des années à l'adresse https://votre-site.fr/wp-json/wp/v2/ : les articles vivent sous /posts, les médias sous /media, les catégories et tags sous /categories et /tags.

Cette dualité est une force : tout ce que le node ne couvre pas (upload de média, champs meta d'un plugin SEO, custom post types) reste accessible avec un simple node HTTP Request pointé sur le même wp-json, avec la même authentification. On utilise donc le node natif pour le cas nominal — créer le brouillon — et l'API REST en direct pour les finitions.

Authentification : Application Passwords, sans plugin

Depuis WordPress 5.6, les Application Passwords sont intégrés au cœur de WordPress — aucun plugin nécessaire. Dans le profil de l'utilisateur WordPress (idéalement un compte dédié n8n avec le rôle Auteur ou Éditeur, pas votre compte administrateur), la section « Application Passwords » génère un mot de passe dédié, révocable indépendamment du mot de passe principal.

Côté n8n, la credential WordPress API demande trois champs : l'URL du site, le nom d'utilisateur et ce mot de passe d'application. L'authentification passe en Basic Auth sur chaque requête, ce qui impose une condition non négociable : le site doit être servi en HTTPS, sinon les identifiants circulent en clair. Pour les appels HTTP Request complémentaires (média, meta), la même credential se réutilise en choisissant Predefined Credential Type → WordPress dans le node.

Le pipeline type : de la source au brouillon relu

1. Une source de contenu, pas une page blanche

Un LLM qui part de rien produit du remplissage. Un LLM qui part d'une matière première précise produit un premier jet utile. Trois sources qui fonctionnent bien en entrée de pipeline :

• Un flux de veille : les articles marquants de la semaine agrégés par un workflow de veille concurrentielle par IA, ou des données extraites de pages publiques avec un pipeline de scraping encadré par IA, deviennent la base d'un digest hebdomadaire sourcé.
• Un transcript : un webinaire ou une réunion client transcrit via un pipeline de transcription et résumé avec Whisper contient déjà les idées, les exemples et le vocabulaire — le LLM ne fait que restructurer.
• Des données produit : un catalogue dans Airtable ou une base SQL, dont chaque ligne (caractéristiques, prix, cas d'usage) alimente une fiche produit rédigée — les faits viennent de la base, pas du modèle.

2. Rédaction et mise en forme par le LLM

Un node AI Agent (ou un simple node LLM) reçoit la matière première et un prompt système qui fixe la voix éditoriale : ton, longueur, structure des intertitres, formulations bannies. Le point technique qui change tout : demander une sortie structurée plutôt qu'un bloc de texte libre. Un Structured Output Parser contraint le modèle à renvoyer un JSON du type :

{
  "title": "…",
  "slug": "…",
  "content": "<p>…</p>",
  "excerpt": "…",
  "categories_suggestions": ["…"],
  "tags_suggestions": ["…"]
}

Chaque champ se mappe ensuite proprement sur le node WordPress, sans regex fragile pour découper la réponse. Le champ content peut être demandé directement en HTML simple (<p>, <h2>, <ul>), que l'éditeur WordPress accepte tel quel.

3. Création de l'article en statut draft

Le node WordPress en opération Post → Create reçoit le titre et le contenu, avec dans les champs additionnels : Status = draft, le slug, et les IDs de catégories et de tags. Ce choix de statut n'est pas un détail d'implémentation, c'est la décision d'architecture du pipeline : rien de ce que le LLM produit n'est visible publiquement à ce stade. Le brouillon est là, mis en forme, prêt à être relu dans l'éditeur WordPress habituel — l'IA a fait gagner le temps du premier jet, pas pris la main sur la ligne éditoriale.

4. Relecture humaine avant publication

Le workflow envoie ensuite une notification Slack ou email avec le titre, un extrait et le lien de prévisualisation du brouillon. Deux variantes selon le niveau d'intégration souhaité :

• Approbation asynchrone simple : la notification suffit, et la publication se fait à la main dans WordPress après relecture. Zéro mécanique supplémentaire.
• Approbation dans le flux : le pattern human-in-the-loop avec le node Wait et des boutons Slack met le workflow en pause ; un clic sur « Publier » fait reprendre l'exécution, qui passe le statut de l'article à publish (ou future avec une date). Un clic sur « Rejeter » archive le brouillon.

Pourquoi cette étape est-elle non négociable ? Parce que le problème du texte généré n'est pas qu'il soit mauvais — c'est qu'il soit plausible. Dès 2014, l'étude pionnière de Christer Clerwall, Enter the Robot Journalist (Journalism Practice — voir sur Google Scholar), faisait lire à des participants des textes d'actualité sans leur dire lesquels étaient écrits par un logiciel : les lecteurs peinaient à distinguer le texte automatisé de celui du journaliste, et le jugeaient crédible et informatif — mais moins agréable à lire. Douze ans plus tard, la leçon tient toujours : la machine passe le test de la crédibilité, pas celui du style ni de l'angle. C'est exactement ce que la relecture humaine apporte, et c'est aussi ce qui protège le site côté SEO — les moteurs de recherche ciblent explicitement le contenu de masse produit pour manipuler les classements, et un flux qui publie sans supervision finit mécaniquement par en produire.

Image à la une, catégories et tags

Le node WordPress ne gère pas l'upload de média : c'est le node HTTP Request qui s'en charge, en deux temps.

1. Upload du fichier — un POST vers /wp-json/wp/v2/media avec le binaire de l'image (générée par un node d'image IA ou récupérée d'une banque interne) :

POST https://votre-site.fr/wp-json/wp/v2/media
Headers :
  Content-Disposition: attachment; filename="image-a-la-une.jpg"
  Content-Type: image/jpeg
Body : le fichier binaire (Body Content Type = n8n Binary File)

La réponse contient l'id du média créé.

2. Affectation à l'article — un POST vers /wp-json/wp/v2/posts/{{ $json.postId }} avec {"featured_media": <id du média>}. L'image apparaît alors comme image à la une du brouillon.

Pour les catégories et tags, l'API attend des IDs numériques, pas des noms. Deux approches : maintenir une table de correspondance nom → ID dans le workflow (stable si la taxonomie bouge peu), ou interroger /wp-json/wp/v2/categories?search=… pour résoudre dynamiquement — en encadrant le LLM pour qu'il choisisse dans la liste existante plutôt que d'inventer des taxonomies à chaque article.

Champs SEO des plugins : possible, mais avec prudence

Yoast SEO et Rank Math stockent leurs données (meta title, meta description) dans des champs meta de l'article. Ces champs ne sont pas exposés en écriture par défaut sur l'API REST : selon le plugin et sa version, il faut une extension, un réglage ou quelques lignes de code côté WordPress (register_post_meta avec show_in_rest) pour les rendre accessibles. Les noms exacts des champs varient d'un plugin et d'une version à l'autre — vérifiez dans la documentation de votre plugin et testez sur un article de brouillon avant d'industrialiser, plutôt que de recopier un nom de champ trouvé dans un forum daté. Le repli pragmatique : laisser le LLM proposer meta title et meta description dans sa sortie JSON, les inclure dans le message d'approbation Slack, et laisser le relecteur les coller dans le plugin au moment de la publication.

Planifier la publication

Deux mécanismes se combinent bien :

• Côté WordPress : créer ou mettre à jour l'article avec status = future et un champ date dans le futur — WordPress publie lui-même à l'heure dite, ce qui permet d'approuver le lundi un article qui sortira le jeudi.
• Côté n8n : un Schedule Trigger cadence le pipeline en amont (générer les brouillons chaque lundi à 8h, par exemple). Attention au fuseau horaire de l'instance, source classique de publications décalées d'une heure — notre guide du Schedule Trigger, cron et fuseaux horaires détaille les réglages à vérifier.

Les bons cas d'usage — et ce qu'il ne faut pas faire

Le pipeline brille quand la matière première est factuelle et la valeur éditoriale réelle :

• Fiches produit rédigées à partir d'une base structurée, où chaque affirmation vient d'un champ de données. Un modèle appuyé sur une base documentaire interrogeable — l'architecture du Pack Assistant RAG (119 €) — réduit encore le risque d'invention en forçant le LLM à citer la documentation plutôt que sa mémoire.
• Pages programmatiques encadrées : des pages construites sur un même gabarit à partir de données vérifiées (villes, intégrations, comparatifs), avec relecture par échantillonnage et volumes raisonnables.
• Digest de veille : un résumé hebdomadaire sourcé des actualités du secteur, où le LLM condense et l'humain valide l'angle. Le même brouillon peut d'ailleurs alimenter d'autres canaux, sur le modèle du pipeline de publication LinkedIn automatisée.

À l'inverse, générer des dizaines d'articles par jour sur des mots-clés sans rien à dire, sans source ni relecture, est le cas d'école du contenu de masse : au mieux du trafic éphémère, au plus probable une réputation de domaine dégradée. Le juge de paix reste la mesure : un rapport SEO hebdomadaire branché sur Search Console dira rapidement si les contenus publiés par le pipeline se positionnent et génèrent des clics réels — ou s'ils diluent le site.

En résumé

Le pipeline tient en cinq briques : une source de contenu réelle (veille, transcript, données), un LLM avec sortie structurée pour le premier jet, le node WordPress pour créer l'article en draft, une approbation humaine via Slack ou email, et l'API wp-json en HTTP Request pour l'image à la une et les finitions. L'automatisation porte sur la mécanique — récupérer, rédiger, mettre en forme, planifier — jamais sur le jugement éditorial. C'est ce partage des rôles, pas la qualité du prompt, qui fait la différence entre un blog qui monte et un blog qui spamme.