Une recherche GitHub pour "facebook scraper" renvoie 475 dépôts. Seuls 62 d’entre eux ont été mis à jour au cours des six derniers mois.
Cet écart entre "disponible" et "vraiment fonctionnel" résume à lui seul l’état du scraping Facebook sur GitHub en 2026.
J’ai passé beaucoup de temps à éplucher les onglets d’issues 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, les mainteneurs ont tourné la page et les défenses anti-scraping de Facebook deviennent de plus en plus solides. Développeurs comme équipes 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 vide. Cet article propose un état des lieux 2026 — un audit honnête des dépôts qui méritent encore votre attention, de ce que Facebook met en place pour les faire échouer, et des cas 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 n’ont pas changé depuis des années — même si les outils, eux, se cassent régulièrement :
- Génération de leads : extraire les coordonnées des pages d’entreprise (emails, numéros de téléphone, adresses) pour la prospection
- Veille Marketplace : suivre les annonces, les prix et les informations vendeur pour l’e-commerce ou l’arbitrage
- Recherche dans les groupes : archiver les publications et commentaires pour des études de marché, l’OSINT ou la gestion de communauté
- Archivage de contenu et de publications : sauvegarder les posts publics, réactions, images et horodatages
- Agrégation d’événements : récupérer les titres, dates, lieux et organisateurs d’événements
L’attrait de GitHub est évident : code visible, gratuité, 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 reflètent pas le fait qu’un projet fonctionne encore aujourd’hui. Parmi les 10 dépôts correspondant exactement à l’expression et ayant le plus d’étoiles, les 10 étaient obsolètes depuis plus de 12 mois en avril 2026. Ce n’est pas une exception, c’est la règle.
Dans un fil Reddit de novembre 2025, un utilisateur 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 une discussion d’avril 2026, a résumé la situation 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 justement à naviguer dans cet espace entre les deux.
Qu’est-ce qu’un dépôt GitHub de Facebook Scraper, exactement ?
Un "Facebook scraper" sur GitHub est un script open source — généralement en Python — qui extrait de manière programmatique des données publiques depuis des pages, publications, groupes, Marketplace ou profils Facebook. Tous ne fonctionnent pas de la même manière. Trois architectures dominent :
Scrapers basés sur l’automatisation du navigateur, wrappers d’API et scrapers HTTP directs
| Approche | Stack typique | Forces | Faiblesses |
|---|---|---|---|
| Automatisation navigateur | Selenium, Playwright, Puppeteer | Gère les barrières de connexion, imite le comportement d’un vrai utilisateur | Lent, gourmand en ressources, facilement identifiable si mal configuré |
| Wrapper d’API officielle | Meta Graph API / Pages API | Stable, documenté, conforme lorsqu’il est approuvé | Très limité — la plupart des données publiques de posts/groupes ne sont plus accessibles |
| Scraper HTTP direct | requests, parsing HTML, endpoints non documentés | Rapide et léger quand ça marche | Casse dès que Facebook change sa structure ou ses mesures anti-bot |
kevinzg/facebook-scraper est l’exemple classique du scraping HTTP direct : il extrait des pages publiques "sans clé API" via des requêtes directes et du parsing. apurvmishra99/facebook-scraper-selenium illustre l’approche automatisée via navigateur. minimaxir/facebook-page-post-scraper représente l’ère Graph API d’avant, où des scripts pouvaient récupérer des posts de pages/groupes via des endpoints officiels aujourd’hui largement indisponibles.
Les données visées par ces dépôts incluent généralement le texte des publications, les horodatages, le nombre de réactions/commentaires, les URLs d’images, les métadonnées de page (catégorie, téléphone, email, nombre d’abonnés), les champs des annonces Marketplace, ainsi que les métadonnées de groupes ou d’événements.
En 2026, le vrai arbitrage n’est pas le langage utilisé. C’est le type d’échec que vous êtes prêt à accepter.
Audit de fraîcheur 2026 des Facebook Scraper GitHub : quels dépôts fonctionnent vraiment ?
J’ai audité les dépôts Facebook scraper les plus étoilés et les plus souvent recommandés sur GitHub en les confrontant à des données réelles de 2026 — pas à leurs promesses dans le README, mais à leurs dates de commit, à leurs files d’issues et aux retours de la communauté. C’est la section la plus importante.
Tableau complet de l’audit de fraîcheur
| Dépôt | Étoiles | Dernier push | Issues ouvertes | Langage / runtime | Ce qu’il scrape encore | Statut |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3,157 | 2024-06-22 | 438 | Python ^3.6 | Publications de pages publiques limitées, certains commentaires/images, métadonnées de page | ⚠️ Partiellement cassé / obsolète |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | Idem kevinzg + helpers pour Marketplace | ⚠️ Fork partiellement cassé / obsolète |
| minimaxir/facebook-page-post-scraper | 2,128 | 2019-05-23 | 53 | Ère Python 2/3, dépendant du Graph API | Référence historique uniquement | ❌ Abandonné |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | Scraping de pages via navigateur | ❌ Abandonné |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | Annonces Marketplace via automatisation navigateur | ⚠️ Fragile / très spécifique |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | Scraping Selenium généraliste | ❌ Abandonné |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | Orienté automatisation | ❌ Risqué / peu de preuves |
Quelques points sautent aux yeux :
- Même le "fork actif" (moda20) n’a pas été poussé depuis juin 2024.
- Les files d’issues racontent la vraie histoire bien plus vite que les READMEs.
- kevinzg et moda20 déclarent tous deux encore Python ^3.6 dans leurs fichiers pyproject.toml — un signe 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 README décrit le scraping de pages, de groupes, la connexion via identifiants ou cookies, ainsi que des champs de niveau publication comme comments, image, images, likes, post_id, post_text, text et time.
Mais les signaux d’exploitation sont faibles :
- Dernier push : 22 juin 2024
- Issues ouvertes : 438 — dont des titres comme "Example Scrape does not return any posts"
- Le mainteneur n’a pas répondu aux issues récentes
Verdict : Partiellement cassé. Encore utile pour des tests ponctuels sur des pages publiques à faible volume et comme référence des noms de champs, mais pas fiable en production.
moda20/facebook-scraper (fork communautaire)
Le fork le plus visible de kevinzg, avec des options supplémentaires et des helpers orientés Marketplace comme extract_listing (documenté dans son README).
La file d’issues 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 famille de scrapers se retrouve dégradée d’un coup.
Verdict : Le fork le plus notable, mais aussi obsolète et fragile en 2026. À essayer en premier si vous tenez absolument à une solution basée sur GitHub, mais n’attendez pas de stabilité.
minimaxir/facebook-page-post-scraper
À l’époque, c’était 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 README explique encore comment utiliser l’App ID et l’App Secret d’une application Facebook.
En 2026, c’est un artefact historique :
- Dernier push : 23 mai 2019
- Issues ouvertes : 53 — dont "HTTP 400 Error Bad Request" et "No data retrieved!!"
Verdict : Abandonné. Fortement couplé à 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 file d’issues contient "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 : comporte une issue qui demande littéralement "Does it work with new Facebook layout?" depuis septembre 2020. Cela dit presque tout.
- Mhmd-Hisham/selenium_facebook_scraper et anabastos/faceteer : aucune des deux bases n’a une activité actuelle suffisante pour inspirer confiance.
Les défenses anti-scraping de Facebook : ce contre quoi chaque scraper GitHub doit lutter
La plupart des articles sur le sujet se contentent de vagues avertissements sur les CGU. Ce n’est pas utile.
Facebook dispose de l’un des systèmes anti-scraping les plus agressifs de toutes les grandes plateformes. Comprendre ces couches de défense spécifiques fait toute la différence entre un scraper qui marche et un après-midi de sorties vides.
Le post technique de Meta de février 2025 décrit une équipe "Anti Scraping" qui utilise l’analyse statique sur l’ensemble de la base de code pour détecter 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 théorique : c’est une politique assumée.
DOM et noms de classes CSS randomisés
Facebook randomise délibérément les identifiants HTML, les noms de classes et la structure des pages. Comme l’a dit un commentateur sur r/webscraping : "Aucun scraper normal ne peut fonctionner sur Facebook. Le HTML change entre deux rafraîchissements."
Ce qui casse : les sélecteurs XPath et CSS qui fonctionnaient la semaine dernière ne renvoient plus rien aujourd’hui.
Contre-mesure : privilégier, quand c’est possible, des sélecteurs fondés sur le texte ou les attributs. Le parsing assisté par IA, qui lit le contenu de la page plutôt que de dépendre de sélecteurs rigides, gère mieux ce type de situation. Il faut prévoir la maintenance des sélecteurs comme un coût récurrent.
Mur de connexion et gestion de session
De nombreuses surfaces Facebook — profils, groupes, certaines annonces Marketplace — exigent une connexion pour être consultées. Les navigateurs headless sont redirigés ou reçoivent du HTML appauvri. L’onglet issues du scraper Marketplace de passivebot contient "login to view the content" parmi les plaintes majeures.
Ce qui casse : les requêtes anonymes ne voient pas le contenu ou sont totalement redirigées.
Contre-mesure : utiliser des cookies de session issus d’un vrai navigateur, ou des outils de scraping navigateur qui fonctionnent dans votre session connectée. Le changement de compte est possible, mais risqué.
Empreinte numérique
Le post technique de Meta indique que les scrapers non autorisés "se cachent souvent en imitant la façon dont les utilisateurs utilisent normalement un produit" — ce qui revient à dire que la qualité du navigateur et du comportement est au cœur de la détection. Les discussions communautaires de mars et avril 2026 continuent de recommander des navigateurs anti-detect 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-detect. Des sessions réalistes et des empreintes cohérentes comptent plus qu’un simple spoofing du user-agent.
Limitation de débit et blocage par IP
Le post technique de Meta évoque explicitement la limitation de débit comme partie de sa stratégie de défense, y compris la limitation du nombre d’abonnés affichés pour forcer davantage de requêtes qui déclenchent ensuite les contrôles de débit. En pratique, des utilisateurs signalent des limitations après avoir posté dans 10 groupes à 10 secondes d’intervalle.
Ce qui casse : les requêtes en masse depuis une même IP sont ralenties ou bloquées en quelques minutes. Les IP de proxy datacenter sont souvent déjà bloquées.
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 endpoints GraphQL internes de Facebook, car ils renvoient des données structurées plus propres que du HTML brut. Mais Meta ne publie aucune garantie de stabilité pour ce GraphQL interne, si bien que ces requêtes cassent silencieusement — elles renvoient des données vides plutôt qu’une erreur.
Ce qui casse : l’extraction structurée renvoie soudainement zéro résultat.
Contre-mesure : ajouter des contrôles de validation, surveiller les endpoints de schéma et verrouiller les requêtes connues comme fonctionnelles. Il faut prévoir de la maintenance.
Résumé des défenses anti-scraping
| Couche de défense | Impact sur votre scraper | Contre-mesure pratique | |---|---|---|---| | Churn de mise en page / sélecteurs instables | Les sélecteurs XPath et CSS ne renvoient rien ou seulement une partie des champs | Préférer des ancres robustes, valider par rapport au rendu visible, prévoir de la maintenance | | Barrières de connexion | Les requêtes déconnectées ratent du contenu ou sont redirigées | Utiliser des cookies de session valides ou des outils basés sur une session navigateur | | Fingerprinting | L’automatisation standard semble synthétique | Utiliser de vrais navigateurs, une qualité de session cohérente, des mesures anti-detect | | Limitation de débit | Sortie vide, blocages, throttling | Rythme plus lent, lots plus petits, rotation de proxies résidentiels | | Changements de requêtes internes | L’extraction structurée renvoie silencieusement des données vides | Ajouter des contrôles de validation, s’attendre à maintenir les requêtes |
Quand les dépôts GitHub échouent : choisissez une alternative autorisée
Un dépôt cassé n’est pas une raison pour contourner les protections d’une plateforme. Commencez plutôt par clarifier la question métier : avez-vous besoin d’analyses au niveau des pages, de transparence publicitaire, d’un annuaire de contacts publics ou d’un catalogue produit ? Beaucoup de ces besoins peuvent être couverts par un produit officiel Meta, une API autorisée ou une source publique hors Meta.
Par exemple, utilisez le Graph API uniquement lorsque l’application et le cas d’usage disposent des autorisations requises, utilisez les programmes de recherche Meta uniquement si vous êtes éligible, et utilisez Meta Ad Library pour les informations publicitaires qu’elle expose. Pour la prospection, les prix et la découverte d’entreprises locales, privilégiez des sites publics indépendants dont vous pouvez évaluer directement les conditions d’utilisation et les obligations de confidentialité.
Exemples de sortie réels : ce que vous obtenez vraiment
Tous les articles concurrents montrent du code, mais jamais la sortie réelle. Voici ce à quoi vous pouvez raisonnablement vous attendre selon l’approche.
Exemple de sortie : kevinzg/facebook-scraper (ou fork actif)
À partir de l’exemple du README, une publication publique extraite renvoie un JSON de ce type :
{
"comments": 459,
"comments_full": null,
"image": "https://...",
"images": ["https://..."],
"likes": 3509,
"post_id": "2257188721032235",
"post_text": "Ne laissez pas cette version miniature...",
"text": "Ne laissez pas cette version miniature...",
"time": "2019-04-30T05:00:01"
}
Remarquez les champs pouvant être nuls, comme comments_full. En 2026, attendez-vous à voir davantage de champs vides ou absents — c’est souvent un signal de blocage, pas une simple anomalie. La sortie est du JSON brut et nécessite un traitement après coup.
Exemple de sortie : Facebook Graph API
La Pages API actuelle de Meta documente des requêtes d’informations sur une page comme GET /<PAGE_ID>?fields=id,name,about,fan_count. La référence Page inclut des champs tels que followers_count, fan_count, category, emails, phone et d’autres métadonnées publiques — mais uniquement avec les bonnes autorisations, comme Page Public Content Access ou Page Public Metadata Access.
C’est un modèle de données bien plus restreint que ce que la plupart des utilisateurs de scrapers GitHub imaginent. Il est centré sur les pages, soumis à permissions, et ne remplace pas le scraping libre de publications publiques ou de groupes.
Matrice des types de données Facebook × voies d’accès
| Type de données Facebook | Point de départ recommandé | Limite principale |
|---|---|---|
| Actifs administrés par votre organisation | Outils officiels Meta de gestion et API approuvées | Les permissions et les champs disponibles varient |
| Observations publicitaires | Meta Ad Library | Utilisez uniquement les champs et filtres exposés |
| Données d’entreprise publiques utiles à la prospection | Répertoire public non-Meta ou site éditeur autorisé | Vérifiez les conditions d’utilisation et les obligations de confidentialité de la source |
| Contenu privé, de groupes fermés, protégé par connexion ou réservé au compte | Ne pas automatiser la collecte | Cherchez plutôt une voie autorisée |
Pas à pas : comment mettre en place un Facebook Scraper depuis GitHub, quand cela a du sens
Si vous avez lu l’audit de fraîcheur et que vous voulez malgré tout partir sur GitHub, soit. Voici la démarche pratique — avec des remarques franches 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 cible. Avant toute installation, regardez l’onglet Issues — les titres des issues récentes en disent plus sur l’état réel du projet que le README.
Étape 2 : configurer votre environnement Python
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
Piège courant : les conflits de versions avec les dépendances, en particulier Selenium/Playwright. kevinzg et moda20 déclarent tous deux Python ^3.6 dans leur pyproject.toml — une base ancienne qui peut entrer en conflit avec des bibliothèques plus récentes. Le scraper Marketplace de passivebot verrouille playwright==1.40.0, ce qui est correct pour tester, mais ne prouve rien sur la durabilité.
Étape 3 : configurer les proxies 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 disposant de pools d’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 et valider la sortie
Commencez avec une seule page publique, pas un gros lot. Vérifiez la sortie avec soin :
- Des champs vides ou des données manquantes signifient généralement que les défenses de Facebook vous bloquent
- Comparez la sortie à ce que vous voyez réellement sur la page dans votre navigateur
- Un test réussi sur une seule page vaut plus qu’un beau README
Étape 5 : gérer les erreurs, les limites de débit et la maintenance
- Intégrez de la logique de retry et de gestion d’erreurs
- Attendez-vous à mettre à jour régulièrement les sélecteurs ou la configuration — c’est de la maintenance continue, pas du “set and forget”
- Si vous passez plus de temps à maintenir le scraper qu’à exploiter les données, c’est un signal pour reconsidérer l’approche no-code
Considérations juridiques et éthiques liées au scraping Facebook
Les conditions d’utilisation de la plateforme, les règles de confidentialité, les obligations contractuelles et les lois sur la protection des données peuvent toutes s’appliquer. La visibilité publique n’est pas une autorisation générale pour collecter automatiquement des données. Minimisez les données, documentez la finalité et la base légale, et demandez un avis juridique pour les programmes commerciaux ou à grande échelle.
Ne considérez pas une extension de navigateur, une session connectée ou une étiquette “publique” comme une permission d’automatiser la collecte sur les produits Meta.
À retenir : ce qui fonctionne vraiment pour le scraping Facebook en 2026
L’activité d’un dépôt, les files d’issues et les règles actuelles de la plateforme comptent davantage qu’un nombre d’étoiles ou qu’un ancien README. Quand le besoin métier concerne un actif que vous gérez, commencez par les outils officiels Meta et les API approuvées. Pour les études de marché, la prospection et les questions de prix, une source autorisée non-Meta est souvent plus simple à documenter et à gouverner.
FAQ
Existe-t-il un Facebook scraper fonctionnel sur GitHub en 2026 ?
Oui, mais les options sont limitées. Le plus notable est le fork moda20/facebook-scraper du dépôt original de kevinzg — consultez le tableau d’audit de fraîcheur ci-dessus pour son statut actuel. Il peut partiellement extraire des posts de pages publiques et certaines métadonnées, mais sa file d’issues montre des blocages majeurs autour de mbasic et des sorties vides. La plupart des autres dépôts sont abandonnés ou complètement cassés.
Peut-on scraper Facebook sans coder ?
Utilisez les outils de recherche et de gestion de Facebook pour la recherche manuelle. Pour un usage répétable ou programmatique, évaluez l’API officielle et ses permissions, ou réorganisez le workflow autour d’une source autorisée non-Meta. La simplicité du no-code n’annule pas les obligations de plateforme, de confidentialité ou contractuelles.
Est-il légal de scraper Facebook ?
Les Conditions d’utilisation de Facebook interdisent la collecte automatisée de données sans autorisation. Meta fait activement respecter cette règle via des bannissements de comptes, des mises en demeure et des procédures judiciaires. La légalité varie selon la juridiction et le cas d’usage. Tenez-vous-en aux données professionnelles publiques, évitez les profils personnels et consultez un avocat si vous travaillez à grande échelle.
Quelles données puis-je encore obtenir via le Facebook Graph API ?
En 2026, le Graph API est fortement restreint. 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 autorisations appropriées telles que Page Public Metadata Access. La plupart des données de publications publiques, des données de groupes (le Groups API est obsolète) et des données utilisateur ne sont plus disponibles via l’API.
À quelle fréquence les dépôts GitHub de Facebook scraper cassent-ils ?
Très souvent. Facebook modifie en continu la structure de son DOM, ses mécanismes anti-bot et ses API internes — il n’existe pas de cadence officielle, mais les retours de la communauté montrent des ruptures toutes les quelques semaines pour les scrapers actifs. La file d’issues 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 de la maintenance régulière et une validation systématique des résultats.
En savoir plus
