Roadmap

Feuille de route produit

La V2 « cockpit universel » est livrée en lots fonctionnels indépendants — chacun shippable seul, sans jalon date imposé. La direction est claire, l'ordre aussi. Pour le détail release par release, voir le changelog public.

En cours

Le lot en chantier en ce moment.

  • Publication de l'application mobile 3.2

    mobile 3.2.1

    L'application est reconstruite et testée ; il reste à la publier sur l'App Store et Google Play. Le dernier correctif ferme la fuite qui comptait le plus : changer de compte recharge maintenant tous les écrans, même quand l'application a été fermée sans se déconnecter.

  • Connecter les dernières fonctions livrées sans écran

    Quatorze opérations de l'API existent sans page dédiée dans le cockpit — elles sont mesurées, une par une, avec leur raison, et disparaissent au fur et à mesure que les écrans arrivent.

Envisagé

La direction de la V2 « cockpit universel », en lots fonctionnels indépendants. Pas de date ferme, mais un ordre clair.

  • LOT 6 — Connecteurs Jira, GitLab et GitHub

    Les trois connecteurs aujourd'hui en aperçu deviennent fonctionnels : issues, sprints, merge requests, pipelines — rapprochés des crashes et des avis. Disponibles aussi bien sur les apps que sur les serveurs.

  • LOT 7 — Déploiement sans interruption

    Industrialisation des mises en production : rolling restart instrumenté pour réduire la fenêtre d'indisponibilité à moins d'une seconde lors des releases.

  • LOT 9 — Mise à jour automatique de l'agent (optionnel)

    Canal de distribution signé pour que les agents installés se mettent à jour proprement, au rythme choisi par l'administrateur.

  • Au-delà — bases de données, sites, conteneurs

    Le socle polymorphe posé au LOT 1 est conçu pour accueillir de nouveaux types de cibles sans refonte. Bases de données, sites e-commerce et conteneurs Docker sont la suite logique du cockpit universel.

Livré

Ce qui est déjà en production.

  • Exporter ses données en Excel ou en CSV

    v3.11.0

    Tendance mensuelle et quota Sentry au-delà des 90 jours de Sentry, crash-free par release, stores, métriques serveur sur 400 jours : un écran Exports par cible et pour le parc, prêt pour un tableau croisé.

  • Chaque alerte dit quoi et combien

    v3.8.0

    Une jauge, un chiffre ou un nom pour chacun des 38 types d'alerte, avec l'icône de la ressource touchée ; des pistes de diagnostic propres à chaque ressource. Cockpit et téléphone.

  • Profil « Runner CI » et conteneurs de job ignorés

    v3.8.0

    Une machine d'intégration continue n'alerte plus à chaque job : profil à cocher, suggéré quand GitLab Runner tourne ; les conteneurs éphémères des jobs sont ignorés partout.

  • Filtrer la boîte de réception par type, groupe et cible

    v3.7.2

    Le badge d'anomalies d'un serveur mène à ses anomalies, plus à celles de tout le parc. La boîte de réception se filtre par type, par groupe (sous-groupes compris) et par cible, sur le cockpit comme sur le téléphone.

  • Ce qui s'est réglé tout seul se voit encore

    v3.1.3

    Une alerte partie par courriel à 3 h 30 et réglée par le serveur à 6 h disparaissait de la boîte de réception : elle y reste maintenant vingt-quatre heures, marquée « Réglée » et accompagnée de ce qui l'a réglée. Au passage, deux alertes qui ne servaient à rien se taisent : le swap plein d'une machine qui ne swappe pas, et le bruit d'un serveur de compilation.

  • Une alerte par incident, et rien du compte précédent

    v3.1.2

    Un conteneur qui redémarrait en boucle produisait cinquante-quatre alertes pour une seule panne, et les robots repoussés par un serveur web étaient comptés comme des erreurs d'application. Les deux se taisent. Et changer de compte ne laisse plus les données du précédent à l'écran, même quand la session s'est terminée sans déconnexion.

  • Des alertes qui ne crient plus au loup

    v2.9.1

    Une alerte CPU se déclenchait sur un seul cœur occupé d'une machine qui en a seize, et un pic d'une minute ouvrait une alerte d'un quart d'heure. Les alertes regardent désormais la machine, exigent que le dépassement dure, et disent s'il est ponctuel ou continu. Chaque anomalie propose des pistes et un prompt prêt à copier dans l'assistant IA de votre choix.

  • Une seule navigation, et plus rien d'inatteignable

    v2.9.0

    Cinq menus concurrents fusionnent en un seul. La création d'une cible n'est plus réservée aux administrateurs. Un écran rassemble les clés IA de toutes vos cibles. Et un plan du site liste tous les écrans, y compris ceux que vos droits masquent — avec la raison.

  • Supervision prédictive, canaux d'alerte et veille de failles

    v2.8.0 → v2.8.7 · agent 1.3

    Saturation de disque annoncée à l'avance, alertes par e-mail, push, webhook signé et Telegram, inventaire logiciel avec avis de sécurité, et un brief d'alerte qui se comprend sans ouvrir le cockpit.

  • Journaux résilients et détection à partir des logs

    v2.7.0 → v2.7.8 · agent 1.2

    Lecture des journaux bornée et pagination stable, protocole d'ingestion tolérant aux versions, et sept nouveaux types d'anomalie dérivés des logs : rafale d'erreurs, erreurs disque, force brute SSH, processus qui plante.

  • Application mobile 3.0 — nouvelle génération

    mobile 3.0.0

    L'application iOS et Android reconstruite sur un socle neuf : interface adaptée aux tablettes, notifications plus fiables, mode hors ligne qui rejoue vos actions au retour du réseau.

  • Mobile 2.5 — hors ligne, arrière-plan, notifications riches

    mobile 2.5.0

    Cache persistant et lecture hors ligne, actions (acquitter, résoudre, reporter) mises en file et rejouées au retour du réseau, rafraîchissement en arrière-plan avec badge, notifications avec titre, corps et action « Acquitter », vue d'ensemble, liens app ↔ serveur, création d'une cible serveur avec QR code, seuils d'alerte, sondes et conteneurs sur la fiche serveur.

  • LOT 3 — Vue d'ensemble, liens app ↔ serveur et cockpit temps réel

    v2.6.0

    Vue d'ensemble de toutes les cibles triées par priorité avec la topologie « hébergée sur », mises à jour en temps réel (plus de rafraîchissement périodique), boîte de réception paginée et fluide, cockpit installable comme une application, chargement initial quatre fois plus léger. StatHall se surveille lui-même (planificateur, workers, connecteurs, fraîcheur des données).

  • LOT 2 — Serveurs supervisés de bout en bout : agent 1.1 + sondes

    v2.5.0 · agent 1.1.0

    Agent Unix 1.1 (vingt métriques système, conteneurs Docker, timers systemd, redémarrage requis, processus tués faute de mémoire), sondes HTTP / TCP / TLS exécutées depuis le cockpit avec alerte sur certificat proche de l'expiration, agent silencieux signalé comme anomalie, seuils réglables par serveur, rétention bornée. Détection fiabilisée pour les apps : taux d'ANR Android ingéré et notifié, dernier point disponible pris en compte, escalades notifiées.

  • LOT 4 — Fair-use, dons et ouverture open-source

    v2.4.0

    Plus de tarif ni d'abonnement : instance hébergée gratuite (fair-use), code publié en open-source (AGPL-3.0) pour l'auto-hébergement, soutien volontaire par les dons.

  • LOT 1 — Socle « cockpit universel »

    v2.0.0-rc.1

    Refonte interne du modèle de données : StatHall ne supervise plus seulement des « apps » mais des « cibles supervisées » génériques, prêtes à accueillir les serveurs (LOT 2) puis les bases, sites et conteneurs. Migration transparente — toutes les apps, connecteurs et historiques V1 sont conservés à l'identique. Les contributeurs Buy Me A Coffee historiques sont reconnus comme « Founding supporters ». Suivi des correctifs de fiabilité du score de santé en rc.2 → rc.5 dans le changelog public.

  • Avant la V2 — StatHall V1

    v1.0.0

    Tout le socle hérité : supervision d'apps mobiles (Sentry, Apple App Store Connect, Google Play, Firebase), synthèses IA des avis, détection d'anomalies, corrélation crash ↔ avis, roadmap, mode SaaS multi-tenant et mode auto-hébergé, app mobile iOS/Android, site marketing. Le détail version par version reste consultable dans le changelog public.