Méthodologie de test
Comment nous testons les proxies : benchmarks hebdomadaires, 4 segments de marché, charge réelle.
Dernière revue de la méthodologie : 5 septembre 2026 · Prochaine revue prévue : Q4 2026
Ce document décrit précisément comment PROXYDECK teste, note et classe les providers proxy. On le publie ouvertement pour que n'importe qui puisse vérifier que notre process est reproductible, équitable et indépendant des relations commerciales.
1. Indépendance et financement
Le site vit grâce aux commissions affiliées — quand un lecteur s'inscrit chez un provider via l'un de nos liens après notre review, on touche un pourcentage du premier paiement. Ça n'entre pas dans le score du catalogue. Le même protocole de test s'applique à tous les providers, partenaires comme non-partenaires.
Le badge Editor's Pick est attribué d'après les résultats des tests, pas selon la taille de la commission. Les providers sans programme affilié peuvent l'obtenir à égalité — et l'obtiennent.
Une place au catalogue est gratuite et n'est pas à vendre. Un fournisseur peut postuler via le formulaire de suggestion, mais postuler n'achète rien : nous testons, et un service qui échoue à la vérification n'est pas publié. Une grande partie du catalogue, nous l'ajoutons de notre propre initiative, sans demander à personne. Les formats payants — placement partenaire, review sponsorisée, landing — existent séparément, sont signalés comme publicité et ne touchent ni au score, ni à la position au classement, ni au badge.
2. Ce qu'on teste
2.1. Métriques de performance
- Success rate — part des réponses HTTP 200 sur un batch de 1000 requêtes contre des cibles benchmark (listings Amazon, Google SERP, page protégée par Cloudflare Bot Fight).
- Latence — round-trip P50 / P95 / P99 mesuré en parallèle depuis 4 marchés (US-East, EU-Frankfurt, UK-London, APAC-Singapore).
- Throughput — connexions concurrentes par port avant dégradation de la success rate.
- Diversité du pool — part d'IPs uniques sur 1000 requêtes consécutives, vérifiée par ASN lookup.
2.2. Couverture géographique
Pour chaque provider on échantillonne 50 IPs aléatoires par pays annoncé et on croise la localisation réelle avec trois sources indépendantes — IPinfo, MaxMind, IP2Location. Si la concordance descend sous 80%, le géo est marqué « mal déclaré », ce qui coûte des points en catégorie géo. Pour les providers résidentiels on logue aussi la part d'ASNs vraiment résidentiels (pas datacenter) — un vrai marqueur d'honnêteté du sourcing.
2.3. Transparence des prix
- Prix landing-page vs. prix réel au checkout (suppléments sticky session, géo-targeting, sub-users).
- Politique de remboursement et son application — vérifiée par une demande de remboursement sur un petit paiement test.
- Possibilité d'acheter sans KYC, prix d'entrée en pay-as-you-go.
2.4. Compliance et tolérance use-case
- Quels use-cases sont bloqués à l'inscription vs. à la vérification.
- Tolérance envers iGaming, affiliate, ad-verification, multi-account.
- Posture GDPR / CCPA — disponibilité DPA, localisation des serveurs, politique de retention publique.
- Crypto et paiements non-carte, rails locaux (Wise, SEPA, AliPay).
2.5. Qualité du support
- Délai de première réponse — questions techniques, billing, demandes de refund.
- Délai de résolution réel sur un problème qu'on plante volontairement (cas typique : mismatch géo-targeting dans un état US précis).
- Présence d'un account manager et seuil de plan auquel il apparaît.
3. Score composite — 7 catégories
Chaque provider reçoit une note de 0 à 10. C'est une somme pondérée sur 7 catégories. Les poids sont ouverts :
| Catégorie | Poids | Contenu |
|---|---|---|
| Success rate | 25% | Part de requêtes réussies sur les cibles benchmark |
| Prix (rapport qualité-prix) | 20% | Coût réel par-GB / par-port après tous les suppléments |
| Taille et diversité du pool | 15% | Pool annoncé vs. mesuré, unicité des IPs |
| Couverture géographique | 15% | Pays couverts et précision du géo-targeting |
| Sticky session | 10% | Stabilité de session et contrôle TTL |
| Paiement | 5% | Crypto, PayPal, rails locaux ; friction KYC |
| Support | 10% | Temps de réponse, time-to-resolution, account manager |
Somme des poids = 100%. La caption de formule sous la note de chaque provider reflète ce tableau — on les garde synchronisés.
4. Environnement de test — 4 marchés, cycle hebdomadaire
Tous les runs tournent sur une infra identique pour éliminer le biais d'environnement réseau :
- Matériel : AWS EC2 t3.medium (2 vCPU, 4 GB RAM), stack PHP identique + Chromium headless.
- 4 marchés de test : US-East (Virginie), EU-Central (Frankfurt), UK (Londres), APAC (Singapour). Couvre les fuseaux horaires principaux et les patterns typiques de divergence de latence.
- Toolchain : runner benchmark maison (release open-source prévu Q4 2026), Chrome DevTools Protocol pour vérifier les JS-fingerprints et le passage Cloudflare.
- Calendrier : perf — hebdo ; deep-dive top-10 — mensuel ; re-test complet du catalogue — trimestriel.
5. Critères Editor's Pick
Le badge va aux providers qui remplissent simultanément toutes les conditions :
- Score composite ≥ 9.0.
- Top-3 dans leur catégorie principale (résidentiel / mobile / datacenter / ISP).
- Aucun scandale de compliance connu et un record KYC propre sur les 12 derniers mois.
- Essai gratuit ou pay-as-you-go avec entrée ≤ 5 $.
- ≥ 6 mois dans le catalogue — pour avoir une tendance, pas un snapshot.
6. Cadence de mise à jour
- Hebdo : métriques de performance (success rate, latence, drop-out).
- Mensuel : changements prix et policy, mises à jour KYC.
- Trimestriel : re-test complet de toutes les catégories du score composite.
- On-demand : quand un provider annonce un changement majeur, qu'un scandale apparaît ou que la propriété change.
7. Conflits d'intérêts et hard disqualifiers
Si un membre de la rédaction a un intérêt financier dans un provider au-delà de la commission affiliate standard (equity, consulting payé), il se récuse de l'évaluation de ce provider. On rend chaque cas public.
Hard disqualifiers — providers qui n'entrent pas au catalogue quelles que soient leurs perfs techniques :
- Liens juridiques avec la Fédération de Russie (fondateurs, siège, infrastructure, acceptation des rails de paiement russes comme méthode principale).
- Origine documentée de botnet pour le pool d'IPs (911.re, RSocks, Faceless et écosystèmes liés).
- Pratique avérée de farm d'IPs via malware ou logiciel trompeur.
8. Corrections et litiges
Si tu vois une erreur factuelle ou veux contester une note :
- Bouton « Signaler une erreur » sur n'importe quelle page de review.
- Email [email protected] avec preuves (screens, logs bruts, liens vers les annonces officielles).
On répond sous 48 heures. Les corrections sont publiées sous 5 jours ouvrés quand les preuves tiennent.
9. Comment un provider entre dans le catalogue
Un provider peut demander son inclusion par mail à [email protected]. On n'accepte aucun paiement pour l'inclusion ou l'ajustement d'une note. Les formats sponsorisés sont clairement étiquetés — détails sur la page À propos.
10. Ce qu'on ne fait pas
La transparence pèse plus que les claims marketing. Donc :
- On ne publie pas de notes sans test réel — les providers qui n'ont pas complété le cycle complet apparaissent dans le catalogue avec
verified=0. - On n'utilise pas de benchmarks synthétiques — chaque run tape sur de vraies cibles publiques.
- On n'accepte pas de paiement pour réécrire les Pros / Cons.
- On ne laisse pas les notes se périmer : si un provider n'a pas été testé depuis plus de 90 jours, un badge d'avertissement « stale data » apparaît sur sa page.
Si tu as une hypothèse sur quel test ou quelle métrique ajouter — le bouton « Proposer un nouveau pattern » plus bas envoie directement dans notre queue éditoriale.
Vous avez votre propre protocole — ou repéré un trou dans le nôtre ?
Écrivez-nous — proposez de nouveaux patterns de test, métriques, edge-cases. Tout ce qui tient passe dans le prochain re-test trimestriel. On publie aussi les idées qu'on écarte, avec la raison.