Collecte automatisée : pourquoi ça se fait bloquer

La plupart des articles sur le sujet recommandent d'ajouter des délais et de faire tourner des adresses IP. C'est juste, et c'est très insuffisant. Voici ce qu'on apprend en faisant tourner une collecte nationale pendant six mois, sur 120 000 lignes enrichies.

Ce qui déclenche un blocage n'est pas un volume

C'est l'erreur de raisonnement de départ : chercher le nombre de requêtes à ne pas dépasser, comme s'il existait une limite affichée sous laquelle on serait tranquille.

Les défenses modernes ne comptent pas, elles comparent. Deux collectes au même rythme ne sont pas traitées pareil selon la manière dont elles se présentent : signature technique, exécution du JavaScript, historique de session, régularité des délais. Un même volume passe ou ne passe pas selon ces signaux.

La conséquence pratique : il n'y a pas de seuil à connaître, il y a un comportement à tenir. Et ce comportement se décide dans l'architecture, pas dans un paramètre de temporisation.

Un vrai navigateur, pas un client HTTP

C'est la décision qui change tout, et elle coûte cher en ressources.

Un client HTTP — une requête envoyée depuis un script — se signale à chaque appel. Il n'exécute pas le JavaScript de la page, ne charge ni les polices ni les images, ne possède aucun historique de session, et présente une signature technique qui ne ressemble à aucun navigateur réel. Les défenses modernes ne comparent pas des volumes : elles comparent des comportements.

Piloter un vrai Chrome coûte environ cent fois plus de mémoire et de processeur par requête. En échange, la page s'exécute normalement, l'écran de consentement est traité comme un visiteur le ferait, et les délais entre actions sont ceux d'une navigation. C'est très exactement le comportement décrit plus haut, et c'est ce qui se paie.

Le calcul est simple : mille requêtes rapides qui font bannir l'adresse valent moins que cent requêtes lentes qui passent tous les jours pendant six mois.

La vitesse s'achète en adresses IP, pas en processus

Voici l'erreur la plus fréquente, et la plus coûteuse. La collecte est trop lente, alors on lance seize processus en parallèle. Résultat : on se fait bannir cinq fois plus vite, sans avoir gagné une ligne.

Le mur du passage à l'échelle n'est pas la puissance de calcul, c'est le nombre d'adresses IP disponibles. Chaque adresse supporte un budget quotidien, quel que soit le nombre de processus qui tournent derrière. Seize processus sur une adresse ne se partagent pas seize budgets : ils consomment le même, seize fois plus vite.

La conséquence est contre-intuitive pour qui vient du développement : le dimensionnement machine découle de l'adresse IP, il ne la précède pas. Deux mille lignes par jour représentent environ trois sessions de navigateur simultanées, soit un petit serveur à deux cœurs par adresse. Tout ce qu'on ajoute au-dessus est du gaspillage.

Le calcul de planification devient alors trivial. Pour 120 000 lignes à 2 000 par jour et par adresse : une adresse, soixante jours ; deux adresses, trente jours ; quatre adresses, quinze jours.

N'appelez la source surveillée qu'en dernier recours

La meilleure façon de ne pas se faire bloquer par une source reste de ne pas l'interroger.

Sur ce pipeline, la donnée est d'abord cherchée dans les sources ouvertes : registre officiel des entreprises, site de la société, annuaires publics. La source surveillée n'est sollicitée que lorsque tout le reste a échoué, ou pour arbitrer un doute entre deux résultats.

L'effet est direct sur le budget quotidien : de 2 000 à 5 000 lignes par jour et par adresse, pour la même infrastructure. La France entière en trois semaines, sur une seule adresse.

Ce que ça change dans la conception : la source la plus riche ne doit pas être la première appelée, mais la dernière. C'est l'inverse de ce qu'on écrit spontanément.

Le piège qui coûte une journée : l'écran de consentement

Depuis une adresse allemande, l'écran de consentement Google arrive en allemand. Le bouton « Tout refuser » n'existe pas sous ce libellé, le script ne franchit jamais l'interstitiel, et la collecte renvoie zéro résultat sur les vingt-cinq premières lignes — sans la moindre erreur dans les journaux.

Le correctif tient en deux paramètres d'URL, hl=fr et gl=FR, plus une gestion du consentement qui reconnaît plusieurs langues. Une journée perdue pour deux paramètres.

La leçon dépasse le cas particulier : quand une collecte renvoie zéro résultat sans erreur, le problème est presque toujours en amont de l'extraction. Regardez ce que la page affiche réellement à votre robot avant de suspecter votre sélecteur.

Le cadre juridique, sans faux-semblant

Beaucoup d'articles présentent tel ou tel outil comme « conforme aux conditions d'utilisation ». C'est inexact, et il vaut mieux le savoir avant qu'après.

Les grandes plateformes — réseaux professionnels, moteurs, services cartographiques — interdisent l'extraction automatisée dans leurs conditions d'utilisation, quel que soit l'outil employé. Un service tiers ne rend pas conforme une pratique qui ne l'est pas : il déplace simplement le risque. C'est une raison de plus d'aller chercher la donnée dans les sources ouvertes d'abord, comme décrit plus haut : ce n'est pas seulement plus économe, c'est le seul chemin qui se défend. Par ailleurs, un nom, une fonction et un email professionnel sont des données personnelles au sens du RGPD, y compris lorsqu'ils sont publiquement accessibles — ce qui implique une base légale, une information des personnes et un droit d'opposition effectif.

Ce n'est pas un conseil juridique, et votre situation mérite l'avis d'un professionnel. C'est un rappel de bon sens : la conformité se traite en amont du projet, pas en découvrant une mise en demeure.

Ce qu'il faut retenir

Trois principes, dans cet ordre : préférez un vrai navigateur à un client rapide, achetez de la vitesse en adresses IP plutôt qu'en processus, et n'interrogez la source surveillée qu'après avoir épuisé les sources ouvertes.

Le reste — délais aléatoires, rotation d'agents utilisateurs, en-têtes crédibles — relève de l'hygiène de base. Nécessaire, jamais suffisant.

Cet article fait partie du Guide Complet de l'Automatisation B2B. Le projet dont viennent ces enseignements est détaillé dans cette étude de cas.