Les coulisses de CommunityGlows : d’une extension de navigateur à une application desktop

Read this article in English

La plupart de ce que j’écris sur ce blog parle de votre travail : garder vos clients séparés, organiser une journée sur plusieurs réseaux, publier depuis le bon compte. Cet article est différent. C’est le seul endroit où je raconte comment CommunityGlows est construit, et pourquoi.

Vous n’en avez pas besoin pour utiliser l’application. Mais si vous vous êtes déjà demandé pourquoi c’est une application desktop et pas seulement une extension, comment vos profils restent séparés, ou pourquoi le Gestionnaire des tâches affiche plusieurs processus dès que quelques réseaux sont ouverts, les réponses sont ici, avec des mots simples.

Je suis Diane. Je construis CommunityGlows seule, en artisane indépendante. Cela oriente chacun des choix qui suivent : je préfère une fondation que je peux entretenir avec soin pendant des années à une fondation impressionnante qui finirait par avaler tout mon temps.

Au début, une extension de navigateur

CommunityGlows a commencé comme une extension pour Chrome et Firefox, construite avec Vue, un outil courant pour les interfaces web. L’idée était simple : réunir au même endroit les réseaux sociaux que vous utilisez pour travailler, avec vos liens utiles et vos tâches à côté.

Une extension est légère et familière. Elle vit dans le navigateur que vous utilisez déjà et ouvre chaque réseau dans un onglet ordinaire.

Ce dernier point est aussi sa limite. Une extension fonctionne à l’intérieur de votre profil de navigateur : elle partage ses cookies et ses connexions. Si vous êtes connecté à LinkedIn avec votre compte dans Chrome, chaque onglet LinkedIn ouvert par l’extension, c’est aussi vous. Elle ne peut pas séparer « mon compte » et « le compte de mon client » sur un même réseau. Ce n’est pas un bug que je pourrais corriger : c’est la façon dont les navigateurs protègent leurs propres sessions.

L’extension fait toujours partie du projet, et elle est en préparation. Elle ne peut simplement pas tout faire.

Ce dont j’avais besoin ensuite

Deux besoins m’ont poussée au-delà de l’extension.

Le premier, c’était le grand écran. Travailler sur plusieurs réseaux est plus serein quand ils sont côte à côte, chacun dans son panneau, plutôt que cachés dans une rangée d’onglets. C’est devenu le cockpit Bento de l’application Windows, où vous organisez les réseaux en Scènes selon la tâche, comme « Réponses » ou « Publication ».

Le second, c’était la séparation. Les community managers et les solopreneurs gèrent souvent un compte personnel, une marque et plusieurs clients, parfois sur le même réseau. Je voulais que chacun de ces contextes garde sa propre connexion, pour que changer de profil change vraiment de compte. Et je voulais que la même idée fonctionne plus tard sur Android.

La question est donc devenue : quelle fondation me permet de garder l’interface que j’avais déjà, d’ouvrir de vrais sites côte à côte, de séparer leurs sessions, et d’aller à la fois sur Windows et sur Android ?

Choisir la fondation

Il y avait trois options réalistes, plus une quatrième que l’on me suggère souvent.

Electron emballe une interface web avec sa propre copie de Chromium, le moteur de Chrome. Beaucoup d’applications desktop connues l’utilisent. Il aurait donné au cockpit desktop le même moteur sur chaque ordinateur. Mais Electron vise uniquement le desktop : Android aurait demandé une autre approche.

Flutter est une boîte à outils pour construire une seule interface sur mobile et desktop. Il est excellent quand on part de zéro. Pour moi, cela voulait dire réécrire toute l’interface Vue dans un autre langage, Dart, tout en intégrant quand même les vues web des systèmes pour afficher les réseaux, car Flutter n’affiche pas de sites web par lui-même. Deux interfaces à entretenir, pour un seul produit.

Forker Chromium, c’est-à-dire construire ma propre version du navigateur, donnerait le contrôle le plus profond. Cela me rendrait aussi responsable d’un navigateur entier : suivre chaque évolution du projet d’origine, livrer vite les correctifs de sécurité, tester chaque version. Les principes de Chromium placent les mises à jour rapides et la défense en profondeur au cœur de la sécurité d’un navigateur. C’est un travail à plein temps pour une équipe. Pour une artisane seule, CommunityGlows serait devenu un projet de maintenance de navigateur.

Tauri est mon choix. Il garde une interface web, donc le code Vue a survécu, et il ajoute du code natif là où une plateforme l’exige : Rust côté desktop, Kotlin pour Android. Surtout, il n’embarque pas son propre moteur de navigateur. Il utilise celui que le système fournit déjà : WebView2 sous Windows, Android System WebView sur Android. Tauri documente cette répartition des moteurs.

Voici le compromis honnête, côte à côte :

Ce dont j’avais besoin	Tauri avec les moteurs système	Chromium embarqué ou forké
Garder l’interface Vue existante	Oui	Oui
Une seule approche pour Windows et Android	Oui, avec des adaptations natives	Pas directement
Un moteur identique sur chaque ordinateur	Non, il suit chaque plateforme	Oui, sur desktop
Garder le moteur à jour et sûr	Assuré par Microsoft et Google	Ma responsabilité
Profils, sessions et cockpit	Toujours mon travail	Toujours mon travail

La dernière ligne est la plus importante. Aucun moteur ne conçoit le produit à votre place. Quel que soit mon choix, il me faudrait toujours définir ce qu’est un profil CommunityGlows, comment une Scène se restaure, et quelles données restent sur votre appareil.

Ce qu’est une WebView, et ce qu’elle n’est pas

Chaque réseau ouvert dans l’application tourne dans une WebView : un vrai moteur web intégré à une application. Elle exécute le code du site, conserve ses cookies et ses données, et l’affiche. Ce n’est pas un navigateur complet pour autant : pas de barre d’adresse, pas de catalogue d’extensions, pas de gestionnaire de profils de navigateur.

Sous Windows, CommunityGlows utilise WebView2, basé sur le moteur de Microsoft Edge. Dans son mode habituel, Microsoft le met à jour à peu près au rythme d’Edge stable : l’application profite d’un moteur entretenu sans que j’aie à intégrer une copie de Chromium dans chaque installateur. Microsoft décrit les modes de distribution de WebView2.

Sur Android, le moteur est Android System WebView, et sa version exacte dépend du téléphone. Cela garde l’application légère, mais impose de tester sur différents appareils.

Tauri m’a donc évité d’entretenir un moteur. Il ne m’a pas évité de construire tout ce qui l’entoure : les profils, l’ouverture et la restauration des panneaux, la conservation des sessions, le partage de liens vers l’application sur Android. Cette couche native occupe une grande partie de mon temps, et je pense que c’est le bon endroit où le mettre.

Comment les sessions restent séparées

C’est la partie qui me tient le plus à cœur, parce que c’est elle qui protège vos clients.

Dans les applications, la frontière est toujours un couple : un profil plus un réseau. LinkedIn dans votre profil « Personnel » et LinkedIn dans votre profil « Client A » forment deux couples différents, donc deux sessions séparées.

Sous Windows

Dans l’application Windows, chaque couple profil/réseau a son propre dossier de données WebView2. Ses cookies, son stockage local, IndexedDB et son cache y vivent, sans jamais se mélanger à ceux d’un autre couple. Quand vous vous connectez à un réseau dans un profil, cette connexion n’apparaît pas dans un autre.

Sur Android

Dans l’application Android, chaque couple a son propre profil WebView Android natif quand la WebView du téléphone le permet. C’est le mode privilégié.

Certains appareils ne le permettent pas. L’application utilise alors un mode de secours : une seule WebView qui enregistre et restaure, pour chaque couple, ses cookies et son stockage local, rangés par adresse exacte de site. Cela fonctionne, mais couvre moins. Ce mode ne sépare pas tout ce qu’un site peut stocker, comme IndexedDB, les fichiers en cache ou les service workers, et le changement est plus lent. Quand l’application fonctionne dans ce mode dégradé, elle le signale au lieu de prétendre que la séparation est complète.

Les limites, clairement

• Même réseau, même profil : deux copies d’un réseau dans un même profil partagent la session de ce profil. C’est voulu.
• Pas un bac à sable de sécurité : il s’agit d’une séparation des sessions et du stockage. Toute personne qui peut utiliser votre compte Windows ou Android est en dehors de cette frontière.
• Les gestionnaires de mots de passe restent en dehors de la frontière des sessions.
• L’extension n’isole pas les réseaux, comme expliqué plus haut.

Une vérification simple, à faire vous-même

Je teste cette frontière avec ce que j’appelle la vérification A/B/A, et vous pouvez la faire en deux minutes :

1. ouvrez un réseau dans le profil A et connectez-vous au compte A ;
2. passez au profil B et ouvrez le même réseau : le compte A ne doit pas y être ;
3. connectez-vous au compte B ;
4. revenez au profil A : le compte A doit réapparaître, sans aucune trace du compte B.

Si cela échoue un jour pour un réseau, je veux le savoir. Pour le côté quotidien, voyez comment séparer plusieurs comptes sociaux sur un même appareil. Les connexions restent aussi sur l’appareil où vous les avez faites ; ce qui reste local et ce qui est synchronisé explique le reste.

Pourquoi plusieurs réseaux ouverts consomment de la mémoire

Si vous ouvrez le Gestionnaire des tâches de Windows avec quelques réseaux ouverts, vous verrez peut-être plusieurs processus WebView2 et plus de mémoire utilisée que pour une petite application. Ce n’est généralement pas une fuite, et l’article consacré à la mémoire détaille le sujet.

Chaque panneau contient un vrai site, pas une image de site. LinkedIn, Instagram ou Gmail sont des applications complètes : leur code, leurs images, leurs polices, leurs connexions et parfois leurs vidéos doivent rester en mémoire. La règle est simple : plus vous gardez de réseaux réellement ouverts, plus votre ordinateur a de pages à faire vivre. C’est pareil avec les onglets d’un navigateur.

Pourquoi il y a plusieurs processus

WebView2 suit la même architecture multi-processus que Microsoft Edge. Le travail est réparti entre un processus principal, des processus qui dessinent les pages, et des processus d’aide pour le graphisme, le réseau ou l’audio. Microsoft explique que leur nombre exact dépend des sites et des fonctions utilisés. Plusieurs lignes dans le Gestionnaire des tâches ne veulent pas dire que plusieurs copies de CommunityGlows tournent.

Cette séparation a aussi un avantage : un problème dans un site reste mieux contenu. Et les dossiers de session par couple décrits plus haut expliquent en partie pourquoi je ne partage pas simplement un seul moteur pour tout, juste pour économiser de la mémoire. Partager davantage coûterait peut-être moins, mais toucherait la frontière qui garde vos clients séparés. Je ne changerai cela qu’après avoir mesuré le comportement réel, pas sur une économie théorique.

Pages au chaud, pages masquées, pages fermées

Quand vous quittez un réseau et que vous y revenez, le retour semble instantané parce que la page a été gardée « au chaud ». Ce confort consomme de la mémoire. L’application Windows garde un nombre limité de pages au chaud : quand la réserve est pleine, les plus anciennes pages masquées sont fermées.

Trois actions se confondent facilement :

• Masquer un panneau le retire de l’écran, mais sa page peut rester en mémoire pour un retour rapide.
• Fermer une page la libère ; la prochaine ouverture la recharge.
• Effacer une session supprime les données de connexion, et il faudra vous reconnecter.

Fermer une page ne vous déconnecte jamais. Votre session reste sur le disque.

Ce que vous pouvez faire dès aujourd’hui

• Ne gardez visibles que les réseaux utiles à la tâche du moment. Une Scène ciblée, comme « Réponses », est plus légère que tout ouvert toute la journée.
• Mettez en pause les vidéos ou l’audio que vous ne suivez pas : cela réduit le travail du processeur.
• Redémarrez l’application quand vous voulez repartir de zéro. Fermer un panneau ne fait pas toujours baisser tout de suite le Gestionnaire des tâches, car sa page peut rester un moment au chaud dans la réserve.

Ouvrir moins de réseaux à la fois est aussi une habitude de concentration ; gérer plusieurs réseaux sociaux au quotidien en parle.

Ce sur quoi je travaille

Je travaille sur la mise en veille des pages inactives : utiliser moins de ressources quand vous ne les regardez pas, tout en gardant la session. C’est en développement, pas une fonction disponible, et je n’ai pas fixé de date. Cela demande du soin : une page en veille ne doit pas vous faire manquer ce qui compte, et elle doit se réveiller dans le bon profil, jamais dans un autre.

Referais-je le même choix aujourd’hui ?

Pour un produit uniquement desktop dont tout l’intérêt serait la navigation, j’étudierais plus sérieusement l’option d’embarquer Chromium. Un moteur uniforme et les extensions de navigateur pourraient alors justifier le coût.

Pour CommunityGlows tel qu’il est (une extension, une application Windows, une application Android et une seule interface partagée, construits par une seule personne), je garderais cette direction. Repartir sur un fork de Chromium déplacerait mon énergie vers la maintenance d’un navigateur, sans résoudre Android.

Ce choix n’est pas gravé pour autant. Je continue de mesurer la mémoire, la stabilité des sessions, le comportement de chaque réseau et le coût de la couche native. Un choix technique est bon tant qu’il sert les personnes qui utilisent le produit.

Ce que cela change pour vous

• Vos connexions aux réseaux sociaux restent sur votre appareil.
• Dans les applications Windows et Android, chaque profil et chaque réseau gardent leur propre session. L’extension de navigateur partage plutôt les sessions de votre navigateur.
• Certains comportements diffèrent un peu entre Windows et Android, car chacun utilise son propre moteur système.
• Les mises à jour du moteur web par Microsoft ou Google peuvent changer le comportement d’un site, indépendamment d’une mise à jour de CommunityGlows.
• Plus de réseaux ouverts, c’est plus de mémoire. Vous gardez la main sur le nombre de réseaux ouverts.

Je préfère vous dire où s’arrêtent mes garanties plutôt que de les cacher derrière le mot « multiplateforme ». Pour voir l’espace de travail que tout cela sert, commencez par transformer un grand écran en cockpit multi-réseaux avec Bento.