Les emplacements des concessionnaires ne se trouvent presque jamais dans une base de données unique et bien propre. Un fabricant publie un annuaire clair, un autre mise sur une carte interactive, un troisième impose une recherche par code postal, et un quatrième planque les détails des concessionnaires derrière des pages de profil individuelles.
Quand le portefeuille monte à des centaines de sites, le travail ne consiste plus simplement à « récupérer quelques adresses ». Le vrai livrable, c’est un référentiel de concessionnaires fiable, capable de répondre à des questions métier comme :
- Où la distribution se développe-t-elle ou recule-t-elle ?
- Quels territoires présentent des zones de couverture manquantes ?
- Quels concessionnaires ont été ajoutés, déplacés ou supprimés ?
- Quels emplacements proposent une gamme de produits ou un service précis ?
- Quel responsable CRM doit recevoir un nouveau concessionnaire détecté ?
- Comment l’empreinte réseau d’un concurrent évolue-t-elle dans le temps ?
L’architecture la plus pratique est simple : repérer les sources, classer les modèles de localisateur, extraire les données dans un schéma canonique, conserver les preuves d’origine, résoudre les doublons, détecter les changements significatifs et les envoyer vers la bonne équipe.
Le système cible
Un workflow de suivi des concessionnaires en production comporte six couches :
- Registre des sources : les sites web, les URL de localisateur, les pays, les propriétaires, les patterns, les calendriers et l’état du dernier passage.
- Découverte : une méthode répétable pour trouver les pages d’annuaire, les sitemaps, les API, les formulaires de recherche et les URL de détail.
- Extraction : des jobs navigateur ou API qui collectent les mêmes champs sémantiques à travers des mises en page différentes.
- Normalisation : des adresses, numéros de téléphone, pays, catégories et libellés de statut cohérents, sans écraser les valeurs brutes.
- Couche entité et changement : des identités canoniques des concessionnaires, les appartenances de marque, les horodatages de première et dernière apparition, ainsi que les ajouts ou suppressions confirmés.
- Activation : alertes, routage vers le CRM, analyse de couverture, tableaux de bord et files de revue.
Essayer d’aller directement des sites web à une importation CRM crée en général un empilement fragile de scripts bricolés et d’enregistrements en double. Le registre et le modèle canonique sont ce qui permet de gérer des centaines de sites.
Étape 1 : définir le schéma canonique du concessionnaire
Commencez par la sortie attendue, pas par le premier site web. Un schéma minimal utile ressemble à ceci :
| Groupe | Champs |
|---|---|
| Preuve source | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| Identité | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| Adresse | street_address, address_locality, address_region, postal_code, address_country |
| Contact | phone_raw, phone_normalized, website |
| Localisation | latitude, longitude |
| Attributs commerciaux | services, products, categories, authorized_status_raw |
| Observation | observed_at, first_seen, last_seen, record_status |
| Contrôle des changements | source_hash, change_hash, parser_version |
PostalAddress de Schema.org fournit une base de nommage utile pour l’adresse, la localité, la région, le code postal et le pays. Préférez les codes pays ISO à deux lettres dans les données normalisées, tout en conservant le pays exactement tel que la source le publie.
Conservez côte à côte les champs bruts et normalisés. Si un site affiche St. John's, NL et que la couche de normalisation produit une province et un indicatif téléphonique standardisés, les deux versions doivent rester disponibles pour le contrôle.
Étape 2 : créer un registre des sources
Le registre des sources est le plan de contrôle de l’opération. Donnez à chaque site web une ligne avec :
- Domaine et marque
- Pays ou marché
- URL probable du localisateur
- Famille de pattern du localisateur
- Mode de crawl préféré
- Version du parser ou du template
- Fréquence d’exécution
- Responsable métier
- Dernier passage tenté, réussi, vide et échoué
- Remarques sur les champs de recherche ou les interactions requises
N’attendez pas que chaque localisateur soit compris. Créez d’abord le registre, puis laissez la classification s’affiner au fil du pilote.
Comment découvrir les sources de localisateur
Vérifiez :
- La navigation principale et les liens de pied de page tels que « Trouver un concessionnaire », « Où acheter » ou « Localisateur de magasin »
/sitemap.xmlet les index de sitemaps- La recherche interne du site
- Les requêtes de moteur de recherche comme
site:brand.example dealer locator - Le code source de la page et les données structurées embarquées
- Les requêtes réseau déclenchées par une recherche de localisateur
- Les PDF ou documents de distributeur comme source de secours
Le protocole Sitemap exige une URL <loc> pour chaque entrée du sitemap et prend en charge les index de sitemaps. Les sitemaps peuvent accélérer la découverte, mais ils ne garantissent pas que tous les résultats dynamiques du localisateur soient inclus, et une valeur <lastmod> ne doit pas être considérée comme une preuve que les informations du concessionnaire sont à jour.
Étape 3 : classer chaque localisateur avant de monter en échelle
La plupart des sites de concessionnaires se répartissent en quelques familles de patterns :
- Liste ou tableau HTML statique — le cas le plus simple ; les enregistrements sont présents dans le code source de la page.
- Annuaire paginé ou défilement infini — les enregistrements se répètent mais nécessitent une navigation.
- Cartes avec liens vers des détails — les cartes récapitulatives doivent être enrichies via des sous-pages.
- Formulaire de recherche — l’utilisateur doit saisir un pays, un État, une ville ou un code postal.
- JSON embarqué ou réponse réseau — la page est une coque visuelle autour de données structurées.
- Liste légère plus pages de détail des concessionnaires — la liste porte l’identité, tandis que les adresses et services vivent sur les sous-pages.
- Annuaire PDF ou document — l’extraction et la revue des changements nécessitent un chemin spécifique aux documents.
Un scraper universel ne gérera pas correctement des centaines de sites différents. L’approche scalable consiste à construire un workflow réutilisable par famille de pattern, puis à le configurer par source.
Étape 4 : tester le workflow navigateur avec Thunderbit
Thunderbit est très utile pour valider le schéma sur des sites représentatifs avant d’investir dans l’automatisation à grande échelle.
Procédure pilote
- Ouvrez un annuaire de concessionnaires représentatif dans Chrome.
- Lancez Thunderbit et utilisez AI Suggest Fields.
- Renommez les champs proposés pour qu’ils correspondent au schéma canonique.
- Ajoutez des Field AI Prompts pour la normalisation ou la classification — par exemple, mapper le nom de pays affiché vers un code ISO ou classer les services dans un ensemble de catégories approuvé.
- Activez la gestion de la pagination ou du défilement infini pour les pages de liste.
- Utilisez le scraping de sous-pages lorsque les pages individuelles contiennent les téléphones, sites web, services ou IDs source.
- Exportez un petit échantillon vers Sheets ou Excel et validez chaque URL source.
Le mode navigateur est particulièrement utile lorsqu’un localisateur nécessite une interaction, une session connectée ou un rendu qu’une simple requête ne reproduit pas. N’utilisez que des sources et des comptes que l’organisation est autorisée à consulter.
Choisissez des sites représentatifs, pas les plus faciles
Le premier pilote devrait inclure 20 sites couvrant les principaux patterns, régions et technologies de page. Si toutes les sources du pilote sont de simples tableaux statiques, le workflow semblera parfait jusqu’à l’arrivée du premier localisateur basé sur une carte.
Pour chaque famille de pattern, validez au minimum :
- Un exemple propre
- Un exemple de grande taille
- Un exemple dynamique ou irrégulier
- Un site avec pages de détail de concessionnaire
- Un site avec champs rares ou facultatifs
Étape 5 : passer les sources stables à grande échelle avec le Batch Extract API
Pour les pages publiques répétables, migrez les jobs stables de l’opération manuelle dans le navigateur vers le Thunderbit Web Scraper API.
Le point de terminaison Batch Extract accepte jusqu’à 50 URL dans une seule requête avec un unique JSON Schema. Il renvoie un ID de job, traite les URL en parallèle, prend en charge les erreurs par URL, peut envoyer des notifications webhook et propose des options renderMode comme none, basic et full.
Conception du batch
- Regroupez les URL qui partagent le même schéma de sortie sémantique.
- Gardez les lots à 50 URL maximum.
- Sélectionnez le mode de rendu le plus léger qui expose les données de manière fiable.
- Conservez l’ID du job et la version du parser avec l’exécution.
- Enregistrez le statut de réussite, vide et erreur pour chaque URL, pas seulement pour le lot.
- Ne relancez que les URL en échec.
- Conservez les valeurs extraites brutes et les liens source avant la normalisation.
Un seul schéma peut couvrir des sites conçus différemment tant que le sens métier des champs reste cohérent. C’est ce qui permet à un annuaire statique et à un localisateur sous forme de cartes d’alimenter le même référentiel de concessionnaires.
Étape 6 : normaliser sans effacer les preuves
La normalisation rend les enregistrements comparables ; elle ne doit pas les rendre inexploitables en audit.
Les transformations recommandées incluent :
- Supprimer les espaces superflus et normaliser la ponctuation
- Standardiser la casse tout en conservant
dealer_name_raw - Analyser les numéros de téléphone avec un contexte pays explicite
- Mapper les noms de pays et de région vers des codes approuvés
- Découper ou recomposer les composants d’adresse de façon cohérente
- Normaliser les URL et retirer les paramètres de suivi lorsque c’est pertinent
- Mapper les services en texte libre vers des catégories contrôlées tout en conservant la formulation source
N’écrasez pas le libellé d’autorisation de la source. Si un fabricant indique « Authorized Dealer » et qu’un autre indique « Certified Reseller », stockez la formulation exacte et ajoutez éventuellement une catégorie normalisée dans un champ séparé.
Étape 7 : résoudre l’identité des concessionnaires entre marques et sources
Le simple matching sur le nom du concessionnaire ne suffit pas. « Smith Auto », « Smith Automotive » et « Smith Auto LLC » peuvent être une seule entreprise — ou trois entreprises dans des villes voisines.
Utilisez une clé composite candidate telle que :
nom normalisé + code postal + téléphone
ou, lorsque les coordonnées sont disponibles :
nom normalisé + distance géospatiale + numéro de rue
Puis attribuez un score aux éléments de preuve :
- Nom normalisé exact ou quasi exact
- Numéro de téléphone exact
- Même code postal
- Adresse de rue similaire
- Coordonnées dans un rayon réduit
- Domaine de site web correspondant
Créez une table de correspondance source-vers-canonique plutôt que de fusionner immédiatement les enregistrements. Plusieurs fabricants peuvent pointer vers le même concessionnaire physique tout en conservant des appartenances de marque, des services et des libellés de statut distincts.
Étape 8 : détecter les changements significatifs
Chaque exécution doit être une observation, pas un écrasement destructif.
Stockez :
observed_atpour l’exécution courantefirst_seenlorsque l’enregistrement source apparaît pour la première foislast_seenpour l’observation réussie la plus récente- Un hash source pour l’enregistrement brut
- Un hash de changement pour les champs métier normalisés
Les types de changement utiles incluent :
- Concessionnaire ajouté
- Concessionnaire manquant
- Nom, adresse, téléphone ou site web modifié
- Statut d’autorisation modifié
- Catégorie de service ou de produit modifiée
- Emplacement déplacé
- Échec de page source ou dérive de mise en page
Un enregistrement manquant doit d’abord devenir missing_pending_review. Ne confirmez la suppression qu’après absence répétée ou revue manuelle. Un crawl en échec, une réponse vide ou un sélecteur cassé ne prouvent pas qu’un concessionnaire a fermé.
Étape 9 : ajouter Google Places comme validation optionnelle
Google Places Place Details peut enrichir ou valider un enregistrement de concessionnaire avec un stable place ID, un nom affiché, une adresse formatée, des coordonnées, un numéro de téléphone, un site web, un statut d’activité et des informations sur un déménagement, selon le champ demandé et le SKU.
Utilisez-le comme signal secondaire, et non comme autorité pour savoir si un emplacement appartient au programme concessionnaire d’un fabricant. La source du fabricant reste l’autorité pour cette appartenance. Conservez le fournisseur de validation et l’horodatage, et n’écrasez jamais silencieusement le statut du fabricant.
Étape 10 : mesurer la qualité d’extraction par pattern et par source
Suivez la qualité au niveau de l’exécution, du pattern et du domaine.
Métriques par exécution
- URL source enregistrées
- URL tentées
- URL réussies, vides et en échec
- Enregistrements extraits
- Enregistrements ajoutés, modifiés, manquants et inchangés
- Complétude des champs essentiels
- Nombre de candidats doublons
- Suppressions suspectées en attente de revue
- Incidents de dérive de schéma
Validation par échantillon
Pour chaque famille de pattern et pour chaque grande exécution :
- Comparez 20 à 50 enregistrements échantillonnés avec leurs pages sources.
- Confirmez le nombre d’URL attendues par rapport aux URL tentées et réussies.
- Passez en revue les champs essentiels manquants par domaine.
- Inspectez les clusters de doublons et les correspondances d’entités à faible confiance.
- Vérifiez les valeurs aberrantes de coordonnées et les incohérences pays/code postal.
- Reprenez un échantillon de suppressions apparentes.
- Enregistrez la version de l’extracteur ou du template utilisée.
L’objectif n’est pas un pourcentage global d’« exactitude » unique. L’objectif est de savoir quels patterns et quelles sources sont fiables, quels champs sont fragiles, et où concentrer les efforts de revue.
Étape 11 : acheminer les changements dans les workflows métier
Chaque type de changement mérite une destination différente :
- Nouveau concessionnaire : vers les opérations commerciales pour la création CRM, l’attribution du propriétaire et l’affectation territoriale.
- Emplacement supprimé ou fermé : vers une file de revue avant modification du statut du compte.
- Changement d’adresse ou de téléphone : mise à jour de l’enrichissement et vérification des opportunités ouvertes ou de la couverture de service.
- Changement d’autorisation : notification aux équipes channel management et aux équipes en contact avec les clients.
- Zone de couverture manquante : vers la planification territoriale et le recrutement de partenaires.
- Expansion d’un concurrent : mise à jour de l’intelligence de distribution et de la stratégie régionale.
- Échec répété de source : vers la file data-operations, pas vers l’équipe commerciale.
Chaque notification doit inclure le concessionnaire canonique, l’appartenance de marque, le type de changement, les valeurs avant/après, l’URL source, l’heure d’observation et le niveau de confiance ou l’état de revue.
Plan de déploiement sur 30/60/90 jours
Jours 1 à 30 : concevoir et prouver
- Finaliser le schéma canonique et les catégories contrôlées.
- Construire le registre des sources.
- Classer 20 sites représentatifs.
- Valider 3 à 5 familles de patterns de localisateur.
- Mettre en place les règles de validation par échantillon et les métriques d’exécution.
- Livrer un premier référentiel de concessionnaires avec preuves sources.
Jours 31 à 60 : étendre et automatiser
- Étendre la classification à l’ensemble du portefeuille.
- Déplacer les groupes d’URL publiques stables vers l’extraction par lot.
- Ajouter les calendriers, le suivi des jobs, la logique de retry et les tableaux de bord d’erreur.
- Introduire le mapping d’entité source-vers-canonique.
- Connecter les ajouts et mises à jour revus aux workflows CRM.
Jours 61 à 90 : industrialiser l’intelligence de changement
- Ajouter des alertes et des files de revue spécifiques aux changements.
- Introduire la première apparition, la dernière apparition et la confirmation de suppression.
- Ajouter une validation Places optionnelle lorsqu’elle améliore la confiance sur l’adresse.
- Définir des objectifs de service au niveau des exécutions.
- Revoir chaque mois les performances des patterns et des templates.
- Désigner un responsable pour chaque famille de source et chaque action métier.
Modes d’échec fréquents
Créer un scraper par site web. Cela génère des centaines de chemins de maintenance. Classez les familles de patterns et séparez la logique réutilisable de la configuration source.
Dédupliquer uniquement sur le nom du concessionnaire. Les noms sont incohérents et souvent réutilisés. Faites le matching avec l’adresse, le code postal, le téléphone, les coordonnées et les preuves du site web.
Écraser les valeurs brutes. Les erreurs de normalisation deviennent impossibles à auditer dès que la représentation source est perdue.
Interpréter une sortie vide comme zéro concessionnaire. Une sortie vide peut signifier une interaction échouée, un changement de rendu ou une requête bloquée. Séparez la santé du crawl du statut métier.
Déclarer une suppression après un seul échec. Exigez une absence répétée ou une vérification manuelle.
Utiliser un fournisseur de cartographie comme autorité concessionnaire. Les données cartographiques peuvent valider un lieu, mais pas confirmer la relation d’autorisation d’un fabricant.
Monter en échelle avant de mesurer la qualité des patterns. Une petite erreur d’extraction devient un gros problème opérationnel lorsqu’elle est multipliée par des centaines de sites.
FAQ
Un seul schéma peut-il fonctionner sur des centaines de sites de concessionnaires différents ?
Oui. Les mises en page varient, mais les champs sémantiques — nom du concessionnaire, adresse, téléphone, site web, marque, services, URL source et statut — restent largement cohérents. Utilisez différents patterns d’extraction pour alimenter un schéma canonique unique.
Comment automatiser les pages de localisateur qui exigent une recherche par code postal ?
Traitez le formulaire de recherche comme une famille de pattern à part entière. Définissez une grille de couverture des emplacements d’entrée, capturez les IDs ou URLs de résultats, dédupliquez les zones de recherche qui se chevauchent, et conservez l’entrée qui a produit chaque résultat pour le débogage.
À quelle fréquence faut-il actualiser les emplacements des concessionnaires ?
Adaptez la cadence à l’usage métier et au comportement de la source. Les sources concurrentielles ou de couverture de service à forte valeur peuvent être exécutées chaque semaine ; les annuaires fabricants plus lents peuvent être actualisés chaque mois. Les échecs d’exécution doivent déclencher une revue opérationnelle indépendamment de la cadence de changement des concessionnaires.
Comment le système distingue-t-il un concessionnaire supprimé d’un scrape échoué ?
Suivez séparément la santé de la source et la présence de l’enregistrement. Un crawl échoué ou vide ne met pas à jour le statut last-seen du concessionnaire. Seules les exécutions réussies peuvent fournir une preuve d’absence, et la suppression doit nécessiter répétition ou revue.
Google Places doit-il remplacer l’adresse et le statut métier du site web ?
Non. Utilisez Places comme enrichissement ou validation, en stockant son horodatage et son fournisseur, et conservez le localisateur du fabricant comme autorité pour l’appartenance au programme de concessionnaires.
Le suivi automatisé des concessionnaires fonctionne lorsqu’il est traité comme un produit data : un registre de sources gouverné, des familles de patterns réutilisables, des preuves conservées, une résolution d’entités prudente et des workflows de changement pilotés par le métier. Cette architecture peut passer de 20 sites pilotes à des centaines sans transformer chaque refonte en reconstruction d’urgence.
En savoir plus
