Modérer avis et commentaires automatiquement avec l'IA dans n8n

Un site e-commerce qui reçoit des avis produits, un blog avec des commentaires ouverts, un forum ou une communauté Discord : dès que les utilisateurs peuvent publier du contenu, quelqu'un doit le relire. Le spam promotionnel arrive vite, les insultes suivent, et entre les deux s'étale une zone grise de messages limites qu'aucune règle simple ne tranche. Modérer tout à la main ne tient pas la charge ; publier sans filtre expose votre image de marque et, pour les contenus manifestement illicites, à des obligations légales de retrait. Un pipeline n8n qui classe chaque contenu à l'arrivée, publie les cas évidents et fait relire les cas douteux par un humain offre le meilleur des deux mondes.

Pourquoi la modération manuelle ne tient pas la charge

Le problème de l'UGC (user generated content) n'est pas la difficulté unitaire — décider si « super produit, livraison rapide » est publiable prend deux secondes — mais le débit et la disponibilité :

• Le spam arrive par vagues, souvent la nuit ou le week-end, quand personne ne relit la file ;
• Un commentaire insultant ou diffamatoire visible pendant douze heures fait plus de dégâts qu'un commentaire bloqué dix minutes de trop ;
• La cohérence des décisions se dégrade quand plusieurs personnes modèrent selon leur propre lecture des règles, sans trace de qui a décidé quoi.

Une étude de Gorwa, Binns et Katzenbach publiée en 2020 dans Big Data & Society (« Algorithmic content moderation ») analyse précisément ce compromis : l'automatisation est ce qui permet de tenir l'échelle, mais les cas ambigus — ironie, contexte culturel, critique virulente mais légitime — continuent d'exiger un jugement humain. C'est exactement le circuit hybride que ce pipeline met en place : l'IA tranche les cas évidents, l'humain garde la main sur la zone grise.

Architecture du pipeline

Webhook (CMS, Shopify, Disqus…)
        │
        ▼
Normalisation (Set / Code)
        │
        ▼
API Moderation OpenAI ── premier filtre gratuit
        │
        ▼
Text Classifier / LLM + Structured Output Parser
        │
        ▼
      Switch
  ┌─────┼─────────────┐
  ▼     ▼             ▼
Publier Rejeter   Relecture humaine (Slack)
  │     │             │
  └─────┴──────┬──────┘
               ▼
Journal d'audit (Google Sheets / Postgres)

Étape 1 — Réception et normalisation

Le point d'entrée est un node Webhook : la plupart des sources d'UGC savent notifier une URL à chaque nouveau contenu — webhook Shopify sur création d'avis produit, hook WordPress ou Ghost sur nouveau commentaire, webhook Disqus, ou simple appel HTTP depuis votre propre application au moment de la soumission.

Chaque source envoie un payload différent. Un node Set (ou Code pour les cas tordus) normalise tout vers un format unique avant classification :

{
  "source": "shopify",
  "type": "avis_produit",
  "texte": "Produit reçu cassé, service client injoignable...",
  "auteur_id": "cust_84213",
  "cible": "produit-chaise-oslo",
  "recu_le": "2026-08-04T09:12:00Z"
}

Notez ce qui n'y figure pas : l'email et le nom complet de l'auteur. Le modèle n'en a pas besoin pour classer le texte, et ne pas les transmettre simplifie nettement la conformité RGPD (on y revient plus bas).

Étape 2 — Premier filtre : l'API Moderation d'OpenAI

Avant de mobiliser un LLM, un appel à l'endpoint /v1/moderations d'OpenAI via un node HTTP Request écarte les cas graves. Cet endpoint dédié à la modération est gratuit à ce jour et renvoie des scores par catégorie (harcèlement, haine, contenu sexuel, violence…). Un commentaire signalé avec un score élevé peut partir directement en rejet ou en relecture humaine sans passer par la classification complète.

Ce premier filtre a deux limites qui justifient la suite du pipeline : il est entraîné sur des catégories génériques (il ne détecte pas le spam promotionnel ni le hors-sujet) et il ne connaît pas vos règles maison — un concurrent qui poste un lien vers sa boutique n'est ni haineux ni violent, mais vous ne voulez pas le publier.

Étape 3 — Classification en quatre catégories

Le cœur du workflow classe chaque contenu dans l'une de quatre catégories : publiable, spam, toxique (insultes, attaques personnelles, contenu illicite) ou ambigu (à faire relire par un humain).

Deux options dans n8n. La plus simple : le node Text Classifier, où vous définissez les catégories avec une description chacune — notre guide du Text Classifier détaille sa configuration. Pour un contrôle plus fin (motifs, score de confiance), une Basic LLM Chain avec un Structured Output Parser impose un schéma de sortie :

{
  "verdict": "publiable | spam | toxique | ambigu",
  "motifs": ["lien promotionnel non sollicité"],
  "confiance": 0.92
}

Le prompt système décrit vos règles concrètement :

Tu modères les avis et commentaires d'un site e-commerce.
Classe chaque texte dans une seule catégorie :
- publiable : opinion sur le produit ou service, même très négative.
  Une critique dure mais argumentée est PUBLIABLE.
- spam : lien promotionnel, contenu hors sujet, texte généré en masse.
- toxique : insulte, attaque personnelle, menace, contenu discriminatoire.
- ambigu : tu hésites entre deux catégories, ironie difficile à lire,
  ou accusation grave invérifiable (ex. « ce produit m'a rendu malade »).
Réponds uniquement au format JSON demandé.
En cas de doute, choisis "ambigu" plutôt que de trancher.

La dernière ligne est la plus importante du prompt : elle inverse le biais naturel du modèle, qui préfère trancher, au profit de la prudence. Le fonctionnement du parser et la gestion de ses erreurs sont couverts dans notre guide du Structured Output Parser.

Étape 4 — Routage avec Switch

Un node Switch à quatre sorties route selon {{ $json.verdict }}, en ajoutant une règle de sécurité : tout verdict avec confiance < 0.8 est traité comme ambigu, quel que soit le label. La configuration des règles de routage est détaillée dans notre guide des nodes IF et Switch.

• Publiable : un appel API vers le CMS ou Shopify publie le contenu (ou le marque « approuvé »). Aucune intervention humaine.
• Spam : rejet silencieux. Inutile de notifier l'auteur — un message de rejet détaillé renseigne surtout le spammeur sur la façon de contourner le filtre.
• Toxique : rejet avec motif générique côté auteur (« votre commentaire ne respecte pas nos règles de publication »), et conservation du texte au journal d'audit — utile si le contenu relève d'une obligation de retrait ou d'un signalement.
• Ambigu : direction la file de relecture humaine.

Étape 5 — La file de relecture humaine dans Slack

Pour les cas ambigus, un node Slack poste le texte complet, le verdict provisoire, les motifs et deux boutons Approuver / Rejeter, puis le workflow se met en pause jusqu'au clic grâce au node Wait. Le mécanisme complet — boutons interactifs, reprise du workflow, délai d'expiration — est décrit pas à pas dans notre article sur l'approbation humaine avec Wait et Slack dans n8n.

Ce circuit hybride est ce qui rend le système tenable dans les deux sens : l'équipe ne voit passer que les 5 à 15 % de cas réellement difficiles, et aucun contenu limite n'est publié ou censuré sur la seule foi d'un score de probabilité.

Journal d'audit : indispensable, pas optionnel

Chaque décision — automatique ou humaine — s'écrit dans un node Google Sheets (Append) ou Postgres (Insert) : texte, source, verdict, motifs, confiance, décideur (auto ou identifiant du relecteur), horodatage. Ce journal sert trois usages concrets : répondre à un utilisateur qui conteste un rejet, mesurer le taux de faux positifs pour ajuster prompt et seuils, et documenter vos décisions si un contenu signalé fait l'objet d'une demande de retrait.

Relisez ce journal les premières semaines : c'est là que vous verrez si le modèle classe « spam » des avis négatifs légitimes (le faux positif le plus coûteux, car il ressemble à de la censure d'avis) ou s'il laisse passer un type de spam récurrent qu'un exemple ajouté au prompt suffirait à bloquer.

RGPD : les commentaires contiennent des données personnelles

Un avis client peut contenir un nom, une adresse, un numéro de commande, voire des données de santé (« ce complément m'a donné des migraines »). Trois réflexes : transmettre au modèle le texte seul, sans les métadonnées d'identité de l'auteur ; encadrer l'appel au fournisseur d'IA par un DPA et le mentionner dans votre politique de confidentialité ; définir une durée de rétention du journal d'audit et le purger au-delà. Et si un auteur exerce son droit à l'effacement, le journal fait partie des systèmes à couvrir — notre article sur le traitement automatisé des demandes RGPD avec n8n montre comment industrialiser cette partie.

En résumé

Modérer l'UGC avec n8n tient en cinq briques : un Webhook qui reçoit chaque contenu, une normalisation, un premier filtre gratuit via l'API Moderation d'OpenAI, une classification en quatre catégories avec sortie structurée (verdict, motifs, confiance), et un Switch qui publie, rejette ou envoie en relecture humaine dans Slack — le tout tracé dans un journal d'audit. Le principe directeur, validé aussi bien par la recherche que par la pratique : automatiser les cas évidents, jamais les cas douteux. Une fois ce pipeline en place, la brique d'analyse s'étend naturellement — par exemple vers l'analyse de sentiment des avis clients par IA sur les contenus publiés.