Elements : inspecter et modifier en direct
L’arbre DOM vivant de la page, avec styles calculés, héritage et modèle de boîte. Changez une valeur et l’appareil se redessine sur-le-champ : le chemin le plus court vers un bug de mise en page mobile.
Comme un F12 dans votre propre navigateur, mais sur les pages ouvertes sur un iPhone ou un Android réel : onglets du navigateur, ou WebView / H5 intégrée à une app. Inspection des éléments, erreurs de console, points d’arrêt, requêtes réseau, cookies et stockage local.

Tout ce qui suit est le quotidien du débogage d’une page sur téléphone. La colonne de gauche, c’est la façon habituelle.
| Ce que vous cherchez à faire | La méthode habituelle | Avec l’inspecteur web |
|---|---|---|
| La mise en page ne casse que sur le téléphone | Deviner le correctif, rebuilder, redéployer, regarder à nouveau | Modifier l’élément et son CSS en direct et voir l’appareil se rafraîchir aussitôt |
| Page blanche ou bouton qui ne fait rien | Pas de console sur un téléphone : on ajoute des alertes et des logs | Les erreurs et les logs exactement tels que la page les a émis |
| Trouver quelle ligne de JavaScript a déclenché une requête | Un outil de capture montre la requête, jamais l’appelant | Points d’arrêt et exécution pas à pas dans Sources, variables à l’appui |
| Voir ce qu’il y a vraiment dans les cookies et le localStorage | Le deviner à partir des en-têtes de requête | Des tables complètes — nom, valeur, domaine, expiration, Secure, HttpOnly, SameSite — modifiables |
| Déboguer une page H5 intégrée dans une application | Noyée dans le trafic, sans moyen de s’y attacher | Listée sous l’application qui la contient : on la choisit et on la débogue comme n’importe quelle page |
| Simplement faire fonctionner le débogage à distance | Options propres à chaque plateforme, points d’entrée cachés, étapes fastidieuses | Une seule boîte de dialogue : choisir l’appareil, choisir la page, cliquer sur Déboguer |
| Lire le trafic et l’état de la page ensemble | Un outil de capture et un débogueur, côte à côte, sans lien | Les deux dans un seul outil : la requête déchiffrée et le code qui l’a envoyée |
Pas une visionneuse allégée : les mêmes panneaux que sur votre ordinateur, attachés à la page qui tourne sur le téléphone.
L’arbre DOM vivant de la page, avec styles calculés, héritage et modèle de boîte. Changez une valeur et l’appareil se redessine sur-le-champ : le chemin le plus court vers un bug de mise en page mobile.
Toutes les erreurs et tous les logs produits par la page, plus une invite qui exécute votre JavaScript dans cette page, sur cet appareil. Fini le débogage à coups d’alert().
Parcourez les scripts et feuilles de style chargés, posez des points d’arrêt, remontez la pile d’appels et inspectez les variables au moment précis où ça dérape.
Statut, type, initiateur, taille, chronologie et état du cache pour chaque requête, avec les totaux : nombre de requêtes, octets transférés, DOMContentLoaded et temps de chargement complet.
Cookies groupés par domaine avec expiration, Secure, HttpOnly et SameSite, à côté du localStorage et du sessionStorage — le plus rapide pour démêler un bug d’état de connexion.
Sous Android, la page en cours est reproduite à côté des panneaux et se pilote à la souris : inspection et manipulation sur un seul écran, sans jongler entre le téléphone et le clavier.
De vraies sessions sur un vrai téléphone — rien de mis en scène.



Téléphones, tablettes, émulateurs et simulateurs, plus un navigateur sur votre propre machine.
| Cet ordinateur | iOS | Android | |
|---|---|---|---|
| Onglets de navigateur | ✓ | ✓ | ✓ |
| Pages dans les applications (WebView / WKWebView / H5) | ✓ | ✓ | ✓ |
| Émulateur / simulateur | — | ✓ | ✓ |
| Inspecter et modifier éléments et styles en direct | ✓ | ✓ | ✓ |
| Console, points d’arrêt et pas à pas | ✓ | ✓ | ✓ |
| Cascade réseau de la page | ✓ | ✓ | ✓ |
| Cookies / localStorage / sessionStorage | ✓ | ✓ | ✓ |
| Écran de l’appareil à côté des panneaux | — | — | ✓ |
| Ni certificat ni proxy à configurer | ✓ | ✓ | ✓ |
Les trois blocs ci-dessous sont des alternatives : faites celui qui correspond à votre cible, une bonne fois pour toutes.
Branchez le câble et laissez l’appareil déverrouillé. Pour Safari, activez Réglages → Safari → Avancé → Inspecteur web ; pour Chrome, Réglages Chrome → Réglages de contenu → Inspecteur web.
Branchez le câble et activez le débogage USB dans les options pour développeurs. Les émulateurs sont généralement repérés sans câble.
Lancez Chrome ou Edge avec --remote-debugging-port=9222, puis cliquez sur Actualiser dans la liste des pages.
Inutile si vous ne visez que des onglets. Votre propre app : sur Android, appelez une fois setWebContentsDebuggingEnabled(true) ; à partir d’iOS 16.4, mettez isInspectable = true sur la WKWebView. App d’un tiers, ou sans toucher au code : cochez « Inclure aussi les pages dans les apps » et les pages des apps ouvertes s’ajoutent à la liste — appareil Android rooté requis, et côté iOS uniquement pour les apps signées en développement.
Nouvelle capture → cible (Cet ordinateur / iOS / Android) → méthode « Inspecteur web » → Actualiser → choisir la page → Inspect. Des outils de développement complets s’ouvrent dans votre navigateur ; autant de sessions que vous voulez, en parallèle.


La plupart des applications sont mi-natives, mi-web. C’est dans ces pages H5 intégrées que se logent les bugs pénibles — et là que l’outillage habituel ne donne rien.
La liste des pages est organisée par application : vous distinguez d’un coup d’œil une page de paiement intégrée d’un onglet de navigateur et vous attachez à celle que vous visez.
« Inclure aussi les pages dans les applications » ajoute à la liste les pages des applications actuellement ouvertes. Décochez, et il ne reste que les onglets de navigateur.
Pas de rebuild de l’application, rien à signer, aucun utilitaire installé sur l’appareil. La session terminée, l’appareil redevient ce qu’il était.
Déboguez la page ici et capturez le trafic de la même application dans le même outil — HTTPS déchiffré, y compris pour les applications à certificat épinglé ou qui ignorent le proxy système.
Connectez le téléphone à l’ordinateur en USB, ouvrez Trace Eagle, choisissez Nouvelle capture → iOS ou Android → méthode « Inspecteur web », sélectionnez la page et cliquez sur Déboguer. Un panneau Elements complet s’ouvre sur votre ordinateur avec le DOM et le CSS en direct de la page de l’appareil ; y modifier une valeur change immédiatement la page sur le téléphone.
Oui. Les WebView qui autorisent déjà le débogage apparaissent directement dans la liste. Pour les applications qui ne l’exposent pas, cochez « Inclure aussi les pages dans les applications » et les pages des applications ouvertes s’ajoutent — cela demande un appareil rooté, et rien n’est reconstruit, repackagé ni installé durablement.
Branchez l’appareil, déverrouillez-le et activez Réglages → Safari → Avancé → Inspecteur web (ou Réglages de Chrome → Paramètres de contenu → Inspecteur web). Choisissez ensuite l’appareil et la page dans Trace Eagle et cliquez sur Déboguer : l’inspecteur web complet s’ouvre dans le navigateur de votre ordinateur, avec Elements, Console, Sources, Network, Storage, Layers et plus.
Cela couvre le même besoin, et davantage, dans une seule boîte de dialogue. La page de débogage à distance du navigateur ne gère que les cibles Chromium sous Android ; ici, iOS, Android et votre navigateur local sont dans le même sélecteur, les pages sont regroupées par application, les pages H5 intégrées s’ajoutent d’une case à cocher, et le tout voisine avec un outil de capture qui déchiffre le trafic HTTPS de la même application.
Non, pas pour un débogage ordinaire : les onglets de navigateur et les applications qui l’autorisent déjà fonctionnent sur un appareil d’origine. Seule l’option supplémentaire qui ajoute les pages des applications tierces exige un appareil Android rooté ; sous iOS, c’est le système qui décide des applications incluables.
Aucun des trois. Le débogage web à distance passe par la connexion USB : pas de proxy à configurer, pas de certificat racine à installer sur l’appareil, pas de SDK ni de bibliothèque à ajouter à l’application.
La capture répond à « qu’est-ce qui est passé sur le réseau » : la requête, la réponse, les en-têtes et le corps, déchiffrés. L’inspecteur web répond à « qu’a fait la page » : le DOM, les styles, les erreurs console, quel script a déclenché la requête et ce qui se trouvait déjà dans les cookies et le stockage. Trace Eagle embarque les deux, vous passez de l’un à l’autre sans changer d’outil.
Les sessions Android et navigateur local s’ouvrent dans Chrome, Edge ou Brave (Trace Eagle en lance un pour vous) ; les sessions iOS fonctionnent dans n’importe quel navigateur.
Oui. Les émulateurs Android sont généralement détectés sans câble, et les simulateurs iOS lancés sur la machine le sont aussi — la procédure est identique à celle d’un appareil physique.
Oui. Comme le reste de Trace Eagle, il est entièrement gratuit sur macOS, Windows et Linux, sans fonctionnalité payante.