# Comment automatiser la collecte des commentaires Facebook avec n8n

Planifiez des liens de publications publiques pour une exécution automatique à intervalles définis. Attendez la fin de la tâche de collecte, puis récupérez les données de commentaires obtenues. Enregistrez chaque commentaire à l'aide de son identifiant unique, afin que les contrôles de collecte répétés ne créent pas d'enregistrements en double.

Ce guide fournit une méthode de référence pour construire et tester en local. Il établit un workflow d'ingestion reproductible, et non un import préconstruit ni un déploiement complet vérifié. Un point de contrôle est un enregistrement sauvegardé de l'avancement de votre exécution. Un upsert est une opération de base de données qui insère une nouvelle ligne ou met à jour un enregistrement existant si une clé unique en double correspond.

## Périmètre technique et limites opérationnelles

Avant de configurer votre workflow n8n, vous devez comprendre ce que ce pipeline d'extraction traite et où se situent ses limites. Ce système se concentre strictement sur l'extraction automatisée de données et le stockage persistant. Il ne fait pas de filtrage de spam, d'analyse de sentiment, de notation de l'intention client, de réponses automatiques ni de modération de contenu. Si vous devez regrouper les commentaires en catégories personnalisées, lisez notre guide sur l'[analyse des retours clients dans les commentaires Facebook](/fr/articles/exporter-commentaires-facebook-analyser-retours-clients/). Si vous devez acheminer les questions d'assistance vers un service d'assistance en activité, consultez notre tutoriel sur la [file des questions sans réponse dans les commentaires Facebook](/fr/articles/questions-sans-reponse-commentaires-facebook/).

Ce tutoriel couvre la mise en œuvre technique avec les nœuds n8n standard et l'API HTTP du [Facebook Comments Scraper](https://apify.com/chronometrica/facebook-comments-scraper). Une API (interface de programmation d'applications, Application Programming Interface) est un ensemble de règles et de points de terminaison qui permet à différents logiciels de communiquer entre eux sur le web. Le scraper accepte en entrée des URL précises et connues de publications publiques. Il n'accepte pas les liens de profil généraux, les URL de groupes ni les pages de canaux de marque. Une fois exécuté, le scraper renvoie des enregistrements de données plats au format JSON (JavaScript Object Notation), un format texte standard pour partager des données structurées.

Chaque ligne de sortie représente soit un commentaire de premier niveau, soit une réponse imbriquée directe. La charge utile renvoyée inclut des identifiants de type chaîne, comme commentId et contentId. Notez que authorId et publishedAt peuvent être null, que publishedAt et scrapedAt sont des horodatages, et que isReply est une valeur booléenne plutôt qu'un identifiant de chaîne exact. L'objet JSON brut conserve parentCommentId, rootCommentId, isReply, text et les valeurs null. D'une exécution à l'autre, votre base de données gère la déduplication à l'aide d'une contrainte d'unicité composite sur contentId et commentId, mise en œuvre par des requêtes paramétrées.

Gardez à l'esprit les paramètres opérationnels suivants lorsque vous configurez votre pipeline :

- Liens cibles : vous devez transmettre entre 1 et 100 URL explicites de publications publiques, sous forme d'éléments de type chaîne dans un tableau.
- Plafonds de résultats : le paramètre maxResultsPerPost fixe le nombre maximal de lignes de commentaires et de réponses collectées par publication. Le régler sur 25 limite l'exécution à 25 lignes au plus par publication.
- Extraction des réponses : régler includeReplies sur true indique au scraper de collecter les réponses imbriquées en plus des commentaires parents.
- Extraction complète : régler collectAllAvailable sur true contourne le plafond numérique de résultats, tout en restant soumis aux limites de visibilité de la plateforme et aux frais de calcul.
- Paramètres de tri : des options de tri comme all, newest ou most_relevant déterminent comment Facebook ordonne les commentaires avant l'extraction. Elles fonctionnent indépendamment des plafonds de résultats.

## Référence des points de terminaison principaux de l'API

Le tableau suivant résume les points de terminaison utilisés dans ce workflow, avec leurs structures d'URL brutes et les champs de réponse attendus :

| URL du point de terminaison | Description | Champs de réponse attendus |
| --- | --- | --- |
| [https://api.apify.com/v2/acts/chronometrica~facebook-comments-scraper/runs](https://api.apify.com/v2/acts/chronometrica~facebook-comments-scraper/runs) | Lance l'exécution du scraper | data.id, data.defaultDatasetId, data.defaultKeyValueStoreId, data.status |
| [https://api.apify.com/v2/actor-runs/RUN_ID](https://api.apify.com/v2/actor-runs/RUN_ID) | Contrôle le statut d'exécution | data.status |
| [https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&clean=false&offset=0&limit=100](https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&clean=false&offset=0&limit=100) | Récupère les pages d'éléments du jeu de données | Tableau JSON d'enregistrements de commentaires |
| [https://api.apify.com/v2/key-value-stores/STORE_ID/records/OUTPUT](https://api.apify.com/v2/key-value-stores/STORE_ID/records/OUTPUT) | Inspecte le magasin de résumé de l'exécution | Enregistrement de résumé propre à l'exécution |

Remarque : remplacez les espaces réservés comme RUN_ID, DATASET_ID et STORE_ID par vos valeurs d'exécution réellement enregistrées. N'incluez jamais les jetons d'accès directement dans les chaînes d'URL.

## Architecture et séquence des nœuds, étape par étape

Pour construire ce pipeline dans n8n, vous configurerez une séquence structurée de nœuds intégrés. Vous aurez besoin de n8n installé, d'un jeton d'API Apify stocké dans un identifiant Header Auth de n8n (nommé Authorization, avec la valeur Bearer your_token) et d'un identifiant de base de données relationnelle (comme Postgres).

### 1. Configuration des déclencheurs et des identifiants

Commencez par créer un nouveau workflow dans n8n. Ouvrez les paramètres du workflow, sélectionnez votre fuseau horaire local et laissez le workflow non publié pendant que vous construisez et testez vos composants.

Vous créerez deux points d'entrée :

- Schedule Trigger : déclenche automatiquement votre exécution de collecte récurrente, quotidienne ou horaire, selon les paramètres de votre fuseau horaire.
- Manual Trigger et entrée de reprise : un point d'entrée manuel distinct pour les opérateurs. Comme un déclencheur manuel ne peut pas accepter directement un identifiant d'exécution, placez un nœud Edit Fields après lui, où un opérateur peut saisir un identifiant d'exécution déjà enregistré. Cela permet de reprendre des exécutions bloquées sans lancer une nouvelle tâche de scraping.

### 2. Lancement du scraper

Reliez votre déclencheur planifié à un nœud HTTP Request nommé Launch Scraper. Réglez la méthode sur POST et ciblez le point de terminaison d'exécution de l'acteur Apify. Associez votre identifiant Header Auth. Configurez un petit corps de requête en JSON simple, avec des chaînes d'URL brutes :

```text
{
  "startUrls": [
    "https://www.facebook.com/story.php?story_fbid=123456789&id=987654321"
  ],
  "maxResultsPerPost": 25,
  "includeReplies": true,
  "collectAllAvailable": false,
  "commentSortMode": "all"
}
```

Architecture et séquence des nœuds, étape par étape

Lorsque cette requête réussit, l'API Apify renvoie une enveloppe qui contient les métadonnées d'exécution. Votre workflow doit capturer et enregistrer immédiatement quatre valeurs : data.id, data.defaultDatasetId, data.defaultKeyValueStoreId et data.status.

Enregistrez ces valeurs dans un point de contrôle durable en base de données, indexé par l'identifiant d'exécution, en initialisant le nombre de tentatives à 0 et le décalage suivant à 0. Durable signifie stocké de façon permanente dans une base de données relationnelle, en dehors de la mémoire temporaire du workflow.

Règle de sécurité critique : ne relancez jamais automatiquement une requête POST de lancement ambiguë si un délai d'attente réseau se produit. Si la première requête a atteint le serveur, une nouvelle tentative aveugle lancera une seconde exécution de scraping facturable. Si un lancement est ambigu, inspectez manuellement la liste des exécutions de votre compte Apify avant d'en déclencher une nouvelle.

### 3. Le chemin de reprise

Si une exécution échoue ou se bloque, la branche de reprise manuelle sélectionne l'enregistrement de point de contrôle existant à l'aide de l'identifiant d'exécution fourni par l'opérateur, et ignore entièrement le nœud de lancement.

Votre workflow applique une règle d'une seule exécution active par identifiant d'exécution. Si une exécution reprise affiche déjà un statut terminal enregistré SUCCEEDED dans la base de données, le workflow ignore complètement l'interrogation du statut et passe directement au chargement des pages. Si le statut enregistré est failed, il oriente vers une revue manuelle. Les autres états entrent en interrogation bornée. Les nombres de tentatives ne sont jamais réinitialisés automatiquement par les exécutions de reprise.

### 4. Interrogation du statut et contrôle du nombre de tentatives

Avant chaque vérification de statut, votre workflow interroge la base de données pour contrôler le nombre actuel de tentatives. Si le nombre de tentatives a atteint 30, le système oriente l'exécution vers une branche de revue manuelle afin d'éviter les boucles infinies.

Si le nombre est inférieur à 30, le workflow incrémente le nombre de tentatives dans la base de données, met l'exécution en pause pendant 10 secondes avec un nœud Wait, puis utilise une requête HTTP GET pour vérifier le statut de l'exécution auprès de l'API Apify ([https://api.apify.com/v2/actor-runs/RUN_ID](https://api.apify.com/v2/actor-runs/RUN_ID)).

Les erreurs de requête réseau pendant l'interrogation doivent utiliser des nouvelles tentatives de lecture bornées (3 tentatives au maximum, avec une attente de 10 secondes), plutôt que de relancer des requêtes POST.

Le workflow évalue le statut renvoyé :

- SUCCEEDED : le workflow enregistre le statut plat dans la base de données et passe à la récupération du jeu de données.
- READY / RUNNING / ABORTING / TIMING-OUT : le workflow renvoie l'exécution vers le contrôle du nombre de tentatives pour attendre et vérifier de nouveau.
- FAILED / ABORTED / TIMED-OUT : le workflow enregistre le statut d'échec et s'arrête, ou oriente vers une revue manuelle.
- Statut inconnu : oriente vers une revue manuelle.

Remarque : arrêter votre boucle d'interrogation n'annule pas l'acteur Apify distant. Cela arrête seulement l'attente de votre workflow n8n. Un délai d'attente de l'interrogation ne signifie pas que la publication avait 0 commentaire.

### 5. Pagination et chargement des pages

Une fois l'exécution réussie, votre workflow entre dans la boucle de pagination. Avant de récupérer chaque page, il recharge l'état actuel du point de contrôle depuis la base de données pour obtenir le dernier décalage et l'identifiant du jeu de données.

Il effectue une requête HTTP GET pour récupérer les éléments du jeu de données ([https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&clean=false&offset=0&limit=100](https://api.apify.com/v2/datasets/DATASET_ID/items?format=json&clean=false&offset=0&limit=100), en remplaçant par le décalage actuel et l'identifiant de jeu de données enregistré). Vous devez cibler l'identifiant de jeu de données de l'exécution précise, et non un alias générique latest. Réglez le format de la requête sur JSON, utilisez clean=false et fixez limit=100.

Configurez le nœud HTTP pour qu'il renvoie le corps de réponse complet. Notez la longueur du tableau entrant avant de transmettre les données à tout nœud de découpage. Si le tableau de la page initiale est complètement vide, contournez le découpage et inspectez l'enregistrement de sortie du magasin clé-valeur via son point de terminaison dédié ([https://api.apify.com/v2/key-value-stores/STORE_ID/records/OUTPUT](https://api.apify.com/v2/key-value-stores/STORE_ID/records/OUTPUT)), avec l'identifiant de magasin enregistré, pour déterminer si une erreur s'est produite. Pour les pages suivantes, un tableau vide signale simplement la fin de la collecte.

### 6. Découpage et upsert en base de données

Transmettez le tableau du jeu de données à un nœud Split Out configuré avec un champ de destination explicite nommé comment.

Votre nœud de stockage en base de données, en aval, reçoit chaque élément découpé et mappe les champs directement depuis comment. Il valide l'existence d'identifiants de chaîne non vides et d'horodatages valides. Il exécute une opération d'upsert à l'aide de requêtes paramétrées sur une contrainte de clé unique composite (contentId et commentId). Un upsert insère une nouvelle ligne ou met à jour un enregistrement existant si une correspondance en double se produit.

Pour empêcher d'anciennes données d'écraser des mises à jour plus récentes, configurez la condition de mise à jour de la base de données afin que le texte et les métadonnées entrants ne se mettent à jour que si l'horodatage scrapedAt entrant est supérieur ou égal à l'horodatage stocké. Cela représente le dernier état observé de la publication publique, et non un journal d'audit historique immuable ni une preuve de suppression.

### 7. Avancement du point de contrôle

Après l'écriture réussie de tous les éléments de la page actuelle dans la base de données, votre workflow met à jour le décalage du point de contrôle dans la base de données en ajoutant 100.

Règle cruciale : n'avancez jamais le décalage du point de contrôle une fois par commentaire. Vous devez mettre à jour le décalage du point de contrôle exactement une fois par page, après la réussite de l'ensemble du lot. Si une écriture en base de données échoue au milieu d'une page, le décalage du point de contrôle reste inchangé. Votre workflow peut alors rejouer la page en sécurité, sans dupliquer les enregistrements.

Conservez séparément les métadonnées de longueur de la page actuelle pendant les étapes de découpage et de base de données. Le contrôle final utilise la longueur de la page actuelle, et non la longueur de la première boucle. Si la longueur de la page actuelle était inférieure à 100 éléments, la collecte est terminée et le workflow se termine. Si la longueur de la page est égale à 100, le workflow reboucle pour recharger le point de contrôle et récupérer le lot suivant.

## Protocole de test et de validation pour le lecteur

Avant de publier votre workflow pour une exécution automatique en production, vous devez construire et tester votre workflow en local à l'aide de contrôles de vérification structurés. Ne vous appuyez pas sur des modèles non testés.

1. Test d'ingestion isolé : injectez une entrée de fixture de test figée {body: [25 comments]} directement dans un nœud Split Out relié à votre nœud de base de données et configuré pour s'arrêter immédiatement, en contournant tous les nœuds actifs de point de contrôle et de résumé de page. Vérifiez que votre base de données stocke exactement 25 lignes. Exécuter exactement la même fixture une deuxième fois aboutit à 0 nouvelle ligne insérée, et les enregistrements existants sont évalués sans régression. L'ajout d'un 26e enregistrement distinct insère exactement 1 nouvelle ligne. Vérifiez en outre qu'une fixture plus ancienne ne peut pas écraser un texte plus récent.
2. Test de fixture de pagination : testez votre boucle de décalage avec un point de contrôle simulé et 201 enregistrements sur 3 pages de 100, 100 et 1, sans aucun appel Actor payant.
3. Test de tolérance aux pannes et d'interrogation : vérifiez que les nombres maximaux d'interrogations déclenchent correctement la revue manuelle sur le chemin d'interrogation. Simulez un échec d'écriture en base de données sur une page intermédiaire. Vérifiez que le décalage de votre point de contrôle reste inchangé, que la reprise ne relance pas le scraper, et que les statuts qui ne sont pas une réussite bloquent correctement la récupération du jeu de données.
4. Vérification manuelle en direct : exécutez un seul test manuel sur un lien réel de publication publique. Examinez vos limites de plateforme, vos coûts de calcul et vos journaux d'exécution.

N'enregistrez et ne publiez votre workflow n8n qu'après la réussite de tous les tests locaux et la configuration correcte du fuseau horaire de la planification.

## Automatisez dès aujourd'hui votre collecte de commentaires Facebook

Construire un pipeline personnalisé d'ingestion de commentaires donne à votre équipe un accès fiable aux données de discussion publique, sans exports manuels de feuilles de calcul. En associant les nœuds n8n standard à des points de contrôle durables en base de données et à des contraintes d'unicité composites, vous établissez un workflow d'extraction résilient qui gère proprement les interruptions réseau. Commencez dès aujourd'hui à extraire des conversations sociales structurées avec le [Facebook Comments Scraper](https://apify.com/chronometrica/facebook-comments-scraper).

## Sources et lectures complémentaires

- [Acteur Facebook Comments Scraper](https://apify.com/chronometrica/facebook-comments-scraper)
- [Documentation du Schedule Trigger n8n](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/)
- [Documentation du nœud HTTP Request n8n](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/)
- [Documentation du nœud Wait n8n](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.wait/)
- [Documentation du nœud Postgres n8n](https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.postgres/)
- [Documentation du nœud Split Out n8n](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.splitout/)
- [Référence de l'API Apify - Get Actor Run](https://docs.apify.com/api/v2/actor-run-get)
- [Référence de l'API Apify - Get Dataset Items](https://docs.apify.com/api/v2/dataset-items-get)
- [Guide Chronometrica d'analyse des retours](/fr/articles/exporter-commentaires-facebook-analyser-retours-clients/)
- [Guide Chronometrica des questions sans réponse](/fr/articles/questions-sans-reponse-commentaires-facebook/)