Retour au Blog
Plateforme

Émulation d'appareil : événements tactiles, métriques d'écran et identité mobile

Comment BotBrowser fournit des signaux d'appareil cohérents pour les identités mobiles, tablettes et bureau à partir de profils capturés sur des appareils réels.

Introduction

Le navigateur expose des dizaines de signaux sur l'appareil sur lequel il s'exécute : dimensions d'écran, ratio device pixel, prise en charge tactile, mémoire appareil, caractéristiques GPU, modes d'entrée, etc. Ces signaux forment ensemble une description complète du matériel sous-jacent. Un Pixel 7 a des dimensions d'écran spécifiques, un DPR spécifique, un nombre de points tactiles, un GPU et une mémoire donnés. Lorsque ces signaux sont cohérents, le navigateur ressemble à un appareil réel ; lorsqu'ils sont incohérents, les écarts sont évidents.

BotBrowser charge des profils d'appareil capturés depuis du matériel réel. Lorsqu'un profil mobile est chargé sur une machine de bureau, tous les signaux de l'appareil sont mis à jour de manière cohérente car ils proviennent de la même source. Pas de mélange, pas de configuration manuelle par propriété, pas de risque de signaux contradictoires.

Impact sur la vie privée : pourquoi les signaux d'appareil importent

L'émulation d'appareil dépasse la simple représentation d'un navigateur mobile ou de bureau.

Les systèmes de suivi utilisent les signaux d'appareil comme partie de l'empreinte. La combinaison de la résolution d'écran, du DPR, de la prise en charge tactile, de navigator.deviceMemory, du renderer WebGL et du nombre de cœurs CPU forme une empreinte au niveau de l'appareil qui peut persister entre les sessions. Contrôler ces signaux est crucial pour maintenir une identité de navigateur cohérente et pour étudier comment les systèmes de suivi exploitent les caractéristiques de l'appareil.

Les commerces et plateformes de contenu adaptent l'expérience en fonction de l'appareil détecté. Les utilisateurs mobiles peuvent voir des prix, des mises en page et du contenu différents. Les chercheurs en vie privée ont besoin d'une émulation d'appareil précise pour étudier ces pratiques de manière fiable.

Pour la gestion multi-comptes, la diversité des appareils est également importante. Présenter des identités partageant exactement le même modèle d'appareil et les mêmes dimensions d'écran peut paraître suspect. Utiliser plusieurs profils d'appareil et varier entre mobile et bureau, différentes tailles d'écran et DPR, génère une variation naturelle.

Contexte technique

Signaux d'appareil dans le navigateur

Le navigateur expose des caractéristiques d'appareil via plusieurs APIs :

Dimensions d'écran : screen.width, screen.height, screen.availWidth, screen.availHeight rapportent les dimensions physiques. window.innerWidth et window.innerHeight rapportent la fenêtre d'affichage. window.outerWidth et window.outerHeight incluent le chrome du navigateur.

Device Pixel Ratio : window.devicePixelRatio rapporte le ratio entre pixels CSS et pixels physiques. Les écrans de bureau sont généralement 1.0 ou 1.25 ; les mobiles sont souvent entre 2.0 et 3.5 ou plus ; les MacBook Retina sont 2.0.

Prise en charge tactile : navigator.maxTouchPoints rapporte le nombre maximal de points tactiles simultanés (0 sur bureau, 5–10 sur mobile). La présence de ontouchstart sur l'objet window indique la prise en charge tactile. Les media queries CSS (pointer: coarse) et (hover: none) distinguent l'entrée tactile de l'entrée au pointeur.

Mémoire appareil : navigator.deviceMemory rapporte des gigaoctets approximatifs. Les mobiles ont généralement 4–8 GB, les bureaux 8–16 GB.

Concurrence matérielle : navigator.hardwareConcurrency rapporte le nombre de cœurs CPU disponibles. Mobiles typiques : 4–8 ; bureaux : 4–16 ou plus.

Informations de connexion : navigator.connection fournit le type de réseau, effectiveType, le débit descendant et le RTT. Les mobiles rapportent souvent des caractéristiques de réseau différentes.

GPU : la chaîne renderer WebGL identifie le GPU. Les GPU mobiles (Adreno, Mali, PowerVR, Apple GPU) diffèrent complètement des GPU de bureau (NVIDIA, AMD, Intel).

Exigences de cohérence des signaux

Ces signaux doivent être cohérents en interne. Si un navigateur rapporte maxTouchPoints: 10 mais aussi (pointer: fine) et (hover: hover), il y a une contradiction ; déclarer une largeur d'écran de 412px tout en ayant 16 GB de mémoire et un GPU NVIDIA mélange des caractéristiques mobiles et desktop, ce qui suggère une falsification plutôt que du matériel réel.

Méthodes courantes et leurs limites

Émulation d'appareil dans Chrome DevTools

Le Chrome DevTools Protocol fournit Emulation.setDeviceMetricsOverride pour définir les dimensions du viewport, le DPR et le support tactile. Playwright et Puppeteer encapsulent cette capacité dans leurs APIs d'émulation d'appareil.

Limites :

  • Ne modifie pas navigator.platform ni d'autres données User-Agent sauf si défini explicitement
  • La chaîne renderer WebGL continuera à indiquer le GPU du bureau
  • navigator.deviceMemory et navigator.hardwareConcurrency conservent les valeurs de bureau
  • L'émulation tactile est superficielle, pas au niveau du moteur
  • La disponibilité des polices reste celle du bureau
  • Les media queries peuvent ne pas correspondre complètement à l'appareil émulé

Surcharge manuelle de propriétés

Il est possible de surcharger des propriétés individuelles via l'injection JavaScript :

Object.defineProperty(navigator, 'maxTouchPoints', { get: () => 10 });
Object.defineProperty(navigator, 'deviceMemory', { get: () => 4 });

Cela change les valeurs visibles en JavaScript, mais n'altère pas le comportement réel du navigateur. Les media queries CSS, le pipeline de rendu et les en-têtes HTTP ne sont pas affectés par ces surcharges.

Méthode de viewport seule

Définir une taille de viewport mobile (par ex. 412x915) via un framework d'automatisation change la mise en page, mais pas les autres signaux d'appareil. Le navigateur continuera à rapporter des dimensions d'écran de bureau, un DPR de bureau, 0 points tactiles et des chaînes GPU de bureau.

Approche BotBrowser

Les profils de BotBrowser proviennent d'appareils réels, donc tous les signaux d'appareil proviennent de la même source. Quelle que soit la machine sur laquelle ils sont chargés, ces signaux sont appliqués au niveau du moteur garantissant une cohérence interne.

Identité d'appareil basée sur un profil

Chaque profil contient un instantané des caractéristiques de l'appareil :

  • Dimensions d'écran (width, height, availWidth, availHeight)
  • Device pixel ratio
  • Prise en charge tactile (maxTouchPoints, support des événements tactiles)
  • Mémoire appareil
  • Concurrence matérielle
  • Chaînes vendor et renderer du GPU
  • Propriétés navigator spécifiques à la plateforme
  • Dimensions du chrome de la fenêtre (pour calculer outer)

Ces signaux sont appliqués comme un ensemble, pas comme des réglages isolés, éliminant le risque de conflits.

Support tactile au niveau du moteur

Lors du chargement d'un profil mobile, le support tactile est activé au niveau du moteur Chromium plutôt que par injection JavaScript :

  • navigator.maxTouchPoints renverra la valeur réelle de l'appareil
  • ontouchstart sera disponible nativement sur l'objet window
  • Les media queries CSS (pointer: coarse) et (hover: none) seront correctement évaluées dans le moteur de styles
  • La construction des événements tactiles et leurs propriétés se comporteront comme sur un appareil réel
  • L'API InputDeviceCapabilities rapportera correctement les capacités tactiles

Profils desktop, mobile et tablette

BotBrowser prend en charge des profils pour toutes les catégories d'appareils :

Profils desktop : grands écrans (1920x1080, 2560x1440), DPR 1.0–2.0, 0 points tactiles, pointeur fin, GPU desktop, 8–16 GB de mémoire.

Profils mobile : petits écrans (412x915, 390x844), DPR 2.0–3.5, support tactile 5–10 points, pointeur grossier, GPU mobiles, 4–8 GB de mémoire.

Profils tablette : écrans moyens (1024x1366, 820x1180), DPR 2.0, support tactile et parfois pointeur fin, GPU mobile ou intégré.

Configuration de la fenêtre et de l'écran

BotBrowser offre un contrôle fin des propriétés de fenêtre et d'écran via des flags CLI :

# Utiliser les dimensions du profil (par défaut en headless)
--bot-config-window=profile
--bot-config-screen=profile

# Spécifier des dimensions
--bot-config-window=1920x1080
--bot-config-screen=2560x1440

# JSON complet personnalisé
--bot-config-window='{"innerWidth":1920,"innerHeight":1080,"devicePixelRatio":2}'

Configuration et utilisation

Profil d'appareil mobile

chrome --bot-profile="/profiles/pixel7-chrome-130.enc" \
       --user-data-dir="$(mktemp -d)"

Intégration Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/profiles/pixel7-chrome-130.enc',
    ],
    headless: true,
  });

  // Important : ne pas définir le viewport — laisser le profil le contrôler
  const context = await browser.newContext();
  const page = await context.newPage();

  const metrics = await page.evaluate(() => ({
    screenWidth: screen.width,
    screenHeight: screen.height,
    innerWidth: window.innerWidth,
    innerHeight: window.innerHeight,
    dpr: devicePixelRatio,
    touchPoints: navigator.maxTouchPoints,
    touchStart: 'ontouchstart' in window,
    pointer: matchMedia('(pointer: coarse)').matches ? 'coarse' : 'fine',
    hover: matchMedia('(hover: none)').matches ? 'none' : 'hover',
    memory: navigator.deviceMemory,
    cores: navigator.hardwareConcurrency,
  }));

  console.log('Device metrics:', metrics);
  await browser.close();
})();

Utilisation de Puppeteer avec un profil desktop

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/profiles/win11-desktop-1080p.enc',
    ],
    headless: true,
    defaultViewport: null, // Laisser le profil contrôler le viewport
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Personnaliser uniquement la taille de la fenêtre

# Remplacer uniquement la taille de la fenêtre, en conservant les autres signaux du profil
chrome --bot-profile="/profiles/win11-chrome-130.enc" \
       --bot-config-window=1440x900 \
       --bot-config-screen=1920x1080

Vérification

Vérifiez l'émulation en contrôlant l'ensemble des signaux d'appareil :

const page = await context.newPage();
await page.goto('https://example.com');

const deviceCheck = await page.evaluate(() => ({
  // Écran
  screen: {
    width: screen.width,
    height: screen.height,
    availWidth: screen.availWidth,
    availHeight: screen.availHeight,
  },
  // Fenêtre
  window: {
    innerWidth: window.innerWidth,
    innerHeight: window.innerHeight,
    outerWidth: window.outerWidth,
    outerHeight: window.outerHeight,
    dpr: window.devicePixelRatio,
  },
  // Tactile
  touch: {
    maxTouchPoints: navigator.maxTouchPoints,
    ontouchstart: 'ontouchstart' in window,
    pointerCoarse: matchMedia('(pointer: coarse)').matches,
    hoverNone: matchMedia('(hover: none)').matches,
  },
  // Matériel
  hardware: {
    deviceMemory: navigator.deviceMemory,
    hardwareConcurrency: navigator.hardwareConcurrency,
  },
}));

console.log('Device verification:', JSON.stringify(deviceCheck, null, 2));

Bonnes pratiques

  • Dans Playwright et Puppeteer, utilisez toujours defaultViewport: null. Laissez le profil contrôler les dimensions du viewport. Les paramètres du framework écraseront les valeurs du profil et casseront la cohérence.
  • Choisissez le profil adapté à votre cas d'usage. Utilisez des modèles d'appareils courants pour l'automatisation générale ; des profils mobiles populaires pour les tests mobiles.
  • Ne mélangez pas les surcharges manuelles avec les profils. Laissez le profil contrôler l'identité complète. Les surcharges manuelles (par ex. définir un viewport personnalisé sur un profil mobile) peuvent créer des incohérences.
  • Vérifiez toutes les catégories de signaux. Contrôlez écran, tactile, matériel et signaux GPU ensemble, pas une seule catégorie isolée.
  • Utilisez --bot-config-window et --bot-config-screen pour des overwrites contrôlés. Lorsque vous avez besoin de dimensions spécifiques, ajustez ces flags et conservez la cohérence des autres signaux.
  • Adaptez le profil au cas d'usage. Pour les tests e‑commerce utilisez des profils de téléphones de consommation ; pour les tests d'entreprise utilisez des profils desktop avec des écrans typiques.

FAQ

BotBrowser génère‑t‑il de vrais événements tactiles ?

Oui. BotBrowser active la prise en charge tactile au niveau du moteur, donc maxTouchPoints, ontouchstart et les media queries renvoient des valeurs correctes. Pour générer des séquences tactiles (tap, swipe, pinch), utilisez les APIs d'entrée tactile du framework (par ex. page.touchscreen.tap() dans Playwright).

Que se passe‑t‑il si je configure le viewport dans Playwright en utilisant un profil mobile ?

Définir le viewport via Playwright ou Puppeteer écrasera les dimensions de fenêtre du profil, ce qui peut produire des incohérences entre innerWidth/innerHeight (définis par le framework) et screen.width/screen.height (définis par le profil). Utilisez defaultViewport: null pour l'éviter.

Puis‑je personnaliser la taille d'écran en laissant le reste des signaux inchangés ?

Oui. Utilisez --bot-config-window et --bot-config-screen pour remplacer les dimensions d'affichage tout en conservant les autres signaux du profil.

Comment devicePixelRatio affecte‑t‑il les captures d'écran ?

La taille en pixels réels d'une capture est width * devicePixelRatio × height * devicePixelRatio. Par exemple, un viewport mobile de 412px de large avec un DPR de 2.625 produira une capture d'environ 1081 pixels de large.

Les profils tablette supportent‑ils le tactile ?

Oui. Les profils tablette incluent normalement la prise en charge tactile (maxTouchPoints: 10) et des valeurs DPR/dimensions appropriées.

Puis‑je utiliser différents profils d'appareil dans le même navigateur ?

Les caractéristiques d'appareil sont définies au niveau de l'instance du navigateur via le profil. Les contextes au sein du même navigateur partagent les signaux d'appareil. Pour des identités différentes, lancez des instances de navigateur séparées avec des profils distincts.

Quelles chaînes GPU rapportent les profils mobiles ?

Les profils mobiles rapportent le GPU de l'appareil source, par exemple "Adreno (TM) 730", "Mali-G710" ou "Apple GPU".

Résumé

L'émulation d'appareil de BotBrowser applique des profils capturés sur du matériel réel pour fournir une identité d'appareil complète et cohérente : écran, prise en charge tactile, GPU et mémoire proviennent de la même source, éliminant la nécessité de configurations manuelles fragmentées.

Lectures connexes : Android Emulation, Screen and Window Fingerprinting, Cross-Platform Profiles.

title: "Emulation d'appareil : evenements tactiles, metriques d'ecran et identite mobile" description: "Comment BotBrowser fournit une emulation d'appareil complete a travers une configuration basee sur les profils pour les identites mobiles, tablettes et bureau." date: "2026-01-28" locale: fr category: platform tags: ["device", "emulation", "touch", "mobile", "platform"] published: true

Presentation

BotBrowser charge des profils d'appareil complets captures depuis du materiel reel. Lorsqu'un profil mobile est charge, tous les signaux de l'appareil se mettent a jour de maniere coherente : APIs tactiles, dimensions d'ecran, ratio de pixels, memoire et type de connexion.

Ce que BotBrowser controle

Capacites tactiles. Les profils mobiles activent navigator.maxTouchPoints, ontouchstart et les media queries CSS (pointer: coarse) et (hover: none) au niveau du moteur.

Ecran et viewport. Les profils incluent des valeurs precises de screen.width, screen.height et devicePixelRatio provenant de vrais appareils.

Memoire et connexion. Les valeurs de navigator.deviceMemory et navigator.connection correspondent a la classe de l'appareil source.

Profils bureau, mobile et tablette

Les profils bureau signalent zero points tactiles, pointeur fin et grands ecrans. Les profils mobiles presentent le support tactile, pointeur grossier et ecrans de taille mobile. Les profils tablette se situent entre les deux.

Integration Playwright

const { chromium } = require('playwright-core');

const browser = await chromium.launch({
  executablePath: '/path/to/botbrowser/chrome',
  args: [
    '--bot-profile=/profiles/pixel7-chrome-122.enc',
  ],
  headless: true,
  defaultViewport: null,
});

const page = await (await browser.newContext()).newPage();
const metrics = await page.evaluate(() => ({
  screenWidth: window.screen.width,
  screenHeight: window.screen.height,
  dpr: window.devicePixelRatio,
  touchPoints: navigator.maxTouchPoints,
}));
console.log('Device metrics:', metrics);

Points cles

  • Les profils d'appareil sont captures depuis du materiel reel pour une coherence complete
  • Le support tactile est controle au niveau du moteur, pas via des polyfills JavaScript
  • Utilisez defaultViewport: null dans Playwright/Puppeteer pour laisser le profil controler les proprietes d'affichage
  • Tous les signaux restent internement coherents car ils proviennent du meme appareil source

Pour commencer

  1. Telechargez BotBrowser depuis GitHub
  2. Choisissez un profil d'appareil depuis le depot de profils
  3. Lancez avec --bot-profile et verifiez les metriques de l'appareil
#device#emulation#touch#mobile#platform