Le moment où c'est devenu évident
C'est arrivé pendant une visioconférence. Quelqu'un dans l'appel partageait son écran, et on voyait le curseur de la souris saccader. L'appel lui-même se passait bien — le problème, c'était Slack qui tournait en arrière-plan, consommant environ 4 % du CPU et plus de 1 GB de RAM sur une machine dotée de 16 GB au total.
Ce n'est pas une machine à court de ressources. C'est un ordinateur moderne dont les performances sont mesurablement dégradées par une application de chat. Et la personne à l'autre bout de l'appel avait fini par accepter cela comme normal.
Nous n'étions pas les seuls
Cette frustration n'a rien d'anecdotique. Cherchez « Slack RAM » ou « Slack lent » et vous trouverez des années de messages sur les forums, de fils Reddit et de sections de commentaires — tous disant la même chose. La réponse de Slack a toujours été « nous travaillons sur les performances ». L'application s'est améliorée à la marge, mais l'architecture n'a pas changé : c'est toujours un navigateur web complet embarqué dans un client de chat.
Cette architecture implique une surcharge minimale de 150 à 200 MB rien que pour le framework, avant que la moindre logique applicative ne s'exécute. Chaque espace de travail la multiplie. Elle s'accumule au fil d'une journée de travail.
Pourquoi ne pas simplement envelopper l'application web ?
Le raccourci évident consiste à prendre l'interface web de Slack, à l'envelopper dans une fenêtre de bureau et à appeler cela un client plus léger. Plusieurs outils font exactement cela.
Nous ne voulions pas construire ça. Cela résout le problème de gestion des fenêtres — un onglet de navigateur de moins vers lequel basculer — mais ne change rien à la mémoire ni au CPU. Vous exécutez toujours Chromium. Le ventilateur s'emballe toujours. La batterie se vide toujours.
Si la solution ne s'attaque pas à la cause première, ce n'est pas vraiment une solution.
La décision de développer en natif
Nous avons choisi Qt6 — le même framework d'interface qui propulse Telegram Desktop. Qt se compile en véritable code natif : pas de navigateur embarqué, pas d'environnement d'exécution JavaScript, pas de machine virtuelle entre vos frappes au clavier et l'écran. Le résultat est une application que le système d'exploitation traite comme n'importe quelle autre application native.
Le compromis est réel. Le développement natif est plus lent à itérer que les technologies web. Les fonctionnalités prennent plus de temps à construire. Nous ne pouvons pas simplement intégrer une bibliothèque JavaScript quand nous avons besoin d'un nouveau composant. Mais le résultat est une application qui démarre en moins d'une seconde et reste à ~0 % CPU au repos. C'est précisément ce que nous voulions résoudre, et c'est résolu.
Ce à quoi nous avons renoncé — et pourquoi ce n'est pas grave
msga ne dispose pas aujourd'hui de l'ensemble complet des fonctionnalités de Slack. Les appels audio et vidéo, les Huddles, Canvas et les intégrations d'applications figurent sur la feuille de route. Si l'un de ces éléments est essentiel à votre travail quotidien, l'application officielle reste l'outil approprié pour l'instant.
Mais un très grand nombre de personnes utilisent Slack principalement pour le texte : envoyer des messages, lire des canaux, répondre dans des fils de discussion, retrouver ce que quelqu'un a dit la semaine dernière. Pour cet usage, msga fait le travail — sans la surcharge qui fait ramer votre ordinateur.
La suite
La prise en charge de macOS et de Windows est en cours de développement. L'objectif est la même expérience sur les trois plateformes : démarrage en moins d'une seconde, silence au repos, faible empreinte mémoire.
msga est gratuit, open source sous licence GPL-3.0, et développé publiquement sur GitHub. Si vous en avez assez que Slack ralentisse votre journée de travail, essayez-le.