Il y a quelques mois, un développeur sur Stack Overflow a reposé une question en suspens depuis 2012 : "Google Places API Place Details limited to 5 reviews?" Quatorze ans plus tard, avec des centaines de votes positifs, la réponse n’a pas bougé : oui, cinq avis maximum. Rien que cette limite suffit déjà à poser le décor du débat.
Si vous avez déjà eu besoin de données Google Places à grande échelle — listes de prospects, avis de concurrents, analyse du trafic local, audits SEO local — vous êtes sûrement tombé sur le même casse-tête. L’API officielle Google Places est propre, structurée et bien documentée. Mais elle ne renvoie pas tout ce que vous voyez sur une page Google Maps, et la facture peut vite grimper dès qu’on dépasse le niveau gratuit. Le scraping récupère plus de données, se facture autrement, mais il vient aussi avec son lot de galères : CAPTCHA, sélecteurs qui cassent, zones grises juridiques. J’ai passé pas mal de temps à creuser les deux approches — doc de l’API, grilles tarifaires, outils de scraping et arbitrages concrets — et cet article en est le résultat. On va passer en revue les écarts de données champ par champ, les vrais coûts à 10K/100K/1M d’enregistrements, la réalité de l’anti-bot, et une méthode hybride vraiment exploitable. Avec, en bonus, un arbre de décision, parce que personne n’a envie de lire 3 000 mots sans savoir quoi choisir.
Qu’est-ce que l’API Google Places et qu’est-ce qu’elle fournit vraiment ?
L’API Google Places est la solution officielle et structurée de Google pour récupérer des données d’entreprises — nom, adresse, numéro de téléphone, note, avis, photos — depuis sa base. Tu envoies une requête HTTP, tu récupères du JSON formaté. C’est la voie validée par Google.
La version actuelle, Places API « New », repose sur des field masks. Quand tu appelles Place Details, tu indiques précisément les champs que tu veux — displayName, formattedAddress, rating, reviews, photos, etc. — et Google facture selon le niveau le plus élevé parmi les champs demandés. Si tu oublies le field mask, tu obtiens une erreur, pas une réponse par défaut. C’est volontaire : Google veut que tu ne paies que ce que tu utilises, et surtout plus cher pour les données les plus riches.
Les champs disponibles sont répartis par niveaux tarifaires :
| Niveau | Exemples de champs | Ce que tu obtiens |
|---|---|---|
| Essentials | ID du lieu, adresse formatée, localisation, métadonnées de photos | Identité et localisation de base |
| Pro | Nom affiché, statut de l’établissement, URI Google Maps, type principal | Infos business plus riches |
| Enterprise | Note, nombre d’avis, site web, numéros de téléphone, horaires d’ouverture, niveau de prix | Les champs que la plupart des utilisateurs métier cherchent vraiment |
| Enterprise + Atmosphere | Avis, résumé d’avis, résumé génératif, équipements, parking, livraison / à emporter | Les données les plus riches — et les plus chères |
Les endpoints que la plupart des utilisateurs utilisent le plus : Autocomplete (recherche au fil de la frappe), Text Search et Nearby Search (découverte de lieux), Place Details (enrichissement d’un lieu connu) et Place Photos (images).
Voici maintenant les limites importantes :
- Avis : la ressource Place renvoie au maximum 5 avis par lieu, triés par pertinence. C’est tout. Pas 50, pas « tous ». Cinq.
- Photos : limitées à 10 références de photos par lieu dans la ressource Place.
- Affluence / popular times : non disponible comme champ standard de l’API Places. Google confirme l’existence de ces données sur ses surfaces grand public (à partir d’un historique de position agrégé et anonymisé), et son blog Maps explique le fonctionnement — mais la liste des champs ne les inclut pas.
- Section Q&R : non exposée.
- Concurrents dans “People also search for” : non exposés.
- Menu / carte des prix : pas un champ standard.
Qui utilise généralement l’API Google Places ?
- Entreprises de logistique qui valident et géocodent des adresses
- Applications voyage et hôtellerie qui affichent hôtels, restaurants et attractions à proximité
- Plateformes immobilières qui enrichissent les annonces avec des données locales
- Agences SEO local qui contrôlent la cohérence du NAP (nom, adresse, téléphone)
- Équipes commerciales qui montent des listes de prospects à partir d’IDs de lieux et d’infos business de base
Si ton besoin est clairement : « je veux des données de lieux structurées dans une application de production », l’API est le bon point de départ. Si tes mots-clés sont « tous les avis », « popular times » ou « analyse concurrentielle », continue à lire.
Que signifie exactement « scraper » les données Google Places ?
Le web scraping consiste à utiliser un logiciel pour extraire automatiquement des données d’une page web — ici Google Maps ou Google Search — au lieu de passer par une API officielle. Le scraper lit la page comme ton navigateur, puis récupère les éléments structurés : nom de l’entreprise, adresse, texte des avis, notes, histogrammes de fréquentation, Q&R, suggestions concurrentes, galerie photo complète, et tout autre élément affiché à l’écran.
La différence clé : l’API te donne ce que Google accepte d’exposer. Le scraping te donne, en théorie, tout ce qu’un humain peut voir sur la page.
Mais « scraping » ne veut pas dire une seule chose. Il existe trois approches très différentes, et les compromis n’ont rien à voir.
Scripts maison vs API de scraping managée vs outils no-code
| Approche | Fonctionnement | Idéal pour | Principal compromis |
|---|---|---|---|
| Scripts maison (Puppeteer, Playwright, Selenium) | Tu écris et maintiens un script de navigateur headless qui parcourt Google Maps et analyse le DOM | Développeurs qui veulent un contrôle total et une logique sur mesure | Maintenance élevée : les sélecteurs cassent quand Google change l’interface |
| API de scraping managée (Thunderbit API, SerpApi, Outscraper) | Tu envoies une URL ou une requête à une API ; elle gère le rendu, l’anti-bot et l’analyse, puis renvoie des données structurées | Développeurs qui veulent une sortie propre sans maintenir eux-mêmes le scraper | Les prix et la qualité varient selon le fournisseur ; tu dépends d’un tiers |
| Extensions navigateur no-code (Thunderbit Chrome Extension) | Extraction en point-and-click depuis ton navigateur — l’IA propose les champs, tu cliques sur « Scrape », puis tu exportes vers Sheets/Excel | Utilisateurs métier, marketeurs, équipes commerciales qui veulent des données dans un tableur rapidement | Moins flexible pour les pipelines complexes ; dépend de la qualité de l’IA de l’outil |
Version courte : DIY = le plus flexible, mais le plus coûteux à maintenir. API managées = sortie structurée, pas de maintenance. Outils no-code = le plus rapide pour les non-développeurs.
API Google Places vs scraping : comparaison champ par champ
Voici le tableau que j’aurais aimé avoir au début de mes recherches. Tous les champs dont un utilisateur métier ou un développeur peut avoir besoin, côte à côte :
| Champ de données | API Google Places | Web Scraping |
|---|---|---|
| Nom de l’entreprise | ✅ Complet (niveau Pro) | ✅ Complet |
| Adresse / localisation | ✅ Complet (niveau Essentials) | ✅ Complet |
| Numéro de téléphone | ✅ Niveau Enterprise | ✅ Quand il est affiché |
| URL du site web | ✅ Niveau Enterprise | ✅ Quand il est affiché |
| Note moyenne | ✅ Niveau Enterprise | ✅ Complet |
| Nombre d’avis | ✅ Niveau Enterprise | ✅ Complet |
| Avis individuels (texte + note) | ⚠️ 5 avis max | ✅ Tous les avis visibles |
| Popular times / affluence en direct | ❌ Pas un champ standard de l’API | ✅ Extractible (quand affiché) |
| Section Q&R | ❌ Non exposée | ✅ Extractible |
| Métadonnées photo | ✅ 10 références max via l’endpoint Photos | ✅ Galerie complète |
| Menu / carte des prix | ❌ Pas un champ standard | ⚠️ Quand présent sur la page |
| « Les gens recherchent aussi » (concurrents) | ❌ Non exposé | ✅ Extractible |
| Horaires d’ouverture | ✅ Niveau Enterprise | ✅ Quand ils sont visibles |
| Niveau de prix | ✅ Niveau Enterprise | ✅ Quand il est visible |
| ID du lieu | ✅ Très fiable (Essentials) | ⚠️ Possible, mais l’API reste la source de référence |
| URI Google Maps | ✅ Niveau Pro | ✅ C’est l’URL de la page |
| Réponses du propriétaire aux avis | ⚠️ Vérifier la disponibilité actuelle | ✅ Souvent visibles |
| Position SERP / pack local | ❌ Ce n’est pas le but de l’API | ✅ Via scraping SERP |
La principale limite : si tu as besoin de l’ensemble des avis pour une analyse de sentiment, un suivi de réputation ou un benchmark concurrentiel, l’API seule ne suffit pas. Cinq avis par lieu, c’est un échantillon, pas un corpus.
Les popular times et les schémas de fréquentation ? Même problème. Si tu es consultant retail ou analyste immobilier commercial, le scraping est la seule voie — cette donnée n’existe tout simplement pas dans l’API.
À l’inverse, pour des IDs de lieux canoniques, des adresses structurées pour le géocodage ou l’alimentation d’un store locator, l’API est plus propre, plus fiable et officiellement supportée.
Le vrai coût : API Google Places vs scraping à 10K, 100K et 1M d’enregistrements
Le coût est la partie la plus mal comprise de cette décision. Beaucoup d’utilisateurs s’inscrivent au niveau gratuit de l’API, construisent un prototype, puis découvrent une facture salée dès qu’ils montent en volume. Côté scraping, on sous-estime souvent le coût des proxies et le temps développeur.
Voici donc les calculs.
Détail des tarifs de l’API Google Places
Google a revu en profondeur la tarification de Maps Platform en mars 2025, en remplaçant l’ancien crédit mensuel fixe de 200 $ par des plafonds gratuits par SKU et une tarification par volume. La tarification actuelle fonctionne ainsi :
- Champs Essentials (Place Details) : 10 000 requêtes gratuites/mois, puis 5,00 $ par 1 000 jusqu’à 100K
- Champs Pro (Place Details) : 5 000 gratuites, puis 7,00 $ / 1K
- Champs Enterprise (Place Details) : 1 000 gratuites, puis 20,00 $ / 1K
- Enterprise + Atmosphere (avis, équipements) : 1 000 gratuites, puis 25,00 $ / 1K
Point crucial : si ton field mask inclut ne serait-ce qu’un champ Enterprise + Atmosphere (comme reviews), toute la requête est facturée à ce niveau. Et un workflow classique enchaîne souvent plusieurs SKU — Text Search Pro pour découvrir les lieux, puis Place Details Enterprise + Atmosphere pour les enrichir — donc les coûts s’additionnent.
Un simple « lookup » correspond rarement à une seule requête facturable.
Coûts du scraping : outils, proxies et temps développeur
Les coûts du scraping se divisent en trois blocs :
- Abonnement à l’outil ou crédits API : les API de scraping managées facturent par requête, par crédit ou par enregistrement. SerpApi facture par recherche. Outscraper fonctionne en paiement à l’usage par enregistrement. L’API de Thunderbit utilise un système de crédits (Extract = 20 crédits/requête). L’extension Chrome de Thunderbit facture 1 crédit par ligne de sortie.
- Coût des proxies (DIY uniquement) : les proxies résidentiels pour le scraping Google Maps tournent généralement entre 50 $ et 300 $ par mois selon le volume et le fournisseur.
- Temps développeur (DIY uniquement) : création et maintenance de scripts Puppeteer/Playwright. C’est le coût caché qui ruine l’économie du DIY (on y revient juste après).
Tableau comparatif des coûts : API vs scraping à grande échelle
| Échelle | API Google Places (Enterprise + Atmosphere) | API de scraping managée (est.) | Scraping DIY (proxy + temps dev) |
|---|---|---|---|
| 10K enregistrements/mois | ~225 $ (1K gratuit, 9K × 25 $/1K) | ~50–150 $ selon le fournisseur | ~50 $ de proxy + 2 à 4 h de dev/mois |
| 100K enregistrements/mois | ~2 475 $ (après le quota gratuit, tarification par paliers) | ~250–500 $ | ~150 $ de proxy + 8 à 16 h de dev/mois |
| 1M enregistrements/mois | ~17 975 $ (les paliers volume réduisent le coût unitaire, mais le total reste élevé) | ~1 500–3 000 $ | ~300 $ de proxy + 20 h+ de dev/mois + risque de casse |
Notes : les estimations API utilisent les paliers de volume publiés pour Place Details Enterprise + Atmosphere, appliqués après le quota gratuit de 1K. Les estimations des API de scraping managées sont des fourchettes approximatives entre fournisseurs. Le temps dev DIY suppose un coût complet de 50 à 100 $/h.
Le schéma est clair : à petite échelle (moins de 10K), les plafonds gratuits de l’API peuvent en faire l’option la moins chère, surtout si tu n’as besoin que de champs Essentials ou Pro. À l’échelle business (100K+), la facture API grimpe vite, en particulier pour les champs riches. À l’échelle entreprise (1M+), l’API peut frôler les cinq chiffres par mois, et le scraping ou les services de données deviennent économiquement très attractifs — à condition d’avoir vraiment besoin des champs supplémentaires que l’API n’expose pas.
Si tu n’as besoin que d’adresses et d’IDs de lieux, ne scrape pas. L’API est moins chère et mieux adaptée. L’argument économique du scraping ne tient que si tu as besoin de données que l’API ne peut pas renvoyer.
Le point sur l’anti-bot : pourquoi les scrapers Google faits maison cassent
Voici la partie que les défenseurs du scraping passent souvent sous silence. Google ne veut pas que tu scrapes Google Maps. L’entreprise a mis en place plusieurs couches de défense, régulièrement mises à jour.
Les défenses multicouches de Google
- Déclenchement de reCAPTCHA : les navigateurs automatisés déclenchent des CAPTCHA bien plus souvent que les humains
- Rendu JavaScript côté client : Google Maps est une application JavaScript lourde. Une simple requête HTTP ne suffit pas à obtenir le contenu rendu — il faut un navigateur headless complet
- Empreinte navigateur : Google détecte les navigateurs headless via les empreintes canvas, WebGL, les propriétés de navigator et d’autres signaux
- Limitation de débit IP : trop de requêtes depuis la même IP — ou le même sous-réseau de proxy — et tu es bloqué
- Changements de structure DOM : Google modifie régulièrement la structure de ses pages — l’avis général sur Reddit et dans les issues GitHub est que les sélecteurs cassent toutes les quelques semaines à quelques mois
Ce dernier point est le tueur silencieux. Un script Puppeteer qui fonctionnait parfaitement en juin peut renvoyer des résultats vides en juillet, simplement parce que Google a renommé une classe CSS ou réorganisé un div.
Le coût caché de la maintenance des scripts maison
À chaque changement de DOM chez Google, quelqu’un dans ton équipe doit :
- Repérer que le scraper est cassé (idéalement avant que de mauvaises données ne se propagent)
- Examiner la nouvelle structure de la page
- Mettre à jour les sélecteurs, gérer de nouveaux types de CAPTCHA, ajuster la logique de retry
- Tester puis redéployer
Sur un an, ce temps de maintenance dépasse facilement le prix d’un abonnement à une API de scraping managée. J’ai vu des équipes consommer 40 heures développeur ou plus par an juste pour maintenir un scraper Google Maps en vie — et c’est une estimation prudente pour une configuration de complexité modérée.
Pourquoi les API de scraping managées existent
C’est précisément pour absorber cette charge que des services comme Thunderbit API, SerpApi et Outscraper existent. Ils prennent en charge la complexité anti-bot — rendu JS, résolution de CAPTCHA, rotation des proxies, maintenance des sélecteurs — et renvoient des données structurées.
L’endpoint POST /extract de Thunderbit avec renderMode: "full" gère les pages lourdes en JavaScript comme Google Maps et renvoie du JSON structuré, aligné sur le schéma, et non du HTML brut à parser ensuite. Le serveur MCP étend cela aux agents IA — Claude, Cursor ou d’autres workflows fondés sur des LLM peuvent scraper des données Google Maps en plein milieu d’une tâche sans quitter leur environnement.
Pour les utilisateurs non techniques, la Thunderbit Chrome Extension est l’option sans maintenance : ouvre une page Google Maps, clique sur « AI Suggest Fields », clique sur « Scrape », exporte vers Sheets. Pas de sélecteurs, pas de proxies, pas de débogage.
SerpApi et Outscraper sont aussi de bonnes alternatives, avec des modèles de tarification et des formats de sortie différents. SerpApi renvoie du JSON structuré par recherche ; Outscraper facture par enregistrement en paiement à l’usage. Le bon choix dépend de ton volume, de ton budget et de ta préférence entre JSON structuré ou sortie semi-structurée à parser.
Le plan hybride : utiliser ensemble l’API Google Places et le scraping
Aucun des articles les mieux classés sur ce sujet ne propose ce que j’ai vu marcher le mieux en pratique : utiliser les deux. Beaucoup d’équipes finissent par s’appuyer sur l’API officielle pour certaines tâches et sur le scraping pour d’autres. L’astuce consiste à associer le bon outil à la bonne mission.
Quand l’API officielle gagne
- Autocomplete dans une application de production : faible latence, conformité aux conditions d’utilisation, fiabilité SLA. Sans débat.
- Backends d’applications géolocalisées : store locators, validation d’adresses, correspondance d’IDs de lieux. L’API est structurée, supportée et documentée.
- Intégrations sensibles en matière de conformité : contrats entreprise, produits grand public, ou tout contexte où le respect des conditions de Google n’est pas négociable.
Quand le scraping gagne
- Extraction complète d’avis (5K+ avis par lieu) : analyse de sentiment, suivi de réputation, benchmark concurrentiel. La limite de 5 avis de l’API la rend inutilisable ici.
- Extraction ponctuelle de listes de prospects : moins cher pour des traitements batch sans facturation récurrente. Un outil no-code comme Thunderbit peut extraire une liste d’entreprises et l’exporter vers un tableur en quelques minutes.
- Analyse des popular times / trafic piéton : pas disponible via l’API. Point final.
- Données Q&R, “people also search for” concurrents : visibles uniquement sur la page, pas dans l’API.
Quand l’approche hybride a du sens
- Suivi continu des prix / notes : utilise l’API pour les données structurées de base (ID du lieu, adresse, note moyenne), puis le scraping pour les champs profonds que l’API ne couvre pas (avis complets, popular times).
- Workflows d’enrichissement : utilise l’API pour récupérer les Place IDs et les informations canoniques de l’entreprise, puis scrape les pages de chaque fiche pour obtenir l’ensemble des avis, les Q&R et le contexte concurrentiel.
- Surveillance planifiée : le scraper planifié de Thunderbit (pour les utilisateurs no-code) ou un batch CLI déclenché par cron (pour les développeurs) permet de gérer des extractions récurrentes sans infrastructure custom.
Matrice de décision par cas d’usage
| Cas d’usage | Méthode recommandée | Pourquoi |
|---|---|---|
| Autocomplete dans une appli en production | ✅ API officielle | Faible latence, conforme, fiable |
| Récupérer des ensembles complets de 5K+ avis | ✅ Scraping / API de scraping | L’API est plafonnée à 5 avis par lieu |
| Liste de prospects d’entreprises locales, une seule fois | ✅ Scraping (ou extension Thunderbit) | Moins cher pour du batch ; pas de facturation continue |
| Analyse des popular times / trafic piéton | ✅ Scraping uniquement | Pas disponible via l’API |
| Suivi continu des prix / notes | ⚠️ Hybride | API pour le socle, scraping pour les champs avancés |
| Backend d’application géolocalisée | ✅ API officielle | Structurée, supportée, SLA |
| Suivi de position SERP pour SEO local | ✅ Scraping / SERP API | Ce n’est pas la fonction de l’API Places |
| “People also search for” des concurrents | ✅ Scraping uniquement | Non exposé dans l’API |
Arbre de décision : API Google Places vs scraping — lequel choisir ?
Plutôt qu’un flou « ça dépend », voici un cadre de décision concret. Pose-toi ces quatre questions :
1. As-tu besoin de données en temps réel dans une application de production ? → Oui : utilise l’API officielle. Elle est supportée, couverte par un SLA et conforme aux conditions d’utilisation. Arrête-toi là. → Non : continue.
2. As-tu besoin de données que l’API ne renvoie pas (avis complets, popular times, Q&R) ? → Oui : le scraping est nécessaire. L’API ne peut littéralement pas fournir ces données. → Non : continue.
3. Combien d’enregistrements par mois ? → Moins de 10K : l’API est probablement la moins chère, surtout si tu n’as besoin que des champs Essentials ou Pro. Les quotas gratuits couvrent déjà beaucoup à cette échelle. → Plus de 10K : le scraping ou une API de scraping managée sera probablement plus rentable, surtout pour des champs riches.
4. As-tu les ressources techniques pour construire et maintenir des scrapers ? → Oui : le DIY avec Puppeteer/Playwright te donne le maximum de contrôle, mais prévois un budget de maintenance continue. → Non : utilise une API de scraping managée (Thunderbit API, SerpApi, Outscraper) ou un outil no-code (Thunderbit Chrome Extension).
Comparatif rapide des alternatives orientées développeurs
| Outil | Modèle de tarification | Format de sortie | Anti-bot pris en charge | Support batch |
|---|---|---|---|---|
| Thunderbit API / MCP | Basé sur des crédits (Extract = 20 crédits/requête) | JSON structuré conforme au schéma | ✅ Rendu JS, rotation des proxies, géoroutage | ✅ Jusqu’à 100 URLs par lot |
| SerpApi | Par recherche (forfaits par paliers) | JSON structuré | ✅ | ✅ Via les paramètres API |
| Outscraper | Par enregistrement (paiement à l’usage) | JSON / CSV | ✅ | ✅ Via des files de tâches |
| DIY (Puppeteer/Playwright) | Proxy + temps de dev | HTML brut (à parser) | ❌ À votre charge | ✅ Ce que vous construisez |
L’atout différenciant de l’API Thunderbit : elle renvoie du JSON structuré, aligné sur le schéma que tu définis en JSON Schema — pas du HTML brut ni du Markdown qu’il faut encore retraiter. Si tu alimentes un pipeline LLM ou une base de données, ça fait gagner un vrai temps de post-traitement.
Où Thunderbit se situe dans tout ça (pour les équipes métier et les développeurs)
Nous avons créé Thunderbit pour combler l’écart entre « j’ai besoin de données Google Maps » et « je ne veux pas devenir ingénieur en infrastructure de scraping ». Voici comment ça fonctionne pour les deux publics.
Pour les utilisateurs non techniques : l’extension Chrome
- Ouvre une page Google Maps — une page de résultats ou une fiche d’entreprise
- Clique sur « AI Suggest Fields » — l’IA de Thunderbit lit la page et propose des colonnes (nom, adresse, note, avis, téléphone, etc.)
- Clique sur « Scrape » — l’extension extrait les données dans un tableau structuré. Utilise le mode cloud pour jusqu’à 50 pages en parallèle
- Scrape les sous-pages — clique sur « Scrape Subpages » pour visiter chaque fiche et récupérer les détails complets
- Exporte — vers Excel, Google Sheets, Airtable ou Notion. Export de données gratuit, sans paywall
Pour la surveillance récurrente — suivi hebdomadaire des notes des concurrents, nouvelles fiches d’entreprises — le scraper planifié s’exécute automatiquement selon la cadence que tu définis.
Pour les développeurs : API, serveur MCP et CLI
POST /extractavec un JSON Schema : envoie une URL Google Maps, définis les champs souhaités, et récupère un JSON structuré. RéglerenderMode: "full"pour les pages riches en JavaScript. Thunderbit prend en charge le rendu, l’anti-bot, la rotation des proxies et le géoroutage.POST /distill: obtiens du Markdown propre à partir de n’importe quelle page — utile pour les pipelines LLM qui ont besoin de contenu brut plutôt que de champs structurés. 1 crédit/requête contre 20 pour Extract.- Serveur MCP : les agents IA (Claude, Cursor) peuvent scraper des données Google Maps au fil de la tâche. Prend en charge la distillation, l’extraction structurée, les suggestions de champs et les batchs jusqu’à 100 URLs.
- CLI :
thunderbit batch extract --file urls.txt --schema places.jsonpour du scraping planifié ou intégré à un pipeline CI/CD.
Tarification en crédits : Extract = 20 crédits/requête, Distill = 1 crédit/requête. Les crédits API s’appliquent par requête, pas par ligne (contrairement à l’extension, où 1 crédit = 1 ligne de sortie). Consulte Thunderbit Pricing pour les offres actuelles.
Aspects juridiques et conditions d’utilisation
Je vais rester bref et factuel — pas de discours alarmiste, pas de pitch commercial.
L’API Google Places s’accompagne de conditions claires : les conditions spécifiques du service Google indiquent que le contenu de l’API Places peut être utilisé sans Google Map, mais ne doit pas être utilisé avec une carte non Google. Les coordonnées latitude / longitude peuvent être mises en cache jusqu’à 30 jours calendaires consécutifs ; les Place IDs peuvent être conservés indéfiniment. L’attribution est obligatoire pour les détails, les photos et les avis.
Le scraping de Google Maps peut enfreindre les Conditions d’utilisation de Google. L’application varie : les risques vont du blocage d’IP aux CAPTCHA, et dans de rares cas à des poursuites. Les API de scraping managées assument généralement une partie de la charge de conformité pour l’utilisateur, mais ce n’est pas un bouclier juridique.
Pour une application de production destinée à des utilisateurs finaux, l’API officielle est l’option la plus sûre. Pour la recherche interne, l’analyse par lot et la veille concurrentielle, le scraping est courant dans l’industrie. Consulte ton conseil juridique pour les workflows commerciaux.
Ce que je choisirais vraiment, et pourquoi
Après avoir passé en revue les SKU tarifaires, les listes de champs, les discussions communautaires et la documentation des outils, voici ma conclusion :
- Utilise l’API officielle quand tu as besoin de données en temps réel, conformes aux conditions d’utilisation, dans une application de production, ou lorsque les champs Essentials / Pro suffisent et que ton volume reste sous 10K/mois. Les quotas gratuits sont généreux à petite échelle, et la qualité des données est irréprochable.
- Utilise le scraping (API managée ou outil no-code) quand tu as besoin des avis complets, des popular times, de la Q&R, du contexte concurrentiel, ou de tout champ que l’API n’expose pas. Idem lorsque ton volume dépasse 10K à 100K enregistrements/mois et que tu demandes des champs riches (Enterprise + Atmosphere) — la facture API devient difficile à défendre.
- Utilise les deux quand ton workflow exige à la fois des Place IDs canoniques et des données structurées de base (API), plus des infos approfondies visibles sur la page (scraping). C’est plus fréquent que la plupart des articles ne le reconnaissent.
Le point de bascule côté coût : en dessous d’environ 10K enregistrements/mois avec des champs basiques, l’API est plus simple et souvent gratuite. Au-delà, surtout pour des données riches, le scraping devient généralement plus rentable. À 1M d’enregistrements avec les champs Enterprise + Atmosphere, on tourne autour de 18K $/mois via l’API contre une fraction de ce montant avec un scraper managé.
Si tu veux tester par toi-même, la Thunderbit Chrome Extension est le moyen le plus rapide de voir ce que le scraping capte par rapport à l’API. Pour les workflows développeurs, la documentation de l’API Thunderbit contient tout ce qu’il faut pour démarrer. Et pour aller plus loin sur le web scraping sans code ou le web scraping avec IA en général, nous avons déjà largement couvert ces sujets sur le blog.
Points clés à retenir
- L’API Google Places est l’outil adapté aux applications de production, à l’autocomplete et aux recherches structurées de lieux — mais elle limite les avis à 5, les photos à 10, et n’expose ni popular times, ni Q&R, ni suggestions concurrentes.
- Le scraping capture tout ce qui est visible sur une page Google Maps, y compris l’ensemble des avis et les données de popular times, mais impose de gérer l’anti-bot ou de payer un service managé.
- En dessous de 10K enregistrements/mois, les quotas gratuits de l’API en font souvent l’option la moins chère. Au-dessus de 100K, le scraping ou les API de scraping managées sont généralement plus économiques pour les données riches.
- Les scrapers DIY cassent régulièrement à cause des défenses anti-bot et des changements de DOM de Google — prévois 40 heures développeur ou plus par an pour la maintenance, ou utilise un outil managé.
- La meilleure stratégie en conditions réelles est souvent hybride : API pour les IDs canoniques et les champs de base, scraping pour l’intelligence approfondie que l’API ne peut pas renvoyer.
- Thunderbit couvre les deux besoins : une extension Chrome pour les utilisateurs no-code et une API / un serveur MCP en JSON structuré pour les développeurs.
FAQ
Peut-on obtenir plus de 5 avis Google via l’API Places ?
Non. L’API Google Places limite les retours d’avis à 5 par lieu, triés par pertinence. C’est le cas depuis le lancement de l’API et cela n’a pas changé malgré des années de demandes des développeurs. Pour accéder à tous les avis disponibles d’une entreprise, le scraping (fait maison ou via une API de scraping managée) est la seule option.
Le scraping de Google Maps est-il légal ?
Il n’existe pas de réponse universelle par oui ou par non. Le scraping de données Google Maps visibles publiquement peut violer les Conditions d’utilisation de Google, et l’application va du blocage d’IP à, rarement, des poursuites. Beaucoup d’entreprises utilisent le scraping pour la recherche interne et la veille concurrentielle sans problème. Les API de scraping managées absorbent une partie du risque de conformité, mais ce n’est pas une protection juridique. Si tu construis un produit commercial ou traites des données personnelles, consulte un avocat.
Combien coûte l’API Google Places pour 100K requêtes ?
Ça dépend des champs demandés. Pour Place Details au niveau Essentials, compte environ 450 $. Au niveau Pro, environ 1 615 $. En Enterprise + Atmosphere (qui inclut avis et équipements), environ 2 475 $. Si ton workflow exige aussi Text Search Pro pour la découverte, ajoute environ 3 040 $. Ces estimations utilisent les paliers de volume publiés par Google et supposent une requête facturable par enregistrement après le quota gratuit.
Quelle est la différence entre une API de scraping et un outil de scraping no-code ?
Une API de scraping (comme Thunderbit Open API) s’adresse aux développeurs qui intègrent le scraping dans du code, des pipelines d’automatisation ou des workflows d’agents IA via des requêtes HTTP. Un outil no-code (comme la Thunderbit Chrome Extension) permet aux utilisateurs non techniques de pointer, cliquer et exporter des données depuis leur navigateur sans écrire de code. Les deux peuvent renvoyer des données structurées ; la différence tient à l’interface et au modèle d’intégration.
Thunderbit fonctionne-t-il sur les pages Google Maps ?
Oui. L’extension Chrome peut scraper les résultats de recherche Google Maps et les fiches d’entreprises individuelles — l’IA propose automatiquement les champs, et tu peux utiliser le mode cloud pour jusqu’à 50 pages en parallèle. L’endpoint POST /extract de l’API avec renderMode: "full" gère les pages Google Maps rendues en JavaScript et renvoie du JSON structuré conforme au schéma. Le serveur MCP permet aux agents IA de scraper des données Google Maps en plein workflow.
En savoir plus
