
La réponse courte est celle que personne ne veut : sur le téléphone, ce n’est pas possible. Il n’y a pas d’Inspecter l’élément dans le Safari mobile, pas d’appui long qui ouvre les outils de développement, et aucun réglage qui en ajoute.
Ce qui existe à la place, c’est l’inspecteur web, qui tourne sur un Mac et se rattache au téléphone par un câble. C’est le vrai outil - les mêmes panneaux que sur le bureau, montrant la page telle que le téléphone la rend réellement - et il demande un matériel que la plupart des gens qui posent cette question n’ont pas devant eux.
Avec un Mac, ce qui est la bonne méthode
Trois étapes, et les deux premières sont des réglages qu’on ne fait qu’une fois.
Sur l’iPhone ou l’iPad. Ouvrez Réglages, puis Apps → Safari → Avancé, et activez Inspecteur web. Sur iOS 17 et antérieur, le chemin est Réglages → Safari → Avancé, sans le niveau Apps.
Sur le Mac. Ouvrez Safari → Réglages → Avancés et cochez Afficher les fonctionnalités pour développeurs web, ce qui ajoute un menu Développement dans la barre des menus. Sur les versions plus anciennes, la case s’appelle “Afficher le menu Développement dans la barre des menus”. C’est le même interrupteur que celui dont vous avez besoin pour inspecter quoi que ce soit sur le Mac lui-même.
Puis reliez-les. Branchez le téléphone au Mac avec un câble et déverrouillez-le. S’il demande s’il faut faire confiance à cet ordinateur, dites oui. Ouvrez la page sur le téléphone, puis sur le Mac ouvrez Développement, trouvez l’appareil par son nom dans la liste, et choisissez la page. L’inspecteur web s’ouvre sur le Mac et pilote le téléphone : survolez un élément sur le Mac et il est mis en évidence sur l’appareil.
Deux choses qui coincent à ce moment-là. Si l’appareil n’apparaît pas, le téléphone est verrouillé, le câble ne sert qu’à charger, ou l’inspecteur web n’a jamais été activé. Et vous ne pouvez inspecter que Safari par ce biais - Chrome et Firefox sur iOS ne sont pas inspectables depuis le menu Développement, ce qui compte moins qu’il n’y paraît, puisque tous les navigateurs sur iOS rendent avec le même moteur WebKit en dessous.
Sur un iPad, c’est la même procédure
Identique, y compris les chemins dans les réglages. La seule différence à connaître est qu’un iPad en Stage Manager ou en écran partagé annonce un viewport qui n’est pas la largeur entière de l’écran, si bien qu’un bug de mise en page que vous poursuivez peut dépendre de la disposition plutôt que de l’appareil.
Sans Mac
Trois options, par ordre décroissant de ce qu’elles vous apprennent vraiment.
Un service de débogage à distance. Plusieurs sociétés louent de vrais iPhones avec l’inspecteur web rattaché, dans un onglet de navigateur. Ils coûtent de l’argent et ils marchent, et pour une équipe qui livre sur iOS et ne possède aucun Mac, c’est la réponse honnête.
Une console embarquée dans votre propre page. Si vous maîtrisez le site, une petite bibliothèque de console dans la page vous donne un journal lisible sur l’appareil lui-même. C’est la seule voie qui ne demande pas une deuxième machine, et elle est faite pour les versions de développement plutôt que pour la production, parce que vous livrez une surface de débogage à tout le monde.
La simulation d’appareil sur le bureau, qui n’est pas la même chose. La barre d’appareils de Chrome change le viewport, l’user agent et le comportement tactile, et elle est vraiment utile pour vérifier une mise en page responsive. Elle ne change pas le moteur : vous regardez toujours Blink qui joue au téléphone. Un bug qui n’apparaît que sur iOS est le plus souvent un bug de WebKit, et WebKit est précisément la partie que la simulation ne simule pas. (C’est le seul endroit où Android est plus facile : son Chrome est le même moteur que votre Chrome de bureau, donc le mode appareil y est une première supposition raisonnable.)
Cette dernière distinction est celle qui coûte une journée aux équipes : “ça a l’air correct dans la vue téléphone” et “ça marche sur le téléphone” sont deux affirmations différentes.
Session Replay
Extension Chrome gratuite. Un clic sur la page qui se comporte mal capture la capture d'écran, la console et le journal réseau, et vous rend un lien à coller dans le ticket.
Quand la personne qui a le téléphone n’est pas vous
La plupart du temps, cette question ne porte pas vraiment sur l’outillage. Quelqu’un a signalé que votre site est cassé sur son iPhone, il n’est pas assis à côté de vous, il ne possède pas de Mac, et lui demander d’activer l’inspecteur web et de trouver un câble n’est pas une demande que vous pouvez raisonnablement faire.
Ce que vous pouvez demander, et qui vaut la peine d’être obtenu :
- La version exacte d’iOS et le navigateur. Réglages → Général → Informations donne la version. “iPhone” n’est pas une réponse ; iOS 26.1 dans Safari, oui.
- Un enregistrement de l’écran. L’iPhone rend cela facile depuis le centre de contrôle, et cela capture le comportement, le rythme et ce sur quoi la personne a appuyé, c’est-à-dire l’essentiel de ce que vous auriez regardé de toute façon.
- Le texte exact de ce qui s’affiche, photographié s’il le faut. Un message d’erreur se cherche dans votre code ; la description d’un message d’erreur, non.
- Si cela arrive aussi dans un onglet privé. Cette seule question sépare un bug de votre page de ce que font une extension, une ressource en cache ou un service worker périmé.
Ces quatre éléments vont au même endroit que tout le reste de ce que vous demanderiez, et notre guide du rapport de bug donne le reste de la forme.
Il faut être francs sur nos propres limites ici, puisque cette page parle de mobile. Notre extension est une extension Chrome de bureau : elle capture la console et le journal réseau sur un ordinateur, pas sur un téléphone. Si votre visiteur appuie sur un bouton de signalement depuis un iPhone, ce qu’il obtient est une explication et un lien à emporter vers un navigateur de bureau - utile pour que le rapport soit déposé, et pas un substitut à la sortie console que vous auriez eue avec un Mac.
Pour les bugs de bureau, elle supprime tout ce problème, parce que la moitié technique est capturée par la personne qui appuie sur un bouton. Pour un bug qui n’arrive que sur l’iPhone de quelqu’un, un enregistrement d’écran et un numéro de version exact restent le mieux que vous obtiendrez sans câble.
Si vous déboguez votre propre téléphone
Cela mérite d’être dit clairement, parce que la longue réponse ci-dessus vise le cas courant. Si c’est votre appareil, votre Mac et votre page, branchez le câble et servez-vous de l’inspecteur web. Tout le reste de cette page est un contournement pour quand ce n’est pas possible.
Aide-mémoire
- iPhone/iPad : Réglages → Apps → Safari → Avancé → Inspecteur web activé. (Réglages → Safari → Avancé sur iOS 17 et antérieur.)
- Mac : Safari → Réglages → Avancés → Afficher les fonctionnalités pour développeurs web.
- Reliez par câble, déverrouillez, faites confiance, puis Développement → appareil → page.
- Safari uniquement. Tous les navigateurs iOS utilisent WebKit, quel que soit leur nom.
- Le “mode appareil” du bureau teste la mise en page, pas le moteur.