Source : Oxylabs, Decodo, Webshare sous un même propriétaire

Le 13 octobre 2026, cinq entreprises du secteur de la collecte de données web ont annoncé qu'elles opéraient désormais sous le même toit Source. Cela inclut Oxylabs, Decodo (anciennement Smartproxy), Webshare, ScrapingBee et Honeygain. Pendant des années, de nombreux clients ont choisi parmi ces marques un fournisseur « principal » et un fournisseur « de secours », les considérant comme des concurrents. Maintenant, c'est officiel : il s'agit d'un seul groupe. Voyons ce qui a été unifié, pourquoi cela concerne tous ceux qui maintiennent un pool de proxies de secours, et comment vérifier en une heure que votre fournisseur de secours est réellement indépendant du principal.

Ce qui s'est passé : cinq marques, un propriétaire

Selon Proxyway, Source se décrit comme une « écosystème de données ». La structure principale est basée à Vilnius et, comme le souligne Proxyway, fait partie d'un écosystème plus large, celui de Tesonet. Voici quelques chiffres que le groupe fournit sur lui-même :

plus de 800 employés, dont plus de 350 développeurs et ingénieurs ;
plus de 180 brevets et 215 marques déposées ;
1,5 million de requêtes par seconde dans des systèmes distribués ;
la demande des agents IA et des produits IA a quadruplé au cours de l'année.

Le groupe a grandi à partir d'Oxylabs. En juillet 2026, Oxylabs a levé 130 millions de dollars auprès de Warburg Pincus avec une valorisation de 3,6 milliards de dollars, c'était son premier tour de financement externe. Les liens entre les marques se sont tissés au fil des ans : Webshare a été acquis par Oxylabs en 2022, ScrapingBee en 2025, et Honeygain sert de partenaire principal pour l'acquisition d'IP résidentiels depuis 2021. Le lien entre Decodo et Oxylabs, comme l'écrit Wilson's Media, n'était pas si évident publiquement avant le lancement de Source. Détail révélateur : le directeur général de Source, Vitautas Savickas, a dirigé Decodo jusqu'en mars 2026.

Comment les marques partagent le marché

Oxylabs — grande entreprise et laboratoires IA ;
Decodo — segment intermédiaire ;
ScrapingBee — API pour développeurs ;
Webshare — indépendants avancés et petites équipes ;
Honeygain — application qui paie les gens ordinaires pour le « trafic supplémentaire » de leurs appareils.

Formellement, les marques restent indépendantes : elles ont leurs propres équipes, prix, produits et clients. Source déclare qu'elle ne vend rien elle-même, mais centralise les brevets, les achats, le recrutement et la conformité. Que les pools d'IP ou l'infrastructure soient communs aux marques, ni Source ni les publications spécialisées ne le précisent. Mais pour l'acheteur, c'est la question principale.

Pourquoi cela concerne votre pool de secours

Un pool de secours de proxies est nécessaire au cas où le principal cesse de fonctionner : le site cible a bloqué les sous-réseaux du fournisseur, le fournisseur a un problème, les conditions ou les prix ont changé. Nous avons détaillé les scénarios et l'architecture des réserves dans notre analyse quand les pools de proxies de secours sauvent réellement des comptes. La règle principale est simple : la réserve doit provenir d'un autre fournisseur et idéalement d'autres sources d'IP.

L'unification sous un même propriétaire rend cette règle plus complexe qu'il n'y paraît. Il existe trois niveaux de dépendance, et la marque sur le site ne reflète que le premier :

Juridique. Qui possède l'entreprise et dont les décisions déterminent les prix, les règles et le sort du service.
Source IP. D'où proviennent les adresses résidentielles : application propre ou SDK, programme partenaire comme Honeygain, achat en gros auprès d'un autre fournisseur.
Infrastructure. Les passerelles par lesquelles passe le trafic, leur hébergement et leurs réseaux.

Deux fournisseurs « différents » peuvent coïncider à n'importe quel niveau. Si la source IP coïncide, l'anti-bot du site cible, ayant appris à reconnaître ces adresses, bloquera les deux pools en même temps, et la réserve sera inutile au moment même où elle a été achetée.

Les coïncidences de pools peuvent se produire même sans propriétaire commun

Il est important de ne pas transformer cette nouvelle en théorie du complot. Le chevauchement d'IP se rencontre également chez des entreprises qui ne sont pas liées : le marché des proxies résidentiels est structuré de manière multi-niveaux, et de nombreuses marques revendent des adresses de grands réseaux en gros, tandis que ces réseaux achètent du trafic via les mêmes applications et SDK. Par conséquent, il est nécessaire de vérifier non seulement « qui est le propriétaire », mais aussi « d'où viennent les adresses » et « se croisent-elles dans la pratique ».

Comment vérifier que le fournisseur de secours est indépendant : 5 étapes

La vérification prend environ une heure et coûte quelques centaines de mégaoctets de trafic. Faites-le avant que la réserve ne soit nécessaire.

Étape 1. Entité juridique et propriétaire

Ouvrez les conditions d'utilisation (Terms of Service) et la politique de confidentialité des deux fournisseurs : y sont indiqués l'entité juridique, le pays d'enregistrement et l'adresse. Ensuite, consultez le registre des entreprises de ce pays et la section « À propos de nous » ou les communiqués de presse. Une adresse coïncidente, des directeurs identiques ou une mention d'un groupe commun sont des raisons de considérer les fournisseurs comme un seul fournisseur. Il est également utile de vérifier le descripteur de paiement dans l'extrait : il mentionne souvent l'entité juridique réelle, et non la marque.

Étape 2. Source des IP résidentielles

Demandez directement au support : « Comment obtenez-vous des IP résidentielles ? Application propre, SDK dans des applications tierces, partenaires ou achat en gros ? » Un fournisseur normal répondra au moins en termes généraux. Si les deux mentionnent le même programme de monétisation du trafic ou évitent de répondre, considérez que la source est commune. La question n'est pas triviale du point de vue de la sécurité : le 16 octobre, GBHackers, citant GreyNoise, a décrit une campagne dans laquelle des attaquants, via des vulnérabilités dans des NAS D-Link, des caméras de surveillance et SAP NetWeaver, installaient secrètement sur des appareils étrangers l'application légale Pawns.app et les transformaient en nœuds résidentiels commerciaux. Au moins 143 appareils dans 34 pays ont été touchés. IPRoyal désigne Pawns.app comme son partenaire direct pour l'acquisition d'IP résidentielles ; cependant, comme le souligne la publication, il n'y a pas de données indiquant que la campagne a été dirigée par l'un des fournisseurs. Conclusion pour l'acheteur : la transparence de l'origine des IP est également une question de la propreté des adresses que vous obtenez.

Étape 3. Chevauchement des IP sortantes

C'est le principal test technique. Prenez la rotation des deux fournisseurs dans le même pays et effectuez entre 500 et 1000 requêtes à un service qui renvoie votre IP. Conservez les listes et comparez :

coïncidence des IP exactes — signe direct d'un pool commun ;
coïncidence des sous-réseaux /24 — signe d'une source commune ou d'opérateurs communs ;
répartition par ASN — si les mêmes réseaux d'opérateurs dominent dans les deux listes dans des proportions similaires, les sources sont probablement proches.

Un script minimal en Python :

import requests

def collect(proxy_url, n=500):
    ips = set()
    for _ in range(n):
        try:
            r = requests.get("https://api.ipify.org",
                             proxies={"http": proxy_url, "https": proxy_url},
                             timeout=15)
            ips.add(r.text.strip())
        except requests.RequestException:
            pass
    return ips

a = collect("http://login:[email protected]:port")
b = collect("http://login:[email protected]:port")
net24 = lambda s: {".".join(ip.split(".")[:3]) for ip in s}

print("IP uniques :", len(a), len(b))
print("IP communes :", len(a & b))
print("Communes /24 :", len(net24(a) & net24(b)))

Les ASN pour les adresses obtenues peuvent être déterminés par n'importe quel service de géolocalisation IP ou une base de données locale. Comment interpréter correctement le nombre d'adresses uniques dans l'échantillon a été discuté dans notre article comment vérifier la taille réelle d'un pool de proxies avec 1000 requêtes. Règle courte : quelques pourcents d'IP communes /24 dans un grand pool sont un fond normal pour un seul pays, tandis que des dizaines de pourcents d'IP exactes communes représentent en fait un seul pool.

Étape 4. Passerelles et infrastructure

Vérifiez où se résolvent les hôtes des passerelles des deux fournisseurs (commandes dig ou nslookup) et à quels réseaux appartiennent ces adresses. Un même hébergement ne prouve rien, mais une plage d'adresses de passerelles commune, des schémas de ports identiques et un format de connexion similaire, des réponses similaires aux erreurs d'autorisation — sont déjà des signaux qu'une seule plateforme pourrait se cacher derrière différentes enseignes. Dans ce cas, une panne de la passerelle affectera les deux services simultanément.

Étape 5. Test de bannissement commun

La vérification la plus pratique. Prenez un site cible où le fournisseur principal rencontre déjà des captchas ou des blocages, et exécutez le même scénario via la réserve avec les mêmes en-têtes et le même profil de navigateur. Si la réserve est bloquée avec la même fréquence et aux mêmes étapes, pour ce site, elle n'est pas une réserve, même si les propriétaires sont différents. Répétez le test une fois par mois : les pools changent.

Quel type de réserve choisir pour différentes tâches

Extraction et surveillance des prix. L'indépendance de la source IP et des passerelles est primordiale. Un schéma raisonnable serait de disposer d'une réserve d'un autre type : si le pool principal est constitué de proxies résidentiels, la réserve pour des objectifs peu exigeants peut être constituée de proxies de centres de données, et vice versa.
Multi-comptes et réseaux sociaux. Ici, la réserve doit correspondre au type du principal, sinon la plateforme verra un changement de « profil » réseau. Pour les scénarios mobiles, il est logique de maintenir une réserve sur des proxies mobiles avec des opérateurs qui ne figurent pas dans le pool principal.
Tâches critiques avec SLA. Maintenez deux fournisseurs avec des propriétaires différents et des origines IP différentes et vérifiez le chevauchement selon les étapes 3 et 5 au moins une fois par trimestre.

Ce que l'unification change encore

La consolidation a aussi un autre aspect. Le groupe déclare qu'une voix commune est nécessaire pour protéger « l'accès responsable aux données web publiques », et Wilson's Media rappelle qu'Oxylabs reste défendeur dans le procès intenté par Reddit en octobre 2025, conjointement avec SerpApi, Perplexity et AWMProxy. Pour le client, cela signifie une chose simple : les risques juridiques et réputationnels d'une marque concernent désormais potentiellement l'ensemble du groupe. Les décisions concernant les règles d'utilisation, les prix et les objectifs acceptables peuvent également commencer à être harmonisées.

Cependant, les marques continuent d'être vendues comme des services distincts, et rien n'empêche d'utiliser l'une d'entre elles. Une seule chose change : il n'est plus judicieux de choisir deux d'entre elles comme « principal et de secours » sans vérification.

Conclusion

Le lancement de Source est une bonne occasion de revoir le schéma de réservation. Le nom de la marque ne dit rien sur l'indépendance du fournisseur : ce qui compte, c'est le propriétaire, la source IP et l'infrastructure. Vérifiez les entités juridiques, demandez l'origine des adresses, comparez les IP sortantes et les sous-réseaux, et effectuez un test commun de bannissement. Si le chevauchement est important, vous n'avez pas deux fournisseurs, mais un seul avec deux comptes. Mieux vaut le savoir maintenant que le jour où le pool principal s'effondrera.