Isolation multi-comptes du navigateur : réglages indépendants

L'isolation de plusieurs comptes consiste à donner à chaque identité autorisée sa propre route, son profil, sa limite de stockage et son relevé de revue. BotBrowser peut isoler des comptes approuvés par profil et contexte ; il ne peut pas autoriser l'usage d'un compte, contourner les règles d'une plateforme ni garantir qu'une plateforme ne corrélera jamais des comptes.

Résumé

Utilisez BrowserContext pour un stockage isolé, puis les réglages d'identité par contexte ou des instances séparées pour le reste de la limite approuvée. Vérifiez exitIp, locale, les lectures de rendu et les partitions de stockage pour chaque identité après un changement de configuration ou de version du navigateur.

Sommaire

• Cinq signaux qui peuvent relier un compte à un autre
• Une instance avec plusieurs contextes, ou plusieurs instances
• Attribuer des réglages indépendants à chaque identité
• Vérifier chaque identité séparément
• Conclusion pratique

Cinq signaux qui peuvent relier un compte à un autre

Toute personne qui gère volontairement plusieurs comptes, comme une agence qui administre des pages de clients, une équipe d’assistance qui reproduit des incidents régionaux ou un chercheur qui compare des contenus localisés, rencontre le même problème : les comptes partagent plus de choses que la personne qui les utilise. Un site n’a pas besoin d’un nom pour remarquer que deux sessions ont quelque chose en commun. Quelques valeurs qui se répètent lui suffisent. Le travail d’isolation consiste donc à décider quelles valeurs doivent rester indépendantes pour chaque identité et à vous assurer que chacune est choisie volontairement, au lieu d’être héritée par hasard de la machine. Les conseils ci-dessous supposent que chaque compte est le vôtre, ou que vous l’exploitez avec l’accord de son titulaire et dans le respect des conditions de la plateforme. BotBrowser peut garder chaque compte autorisé dans son propre profil et contexte isolés ; il ne peut pas accorder l’autorisation d’exploiter un compte ni remplacer les conditions d’une plateforme.

Cinq dimensions comptent en pratique. Elles sont listées dans l’ordre où elles posent le plus souvent problème.

• Route réseau. Deux comptes qui se connectent depuis la même adresse IP se rapprochent facilement. Chaque identité a besoin de sa propre route approuvée, et son registre peut conserver l’adresse observée dans exitIp.
• Signaux d’empreinte. Le rendu de Canvas et de WebGL, les caractéristiques audio, les dimensions d’écran et les valeurs de navigator proviennent du matériel et du système d’exploitation ; ils se répètent donc pour tout ce qui s’exécute sur une même machine tant que rien ne les modifie. Relevez canvasHash et webglRenderer lorsque le profil ou la graine devrait les distinguer.
• Cookies et stockage. Les cookies, localStorage, IndexedDB, le cache et les service workers conservent un état. Tout partage à cet endroit relie directement les comptes, sans aucune déduction ; notez la frontière attendue dans storagePartition.
• Métadonnées géographiques. Le fuseau horaire, les paramètres régionaux et la langue doivent concorder entre eux et avec la route. Un compte qui semble se connecter depuis Berlin tout en indiquant un fuseau horaire de New York est incohérent avec lui-même ; le registre peut les nommer timeZone et locale.
• Horaires d’activité. Des comptes qui démarrent, s’arrêtent et agissent toujours aux mêmes moments depuis la même machine forment un schéma qu’aucun réglage du navigateur ne peut supprimer.

Les quatre premiers sont des questions de configuration, et un navigateur peut aider à les traiter. Le cinquième dépend du comportement des personnes et des calendriers ; il apparaît donc plus bas comme une habitude de travail et non comme un réglage.

Gardez une idée en tête pour la suite : l’isolation réduit le risque de liaison sur ces dimensions, sans jamais le ramener à zéro. Un ensemble d’identités bien configuré supprime les liens faciles et accidentels. Il n’empêche pas un analyste déterminé de corréler des comptes par le comportement, par des informations de paiement partagées ou par la manière d’écrire de la même personne. Planifier en tenant compte de cette limite mène à de meilleures décisions que supposer une séparation parfaite.

L’indépendance n’est que la moitié de l’objectif : chaque identité doit aussi être cohérente avec elle-même. Un profil qui décrit un ordinateur de bureau, des paramètres régionaux d’un autre pays et une route dans une troisième région rendent une identité contradictoire, ce qui constitue déjà un signal. Lorsque vous préparez une identité, posez-vous deux questions : diffère-t-elle des autres sur chaque dimension, et ses propres réglages décrivent-ils un seul appareil cohérent dans un seul lieu cohérent ? Les deux réponses doivent être positives.

Une instance avec plusieurs contextes, ou plusieurs instances

Disposition	Frontière de stockage	Frontière de configuration de l’identité	Compromis d’exploitation
une instance, plusieurs objets BrowserContext	un stockage isolé par contexte	profil, route, paramètres régionaux et graine par contexte	coût mémoire moindre ; l’empreinte par contexte exige une licence ENT Tier3
une instance par identité	un répertoire de données utilisateur par processus	un fichier de profil et une route par instance	rayon d’impact plus clair ; coût de démarrage et mémoire plus élevés

Les navigateurs basés sur Chromium séparent le stockage par contexte de navigation. Playwright décrit un contexte comme une session de navigateur isolée : chacun a ses propres cookies, son stockage local, ses données IndexedDB, son cache et ses service workers, et un test peut en ouvrir un grand nombre dans un seul navigateur à faible coût. C’est le comportement standard, et il ne dépend d’aucune version particulière. Il couvre la troisième dimension de la liste ci-dessus et explique pourquoi un contexte est l’unité naturelle pour une identité.

Ce qu’un contexte standard ne sépare pas, ce sont les signaux qui proviennent du matériel et du système d’exploitation. Le rendu, les caractéristiques audio, les dimensions d’écran et les valeurs de navigator sont identiques dans tous les contextes d’un navigateur ordinaire, car chaque contexte s’exécute sur la même machine. Une installation standard vous apporte donc l’isolation du stockage, et rien de plus. Les conteneurs de Firefox et les répertoires de données utilisateur distincts partagent la même frontière : les cookies sont séparés, tandis que les signaux issus de l’appareil restent les mêmes.

À l’autre bout de l’échelle existent des options plus lourdes. Les installations de navigateur séparées et les machines virtuelles offrent une forte séparation, puisque chacune dispose de ses propres binaires, de son système d’exploitation ou de son profil matériel, mais elles multiplient le travail de mise à jour, de supervision et de stockage de chaque environnement, et chaque machine virtuelle réserve de la mémoire pour un système d’exploitation complet. Elles conviennent lorsque des règles de conformité exigent que les identités ne partagent aucun hôte. Pour la plupart des usages multi-comptes, les contextes et les instances de navigateur séparées répondent au besoin pour un coût d’exploitation moindre.

Deux dispositions sont courantes. Dans la première, une instance du navigateur contient plusieurs contextes, chacun attribué à une identité. Elle démarre vite, mutualise le coût de l’instance et consomme moins de mémoire par identité. La fonction d’empreinte par contexte de BotBrowser a été conçue pour cette disposition : chaque contexte peut porter son propre profil, son fuseau horaire, ses paramètres régionaux, sa graine de bruit et son proxy, et la documentation indique que la plupart des options de ligne de commande de BotBrowser sont prises en charge par contexte. Cette fonction exige la licence ENT Tier3 ; vérifiez donc votre niveau de licence avant de bâtir votre conception dessus.

Dans la seconde disposition, chaque identité dispose de sa propre instance du navigateur, avec son propre fichier de profil et son propre répertoire de données utilisateur. Rien n’est partagé entre les instances, ce qui donne la séparation la plus nette et l’explication la plus simple pour un audit. Le prix est le coût : chaque instance a son propre temps de démarrage et sa propre consommation de mémoire, et le nombre d’instances qu’une machine peut contenir dépend de son matériel, non du navigateur. Un plantage ou une page bloquée n’affecte en outre qu’une seule identité, ce qui est un vrai avantage d’exploitation.

Choisissez selon le risque et le volume. Si les identités sont peu nombreuses et qu’une confusion coûte cher, des instances séparées sont faciles à raisonner. Si vous avez besoin de nombreuses identités sur un matériel limité, une instance avec plusieurs contextes est plus efficace, à condition d’accepter que les contextes partagent une instance du navigateur et de vous appuyer sur les réglages par contexte pour tout le reste. Beaucoup d’équipes combinent les deux : des contextes dans chaque instance pour des identités apparentées, et des instances séparées pour les groupes qui ne doivent jamais partager d’infrastructure. Quelle que soit la disposition retenue, donnez à chaque instance son propre répertoire de données utilisateur afin que les données de profil ne se mélangent jamais.

La capacité est une mesure, pas une promesse. Le nombre d’identités qu’une machine peut porter dépend de la mémoire disponible, des cœurs du processeur et du poids des pages de chaque contexte ; testez donc avec vos charges réelles plutôt que de recopier un chiffre issu de la configuration d’un autre. Planification de la capacité des contextes du navigateur montre comment planifier et surveiller l’utilisation des ressources à mesure que le nombre de contextes augmente. Ajoutez les identités progressivement, surveillez la mémoire et les temps de chargement, et arrêtez-vous lorsque la machine commence à ralentir.

Attribuer des réglages indépendants à chaque identité

Commencez par un registre simple des identités avant de toucher à la configuration. Pour chacune, notez le fichier de profil, la route, le fuseau horaire, les paramètres régionaux et les langues, la graine de bruit, ainsi que le répertoire de données ou le contexte qui conserve son état. Le registre est court, mais il évite l’erreur la plus courante : réutiliser une valeur parce qu’elle figurait déjà sur la ligne de commande. Traitez chaque ligne comme une unité qui ne partage aucune valeur avec une autre ligne, sauf là où vous avez décidé que le partage est acceptable.

Le profil fixe l’empreinte de base. Des fichiers de profil séparés donnent la séparation la plus forte, car chacun décrit un appareil différent, tandis qu’un même profil combiné à des graines de bruit différentes donne des résultats distincts à partir de la même base. La graine de bruit commande de petites variations du rendu et de l’audio. La même graine produit toujours le même résultat : une identité reste donc stable d’une session à l’autre, et une graine différente donne à une autre identité un résultat différent. Choisissez la graine une fois, conservez-la dans le registre de l’identité et ne la changez pas sans raison. Reproductibilité de la graine de bruit détaille ce point.

La route et les métadonnées géographiques doivent concorder. Lorsque vous attribuez le proxy à un contexte par ses réglages BotBrowser, BotBrowser déduit le fuseau horaire, les paramètres régionaux et la langue de l’adresse de sortie de cette route. La documentation permet aussi d’indiquer vous-même l’adresse de sortie, ce qui évite la recherche et accélère la création du contexte. Elle avertit qu’un proxy défini uniquement par l’option intégrée de Playwright laisse le fuseau horaire en décalage avec la route ; utilisez donc le réglage --proxy-server de BotBrowser pour les routes par contexte. Des valeurs explicites de fuseau horaire, de paramètres régionaux et de langue restent disponibles lorsque vous devez remplacer les valeurs déduites, comme l’explique Configuration du fuseau horaire, des paramètres régionaux et de la langue.

La stabilité dans le temps fait partie de la conception. Un compte qui conserve le même profil, la même graine, la même région de route et le même répertoire de données d’une session à l’autre ressemble à une personne qui revient sur un même appareil. Un compte dont les réglages changent d’une session à l’autre ressemble à plusieurs appareils et peut déclencher des vérifications supplémentaires sur les plateformes qui surveillent les nouveaux appareils. Si une identité a besoin d’une nouvelle route, par exemple après un changement de fournisseur, gardez stables la région et les métadonnées géographiques, puis mettez le registre à jour. Ne changez le profil ou la graine que lorsque vous retirez volontairement l’identité.

L’ordre compte au sein d’une instance. Les réglages par contexte doivent être appliqués après la création du contexte et avant l’ouverture de sa première page, car une page les lit au démarrage, et les réglages appliqués à un contexte qui possède déjà une page ne prennent pas effet. Les workers créés depuis des pages de ce contexte, qu’ils soient dédiés, partagés ou de type service worker, héritent de l’identité du contexte et n’exigent aucune étape supplémentaire. Créez chaque contexte, appliquez ses réglages, puis seulement ensuite ouvrez des pages.

Les détails de la route méritent leur propre soin. Donnez à chaque identité une route approuvée distincte, et vérifiez comment votre fournisseur et le navigateur gèrent le DNS et WebRTC, afin que la route choisie soit celle qui porte toutes les connexions. BotBrowser documente des contrôles pour les deux côté réseau, et Proxy par contexte explique comment attribuer et valider des routes par contexte. Conservez les identifiants de chaque route dans un gestionnaire de secrets plutôt que dans des scripts partagés entre plusieurs identités.

Vérifier chaque identité séparément

Valeur lue	Comparaison attendue	Champ du registre
adresse publique	diffère et correspond à la route approuvée	exitIp
paramètres régionaux et fuseau horaire	concordent avec la région de la route approuvée	locale et timeZone
rendu Canvas et WebGL	diffère lorsque le profil ou la graine choisis doivent différer	canvasHash et webglRenderer
cookies et stockage	absents en dehors du contexte qui les possède	storagePartition

Vérifier, c’est relire les valeurs observables de chaque identité et les comparer à votre registre. Faites-le après chaque modification de configuration et à chaque changement de version du navigateur. Utilisez une page de test que vous maîtrisez ou une page publique neutre, et gardez des contrôles courts. Le but est de confirmer que vos réglages ont atteint chaque contexte, non d’étudier le fonctionnement d’un site particulier. Exécutez les mêmes contrôles dans chaque identité afin de pouvoir comparer les résultats ligne à ligne.

1. L’adresse IP publique diffère d’une identité à l’autre et correspond à la route attribuée à chacune.
2. Le fuseau horaire, les paramètres régionaux et la langue signalés correspondent à la région de cette route.
3. Le rendu de Canvas diffère entre les identités qui utilisent des profils ou des graines de bruit différents.
4. La chaîne du moteur de rendu WebGL diffère entre les identités qui utilisent des profils différents.
5. Les cookies et le stockage écrits dans une identité sont absents de toutes les autres.

Interprétez les résultats avec les bonnes attentes. Des différences dans la chaîne du moteur de rendu sont attendues entre des profils distincts, alors que les graines de bruit modifient surtout le rendu ; deux identités sur un même profil peuvent donc légitimement signaler la même chaîne. Si une différence attendue manque, regardez d’abord le registre : une graine répétée, un fichier de profil partagé ou un contexte dont les réglages ont été appliqués après sa première page sont les causes habituelles, et un répertoire de données partagé explique un stockage partagé.

Gardez les contrôles à part des sessions normales de l’identité. Ouvrez la page de vérification dans une nouvelle page du même contexte, relevez les valeurs puis fermez-la, afin qu’un contrôle ne laisse pas d’état supplémentaire dans le stockage, l’historique ou les horaires du compte. Ne vous connectez à rien et ne chargez aucune page appartenant au compte réel pendant un contrôle. Conservez les valeurs relevées avec le registre de l’identité pour pouvoir comparer un changement ultérieur.

Planifiez les contrôles. Faites-les à la création d’une identité, après toute modification de profil, de route ou de graine, après une mise à jour du navigateur et selon un calendrier régulier pour les identités durables, par exemple une fois par mois. Une liste courte et reproductible vaut mieux qu’une longue que personne ne termine. Lorsqu’une valeur change sans entrée correspondante dans le registre, traitez-la comme un constat : cherchez qui a modifié quoi, puis corrigez la configuration ou le registre avant de réutiliser l’identité.

Gardez en tête ce que signifie un contrôle réussi. Ces relevés confirment que les réglages ont été appliqués comme prévu et que les identités sont distinctes sur les valeurs lues. Ils ne prouvent pas qu’un site donné ne peut pas relier deux identités, car un site peut utiliser des signaux que vous n’avez pas lus, et la liaison peut venir du comportement plutôt que des valeurs du navigateur. Considérez un résultat propre comme la preuve que la configuration est correcte, jamais comme une garantie sur le comportement d’une plateforme.

Conclusion pratique

Les horaires sont la première lacune. Des comptes qui agissent toujours aux mêmes minutes, se connectent l’un juste après l’autre ou suivent des routines identiques présentent un schéma qui n’a rien à voir avec le navigateur. Décalez les calendriers, variez la durée des sessions et laissez chaque compte suivre le rythme qui convient à son objectif. Ne pilotez pas plusieurs comptes depuis un seul script qui les exécute en parallèle.

La deuxième lacune est le matériel partagé. La même adresse e-mail, le même numéro de téléphone, le même moyen de paiement, le même contact de récupération ou le même fichier téléversé relient des comptes au niveau de la plateforme. Les cookies méritent une mention particulière : copier un cookie d’une identité vers une autre emporte avec lui la session et ses identifiants, et défait la séparation qu’apporte l’isolation du stockage. Ne déplacez jamais de cookies, de sessions exportées ou de mots de passe enregistrés entre des identités.

L’hygiène courante couvre les lacunes restantes. Fermez les contextes terminés pour libérer la mémoire et éviter l’accumulation d’état. N’utilisez des répertoires de données persistants que pour les identités qui doivent conserver un état entre les exécutions, avec un répertoire par identité. Conservez les identifiants des routes, les fichiers de profil et les graines dans un stockage à accès contrôlé, avec un responsable désigné. Lisez les conditions de chaque plateforme que vous utilisez : certaines limitent le nombre de comptes qu’une personne peut exploiter, et aucune configuration du navigateur ne change ces règles ni la manière dont la plateforme les applique.

Prévoyez les erreurs, car elles arriveront. Si un cookie a été copié à la main, si un fichier de profil a été réutilisé ou si deux contextes ont été ouverts avec les mêmes réglages, considérez les deux identités concernées comme mélangées. Cessez de les utiliser pour le travail touché, documentez ce qui s’est passé et reconstruisez l’identité concernée avec un nouveau répertoire de données et ses propres réglages, au lieu de la rafistoler. Reconstruire est plus lent sur le moment, mais laisse un registre auquel on peut se fier, alors qu’une identité rafistolée conserve tout l’état qui s’y est infiltré.

Avant d’ajouter une nouvelle identité, examinez-la au regard des cinq dimensions et du matériel partagé décrit plus haut. A-t-elle sa propre route, son propre profil et sa propre graine, son propre répertoire de données, ses propres horaires et ses propres données de compte ? Une nouvelle identité qui échoue à l’une de ces questions n’est pas encore isolée, même si les réglages du navigateur sont corrects.

BotBrowser permet d’attribuer un profil, un proxy, un fuseau horaire, des paramètres régionaux et une graine de bruit distincts à chaque BrowserContext au sein d’une même instance du navigateur (l’empreinte par contexte exige la licence ENT Tier3 documentée), ou d’exécuter des instances séparées avec leurs propres profils et répertoires de données utilisateur, de sorte que chaque identité présente des réglages d’empreinte et de réseau indépendants et que vous puissiez garder les comptes séparés sans entretenir un parc complet de machines. BotBrowser ne peut pas garantir que les comptes ne seront jamais reliés : il ne fournit ni proxys ni réputation d’IP, ne contrôle pas la corrélation de comportement ou d’horaires, ni la façon dont vous gérez les cookies, ni les politiques de comptes d’une plateforme, et ne remplace pas une séparation opérationnelle rigoureuse des comptes.

Sources publiques

• BotBrowser: Multi-Account Isolation
• BotBrowser: Per-Context Fingerprint
• BotBrowser: Per-Context Proxy
• Playwright: Isolation with browser contexts
• Playwright: HTTP proxy