Publier automatiquement sur X (Twitter) avec n8n et l'IA

Sur X, la fenêtre entre une actualité et sa pertinence se compte en heures, pas en jours : un thread technique publié le lendemain d'un sujet chaud a déjà raté le pic d'attention. C'est la plateforme où l'automatisation a le plus de valeur — et où elle se voit le plus vite si elle est mal conçue. Ce guide construit un pipeline n8n qui accélère la rédaction avec l'IA sans jamais publier sans validation humaine, et couvre le piège technique le plus fréquent sur X : l'authentification, qui diffère selon qu'on publie du texte ou qu'on joint une image.

Node X natif ou HTTP Request : bien choisir sa brique

n8n embarque un node X (Formerly Twitter) natif, avec des actions prêtes à l'emploi : créer un post, supprimer un tweet, liker, retweeter, rechercher, envoyer un message direct. Sa credential OAuth2 prédéfinie couvre les scopes courants (tweet.write, tweet.read, users.read, offline.access) et suffit largement pour un post texte planifié.

La limite apparaît sur des besoins plus fins : sondages intégrés au post, gestion précise des réponses à un thread, ou logique conditionnelle sur le corps de la requête que le node ne couvre pas nativement. Dans ces cas, un node HTTP Request en POST vers https://api.x.com/2/tweets avec l'en-tête Authorization: Bearer <access_token> reproduit exactement ce que fait le node natif, avec un contrôle total sur le JSON envoyé — le même choix que celui documenté dans notre guide pour publier automatiquement sur LinkedIn avec n8n, où l'API évolue plus vite que la couverture d'un node générique.

Le piège de l'upload média : OAuth2 ne suffit pas toujours

C'est le point qui bloque le plus de workflows n8n sur X : publier du texte pur en OAuth2 fonctionne sans accroc, mais joindre une image se heurte souvent à une erreur 403 sur les endpoints d'upload, y compris sur les nouveaux endpoints v2 en trois temps (/2/media/upload/initialize, /append, /finalize) censés remplacer l'ancien v1.1/media/upload.json. De nombreux développeurs rapportent encore ce comportement sur le forum développeur de X à l'heure actuelle, alors que le même token OAuth2 publie le texte sans problème.

Le contournement qui fonctionne de façon fiable en pratique :

1. Garder la credential OAuth2 du node X (ou du HTTP Request) pour la publication du post lui-même (/2/tweets).
2. Créer une seconde credential OAuth 1.0a (clé et secret d'API classiques, plus token et secret d'accès) dédiée uniquement à l'upload média.
3. Un premier node HTTP Request, authentifié en OAuth 1.0a, uploade le fichier et récupère le media_id.
4. Le node de publication (OAuth2) référence ce media_id dans le tableau media.media_ids du post.

Cette asymétrie n'est pas un bug de configuration côté n8n : c'est l'état actuel de l'API X, à vérifier régulièrement sur la documentation officielle car elle évolue. Mieux vaut prévoir les deux credentials dès la conception du workflow plutôt que de découvrir le blocage en production.

Le pipeline en quatre étapes

1. Un déclencheur planifié et une source de sujets

Un Schedule Trigger (par exemple trois fois par semaine) lance le workflow. La source peut être une liste de sujets préparée dans un calendrier éditorial Notion — voir notre article sur le calendrier éditorial multi-réseaux avec Notion et n8n — ou un flux d'actualité sectorielle agrégé par un node RSS Feed Read, sur le même principe que notre guide de veille concurrentielle automatisée par IA.

2. Génération du brouillon par un AI Agent

Un node AI Agent reçoit le sujet et un prompt système strict : longueur cible (280 caractères pour un post simple, structure en plusieurs tweets pour un thread), ton de la marque, exemples de posts passés en few-shot, et une liste noire de tournures génériques à éviter. C'est là que le gain de temps se mesure : X récompense la réactivité, et un brouillon produit en quelques secondes plutôt qu'en vingt minutes permet de réagir à une actualité pendant qu'elle est encore chaude.

Ce gain a toutefois une limite documentée. Une étude de 2024 menée par Radivojevic, Chou, Badillo-Urquiola et Brenner (Université de Notre Dame), qui a recruté plus de 1 000 participants pour distinguer des posts humains de posts générés par IA sur des fils de discussion de réseaux sociaux, montre que les lecteurs humains identifient mal ce contenu de façon explicite — mais ressentent malgré tout un malaise diffus face à lui, un effet d'« uncanny valley » textuel (Radivojevic et al., 2024). Concrètement : ne pas se fier au seul fait que « personne ne le remarquera » pour sauter la relecture humaine — le malaise, lui, reste perceptible même sans identification consciente.

3. Relecture humaine obligatoire avant publication

Le brouillon ne part jamais directement sur X. Il est envoyé sur Slack pour validation, en reprenant le pattern human-in-the-loop détaillé dans notre article sur l'approbation humaine avec le node Wait et des boutons Slack : un node Wait en mode On Webhook Call met le workflow en pause, un message Slack présente le brouillon avec des boutons « Publier » / « Modifier » / « Rejeter », et seule une action explicite relance l'exécution via le resumeUrl. Sur X plus qu'ailleurs, cette étape rattrape aussi les erreurs de contexte qu'un LLM peut commettre sur une actualité en cours — un risque réel quand la vitesse de publication est justement l'objectif recherché.

4. Publication via l'API X

Une fois validé, le post part vers l'endpoint /2/tweets :

POST https://api.x.com/2/tweets
Headers :
  Authorization: Bearer <access_token>
  Content-Type: application/json
Body (JSON) :
  {
    "text": "{{ $json.posteValide }}"
  }

Pour un thread, chaque tweet suivant référence l'identifiant du précédent via reply.in_reply_to_tweet_id, ce qui impose de récupérer l'id retourné par chaque appel avant d'enchaîner le suivant — un enchaînement naturel à construire avec un Loop Over Items plutôt qu'un envoi en parallèle, sur le même principe de cadencement que celui décrit dans notre guide sur les rate limits des API IA dans n8n (les quotas de publication X répondent à la même logique de fenêtre glissante).

Variantes utiles

• Republication d'un article de blog en fil résumé : l'AI Agent reçoit le contenu complet d'un article déjà publié et génère un thread de 3 à 5 tweets qui en résume les points clés, avec un lien vers l'article en dernier post.
• Veille et réaction rapide : le même flux RSS qui alimente un digest peut aussi déclencher une proposition de post dès qu'une actualité correspond à des mots-clés surveillés, avec la relecture Slack comme seul frein avant publication.
• Programmation différée : au lieu d'un Schedule Trigger unique, une table Supabase de posts pré-validés associée à un cron régulier permet d'étaler dans la journée des posts approuvés en une seule session de relecture.

Sécuriser les deux credentials

Deux jeux de clés cohabitent dans ce pipeline (OAuth2 pour la publication, OAuth 1.0a pour l'upload média) : traitez-les avec la même rigueur que n'importe quelle credential API sensible, en suivant les principes de notre guide pour sécuriser ses credentials API dans n8n — accès restreint aux seuls workflows qui en ont besoin, et rotation prévue en cas de doute sur une fuite.

En résumé

Le pipeline tient en quatre briques : Schedule Trigger pour le rythme, AI Agent pour le premier jet, Wait + Slack pour la validation humaine, et HTTP Request (ou node X natif) pour la publication — avec une attention particulière portée à la double authentification dès qu'une image entre en jeu. Les patterns de génération assistée par IA et de validation humaine construits ici sont les mêmes qui équipent les workflows de brouillons du Pack Inbox IA : une fois le principe acquis sur X, il se transpose directement à d'autres canaux.