Lorsque les proxies résidentiels sont apparus comme produit commercial vers 2012, le modèle de tarification dominant était le “port” ou “canal”. On achetait une offre qui donnait accès à, disons, 100 ports. Chaque port représentait une connexion simultanée unique. Si l’on avait besoin de plus de simultanéité, on souscrivait à une offre supérieure.
Ce modèle a correspondu au marché pendant un temps. Il reflétait la façon dont les clients pensaient la montée en charge à l’époque. Il rendait les factures prévisibles. Il a fonctionné suffisamment bien pour que la majeure partie du secteur le conserve jusqu’au milieu des années 2010.
Il a aussi cessé d’avoir du sens, progressivement, puis brutalement.
Pourquoi les ports avaient du sens au départ
Les premiers cas d’usage des proxies résidentiels étaient limités. Bots pour les sneakers, bots de billetterie, scrapers de niche. Des charges de travail où l’on faisait tourner un nombre connu de sessions parallèles et où chaque session devait paraître distincte. Une offre basée sur les ports correspondait directement à ce modèle mental : un port, une session, un comportement prévisible.
Les réseaux de proxies eux-mêmes étaient de petite taille. Des pools de quelques centaines de milliers d’adresses IP, concentrées pour la plupart dans une poignée de pays. Les opérateurs ne pouvaient pas réalistement prendre en charge une simultanéité illimitée, ils exposaient donc la simultanéité comme un axe facturable.
Et les ports étaient économiquement défendables. Un client avec 100 ports représentait une taille significativement différente d’un client avec 10. La tarification reflétait l’échelle apparente du client.
Pourquoi les ports ont montré leurs limites
Trois choses se sont produites, à peu près en parallèle, qui ont fait des offres basées sur les ports une mauvaise primitive :
Les pools ont grandi d’un ordre de grandeur. Le marché des proxies résidentiels s’est consolidé et a pris de l’ampleur. Les principaux fournisseurs sont passés de quelques centaines de milliers d’adresses IP à plus de 100 millions. La simultanéité a cessé d’être une contrainte significative au niveau du réseau. Un client demandant 1 000 connexions simultanées ne demandait rien que le réseau ne puisse livrer sans effort.
Les charges de travail ont divergé du modèle mental des ports. La collecte de données moderne n’est pas 100 scrapers parallèles tournant régulièrement pendant un mois. C’est un déploiement en rafale : mille requêtes à 9h le lundi pour une actualisation des prix, puis un trafic quasi nul jusqu’au lundi suivant. Ou c’est un scraping déclenché par un événement : un webhook se déclenche, on a besoin de 50 requêtes simultanées pendant 90 secondes, puis retour à zéro. Les allocations de ports statiques s’adaptaient mal à l’une ou l’autre de ces configurations. On surprovisionnait (en payant pour une capacité inutilisée) ou on se retrouvait limité.
Les clients ont cessé de vouloir y penser. La vraie question qui intéresse les acheteurs est “quelle quantité de données puis-je faire transiter par ce service ?”. La bande passante est l’unité naturelle. Elle s’adapte à la charge de travail. Elle correspond à des factures qui ressemblent à celles d’AWS : un coût unitaire prévisible, un coût total déterminé par l’usage réel.
La transition
Le passage à la facturation à la bande passante a pris environ cinq ans à la majeure partie du marché des proxies résidentiels (2019-2024). Non pas parce que quiconque le cachait. Pure inertie : les grands clients avaient des contrats pluriannuels sur des offres à ports, les plans de migration étaient pénibles à rédiger, et la plupart des fournisseurs voulaient maintenir les deux modèles suffisamment longtemps pour offrir une sortie aux acheteurs historiques.
En 2024, chaque réseau résidentiel sérieux du secteur proposait la facturation à la bande passante comme option par défaut. Shifter inclus. Nous avons conservé les offres à ports historiques pour les clients qui avaient construit leur infrastructure autour d’elles - cet engagement envers l’existant reste valable - mais tout ce qui est nouveau est facturé à la bande passante.
Ce que la facturation à la bande passante change concrètement
Plusieurs choses deviennent plus simples, et une devient plus difficile.
Plus simple : l’achat. “J’ai besoin de scraper environ 200 Go de pages par mois” est une phrase qu’un client peut écrire avant même d’avoir rien construit. “J’ai besoin de 80 ports” est une phrase qui nécessite d’avoir fait tourner la charge de travail au préalable pour le savoir.
Plus simple : la prévision. La bande passante évolue linéairement avec les données que l’on déplace. Doubler la fréquence de scraping double la bande passante. La tripler, on la triple. Pas de seuils brutaux, pas de goulots d’étranglement de simultanéité aux pics.
Plus simple : la facturation. Un seul chiffre sur la facture. Plus de “vous avez utilisé 110 % de votre simultanéité mais seulement 40 % de votre trafic, voici le calcul.” Les clients savent ce qu’ils paient.
Plus difficile : la rigueur. La bande passante est un robinet ouvert. Un scraper mal configuré qui télécharge l’intégralité des ressources d’une page alors qu’il n’avait besoin que du corps HTML peut quadrupler la bande passante sans produire aucune donnée utile supplémentaire. Avec des ports, ce scraper aurait heurté le plafond de simultanéité et l’opérateur s’en serait aperçu. Avec la bande passante, il fait simplement grimper la facture jusqu’à ce que quelqu’un audite les sorties.
La parade consiste à être rigoureux sur la forme des requêtes. Ne pas récupérer les images quand on veut seulement des données produit. Utiliser Accept-Encoding: gzip (la plupart des clients le font par défaut, mais cela vaut la peine de vérifier). Supprimer les paramètres de requête qui déclenchent des bundles de ressources. Effectuer un HEAD avant un GET si l’on a seulement besoin des codes de réponse.
Où va le secteur à partir de là
La facturation à la bande passante a gagné le marché résidentiel. Le prochain axe de différenciation n’est plus le modèle de tarification, mais ce qui est inclus, quelles fonctionnalités sont gratuites, et ce qui est comptabilisé dans le compteur de bande passante.
Quelques exemples de différenciation des fournisseurs en 2026 :
Tarification des sessions persistantes. Certains fournisseurs facturent la bande passante des sessions persistantes à un tarif premium. Nous ne le faisons pas : les sessions persistantes sont facturées au même tarif que la rotation par requête.
Le ciblage géographique comme fonctionnalité. Certains fournisseurs proposent le ciblage au niveau de la ville ou de l’ASN comme une option payante. Nous ne le faisons pas : toute la précision géographique est incluse dans chaque offre.
Plafonds de simultanéité. Certains fournisseurs imposent encore des limites de simultanéité en plus des quotas de bande passante. Nous ne le faisons pas : connexions simultanées illimitées sur chaque offre.
API et tableau de bord. Maintenant que la bande passante est le compteur, les clients veulent de la visibilité. Combien de Go par endpoint, par zone géographique, par session, avec une granularité horaire. C’est désormais le minimum attendu, pas une fonctionnalité premium.
Pour les acheteurs, la leçon est la même que pour toute catégorie d’infrastructure : lire les petits caractères sur ce qui est facturé et ce qui est inclus. Le tarif affiché par Go ne signifie rien si la moitié des fonctionnalités que l’on utilisera réellement déclenchent des suppléments.
Perspectives
La facturation à la bande passante n’est pas la forme définitive. À mesure que les charges de travail continuent d’évoluer vers des agents IA qui effectuent un petit nombre de requêtes à forte valeur plutôt que des scrapers qui se déploient sur des millions de requêtes à faible valeur, des modèles de tarification au niveau de la requête ou du taux de succès réapparaîtront probablement pour des secteurs spécifiques.
Pour l’instant, cependant, la bande passante s’est imposée comme la bonne unité. L’ère du port a rempli son rôle, et elle est révolue.