Scraping de données : les 5 erreurs qui coûtent cher

Ces cinq erreurs viennent d'un pipeline réel : la constitution d'une base de 120 000 contacts dirigeants à l'échelle nationale, entre mars et août 2026. Aucune n'est théorique. Chacune a coûté des heures ou des jours, et c'est en les corrigeant que le système est passé de quelques centaines de lignes par jour à plusieurs dizaines de milliers.

Erreur 1 : croire qu'un scraper qui marche va continuer de marcher

L'incident le plus coûteux du projet n'a rien eu de technique. Un jeton d'authentification a expiré, le pipeline s'est arrêté, et personne ne l'a su pendant quatre jours. Le script ne plantait pas : il tournait, recevait des refus, et les enregistrait sans rien signaler.

Un scraper qui échoue bruyamment est un scraper sain. Le danger vient de celui qui échoue en silence, parce que la panne se mesure alors en jours perdus et non en minutes. La correction n'a pas été de fiabiliser le jeton — un jeton expire toujours — mais de surveiller la progression : si le compteur de lignes traitées n'avance pas pendant trente minutes, une alerte part.

Vérifiez ce que produit votre collecte, pas seulement qu'elle tourne. Un processus vivant qui ne produit rien est plus dangereux qu'un processus mort, parce qu'il donne l'illusion que tout va bien.

Erreur 2 : ajouter des processus au lieu d'adresses IP

C'est le réflexe le plus courant, et le plus contre-productif. La collecte est trop lente, on lance seize processus en parallèle sur la même machine, et on se fait bannir cinq fois plus vite.

La vitesse s'achète en adresses, pas en processeurs : ajouter des processus derrière une même IP ne fait que consommer son budget quotidien plus vite. Le calcul complet — combien de sessions de navigateur par adresse, quelle taille de serveur, combien de jours pour 120 000 lignes — est détaillé dans pourquoi une collecte automatisée se fait bloquer.

Erreur 3 : lire le premier élément trouvé plutôt que le bon

Un sélecteur comme `querySelector('h1.DUwDvf, h1')` semble prudent : on vise une classe précise, avec un repli générique. En réalité il renvoie le premier h1 du document, pas le premier élément correspondant au premier sélecteur.

Sur les résultats de recherche locale, un bloc publicitaire pose son propre titre avant la fiche réelle. Le pipeline lisait donc la publicité comme raison sociale, et l'associait tranquillement au bon numéro de SIRET. Rien ne plantait, rien n'alertait : les données étaient simplement fausses.

Même piège avec les résultats sponsorisés, cliqués comme s'ils étaient organiques. Ces deux défauts réunis expliquaient une part importante des rejets d'un premier sprint. Une fois corrigés — et testés sur 2 088 rejets réels plus 2 000 paires aléatoires comme pièges — ils ont permis de récupérer 607 lignes, soit 29 %, pour 0,25 % de faux positifs.

Quand une extraction produit des données plausibles mais fausses, le coupable est presque toujours un sélecteur trop permissif.

Erreur 4 : comparer deux noms avec un ratio de similarité nu

Pour rapprocher une raison sociale légale d'un nom commercial trouvé en ligne, la tentation est d'utiliser une distance textuelle et un seuil. Ça échoue sur exactement les cas qui comptent.

`FCN` contre `FCN Expertise Audit Conseil` donne un ratio de 0,20 — largement sous n'importe quel seuil raisonnable. Pourtant c'est la même entreprise. Les abréviations, les sigles et les noms tronqués sont la norme dans les registres, pas l'exception.

La correction a demandé trois ajouts : la ressemblance partielle, la couverture des mots distinctifs pondérée par leur longueur, et la reconnaissance des sigles — `ICAF` pour « Institut de Comptabilité et d'Analyse Financière ». Puis un garde-fou : en l'absence de mot distinctif commun, le seuil passe de 0,55 à 0,75. Cette seule règle a divisé les faux positifs par deux, en écartant des rapprochements du type « AMBULANCES ROUSSEAU » contre « Nantes Ambulance Sarl ».

Audit final sur 242 fiches : 95,5 % géographiquement cohérentes, aucun doublon de téléphone entre SIRET différents.

Erreur 5 : traiter tout en un seul bloc

Un traitement national lancé d'une traite a épuisé la mémoire de la machine et s'est perdu en entier. Des heures de collecte, rien à récupérer, parce que l'écriture n'intervenait qu'à la fin.

Le correctif tient en deux règles : plafonner la taille des lots, et écrire au fil de l'eau plutôt qu'à la fin. Un incident ne coûte alors que le lot en cours. Combiné à une file de travail qui reprend là où elle s'est arrêtée, le pipeline redémarre seul après une panne, sans intervention et sans perte.

Le taux que vous ne dépasserez pas, et pourquoi

Un dernier point, qui n'est pas une erreur mais une limite qu'il vaut mieux connaître avant de la promettre à un client.

Sur ce pipeline, le téléphone est trouvé dans 77 % des cas, le nom du dirigeant dans 75 %, l'email professionnel dans 33 % seulement. Ce n'est pas un défaut de méthode : les pare-feux applicatifs des sites cibles ont renvoyé 362 refus en 48 heures. Insister ferait perdre le domaine définitivement, donc la règle est d'une seule passe par domaine, trois pages au maximum.

Un tiers d'emails est le plafond réaliste d'une collecte respectueuse. Quiconque vous annonce 80 % ou 90 % sans nommer sa source ne les a jamais mesurés — mais le plus souvent, il ne compte pas la même chose. Deux questions suffisent à le vérifier.

Compte-t-il les adresses génériques ? Une adresse « contact@ » ou « info@ » se trouve sur presque tous les sites : la compter fait monter n'importe quel taux au-dessus de 80 %. Je ne compte que les adresses nominatives, celles qui désignent une personne. C'est là qu'est l'essentiel de l'écart.

Parle-t-il d'adresses trouvées ou délivrables ? Je mesure la complétion d'un fichier — pour chaque ligne, le canal a-t-il été trouvé. C'est autre chose que le taux de rebond d'un envoi, qui se mesure après coup et sur un autre périmètre. Les deux se confondent partout, et une adresse déduite d'un format d'entreprise (« prenom.nom@ ») se compte facilement sans jamais avoir été vérifiée.

Ces deux distinctions ne sont pas des détails de méthode : elles décident si un chiffre veut dire quelque chose. Demandez-les avant d'acheter un fichier sur la foi d'un pourcentage.

Ce qu'il faut retenir

La qualité d'une extraction ne se joue pas sur l'outil choisi, mais sur trois réflexes : surveiller ce qui est produit et non ce qui tourne, dimensionner en adresses IP plutôt qu'en processus, et se méfier des données qui semblent correctes. Une extraction qui plante se répare en une heure ; une extraction qui ment se découvre trois mois plus tard, dans les retours de l'équipe commerciale.

Cet article fait partie du Guide Complet de l'Automatisation B2B. Les chiffres cités viennent de cette étude de cas détaillée.