SentinelMesh/doc_brainstorming/deep-research-report(5).md

Dossier technique sur Glance et l’ajout d’un onglet IP réseau

Périmètre de l’analyse

Le dépôt que tu as donné est bien glanceapp/glance, c’est-à-dire Glance, le dashboard self-hosted de l’organisation glanceapp. Ce n’est pas Glances de nicolargo, qui est un outil de monitoring système différent. La nuance compte beaucoup pour ton projet, parce que Glance est d’abord un framework de tableau de bord configurable en YAML, pensé pour agréger et afficher des données, pas un moteur natif de supervision réseau temps réel. citeturn2view0turn26search2turn19view0

La conséquence la plus importante pour ton besoin est celle-ci : Glance doit être traité comme la couche d’interface, tandis que le scan de ton réseau 10.0.0.0/22 et l’inventaire détaillé des IP doivent vivre dans un service séparé. Le README officiel précise en effet qu’une actualisation de page est nécessaire pour mettre à jour les informations et qu’aucune requête périodique n’est effectuée en arrière-plan par les widgets ; les données sont chargées au rendu puis mises en cache suivant la durée définie pour chaque widget. citeturn19view0

Autre point utile : le widget natif monitor existe déjà, mais il est conçu pour une liste de sites/URLs avec title, url, éventuel check-url, icon, timeouts et variantes d’affichage. Il ne correspond pas à un inventaire CIDR, à un découpage par sous-réseaux, ni à un volet détaillé par IP. Ton besoin dépasse donc nettement le périmètre des widgets intégrés actuels. citeturn12view2

Langages et technologies employés

D’après la répartition des langages affichée sur le dépôt GitHub, Glance est majoritairement écrit en Go, avec une part significative de HTML, JavaScript et CSS, puis un peu de Dockerfile. La page du dépôt affiche précisément Go 55,5 %, HTML 16,2 %, JavaScript 15,0 %, CSS 13,2 % et Dockerfile 0,1 %. Cette répartition correspond bien à ce qu’on voit dans l’arborescence : un backend Go, des templates HTML embarqués, des assets CSS/JS locaux et un packaging Docker très léger. citeturn19view0

Le cœur applicatif est un module Go nommé github.com/glanceapp/glance, et le go.mod déclare aujourd’hui Go 1.24.3. Les dépendances directes sont révélatrices : fsnotify pour la surveillance et le rechargement de config, gofeed pour les flux, gopsutil/v4 pour les métriques système, gjson pour le parsing JSON dans les widgets custom, x/crypto pour l’authentification et yaml.v3 pour toute la configuration. À noter qu’il y a un léger écart documentaire : le README parle encore d’un build avec Go >= 1.23, mais le go.mod du dépôt main pointe déjà sur 1.24.3 ; si tu recompiles, c’est le go.mod qu’il faut considérer comme source de vérité. citeturn4view0turn19view0

Le point d’entrée est volontairement minuscule : main.go ne fait qu’appeler glance.Main() depuis internal/glance. Le Dockerfile confirme le modèle de distribution : build en Go sur Alpine, avec CGO_ENABLED=0, puis copie du binaire dans une image Alpine finale. En pratique, Glance est donc pensé comme un binaire Go autonome, sans runtime Node, sans bundle frontend externe et avec une surface de build très simple. citeturn4view2turn4view1

Le frontend n’emploie pas de framework type React/Vue/Svelte. Le README insiste sur du “minimal vanilla JS”, et les guidelines de contribution ajoutent même explicitement “No package.json” et la consigne d’éviter les nouvelles dépendances. Pour un développeur, c’est un signal très clair : Glance privilégie du server-side rendering avec templates Go, des assets statiques maison, et un JavaScript utilitaire limité. citeturn19view0

Techniquement, les assets sont embarqués dans le binaire via //go:embed pour static et templates. Le code montre aussi que le CSS est bundlé au runtime à partir de internal/glance/static/css, tandis que internal/glance/static/js contient des scripts comme animations.js, calendar.js, login.js, masonry.js, page.js, popover.js, templating.js, todo.js et utils.js. Côté templates, on trouve les vues page/document/footer ainsi qu’un template HTML dédié par widget ou style de widget. citeturn9view4turn13view0turn13view1turn14view0

Structure interne de l’application

L’arborescence de haut niveau est sobre et lisible : à la racine, on a surtout docs/, internal/glance/, pkg/sysinfo/, main.go, go.mod, Dockerfile et la config de release. Pour une lecture développeur, tout le produit est concentré dans internal/glance, tandis que docs/ sert de documentation fonctionnelle et pkg/sysinfo/ isole une partie des métriques système. citeturn2view0

La structure de configuration est également très claire dans config.go. On y voit les blocs top-level server, auth, document, theme, branding et surtout pages. Chaque page possède un name, un slug, une largeur (width), des head-widgets et des columns; chaque colonne porte une size et une liste de widgets. La documentation confirme que la première page devient la page d’accueil, que les pages apparaissent automatiquement dans la navigation dans l’ordre de déclaration, et qu’une page peut avoir jusqu’à 3 colonnes, avec 1 ou 2 colonnes full au minimum. citeturn16view0turn11view0

Autrement dit, dans le vocabulaire de Glance, ton futur “tab” n’est pas une entité spéciale : c’est simplement une nouvelle page Glance. C’est une bonne nouvelle, parce que ton onglet réseau peut donc être ajouté proprement comme page dédiée, avec une largeur wide et un ou plusieurs widgets de présentation. La doc donne d’ailleurs des largeurs default, slim et wide, et associe wide à 1920 px max, ce qui est pertinent pour ton souhait d’afficher un très grand nombre de petites cases IP. citeturn11view0

Le système de widgets natifs est, lui aussi, très explicite. Dans internal/glance, on voit une série de fichiers widget-*.go et, côté templates, des fichiers *.html correspondants. La fonction newWidget dans widget.go enregistre les types connus comme calendar, clock, weather, monitor, extension, custom-api, iframe, html, server-stats, etc. Le même fichier définit une interface widget avec notamment Render(), initialize(), requiresUpdate(), update(), handleRequest() et les méthodes d’identification/configuration. En pratique, cela veut dire qu’un widget natif Glance est un type Go compilé, pas un plugin chargé dynamiquement. citeturn3view0turn24view0

Le couplage avec le rendu HTML est fort, mais propre : les widgets vivent en Go, le rendu passe par des templates de html/template, et les assets/template sont embarqués dans le binaire. J’en déduis qu’ajouter un widget natif implique toujours des modifications du code source Go, un template HTML et souvent une recompilation complète de l’application. Ce n’est pas une architecture à plugins dynamiques. citeturn24view0turn9view4turn4view1

Les options réalistes pour ajouter ton module

Officiellement, Glance documente quatre façons de créer des widgets personnalisés : iframe, html, extension et custom-api. Pour ton cas, les deux plus sérieuses sont custom-api, extension et, très franchement, iframe si tu veux une vraie mini-application interactive. Le mode html reste trop statique pour un module IPAM réseau un peu avancé. citeturn19view0turn12view0turn12view1turn12view4

Le widget custom-api est la voie la plus “Glance-compatible” quand on dispose déjà d’une API JSON. La documentation officielle dit explicitement que sa configuration demande des notions de programmation, HTML, CSS, langage de templates Go et concepts propres à Glance. Elle précise aussi que le rendu repose sur html/template et gjson. C’est très puissant si ton backend de scan publie un JSON structuré et si tu acceptes un modèle d’affichage plutôt déclaratif. Le dépôt glanceapp/community-widgets est d’ailleurs un excellent indicateur de la stratégie réelle du projet : il précise que la plupart des widgets communautaires sont faits avec custom-api, et que cette approche est beaucoup plus simple à déployer qu’une extension. citeturn12view0turn9view1turn18search2turn20search0

Le widget extension est plus souple côté langage, parce qu’il ne demande qu’un serveur HTTP renvoyant du contenu et quelques en-têtes spéciaux comme Widget-Title, Widget-Title-URL, Widget-Content-Type et Widget-Content-Frameless. Mais la doc officielle prévient de deux choses importantes : l’API d’extension est WIP et seul le type de contenu html est officiellement supporté pour l’instant. Le dépôt communautaire confirme aussi que les extensions sont plus impliquées, car elles demandent un serveur ou conteneur séparé. Autrement dit : oui, c’est faisable et élégant pour du Rust, mais c’est moins stable et plus coûteux à maintenir qu’un custom-api. citeturn9view0turn12view1turn18search2

Le widget iframe est paradoxalement très intéressant pour toi. La doc officielle le décrit simplement comme un widget capable d’embarquer une source externe avec une hauteur configurable. Ça paraît basique, mais pour un plan IP cliquable, avec volet de détails, rafraîchissement indépendant et éventuellement un peu de JS applicatif, c’est en pratique l’intégration la plus simple et la plus robuste : tu gardes Glance comme shell de navigation et tu exécutes ton mini-dashboard réseau comme une petite app web autonome. citeturn12view4turn19view0

Enfin, si tu veux modifier le cœur de Glance pour ajouter un widget “officiel” à ton fork, les technologies à employer sont sans ambiguïté : Go pour la logique, templates HTML Go pour le rendu, éventuellement un peu de JS/CSS statiques dans internal/glance/static, et la documentation YAML dans docs/configuration.md. C’est la voie la plus intégrée, mais aussi celle qui te lie le plus au codebase et aux conventions du projet. citeturn3view0turn13view1turn14view0turn24view0

Glance fournit néanmoins quelques points d’extension utiles pour “hybrider” une approche custom : le serveur peut exposer un répertoire /assets/, le document global peut recevoir du HTML custom dans <head>, et le thème supporte un fichier CSS custom. En plus, chaque widget peut recevoir un css-class, et la doc explique que Glance utilise beaucoup de classes utilitaires, avec une classe widget-type-{name} pour cibler précisément un widget. En clair, tu peux très bien injecter ton propre CSS et même ton propre JS global si tu veux enrichir un custom-api avec un comportement plus dynamique. citeturn23view0turn23view2

Architecture recommandée pour ton onglet IP

Pour ton besoin précis, je recommande une page Glance dédiée nommée par exemple “Réseau”, en width: wide, avec une seule colonne full. La raison est simple : une page Glance ne peut avoir que trois colonnes maximum, alors que ton découpage logique contient déjà quatre sous-réseaux (10.0.0.x, 10.0.1.x, 10.0.2.x, 10.0.3.x), sans compter le volet de détail. En plus, un bloc /22 représente 1024 adresses IPv4 ; à cette échelle, il vaut mieux afficher un seul grand module full-width avec quatre sections internes, plutôt que disperser l’UI dans les colonnes natives de Glance. citeturn11view0turn25calculator0

Je déconseille fortement d’embarquer le moteur de ping directement dans Glance. Le produit n’est pas conçu pour exécuter des sondes réseau en tâche de fond : il rafraîchit ses données au chargement de page, puis s’appuie sur le cache de widget. Ton service de scan doit donc être un daemon séparé qui fait le travail lourd à la fréquence de ton choix et qui publie un état matérialisé que Glance ne fait qu’afficher. C’est le découpage le plus propre techniquement, mais aussi celui qui colle le mieux à l’architecture officielle du projet. citeturn19view0

Je te conseille aussi de ne pas assimiler “IP libre” à “ne répond pas au ping”. La documentation officielle de Nmap rappelle qu’un hôte actif peut être manqué si un firewall filtre les probes ou leurs réponses, et qu’un échec de découverte ICMP ne permet pas de conclure qu’une machine est réellement absente. Pour ton dashboard, il vaut mieux distinguer au moins alive, seen/used, reserved et free, où free ne devient vrai qu’en absence de réponse et en absence d’occupation connue dans ton inventaire/DHCP/ARP. citeturn29search0turn29search1

Si tu veux le faire en Rust, le stack le plus cohérent pour le service externe est un backend de type Axum + Tokio, avec SQLite via SQLx si tu veux persister tes métadonnées riches (hardware, icon, services, link, location, parent, notes, dernières vues, etc.). Axum se présente comme une bibliothèque de routage HTTP et de handling ergonomique, Tokio comme le runtime asynchrone de référence pour I/O, timers et scheduling, et SQLx comme un toolkit SQL async “pure Rust” compatible SQLite. Pour ton besoin, c’est un trio très logique. citeturn27search0turn27search5turn27search2

L’API de ce service peut rester simple. Je te recommande un endpoint de synthèse pour le rendu global, et éventuellement un endpoint fin pour le détail d’une IP. Par exemple :

{
  "last_scan_at": "2026-05-19T12:34:56Z",
  "sections": [
    {
      "name": "VM",
      "cidr": "10.0.0.0/24",
      "items": [
        {
          "ip": "10.0.0.12",
          "state": "alive",
          "hostname": "vm-proxy-01",
          "icon": "mdi:server",
          "link": "https://vm-proxy-01.local",
          "services": ["ssh", "https"],
          "location": "rack-a",
          "parent": "pve01"
        }
      ]
    }
  ]
}

Ce schéma n’est pas imposé par Glance ; c’est le bon niveau d’abstraction pour séparer proprement scan, inventaire et présentation.

Pour l’intégration visuelle dans Glance, tu as à mon avis deux architectures vraiment pertinentes. La première, que je considère comme la meilleure pour ton cas, est une page Glance + un widget iframe plein écran pointant vers une petite app web Rust. Tu gagnes tout de suite la liberté de faire une vraie grille, un volet latéral au clic, un polling indépendant, du tri, du filtrage, voire de la navigation clavier, sans dépendre du cycle de rendu de Glance. C’est la voie la plus simple si tu veux une UX riche. citeturn12view4turn19view0

La seconde est une approche plus native visuellement : un widget custom-api qui tire un JSON de ton service Rust, rend les cases via template HTML, puis s’appuie sur css-class, custom-css-file, /assets/ et éventuellement un script injecté dans document.head pour animer un panneau de détails ou appliquer un peu de comportement côté client. Cette voie demande plus de bricolage frontend, mais elle garde un rendu plus “Glance”. Elle a aussi des précédents crédibles : le dépôt communautaire propose déjà des widgets Tailscale devices et NetAlertX Device Status qui affichent justement des équipements, leur statut et leurs IP à partir d’une API externe. citeturn12view0turn23view0turn23view2turn21search0turn22search0turn22search2

Comme ton futur widget risque vite d’être long, ne mets pas tout en vrac dans glance.yml. La documentation Glance supporte les includes YAML avec $include, et le dépôt communautaire recommande justement de sortir les widgets complexes dans des fichiers dédiés. Pour ton cas, un fichier ipam.yml séparé est la bonne pratique. citeturn11view0turn20search0

Voici le squelette Glance que je recommanderais pour la solution la plus robuste, c’est-à-dire une page dédiée + iframe :

pages:
  - name: Réseau
    width: wide
    columns:
      - size: full
        widgets:
          - type: iframe
            title: Plan IP
            source: http://ipam-ui:8088/
            height: 1200

Et si tu veux tenter le mode “plus natif Glance”, voici le principe hybride :

server:
  assets-path: /app/assets

document:
  head: |
    <script defer src="/assets/ipam.js"></script>

pages:
  - name: Réseau
    width: wide
    columns:
      - size: full
        widgets:
          - type: custom-api
            title: Plan IP
            cache: 15s
            css-class: ipam-grid
            url: http://ipam-api:8088/api/network/summary
            template: |
              <!-- grille + sous-sections + drawer -->

Le second modèle demande plus de finesse, mais il reste compatible avec les mécanismes officiellement documentés par Glance. citeturn12view0turn23view0turn23view2

Peut-on ajouter des widgets en Rust

Oui, mais pas de la même manière selon ce que tu appelles “ajouter un widget”. Si tu entends par là fournir les données et/ou le rendu depuis un service externe, alors oui, Rust convient très bien. C’est même une très bonne option, parce que Glance supporte officiellement un widget custom-api qui consomme du JSON, un widget extension basé sur un serveur HTTP externe, et un widget iframe qui peut embarquer n’importe quelle application web. Ces trois voies sont compatibles avec un backend écrit en Rust. citeturn12view0turn12view1turn12view4turn9view0

En revanche, si tu veux dire “ajouter un widget natif à Glance lui-même, dans le code de l’application”, alors la réponse réaliste est non, pas en Rust dans le cadre normal du projet. Le code source montre que les widgets natifs sont des types Go enregistrés dans newWidget, que l’application est construite comme un binaire Go unique, et que les templates/assets sont embarqués par go:embed. Le dépôt ne montre pas de système de plugins dynamiques ou de pont officiel vers Rust. Tu pourrais toujours bricoler une solution maison via FFI, sidecar ou fork très personnalisé, mais ce ne serait ni idiomatique pour Glance, ni dans l’esprit “peu de dépendances / binaire simple” affiché par le projet. citeturn24view0turn4view1turn9view4turn19view0

Ma conclusion est donc nette : si ton vrai objectif est d’obtenir rapidement un onglet IP réseau puissant et maintenable, fais-le en Rust à l’extérieur de Glance, puis intègre-le dans Glance via iframe si tu veux la meilleure interactivité, ou via custom-api si tu veux un rendu plus natif et que tu acceptes davantage de contraintes côté UI. Si ton objectif est d’ajouter un widget “first-class” au codebase Glance, alors il faut le faire en Go, avec les templates et assets du projet. citeturn12view4turn12view0turn9view0turn24view0turn4view1