Comment changer le User-Agent dans Chrome (2026) : DevTools ou extension ?
Le serveur vous affiche la page mobile, le layout IE cassé, la bannière géo-bloquée — et derrière tout cela, une seule ligne a décidé votre sort : l’en-tête User-Agent. Le modifier est le plus vieux trick de développement du web : vérifier ce qu’un site sert aux mobiles sans en posséder, reproduire un bug qui n’apparaît que sur un vieux navigateur, voir à peu près ce que voit le crawler. En 2026, Chrome offre trois voies réalistes — deux dans DevTools et une extension — et ce qui les sépare, c’est la portée et la tenue, pas la capacité.
Ce que le User-Agent dit vraiment aux serveurs
L’en-tête est une simple ligne en clair dans chaque requête :
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Anatomie : le préfixe Mozilla/5.0 est une poignée de main de compatibilité héritée des guerres des navigateurs que personne n’ose retirer. La partie entre parenthèses nomme votre système d’exploitation. AppleWebKit et KHTML déclarent le moteur de rendu, Chrome/… la version du navigateur, et le Safari/… final est une politesse héritée de plus. Les serveurs analysent cette chaîne avant le moindre octet de HTML : elle choisit la mise en page mobile ou bureau, active ou coupe des fonctions, décide des bannières App Store, parfois même du fichier que vous téléchargez. Cette décision se prend sur le fil — exactement la partie que vous pouvez réécrire.
Méthode 1 : le mode appareil de DevTools
La vérification ponctuelle la plus rapide. Ouvrez DevTools avec F12, activez la barre d’outils appareil (Ctrl+Shift+M) et choisissez un appareil prédéfini — ou ouvrez le menu déroulant UA et sélectionnez « Autre… » pour coller la chaîne de votre choix. Chrome envoie alors le User-Agent choisi pour les requêtes de cet onglet, et les serveurs qui décident par en-tête répondent immédiatement par la page mobile.
Le piège est voulu : l’écrasement appartient à cet onglet et à cette session DevTools. Rechargez, fermez l’onglet ou éteignez le navigateur et votre vrai User-Agent revient. Parfait pour un rapide « à quoi ça ressemble sur un iPhone » ; inutile comme configuration permanente sur laquelle compter chaque jour.
Méthode 2 : écrasement via le menu de commandes / flags de lancement
Le menu de commandes de DevTools (Ctrl+Shift+P) expose les mêmes écrasements d’appareil, Paramètres → Appareils permet d’éditer la liste des UA, et vous pouvez même lancer Chrome avec le commutateur --user-agent. Limites honnêtes : les variantes DevTools se réinitialisent tout aussi obstinément et sont pénibles à garder configurées, tandis que le flag de lancement estampille chaque onglet de cette fenêtre de la même identité fausse — l’inverse du confinement. Aucune des deux n’est un workflow de tous les jours.
Méthode 3 : une extension d’en-têtes (recommandée pour un travail répété)
Si vous changez de User-Agent plus d’une fois par semaine, VKT Header en fait une opération enregistrée, cantonnée et auto-nettoyante. C’est une extension Manifest V3 pour Chrome/Edge qui réécrit les en-têtes de requête via des règles de session declarativeNetRequest :
- Modèles : enregistrez « iPhone Safari », « Old Chrome », « Googlebot » en profils — appliquez-en un d’un clic au lieu de coller une chaîne à chaque fois.
- Isolation par onglet : les règles s’appliquent à l’onglet ciblé, l’UA fausse ne vous suit pas partout.
- Correspondance d’URL : liez un modèle à des URL précises pour que le bon onglet de test reçoive automatiquement la bonne identité.
- Auto-nettoyage : les règles de session meurent quand l’onglet se ferme ou que le navigateur redémarre — aucune UA oubliée se faisant passer pour vous la semaine prochaine.
L’offre gratuite couvre 5 profils de 5 en-têtes chacun ; Premium ($9.99 à vie en une fois, ou $2.99/mois) lève les plafonds et ajoute le support prioritaire. Installez-la depuis le store Edge Add-ons, ou utilisez le lien d’installation Chrome de la page produit. Une frontière honnête : VKT Header ne change que les en-têtes de requête — lisez la réserve ci-dessous avant de lui demander plus.
Les trois méthodes côte à côte
| Méthode | Persistance | Portée | Rapidité de mise en place | Nettoyage |
|---|---|---|---|---|
| Mode appareil DevTools | Jusqu’au rechargement ou à la fermeture de l’onglet | Cet onglet seul | Secondes | Disparaît seul — et disparaît quand vous en avez besoin |
| Écrasement menu de commandes / flag de lancement | Réinitialisé au redémarrage ; le flag dure la fenêtre | Onglet (DevTools) ou fenêtre entière (flag) | Pénible à garder configurée | Imprévisible |
| VKT Header | Profils gardés à jamais ; règles par onglet | Un onglet, ou les onglets appariés par URL | Un clic après réglage | Automatique — fermer l’onglet efface chaque règle |
L’honnête réserve : en-têtes contre empreinte du navigateur
Changer l’en-tête User-Agent change ce que le serveur lit sur le fil. Cela ne change pas ce que lit JavaScript : navigator.userAgent continue d’annoncer votre vrai navigateur, et le fingerprinting moderne — client hints, canvas, réalité des plugins — peut trahir le désaccord. C’est très bien pour tester et vérifier la compatibilité, c’est exactement son usage. Cela veut dire aussi qu’il ne faut pas se servir d’un changement d’UA pour tromper : les sites sensibles comme les banques et les stores signalent le désaccord, et les conditions d’utilisation de certains services interdisent carrément de déclarer faux votre client. Testez avec ; ne vous déguisez pas avec.
Questions fréquentes
La modification du User-Agent dans DevTools s’applique-t-elle à tous les onglets ?
Non. L’écrasement de DevTools est limité à l’onglet dont vous avez configuré les DevTools, et il est temporaire — rechargez la page ou fermez l’onglet et votre véritable User-Agent revient. Les flags de lancement sont l’extrême inverse : ils estampillent chaque fenêtre démarrée avec ce flag.
Les serveurs me serviront-ils vraiment des pages mobiles ?
Séparons honnêtement la question. Si le serveur décide sur l’en-tête User-Agent — c’est le cas de la plupart des bascules mobile/bureau —, oui, vous obtiendrez la page mobile. Si la décision se prend côté client, dans JavaScript ou le fingerprinting qui lit navigator.userAgent et d’autres signaux, changer seul l’en-tête ne le convaincra pas — et ne devrait pas essayer.
Changer le User-Agent est-il légal ?
Pour tester, développer et vérifier la compatibilité, c’est un workflow de développeur ordinaire. Déclarer faux votre client pour contourner des restrictions peut violer les conditions d’utilisation d’un site — et davantage dans certaines juridictions. Dans le doute, testez sur des systèmes que vous possédez ou que vous avez l’autorisation de tester. Ceci n’est pas un conseil juridique.
Quelle est la meilleure façon gratuite de conserver un User-Agent personnalisé ?
L’offre gratuite de VKT Header stocke 5 profils avec 5 en-têtes chacun — y compris isolation par onglet, correspondance d’URL et import/export —, une identité « iPhone Safari » enregistrée est à un clic, et elle s’efface seule à la fermeture de l’onglet. Premium lève les plafonds pour $9.99 à vie, en une fois.
Pourquoi ma banque ou mon app proteste-t-elle après un changement de User-Agent ?
Parce que l’en-tête ne concorde plus avec l’empreinte réelle de votre navigateur — c’est exactement la réserve honnête ci-dessus, et la détection de fraude le traite comme un signal d’alarme. Effacez la règle et tout se comportera de nouveau normalement. Avec l’auto-nettoyage de VKT Header, fermer l’onglet l’a déjà effacée.
Notre avis : DevTools répond à « qu’est-ce que cette page sert à un iPhone, maintenant ». Une extension à portée par onglet répond à « tous les jours, pour exactement un onglet, puis plus jamais » — profils enregistrés, correspondance d’URL et règles de session qui meurent avec l’onglet font de VKT Header le choix au quotidien du travail UA répétitif, gratuit pour démarrer avec 5 profils.
Plus d’outils VKT dans le catalogue des extensions, ou écrivez-nous à [email protected].
