La collecte de données avec connexion utilise souvent plusieurs comptes, et les limitations ne viennent pas toujours du script. Décomposer le risque d’association entre caractéristiques de l’appareil, sortie réseau, état de session et rythme des requêtes permet de mieux distinguer les variables réellement contrôlables.
La collecte de données e-commerce se divise généralement en deux catégories : la collecte de pages publiques sans connexion et la collecte avec une session authentifiée, par exemple pour consulter des données de back-office de concurrents ou récupérer des résultats affichés après personnalisation.
Pour la première catégorie, maîtriser la fréquence suffit le plus souvent. Dès que la seconde implique plusieurs comptes, la réussite dépend moins de l’ingéniosité du script que de la capacité de ces comptes à exister de façon indépendante. Si cette couche est mal gérée, les limitations et les blocages semblent aléatoires ; modifier le script, réduire la fréquence ou changer de sélecteur n’apporte alors aucune amélioration réelle.
D’où vient le risque
Les plateformes déterminent si plusieurs comptes sont exploités par la même partie en croisant différents signaux : adresses réseau, caractéristiques du navigateur et de l’appareil, données de Cookie et de session, ainsi que les habitudes d’utilisation. Un fort chevauchement dans une seule de ces catégories peut suffire à regrouper les comptes sous le même opérateur.
Il faut ici poser une limite claire. Les mécanismes de détection évoluent en permanence ; compter sur des astuces temporaires pour les contrer produit des gains brefs à un coût élevé. Il n’est donc pas question ici de contourner les contrôles de risque. La question utile est différente : une fois les sources de risque identifiées, quelles variables pouvons-nous contrôler et maintenir stables sur le long terme ? Ce sont elles qui déterminent si plusieurs comptes légitimes risquent de se répercuter les uns sur les autres.
Caractéristiques de l’appareil et du navigateur
L’une des configurations les plus risquées consiste à ouvrir plusieurs fenêtres sur la même machine et à s’y connecter avec des comptes différents. Même après avoir vidé le cache ou utilisé la navigation privée, ces fenêtres partagent toujours le même environnement système et les mêmes données de navigateur. Les caractéristiques restent donc corrélées, et la plateforme voit un même appareil changer d’identité à répétition.
Une approche contrôlable consiste à attribuer un environnement propre à chaque compte : un compte par environnement indépendant, avec empreinte, Cookies et stockage local séparés. L’essentiel est de conserver cet environnement pour le compte, plutôt que d’en générer un nouveau au hasard à chaque démarrage. Les combinaisons aléatoires sont souvent incohérentes : fuseau horaire, langue, résolution et UA peuvent se contredire, ce qui paraît plus anormal qu’une configuration stable.
Au fond, la stabilité vient de la cohérence, pas du hasard.
Sortie réseau
La sortie doit être liée au compte : un environnement, une sortie, avec une région de sortie cohérente avec le profil du compte, le fuseau horaire et la langue. Si plusieurs comptes ont des environnements séparés mais partagent la même sortie, l’isolation mise en place auparavant perd en grande partie son intérêt.
La sortie doit aussi rester relativement stable. Des changements fréquents de région rendent le signal de localisation du compte difficile à expliquer. Lors du choix d’une sortie, les adresses résidentielles ressemblent généralement davantage à un accès utilisateur normal que les adresses de centre de données. Il faut également éviter les adresses déjà massivement utilisées, car elles peuvent faire l’objet d’une surveillance renforcée.
Cookies et sessions
L’état de session constitue à lui seul un dossier d’identité. Si plusieurs comptes partagent les mêmes Cookies ou le même stockage local, cela crée un lien direct entre eux, même si le reste des environnements est parfaitement séparé.
Une session dans un nouvel environnement ne devrait pas non plus être utilisée immédiatement à forte intensité. Il vaut mieux accumuler d’abord un historique de navigation normale, puis augmenter progressivement la charge. Cette règle vaut aussi en dehors de la collecte : le fait qu’un compte dispose ou non d’un historique d’utilisation influence directement le volume d’activité qu’il peut soutenir.
Rythme des requêtes
La densité des requêtes est un signal comportemental. Les scripts présentent souvent une régularité typique : intervalles fixes, ordre de pages fixe et absence totale d’activité en dehors de la collecte. Ajouter des valeurs aléatoires ne suffit pas à corriger cette régularité, car le problème principal se situe dans le volume global.
La variable maîtrisable consiste à maintenir la charge dans une plage raisonnable : décaler les horaires d’exécution entre comptes, éviter que tous fonctionnent à pleine capacité au même moment, laisser des intervalles raisonnables entre les pages et distinguer les tâches de collecte selon leur priorité. La limite est simple : la collecte ne doit pas mettre le service cible sous pression. Toute vitesse obtenue au prix d’une dégradation du service cible n’est pas une optimisation acceptable.
Pourquoi un environnement fixe par compte est plus stable qu’un changement aléatoire
Le changement aléatoire vise à présenter une apparence différente à chaque fois, mais les contrôles d’association vérifient surtout si les signaux restent stables entre les différentes dimensions et s’ils se contredisent. Si un compte sort d’un endroit aujourd’hui et d’un autre demain, avec une combinaison de caractéristiques différente à chaque fois, cette incohérence devient elle-même un signal anormal.
Un environnement fixe suit la logique inverse. Dès l’inscription, le compte conserve une identité stable : environnement fixe, sortie fixe, fuseau horaire et langue cohérents, et historique de session qui s’accumule progressivement. Plus cette cohérence dure, plus l’activité ressemble à celle d’un utilisateur normal. C’est précisément la valeur de la couche d’environnement : une stabilité à long terme, pas des variations spectaculaires.
Cela explique également pourquoi le script de collecte ne devrait pas gérer lui-même les instances du navigateur. Les environnements doivent pouvoir être planifiés indépendamment afin d’attribuer un environnement dédié à chaque compte ; leur état doit être consultable pour détecter les environnements anormaux et les comptes devenus invalides ; ils doivent pouvoir être libérés pour éviter l’accumulation d’instances zombies sur les opérations de longue durée ; enfin, les nouvelles tentatives d’une tâche de collecte nécessitent souvent de changer d’environnement, ce qui n’est possible proprement que si la planification est indépendante. Dans ce type d’architecture, PurpleMark constitue la couche de ressources d’environnement. Le script gère la logique de collecte, tandis que l’identité et les ressources sont confiées à la couche d’environnement.
Limites de conformité
Les points suivants sont plus importants que toutes les optimisations précédentes.
Respectez les conditions d’utilisation et les règles robots du site cible. De nombreuses plateformes e-commerce limitent explicitement l’accès automatisé dans leurs conditions ; vérifiez donc avant de commencer que l’usage envisagé est autorisé. Ne collectez que des informations publiques sur les produits, les prix et les stocks, et ne collectez pas de données personnelles. Ne contournez pas les mesures de protection technique. Face à des protections telles que des CAPTCHA ou des interfaces chiffrées, adaptez la stratégie de collecte ou demandez une autorisation au lieu de chercher à les casser. Maîtrisez la fréquence des requêtes quel que soit le nombre de comptes disponibles et ne perturbez jamais le fonctionnement normal du service cible.
Le principe de cette discussion est de permettre à plusieurs comptes légitimes de rester indépendants sans se gêner, et non de contourner les règles d’une plateforme. Le premier sujet relève de l’hygiène opérationnelle ; le second est d’une autre nature.
