Facebook Scraper GitHub : ce qui fonctionne encore et ce qui ne fonctionne plus

Une recherche GitHub pour « facebook scraper » renvoie . Seuls ont été mis à jour au cours des six derniers mois.

L’écart entre « disponible » et « fonctionne vraiment » résume à lui seul le scraping Facebook sur GitHub en 2026.

J’ai passé beaucoup de temps à fouiller les onglets d’incidents des dépôts, les plaintes sur Reddit et les résultats réels produits par ces outils. Le constat est toujours le même : la plupart des projets les plus étoilés sont discrètement cassés, leurs mainteneurs sont passés à autre chose, et les défenses anti-scraping de Facebook deviennent de plus en plus solides. Les développeurs comme les utilisateurs métier retombent sans cesse sur les mêmes résultats de recherche, installent les mêmes dépôts et se heurtent au même résultat vide. Cet article est un état des lieux 2026 — un audit honnête des dépôts qui valent encore votre temps, de ce que Facebook fait pour les casser, et du moment où il vaut mieux éviter GitHub complètement.

Pourquoi les gens cherchent un Facebook Scraper sur GitHub

Les cas d’usage derrière cette recherche sont les mêmes depuis des années — même si les outils, eux, s’effritent peu à peu :

• Génération de leads : extraire les coordonnées des pages d’entreprise (emails, numéros de téléphone, adresses) pour des actions commerciales
• Surveillance de Marketplace : suivre les annonces, les prix et les infos vendeur pour l’e-commerce ou l’arbitrage
• Recherche dans les groupes : archiver les publications et les commentaires pour des études de marché, l’OSINT ou la gestion de communauté
• Archivage de contenus et de publications : sauvegarder les publications publiques, réactions, images et horodatages
• Agrégation d’événements : récupérer les titres d’événements, les dates, les lieux et les organisateurs

L’attrait de GitHub est évident : code visible, coût nul, maintenance communautaire (en théorie) et contrôle total sur les champs et les pipelines.

Le problème, c’est que les étoiles et les forks ne disent rien sur le fait qu’un projet soit « encore fonctionnel ». Parmi les 10 dépôts correspondant exactement à l’expression et les plus étoilés, en avril 2026. Ce n’est pas une anomalie — c’est la norme.

Un utilisateur Reddit, dans , l’a dit très clairement après six mois d’essais : c’était « impossible sans payer une application externe de scraping de données » ou sans utiliser Python, du rendu JS et une puissance de calcul importante. Un autre, dans , l’a résumé ainsi : « Facebook est l’un des plus difficiles à scraper parce qu’ils bloquent agressivement l’automatisation » et l’automatisation navigateur est « fragile, car Facebook modifie constamment son DOM ».

Les cas d’usage sont réels. La demande est réelle. La frustration l’est tout autant. Le reste de cet article sert à naviguer dans cet écart.

Qu’est-ce qu’un dépôt Facebook Scraper sur GitHub, exactement ?

Un « Facebook scraper » sur GitHub est un script open source — généralement en Python — qui extrait par programme des données publiques depuis des pages, publications, groupes, Marketplace ou profils Facebook. Ils ne fonctionnent pas tous de la même façon. Trois architectures dominent :

Scrapers basés sur l’automatisation du navigateur, wrappers d’API et scrapers HTTP directs

est l’exemple classique du HTTP direct : il scrappe des pages publiques « sans clé API » à l’aide de requêtes directes et d’un parsing. est un exemple d’automatisation navigateur. représente l’ancienne époque de la Graph API, quand des scripts pouvaient récupérer des publications de pages/groupes via des points de terminaison officiels qui ne sont plus largement disponibles.

Les données ciblées dans ces dépôts incluent généralement le texte des publications, les horodatages, les nombres de réactions/commentaires, les URL d’images, les métadonnées de page (catégorie, téléphone, email, nombre d’abonnés), les champs des annonces Marketplace et les métadonnées des groupes ou des événements.

En 2026, le vrai arbitrage n’est pas la préférence de langage. C’est le type d’échec que vous êtes prêt à tolérer.

Audit de fraîcheur 2026 des Facebook Scraper sur GitHub : quels dépôts fonctionnent vraiment ?

J’ai audité les dépôts Facebook scraper les plus étoilés et les plus recommandés sur GitHub à partir de données réelles de 2026 — pas des promesses du README, mais des dates de commit, des files d’incidents et des retours de la communauté. C’est la section la plus importante.

Tableau complet de l’audit de fraîcheur

Quelques points sautent aux yeux :

• Même le « fork actif » (moda20) n’a pas été mis à jour depuis juin 2024.
• Les files d’incidents racontent l’histoire réelle bien plus vite que les READMEs.
• kevinzg et moda20 déclarent encore Python ^3.6 dans leurs fichiers — un signal clair que la base de dépendances n’a pas été modernisée.

kevinzg/facebook-scraper

Le scraper Facebook Python le plus connu sur GitHub. Son décrit le scraping de pages, le scraping de groupes, la connexion via identifiants ou cookies, ainsi que des champs au niveau des publications comme comments, image, images, likes, post_id, post_text, text et time.

Mais le signal opérationnel est faible :

• Dernière mise à jour : 22 juin 2024
• Incidents ouverts : — dont des titres comme « Example Scrape does not return any posts »
• Le mainteneur n’a pas répondu aux incidents récents

Verdict : Partiellement cassé. Encore utile pour de petits tests sur des pages publiques et comme référence de noms de champs, mais peu fiable pour un usage en production.

moda20/facebook-scraper (fork communautaire)

Le fork le plus visible de kevinzg, avec des options supplémentaires et des aides orientées Marketplace comme extract_listing (documentées dans son ).

La rend la casse très explicite :

• « mbasic is gone »
• « CLI 'Couldn't get any posts.' »
• « https://mbasic.facebook.com is no longer working »

Quand l’interface simplifiée mbasic change ou disparaît, toute une classe de scrapers se dégrade d’un coup.

Verdict : Le fork le plus notable, mais aussi obsolète et fragile en 2026. C’est celui qu’il faut essayer en premier si vous tenez absolument à une solution basée sur GitHub, mais n’attendez pas de stabilité.

minimaxir/facebook-page-post-scraper

Autrefois un outil Graph API très pratique pour récupérer des publications, réactions, commentaires et métadonnées de Pages publiques et de Groupes ouverts dans des CSV. Son explique encore comment utiliser l’App ID et l’App Secret d’une application Facebook.

En 2026, c’est un artefact historique :

• Dernière mise à jour : 23 mai 2019
• Incidents ouverts : 53 — dont « HTTP 400 Error Bad Request » et « No data retrieved!! »

Verdict : Abandonné. Fortement lié à un modèle d’autorisations API que Meta a depuis considérablement restreint.

Autres dépôts notables

• passivebot/facebook-marketplace-scraper : utile pour des cas d’usage Marketplace, mais sa contient notamment « login to view the content », « CSS selectors outdated » et « Getting blocked ». Un cas d’école en une ligne de ce qui casse sur Marketplace.
• apurvmishra99/facebook-scraper-selenium : contient un incident demandant littéralement datant de septembre 2020. Cela dit presque tout.
• Mhmd-Hisham/selenium_facebook_scraper et anabastos/faceteer : aucune activité récente suffisante pour inspirer confiance.

Les défenses anti-scraping de Facebook : à quoi se heurte chaque scraper GitHub

La plupart des articles sur le sujet se contentent d’un vague avertissement « vérifiez les CGU ». Ce n’est pas utile.

Facebook dispose de l’un des systèmes anti-scraping les plus agressifs parmi les grandes plateformes. Comprendre les couches de défense précises, c’est la différence entre un scraper qui fonctionne et un après-midi à produire du vide.

Le propre décrit une « Anti Scraping team » qui utilise l’analyse statique sur l’ensemble du codebase pour identifier les vecteurs de scraping, envoie des mises en demeure, désactive des comptes et s’appuie sur des systèmes de limitation de débit. Ce n’est pas hypothétique — c’est un engagement organisationnel.

DOM et noms de classes CSS aléatoires

Facebook randomise délibérément les identifiants HTML, les noms de classes et la structure des pages. Comme l’a formulé un : « Aucun scraper normal ne peut fonctionner sur Facebook. Le HTML mute entre deux actualisations. »

Ce qui casse : les sélecteurs XPath et CSS qui fonctionnaient la semaine dernière ne renvoient plus rien aujourd’hui.

Contre-mesure : utiliser, quand c’est possible, des sélecteurs basés sur le texte ou sur les attributs. Le parsing fondé sur l’IA, qui lit le contenu de la page plutôt que de dépendre de sélecteurs rigides, s’en sort mieux. Attendez-vous à devoir maintenir vos sélecteurs régulièrement.

Murs de connexion et gestion de session

De nombreuses surfaces Facebook — profils, groupes, certaines annonces Marketplace — nécessitent une connexion pour être consultées. Les navigateurs headless sont redirigés ou reçoivent du HTML simplifié. L’onglet cite « login to view the content » parmi les plaintes principales.

Ce qui casse : les requêtes anonymes perdent du contenu ou sont entièrement redirigées.

Contre-mesure : utiliser des cookies de session issus d’une vraie session navigateur, ou des outils de scraping basés sur le navigateur qui opèrent dans votre session connectée. La rotation de comptes est possible, mais risquée.

Empreinte numérique

Le billet d’ingénierie de Meta explique que les scrapers non autorisés — ce qui revient à dire que la qualité du navigateur et celle du comportement sont centrales dans la détection. Les discussions communautaires de et continuent de recommander des navigateurs anti-détection et des empreintes cohérentes.

Ce qui casse : les configurations Selenium ou Puppeteer standard sont facilement identifiées.

Contre-mesure : utiliser des outils comme undetected-chromedriver ou des profils de navigateur anti-détection. Des sessions réalistes et des empreintes cohérentes comptent davantage qu’un simple spoofing du user-agent.

Limitation de débit et blocage par adresse IP

Le billet d’ingénierie de Meta parle explicitement de la limitation de débit comme partie de la stratégie de défense, y compris le plafonnement du nombre d’abonnés pour forcer davantage de requêtes qui finissent par . En pratique, des utilisateurs rapportent être limités après des publications dans .

Ce qui casse : les requêtes en volume depuis la même IP sont ralenties ou bloquées en quelques minutes. Les IP de proxy datacenter sont souvent bloquées d’avance.

Contre-mesure : rotation de proxies résidentiels (pas de proxies datacenter), avec un rythme de requêtes raisonnable.

Changements de schéma GraphQL

Certains scrapers s’appuient sur les points de terminaison GraphQL internes de Facebook parce qu’ils renvoient des données structurées plus propres que le HTML brut. Mais Meta ne publie aucune garantie de stabilité pour son GraphQL interne ; ces requêtes cassent donc silencieusement — elles renvoient des données vides au lieu d’erreurs.

Ce qui casse : l’extraction structurée renvoie silencieusement rien.

Contre-mesure : ajouter des vérifications de validation, surveiller les points de terminaison du schéma et figer les requêtes connues comme fonctionnelles. Attendez-vous à de la maintenance.

Résumé des défenses anti-scraping

Quand les dépôts GitHub échouent : l’échappatoire no-code

Une grande partie des personnes qui cherchent « facebook scraper github » ne sont pas développeuses ou développeurs. Ce sont des commerciaux à la recherche d’emails de pages d’entreprise, des opérateurs e-commerce qui suivent les prix sur Marketplace ou des marketeurs qui font de la veille concurrentielle. Ils n’ont pas envie de gérer un environnement Python, de déboguer des sélecteurs cassés ou de faire tourner des proxies.

Si cela vous ressemble, l’arbre de décision est court :

Extraire les coordonnées d’une page Facebook (emails, numéros de téléphone)

Si le but est de récupérer des emails et des numéros de téléphone depuis les sections « À propos » des Pages, un dépôt GitHub est largement surdimensionné. L’ et l’ gratuits de analysent une page web et exportent les résultats vers Sheets, Excel, Airtable ou Notion. L’IA relit la page à chaque fois, donc les changements de DOM Facebook ne cassent pas l’outil.

Extraire des données structurées depuis Marketplace ou des pages d’entreprise

Pour extraire des annonces, des prix, des emplacements ou des informations d’entreprise, l’Extracteur Web IA de Thunderbit vous permet de cliquer sur « AI Suggest Fields » — l’IA lit la page et propose des colonnes comme le prix, le titre, la localisation — puis de cliquer sur « Scrape ». Pas de maintenance XPath, pas d’installation de code. Export direct vers .

Suivi programmé (alertes de prix Marketplace, veille concurrentielle)

Pour une surveillance continue — « alertez-moi lorsqu’une annonce Marketplace correspond à ma fourchette de prix » — le de Thunderbit vous permet de décrire l’intervalle en langage courant (par exemple ) et de définir des URL. L’exécution est automatique, sans cron job.

Quand les dépôts GitHub restent le bon choix

Si vous avez besoin d’un contrôle programmatique poussé, d’extractions à grande échelle ou de pipelines de données sur mesure, les dépôts GitHub (ou pour l’extraction structurée) sont les bons outils. La décision est simple : utilisateurs métier avec des besoins d’extraction simples → no-code d’abord ; développeurs construisant des pipelines de données → dépôts GitHub ou API.

Exemples de sortie réels : ce que vous obtenez vraiment

Tous les articles concurrents montrent des extraits de code, mais jamais les sorties réelles. Voici ce que vous pouvez raisonnablement attendre de chaque approche.

Exemple de sortie : kevinzg/facebook-scraper (ou fork actif)

À partir de l’, une publication publique extraite renvoie un JSON comme celui-ci :

1{
2  "comments": 459,
3  "comments_full": null,
4  "image": "https://...",
5  "images": ["https://..."],
6  "likes": 3509,
7  "post_id": "2257188721032235",
8  "post_text": "Ne laissez pas cette version miniature...",
9  "text": "Ne laissez pas cette version miniature...",
10  "time": "2019-04-30T05:00:01"
11}

Remarquez les champs pouvant être nuls, comme comments_full. En 2026, attendez-vous à ce que davantage de champs reviennent vides ou manquants — c’est généralement un signal de blocage, pas un simple bug bénin. La sortie est du JSON brut et nécessite un post-traitement.

Exemple de sortie : Facebook Graph API

La actuelle de Meta documente des requêtes d’informations de page comme GET /<PAGE_ID>?fields=id,name,about,fan_count. La inclut des champs comme followers_count, fan_count, category, emails, phone et d’autres métadonnées publiques — mais seulement avec les bonnes autorisations, comme .

C’est une structure de données bien plus limitée que ce à quoi s’attendent la plupart des utilisateurs de scrapers GitHub. Elle est centrée sur les pages, dépendante des permissions, et ne remplace pas un scraping arbitraire de publications publiques ou de groupes.

Exemple de sortie : Extracteur Web IA de Thunderbit

Les colonnes suggérées par l’IA de Thunderbit pour une page Facebook d’entreprise produisent un tableau propre et structuré :

Pour les publications et les commentaires, la sortie ressemble à ceci :

Colonnes structurées, numéros de téléphone formatés, données prêtes à l’emploi — aucune étape de post-traitement. Le contraste avec le JSON brut des outils GitHub est difficile à manquer.

Matrice Type de données Facebook × meilleur outil

Aucun outil unique ne gère tout correctement sur Facebook en 2026.

Cette matrice vous permet d’aller directement à votre cas d’usage au lieu de lire tout l’article en espérant tomber sur la bonne réponse.

Quelle approche convient à votre équipe ?

• Équipes commerciales qui extraient des leads : commencez par l’Extracteur d’email / de téléphone de Thunderbit ou par l’Extracteur IA. Pas de configuration, résultats immédiats.
• Équipes e-commerce qui surveillent Marketplace : utilisez l’Extracteur Programmé de Thunderbit ou une configuration personnalisée Scrapy + proxies résidentiels si vous avez les ressources d’ingénierie.
• Développeurs qui construisent des pipelines de données : dépôts GitHub (forks actifs) + proxies résidentiels + budget de maintenance. Attendez-vous à un travail continu.
• Chercheurs qui archivent du contenu de groupes : workflow basé sur le navigateur uniquement (Thunderbit ou Selenium avec connexion), avec revue de conformité.

La position honnête — et celle vers laquelle — est qu’il n’existe pas de solution unique et fiable. Faites correspondre votre besoin précis au bon outil.

Étape par étape : comment mettre en place un Facebook Scraper depuis GitHub (quand cela a du sens)

Si vous avez lu l’audit de fraîcheur et souhaitez quand même passer par GitHub, pourquoi pas. Voici le chemin pratique — avec des notes honnêtes sur ce qui casse.

ÉTAPE 1 : Choisir le bon dépôt (utilisez l’audit de fraîcheur)

Revenez au tableau d’audit. Choisissez le dépôt le moins obsolète qui correspond à la surface que vous ciblez. Avant d’installer quoi que ce soit, consultez l’onglet Issues — les titres récents des incidents vous en disent plus sur les fonctionnalités actuelles que le README.

ÉTAPE 2 : Configurer votre environnement Python

1python3 -m venv fb-scraper-env
2source fb-scraper-env/bin/activate
3pip install -r requirements.txt

Piège courant : les conflits de version avec les dépendances, surtout Selenium/Playwright. kevinzg et moda20 déclarent tous deux Python ^3.6 dans leur — une base ancienne qui peut entrer en conflit avec des bibliothèques plus récentes. Le scraper Marketplace de passivebot verrouille , ce qui est suffisant pour expérimenter, mais ne prouve en rien la durabilité.

ÉTAPE 3 : Configurer les proxys et l’anti-détection

Si vous faites autre chose qu’un test rapide :

• Mettez en place une rotation de proxies résidentiels (cherchez des fournisseurs avec des pools IP spécifiques à Facebook)
• Si vous utilisez l’automatisation navigateur, installez undetected-chromedriver ou configurez l’anti-fingerprinting
• Ne sautez pas cette étape — Selenium ou Puppeteer standards sont vite repérés

ÉTAPE 4 : Lancer un petit test de scraping et valider la sortie

Commencez par une seule page publique, pas par un gros lot. Vérifiez soigneusement les résultats :

• Des champs vides ou des données manquantes signifient généralement que les défenses de Facebook vous bloquent
• Comparez les résultats à ce que vous voyez réellement sur la page dans votre navigateur
• Un test réussi sur une seule page compte plus qu’un beau README

ÉTAPE 5 : Gérer les erreurs, les limites de débit et la maintenance

• Ajoutez une logique de retry et une gestion d’erreurs
• Attendez-vous à devoir mettre à jour régulièrement les sélecteurs ou les configurations — c’est de la maintenance continue, pas du « configurez et oubliez »
• Si vous passez plus de temps à maintenir le scraper qu’à utiliser les données, c’est un signal qu’il faut reconsidérer la voie no-code

Considérations juridiques et éthiques du scraping Facebook

Cette section est brève et factuelle. Ce n’est pas le cœur de l’article, mais l’ignorer serait irresponsable.

Les de Facebook indiquent que les utilisateurs « ne peuvent pas accéder à nos Produits ni collecter leurs données à l’aide de moyens automatisés (sans notre autorisation préalable) ». Les de Meta, mises à jour le 3 février 2026, précisent que l’application des règles peut inclure la suspension, la suppression de l’accès API et des mesures au niveau du compte.

Ce n’est pas théorique. Le décrit l’investigation active du scraping non autorisé, l’envoi de mises en demeure et la désactivation de comptes. Meta a aussi contre des sociétés de scraping (par exemple l’affaire Voyager Labs).

Le cadrage le plus sûr :

• Les conditions de Meta sont explicitement anti-scraping
• L’utilisation d’API autorisées est plus sûre qu’un scraping non autorisé
• La disponibilité publique n’efface pas les obligations liées aux lois sur la vie privée (RGPD, CCPA, etc.)
• Si vous travaillez à grande échelle, consultez un conseil juridique
• Thunderbit est conçu pour le scraping de données publiquement disponibles et ne contourne pas les exigences de connexion lors du scraping cloud

Points clés à retenir : ce qui fonctionne vraiment pour le scraping Facebook en 2026

La plupart des dépôts GitHub de Facebook scraper sont cassés ou peu fiables en 2026. Ce n’est pas un effet d’annonce — c’est ce que montrent de façon cohérente les dates de commit, les files d’incidents et les retours de la communauté.

Les quelques forks actifs fonctionnent encore pour des données publiques limitées sur les pages, mais ils exigent une maintenance continue, une configuration anti-détection et l’acceptation réaliste qu’ils recasseront encore. La Graph API est utile, mais limitée — elle couvre les métadonnées au niveau des pages avec les bonnes permissions, pas l’extraction large de publications publiques ou de groupes que la plupart des gens recherchent.

Pour les utilisateurs métier qui ont besoin de données Facebook sans la charge de travail d’un développeur, les outils no-code comme offrent une voie plus fiable et plus simple à maintenir. L’IA relit la page à chaque fois, donc les changements de DOM ne cassent pas votre workflow. Vous pouvez essayer gratuitement et exporter vers Sheets, Excel, Airtable ou Notion.

La recommandation pratique : commencez par le tableau d’audit de fraîcheur. Si vous n’êtes pas développeur, essayez d’abord l’option no-code. Si vous êtes développeur, n’investissez dans une configuration GitHub que si vous avez les ressources techniques — et la patience — pour la maintenir. Et quelle que soit la voie choisie, adaptez votre besoin de données à l’outil approprié au lieu d’espérer une solution unique qui ferait tout.

Si vous voulez aller plus loin sur le scraping de données de réseaux sociaux et les outils associés, nous avons des guides sur , et . Vous pouvez aussi regarder des tutoriels sur la .

FAQ

Existe-t-il en 2026 un Facebook scraper qui fonctionne sur GitHub ?

Oui, mais les options sont limitées. Le plus notable est le fork du dépôt original de kevinzg — consultez le tableau d’audit de fraîcheur ci-dessus pour l’état actuel. Il peut encore extraire partiellement des publications publiques de pages et certaines métadonnées, mais sa file d’incidents montre des cassures de base autour de mbasic et des sorties vides. La plupart des autres dépôts sont abandonnés ou complètement cassés.

Puis-je scraper Facebook sans coder ?

Oui. Des outils comme et les extracteurs gratuits d’emails / de téléphones vous permettent d’extraire des données Facebook depuis votre navigateur en quelques clics, sans configuration Python ni GitHub. L’IA lit la page à chaque fois, donc vous n’avez pas à maintenir les sélecteurs lorsque Facebook change sa mise en page.

Est-il légal de scraper Facebook ?

Les de Facebook interdisent la collecte automatisée de données sans autorisation. Meta fait appliquer cette règle de manière active via des bannissements de compte, des mises en demeure et des . La légalité varie selon la juridiction et le cas d’usage. Concentrez-vous sur les données commerciales publiquement disponibles, évitez les profils personnels et consultez un conseil juridique si vous opérez à grande échelle.

Quelles données puis-je encore obtenir via la Facebook Graph API ?

En 2026, la est fortement restreinte. Vous pouvez accéder à des données limitées au niveau des pages — des champs comme id, name, about, fan_count, emails, phone — avec les permissions appropriées, comme . La plupart des données de publications publiques, des données de groupes (la ) et des données au niveau utilisateur ne sont plus accessibles via l’API.

À quelle fréquence les dépôts GitHub de Facebook scraper cassent-ils ?

Très souvent. Facebook modifie en continu sa structure DOM, ses mesures anti-bot et ses API internes — il n’existe pas de cadence publiée, mais les retours de la communauté montrent des cassures toutes les quelques semaines pour les scrapers actifs. La file d’incidents du fork moda20 autour de la disparition de mbasic en est un exemple récent. Si vous dépendez d’un dépôt GitHub, prévoyez un budget de maintenance régulière et de validation des sorties.

En savoir plus