Publier automatiquement sur Threads avec n8n et l'IA

Threads a dépassé les 400 millions d'utilisateurs actifs mensuels fin 2025, porté en bonne partie par des comptes qui ont d'abord quitté X. Une étude de Radivojevic, Adams, Laszlo, Kery et Weninger (Université de Notre Dame), publiée en 2025 dans EPJ Data Science, User migration in the Twitter diaspora, montre que ce sont surtout les comptes à forte audience sur X qui migrent vers les plateformes alternatives — et que, contrairement à Mastodon ou Truth Social, le nombre d'abonnés sur X se retrouve fortement corrélé au nombre d'abonnés gagnés sur Threads. Autrement dit : l'audience se transfère réellement sur Threads, ce qui en fait un canal qu'il vaut la peine d'alimenter avec la même rigueur qu'Instagram ou X — sans pour autant disposer, à ce jour, d'un node n8n dédié.

Ce qu'expose l'API Threads

L'API Threads (documentée sur developers.facebook.com/docs/threads) reprend presque à l'identique le modèle de l'API Content Publishing d'Instagram, avec son propre domaine :

• Un compte professionnel Threads est requis, lié à l'app Meta utilisée. Le scope threads_basic est activé par défaut ; threads_content_publish doit être ajouté explicitement pour pouvoir publier, ce qui suppose de passer l'App Review de Meta avant tout usage en production au-delà des comptes de test.
• Un container, puis une publication. Un premier appel POST /{threads-user-id}/threads crée un container avec le media_type (TEXT, IMAGE, VIDEO ou CAROUSEL) et le contenu associé. La réponse renvoie un id de container, rien n'est encore publié à ce stade.
• Le container doit finir de traiter avant publication pour l'image et la vidéo — un GET /{container-id}?fields=status renvoie IN_PROGRESS, FINISHED, ERROR ou EXPIRED.
• La publication proprement dite se fait avec POST /{threads-user-id}/threads_publish et le creation_id du container.
• Un quota de 250 publications par 24 heures glissantes s'applique par compte (un carrousel compte pour une seule publication). L'endpoint GET /{threads-user-id}/threads_publishing_limit renvoie la consommation actuelle du quota.
• Le token d'accès de courte durée issu de l'échange OAuth dure environ une heure et doit être échangé contre un token longue durée (environ 60 jours), lui-même rafraîchissable avant expiration.

Aucun node natif n8n ne couvre ce flux à ce jour : soit le node communautaire n8n-nodes-meta-publisher, soit — l'option retenue ici pour un contrôle total sur le polling et les erreurs — une série de nodes HTTP Request.

Le pipeline en n8n

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

Un Schedule Trigger lance le workflow depuis un calendrier éditorial tenu dans Notion ou Airtable, sur le même principe que celui décrit dans notre article sur le calendrier éditorial multi-réseaux avec Notion et n8n. Chaque ligne porte un sujet, un format cible (texte, image, carrousel) et un statut « à traiter ».

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

Un node AI Agent reçoit le sujet et un prompt système qui fixe le ton (Threads penche plus conversationnel qu'Instagram, plus proche du fil de discussion que de la vitrine), la longueur cible (500 caractères maximum par post) et des exemples de publications passées en few-shot. Verrouiller la sortie avec un Structured Output Parser (champs texte, media_type, alt_text) évite les surprises de format en aval, exactement comme pour le pipeline Instagram déjà documenté sur ce blog.

3. Génération et hébergement public du visuel (si applicable)

Pour un post image ou carrousel, le node OpenAI (ressource Image) génère le visuel — voir notre guide sur la génération d'images par IA dans n8n. Comme pour Instagram, Threads n'accepte pas de fichier binaire en entrée du container : il faut une URL publiquement accessible (image_url ou video_url), donc un passage préalable par un stockage exposé publiquement (bucket S3, Supabase Storage en accès public).

4. Relecture humaine avant tout appel à l'API

Le brouillon est envoyé sur Slack pour validation, avec 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 jusqu'à un clic « Publier » ou « Rejeter ». Sur un canal aussi rapide que Threads, cette étape reste la meilleure garantie contre un post généré hors contexte sur une actualité qui a déjà bougé au moment de la publication.

5. Création du container, attente, puis publication

1) POST https://graph.threads.net/v1.0/{threads-user-id}/threads
   Headers : Authorization: Bearer <access_token>
   Body : { "media_type": "TEXT", "text": "{{ $json.texte }}" }
   → renvoie { "id": "<container_id>" }

2) GET https://graph.threads.net/v1.0/{container_id}?fields=status
   → poller (avec un node Wait entre chaque relève) jusqu'à status = "FINISHED"
   (inutile pour un post TEXT pur, indispensable pour IMAGE, VIDEO ou CAROUSEL)

3) POST https://graph.threads.net/v1.0/{threads-user-id}/threads_publish
   Body : { "creation_id": "<container_id>" }

Le pattern soumission-puis-polling est identique à n'importe quelle API asynchrone lente : les bonnes pratiques de retry et timeout s'appliquent telles quelles, notamment pour éviter de boucler indéfiniment sur un container bloqué en ERROR.

Variantes : carrousel et réponses enchaînées

• Carrousel : créer d'abord un container par image avec is_carousel_item: true, puis un container parent avec media_type: "CAROUSEL" et children: ["id1", "id2", ...] référençant les containers enfants — même mécanique que sur Instagram.
• Réponse enchaînée (thread de posts) : chaque post suivant référence l'id du post précédent via le champ reply_to_id au moment de la création du container, ce qui impose de récupérer l'identifiant retourné avant d'enchaîner le suivant — un traitement à construire avec un Loop Over Items plutôt qu'un envoi en parallèle.
• Republication d'un article de blog : l'AI Agent reçoit le contenu complet d'un article déjà publié et en génère un résumé en un ou plusieurs posts, sur le même principe que la republication décrite dans notre guide X (Twitter).

Gérer le renouvellement du token

Le token longue durée expire au bout d'environ 60 jours. Un second workflow, planifié une fois par mois avec un Schedule Trigger, appelle l'endpoint de rafraîchissement et remplace la valeur stockée dans la credential n8n — évitez de laisser cette tâche à la mémoire humaine, c'est la cause la plus fréquente de panne silencieuse sur ce type de pipeline (le workflow échoue un mois plus tard, sans lien évident avec le token).

Pièges fréquents

• Confondre graph.facebook.com et graph.threads.net : Threads utilise son propre domaine d'API, distinct de celui d'Instagram et de Facebook — une erreur de copier-coller entre pipelines Meta fréquente quand on a déjà un workflow Instagram en place.
• Oublier l'URL publique : comme pour Instagram, un lien non accessible publiquement fait échouer la création du container, parfois avec un message d'erreur peu explicite.
• Ignorer le quota de 250 posts/24h : au-delà d'un compte géré à haute cadence, interrogez threads_publishing_limit avant d'envoyer une rafale de publications plutôt que de découvrir la limite en pleine campagne.
• Laisser le token longue durée expirer sans renouvellement automatisé : la panne la plus fréquente et la plus évitable de ce pipeline.

Pour aller plus loin

Le pipeline décrit ici — déclencheur planifié, génération par IA, sortie structurée, relecture humaine avant action — reprend exactement les patterns qui structurent les workflows de tri et de rédaction du Pack Inbox IA (79 €), appliqués cette fois à un canal social plutôt qu'à une boîte mail. Si vous publiez déjà sur Instagram ou X avec n8n, la majorité de ce pipeline — génération, relecture Slack, hébergement des visuels — se réutilise telle quelle : seule la couche d'appels API change de domaine et de forme de payload.