Tarification des proxys par requête

Ce que vous payez

Vous payez le nombre de requêtes comptabilisées par le fournisseur. Celui-ci peut vendre des forfaits fixes ou facturer à mesure de l’utilisation. Les prix sont souvent indiqués pour mille ou un million de requêtes. Cela facilite la comparaison des tarifs, mais ne dit pas combien vous devrez dépenser lors de l’achat : le plus petit forfait peut contenir davantage de requêtes.

Le même mot, « requête », peut désigner des services différents. Un proxy ordinaire transmet les requêtes de votre application aux sites et renvoie leurs réponses. Votre application charge les pages et extrait les données. Avec une API de collecte de données, le prix peut aussi inclure l’exécution d’un navigateur, la gestion des restrictions d’accès et la préparation des résultats. Comparer uniquement le prix des requêtes ne suffit donc pas ; vous devez savoir ce que le service fait pour ce prix.

Cette tarification est pratique pour un travail qui suit un calendrier. Vous savez peut-être déjà combien de pages vérifier et à quelle fréquence. Déterminez ensuite le nombre de requêtes utilisées par chaque vérification. Vous pouvez alors estimer le forfait nécessaire pour un mois et la croissance de l’utilisation si vous ajoutez des pages.

La taille de la réponse n’influence pas nécessairement le prix. Si le tarif facture le même montant pour chaque requête, récupérer davantage de données dans une réponse peut coûter autant que récupérer une petite réponse. Vérifiez toutefois ce que comprend le tarif : il peut exister des limites de bande passante, de taille de réponse ou de durée d’exécution. Un traitement de données supplémentaire peut aussi être facturé séparément.

Un forfait de requêtes ne détermine pas le nombre d’adresses IP reçues. Un service rotatif, par exemple, peut donner accès à un pool d’IP par un point de connexion commun. Les changements d’IP et la conservation d’une adresse pour une session dépendent des réglages du service. Un changement d’IP ne dit pas, à lui seul, combien de requêtes seront facturées.

Ce que le service compte comme une requête

Commencez par distinguer une requête d’une connexion. Une requête HTTP demande à un site d’effectuer une action, comme renvoyer une page ou fournir des données. Le site envoie une réponse. Le fait que les données circulent dans les deux sens ne signifie pas, à lui seul, que deux requêtes doivent être décomptées. Cela nécessiterait une règle de facturation distincte.

Une connexion est le canal par lequel l’application communique avec le serveur. Plusieurs requêtes peuvent utiliser la même connexion. HTTP/1.1 permet de réutiliser une connexion, tandis que HTTP/2 permet d’y mener plusieurs échanges à la fois. Le nombre de requêtes, les connexions ouvertes et les connexions actives au même moment sont donc des mesures différentes.

HTTPS ajoute un autre détail. Lors d’une connexion par un proxy HTTP, l’application envoie couramment une commande CONNECT pour créer un tunnel vers le site. Les requêtes suivantes circulent dans ce tunnel sous forme chiffrée. Le proxy transmet les données, mais ne peut pas, en utilisation ordinaire, lire les requêtes HTTP individuelles. Un proxy SOCKS fournit lui aussi une connexion à la destination ; chaque action de l’application ne nécessite pas forcément une nouvelle connexion.

C’est pourquoi certains services utilisent « requête » pour désigner une connexion ou un autre événement que leur serveur proxy peut compter. D’autres comptent les requêtes HTTP individuelles ou les appels à une API. Le nombre de requêtes dans les outils de développement du navigateur peut donc différer de l’utilisation affichée dans le tableau de bord du fournisseur. La prise en charge de HTTP, HTTPS ou SOCKS5 ne détermine pas, à elle seule, la règle de comptage.

Avant d’acheter un gros forfait, effectuez un petit test. Notez le nombre de tâches achevées par l’application et le nombre de requêtes décomptées par le service. Utilisez la même application, le même protocole et les mêmes réglages que ceux prévus ensuite. Un test avec un simple client HTTP ne montrera pas l’utilisation d’un navigateur qui charge aussi des scripts et d’autres ressources de la page.

Pourquoi une page peut utiliser plusieurs requêtes

Ouvrir une page nécessite souvent davantage que son document principal. Le navigateur charge séparément les styles, les scripts, les images et les données. Une page ouverte peut continuer à contacter le serveur pour des mises à jour. Certaines de ces requêtes passent aussi par le proxy, selon les réglages de l’application. Leur facturation dépend du tarif.

Suivre une redirection ajoute une requête. Si le site répond qu’une page se trouve à une autre adresse, une application configurée pour suivre la redirection envoie une autre requête HTTP à cette adresse. Récupérer un document avec un simple client et ouvrir la page complète dans un navigateur peuvent donc utiliser des nombres de requêtes différents. Le nombre d’URL de votre liste ne dit pas encore combien de requêtes leur traitement nécessitera.

Une API peut fonctionner à l’inverse : une requête peut récupérer de nombreux enregistrements. Dans cet exemple, un navigateur effectue cinq requêtes pour charger la page d’un casque audio avec son prix. Une application utilise le même proxy pour appeler l’API de catalogue de ce commerçant et récupère cinq prix de produits en une requête. Il s’agit de l’API du commerçant, qui fournit les données produit. Si elle renvoie le catalogue par pages, chaque page nécessite une autre requête. Vous pouvez parfois augmenter le nombre de produits par réponse, à condition que l’API prenne en charge ce réglage et renvoie toutes les données nécessaires.

Cette approche aide à tirer davantage de travail utile d’un forfait. Recharger des pages complètes, récupérer des données déjà enregistrées et vérifier les prix plus souvent que nécessaire peuvent épuiser rapidement le quota. Récupérer plusieurs produits par appel, enregistrer les résultats et choisir une fréquence de vérification adaptée réduisent le nombre de requêtes nécessaire à la même tâche. À charge égale, le quota peut durer plus longtemps pendant la validité du forfait ; vous pouvez aussi l’utiliser pour vérifier davantage de produits.

Il est utile de mesurer l’utilisation par tâche achevée. Il peut s’agir de vérifier une page, de récupérer une liste complète ou de contrôler un élément qui apparaît après l’exécution de scripts. Mesurez toute la séquence nécessaire pour obtenir ce résultat. Cela inclut les chargements de pages supplémentaires, faciles à manquer si l’on compte seulement les URL de départ.

Les cas où ce modèle tarifaire est utile

Surveillance planifiée

L’utilisation des requêtes peut être liée à des vérifications régulières. Une application peut surveiller la disponibilité de pages, les modifications d’annonces publiques ou les résultats de recherche pour une région requise. Vous connaissez à l’avance le nombre de cibles et la fréquence des vérifications. Un test montre combien de requêtes chaque vérification utilise et aide à estimer la consommation mensuelle.

Les différentes pages ne doivent pas forcément être vérifiées aussi souvent. Si l’information change une fois par jour, une vérification chaque minute renverra généralement les mêmes données. Les vérifications plus fréquentes peuvent être réservées aux pages où il est important de détecter rapidement un changement. Le forfait reste ainsi disponible pour les observations nécessaires.

Collecte de données par les API et les annuaires

L’utilisation dépend ici de la façon dont le site fournit ses informations. Si la liste contient déjà tout ce dont vous avez besoin, il n’y a aucune raison d’ouvrir chaque page de détail. Les requêtes supplémentaires peuvent être réservées aux éléments dont les données manquent ou aux enregistrements modifiés depuis la précédente exécution. Plus vous récupérez de données nécessaires dans un appel, moins la collecte complète demande de requêtes.

Vous devez aussi tenir compte de ce que fait le service. Une API de recherche peut renvoyer des résultats analysés, tandis qu’un proxy ordinaire laisse le téléchargement et le traitement à votre application. Ce sont des quantités de travail différentes. Lorsque vous comparez les prix, vérifiez le contenu de la réponse et ce qu’il vous reste à faire vous-même.

Audits de sites et vérifications dans le navigateur

Un audit technique suit souvent une séquence claire : ouvrir une adresse, vérifier la réponse, suivre une redirection si nécessaire et enregistrer le constat. Si la plupart des adresses sont traitées de façon similaire, un test facilite l’estimation de l’utilisation. Une vérification dans un navigateur peut nécessiter davantage de requêtes parce qu’elle dépend de scripts, d’images et d’éléments de page fonctionnels.

Choisissez la méthode de vérification selon son objectif. Un simple client suffit souvent pour voir si une page répond. Tester un formulaire de commande nécessite de charger ce dont il a besoin pour fonctionner. Désactiver les fichiers requis réduit les requêtes, mais le test ne montre alors plus l’expérience de l’utilisateur.

L’effet des erreurs et des nouvelles tentatives sur l’utilisation

Une requête envoyée ne renvoie pas toujours les données nécessaires. Un site peut renvoyer une erreur, une vérification d’accès ou une autre page. Même HTTP 200 ne garantit pas que l’application a reçu ce qu’elle voulait : le code indique un succès au niveau HTTP, tandis que le contenu de la réponse doit être vérifié séparément.

Les règles de facturation de ces requêtes varient. Certains services comptent les requêtes envoyées. D’autres ne facturent que les réponses qui répondent à leur définition d’un résultat obtenu avec succès. Une API gérée peut inclure plusieurs tentatives internes de récupération des données dans le prix d’une réponse. Des modes ou des fonctionnalités supplémentaires changent parfois les règles de facturation. « Payer par requête » ne signifie donc pas automatiquement « payer uniquement les données récupérées ».

Une nouvelle tentative de votre application diffère d’une nouvelle tentative à l’intérieur du service. Lorsque l’application renvoie la requête, elle en crée une nouvelle. Lorsque le service réessaie un travail déjà soumis, ces tentatives peuvent être comprises dans son prix. Déterminez quelles tentatives sont décomptées de votre forfait.

Pendant un test, consignez trois nombres : les tâches démarrées, les requêtes facturées et les tâches achevées. L’achèvement dépend de l’objectif. Pour la collecte de données, la réponse doit contenir les champs requis et des informations suffisamment récentes. Pour la surveillance de disponibilité, détecter correctement un site indisponible constitue aussi une vérification achevée.

Ces nombres aident à montrer le coût réel du travail. Des requêtes peu chères peuvent être peu avantageuses si les réponses nécessitent constamment une nouvelle tentative ou doivent être écartées. Un service plus cher peut faire une partie du travail pour vous. Comparez la dépense nécessaire pour obtenir le résultat requis, en tenant compte du travail laissé à votre application.

Comment calculer le forfait nécessaire

Comptez d’abord le travail prévu : combien de cibles doivent être traitées et à quelle fréquence. Ajoutez ensuite les requêtes nécessaires au-delà de la récupération habituelle, comme les nouvelles tentatives observées pendant les tests. Calculez séparément les différents groupes de pages si leur comportement diffère. Gardez aussi séparée une réserve pour la croissance de la charge, afin de ne pas ajouter deux fois les mêmes requêtes supplémentaires.

Prenons un exemple illustratif. Une application vérifie 150 URL toutes les 30 minutes pendant 30 jours. Supposons qu’une vérification normale utilise une requête selon le tarif choisi et que les tentatives supplémentaires augmentent l’utilisation de 5 %. Tous les chiffres et les prix de cet exemple sont hypothétiques ; il ne s’agit ni de résultats de tests d’un fournisseur ni d’un tarif ProxyCompass.

Le forfait choisi laisse une réserve de 23 200 requêtes. Elle peut couvrir la croissance de la charge tant que le forfait reste valide. Les nouvelles tentatives attendues sont déjà incluses dans les 10 800 tentatives supplémentaires ; cette réserve ne doit pas être comptée une nouvelle fois comme une consommation pour ces mêmes tentatives.

Supposons que le forfait coûte 10 $. Il contient 250 milliers de requêtes, soit un prix nominal de 0,04 $ pour mille. Vous payez 10 $ pour l’ensemble du forfait. Multiplier l’utilisation attendue de 226 800 requêtes par ce tarif donne 9,072 $. C’est la valeur de la partie utilisée, pas le montant de l’achat : le forfait fixe a tout de même coûté 10 $.

Supposons maintenant qu’après les tentatives supplémentaires, l’application achève les 216 000 vérifications planifiées. Mille vérifications achevées coûtent environ 0,0463 $ : 10 $ ÷ 216 000 × 1 000. Ce montant tient compte des requêtes supplémentaires et de la réserve achetée. Si moins de vérifications sont achevées, divisez la dépense par leur nombre réel.

Le calcul fonctionne de la même manière pour les autres tâches. Avec une facturation à l’utilisation, multipliez les requêtes facturables par le tarif, en tenant compte du nombre de requêtes couvert par ce tarif. Avec un forfait, utilisez son prix d’achat complet. Divisez ensuite la dépense par le nombre de tâches achevées. Si plusieurs projets partagent un forfait, décidez comment répartir son coût entre eux.

Vérifiez aussi si l’application peut finir le travail à temps. Notre exemple nécessite 7 200 vérifications par jour, soit en moyenne cinq démarrages par minute. Vous pourriez lancer les 150 vérifications ensemble toutes les demi-heures ou les répartir sur l’intervalle. La consommation du forfait serait identique si chaque vérification nécessitait le nombre de tentatives supposé, mais la charge au lancement différerait. Une limite de connexions ou de débit de requêtes peut empêcher le premier calendrier de fonctionner comme prévu.

Comment réduire les requêtes inutiles

Supprimez les adresses en double et enregistrez les résultats à mesure de la progression. Après un échec, l’application doit reprendre là où elle s’est arrêtée. Si elle relance toute la liste à chaque fois, les pages déjà traitées consomment de nouveau le forfait. Gardez une trace des tâches achevées et de celles qui restent à traiter.

Utilisez la méthode de chargement nécessaire à la récupération des données. Si le texte requis figure déjà dans la réponse du serveur, exécuter un navigateur peut être inutile. Si les données n’apparaissent qu’après l’exécution de scripts, un simple téléchargement peut ne pas suffire. Avec les services de collecte de données, le mode navigateur et les fonctions supplémentaires utilisent parfois davantage de crédits ou un autre tarif. Un crédit ne correspond donc pas toujours à une requête.

Réduire la taille de la réponse n’économise pas toujours des requêtes. Si le fournisseur compte les appels HTTP, une réponse courte peut utiliser autant de requêtes qu’une longue. Pour réduire le nombre, vous pouvez vérifier moins souvent les données inchangées, réutiliser un résultat enregistré ou récupérer plusieurs enregistrements dans un appel d’API. Les informations doivent toujours être assez récentes pour votre tâche.

Limitez les nouvelles tentatives et examinez la cause de l’échec de la requête. Si un site est temporairement indisponible ou vous demande de ralentir, une nouvelle tentative immédiate peut renvoyer la même réponse et consommer une autre requête. Faire une pause ou réduire la fréquence peut être plus utile. Soyez particulièrement attentif aux actions qui créent ou modifient des données : vérifiez le résultat de la première tentative avant de la soumettre de nouveau. Une réponse perdue ne signifie pas que le serveur n’a rien fait.

Après des modifications, vérifiez les résultats ainsi que l’utilisation. Le nombre de requêtes peut avoir baissé parce que l’application a cessé d’effectuer une partie du travail. Une réduction est utile lorsque vous obtenez toujours les données requises, avec la même exhaustivité et la même actualité, en utilisant moins de requêtes.

Ce qu’il faut vérifier pour choisir un tarif

Assurez-vous d’abord que le service fonctionne avec vos sites et votre application. Le type de proxy, les pays disponibles, le comportement des sessions et l’accès aux pages requises par les IP fournies comptent tous. Comparez ensuite le travail inclus : qui charge la page, exécute le navigateur, extrait les données et répète les tentatives échouées ? Cela aide à comprendre pourquoi deux services facturent des prix différents par requête.

Vérifiez la durée de validité du forfait, les règles de recharge et le traitement des requêtes inutilisées. Un gros forfait au prix par requête plus bas est avantageux si vous pouvez l’utiliser à temps pour le travail nécessaire. Si certaines requêtes achetées restent inutilisées, le coût par tâche achevée peut être supérieur à celui d’un plus petit forfait.

Pour comparer, choisissez des pages typiques de votre projet, y compris celles qui posent habituellement problème. Notez le temps passé, les requêtes utilisées, les résultats obtenus et les réglages de l’application. Ce test indiquera la taille du forfait nécessaire, le coût approximatif du travail et la possibilité de le terminer à temps.