Un Chrome par compte Google sur macOS

Toute la journée, j’ai deux Chrome ouverts : mon profil perso (Gmail, mes comptes) et mon profil pro (un compte Google Workspace pour l’entreprise). Et sur macOS, c’est pénible.

Le problème

Sur macOS, tous les profils Chrome sont dans une seule application. Le Dock et Cmd+Tab regroupent les fenêtres par application. Résultat :

• le Dock affiche une seule icône Chrome pour tous les profils ;
• Cmd+Tab affiche un seul Chrome. Pour passer de la fenêtre perso à la fenêtre pro, il faut Cmd+`, le menu Fenêtre ou Mission Control ;
• dans Mission Control, les fenêtres perso et pro sont mélangées.

Je voulais quelque chose de simple : une icône par compte dans le Dock, et une entrée par compte dans Cmd+Tab.

Ce que j’ai essayé

Les profils Chrome. C’est la solution normale, mais c’est justement la source du problème : tous les profils restent dans la même app.

Un lanceur Automator. Beaucoup de guides conseillent une petite app qui lance Chrome avec le bon profil. Ça ouvre le bon profil, mais la fenêtre arrive dans la même app Chrome. Le Dock et Cmd+Tab ne changent pas.

Les web apps de Chrome. « Installer la page en tant qu’application » donne une vraie icône dans le Dock et dans Cmd+Tab. Mais c’est une app par site : Gmail, Agenda, Drive… On ne navigue pas librement.

Les outils existants. Epichrome créait des apps basées sur Chromium. Son auteur a arrêté le projet : la dernière version, la 2.4.27, date de janvier 2022. chrome-schismator, un script sur GitHub, lance plusieurs instances de Chrome avec leur propre icône. Et je ne suis pas le seul à vouloir ça : sur Mozilla Connect, une idée demande la même chose pour Firefox. L’auteur écrit qu’aujourd’hui, on ne l’obtient qu’avec des « fragile third-party scripts ».

L’idée : une app, un identifiant

macOS reconnaît une application par son identifiant, le CFBundleIdentifier du fichier Info.plist. Pour Chrome, c’est com.google.Chrome. Tous les profils ont le même, donc macOS les met ensemble.

Alors, il suffit de copier Google Chrome.app et de changer cet identifiant dans la copie. Pour macOS, com.google.Chrome.Pro est une autre application : elle a sa propre icône dans le Dock et sa propre entrée dans Cmd+Tab.

Il reste un problème : la copie et le Chrome d’origine ne doivent pas partager le même dossier de données (profils, cookies, historique). Là, Chromium a déjà la réponse. Dans son code source (chrome/common/chrome_paths_mac.mm), une clé du Info.plist, CrProductDirName, choisit le dossier de données dans ~/Library/Application Support. Google s’en sert pour Chrome Canary, qui utilise Google/Chrome Canary. Ce n’est donc pas une astuce : c’est un mécanisme prévu par Chromium.

La copie change donc trois choses :

Un détail important : dès qu’on change le Info.plist, la signature de Google n’est plus valide. Il faut signer la copie à nouveau sur le Mac, avec une signature locale (« ad hoc »). Ce point explique presque toutes les limites, j’y reviens plus bas.

Le script

J’ai mis tout ça dans un script, copy-chrome.sh. Il copie Chrome, change le Info.plist, pose un badge sur l’icône si on veut, et signe la copie.

# Créer une copie, avec le logo de l'entreprise en badge
./copy-chrome.sh Pro --badge ~/Pictures/logo-entreprise.png

# Après une mise à jour de Chrome : refaire la copie (le badge est gardé)
./copy-chrome.sh Pro

# Supprimer la copie et toutes ses données
./copy-chrome.sh Pro --remove

Le badge est une image ronde, posée en haut à gauche de l’icône Chrome. Il est dessiné par un petit programme Swift, à côté du script. Avec lui, on reconnaît chaque Chrome d’un coup d’œil dans le Dock.

Au premier lancement, la copie démarre vide, comme un Chrome qu’on vient d’installer. On se connecte au compte Google, on active la synchronisation, et les favoris, mots de passe et extensions reviennent. Les cookies, eux, ne reviennent pas : il faut se reconnecter aux sites. Le Chrome d’origine et ses profils ne sont pas touchés.

Ce qui casse

C’est une solution non officielle, et elle a un prix. Tout vient de la même cause : la copie n’est plus signée par Google.

Les passkeys du Mac

Dans une copie, les passkeys enregistrées sur le Mac ne sont pas proposées : ni celles des Mots de passe d’Apple, ni celles du Gestionnaire de mots de passe de Google. Les mots de passe normaux, eux, marchent.

Ce que j’ai constaté sur une page de connexion :

Pourquoi ? Le Chrome de Google a des droits spéciaux (des « entitlements ») qu’Apple ne donne qu’à une app signée par son éditeur : l’accès aux passkeys et à certains groupes du trousseau. Une signature locale ne peut pas les avoir. TeamDev, qui fait un navigateur basé sur Chromium, explique par exemple que les passkeys Touch ID demandent l’entitlement keychain-access-groups et un « provisioning profile » dans l’app. Je n’ai pas encore vérifié la cause exacte dans le code de Chromium : c’est l’explication la plus probable, pas une certitude.

Le contournement qui marche : « Utiliser la clé d’accès d’un autre appareil ». Chrome affiche un QR code, je le scanne avec mon téléphone, et la passkey du téléphone valide la connexion. Il faut juste le téléphone à côté, avec le Bluetooth activé.

Le trousseau redemande l’accès

Après chaque nouvelle copie, macOS redemande l’accès à « Chrome Safe Storage », la clé qui protège les mots de passe et les cookies de Chrome. Le trousseau reconnaît une app signée en local par l’empreinte exacte de son code, et cette empreinte change à chaque signature. Il suffit de cliquer sur Toujours autoriser. Surtout pas sur Refuser : Chrome ne pourrait plus lire ses données.

Pas de mise à jour automatique

La copie ne se met pas à jour toute seule. Après chaque mise à jour du Chrome d’origine, je relance le script. Si la copie est déjà à jour, il ne fait rien.

Deux pièges pendant le développement

Pour ceux qui veulent refaire l’exercice :

• Les attributs Finder. Les fichiers de Chrome ont l’attribut com.apple.FinderInfo, et codesign refuse de signer : « resource fork, Finder information, or similar detritus not allowed ». Il faut d’abord les retirer avec xattr -cr.
• codesign --deep. Chrome garde parfois l’ancienne version de son framework à côté de la nouvelle. --deep essaie de tout signer et casse cette ancienne version. La solution : signer seulement l’app principale.

Et un mur : le dossier de données du Chrome d’origine est protégé par macOS (TCC). Sa lecture échoue avec « Operation not permitted », même avec sudo. On ne peut donc pas copier un profil existant : chaque copie part de zéro, et la synchronisation fait le reste.

Quel profil mettre où ?

À cause des passkeys, le partage est assez clair :

• Dans le Chrome d’origine : les comptes qui utilisent des passkeys ou des clés de sécurité. C’est aussi le navigateur par défaut, qui reçoit les liens ouverts depuis les autres apps.
• Dans une copie : les comptes avec mot de passe ou SSO, pour un usage bien séparé. Pour moi, c’est le compte Google Workspace pro : Gmail, Agenda, Drive et les outils de l’entreprise.

Mon profil perso utilise beaucoup de passkeys, il reste donc dans le Chrome d’origine. Une seule copie suffit, pour le pro.

En résumé

Pour moi, la copie est le bon compromis : une icône par compte, et toute la navigation de Chrome. La perte des passkeys est réelle, mais le QR code la contourne, et le profil qui en a le plus besoin reste dans le Chrome d’origine.

Je l’ai testée avec Chrome 155 sur macOS 27. Attention, c’est une solution non officielle : Google ne la supporte pas, et une future version de Chrome ou de macOS peut la casser.

Le script et les références

Le script est sur GitHub, avec son mode d’emploi : tips-and-scripts/macos/copy-chrome.

Pour aller plus loin :

• Code source de Chromium : chrome_paths_mac.mm (la clé CrProductDirName)
• TeamDev : passkeys et Touch ID dans un navigateur Chromium
• Mozilla Connect : une icône de Dock par profil
• Epichrome (projet arrêté)
• chrome-schismator