Politiques d’utilisation acceptable

Scraping : que change une page nécessitant une connexion ?

Supposons qu’une entreprise collecte des prix sur le site web d’un fournisseur. Certains prix sont visibles par tous ; les prix de gros apparaissent après la connexion de l’entreprise à son compte client. Pour l’entreprise, il s’agit d’un seul projet de suivi des prix. Pour une AUP limitée aux données publiques, les deux parties se trouvent de part et d’autre de la limite d’utilisation autorisée : les identifiants valides du client ne suppriment pas la restriction du fournisseur.

Une politique autorisant l’accès aux données non publiques avec permission conduit à une évaluation différente. La question pertinente devient alors de savoir si le client a l’autorisation d’effectuer la collecte elle-même. L’autorisation de consulter une page de compte, celle d’en exporter le contenu et celle de redistribuer les données obtenues sont des questions distinctes. Un abonnement permettant à un employé de lire des contenus n’autorise pas nécessairement un programme à les copier et à les revendre.

D’autres clauses portent sur le déroulement de la collecte. Des AUP publiées exigent expressément le respect des instructions robots.txt de la cible, des limites d’API et des limites techniques du débit de requêtes. Selon une telle clause, répartir les requêtes entre de nombreuses IP ne rend pas à lui seul acceptable une collecte interdite. Le client a accepté cette condition en achetant le service de proxys ; cela ne revient pas à affirmer que chaque instruction robots.txt est une loi.

Le contenu des pages compte aussi. Des prix de produits publics et des coordonnées personnelles visibles publiquement sont des données différentes. Les AUP peuvent exiger une base légale pour la collecte de données personnelles et des conditions plus strictes pour les informations médicales, les données d’enfants ou le suivi de personnes identifiables. Les restrictions peuvent aussi couvrir la publication ultérieure ou l’entraînement d’une IA. Le téléchargement réussi d’une page ne règle aucun de ces usages ultérieurs.

L’automatisation s’évalue selon ce qu’elle fait

« Scraper », « bot » et « outil pour les réseaux sociaux » décrivent des logiciels, mais renseignent peu sur leur comportement. La même automatisation du navigateur peut examiner une publicité ou fabriquer un clic rémunéré. Les AUP publiées distinguent les activités suivantes ; la prise en charge de la tâche dans la colonne de gauche n’implique pas l’autorisation de l’action de droite.

La même distinction explique pourquoi une règle anti-spam peut s’appliquer même si les ports de messagerie sont bloqués. Des messages peuvent être envoyés par les formulaires, les commentaires ou l’interface de messagerie privée d’un site web. Fermer un port SMTP empêche une voie d’envoi d’e-mails ; cela n’arrête pas toutes les formes de messages non sollicités.

Les formes d’abus plus directes comprennent les attaques par force brute, qui essaient des mots de passe possibles, et le credential stuffing, qui teste des couples identifiant et mot de passe volés. Les politiques interdisent aussi le phishing, les tests de cartes volées, la diffusion de logiciels malveillants, les attaques DDoS et les contenus illicites, notamment l’exploitation d’enfants et la violation du droit d’auteur. Ces interdictions concernent l’activité elle-même : un petit nombre de tentatives peut enfreindre l’AUP même en ne consommant presque aucun trafic.

Des restrictions qui dépassent les attaques et la fraude

Les AUP contiennent aussi des exclusions commerciales. Des listes réellement publiées comprennent les sondages rémunérés, le commerce d’objets dans les jeux, les domaines liés au streaming, le trading de cryptomonnaies, les jeux d’argent et les contenus pour adultes. Ce sont des exemples tirés des règles de différents services, et non une interdiction commune à tout le secteur. Un fournisseur peut exclure une activité commerciale sans affirmer que toutes ses formes sont criminelles.

La revente est une autre restriction concrète. Vendre à des clients l’accès aux identifiants de proxys loués peut nécessiter un accord distinct ou être interdit par le contrat standard. Une fonctionnalité de sous-utilisateurs dans le tableau de bord ne règle pas la question : des identifiants distincts peuvent être destinés à l’équipe du client. Une agence qui utilise des proxys pour préparer des rapports et une entreprise qui vend l’accès proxy lui-même proposent des services différents.

Certaines conditions protègent le pool de proxys lui-même. Elles interdisent de fournir les informations obtenues sur ses adresses et ses nœuds à des bases de données qui détectent les proxys, évaluent la réputation des IP ou bloquent le trafic. Par exemple, louer un accès pour répertorier les IP utilisées par le fournisseur afin d’atteindre les sites web et les ajouter à une base de détection des proxys peut enfreindre une telle clause, même si aucun site cible n’a été attaqué. La restriction protège la valeur commerciale du réseau.

Ces clauses expliquent pourquoi une AUP ne se réduit pas à une liste d’infractions pénales. Elles peuvent déterminer si un modèle économique licite convient à un service particulier. Passer de la recherche interne à la revente, ou de la collecte de prix publics à la constitution d’un jeu de données sur des personnes, peut changer l’évaluation contractuelle même si le programme et les paramètres proxy restent les mêmes.

Tester votre propre site web peut quand même nécessiter une approbation

Une entreprise engage un prestataire pour rechercher des vulnérabilités sur son site web. Elle peut autoriser le test, mais ne contrôle pas le réseau de proxys du prestataire. Des règles de proxys publiées exigent explicitement le consentement écrit du fournisseur avant une recherche de vulnérabilités ou des tests de résistance et de charge. L’autorisation du propriétaire du site web ne complète donc pas toujours les approbations nécessaires à la tâche.

Le réseau qui transporte le test subit aussi le trafic et les réclamations qui en résultent. Une analyse peut atteindre des systèmes hors de la cible convenue ; un test de charge peut affecter un hébergement partagé ou des services de protection. Lorsqu’un fournisseur autorise ces tests, l’accord sur les cibles, les méthodes et la période identifie le trafic qu’il a accepté de transporter. Une description générale comme « recherche en sécurité » ne définit pas ce périmètre.

Comment une activité par proxy devient un signalement d’abus

Une destination voit l’IP utilisée par le proxy. Si son opérateur constate des attaques sur les mots de passe ou une analyse du réseau, ses premières preuves identifient cette adresse. Le signalement peut être adressé au fournisseur de proxys ou à l’hébergeur qui fournit l’adresse et le serveur. Dans le second cas, le vendeur de proxys reçoit le problème de son propre fournisseur.

La documentation publiée par les hébergeurs montre ce que de telles preuves peuvent contenir. Un enregistrement d’analyse réseau indique l’heure, l’IP source, l’IP de destination et le port de destination. Des connexions répétées depuis une source vers le port 22 de différents serveurs peuvent, par exemple, être signalées comme une analyse de services SSH. Un signalement de saturation par trafic peut plutôt contenir des débits de paquets et une synthèse du trafic par destination. Ces enregistrements décrivent des incidents différents et demandent des explications différentes.

Le fournisseur doit ensuite associer l’événement externe à l’activité d’un client. Avec une adresse dédiée, l’attribution peut aider ; avec des IP de proxys partagés ou rotatifs, l’adresse seule peut être insuffisante. Des clients peuvent utiliser la même IP à des moments différents ou simultanément. L’heure exacte, son fuseau horaire et, lorsqu’ils sont disponibles et pertinents, les ports source aident à distinguer les connexions. Cela dépend des enregistrements réellement détenus par le réseau.

L’heure d’arrivée d’une réclamation diffère aussi de celle de l’activité qu’elle décrit. Une tâche inactive au moment où le support écrit au client peut avoir généré le trafic signalé plus tôt. C’est pourquoi vérifier seulement la liste des processus actuels ou le fonctionnement du proxy à cet instant ne répond pas au signalement.

Ce processus n’exige pas qu’un fournisseur de proxys lise chaque page HTTPS. Avec une connexion TLS ordinaire de bout en bout dans un tunnel proxy, les chemins des pages, les mots de passe soumis et le contenu des réponses sont chiffrés. Une cible peut fournir des preuves de son côté, tandis qu’un fournisseur ou un hébergeur dispose de ses informations réseau. Un navigateur géré ou une API de scraping qui traite réellement les pages a un rôle et une visibilité différents.

Pourquoi une destination peut cesser de fonctionner alors que les autres chargent encore

L’application des règles ne désactive pas toujours un compte. Une procédure publiée de traitement des réclamations permet de restreindre temporairement le seul site web ou hôte nommé dans un signalement. Les autres trafics peuvent continuer. Dans ce cas, un outil de vérification de proxys peut indiquer une connexion fonctionnelle alors que la tâche principale du client ne peut pas atteindre sa destination.

Il existe aussi des règles préventives. Certains services surveillent le débit de requêtes vers les destinations sensibles, comme les pages de connexion bancaires, et appliquent des restrictions supplémentaires lorsque l’activité devient excessive. Une catégorie peut donc être accessible dans le cadre d’un usage normal sans être disponible pour des requêtes automatisées sans restriction. Il s’agit de contrôles des destinations, pas nécessairement d’un quota mensuel de trafic.

L’AUP et l’utilisation équitable peuvent se recouper ici, mais le motif de l’intervention compte toujours. Un outil de collecte de prix peut surcharger une ressource partagée tout en effectuant une tâche autorisée. Des attaques sur les mots de passe peuvent enfreindre l’AUP à un volume bien plus faible. Acheter davantage de trafic ne résout le premier problème que si cela change la capacité concernée ; cela n’autorise pas la seconde activité.

Un hébergeur en amont peut imposer une restriction plus large. Des règles d’hébergement décrivent des blocages d’une IP individuelle, de plusieurs adresses ou d’un serveur entier après des attaques et des analyses. Un vendeur de proxys utilisant cette infrastructure peut devoir résoudre l’incident avec l’hébergeur avant le retour de l’accès. Remplacer une IP de proxy tout en poursuivant la même activité laisse la cause en place.

Il n’existe pas non plus de séquence universelle d’avertissements. Certaines politiques décrivent des tentatives de résolution du problème avec le client tout en réservant la possibilité d’une suspension dès la première infraction. Des systèmes de compte publiés distinguent aussi un signalement d’abus, une violation détectée de l’AUP et un problème de fraude au paiement. Le client doit connaître le motif annoncé et le périmètre de la restriction ; le seul mot « suspendu » ne fournit pas cette information.

Si un prestataire ou un autre utilisateur a envoyé le trafic

Les identifiants proxy peuvent être installés dans plusieurs applications ou confiés à une agence. Les conditions du fournisseur peuvent rendre le titulaire du compte responsable de l’activité effectuée par cet accès. La relation du fournisseur est avec le client qui a acheté le service ; expliquer qu’un prestataire a exécuté le programme ne suffit donc pas à résoudre l’incident.

La tâche pratique consiste à identifier quelle application ou personne utilisait les identifiants à l’heure signalée et à arrêter l’activité concernée. Si l’accès a fuité, les identifiants exposés doivent être révoqués ou modifiés. Des identifiants distincts et des traces des tâches, lorsque le service le permet, peuvent faciliter ce travail. Ils ne créent pas d’exception à l’AUP.

Les restrictions du compte peuvent aussi viser les tentatives de contournement des règles du fournisseur lui-même : ouvrir des comptes de remplacement après une exclusion, demander des essais répétés en violation des conditions annoncées ou éviter la vérification d’identité. Un nouveau compte ou une IP nouvellement attribuée ne transforme pas la même opération interdite en opération approuvée.

Ce qu’il advient du forfait payé et de son solde

Il existe plusieurs conséquences financières possibles, qu’il faut distinguer. L’une est la facturation du travail de traitement d’une réclamation. Une autre est la perte du droit au service inutilisé lorsqu’un contrat est résilié pour violation des règles. Une troisième est l’obligation de couvrir certaines réclamations ou dépenses de tiers causées par le comportement du client. Le montant payé pour le forfait proxy ne limite pas nécessairement toutes ces obligations.

Ce sont des différences contractuelles réelles. Des conditions publiées prévoient la perte des crédits inutilisés après une résiliation pour violation des règles, tout en accordant un traitement différent lorsque le fournisseur met fin au service pour sa propre convenance. Certaines indiquent aussi qu’une suspension pour conformité ne prolonge pas automatiquement l’abonnement ou la validité des crédits. Un compte inactif ne signifie donc pas nécessairement que sa période payée est suspendue.

Les frais de traitement d’une réclamation n’ont pas de montant standard dans tout le secteur. Les payer couvre les frais prévus dans l’accord ; cela n’achète pas l’autorisation de poursuivre une activité interdite et ne garantit pas le rétablissement. Inversement, l’arrivée d’un signalement ne suffit pas à établir toutes les conséquences financières. Les motifs pertinents de restriction ou de résiliation et les dispositions de paiement applicables déterminent le résultat contractuel, sous réserve des droits légaux impératifs.

Que transmettre lorsque le support vous contacte

Le support a besoin d’une réponse sur l’activité décrite dans le signalement. « Le proxy fonctionne », « le forfait est payé » et « nous faisons seulement du scraping » n’identifient pas ce qui a généré les connexions signalées. Une réponse utile relie l’événement à la tâche réelle du client et explique ce qui a été fait.

1. Mettez en pause la tâche concernée et conservez ses paramètres ainsi que les journaux disponibles. Utilisez l’heure de l’activité signalée, avec son fuseau horaire, plutôt que l’heure de réception du message.
2. Identifiez l’application, la tâche planifiée, l’employé ou le prestataire utilisant l’accès. Comparez la destination et l’IP du proxy à vos enregistrements. Demandez les détails manquants par le canal de support du fournisseur.
3. Décrivez la cause et le changement effectué : par exemple, la tâche a été arrêtée, une destination involontaire a été retirée ou un accès exposé a été révoqué. Pour un test convenu auparavant, joignez l’autorisation écrite et son périmètre.
4. Confirmez quelle restriction subsiste et ce que le fournisseur exige avant la reprise du travail autorisé. Évitez de relancer la même opération sur une autre IP tant que la cause n’est pas résolue.

Le fournisseur peut utiliser un ticket, un formulaire du tableau de bord ou une procédure de réponse dédiée. Certains services exposent le texte de la réclamation et son état par une API. Ce sont des moyens de traiter l’incident ; aucun ne fixe un délai universel de rétablissement. Un délai d’examen de la réponse du client diffère aussi d’une promesse de réactivation du service.