Profils navigateur multi-plateforme : une identité sur chaque hôte

Une comparaison entre plateformes n'est valable que si l'identité cible, la révision du profil, les paramètres de lancement et le relevé de l'hôte restent liés. BotBrowser utilise le profil comme source d'identité ; il ne promet pas un comportement identique sur tous les hôtes ou sites.

TL;DR

Comparez des relevés fixes, isolez une version ou un paramètre modifié et traitez un écart comme une décision de version, pas comme une garantie du profil.

Sommaire

• Une chaîne User-Agent n'est pas une identité
• Les familles de signaux qu'un profil doit garder alignées
• Hôtes, cibles et matrice de prise en charge documentée
• Comparez les hôtes et investiguez les écarts
• Profils multi-plateforme et fonctionnement Per-Context
• Ce que couvre BotBrowser et où il s'arrête
• Conclusion

Une chaîne User-Agent n'est pas une identité

L'identité d'un navigateur ne se résume pas à un en-tête. Un site web peut lire le nom de la plateforme, la marque et la version du navigateur, les polices installées, le comportement graphique, la taille d'écran, les listes de langues, le fuseau horaire et les capacités multimédias, puis comparer ces valeurs entre elles. Un navigateur qui annonce un User-Agent Windows alors que ses polices, son écran et son comportement graphique viennent d'un serveur Linux présente un tableau mélangé. Ce mélange est un risque pour la confidentialité des personnes qui s'appuient sur le profil, et un problème de support pour l'équipe qui doit expliquer pourquoi le même flux de travail se comporte différemment sur deux machines. BotBrowser peut garder cohérentes les valeurs d'identité d'un profil sélectionné d'un système d'exploitation hôte à l'autre ; il ne peut pas changer la façon dont un site ou un serveur traite cette identité.

Le besoin est concret. Une équipe peut utiliser en même temps des serveurs Linux pour le passage à l'échelle, des postes macOS pour le développement, des machines Windows pour les flux de bureau et des identités cibles Android pour valider le trafic mobile. Le support doit reproduire le cas d'un client sans monter un laboratoire matériel, et la QA a besoin d'une base stable avant d'approuver une version. Si l'identité du navigateur suit l'hôte, chacun de ces groupes voit quelque chose de légèrement différent. Si elle suit le profil, ils peuvent comparer leurs résultats en confiance.

Les User-Agent Client Hints éclairent ce point. MDN décrit l'API User-Agent Client Hints comme un moyen d'exposer des informations sur le navigateur et la plateforme par des en-têtes de requête et de réponse et par une interface JavaScript, avec un petit ensemble de valeurs par défaut et des détails supplémentaires renvoyés seulement lorsqu'un serveur les demande. Ces valeurs doivent concorder avec la chaîne User-Agent, entre elles et avec le reste du profil. Modifier la chaîne tout en laissant les valeurs structurées à celles de l'hôte crée exactement le type d'incohérence qu'une identité cohérente doit éviter.

C'est la raison pour laquelle le profil doit être la source de l'identité. Un profil est un fichier qui consigne les valeurs de toute l'identité, de sorte que le système d'exploitation de l'hôte cesse d'être la réponse par défaut à chaque question posée au navigateur. La documentation des profils multi-plateforme de BotBrowser décrit le modèle ainsi : les surfaces d'identité proviennent des données du profil, notamment le User-Agent, l'écran, les polices, le GPU et la pile de langues, et les différences de l'hôte sont contraintes pour que le profil reste la source principale.

Un cas concret montre ce que cela signifie. Imaginez un profil cible Windows exécuté sur un serveur Linux. Le nom de la plateforme, les valeurs structurées de marque, le jeu de polices, les métriques d'écran et la description du GPU doivent tous décrire un poste de bureau Windows, même si la machine sous-jacente est un serveur Linux. Le flux de travail doit aussi se comporter, en arrivant sur une page, comme sur une vraie cible Windows. Si une seule famille reflète encore l'hôte Linux, l'identité n'est appliquée qu'en partie, et c'est l'écart qu'une comparaison entre hôtes doit révéler.

Les familles de signaux qu'un profil doit garder alignées

Consignez userAgent, platform, brands, screen.width, screen.height, devicePixelRatio, languages, locale et timeZone avant de comparer deux hôtes.

Il est utile de raisonner en familles de signaux plutôt qu'en propriétés isolées. Pour la plateforme cible choisie, un profil doit garder ces familles alignées entre elles :

• Plateforme et marque du navigateur : la chaîne User-Agent, les valeurs structurées de Client Hints et la marque annoncée dans les en-têtes doivent désigner la même plateforme et la même version du navigateur.
• Écran et métriques de l'appareil : la résolution, la profondeur de couleur, le ratio de pixels et la prise en charge du tactile doivent correspondre à la classe d'appareil de la cible, qu'il s'agisse d'un écran de bureau ou d'un téléphone Android.
• Polices et rendu du texte : le jeu de polices installées et la mise en page du texte doivent suivre la plateforme cible, y compris pour le texte d'Asie de l'Est lorsque c'est pertinent.
• Comportement graphique : la description du GPU et le rendu de canvas et de WebGL doivent rester dans la classe d'appareil décrite par le profil.
• Langue, paramètres régionaux et heure : les listes de langues, le formatage régional et le fuseau horaire doivent concorder entre eux et avec la région que le flux de travail doit représenter.
• Capacités multimédias et de stockage : les codecs, la classe de mémoire et des valeurs similaires doivent être plausibles pour l'appareil cible.

Famille de signaux	À consigner avant de comparer les hôtes	À rejeter comme incohérence quand
Identité navigateur	userAgent, platform, brands	la cible déclarée diffère entre les champs
Affichage	screen.width, screen.height, devicePixelRatio	une valeur décrit une autre classe d'appareil
Paramètres régionaux	languages, locale, timeZone	les valeurs désignent des régions incompatibles

Cette liste est une carte de ce qu'il faut comparer. Chaque famille peut être examinée à un niveau général, en vérifiant que la page se comporte comme prévu et que les valeurs relevées sur un hôte représentatif concordent avec la base approuvée par votre équipe. Nul besoin de lire chaque valeur de bas niveau pour remarquer qu'un profil cible Windows annonce une plateforme Linux, ou qu'un profil cible Android affiche encore un écran de bureau.

Le guide MDN sur les User-Agent Client Hints montre pourquoi la première famille demande de l'attention. Un petit ensemble de valeurs, comme la marque du navigateur, l'indicateur mobile et le nom de la plateforme, est envoyé par défaut. Des valeurs plus détaillées, comme la version de la plateforme, l'architecture et le modèle de l'appareil, ne sont renvoyées que si un serveur les demande. Un profil cohérent doit répondre de façon homogène aux valeurs par défaut comme aux valeurs demandées, pour que la réponse reçue par un site ne dépende pas de la question posée en premier.

Les polices méritent une mention particulière, car elles viennent directement de l'hôte tant que le profil n'en prend pas le contrôle. L'article sur la cohérence des polices explique pourquoi le comportement des polices doit suivre la plateforme cible, et la documentation sur le rendu des polices CJK décrit la cohérence typographique de l'Asie de l'Est pour les cas où le texte chinois, japonais ou coréen s'affiche différemment d'un hôte à l'autre.

Hôtes, cibles et matrice de prise en charge documentée

Deux termes aident à planifier clairement. L'hôte est la machine et le système d'exploitation qui exécutent le navigateur. La cible est la plateforme que décrit le profil. Dans un modèle piloté par le profil, les deux peuvent différer volontairement : un profil cible Windows peut s'exécuter sur un portable macOS pendant le développement et sur un serveur Linux en production.

Choisir une cible est une décision de produit, pas une décision d'hôte. Décidez quelle plateforme le flux de travail doit représenter, choisissez le profil correspondant, puis sélectionnez les hôtes selon le coût et la commodité. La documentation énumère les combinaisons prises en charge, et chaque cible de profil est prise en charge sur chaque classe d'hôte.

Cible du profil	Hôte Windows	Hôte macOS	Hôte Linux (ENT Tier1)
Profil Windows	Pris en charge	Pris en charge	Pris en charge
Profil macOS	Pris en charge	Pris en charge	Pris en charge
Profil Android	Pris en charge	Pris en charge	Pris en charge

Les autres prérequis sont une installation de BotBrowser sur chaque hôte et un fichier de profil au format .enc ou .json. Les hôtes Linux et Ubuntu exigent ENT Tier1. La documentation d'Android Emulation décrit les profils cibles Android comme une capacité de la licence PRO, et l'article sur les tests de profils Android montre comment un profil cible Android s'exécute depuis un hôte de bureau ou de serveur.

Les scénarios documentés suivent des chemins de livraison ordinaires. Une équipe peut développer sur macOS et déployer sur Linux en conservant un seul fichier de profil dans le contrôle de version ou dans un coffre de secrets, puis en le déployant tel quel. Une tâche de CI peut exécuter le même profil sur des runners Windows, macOS et Linux et comparer les résultats clés. Une flotte peut passer d'un hôte cloud à un autre sans régénérer les profils d'identité. Dans chaque cas, seul le chemin de l'exécutable change dans la commande de lancement, tandis que le fichier de profil et les paramètres de lancement restent identiques.

Traitez le fichier de profil comme un artefact de livraison versionné. Conservez-le dans le contrôle de version ou dans un coffre de secrets, attribuez un identifiant à chaque révision et consignez cet identifiant chaque fois qu'un hôte l'exécute. La documentation sur la gestion des profils couvre le cycle de vie et le versionnage des profils. Quand tous les hôtes lisent le même fichier au même endroit, un écart de résultats pointe vers l'hôte ou les paramètres de lancement, et non vers une copie égarée du profil.

Comparez les hôtes et investiguez les écarts

Une ligne de comparaison contient hostOs, botBrowserVersion, profileRevision, launchFlags, displayMode et result ; Windows 11, macOS 15 et Ubuntu 24.04 ne sont comparables que si profileRevision et launchFlags restent identiques.

Une affirmation de cohérence n'est utile que si elle repose sur des preuves. Ces preuves viennent d'une comparaison contrôlée toute simple, menée pendant des tests autorisés : gardez les entrées fixes, changez seulement l'hôte et notez ce qui se passe.

1. Fixez les entrées. Consignez dans le dossier de test la version de BotBrowser, le fichier de profil et les paramètres de lancement.
2. Choisissez des hôtes représentatifs. Utilisez au moins un hôte Windows, un hôte macOS et un hôte Linux proche de la production, y compris pour son affichage et sa configuration graphique.
3. Exécutez un flux de travail autorisé qui représente le travail réel, du lancement jusqu'à l'état de page attendu.
4. Comparez les grandes familles de signaux et le comportement de la page à la référence de la version : valeurs de plateforme, d'écran, de langue et d'heure, polices et rendu.
5. Conservez ensemble les captures d'écran, les notes et la décision approuvée, afin de pouvoir comparer la prochaine version à celle-ci.

Notez ce que vous observez en termes simples. « Le flux a atteint l'état de page attendu, les captures correspondaient à la référence et les valeurs de plateforme, d'écran et de langue concordaient avec le profil » est un résultat exploitable. « Ça avait l'air correct » n'en est pas un. Si le flux est sensible aux conditions de démarrage ou de rendu, exécutez-le plusieurs fois et conservez chaque résultat.

Chaque rôle lit la même comparaison pour des raisons différentes. La QA veut savoir si une version candidate correspond à la référence approuvée. Le support veut reproduire le cas d'un client sur les hôtes disponibles. La personne qui examine la confidentialité veut confirmer que l'identité présentée par un flux de travail est bien celle que décrit le profil, et non un effet de bord de la machine. Un seul dossier partagé sert les trois, à condition que les entrées soient notées avant la première exécution.

Les hôtes Linux demandent une vérification de préparation explicite. La documentation Headless Server Setup décrit la base Linux, et le guide du backend de rendu Linux explique comment le choix du backend de rendu influence le comportement graphique et le coût de déploiement. Considérez la configuration d'affichage et de rendu comme un prérequis de la version plutôt que comme un détail découvert après le déploiement.

La même méthode convient à une tâche de CI. La documentation suggère d'exécuter le profil sur des runners Windows, macOS et Linux et de comparer des résultats clés tels que les valeurs de plateforme, les langues, les valeurs d'écran et les résultats de rendu. Gardez la comparaison à ce niveau. Une famille générale concorde avec la référence ou non, et un écart est une raison d'investiguer avant la mise en production. Pour un traitement plus long des dossiers d'acceptation, de la responsabilité du déploiement et du coût d'exécution, lisez comment évaluer la cohérence du navigateur entre plateformes avant le déploiement.

Quand deux hôtes divergent, la première question est de savoir ce qui a changé. Le guide de dépannage pour des résultats différents d'un hôte à l'autre recommande de vérifier la même version de BotBrowser, le même fichier de profil et les mêmes paramètres de lancement. Ces trois entrées expliquent la plupart des écarts et se contrôlent à peu de frais.

• Dérive de version : un hôte exécute une autre version de BotBrowser.
• Dérive de profil : un autre fichier de profil, ou une copie plus ancienne du même, a été utilisé.
• Dérive de paramètres : les paramètres de lancement diffèrent entre un poste de développement et un runner de CI.
• Backend de rendu : des différences liées au GPU peuvent apparaître en mode headless, et la documentation renvoie au guide Headless Server Setup et au réglage du mode GPU.
• Polices et rendu du texte : le texte d'Asie de l'Est peut différer d'un hôte à l'autre et dispose de son propre guide.
• Hôte non pris en charge : un hôte Linux sans ENT Tier1 est hors de la matrice de prise en charge documentée.

Traitez chaque élément comme une hypothèse, changez une variable à la fois et relancez le même flux de travail. Un écart entre hôtes n'est jamais la preuve que l'identité est cohérente. C'est la trace d'une différence qui doit encore avoir un responsable. De même, une concordance sur un hôte ne se transmet pas automatiquement à une nouvelle image d'hôte, à un nouveau paquet de profil ou à une nouvelle version du navigateur : refaites la comparaison dès que l'un d'eux change.

Décidez à l'avance quand vous arrêter. Un état de page inattendu, un résultat de rendu qui empêche le travail, un résultat que personne ne parvient à reproduire ou un hôte auquel manque un prérequis documenté sont autant de raisons de suspendre le déploiement et de revenir à la dernière référence approuvée. Qualifiez un résultat peu clair d'inconclusif plutôt que de le déclarer valide, et attribuez-lui un responsable et une date pour la prochaine vérification. Une incertitude exprimée clairement vaut mieux qu'une fausse assurance quand une décision de production en dépend.

Une personne du support peut appliquer le même ordre de questions à un signalement client : version, profil, paramètres, backend de rendu, puis hôte. Suivre le même ordre à chaque fois rend les résultats comparables et raccourcit les investigations.

La région mérite une note à part. Le profil fournit l'identité de plateforme, tandis que le fuseau horaire, les paramètres régionaux et les langues d'un flux régional peuvent être définis explicitement par des paramètres de lancement, afin qu'ils concordent entre eux et avec le profil. Consignez ces valeurs dans le dossier de test avec les autres entrées, pour qu'une exécution ultérieure parte de la même base régionale. Le comportement des dates, des heures et des fuseaux horaires selon les environnements est présenté dans Formatage des dates et portabilité des fuseaux horaires.

Profils multi-plateforme et fonctionnement Per-Context

Avant la première page, associez au contexte profileRevision, locale, timeZone et une étiquette comme retailer-de-desktop, afin de le retrouver sur un autre hôte.

Les équipes qui ont besoin de nombreuses identités se demandent souvent s'il faut lancer un navigateur par identité. La documentation de Per-Context Fingerprint décrit une alternative : attribuer un lot d'empreinte distinct à chaque contexte de navigateur au sein d'une même instance, ce qui réduit la charge et garde les comptes séparés. Per-Context Fingerprint est une capacité ENT Tier3.

Les deux idées résolvent des parties différentes d'un même problème. Les profils multi-plateforme gardent une identité liée au profil plutôt qu'à l'hôte. Le fonctionnement Per-Context permet à une instance de navigateur de contenir plusieurs de ces identités, chacune avec son propre profil, ses valeurs de langue et d'heure et ses métriques d'écran. Selon la documentation, les workers créés dans un contexte héritent de l'identité de ce contexte.

La documentation précise aussi que les paramètres qui portent l'identité doivent être définis avant la création de la première page ou du premier worker d'un contexte, car cette première page ou ce premier worker fige l'identité du contexte. Planifiez l'ordre des opérations en conséquence et validez chaque contexte avec la même comparaison entre hôtes que pour un profil unique. La capacité dépend de l'hôte, de la charge et du plan : mesurez-la sur les hôtes que vous comptez exploiter.

Le fonctionnement Per-Context ne change pas l'habitude de validation. Validez un ensemble représentatif de contextes sur chaque classe d'hôte, notez quel profil chacun a utilisé et comparez les mêmes grandes familles. Si un contexte utilise un profil cible Android sur un hôte de bureau, examinez-le avec les vérifications Android plutôt qu'avec celles du bureau. Tenir les dossiers par contexte permet aussi de voir plus facilement si un écart concerne une identité ou tout l'hôte.

Ce que couvre BotBrowser et où il s'arrête

BotBrowser peut conserver le profil choisi comme source du User-Agent, de l'écran, des polices, du GPU et de la pile de langues, de sorte qu'un même fichier de profil s'exécute sur des hôtes Windows, macOS et Linux pris en charge et que votre équipe puisse comparer les résultats entre ces hôtes avec la même version et les mêmes paramètres de lancement. La personne qui approuve une version dispose ainsi d'une base commune à examiner plutôt que d'un résultat par machine. BotBrowser ne peut pas garantir des résultats identiques sur tous les hôtes ni sur tous les sites, ne remplace pas la validation sur des hôtes représentatifs et ne contrôle pas la manière dont un site web interprète les signaux du navigateur. Les hôtes Linux exigent en outre ENT Tier1.

Appuyez-vous sur cette limite pour rédiger le plan de déploiement. Indiquez quels hôtes et quelles cibles vous avez validés, quelles version, quel profil et quels paramètres vous avez utilisés, et quels résultats vous avez examinés. Décrivez comme non testé tout ce qui sort de cet ensemble. Un dossier d'acceptation court et exact est plus utile à la personne suivante qu'une promesse générale.

Revoyez le plan lorsque les sources évoluent. La matrice de prise en charge, les exigences de Per-Context et les recommandations sur les Client Hints sont maintenues par leurs responsables : revérifiez les sources listées ci-dessous avant de modifier des affirmations sur les hôtes pris en charge ou sur l'identité dans un document de déploiement.

Conclusion

Conservez une révision de profil et un relevé de lancement pour chaque hôte comparé. Une version, un jeu de paramètres, une route, une locale ou un mode d'affichage différent modifie l'entrée de comparaison ; notez-le avant toute décision de version.

Sources publiques

• Documentation des profils multi-plateforme de BotBrowser
• MDN : User-Agent Client Hints API
• Documentation de Per-Context Fingerprint de BotBrowser