L'équipe teste l'application pendant tout un sprint, publie la version — et une semaine plus tard, le support reçoit des plaintes : « dans ma ville, le prix est différent », « la notification push n'est pas arrivée », « je ne peux pas payer par carte ». La raison est presque toujours la même : tous les tests ont été effectués avec une seule IP d'entreprise, tandis que les utilisateurs réels se connectent depuis d'autres régions, réseaux et opérateurs. Dans cet article, nous examinerons 7 scénarios QA spécifiques qui ne peuvent physiquement pas être vérifiés sans changer d'adresse IP, et nous montrerons comment configurer l'infrastructure de test avec un proxy.
Pourquoi l'IP de bureau est une zone aveugle pour le QA
La plupart des applications mobiles aujourd'hui prennent des décisions basées sur l'adresse IP : elles déterminent le pays de l'utilisateur, la langue de l'interface, la devise, les méthodes de paiement disponibles, l'ensemble des fonctionnalités et même le prix de l'abonnement. Lorsque tout le département QA teste depuis un seul bureau avec une seule IP statique d'un centre de données ou d'un réseau d'entreprise, l'application reçoit toujours la même réponse du backend — comme si tous les testeurs se trouvaient au même endroit dans le monde.
En conséquence, les bogues dépendant de la géolocalisation, de l'heure dans le fuseau horaire, de l'opérateur de télécommunications ou du type de connexion ne se reproduisent tout simplement pas sur l'environnement de test. Ils apparaissent uniquement en production — lorsque l'utilisateur du Kazakhstan voit des prix en roubles, l'utilisateur allemand ne reçoit pas de notification push en raison du blocage de GCM dans son réseau, et le client indonésien ne peut pas payer par carte parce que le fournisseur de paiement pour sa région n'est pas connecté. Corriger un tel bogue après la publication coûte beaucoup plus cher que de le détecter au stade du QA.
La solution consiste à émuler la véritable diversité géographique et réseau des utilisateurs avant la publication. Pour cela, les ingénieurs QA utilisent de plus en plus des serveurs proxy : ils permettent de « déplacer » l'appareil de test ou l'émulateur dans n'importe quel pays, ville ou même opérateur de télécommunications sans avoir à se rendre physiquement là-bas ou à acheter des dizaines de cartes SIM.
Scénario 1 : Géocontenu et prix régionaux
La plupart des applications avec abonnements (streaming, fitness, éducation) affichent des prix différents dans différents pays — cela s'appelle le géopricing. Si le QA vérifie la souscription uniquement avec une IP locale, il est impossible de s'assurer que le prix pour un utilisateur de Turquie, du Brésil ou de l'Inde s'affiche correctement, dans la bonne devise et avec le bon arrondi.
Le même problème se pose avec les catalogues de contenu : une bibliothèque de films, de produits ou de promotions est souvent régionale. Il faut physiquement « apparaître » dans le pays concerné pour voir le même écran que voit un utilisateur réel. Pour ces vérifications, il est pratique d'utiliser des proxies résidentiels — ils fournissent une IP d'utilisateurs domestiques réels d'un pays spécifique, et le backend de l'application perçoit la demande comme un trafic organique normal, et non comme une requête provenant d'un centre de données.
Vérification pratique : nous exécutons le scénario de souscription sur 8 à 10 marchés clés (États-Unis, Allemagne, Brésil, Inde, Turquie, Japon, Nigéria, Émirats Arabes Unis), prenons des captures d'écran des prix et des devises, et les comparons avec la liste de prix du produit. Cela couvre la plupart des plaintes du type « pourquoi j'ai un prix différent ».
Scénario 2 : Géoblocages et restrictions d'accès
Les applications fintech, les services de streaming et certains jeux bloquent l'accès depuis certains pays pour des raisons juridiques ou de licence. Le QA doit s'assurer non seulement que l'application fonctionne là où elle doit, mais aussi qu'elle refuse correctement (et sans crash) l'accès là où elle ne doit pas.
Un bogue typique : au lieu d'un écran soigné « service indisponible dans votre région », l'utilisateur voit un écran blanc ou un chargeur infini — parce que les développeurs n'ont testé que le chemin heureux depuis un pays autorisé. La vérification des géoblocages nécessite une connexion séquentielle depuis plusieurs juridictions interdites, ce qui est irréaliste avec des cartes SIM vivantes et des déplacements, alors qu'avec un proxy, cela prend 10 à 15 minutes par pays.
Pour ce scénario, des proxies avec une géolocalisation précise au niveau de la ville, et non seulement du pays, sont appropriés — il est important de vérifier non pas « l'Allemagne en général », mais des terres spécifiques, si la licence est limitée à une région à l'intérieur du pays.
Scénario 3 : A/B et déploiements progressifs par pays
Les drapeaux de fonctionnalités et les déploiements progressifs sont presque toujours configurés en fonction de la géolocalisation : une nouvelle fonctionnalité est d'abord activée au Canada, une semaine plus tard — en Australie, puis — partout. Si l'équipe QA se trouve physiquement dans un seul pays, elle ne peut pas voir la nouvelle version avant les autres régions, tant que le drapeau n'est pas arrivé jusqu'à elle.
Pour tester une fonctionnalité avant la publication mondiale, il faut remplacer la géolocalisation par celle du pays de la première vague de déploiement. C'est l'une des tâches les plus fréquentes que les proxies résolvent en combinaison avec des navigateurs anti-détection ou des émulateurs d'appareils — nous changeons l'IP pour le pays souhaité, redémarrons la session de l'application, voyons la fonctionnalité avant les autres utilisateurs et avons le temps de trouver des bogues avant que le drapeau n'atteigne 100 % de l'audience.
Un point important : pour les tests A/B, une « résidence » IP stable est nécessaire pendant tout le cycle de test — la session ne doit pas sauter entre les pays entre les requêtes, sinon le backend confondra les conditions de l'expérience et montrera tantôt le groupe de contrôle, tantôt le groupe de test.
Scénario 4 : Localisation et notifications push
Le texte de la notification push, le moment de son envoi et même le fait de la livrer dépendent souvent de la géolocalisation de l'appareil. Dans certains pays, les fournisseurs de notifications push (Firebase, APNs, passerelles SMS locales) fonctionnent avec des retards ou par des routes alternatives — et ce qui est parfaitement livré dans l'environnement de test depuis le bureau à Moscou peut ne pas atteindre l'utilisateur en Indonésie à cause du blocage de certains serveurs de notification push par le fournisseur de télécommunications local.
De plus, la localisation de l'interface est souvent déclenchée par l'IP, et non seulement par la langue du système : un utilisateur avec la langue anglaise sur son téléphone, mais une IP provenant de la France, peut voir une interface mélangée — des titres en français, des boutons en anglais. De tels bogues sont invisibles à 100 % si tout le QA teste depuis une seule zone géographique.
Processus recommandé : nous prenons 5 à 7 localisations des marchés prioritaires du produit, nous nous connectons via un proxy avec l'IP correspondante, nous changeons la langue du système sur l'appareil/émulateur et notons quel texte et quel format de dates/nombres l'application affiche. Les incohérences entre le pays de l'IP et la langue du système sont un cas obligatoire distinct, souvent oublié.
Scénario 5 : Méthodes de paiement et systèmes antifraude
L'ensemble des méthodes de paiement disponibles dans une application mobile dépend presque toujours du pays : dans une région, le paiement par carte et Apple Pay est disponible, dans une autre — uniquement des portefeuilles locaux (Mercado Pago, Boleto, UPI, QIWI), dans une troisième — le paiement par l'opérateur de télécommunications. Si le QA ne peut pas se connecter depuis le pays requis, la moitié des scénarios de paiement reste non vérifiée jusqu'à la production, où le coût de l'erreur est une perte de revenus et des plaintes au support.
Une autre douleur — les systèmes antifraude des fournisseurs de paiement. Ils évaluent le risque de la transaction notamment en fonction de l'IP : une demande avec une IP de centre de données recevra presque certainement un refus ou une vérification 3D-Secure supplémentaire, même si la carte est absolument valide. Cela fausse les résultats des tests : le QA voit un refus de paiement et signale un bogue aux développeurs, alors que le problème ne réside pas dans le code, mais dans le fait que l'IP de test semble suspecte pour le scoring antifraude.
Pour les scénarios de paiement, il est préférable d'utiliser des proxies résidentiels ou des proxies mobiles — ils ressemblent à un trafic normal d'un utilisateur réel et ne déclenchent pas de faux positifs dans les systèmes antifraude, ce qui donne une image plus honnête du comportement du flux de paiement.
Scénario 6 : Comportement dans les réseaux mobiles des opérateurs
Une application qui fonctionne parfaitement sur le Wi-Fi de bureau à 200 Mbit/s peut se comporter complètement différemment dans un réseau mobile 3G/4G avec une connexion instable, un proxy NAT de l'opérateur et une latence élevée. Les délais d'attente des requêtes, les tentatives répétées, la dégradation de la qualité vidéo/audio, le fonctionnement du mode hors ligne — tout cela doit être vérifié précisément dans des conditions proches de l'internet mobile, et non dans un réseau de bureau stable.
Une complexité supplémentaire : certains opérateurs de télécommunications appliquent leurs propres proxies et CGNAT, ce qui fait que le serveur ne voit pas l'IP réelle de l'utilisateur, mais l'IP commune de l'opérateur, par laquelle passent simultanément des milliers d'abonnés. Cela affecte la limitation de taux et la géolocalisation par IP — l'application peut « penser » que l'utilisateur se trouve dans une autre ville que celle où il est physiquement.
Pour reproduire un tel comportement, il faut des proxies mobiles qui se connectent à internet via de vraies cartes SIM des opérateurs du pays concerné — cela donne une image précise du NAT, des délais et de la vitesse, que l'on ne peut obtenir avec une IP de centre de données ordinaire.
Scénario 7 : Limitation de taux et protection contre les bots
De nombreuses API backend des applications mobiles limitent le nombre de requêtes provenant d'une seule IP (limitation de taux) et utilisent une protection contre les bots, similaire à un captcha ou à une analyse comportementale. Si l'équipe QA exécute des tests automatisés depuis une seule IP d'entreprise, au bout d'un certain temps, le serveur commence à répondre par des erreurs 429 ou à bloquer complètement les requêtes — et les tests échouent non pas à cause d'un bogue dans l'application, mais parce que le backend a pris le trafic de test pour une attaque.
Cela est particulièrement pertinent pour les tests de charge et de régression, lorsque des centaines de requêtes similaires doivent être exécutées en peu de temps (inscription, connexion, ajout au panier). La répartition des requêtes entre différentes IP via un pool de proxies permet de charger l'API de manière équitable sans fausser les résultats en raison de déclenchements de protection antifraude.
Pour ce type de test automatisé massif, il est souvent plus avantageux d'utiliser des proxies de centre de données — ils sont plus rapides et moins chers pour de grands volumes de requêtes, et la géolocalisation dans ce scénario n'est pas aussi critique que la vitesse et la stabilité de la connexion.
Outils et configuration de proxy pour le QA
Pour le QA manuel sur des émulateurs (Android Studio Emulator, Xcode Simulator), le proxy est configuré via les paramètres réseau du système de l'émulateur : vous indiquez l'IP et le port du serveur proxy, le nom d'utilisateur et le mot de passe, si l'authentification est utilisée. Pour les appareils réels, des paramètres similaires sont disponibles dans la connexion Wi-Fi via « Paramètres avancés → Proxy → Manuel ».
Pour intercepter et analyser le trafic entre l'application et le backend, les ingénieurs QA utilisent Charles Proxy ou Proxyman — les deux outils permettent de faire passer le trafic de l'application par un proxy externe et de voir simultanément toutes les requêtes HTTP/HTTPS, les en-têtes de géolocalisation et les réponses du serveur. Cela est pratique pour le diagnostic : il est immédiatement visible quelle IP et quel pays le backend « voit » au moment de la requête.
Pour les tests automatisés via Appium ou Espresso, le proxy est spécifié dans les capacités souhaitées de la session ou via les paramètres système de l'appareil avant le lancement du jeu de tests. Les plateformes cloud pour les tests d'applications mobiles (BrowserStack, Sauce Labs) prennent également en charge la connexion de proxies personnalisés, ce qui permet d'exécuter le même scénario de test automatisé depuis différents pays sans appareils physiques à chaque point du monde.
Si l'équipe a une version web de l'application ou si elle doit tester plusieurs comptes avec des géolocalisations différentes en parallèle, il est pratique d'utiliser des navigateurs anti-détection (Dolphin Anty, AdsPower, Multilogin) — chaque profil est lié à un proxy distinct, et l'ingénieur QA peut maintenir ouvertes 5 à 10 sessions provenant de différents pays simultanément sans confusion dans les cookies et le cache.
Quel type de proxy choisir pour chaque scénario
| Scénario QA | Type de proxy recommandé | Pourquoi |
|---|---|---|
| Géoprix et contenu | Résidentiels | Ressemblent au trafic d'un utilisateur normal, ne déclenchent pas la protection anti-bot |
| Géoblocages | Résidentiels | Géolocalisation précise jusqu'à la ville/région |
| A/B et déploiements | Résidentiels / centre de données | Session stable pendant tout le cycle de test |
| Notifications push et localisation | Mobiles | Reproduisent les conditions réelles de livraison via les opérateurs |
| Paiements et antifraude | Résidentiels / mobiles | Faible risque de faux positifs dans les systèmes antifraude |
| Réseaux mobiles des opérateurs | Mobiles | Vraies cartes SIM des opérateurs, émulation précise du NAT et des délais |
| Limitation de taux / tests de charge | Centres de données | Haute vitesse et faible coût pour de grands volumes de requêtes |
Liste de contrôle avant la publication
Avant de publier la version en production, passez en revue une courte liste de vérifications liées à la géolocalisation et au réseau — cela couvre la plupart des bogues décrits ci-dessus :
- Les prix et la devise de l'abonnement ont été vérifiés sur au moins 5 marchés clés du produit
- Affichage correct de l'écran de géoblocage dans les pays interdits vérifié
- Le drapeau de fonctionnalité a été testé dans le pays de la première vague de déploiement avant la publication mondiale
- Les notifications push ont été vérifiées avec l'IP et la langue système provenant de différentes combinaisons de pays
- Méthodes de paiement disponibles vérifiées pour chaque région clé séparément
- Le flux de paiement a été testé sans faux positifs dans les systèmes antifraude
- L'application a été testée dans des conditions de réseau mobile (3G/4G), et non seulement sur Wi-Fi
- Les tests automatisés ne tombent pas en raison de la limitation de taux lors du lancement parallèle depuis une seule IP
Conclusion
Une application mobile vit dans des dizaines de pays, de réseaux et d'écosystèmes de paiement simultanément, tandis que l'équipe QA se trouve physiquement dans un seul bureau avec une seule IP. C'est ce fossé entre l'audience réelle et les conditions de test qui engendre la plupart des bogues « inexplicables » qui atteignent la production. Les sept scénarios ci-dessus — géoprix, géoblocages, déploiements A/B, notifications push et localisation, paiements, réseaux mobiles des opérateurs et limitation de taux — couvrent la majeure partie de ces risques.
Si votre équipe teste une application qui fonctionne avec du contenu régional, des prix ou des paiements, il est judicieux d'intégrer dans la pile de tests des proxies résidentiels pour simuler de vrais utilisateurs, et pour les scénarios impliquant des communications mobiles et la livraison de notifications push — des proxies mobiles liés à des opérateurs spécifiques. Cela permet de trouver des bogues critiques au stade du QA, et non après les plaintes des utilisateurs dans les stores.