Glass : navigateur, éditeur et terminal dans une seule app
📌 Glass rassemble un navigateur complet, un éditeur de code et un terminal dans une seule application, pour enchaîner la recherche, l’écriture et l’exécution sans jongler entre trois fenêtres et des dizaines d’onglets.
L’idée est simple: tout ce qui sert à avancer sur un sujet (lire, copier des extraits, tester une commande, modifier un fichier, relancer un service) se fait dans le même environnement. Le navigateur reste utilisable “tel quel” pour les usages classiques, et l’éditeur + le terminal deviennent disponibles quand il faut passer à l’action. Le résultat attendu n’est pas un “IDE plus gros”, mais un poste de travail cohérent, où la navigation et l’exécution ne sont plus des contextes séparés.
Glass est aussi un projet très concret: une application de bureau en développement actif, avec une priorité actuelle sur macOS et une ambition multi-plateforme à terme (Windows, Linux, iOS, Android). Cela implique des choix d’installation et de maturité: la meilleure expérience est logiquement là où l’équipe itère le plus vite, et le reste viendra ensuite.
Au quotidien, Glass sert surtout à réduire les frictions entre trois tâches qui s’entremêlent en permanence: comprendre un sujet (documentation, tickets, articles, dashboards), modifier quelque chose (code, config, notes) et vérifier le résultat (commande, build, requête, service). Quand tout est côte à côte, le temps perdu en alt‑tab, en recherche d’onglet, en contexte mental et en micro-latences s’accumule beaucoup moins.
Ce que Glass simplifie vraiment
Dans une configuration classique, le navigateur détient les infos, l’éditeur détient le projet, et le terminal détient la réalité d’exécution. On finit par faire des allers-retours: copier/coller, retaper une commande, retrouver un onglet, recoller un lien dans un fichier, ouvrir un nouvel outil pour suivre des logs. Avec Glass, le navigateur reste le point d’entrée, mais l’action (modifier, lancer, inspecter) est au même endroit, sans casser le fil.
Cela change particulièrement les scénarios “mi-projet mi-recherche”: intégrer une librairie, reproduire un bug, préparer un script, comprendre un dépôt, tester une requête, écrire un guide interne, vérifier une configuration. Le but n’est pas d’empiler des fonctionnalités, mais de rapprocher les opérations qui se répondent.
Démarrage et mode d’utilisation
L’entrée la plus simple consiste à l’utiliser comme navigateur, puis à ouvrir l’éditeur et le terminal au moment où il faut passer de “je lis” à “je fais”. Les gestes qui reviennent ensuite sont très stables: naviguer jusqu’à une doc, prendre un extrait, modifier un fichier, lancer une commande, vérifier, itérer. Cette boucle est exactement ce que Glass cherche à optimiser.
Pour le côté “outil”, le projet se présente comme une application à installer/mettre à jour comme n’importe quel logiciel de bureau. Pour le côté “projet”, le code est disponible publiquement et le build se fait en local, avec des scripts et une documentation orientés développement. L’approche est pragmatique: le logiciel doit tourner vite, s’intégrer au système, et rester agréable en usage prolongé.
Points clés
- 🧭 Un navigateur complet et utilisable seul, avec l’éditeur et le terminal intégrés quand c’est nécessaire
- 🧩 Un même contexte pour lire, modifier et exécuter, sans “casser” le flux entre web, fichiers et commandes
- 🖥️ Priorité actuelle à macOS, multi-plateforme annoncée à plus long terme
- 🧱 Héritage d’un éditeur moderne (fork d’un projet existant), avec des changements UI et des composants natifs macOS
- 🧰 Une base technique qui vise aussi à servir de fondation à d’autres apps via un framework UI dédié
Un poste de travail pour les tâches mixtes
Les cas d’usage les plus évidents sont ceux qui demandent de “tenir” en même temps le web et l’exécution: suivre une doc, expérimenter une API, lire un ticket, puis adapter un code ou une config et relancer. Dans ce type de séquence, le navigateur n’est pas un outil annexe: c’est là que sont les sources, les dashboards, les consoles, les outils SaaS, les pages d’aide, les diffs, les références. En rendant l’éditeur et le terminal immédiatement disponibles à côté, Glass réduit la distance entre l’information et l’action.
Autre scénario courant: explorer un dépôt. Il faut lire des fichiers, comprendre des conventions, chercher une fonction, lancer une commande, lire une sortie, puis revenir à une page de doc ou à une issue. Ici aussi, la promesse est de garder un seul “bureau” mental. Cela peut sembler marginal, mais sur des sessions longues, c’est souvent un gain net en fatigue et en erreurs d’attention.
Architecture et écosystème
Glass se construit sur la base d’un éditeur existant et s’aligne régulièrement sur ses évolutions, ce qui a deux effets pratiques. D’un côté, cela donne une base déjà solide sur les fondamentaux (édition, performances, interactions). De l’autre, cela implique un rythme d’intégration et de compatibilité: il faut accepter que le projet avance vite et que certaines parties restent en mouvement, surtout en phase “active development”.
Le projet s’appuie aussi sur un framework UI (GPUI) séparé dans un dépôt distinct, avec des extensions et une orientation composants natifs. Pour un utilisateur, l’intérêt est indirect mais réel: meilleure intégration plateforme, rendu plus cohérent, et capacité à faire évoluer l’app sans se battre contre une couche UI générique. Pour un contributeur, cela clarifie les frontières: l’app d’un côté, le framework de l’autre, avec la possibilité de travailler localement sur les deux quand c’est nécessaire.
Confidentialité, données et surface d’exposition
Comme tout outil qui embarque un navigateur, un éditeur et un terminal, la question n’est pas “est-ce que c’est sensible ?” mais “qu’est-ce qui transite où ?”. Le navigateur consomme des services web, l’éditeur manipule des fichiers locaux, et le terminal exécute des commandes. La pratique saine consiste à considérer l’app comme un environnement de travail: limiter ce qui est ouvert, isoler les comptes, et rester attentif aux permissions (dossiers, trousseau, accès réseau) comme pour n’importe quel navigateur + terminal.
L’intérêt d’une app unifiée, paradoxalement, peut aussi être une réduction de la dispersion: moins d’outils ouverts, moins d’extensions hétérogènes, moins de copies temporaires dans des endroits inattendus. Le point clé reste l’usage: ce qui est exécuté dans un terminal a toujours le même niveau de pouvoir, quel que soit l’enveloppe.
Comment se faire un avis rapidement
Le test le plus parlant consiste à prendre une tâche réelle d’une heure: lire une doc, modifier un petit projet, lancer deux ou trois commandes, et garder une page de référence ouverte. Si le flux est plus simple et si les retours en arrière (retrouver un onglet, recoller un lien, recontextualiser) diminuent, l’approche “tout‑en‑un” a du sens. Si au contraire le regroupement gêne (habitudes multi-écrans, outils spécialisés, workflows très segmentés), il vaut mieux le voir comme une expérimentation plutôt qu’un remplacement immédiat.
Liens utiles: https://glassapp.dev/ et https://github.com/Glass-HQ/Glass
À retenir: Glass vise un environnement unique pour naviguer, éditer et exécuter, avec un focus plateforme assumé et une direction claire vers un poste de travail plus cohérent que l’empilement d’apps.
