Comment visualiser le trafic de votre application mobile : guide pas à pas pour mitmproxy et Charles

Vous développez ou testez une application mobile et vous voulez savoir exactement quelles requêtes elle envoie au serveur et ce qu'elle reçoit en retour ? Ce guide pas à pas vous mènera d'une page blanche à un contrôle total sur le trafic réseau de votre propre application. Nous allons passer en revue les outils les plus populaires de 2026, apprendre à installer un certificat de confiance sur votre téléphone, émulateur et simulateur, et contourner proprement le SSL pinning dans les builds de débogage par des moyens standards.

Important dès le départ : tout ce qui est décrit ci-dessous ne concerne que votre propre application ou une application pour laquelle vous avez l'autorisation écrite du propriétaire. Ce matériel est destiné aux ingénieurs qualité et aux développeurs, et non à une instruction pour interférer avec les programmes d'autrui. Nous en parlerons en détail dans la section sur les règles et l'éthique.

Introduction : pourquoi développeur et testeur doivent voir le trafic de leur application

L'application mobile communique constamment avec le serveur : connexion, catalogue de produits, envoi d'analytiques, synchronisation de données. Tant que tout fonctionne, ces requêtes restent invisibles. Mais dès que quelque chose se casse, la question est toujours la même : qu'est-ce qui est parti vers le serveur et qu'est-ce qui est revenu ?

Savoir lire le trafic de votre propre application résout plusieurs problèmes :

• Vérification des intégrations. Vous voyez le format exact des requêtes vers votre API, les en-têtes, le corps, les codes de réponse. Il est facile de comprendre qui est responsable du bug : le client ou le backend.
• Reproduction des bugs. Lorsqu'un testeur signale un problème, vous pouvez voir la séquence réelle des requêtes et reproduire le scénario.
• Audit des fuites. Vous vérifiez si des informations superflues ne s'échappent pas : jetons dans les logs, données personnelles dans l'analytique, champs en trop.
• Test des scénarios d'erreur. Vous pouvez modifier la réponse du serveur et voir comment l'application se comporte en cas d'erreur 500 ou de timeout.

Ce que vous obtiendrez au final

Après avoir suivi ce guide, vous serez capable de lancer un proxy local sur votre ordinateur, d'y faire passer le trafic de votre téléphone, de déchiffrer les requêtes HTTPS sécurisées, de les lire dans une interface pratique, de les répéter et de modifier les réponses. Tout cela pour votre propre application.

À qui s'adresse ce guide

Ce contenu est rédigé pour les ingénieurs QA, les développeurs mobiles et les professionnels techniques qui souhaitent comprendre la couche réseau de leur application. Niveau : débutant, mais avec des éléments pour avancés.

Ce qu'il faut savoir à l'avance

Une compréhension de base de ce qu'est une requête HTTP, un serveur et un client suffit. Connaître la ligne de commande est un plus, mais nous aborderons aussi les outils graphiques. Aucune connaissance approfondie en cryptographie n'est nécessaire.

Temps nécessaire

La première configuration prendra entre une et deux heures, y compris l'installation des outils et des certificats. Les lancements suivants prendront quelques minutes.

Préparation préalable : outils, exigences et ce qu'il faut installer

Avant de plonger dans le trafic, préparons l'environnement de travail. Passons en revue quatre outils populaires et choisissons celui qui vous convient.

Comparaison des outils : mitmproxy, Charles, Proxyman et Burp

Chacun de ces outils fonctionne comme un proxy MITM, c'est-à-dire un intermédiaire entre votre application et le serveur. Les différences résident dans l'interface, le prix et la commodité.

• mitmproxy. Gratuit et open source. Fonctionne en terminal mais dispose également d'une interface web mitmweb. Idéal pour ceux qui aiment les scripts et l'automatisation en Python. Multiplateforme.
• Charles. Payant, avec une période d'essai. Interface graphique classique en Java, fonctionne sur Windows, macOS et Linux. Très populaire auprès des QA mobiles grâce à sa simplicité.
• Proxyman. Outil moderne avec une belle interface, initialement pour macOS, avec des versions pour Windows et Linux. Configuration automatique pratique des certificats.
• Burp Suite. Outil du monde de la sécurité. Puissant, avec une version Community gratuite. Un peu excessif pour une simple visualisation de trafic, mais utile pour une analyse avancée.

Conseil : Si vous êtes débutant et voulez voir rapidement le résultat, commencez par Charles ou Proxyman. Si vous aimez le terminal et l'automatisation, installez mitmproxy. Pour les besoins de ce guide, nous nous appuierons sur mitmproxy et Charles comme options les plus universelles.

Configuration système requise

• Ordinateur sous Windows, macOS ou Linux avec des droits d'administrateur.
• Appareil mobile ou émulateur Android ou simulateur iOS.
• Réseau Wi-Fi commun pour le téléphone et l'ordinateur, ou émulateur configuré.
• Accès aux sources de votre application pour construire une version de débogage.

Ce qu'il faut télécharger et installer

1. Téléchargez l'outil proxy choisi depuis son site officiel. Pour mitmproxy, c'est l'installateur pour votre OS ou un paquet via le gestionnaire de paquets.
2. Installez l'outil en suivant l'assistant d'installation standard pour votre système.
3. Pour l'émulateur Android, installez Android Studio avec l'émulateur et une image système sans services Google si vous voulez travailler facilement avec le stockage système des certificats.
4. Pour le simulateur iOS sur macOS, installez Xcode depuis l'App Store.

⚠️ Attention : Téléchargez les outils uniquement depuis les sites officiels des développeurs. Les programmes proxy ont un accès profond au trafic, donc les contrefaçons peuvent être dangereuses. Vérifiez les signatures des installateurs lorsque c'est possible.

Sauvegardes et préparation de l'appareil

Travailler avec des certificats et des paramètres réseau est généralement sûr et réversible. Mais il est prudent de se prémunir avant les modifications.

1. Notez les paramètres Wi-Fi actuels du téléphone pour pouvoir les restaurer plus tard.
2. Utilisez un appareil de test séparé ou un profil pour les expériences, et non votre téléphone professionnel principal.
3. Si vous travaillez avec un appareil professionnel, souvenez-vous des certificats que vous installez pour les supprimer après le débogage.

✅ Vérification : À ce stade, vous devriez avoir installé un outil proxy, un appareil de test ou un émulateur prêt, et un accès à la build de votre application.

Concepts de base : comment fonctionne un proxy MITM et pourquoi un certificat personnel est nécessaire

Pour avancer en toute confiance, comprenons les termes clés en termes simples. C'est le fondement sans lequel les étapes sembleront magiques.

Qu'est-ce qu'un proxy MITM

MITM signifie man-in-the-middle, c'est-à-dire un homme du milieu. Le proxy se place entre votre application et le serveur. L'application pense parler au serveur, et le serveur pense parler à l'application. En réalité, les deux communiquent avec le proxy, qui voit et peut afficher tout le trafic.

Pour HTTP classique, cela fonctionne immédiatement : les données sont transmises en clair. Mais les applications modernes utilisent HTTPS, où le trafic est chiffré. C'est là que les choses deviennent intéressantes.

Ce qui se passe lors d'une poignée de main TLS

HTTPS repose sur le protocole TLS. Lorsque l'application se connecte au serveur, ils effectuent une poignée de main. Le serveur présente son certificat, confirmant qu'il est bien celui qu'il prétend être. L'application vérifie ce certificat par rapport à la liste des autorités de certification de confiance.

Autorité de certification, ou CA, est une organisation à laquelle les appareils font confiance. Sa signature sur le certificat du serveur convainc l'application que la connexion est sécurisée.

Pourquoi un certificat CA personnel est nécessaire

Pour que le proxy puisse afficher le trafic chiffré, il doit lui-même jouer le rôle de serveur pour l'application. Pour cela, le proxy génère à la volée un certificat pour chaque domaine demandé et le signe avec son propre certificat racine CA.

Mais par défaut, l'application ne fait pas confiance à ce CA artisanal. Nous installons donc manuellement le certificat racine du proxy dans le magasin de certificats de confiance de l'appareil. Ensuite, l'application voit la signature du proxy comme fiable et établit la connexion en toute sécurité.

Conseil : Considérez le certificat racine du proxy comme un laissez-passer. Tant que vous n'avez pas délivré ce laissez-passer à l'appareil, il n'autorise pas le proxy à lire le trafic protégé.

Pourquoi sans confiance, seul le nom d'hôte dans SNI est visible

Si le certificat du proxy n'est pas installé, l'application refusera d'établir une connexion sécurisée à travers lui. Mais quelque chose reste visible. Au début de la poignée de main TLS, le champ SNI (Server Name Indication) est transmis, c'est-à-dire le nom du serveur auquel la connexion est destinée. Il permet au serveur de savoir quel site est demandé.

Ainsi, même sans confiance au certificat, vous verrez la liste des domaines auxquels l'application se connecte, mais vous ne pourrez pas lire le contenu des requêtes et réponses. Pour lire le contenu, un certificat installé et de confiance est nécessaire.

Qu'est-ce que le SSL pinning

SSL pinning, ou épinglage de certificat, est une protection supplémentaire. L'application stocke en interne l'empreinte du certificat ou de la clé attendue du serveur et vérifie que le serveur présente exactement celui-ci. Même si un certificat proxy de confiance est présent dans le système, l'application avec pinning le rejettera car l'empreinte ne correspond pas. Nous aborderons séparément le travail avec le pinning dans vos builds de débogage.

✅ Vérification : Vous comprenez que le proxy affiche le trafic en étant un intermédiaire, et que pour lire HTTPS, un certificat racine de confiance du proxy est nécessaire sur l'appareil.

Étape 1 : Configurer le proxy réseau sur Android et iOS

Objectif de l'étape : Faire passer tout le trafic web du téléphone via votre ordinateur sur lequel tourne l'outil proxy.

Préparer l'ordinateur et connaître son adresse

1. Assurez-vous que l'ordinateur et le téléphone sont connectés au même réseau Wi-Fi.
2. Lancez l'outil proxy. Pour mitmweb, tapez la commande de lancement de l'interface web dans le terminal, pour Charles ouvrez simplement l'application.
3. Vérifiez sur quel port écoute le proxy. Par défaut, mitmproxy utilise le port 8080, Charles utilise 8888 ou 8080 selon la version.
4. Trouvez l'adresse IP locale de l'ordinateur sur le réseau. Sous Windows, c'est la commande pour afficher les paramètres réseau, sous macOS et Linux une commande similaire dans le terminal. L'adresse ressemble à 192.168.1.15.

Conseil : Notez l'adresse IP de l'ordinateur et le port du proxy sur un papier. Vous saisirez ces deux valeurs dans les paramètres du téléphone.

Configuration du proxy sur Android

1. Ouvrez l'application Paramètres sur le téléphone.
2. Allez dans Réseau et Internet, puis Wi-Fi.
3. Appuyez sur le nom de votre réseau actuel pour ouvrir ses paramètres.
4. Trouvez l'option Avancé ou l'icône de crayon pour modifier le réseau.
5. Dans le champ Proxy, sélectionnez Manuel.
6. Dans le champ Nom d'hôte du proxy, saisissez l'adresse IP de l'ordinateur, par exemple 192.168.1.15.
7. Dans le champ Port, saisissez le port du proxy, par exemple 8080.
8. Enregistrez les paramètres en appuyant sur Enregistrer.

Configuration du proxy sur iOS

1. Ouvrez l'application Réglages.
2. Allez dans Wi-Fi.
3. Appuyez sur l'icône d'information bleue à côté du nom de votre réseau.
4. Faites défiler jusqu'à la section Proxy HTTP.
5. Sélectionnez le mode Manuel.
6. Dans le champ Serveur, saisissez l'adresse IP de l'ordinateur.
7. Dans le champ Port, saisissez le port du proxy.
8. Revenez en arrière, les paramètres sont enregistrés automatiquement.

⚠️ Attention : Après la configuration du proxy, tout le trafic web du téléphone passera par l'ordinateur. Si l'outil proxy est éteint, Internet sur le téléphone cessera de fonctionner. C'est normal : allumez simplement le proxy ou supprimez les paramètres.

Résultat attendu

Ouvrez un navigateur sur le téléphone et allez sur un site simple en HTTP. Dans l'interface du proxy, des entrées de requêtes devraient apparaître. Pour l'instant, le HTTPS ne s'affichera que comme nom d'hôte, car le certificat n'est pas encore installé.

Problèmes possibles. Si rien n'apparaît, vérifiez que le téléphone et l'ordinateur sont sur le même réseau, que vous avez saisi la bonne IP et le bon port, et qu'aucun pare-feu sur l'ordinateur ne bloque les connexions.

✅ Vérification : Dans la fenêtre du proxy, les requêtes entrantes du téléphone sont visibles, au moins sous forme de liste de domaines.

Étape 2 : Installer et approuver le certificat racine

Objectif de l'étape : Faire en sorte que l'appareil fasse confiance au certificat racine du proxy et permette de lire le contenu des requêtes HTTPS.

Télécharger le certificat du proxy

Une fois le proxy configuré et le téléphone y passant, il existe un moyen pratique d'obtenir le certificat directement sur l'appareil.

1. Ouvrez un navigateur sur le téléphone.
2. Pour mitmproxy, allez à l'adresse de service spéciale mitm.it. Cette page n'apparaît que lorsque le trafic passe par mitmproxy.
3. Vous verrez des boutons pour différentes plateformes. Choisissez celle qui convient, par exemple Android ou Apple.
4. Le fichier du certificat sera téléchargé.
5. Pour Charles, le certificat est également accessible via une adresse de service que le programme affiche dans le menu d'aide.

Installation sur Android 7 et versions ultérieures

À partir d'Android 7, le système sépare deux magasins de certificats : utilisateur et système. C'est un point crucial.

• Magasin utilisateur. Vous pouvez y installer un certificat sans droits root. Mais par défaut, les applications ne font pas confiance aux certificats utilisateur, sauf si le développeur l'autorise explicitement dans la configuration de l'application.
• Magasin système. Toutes les applications lui font confiance, mais pour y ajouter un certificat, il faut un accès root sur l'appareil ou un émulateur avec une image sans services Google.

Pour installer dans le magasin utilisateur, suivez ces étapes :

1. Ouvrez Paramètres, puis Sécurité.
2. Trouvez la section Chiffrement et informations d'identification ou Paramètres de sécurité avancés.
3. Sélectionnez Installer un certificat, puis Certificat CA.
4. Le système vous avertira des risques, confirmez l'installation.
5. Indiquez le fichier de certificat téléchargé.
6. Donnez un nom compréhensible au certificat, par exemple DebugProxy.

Important : C'est précisément à cause de la séparation des magasins sur Android 7 et versions ultérieures que votre application peut ne pas voir le trafic, même si le certificat est installé dans le magasin utilisateur. La solution via la configuration de l'application sera abordée à l'étape sur le pinning.

Installation et approbation sur iOS

Sur iOS, le processus se déroule en deux étapes : installation du profil et activation de la confiance.

1. Après le téléchargement du certificat, iOS indique que le profil a été téléchargé.
2. Ouvrez Réglages, tout en haut apparaît l'option Profil téléchargé.
3. Appuyez dessus et sélectionnez Installer en haut à droite.
4. Saisissez le code de l'appareil s'il est défini.
5. Confirmez l'installation du profil.

Maintenant, l'étape clé souvent oubliée : activer la confiance totale.

1. Ouvrez Réglages, puis Général.
2. Allez dans À propos.
3. Faites défiler jusqu'à la section Confiance des certificats.
4. Trouvez votre certificat proxy dans la liste.
5. Activez l'interrupteur à côté pour activer la confiance totale dans le certificat racine.

⚠️ Attention : Sans activer l'interrupteur dans la section Confiance des certificats, iOS considère le certificat comme installé mais pas de confiance. Le trafic HTTPS ne sera pas lisible. C'est l'erreur la plus fréquente chez les débutants sur iOS.

Résultat attendu

Ouvrez un navigateur et allez sur n'importe quel site en HTTPS. Maintenant, dans l'interface du proxy, vous devriez voir le contenu complet des requêtes et réponses, pas seulement les noms de domaine.

✅ Vérification : Dans l'outil proxy, le contenu déchiffré des requêtes HTTPS du navigateur du téléphone est affiché.

Étape 3 : Faire la même chose sur un émulateur Android et un simulateur iOS

Objectif de l'étape : Configurer l'interception du trafic sans appareil physique, directement sur l'ordinateur du développeur.

Émulateur Android

L'émulateur est pratique car vous pouvez utiliser une image sans services Google et obtenir un accès au magasin système des certificats.

1. Dans Android Studio, ouvrez Device Manager et créez un appareil virtuel.
2. Lors du choix de l'image système, privilégiez une version sans mention Google Play pour avoir les droits sur la partition système.
3. Lancez l'émulateur.
4. Dans les paramètres avancés de l'émulateur, vous pouvez spécifier le proxy directement, ou le définir dans les paramètres Wi-Fi à l'intérieur de l'émulateur comme sur un téléphone réel.
5. Pour le magasin système, utilisez des outils en ligne de commande qui permettent de redémarrer l'émulateur avec un droit d'écriture sur la partition système et d'y ajouter le certificat.

Conseil : L'émulateur sans services Google et avec un accès au magasin système vous évite de nombreux problèmes de confiance de certificats. C'est le meilleur choix pour un débogage régulier.

Simulateur iOS

Le simulateur iOS sur macOS utilise les certificats de confiance du système macOS, ce qui simplifie la configuration.

1. Installez le certificat racine du proxy dans le trousseau système de votre Mac.
2. Ouvrez l'application Trousseau d'accès, trouvez le certificat du proxy.
3. Double-cliquez pour l'ouvrir et dans la section Confiance, définissez la valeur Toujours approuvé.
4. Lancez le simulateur via Xcode. Il héritera de la confiance du certificat depuis macOS.
5. Le trafic du simulateur passera par le proxy système du Mac s'il est configuré, ou par le proxy défini dans les paramètres réseau.

Résultat attendu. Dans les deux cas, vous voyez le trafic déchiffré de l'application de test ou du navigateur lancé dans l'émulateur ou le simulateur.

Problèmes possibles. Si l'émulateur Android ne prend pas en compte le proxy, vérifiez les paramètres Wi-Fi à l'intérieur de l'émulateur et les paramètres de lancement. Pour le simulateur iOS, assurez-vous que le certificat dans le trousseau est marqué comme approuvé.

✅ Vérification : Le trafic de l'émulateur ou du simulateur est lisible dans l'outil proxy sous forme déchiffrée.

Étape 4 : Travailler avec le SSL pinning dans votre build de débogage

Objectif de l'étape : Comprendre si l'application a un épinglage de certificat et le désactiver correctement uniquement dans la build de débogage par des moyens standards de la plateforme.

C'est la section la plus importante, alors abordons-la avec réflexion.

Comment savoir si le pinning est activé

Si le certificat du proxy est installé et approuvé, que le navigateur affiche le trafic, mais que votre application ne fonctionne pas ou signale une erreur réseau, il y a probablement un pinning.

• Dans l'interface du proxy, vous verrez une interruption de connexion lors de la poignée de main TLS pour les domaines de votre application.
• Dans les logs de l'application, des messages d'erreur de vérification de certificat ou de chaîne non fiable peuvent apparaître.
• Souvent, le développeur sait lui-même que le pinning a été ajouté intentionnellement pour sécuriser la version release.

Désactiver le pinning sur Android via network_security_config

Android fournit un mécanisme standard de configuration de la sécurité réseau. Grâce à lui, vous pouvez autoriser la confiance aux certificats utilisateur uniquement pour la build de débogage.

1. Dans le projet, créez un fichier de configuration de sécurité réseau dans les ressources.
2. Décrivez-y les règles de confiance des certificats spécifiquement pour la configuration de débogage, en utilisant un bloc spécial pour les redéfinitions de débogage.
3. Indiquez qu'en débogage, l'application fait confiance au magasin utilisateur de certificats.
4. Connectez ce fichier dans le manifeste de l'application via l'attribut approprié.
5. Assurez-vous que les redéfinitions de débogage ne s'appliquent que lorsque l'application est construite en mode débogage et jamais en release.

Important : Le bloc spécial de redéfinitions de débogage ne fonctionne que lorsque l'application est marquée comme débogable. Dans la build release, ces règles sont complètement ignorées par le système, ce qui garantit la sécurité.

Désactiver les vérifications sur iOS via les paramètres dans Info.plist

Sur iOS, la sécurité des transports est contrôlée par le mécanisme ATS. Dans une build de débogage, vous pouvez assouplir les vérifications strictes pour des domaines spécifiques de votre environnement de test.

1. Ouvrez le fichier Info.plist de votre configuration de débogage.
2. Ajoutez les paramètres de sécurité des transports pour les domaines nécessaires du serveur de test.
3. Rappelez-vous qu'ATS régule la politique de connexion, et que le pinning propre dans le code de l'application doit être désactivé séparément.
4. Si le pinning est implémenté dans le code, ajoutez une condition pour que la vérification d'empreinte ne s'effectue que dans la configuration release.

⚠️ Attention : Ne laissez jamais de vérifications assouplies dans la build release. Cela créerait une véritable vulnérabilité pour les utilisateurs de votre application. Toutes les modifications doivent s'appliquer strictement à la configuration de débogage et disparaître automatiquement dans la release.

Pourquoi uniquement en débogage et jamais en release

Le SSL pinning protège les utilisateurs de votre application contre l'interception de leur trafic. En le désactivant en débogage, vous le faites sur votre propre appareil contrôlé, pour le diagnostic, de manière consciente et temporaire. En release, une telle protection est cruciale et doit rester aussi stricte que possible.

Conseil : Séparez la logique de vérification des certificats par un indicateur de build. Configurez les choses de sorte que même accidentellement, il soit impossible de construire une release avec des vérifications assouplies. Cela vous protégera des erreurs humaines.

Résultat attendu

Après une configuration correcte de la build de débogage, votre application établit une connexion via le proxy, et vous voyez ses requêtes et réponses déchiffrées.

✅ Vérification : Les requêtes de votre application vers son API s'affichent dans le proxy sous forme lisible, tandis que les modifications ne concernent que la build debug.

Étape 5 : Lire et analyser le trafic

Objectif de l'étape : Apprendre à trouver les requêtes pertinentes, filtrer le bruit, exporter les données, répéter les requêtes et modifier les réponses.

Filtres et recherche

Même une petite application génère des dizaines de requêtes. Les filtres aident à trouver ce qui est pertinent.

1. Utilisez un filtre par domaine pour ne conserver que les requêtes vers votre API.
2. Filtrez par type de contenu, par exemple uniquement les réponses JSON.
3. Recherchez par chaîne dans le corps de la requête ou de la réponse pour trouver rapidement l'appel souhaité.
4. Dans Charles, il y a une arborescence pratique par hôtes, dans mitmweb une chaîne de filtres flexible.

Conseil : Configurez le filtre pour n'afficher que les domaines de votre application. Cela éliminera immédiatement le trafic de fond superflu du système et des services tiers.

Export au format HAR

Le format HAR est un moyen standard de sauvegarder une session de trafic dans un seul fichier. Il est pratique pour le transmettre à l'équipe backend ou le joindre à un rapport de bug.

1. Sélectionnez les requêtes pertinentes ou toute la session.
2. Choisissez l'option d'export au format HAR dans le menu de l'outil.
3. Enregistrez le fichier et joignez-le à la tâche dans le tracker.

Répéter une requête

Il est parfois nécessaire de répéter la même requête plusieurs fois, par exemple pour vérifier l'idempotence ou reproduire un bug.

1. Sélectionnez la requête souhaitée dans la liste.
2. Utilisez la fonction de répétition ; dans Charles c'est Repeat, dans mitmproxy la commande de répétition de flux.
3. Si nécessaire, modifiez la requête avant de la répéter, en changeant les en-têtes ou le corps.

Modifier la réponse pour tester les scénarios d'erreur

C'est une fonctionnalité puissante. Vous pouvez forcer l'application à recevoir la réponse souhaitée au lieu de la vraie.

1. Configurez une règle de substitution ; dans Charles ce sont les fonctions Map Local ou Breakpoints, dans mitmproxy des scripts Python.
2. Définissez que pour une requête à une adresse spécifique, une réponse préparée à l'avance est renvoyée, par exemple une erreur 500 ou une liste vide.
3. Lancez le scénario dans l'application et observez comment elle gère l'erreur.

Conseil : Avec la modification des réponses, il est pratique de tester le comportement de l'application en cas de mauvaise connexion Internet, d'erreurs serveur et de données inattendues, sans toucher au vrai backend.

✅ Vérification : Vous savez filtrer le trafic, exporter en HAR, répéter une requête et modifier une réponse pour votre application.

Comment les proxies mobiles aident à tester l'application depuis un autre réseau et une autre région

Il convient de mentionner séparément les proxies mobiles. Ce sont des serveurs proxy fonctionnant via de vrais réseaux d'opérateurs mobiles. Ils sont utiles pour tester le comportement de votre application lorsque l'utilisateur se connecte depuis un réseau mobile dans une autre région.

Pourquoi c'est utile pour les QA

• Vérification du contenu régional. De nombreuses applications affichent des données différentes selon la région de l'utilisateur. Un proxy mobile vous permet de voir l'application du point de vue d'un utilisateur dans la région souhaitée.
• Test sur réseau mobile. Le comportement de l'application sur un réseau mobile diffère du Wi-Fi : autres latences, changement d'IP, particularités des réseaux d'opérateurs. Un proxy mobile permet de reproduire ces conditions.
• Vérification de la logique géodépendante. Si votre backend détermine la région par l'IP, vous pouvez vérifier que la logique fonctionne correctement pour différents endroits.

Important : Utilisez les proxies mobiles uniquement pour tester votre propre application et dans le cadre de la loi. C'est un outil QA pour vérifier le bon fonctionnement de la logique régionale, pas un moyen de contourner quoi que ce soit. Des services de proxy mobile comme MobileProxy.space fournissent un accès légal à des IP mobiles pour de telles tâches.

Conseil : Combinez un proxy mobile pour changer le point de sortie avec un proxy MITM local pour lire le trafic. Ainsi, vous voyez simultanément le contenu des requêtes et vérifiez le comportement régional.

Vérification du résultat : checklist d'une configuration réussie

Parcourez cette liste pour vous assurer que tout fonctionne comme prévu.

• L'outil proxy est lancé et écoute sur le bon port.
• Le téléphone, l'émulateur ou le simulateur fait passer le trafic via le proxy.
• Le certificat racine du proxy est installé et approuvé sur l'appareil.
• Le trafic HTTPS du navigateur est lisible sous forme déchiffrée.
• Dans la build de débogage de l'application, le pinning est désactivé par des moyens standards.
• Les requêtes de votre application vers l'API s'affichent complètement dans le proxy.
• Vous savez filtrer, exporter, répéter et modifier les requêtes.

Comment tester

1. Lancez la build de débogage de l'application.
2. Exécutez un scénario typique, par exemple une connexion et le chargement de l'écran principal.
3. Vérifiez que des requêtes vers votre API avec un corps lisible apparaissent dans le proxy.
4. Répétez une requête et modifiez une réponse pour voir la réaction de l'application.

Indicateurs de succès. Vous voyez le cycle de vie complet de l'interaction réseau de votre application et pouvez influencer celui-ci pour les tests.

Erreurs typiques et solutions

Passons en revue les problèmes fréquents selon le schéma : problème, cause, solution.

L'application ignore le proxy système

Problème : Le trafic n'apparaît pas dans le proxy, alors que le navigateur fonctionne. Cause : L'application utilise sa propre pile réseau qui ne lit pas les paramètres système du proxy. Solution : Dans la build de débogage, configurez le client réseau pour qu'il tienne compte du proxy système, ou utilisez un mode proxy transparent au niveau du réseau.

Le trafic via QUIC n'est pas visible

Problème : Certaines requêtes manquent. Cause : L'application utilise le protocole QUIC sur UDP, que les proxies HTTP classiques n'interceptent pas. Solution : Dans la build de débogage, désactivez temporairement le support QUIC dans le client réseau pour que le trafic passe par HTTPS standard et devienne visible dans le proxy.

Nuances d'Android 14

Problème : Le certificat est installé mais l'application ne le voit pas. Cause : Dans les versions récentes d'Android, les règles de gestion des certificats utilisateur sont devenues plus strictes et les applications par défaut ne leur font pas confiance. Solution : Utilisez la configuration de sécurité réseau avec des redéfinitions de débogage ou le magasin système sur émulateur.

iOS ne déchiffre pas le trafic

Problème : Les requêtes de l'application sur iOS ne sont pas lisibles. Cause : Le certificat est installé mais la confiance totale n'est pas activée dans la section Confiance des certificats. Solution : Allez dans Réglages, Général, À propos, Confiance des certificats et activez l'interrupteur.

gRPC et HTTP/2

Problème : Les données sont visibles mais dans un format binaire incompréhensible. Cause : L'application utilise gRPC sur HTTP/2 avec sérialisation binaire. Solution : Utilisez des outils qui comprennent HTTP/2 et, si nécessaire, des plugins pour décoder le format des messages afin de lire le contenu.

Pas d'Internet après configuration du proxy

Problème : Le téléphone n'a plus d'accès Internet. Cause : L'outil proxy est éteint mais les paramètres de proxy sont toujours configurés. Solution : Allumez le proxy sur l'ordinateur ou supprimez les paramètres de proxy dans les paramètres Wi-Fi du téléphone.

Le pare-feu bloque les connexions

Problème : Le téléphone ne peut pas se connecter au proxy. Cause : Le pare-feu de l'ordinateur bloque les connexions entrantes sur le port du proxy. Solution : Ajoutez une règle d'autorisation pour le port du proxy dans le pare-feu intégré du système.

Fonctionnalités supplémentaires et paramètres avancés

Une fois la configuration de base maîtrisée, il est temps d'étendre l'arsenal.

Scripts et automatisation

mitmproxy permet d'écrire des scripts en Python qui modifient automatiquement les requêtes et réponses. C'est pratique pour les tests de régression et les scénarios complexes de substitution.

Sauvegarde des sessions

Sauvegardez les sessions de trafic enregistrées dans des fichiers pour y revenir plus tard ou les partager avec l'équipe. Cela accélère l'analyse des bugs.

Mapping vers des fichiers locaux

La fonction de substitution de réponse par un fichier local permet de développer l'interface de l'application indépendamment de la disponibilité du backend. Vous renvoyez simplement à l'application des réponses JSON préparées à l'avance.

Limitation de vitesse

De nombreux proxies peuvent ralentir artificiellement la connexion. Cela aide à vérifier le comportement de l'application sur un réseau lent et à trouver des problèmes de timeout.

Conseil : Rassemblez un ensemble de scénarios types de substitution et de ralentissement et réutilisez-les à chaque release. Cela transformera le débogage manuel en un processus de test reproductible.

FAQ : questions fréquemment posées

Faut-il root sur Android pour lire le trafic ?

Pour le magasin utilisateur et votre propre application avec une configuration debug, le root n'est pas nécessaire. Pour le magasin système sur un appareil réel, root est requis, mais il est plus simple d'utiliser un émulateur sans services Google.

Peut-on se passer d'installer un certificat ?

Sans certificat de confiance, vous ne verrez que les noms de domaine dans SNI, pas le contenu HTTPS. Pour lire les requêtes, le certificat est obligatoire.

Pourquoi le navigateur voit le trafic mais pas l'application ?

L'application intègre probablement un SSL pinning ou sa propre pile réseau. Configurez la build de débogage comme décrit à l'étape sur le pinning.

Est-il sécurisé d'installer le certificat racine du proxy ?

Sur un appareil de test et pour la durée du débogage, c'est acceptable. Après le travail, supprimez le certificat pour ne pas laisser une confiance étendue sur l'appareil.

Que faire si le trafic passe par QUIC ?

Désactivez QUIC dans la build de débogage du client réseau pour que les connexions passent par HTTPS standard et deviennent visibles par le proxy.

Peut-on analyser le trafic d'une application tierce ?

Non. Uniquement votre propre application ou une application avec l'autorisation explicite du propriétaire. C'est une règle de principe.

Charles ou mitmproxy : que choisir pour un débutant ?

Charles est plus simple pour démarrer grâce à son interface graphique. mitmproxy est plus puissant pour l'automatisation. Commencez par celui qui vous semble le plus pratique.

Comment supprimer toutes les modifications après le débogage ?

Supprimez les paramètres de proxy dans le Wi-Fi, supprimez le certificat installé dans les paramètres de sécurité et construisez l'application en configuration release avec toutes les vérifications.

Pourquoi la confiance du certificat ne fonctionne-t-elle pas sur iOS ?

Vous avez installé le profil mais n'avez pas activé la confiance totale dans la section Confiance des certificats. C'est une étape obligatoire distincte.

Peut-on visualiser le trafic sur un réseau lent ?

Oui, de nombreux proxies peuvent ralentir artificiellement la connexion pour tester le comportement de l'application en cas de mauvaise connexion Internet.

Conclusion

Félicitations, vous disposez désormais d'un ensemble complet de compétences pour analyser le trafic réseau de votre propre application mobile. Vous avez appris à choisir entre mitmproxy, Charles, Proxyman et Burp, à lancer un proxy local, à y faire passer le trafic du téléphone, de l'émulateur et du simulateur.

Vous avez compris comment fonctionne un proxy MITM et pourquoi un certificat racine de confiance est nécessaire, maîtrisé les subtilités des magasins de certificats sur Android 7 et versions ultérieures, et l'étape obligatoire de confiance sur iOS. Vous avez compris comment désactiver proprement et uniquement dans la build de débogage le SSL pinning par des moyens standards de la plateforme, sans jamais toucher à la release.

Enfin, vous savez lire, filtrer, exporter, répéter et modifier les requêtes, ainsi qu'utiliser des proxies mobiles pour vérifier le comportement régional de l'application dans le cadre de la loi.

Que faire ensuite

Consolidez cette compétence sur un projet réel : configurez l'interception du trafic de votre application et ajoutez des scénarios types de substitution de réponses dans le processus de test. Progressivement, explorez les scripts d'automatisation et partagez les sessions de trafic avec l'équipe.

Où aller ensuite : approfondissez l'analyse de HTTP/2 et gRPC, apprenez à écrire des scripts pour mitmproxy, maîtrisez l'intégration de l'interception de trafic dans les tests automatisés. Et rappelez-vous toujours la règle d'or : travaillez uniquement avec votre propre application ou avec l'autorisation explicite du propriétaire, en respectant la législation et la vie privée des utilisateurs.