Générer des fiches produits e-commerce en masse avec l'IA dans n8n

Un catalogue e-commerce de plusieurs centaines ou milliers de références pose toujours le même dilemme : rédiger chaque fiche produit à la main coûte un temps que peu de boutiques ont, mais importer les descriptions du fournisseur telles quelles revient à publier le même texte que des dizaines d'autres sites — un classique du contenu dupliqué, mauvais pour le référencement et pour la conversion. n8n permet de construire un pipeline qui lit votre catalogue, génère une fiche unique et argumentée pour chaque produit avec un LLM, contrôle sa qualité, puis la repousse automatiquement vers Shopify, WooCommerce ou PrestaShop.

Ce n'est pas qu'une intuition marketing : une étude de Reisenbichler, Reutterer, Schweidel et Dan publiée dans Marketing Science en 2022, menée en conditions réelles dans deux secteurs, a montré qu'un contenu SEO généré par un modèle de langage puis révisé par un éditeur humain se classait aussi bien — voire mieux — dans les résultats de recherche qu'un texte rédigé entièrement par des experts SEO humains, tout en restant quasiment indiscernable d'un texte humain pour un lecteur (Reisenbichler et al., 2022, Marketing Science — voir sur Google Scholar). Le rôle de l'éditeur humain y reste toutefois décrit comme essentiel : c'est précisément l'articulation que ce workflow met en place — génération automatique, mais avec un point de contrôle qualité avant publication plutôt qu'une écriture directe en production.

Vue d'ensemble du pipeline

Le workflow tient en cinq étapes : lecture du catalogue source, préparation des attributs par produit, génération du texte par un LLM contraint à un schéma structuré, contrôle qualité (longueur, doublons, mots interdits), puis écriture dans la plateforme e-commerce.

Source catalogue → Préparer attributs → LLM (titre + description + meta) → Contrôle qualité → IF (ok / à relire) → Publication API

Le déclencheur : d'où vient le catalogue

Trois sources reviennent le plus souvent, chacune avec un déclencheur n8n adapté :

• Fichier CSV ou Google Sheets — le cas le plus courant pour un import fournisseur en masse. Un node Google Sheets (lecture) ou Read Binary File + Spreadsheet File suffit à récupérer les lignes du catalogue.
• Shopify ou WooCommerce existant — pour retraiter des fiches déjà en ligne mais incomplètes. Le node natif du connecteur (voir nos guides Shopify et WooCommerce) récupère la liste des produits via l'API, filtrée par exemple sur les descriptions vides ou trop courtes.
• PrestaShop — même logique via l'API Webservice, voir notre guide de connexion PrestaShop.

Dans les trois cas, un node Loop Over Items traite le catalogue par lots plutôt qu'en une seule passe géante : essentiel pour ne pas saturer l'API du LLM ni celle de la plateforme e-commerce sur un catalogue de plusieurs milliers de lignes. Le détail de ce pattern (taille de lot, Wait entre chaque lot, lecture du header retry-after) est couvert dans notre guide sur les boucles n8n et notre guide sur les rate limits d'API.

Préparer les attributs produit

Un node Set (ou Code) normalise chaque ligne en un objet structuré, avant de le transmettre au LLM :

return items.map((item) => ({
  json: {
    sku: item.json.sku,
    nom: item.json.name,
    categorie: item.json.category,
    attributs: {
      couleur: item.json.color,
      matiere: item.json.material,
      dimensions: item.json.dimensions,
    },
    prix: item.json.price,
  },
}));

Ce point est déterminant pour la qualité du texte généré : plus les attributs distinctifs (couleur, matière, dimensions, usage prévu) sont explicites en entrée, moins le modèle a de raisons de produire un texte générique interchangeable d'une référence à l'autre — le risque numéro un sur un catalogue avec beaucoup de variantes proches (mêmes chaussures en cinq coloris, par exemple).

Génération du texte : LLM Chain et sortie structurée

Un node Chain LLM (ou AI Agent pour les cas où le modèle doit aussi consulter une fiche technique externe) reçoit ces attributs et un prompt qui fixe le cadre : ton de marque, longueur cible, interdiction d'inventer une caractéristique absente des attributs fournis. Un node Structured Output Parser en aval force la réponse dans un schéma fixe :

{
  "titre_seo": "string, 60 caractères max",
  "description_courte": "string, 160 caractères max",
  "description_longue": "string, 400-600 caractères",
  "meta_description": "string, 155 caractères max"
}

Ce schéma structuré évite le piège classique du texte libre difficile à réinjecter proprement dans les champs d'une fiche produit — le même principe que celui détaillé dans notre guide sur l'Information Extractor et sur le Structured Output Parser.

Contrôle qualité avant publication

C'est l'étape qui distingue un pipeline fiable d'un générateur de contenu creux. Un node Code applique une série de vérifications automatiques avant tout envoi vers la plateforme :

const d = $json;
const problemes = [];

if (d.description_longue.length < 200) problemes.push("description trop courte");
if (/\b(meilleur|numéro un|incroyable)\b/i.test(d.description_longue)) {
  problemes.push("superlatif non vérifiable");
}
if (d.titre_seo.length > 60) problemes.push("titre SEO trop long");

return [{ json: { ...d, ok: problemes.length === 0, problemes } }];

Un node IF sépare ensuite les fiches conformes (publication directe) des fiches à relire (routées vers une file de relecture humaine plutôt que bloquées). Pour les catalogues volumineux, un contrôle supplémentaire de similarité — comparer l'embedding de chaque nouvelle description à celles déjà générées dans la même catégorie — permet de détecter les cas où le modèle a malgré tout produit un texte trop proche d'une autre fiche, et de forcer une régénération ciblée sur ces références.

Pour les cas ambigus qui ne doivent pas partir en publication automatique (catégories réglementées, allégations santé, produits à forte marge), le pattern d'approbation humaine avec Wait et Slack s'applique directement : un message Slack avec la fiche générée, deux boutons, et le workflow reprend son cours à la réponse.

Publication vers la plateforme

Une fois validée, la fiche repart vers sa plateforme d'origine via le node natif (Shopify, WooCommerce, PrestaShop) ou un HTTP Request authentifié pour les cas non couverts par un node dédié. Mappez explicitement chaque champ généré vers le champ correspondant côté plateforme plutôt que d'écraser l'objet produit complet — cela évite d'effacer par erreur des champs gérés ailleurs (stock, variantes, images).

Champ généré	Destination Shopify	Destination WooCommerce
titre_seo	title	name
description_longue	body_html	description
meta_description	metafield SEO	champ Yoast/RankMath

Catalogues multilingues

Pour une boutique qui vend en plusieurs langues, il est plus fiable de générer d'abord la fiche dans la langue source avec tous les attributs, puis de la traduire avec un second appel LLM dédié plutôt que de demander une génération multilingue en un seul prompt — la qualité et la cohérence terminologique s'en trouvent nettement meilleures. Notre guide sur la traduction automatisée de contenus détaille ce pattern en deux passes.

En résumé

Un pipeline de fiches produits par IA dans n8n tient sur quatre garde-fous : des attributs d'entrée explicites plutôt qu'un simple nom de produit, une sortie structurée plutôt qu'un texte libre, un contrôle qualité automatique avant publication, et un point de relecture humaine pour les cas sensibles. C'est cette dernière étape — la supervision, pas l'automatisation totale — qui fait la différence entre un catalogue qui gagne en visibilité et un catalogue qui accumule du contenu générique. Si votre catalogue s'appuie déjà sur une base documentaire (fiches techniques fournisseurs, guides d'utilisation), le pipeline d'ingestion décrit dans notre guide RAG avec Supabase peut alimenter directement le prompt de génération avec des données produit plus riches que le seul export du catalogue.