Historique des versions

Les failles de Docker et containerd, dès leur publication

StatHall lit désormais les avis de sécurité que Docker et containerd publient sur leurs propres dépôts, chaque nuit. Une mise à jour qui corrige une faille du moteur Docker, de sa ligne de commande, de Compose, de buildx ou de containerd est signalée dès sa sortie, sans attendre qu’elle soit reprise dans les bases publiques, ce qui peut prendre plus d’une semaine.

Les failles moyennes comptent aussi

Une faille de gravité moyenne qu’une mise à jour disponible corrige ouvre désormais une alerte, en priorité basse (P2). Une faille haute la passe en P1, une critique en P0. Son nom devient « Faille corrigeable non appliquée ».

Ranger une machine sans la partager

Vous pouvez ranger dans vos groupes une machine dont vous n’êtes pas co-propriétaire, pour vous y retrouver dans votre catalogue. C’est un simple classement : il ne donne aucun droit sur la machine aux autres membres du groupe et n’y applique aucune règle ni alerte de groupe. Le groupe l’indique par la mention « Classement seul ».

Des boutons seulement quand ils servent

La roadmap d’une app ne montre ses boutons d’édition (version, jalon, paramètres) qu’aux personnes qui peuvent la modifier : propriétaire et co-propriétaires. Les autres membres la consultent sans boutons qui seraient refusés.

Une version abandonnée se range

Une version marquée « sautée » ne sortira pas : elle rejoint l’historique, masqué par défaut, avec les versions déjà sorties.

Les propriétaires d’une app éditent sa roadmap

Le propriétaire et les co-propriétaires d’une app peuvent de nouveau ajouter une version, un jalon ou régler la cadence de sa roadmap : les boutons n’étaient visibles que pour l’administrateur de l’instance. Quand une modification est refusée, le cockpit dit pourquoi.

Le formulaire s’ouvre là où on le voit

« Ajouter une version » ouvre son formulaire en haut de la roadmap, et non plus sous un long historique. Un numéro de version déjà présent est signalé.

L’historique se replie

Les versions déjà sorties et les jalons passés sont masqués par défaut : la roadmap montre ce qui vient. « Afficher l’historique » les fait réapparaître.

Une liste qui dit ce qui reste à faire

Le filtre par défaut de la boîte de réception, « À traiter », ne garde plus les alertes réglées : une faille corrigée dans la nuit n’y apparaît plus le matin. Ce qui s’est réglé depuis 24 heures reste lisible sous « À traiter + acquittées + réglées », sur le cockpit comme sur le téléphone.

Un agent qui survit au redémarrage du serveur StatHall

Si un serveur redémarre pendant que le cockpit est lui-même indisponible, l’agent (1.3.21) démarre quand même et réessaie, au lieu de s’arrêter jusqu’à une relance à la main.

Une alerte qui suit la correction

Une image de conteneur ou un paquet mis à jour dans la journée quitte aussitôt le détail de son alerte, au lieu d’y rester jusqu’au lendemain.

Une base à jour

Le cockpit et ce site sont désormais construits avec Node 24, la version de Node suivie à long terme. Rien ne change à l’usage : c’est l’outillage de construction qui reste dans sa période de support.

Plus besoin d’attendre l’heure

Après une mise à jour de paquets, l’agent (1.3.20) renvoie l’inventaire de la machine dans les minutes qui suivent, au lieu d’attendre le relevé horaire : une faille corrigée quitte le cockpit presque aussitôt. Le coût pour la machine reste négligeable.

Le score dit pourquoi

Chaque carte de la vue d’ensemble nomme ce qui retire des points à son score de santé (« −60 Faille critique non corrigée »), et la carte « Santé moyenne » ouvre la liste triée de la plus basse à la plus haute. Une cible dont un composant n’est pas daté plafonne à 90 au lieu d’afficher 100, et la carte dit lequel.

Plus de faille silencieuse

Une faille dont le correctif est publié depuis plus d’un jour alerte désormais même si la machine ne le voit pas encore : son index de paquets n’est plus à jour, l’alerte vous invite à le rafraîchir.

PHP et Laravel datés, une Inbox plus nette

Une image Docker construite sur votre machine est datée par ce qu’elle contient : la version de PHP, Node.js, Python, Go ou Ruby qu’elle embarque, et Laravel, Symfony, Drupal ou CakePHP lus dans le composer.lock du projet (agent 1.3.19). La boîte de réception masque par défaut les alertes acquittées ; un filtre les retrouve, sur le cockpit comme sur le téléphone. Dans les journaux d’un serveur, un refus du pare-feu, du serveur web ou d’un scanner SSH porte désormais la mention « défense » au lieu du rouge d’une erreur.

Moins de fausses alertes

La mémoire d’un conteneur ne compte plus le cache disque que le système libère à la demande. Une base de données qui garde ses fichiers en cache n’apparaît plus « presque pleine » : seules la mémoire réellement occupée et la mémoire partagée comptent. Mettez à jour l’agent (1.3.18) pour en profiter.

Moins de bruit

Un conteneur qui redémarre en boucle ne produit plus une alerte à chaque cycle : la panne reste une alerte ouverte jusqu’à ce que le conteneur tienne réellement, au lieu de se fermer et de se rouvrir toutes les quelques minutes — avec une notification à chaque fois.

Plus rapide

Le classeur Excel se prépare environ deux fois plus vite, y compris le classeur complet de tout votre parc, et sans alourdir le serveur.

Ce qui change dans le fichier

Chaque feuille est désormais une plage avec filtres et en-tête figé, plutôt qu’un « tableau » Excel mis en forme. Le tableau croisé dynamique fonctionne exactement comme avant : cliquez dans les données puis Insertion › Tableau croisé dynamique. Ctrl+T remet la plage en forme de tableau si vous le souhaitez.

Corrections

• Un classeur Excel contenant une issue dont le titre porte des caractères invisibles (des octets binaires remontés par une application) s’exporte désormais normalement, au lieu d’échouer.
• La préparation d’un gros classeur ne ralentit plus le reste du cockpit pendant qu’elle s’exécute.

Ce que StatHall garde, enfin exportable

Sentry ne conserve que 90 jours de statistiques : la consommation de votre quota mois après mois n’existe plus chez lui. StatHall la relève chaque jour et la garde, comme la tendance mensuelle des issues, le crash-free release par release, les métriques des stores ou, pour un serveur, 400 jours de métriques système. Le nouvel écran Exports vous les rend dans un fichier.

• Un onglet Exports sur chaque application et chaque serveur, et un écran Exports pour tout le parc, dans Mes cibles.
• Treize jeux de données : tendance mensuelle issues et quota Sentry, quota au jour ou au mois, issues, occurrences par issue, sessions et crash-free par release, métriques et avis des stores, versions, métriques système des serveurs, disponibilité des sondes, événements de l’agent, fins de support, anomalies.
• Période et granularité au choix : 3, 6 ou 12 mois entiers, depuis le début, ou des dates libres ; au jour ou au mois.

Prêt pour Excel

• Excel : une feuille par jeu, en vrai tableau Excel (filtres, source directe d’un tableau croisé dynamique), dates et nombres typés, et une feuille « À propos » qui date l’extraction et définit chaque colonne. Un bouton réunit tous les jeux dans un seul classeur.
• CSV : séparateur « ; » et virgule décimale en français, il s’ouvre tel quel d’un double-clic.
• Chaque ligne porte le nom de la cible : un export du parc compare vos applications ou vos serveurs sans retouche.

Sécurité

Vous n’exportez que les cibles dont vous voyez les données. Chaque export est inscrit au journal d’audit, l’auteur d’un avis n’est jamais exporté, et un texte venu d’un service tiers ne peut pas devenir une formule dans votre tableur.

Alertes

Un robot qui réclame des fichiers inexistants à votre site n’ouvre plus d’alerte « rafale d’erreurs » : nginx écrit ces demandes en erreur, mais c’est le visiteur qui se trompe, pas votre serveur. Les lignes restent consultables dans les journaux, et l’alerte indique toujours combien de lignes elle a écartées.

Sécurité

Renforcement de la posture de sécurité du service. Aucune action n’est nécessaire de votre part.

Sécurité

Renforcement de la posture de sécurité du parcours de connexion. Aucune action n’est nécessaire de votre part.

Sécurité

Renforcement de la posture de sécurité des parcours de connexion, d’inscription et de récupération de compte, sur le cockpit comme sur l’application mobile. Aucune action n’est nécessaire de votre part.

Vos anomalies urgentes, sur un écran à vous

Un tableau de bord mural, un script de supervision, un écran dans l’atelier : un client de confiance peut désormais lire le nombre d’anomalies urgentes (P0 et P1) de vos cibles, et le nom des cibles concernées, sans ouvrir de session dans un navigateur. Le compte suit exactement celui de votre Inbox : une alerte acquittée, reportée ou résolue disparaît d’elle-même de l’écran.

Des jetons de service, en lecture seule

L’accès passe par un jeton de service, créé depuis Paramètres › Accès API. Un jeton lit un agrégat précis et rien d’autre : il ne donne accès à aucun écran ni à aucune autre partie de l’API, et ne peut rien modifier.

• La création demande votre mot de passe et un code de double authentification ; le jeton ne s’affiche qu’une fois.
• Chaque jeton expire au plus tard au bout de 90 jours. Vous êtes prévenu une semaine puis la veille de l’échéance, et vous le régénérez sans coupure : l’ancien reste valable le temps de déployer le nouveau.
• Vous pouvez limiter un jeton à l’adresse de votre réseau, en un clic.
• Vous êtes prévenu sur Telegram et par e-mail à la création, au premier usage depuis une nouvelle adresse, et à tout usage anormal. Un jeton utilisé de façon suspecte est suspendu automatiquement.
• La révocation prend effet immédiatement.

Sécurité

Renforcement de la posture de sécurité.

Chaque composant a désormais sa fin de support

StatHall date tout ce que font tourner vos cibles : la distribution, les bases et les langages installés depuis un dépôt tiers, les images Docker en service, les frameworks de vos SBOM, les exigences de Google Play et de l’App Store pour vos applications, l’agent StatHall et la base PostgreSQL d’un projet Supabase. Le calendrier vient d’endoflife.date et il est mis à jour chaque jour. Aucune donnée de votre parc ne part pour autant : on télécharge tout le calendrier, on ne demande jamais « et ce produit-là ? ».

Un paquet fourni par votre distribution suit la fin de support de la distribution : Debian corrige son Python jusqu’au bout, quoi qu’en dise python.org. Seul ce qui vient d’un dépôt tiers suit le calendrier de son éditeur. Un support étendu (Ubuntu Pro, Debian ELTS) est pris en compte dès qu’il est actif.

Une puce « Support », moins grave qu’une faille

Chaque composant est placé sur une échelle à sept niveaux : trois avant l’échéance (fin annoncée, à planifier, imminente), trois après (hors support, hors support de longue date, abandonné), et « non couvert » quand la date est inconnue. Ne pas savoir n’est jamais présenté comme « à jour ».

La puce apparaît sur la liste des cibles, l’en-tête, la vue d’ensemble, l’onglet Sécurité et la fiche de chaque application, et sur le téléphone. Une fin de support ouvre une seule alerte par cible, jamais critique : elle ne compte pas sur la pastille de l’icône. Vous êtes notifié quand un composant passe hors support, et l’alerte se ferme d’elle-même dès qu’il est monté de version.

Un écran « Cycle de vie »

Toutes les échéances de votre parc réunies, triées par gravité puis par date, filtrables par niveau et par origine. Pour une application, renseignez son targetSdk Android et son SDK iOS dans sa configuration : StatHall vous prévient avant que les stores refusent vos mises à jour.

Corrections

• Notifications push : sans réglage de votre part, les alertes P0 et P1 sont désormais envoyées sur votre téléphone, comme l’écran de réglages l’affichait déjà. Les e-mails restent à activer.
• Aide en ligne : l’index des articles se met de nouveau à jour chaque jour.
• Synchronisation Google Play : une indisponibilité passagère de Google ne fait plus échouer la synchronisation des données de stabilité.
• SBOM : plusieurs SBOM sur une même cible (API, front) coexistent au lieu de s’effacer.

Les failles ne recommandent que des versions stables

Quand une faille de sécurité est corrigée, StatHall indique la version à installer. Une version alpha, bêta ou candidate n’est plus jamais proposée : si seule une pré-version corrige une faille du logiciel d’une image ou d’une dépendance applicative, aucune alerte « corrigeable » ne s’ouvre avant la publication d’une version stable.

Préparer une icône toujours juste

Le serveur prévient désormais l’application mobile de chaque changement d’une alerte P0 — ouverture, acquittement, report, fermeture —, même quand ce changement ne vous envoie aucune notification (une mesure revenue à la normale, la nuit pendant vos heures calmes). Ce signal ne s’affiche pas : il permettra à l’application de garder juste le nombre affiché sur son icône, à partir de sa prochaine version.

Les corrections se constatent dans les minutes qui suivent

Les failles de sécurité et les images de conteneurs en retard n’étaient réévaluées qu’une fois par nuit : une mise à jour faite le matin laissait son alerte ouverte jusqu’au lendemain. Désormais, dès que l’agent signale un changement sur un serveur — des paquets mis à jour, un conteneur recréé sur une nouvelle image —, ce serveur est réévalué et l’alerte se ferme d’elle-même si la correction est réelle. La passe de nuit reste en place.

Filtrer la boîte de réception par niveau

La boîte de réception sait ne rendre que les alertes d’un niveau donné — la base de la nouvelle puce « P0 » de l’application mobile.

Une image reconstruite à l’identique n’est plus annoncée en retard

Avec les versions récentes de Docker, reconstruire une image sans rien changer lui donne un nouvel identifiant. StatHall compare désormais le contenu réellement en service, comme le fait Docker Compose : seule une image dont le contenu a changé est signalée. Demande l’agent 1.3.15.

Les failles de vos dépendances applicatives alertent enfin

Une faille corrigée dans une dépendance déclarée par un SBOM ouvre désormais l’alerte de failles du serveur, avec la version qui la corrige dans votre branche.

Les correctifs de sécurité connus dans l’heure

L’agent relit la liste des paquets toutes les heures : un correctif de sécurité disponible apparaît dans le cockpit dans l’heure, et non plus jusqu’à un jour plus tard.

Les failles de vos conteneurs ne comptent plus en double

Une même faille publiée par deux bases de sécurité n’apparaît plus qu’une fois dans l’onglet Sécurité d’un serveur, avec sa note de gravité.

Les failles connues au-delà des paquets de la distribution

La veille de failles d’un serveur ne regardait que les paquets de sa distribution. Elle suit désormais aussi :

• les paquets installés depuis le dépôt de Docker (containerd.io, plugins Compose et Buildx) ;
• le logiciel de certaines images en service : Traefik, Caddy et Gitea tirées de leur dépôt officiel.

Une faille corrigée par l’éditeur s’affiche avec la version la plus proche qui la corrige, dans l’onglet Sécurité et dans l’alerte du serveur. Une version à jour n’hérite jamais des failles d’une autre branche.

La version en service est celle du tag

Quand une version corrective est publiée pour une image épinglée, l’alerte affiche désormais la version du tag en service, et non une version héritée de l’image de base.

Une alerte d’image n’a plus lieu pendant un déploiement

Une image tout juste reconstruite ou tirée n’est signalée que si le retard dure : le moment où un déploiement remplace ses conteneurs ne déclenche plus rien. L’alerte dit aussi plus justement ce qui s’est passé (image tirée, reconstruite sur la machine, ou d’origine inconnue) et n’affiche plus une version héritée de l’image de base. Demande l’agent 1.3.14 pour des versions exactes.

Une alerte quand un conteneur ne tourne pas sur l’image à jour

La fiche d’un serveur signale désormais les conteneurs en retard, avec le geste qui les rattrape :

• image déjà tirée mais pas appliquée — la nouvelle version attend sur la machine, il ne manque que la recréation du conteneur ;
• image reconstruite mais pas appliquée — le piège du restart qui ne recharge pas le code ;
• version corrective publiée — un tag figé comme v3.7.5 alors que la v3.7.13 est sortie ;
• image plus récente au registre sous le même tag.

Une seule alerte par serveur, qui liste les images concernées et leurs versions. Elle demande l’agent 1.3.13, en lecture seule comme toujours.

Les pistes de diagnostic nomment le service en cause

Quand une alerte serveur propose une commande à lancer sur la machine, elle disait « journalctl -u <unité> » et vous laissait retrouver le service. Elle le remplit désormais : le service en échec, celui qui produit la rafale d’erreurs, ou le programme qui a planté. La commande se copie et se lance telle quelle.

Le cockpit s’ouvre directement sur la dernière version

Après une mise à jour, le cockpit pouvait d’abord s’afficher dans sa version précédente, gardée par le navigateur, avant de se recharger de lui-même. La page de connexion annonçait alors un autre numéro de version que ce site. Désormais, la page est toujours demandée au serveur : la version affichée est celle qui tourne, partout. Hors connexion, le cockpit s’ouvre toujours.

Les plantages regroupés ne se répètent plus

Une même série de plantages pouvait encore apparaître deux ou trois fois parmi les incidents, sous des vues calculées à des jours différents. Seule la plus récente reste ouverte désormais.

Un regroupement qui ne plante plus se ferme

Quand plus aucun des plantages d’un regroupement ne se produit depuis deux semaines, ou qu’ils sont tous résolus ou ignorés, l’incident se ferme de lui-même. S’il revient, il se rouvre. Un incident que vous avez fermé vous-même reste fermé.

Un incident réglé ne reste plus en attente

Quand toutes les alertes d’un incident sont closes depuis une journée, l’incident se ferme de lui-même. Il ne vous demande plus de trancher un problème résolu depuis longtemps. Un incident que vous avez confirmé ou écarté garde votre décision.

Plus de doublons parmi les plantages regroupés

Un même groupe de plantages pouvait apparaître plusieurs fois dans la liste des incidents, un nouvel exemplaire par jour. Il n’en reste qu’un, mis à jour au fil des jours.

Une veille de failles plus rapide et plus sobre

Le contrôle quotidien des failles de sécurité de vos serveurs ne tourne plus qu’une fois par nuit, et ne relit plus plusieurs fois les mêmes avis de sécurité : il se termine bien plus vite et ménage votre base de données.

Agent 1.3.11

Un service réparé pendant le redémarrage de l’agent ou de la machine est désormais signalé comme rétabli, au lieu de laisser son alerte ouverte.

Un conteneur qui a récupéré n’est plus signalé en mauvaise santé

Quand le système manque de mémoire, il peut arrêter un processus à l’intérieur d’un conteneur ; Docker s’en souvient ensuite jusqu’au prochain redémarrage du conteneur, même si le service a repris normalement en quelques secondes. Un conteneur en marche et en bonne santé n’est plus signalé pour cette raison. Le manque de mémoire lui-même reste signalé par sa propre alerte, et un conteneur réellement arrêté ou malade après un tel incident continue de vous alerter.

Des failles comparées au bon numéro de version

Les correctifs de sécurité sont publiés pour le logiciel d’origine d’un paquet, qui ne porte pas toujours le même numéro de version que le paquet installé. L’agent 1.3.10 rapporte désormais les deux, tels que le système les connaît : StatHall n’a plus à les déduire, et chaque faille est comparée au bon numéro.

Mettez à jour l’agent sur vos serveurs (apt upgrade) pour en profiter ; un agent plus ancien continue de fonctionner comme avant.

Chaque faille a sa gravité

L’écran Sécurité affiche désormais la gravité de chaque faille connue (critique, haute, moyenne ou faible) et son score CVSS, calculés à partir des informations publiées par les distributions.

Une alerte par serveur, quand il y a quelque chose à faire

Quand des failles graves touchent un serveur et que la mise à jour qui les corrige est disponible, vous recevez une seule alerte pour ce serveur : la faille la plus grave en tête, puis la liste des paquets à mettre à jour. Une faille qu’aucune mise à jour disponible ne corrige, ou que la distribution juge négligeable, reste visible dans l’écran Sécurité sans vous alerter.

Moins de failles imaginaires

Certaines bibliothèques portent un numéro de version différent de celui du logiciel dont elles sont issues. StatHall les comparait parfois au mauvais numéro et signalait des failles corrigées depuis longtemps. La bonne version est désormais retrouvée.

Seul le noyau qui tourne compte

Après une mise à jour, Debian et Ubuntu gardent les noyaux précédents sur le disque. Leurs failles étaient comptées comme celles de la machine, alors qu’ils ne tournent pas et que leur correctif est déjà installé : c’est le noyau démarré. Ils sont désormais écartés de l’analyse.

Chaque faille à sa version

Quand plusieurs versions d’un même logiciel coexistent, chacune ne porte plus que ses propres failles. Le nombre de failles corrigeables d’un serveur redevient la liste des mises à jour réellement disponibles.

Ce qui se corrige sur un serveur Ubuntu

Sur un serveur Ubuntu, l’écran Sécurité n’affichait jamais de faille corrigeable, même quand une mise à jour était disponible. Chaque faille connue est désormais reliée à la version qui la corrige : le chiffre mis en avant dit enfin ce qu’une mise à jour réglerait.

Le verdict d’Ubuntu est pris en compte

Comme pour Debian, les failles qu’Ubuntu juge négligeables (théoriques, sans correctif prévu) sont comptées à part, parmi celles qui ne demandent aucune action. Une faille négligeable qu’une mise à jour corrige reste, elle, dans la liste des choses à faire.

Prêt pour les prochaines versions

Les prochaines versions d’Ubuntu et de Debian seront reconnues dès leur sortie, sans attendre une mise à jour de StatHall. La date de fin de support d’une version d’Ubuntu récente est désormais connue, ou déduite du calendrier d’Ubuntu : vous êtes prévenu à temps, jamais trop tôt.

Des analyses plus complètes

Une indisponibilité passagère de la base des failles connues ne laisse plus de serveurs sans analyse jusqu’au lendemain, et une faille n’est plus annoncée corrigée faute d’avoir pu la relire.

Plus d’interruption au petit matin

La mise à jour quotidienne de la base des failles connues demandait trop de mémoire d’un seul coup et pouvait interrompre le service quelques instants, tôt le matin. Elle traite désormais ces données par petits lots et ne garde que ce qui concerne vos logiciels : le service reste disponible, et les failles signalées sont exactement les mêmes.

Moins de fausses alertes sur les conteneurs

Une commande ponctuelle lancée dans un conteneur temporaire (une migration, un script d’administration) n’est plus signalée comme un conteneur en mauvaise santé : comme les tâches d’intégration continue, elle est reconnue comme éphémère et écartée.

Plus de ralentissements quand le cockpit est ouvert longtemps

Chaque onglet du cockpit ouvert réservait des ressources du serveur pendant toute la durée de sa connexion en temps réel. Avec beaucoup d’onglets ouverts en même temps, le cockpit pouvait devenir lent puis afficher des erreurs pour tout le monde. Ces ressources sont maintenant libérées tout de suite : ouvrir le cockpit dans plusieurs onglets ne pèse plus sur le service.

La politique de confidentialité couvre l’application mobile

Elle dit maintenant ce que l’application pour iPhone, iPad et Android envoie et à qui : l’enregistrement de l’appareil pour vous alerter, les notes que vous écrivez, les rapports de plantage (désactivables dans l’application). Les hébergeurs et prestataires y sont nommés.

Supprimer son compte, pas à pas

Une nouvelle page de documentation, Supprimer son compte, décrit les étapes depuis le cockpit ou l’application, ce qui est effacé et le délai de rétractation. Ce délai est de 14 jours : les conditions d’utilisation et la politique annonçaient 30 jours, elles sont corrigées.

Une seule version des pages légales

Les pages légales ouvertes depuis le cockpit ou l’application mènent désormais au site, qui en tient la seule version à jour.

Renforcement de la posture sécurité

Avant la mise en vente de l’application mobile, une revue de sécurité de l’API et de l’application a conduit à plusieurs renforcements : limites de débit plus justes, journaux plus discrets, et compte de démonstration des stores protégé. Rien ne change dans vos usages.

Chaque page existe aussi en texte

Toutes les pages du site — documentation, pages produit, changelog, pages légales — sont disponibles en Markdown à la même adresse suffixée .md (par exemple /docs/incidents.md) : pratique pour coller une page dans un assistant ou la lire hors navigateur. Le contenu est le même que la page, sans le menu ni la mise en page. Un fichier /llms.txt recense les pages principales.

Des liens qui mènent où ils le disent

Le bouton de langue ne mène plus à une page qui n’existe pas : quand une page n’a pas encore de version anglaise, il ouvre la rubrique la plus proche. Les pages Serveurs Unix, Agent et Super-dashboard sont accessibles depuis le menu Produit. Une adresse inconnue affiche désormais la page d’erreur du site, dans la bonne langue.

Des dates et des versions qu’on peut suivre

Chaque article de documentation affiche sa date de mise à jour, et les pages légales la leur, dans un format uniforme. Le changelog a un flux Atom (/changelog/feed.xml) pour être prévenu des nouvelles versions, et chaque version a son ancre (/changelog/#v3.8.10). L’accueil indique enfin que la supervision des conteneurs Docker est disponible — elle l’est depuis l’agent 1.1.

Le cockpit reste entre vous

L’application (le cockpit) demande désormais aux moteurs de recherche et aux robots de ne pas l’explorer ni l’indexer : seul le site public a vocation à apparaître dans les résultats.

Plus léger

Les pages sont servies compressées, et une police qui n’existait pas n’est plus demandée à chaque visite.

Cibles, santé et applications s’affichent sans attendre

Sur l’application mobile, les écrans Cibles, Santé et la liste des applications pouvaient rester bloqués puis afficher « Le serveur met trop de temps à répondre » lorsque le parc comptait une application très riche en plantages. Le contrôle d’accès aux données est désormais calculé une seule fois par requête : ces écrans répondent en quelques dixièmes de seconde, sans rien changer à ce que chacun a le droit de voir.

Le pliage du catalogue est enregistré dans votre compte

Les groupes que vous repliez dans le catalogue le restent sur tous vos navigateurs et tous vos postes : l’état est enregistré dans votre compte, plus seulement dans l’onglet ouvert.

Un groupe replié signale ses alertes

Un groupe replié affiche le nombre de ses serveurs et applications en alerte, sous-groupes compris : replier un groupe ne cache plus un problème.

Vos groupes restent comme vous les avez laissés

Dans le catalogue, les groupes que vous repliez le restent quand vous ouvrez un serveur ou une application puis revenez, et même après un rechargement. Chaque mode de regroupement garde son propre pliage. Une recherche affiche tous ses résultats, y compris dans un groupe replié, et le pliage revient quand vous effacez la recherche.

Un bouton retour qui sait d’où vous venez

La flèche de retour d’un serveur, d’une application ou d’un groupe vous ramène désormais à la page d’où vous êtes arrivé : la boîte de réception, le catalogue, l’équipe d’un serveur… Elle ne remonte pas onglet par onglet, et le bouton dit où il vous emmène. Si vous êtes arrivé par un lien direct, il vous ramène au catalogue ou à la liste des groupes.

Les accès en double sont signalés

Quand une personne a un accès sur un serveur ou une application et le même accès par un groupe, l’onglet Équipe le signale : « En double avec le groupe », avec un bouton pour retirer le doublon sans rien changer à ses droits. L’onglet Accès du groupe signale aussi les accès accordés sur ses cibles que le groupe couvre déjà.

Le nombre d’anomalies correspond à la boîte de réception

Le badge d’une cible, le catalogue, la vue d’ensemble et l’application mobile comptent désormais les anomalies comme la boîte de réception les affiche : sept plantages d’un même type forment une seule anomalie, « 7 occurrences ». Le badge d’une cible le dit en toutes lettres : « 2 anomalies · 6 occurrences ».

Vous voyez qui a accès, et d’où lui vient ce droit

L’onglet Équipe d’un serveur ou d’une application montre chaque personne avec son rôle et l’origine de son accès : accordé sur la cible, ou venu d’un groupe. Un accès de groupe se gère dans le groupe, en un clic depuis la cible. L’onglet Accès d’un groupe montre à combien de cibles il s’applique, ce qui descend des groupes parents et les accès accordés cible par cible. Ces écrans pouvaient aussi s’afficher vides alors que des accès existaient : c’est corrigé.

Une partition /home séparée est enfin mesurée

Sur une machine dont /home est sur sa propre partition, l’agent affichait 0 % d’occupation, quel que soit le remplissage réel. L’agent 1.3.6 mesure tous les disques comme la commande df. Mettez-le à jour avec sudo apt update && sudo apt install stathall-agent.

Un disque à 90 % n’est plus une urgence

Un disque rempli à 90 % ouvre une alerte à traiter dans la journée, plus une alerte « Agir maintenant » : celle-ci arrive à 95 %. Quand un disque se remplit vite, c’est la prévision de remplissage qui vous prévient à temps.

Les alertes d’application retrouvent leur réglage

Quatre règles installées par défaut dérèglaient la détection des applications : une hausse des plantages pouvait passer inaperçue, et une baisse passagère de la note déclenchait trop facilement une alerte. Elles sont désactivées : chaque type d’alerte suit de nouveau son propre réglage.

L’écran Règles explique ce qui s’applique

Sans règle active, ce sont les seuils calibrés de StatHall qui s’appliquent. Les règles restent disponibles comme modèles, à ajuster et prévisualiser avant de les activer. Une règle que vous aviez modifiée reste telle quelle.

Le profil « Runner CI » a le dernier mot

Une règle d’alerte définie pour tous les serveurs pouvait encore réveiller le processeur d’une machine marquée « Runner CI ». Le profil passe désormais avant ce genre de règle générale. Une règle que vous avez écrite pour cette machine ou pour son groupe, elle, continue de s’appliquer.

Un runner ne réveille plus personne à chaque build

Une règle par défaut ajoutait une alerte processeur à 85 % sur tous les serveurs, y compris ceux qui portent le profil « Runner CI » : une machine d’intégration continue continuait d’alerter pendant ses builds. Cette règle est désactivée ; les seuils habituels du processeur s’appliquent, et le profil les coupe comme promis.

Des règles par défaut qui s’appliquent vraiment

Une règle mémoire « moins de 200 Mo » s’affichait sans jamais rien surveiller : elle est désactivée, le seuil mémoire standard couvre ce cas. Une règle que vous aviez modifiée reste telle quelle. Le bouton « Réinjecter les règles par défaut » de l’écran Règles fonctionne de nouveau.

Quoi, et combien

Une alerte disait « Métrique système élevée ». Elle dit maintenant « Disque / : seuil dépassé », et montre le disque rempli à 90,6 % sur une jauge où le seuil de 90 % est marqué. Toutes les alertes suivent : un certificat affiche ses jours restants, une saturation prévue son échéance (« Plein dans 38 h »), une rafale d’erreurs son compte face à l’habitude, un service en échec son nom. Chaque alerte a l’icône de ce qu’elle touche, dans la liste comme dans le détail, sur le cockpit comme sur le téléphone.

Des pistes qui parlent de la bonne ressource

Sur un disque plein, les commandes proposées étaient celles du processeur. Chaque ressource a désormais les siennes : ce qui prend la place sur ce disque-là, la mémoire réellement disponible, les processus tués faute de mémoire. La prochaine étape s’affiche juste sous l’explication.

Les machines d’intégration continue

Un runner sature son processeur à chaque job. Cochez Runner CI dans l’onglet Alertes du serveur : les alertes processeur et charge se taisent, le reste reste surveillé. Le cockpit vous le propose quand il voit GitLab Runner tourner. Et les conteneurs éphémères des jobs ne déclenchent plus d’alerte, nulle part.

Les liens ouvrent l’application, même installée hors Play Store

Un lien StatHall reçu par e-mail ouvre l’application Android quand elle est installée. C’était vrai pour la version du Play Store, pas pour l’APK installé directement : Android ne le reconnaissait pas et le lien partait dans le navigateur. Les deux sont maintenant reconnus.

Le bon serveur, pas tout le parc

Sur la fiche d’un serveur, le badge « 10 anomalies » ouvrait la boîte de réception sur les anomalies de tous vos serveurs. Il mène maintenant aux anomalies ouvertes de ce serveur-là, toutes dates confondues : exactement ce que le badge compte.

Type, groupe, cible

La boîte de réception se filtre par type (applications ou serveurs), par groupe — sous-groupes compris — et par cible. La liste des cibles suit le choix : sous « Serveurs », on ne vous propose pas une application. Tout tient dans l’adresse de la page : une vue filtrée se partage et s’épingle.

Sur le téléphone, la même chose dans la feuille de choix, en haut de la boîte de réception.

Changer de compte sur son téléphone

Se connecter à un second compte sur un téléphone déjà inscrit sous un autre provoquait une erreur à chaque connexion — et le premier compte continuait de recevoir ses alertes sur ce téléphone. Le téléphone suit maintenant le compte connecté, et seulement lui.

Un quota, une fonction, un projet partagé

Une application ne tombe pas que par son code. Elle tombe parce que le quota d’envoi de courriels est épuisé — et c’est la réinitialisation de mot de passe qui ne part pas. Parce qu’une fonction serveur n’est plus déployée. Parce que le projet Supabase que deux de vos cibles partagent s’est mis en pause.

Trois signaux qui n’existaient pas dans le cockpit, et qui y sont maintenant.

Brevo : le mur qui approche

Le nouveau connecteur lit les crédits d’envoi qu’il vous reste, une fois par heure, et prévient deux fois : sous 100 crédits, puis sous 25. Un seul seuil obligerait à choisir entre alerter trop tôt et alerter quand c’est déjà tombé. Quand les crédits repartent, l’alerte se referme d’elle-même.

Supabase : vos fonctions, et leurs erreurs

Le connecteur surveille désormais chaque Edge Function — une fonction en erreur casse un parcours entier sans que la santé du projet ne bouge d’un pouce — et compte les réponses en erreur de l’heure écoulée. Aucun contenu de journal ne quitte votre projet : StatHall ne ramène qu’un nombre.

Un service, plusieurs cibles

Votre application et son back-office vivent sur le même projet Supabase ? Vous le configurez une fois, et vous le partagez. Le jeton reste à un seul endroit, la collecte ne tourne qu’une fois, et l’alerte s’ouvre des deux côtés — parce que c’est sur sa propre fiche que chacun doit lire « le backend est en pause ». Le partage ne donne aucun droit : il montre l’état du service commun, rien d’autre.

Côté application mobile

Une panne du serveur n’est plus comptée comme un plantage de l’application. Ces erreurs-là étaient déjà traitées à l’écran par un bandeau et un réessai ; les compter en crash faussait le taux de sessions sans crash, c’est-à-dire la mesure sur laquelle on décide de publier une version.

Le cockpit relie les alertes entre elles

Un disque qui se remplit rend un conteneur malade, qui fait échouer une sonde, qui remplit les journaux d’erreurs. Jusqu’ici, ça faisait quatre alertes affichées côte à côte, et c’était à vous de retrouver dans quel ordre elles étaient arrivées.

StatHall le fait désormais. Le nouvel écran Incidents regroupe ce qui appartient à une même histoire, désigne le fait qui a probablement tout déclenché, et vous dit ce que vaut cette désignation : racine probable, plausible, ou à arbitrer quand plusieurs départs sont possibles.

« Ce plantage, c’est qui ? »

Un crash ne frappe presque jamais tout le monde. Le cockpit lit maintenant la répartition par version d’OS, modèle d’appareil et version de l’application, et la compare à ce que pèse réellement chaque valeur. Le tableau affiche l’écart en toutes lettres — « six fois plus » — et dit toujours à quoi il compare : aux sessions mesurées, ou aux autres plantages de la même cible.

Un plancher d’effectif s’applique : deux événements sur un modèle rare ne suffisent pas à affirmer quoi que ce soit.

D’une cible à l’autre

Quand une application dépend d’un serveur — vous l’avez déclaré dans ses liens — un symptôme applicatif et une anomalie du serveur qui se recouvrent dans le temps sont rapprochés. Le symptôme est dans l’app, la cause est en face : c’est le lien que rien ne portait jusqu’ici.

Votre avis compte, et il est gardé

Confirmez la racine, infirmez-la, détachez un fait qui n’a rien à y faire. Le calcul tourne toutes les vingt minutes ; il met à jour la preuve et jamais votre décision.

Sur la liste d’alertes, la case Racines seulement masque ce qu’un incident explique déjà — et laisse tout ce qu’il n’explique pas.

L’écran existe sur le cockpit et sur le téléphone : c’est en astreinte, à 2 h du matin, que la question « laquelle a commencé ? » se pose le plus.

Dix semaines de crashes, aucune alerte

Une application suivie par le cockpit est passée de 89 % à 58 % de sessions sans crash du jour au lendemain, et y est restée dix semaines, sur quatre versions. Pendant ce temps, StatHall a ingéré 78 millions d’événements pour cette application — et n’a ouvert aucune alerte technique. Les seules alertes émises parlaient de la note du store.

La raison tient en une phrase : le cockpit surveillait le taux de plantage publié par le store, pas celui mesuré par Sentry. Sur une application présente sur les deux plateformes, ce chiffre-là ne couvre qu’Android, et affichait 99 % pendant que la mesure réelle était à 58 %.

Le taux de plantage se lit maintenant par version

Le cockpit récupère désormais la mesure de Sentry telle qu’elle est produite : jour par jour, et version par version. C’est la dimension qui manquait, parce que c’est celle sur laquelle on agit — on corrige une version, on retire une version.

Une dégradation qui dure déclenche une alerte

Jusqu’ici, la détection cherchait des pics : un écart soudain par rapport aux jours précédents. Une dégradation qui s’installe n’en produit aucun — au bout de deux semaines, elle est devenue la normale.

Une nouvelle règle surveille le niveau : sous 95 % de sessions sans crash en moyenne sur sept jours, l’alerte reste ouverte tant que ça dure, en P0, et nomme la version concernée. Elle ne se déclenche que pour les versions qui pèsent réellement dans le parc : une vieille version utilisée par une poignée d’appareils n’ouvre pas d’alerte.

Les alertes sur les avis ne crient plus au loup

Une note qui baisse pouvait ouvrir une alerte P0 — la gravité la plus haute — sur la moyenne d’une seule journée d’avis. Trois changements :

• elle plafonne à P1 : une note de store se joue sur l’acquisition, pas sur le service rendu ;
• une journée de moins de cinq avis n’est plus une mesure ;
• seuls les avis qui parlent de l’application comptent. Sur une application de commerce, les avis sur le stock, la livraison ou le service client sont écartés : une équipe technique ne peut rien en faire.

Une version sans mesure n’est plus déclarée « saine »

Quand aucune donnée de plantage n’est disponible pour une version, sa fiche affiche indéterminé au lieu de « sain ». Le cockpit ne dit plus ce qu’il n’a pas vérifié.

Les règles de détection affichées s’appliquent vraiment

L’écran des règles listait des seuils qui n’étaient jamais appliqués : un seuil écrit « 95 % » n’était pas lisible par le moteur, et cinq règles nommaient des détecteurs qui n’existaient pas. Les règles portent désormais une valeur exécutable, l’écran indique ce qui est réellement appliqué — ou signale qu’un seuil ne l’est pas — et un type inconnu est refusé à l’enregistrement.

Une alerte réglée ne se lit plus comme un incident en cours

Une alerte « Mises à jour de sécurité en attente » ouverte à minuit, réglée par la machine à 6 h 55 quand elle a appliqué le correctif toute seule — et relue à 21 h 40 comme si elle était encore ouverte, gravité et urgence comprises.

La fiche dit maintenant son état : réglée ou non, depuis combien de temps, et par quoi (« correctifs appliqués », « service reparti »…). La durée d’ouverture se fige à la clôture au lieu de grandir toute seule.

Les chiffres joints à une alerte viennent du bon moment

Sous le titre « Autres séries au même moment », le cockpit affichait les mesures de maintenant, même sur une alerte de la veille. On y lisait un swap à 99,88 % à côté d’un paquet mesuré 21 heures plus tôt, et on cherchait un lien qui n’existait pas.

Ces séries sont désormais cherchées autour de l’instant de la mesure, avec leur horodatage à l’heure de la machine. Quand elles n’en viennent pas, l’écart est écrit noir sur blanc.

Le correctif de cette nuit ne réveille plus personne

Une machine qui applique ses correctifs de sécurité toute seule a droit à sa nuit. Une alerte n’est plus ouverte pour un correctif publié il y a quelques heures : ce qui compte est l’âge du plus ancien correctif non appliqué, pas le nombre de paquets. Et les passages réussis du patching automatique ne sont plus comptés comme des récidives — trois succès d’affilée s’affichaient jusqu’ici comme « déjà survenue 3 fois ce mois-ci ».

Le lien d’une notification retombe sur son alerte

Cliquer une notification ouvrait l’écran de la machine, sans rien y désigner. Si l’alerte s’était refermée entre-temps, plus rien ne permettait de la retrouver. Le lien ouvre désormais l’alerte elle-même, close ou non. Les alertes qui s’éteignent d’elles-mêmes sont annoncées comme telles, au lieu de laisser une notification sans suite.

Le téléphone montre la même chose que le cockpit

Même compte, deux écrans, deux vérités : la boîte de réception du téléphone ignorait les alertes prises en compte et celles réglées dans les dernières 24 heures. Elle affiche maintenant le même périmètre que le cockpit, avec un badge « Réglée » sur ce qui est déjà derrière vous.

Moins de bruit dans les journaux, et un compteur de failles honnête

Un paquet bloqué par le pare-feu et une requête refusée par un serveur web sont des défenses qui fonctionnent : elles ne comptent plus comme des erreurs dans les extraits joints à une alerte — elles y occupaient neuf lignes sur dix.

Quant à l’écran Sécurité, il affichait « 945 failles ouvertes » sur une machine à jour. Il s’agissait d’avis que l’éditeur de la distribution a examinés et décidé de ne pas corriger — toute machine Debian en porte un millier. Le compteur montre ce qu’il reste à traiter ; le reste est dit, à sa place.

Le scroll descend enfin jusqu’en bas

Sur le téléphone, le dernier élément d’une liste se cachait sous la barre d’onglets. Pas toujours : selon l’écran, selon le modèle d’iPhone, selon l’orientation. Assez souvent pour qu’un bouton « Réessayer » soit hors d’atteinte quand une liste échouait à charger.

La barre est translucide et le contenu passe dessous — c’est voulu, on doit deviner ce qui défile derrière le verre. En contrepartie, chaque liste doit dégager la hauteur qu’on lui prend. Elle la mesure désormais, au lieu de la supposer : la valeur suit la barre, qu’un iPhone lui ajoute son trait d’accueil, qu’une modale n’en ait pas, ou qu’un Android n’ait rien du tout.

Le cockpit ne vous déconnecte plus en plein travail

Une session durait sept jours à partir de la connexion, puis s’arrêtait — au milieu d’une phrase, sans prévenir. Elle se prolonge maintenant toute seule tant que vous l’utilisez, dans la limite d’un mois. Au-delà, il faut se reconnecter : une session ne doit pas vivre éternellement.

L’application ne redemande plus vos identifiants sans raison

Elle travaille aussi en arrière-plan, pour rafraîchir votre boîte de réception avant que vous n’ouvriez l’écran. Ce travail de fond et l’application visible pouvaient renouveler leur accès à la même seconde — et le serveur, qui protège contre le vol de jeton, prenait cette coïncidence pour une attaque. Il sait maintenant faire la différence entre deux mains sur la même porte et une effraction.

Vous saurez toujours ce que l’IA a écrit

L’IA est une force de StatHall, et elle était invisible : une synthèse rédigée par un modèle et un chiffre calculé se ressemblaient. Chaque texte issu d’une IA porte maintenant sa marque, et dit d’où il tire sa matière.

Trois marques distinctes, parce qu’une seule mentirait. IA quand un modèle a écrit le texte. Recherche IA quand la machine comprend votre question sans rien rédiger. Pour votre IA sur le texte que vous copiez vers l’assistant de votre choix. Et aucune marque là où il n’y a pas d’IA — le bloc « Comprendre et agir » d’une alerte est écrit à la main, une fois pour toutes, et le restera.

Quand l’assistant ne peut pas rédiger — fournisseur indisponible, budget mensuel atteint — il vous rend les passages de la documentation tels quels, et il le dit. Pas de marque « IA » sur du texte que personne n’a généré.

La documentation répond dans ⌘K

La recherche rapide cherchait mot pour mot dans vos cibles. Taper « ANR » ne donnait rien si aucune application ne s’appelait ainsi. Elle interroge désormais aussi la documentation, par le sens : la même question trouve l’article sur la stabilité, et « demander à l’assistant » n’est plus qu’à une touche.

Vos données, elles, ne bougent pas : seule la documentation publique est indexée de cette façon. Vos cibles et vos alertes gardent leur recherche instantanée, sur votre machine.

Comprendre une alerte sans ouvrir son ordinateur

Une notification arrive à deux heures du matin : container_unhealthy. L’application savait la montrer, l’acquitter, la reporter, la résoudre. Elle ne savait pas dire ce que ça veut dire.

Le bloc « Comprendre et agir » du cockpit arrive sur le téléphone, entier : ce que l’alerte signifie, par où commencer, les faits mesurés, les pistes de diagnostic avec la commande de lecture qui les vérifie — et le texte complet à coller dans l’assistant de votre choix, avec le contexte de la machine et les journaux récents que l’on oublie toujours en recopiant à la main.

Les commandes proposées ne font que lire. StatHall observe ; il n’exécute rien sur vos machines, et l’application ne fait que vous laisser les copier.

Laisser un mot depuis le terrain

Acquitter une alerte sans rien écrire laissait l’équipe devant un incident « pris en charge » sans savoir par qui ni pourquoi. Les notes existent maintenant dans l’application : « je regarde, c’est la sauvegarde de 3 h qui tourne » s’écrit depuis le quai de la gare et se lit depuis le bureau, dans la même fiche d’anomalie. Chacun ne peut supprimer que les siennes.

Choisir ce que les listes montrent

Le cockpit sépare depuis plusieurs versions « ce que je possède », « ce qu’on m’a partagé », « tout », les démonstrations et le parc entier. Le téléphone, lui, mélangeait tout. Le périmètre de cibles est désormais dans l’application, sur la boîte de réception et sur la liste des cibles.

Un périmètre reste ce qu’il a toujours été : un filtre d’affichage. Il ne donne aucun droit et n’en retire aucun, et les choix proposés sont ceux que le serveur annonce — pas une déduction faite sur le téléphone.

Une alerte réglée dit enfin ce qui l’a réglée

La boîte de réception garde depuis la version précédente ce qui s’est réglé tout seul dans les dernières vingt-quatre heures. L’application montrait bien ces lignes, mais pas la raison : « mises à jour appliquées », « conteneur rétabli », « minuterie repassée ». Elle la montre maintenant, comme le cockpit.

Et en anglais

Les explications d’alerte venaient du catalogue des types de la supervision, qui n’existait qu’en français : un cockpit en anglais affichait des phrases françaises. Les deux langues y sont désormais, et c’est le lecteur qui décide — sur le web comme sur le téléphone.

Une alerte réglée pendant la nuit ne disparaît plus

Cette nuit à 3 h 30, une alerte « mises à jour de sécurité en attente » est partie par courriel. À 6 h 08, le serveur a appliqué les paquets tout seul ; l’alerte s’est refermée deux minutes plus tard. À 9 h, la boîte de réception ne montrait plus rien : le message renvoyait vers une alerte introuvable, et rien ne disait qu’elle avait été traitée.

La boîte de réception montre désormais, par défaut, ce qui demande une action et ce qui s’est réglé dans les dernières vingt-quatre heures. Les lignes réglées portent une pastille « Réglée » et disent ce qui a réglé l’incident — « mises à jour appliquées », « conteneur rétabli », « retour à la normale ». Un incident terminé n’a pas d’urgence : la pastille rouge laisse la place. Le filtre « Ouvertes » reste à un clic pour qui veut la seule liste des actions à faire.

Un swap plein n’est pas une saturation

Une alerte signalait qu’un serveur avait rempli son espace d’échange. Elle est restée ouverte trente-huit heures sans rien apprendre à personne : la machine avait nul échange en cours, aucune pression mémoire, et près de dix gigaoctets de RAM disponibles. Elle ne pouvait pas se refermer — cet espace ne se vide pas tout seul.

Cette alerte ne se déclenche plus d’elle-même. Ce qui fait mal est le débit d’échange, qui garde ses seuils et qui a d’ailleurs parlé, lui, les jours où la machine a réellement souffert. La mesure reste visible dans les graphiques, et s’active à la demande dans la configuration d’un serveur.

Moins de bruit sur les machines d’intégration continue

Un serveur de compilation journalise en erreur le fait qu’une couche d’image est déjà en cours d’écriture — puis réessaie et réussit. Une seule construction en produit des dizaines par minute, ce qui ouvrait une alerte à chaque fois : sept en six jours, sans la moindre panne. Ces lignes rejoignent le bruit connu, écarté du calcul des rafales d’erreurs mais toujours visible dans les journaux.

Un incident, une alerte

Un conteneur qui plante au démarrage redémarre en boucle — et, entre deux plantages, il est « en marche » une poignée de secondes. StatHall prenait cet instant pour un rétablissement : il fermait l’alerte, la rouvrait à la relance suivante, et recommençait. Pour une seule panne d’une nuit, cela faisait cinquante-quatre alertes, autant d’e-mails, et une boîte de réception vide quand on venait enfin regarder — l’alerte du message venait d’être refermée.

Désormais, tant que le compteur de redémarrages monte, l’incident reste ouvert. Le rétablissement se constate sur la durée : le conteneur doit tourner, sainement, pendant dix minutes. Un service dont le contrôle de santé repasse au vert sans avoir redémarré, lui, referme son alerte tout de suite, comme avant.

Une défense qui fonctionne n’est pas une panne

Les robots qui cherchent /.env ou /.git sur un site public sont repoussés par la configuration du serveur web — qui écrit une ligne d’erreur à chaque refus. StatHall comptait ces lignes comme des erreurs d’application et ouvrait une alerte : quatorze en quatre jours sur un site parfaitement en ligne.

Ces refus délibérés ne comptent plus dans les rafales d’erreurs. Ils restent consultables dans les journaux, comptent toujours comme volume — un déluge de scans reste un déluge —, et l’alerte indique combien de lignes ont été écartées : un filtre muet finit par être accusé d’avoir menti.

Changer de compte n’expose plus le précédent

Le cockpit vidait ses données au moment de la déconnexion — le seul moment qui n’est pas garanti. Une session expirée, un onglet fermé, une connexion perdue, et le compte suivant retrouvait à l’écran les cibles, les favoris et l’historique du précédent, jusqu’à ce qu’on rafraîchisse à la main.

Le nettoyage a désormais lieu des deux côtés : quand une session se termine, et quand une autre s’ouvre pour quelqu’un d’autre. Le thème, la langue et la disposition restent — ce sont vos préférences d’appareil, pas des données de compte.

Le détail reprend la place

Dans la boîte de réception, la liste et le détail se partageaient l’écran à l’envers : la liste, qui ne porte qu’un titre et une date, occupait les trois quarts ; le détail — ce que la mesure veut dire, les faits, les pistes de diagnostic et leurs commandes — tenait dans une colonne étroite où les libellés chevauchaient les valeurs.

Les proportions sont inversées. Le panneau de détail défile désormais sur lui-même, et les trois gestes — acquitter, reporter, résoudre — sont à hauteur du titre plutôt qu’au bas d’une longue page.

Des faits écrits pour être lus

Le bloc « Comprendre et agir » affichait encore des restes de la base : un dictionnaire entre accolades pour un seuil, un horodatage complet en notation technique, des drapeaux internes au moteur. Il dit maintenant « Seuil : P2 ≥ 90 », « Dernier signe de vie : 07/09/2026 21:52 », énumère les paquets concernés et traduit les états. Ce qui n’apprend rien à un lecteur — les paramètres du calcul statistique — a disparu.

Aide

Le dialogue des raccourcis clavier s’ouvrait derrière le panneau d’aide. L’attente de l’assistant, elle, ne se voyait pas : elle occupe désormais la place de la réponse. Et le champ de recherche attend une fraction de seconde avant de chercher, au lieu d’interroger le moteur à chaque touche.

Plus besoin de toucher au serveur

La clé qui fait fonctionner l’assistant de documentation se pose désormais dans Administration → Système, avec son fournisseur, son modèle et son plafond mensuel. Jusqu’ici, il fallait un accès au serveur, un éditeur de fichiers et un redéploiement — pour une valeur qui se change en dix secondes.

Une fois enregistrée, la clé n’est plus réaffichée : l’écran n’en montre que les quatre derniers caractères, de quoi la reconnaître sans la lire. Elle est stockée chiffrée, comme les identifiants de vos connecteurs.

Réservé aux administrateurs de l’instance. Chaque modification est tracée dans le journal d’audit — la clé concernée, jamais sa valeur.

Pour qui héberge StatHall soi-même, la configuration par variables d’environnement continue de fonctionner : elle sert de valeur par défaut quand rien n’est posé dans le cockpit.

Un seul point d’interrogation

Il y en avait deux, côte à côte, pour deux choses différentes : l’aide et les raccourcis clavier. Il n’en reste qu’un, en bas à droite — là où on cherche l’aide. Les raccourcis sont une entrée du panneau, et la touche ? les ouvre toujours.

L’assistant en premier, pas au troisième onglet

Le panneau s’ouvre maintenant sur le champ de question, curseur dedans, avec trois questions proposées. L’article de l’écran où vous êtes et le reste de la documentation suivent, pour qui préfère lire. Le même champ filtre les articles pendant que vous écrivez et interroge l’assistant quand vous validez.

Des réponses qui ne s’arrêtent plus à mi-chemin

À « comment ajouter une cible », l’assistant répondait pour une application et se taisait sur les serveurs Unix — alors qu’il avait trouvé le passage. Il rend désormais les trois extraits les plus pertinents, chacun court.

Au passage : l’attente est nommée au lieu d’afficher une liste vide, et les barres de défilement ne tranchent plus sur le fond sombre.

Superviser un backend qui ne tourne sur aucune de vos machines

StatHall sait désormais surveiller Supabase et Cloudflare, à côté de vos applications et de vos serveurs.

L’alerte qui manquait le plus : un projet Supabase du palier gratuit se met en pause après une période sans trafic. L’application qui vit dessus tombe, et jusqu’ici rien ne vous le disait. C’est désormais une alerte de niveau P1. S’y ajoutent la santé service par service (base, authentification, API, stockage, temps réel), l’état du dernier déploiement Cloudflare Pages, le trafic d’une zone, et la validité du jeton lui-même — un jeton expiré arrête la collecte en silence.

Ces deux connecteurs s’installent aussi bien sur une application que sur un serveur. C’est nouveau : jusqu’à cette version, une cible serveur ne pouvait porter aucun connecteur.

Une documentation en ligne, et une aide dans le cockpit

La documentation vit maintenant sur le site, à l’adresse stathall.com/docs : créer une cible, installer l’agent, brancher chaque connecteur, choisir et configurer une IA, recevoir les bonnes alertes.

Dans le cockpit, un bouton ? ouvre l’aide de l’écran où vous êtes. Le même panneau permet de chercher dans toute la documentation, et de poser une question en français : « comment créer une cible ? », « où trouver mon jeton Sentry ? ». Les réponses citent leurs sources, et l’assistant dit quand il ne sait pas plutôt que d’inventer. Il ne consulte aucune de vos données — il ne lit que la documentation.

Configurer une cible, sans le labyrinthe

L’écran de configuration empilait deux barres de navigation, répétait le nom de la cible et proposait un retour vers la page où vous étiez déjà. La configuration est maintenant un onglet de la cible, avec ses réglages rangés en sections nommées : la cible, les données, l’intelligence artificielle, les accès, et ce qui est irréversible.

Depuis l’application mobile

L’application reste volontairement concise. Elle sait désormais passer la main : depuis une cible, un lien ouvre le cockpit sur la même page, et la fiche d’un serveur nomme ce que le cockpit montre en plus — failles et correctifs, journaux filtrables, configuration.

Au passage, un défaut corrigé pour celles et ceux qui hébergent StatHall eux-mêmes : les liens vers le cockpit et les pages légales étaient refusés sans un mot. Ils fonctionnent.

Corrigé

• Un cœur occupé ne déclenche plus d’alerte. Nous recevions quatre alertes « CPU à 92 % » pour un seul événement, sur une machine qui n’était pas en peine : elles portaient chacune sur un cœur d’un serveur qui en a seize. Un cœur saturé, c’est une tâche qui travaille — une compilation, une sauvegarde — pas un incident. StatHall regarde désormais la machine, et garde les cœurs pour les graphiques.
• Un pic d’une minute ne réveille plus personne. Un seul relevé au-dessus du seuil ouvrait une alerte qui vivait un quart d’heure. Il faut maintenant que le dépassement tienne quelques minutes — sauf pour un défaut de disque, qui alerte immédiatement.
• L’alerte dit enfin si c’est ponctuel ou continu. Chaque e-mail précise combien de temps le seuil a été franchi sur la fenêtre observée, et le nombre de cœurs de la machine.
• Application mobile : le bas des listes n’est plus caché par la barre d’onglets, et une anomalie reportée se retrouve — il manquait les filtres « Reportée » et « Résolue ».

Nouveau

• « Comprendre et agir », sur chaque anomalie. L’écran explique ce que l’alerte veut dire, propose des pistes de diagnostic avec la commande de lecture qui les vérifie, et fournit un prompt prêt à copier pour l’assistant IA de votre choix — avec tout le contexte dedans : la machine, les mesures, la durée du dépassement, les journaux récents. Ces journaux sont expurgés avant d’être joints : aucun identifiant ne part avec.

StatHall observe, il n’administre pas : les commandes proposées sont des lectures, à lancer vous-même. Rien n’est jamais exécuté à distance.

Nouveau

• Un seul menu, libellé. Le rail d’icônes, le menu d’administration et le menu mobile n’en font plus qu’un : une barre latérale repliable, avec des mots plutôt que des pictogrammes à deviner. L’administration y est une section comme une autre, marquée d’un liseré violet.
• Vous pouvez créer vos propres cibles. Ajouter une application ou mettre une machine sous supervision ne demande plus un compte administrateur. Un plafond de fair-use s’applique, affiché clairement, et l’écran vous dit où vous en êtes — au lieu de griser un bouton sans explication. Un compte tout neuf n’est plus enfermé dans un cul-de-sac : il commence par créer sa première cible.
• Vos clés IA, toutes au même endroit. Un écran « Paramètres → Intelligence artificielle » montre quelles cibles sont couvertes, par quel fournisseur, avec quel usage du mois — et permet d’appliquer une clé à plusieurs cibles d’un coup. Le réglage fin reste dans chaque cible.
• Un filtre « Périmètre », au pied du menu. Propriétaire, Équipe, Tout — et, pour l’administration, Démo et Instance. Il remplace un filtre réservé aux administrateurs qui triait les cibles selon le rôle de leur propriétaire : une machine qu’on vous avait partagée pouvait n’apparaître nulle part. Par défaut, vous voyez ce qui vous appartient et ce qu’on vous a partagé, et quand un écran est vide, il vous dit lequel des filtres le vide.
• Un plan du site. Il liste tous les écrans, y compris ceux que vos droits masquent — avec la raison. Une fonction absente ne se lit plus « elle a disparu ».
• Des écrans qui manquaient : historique des déploiements, statut de licence, tâches de rattrapage, file des tâches en échec, création de compte, changement de mot de passe sans passer par « mot de passe oublié », et réglage des notifications push sans avoir installé l’application mobile.

Modifié

• Le compte devient « Paramètres », éclaté en huit écrans au lieu d’une longue page : profil, sécurité, notifications, IA, confidentialité, cibles, groupes, offre. Trois écrans qui n’étaient accessibles qu’en connaissant leur adresse (offre, consommation, code d’accès) y ont désormais une place.
• Le plafond de fair-use passe de 3 à 10 cibles, et disparaît sur une installation auto-hébergée. Trois, c’était l’héritage d’une grille tarifaire supprimée depuis : un mini-serveur, un VPS et deux applications en font déjà quatre. Quand vous hébergez StatHall chez vous, plus aucun plafond ne s’applique — c’est votre matériel.
• Un compte sans cible garde son menu. Il était jusqu’ici enfermé sur quatre pages. Il atterrit toujours sur un écran d’accueil qui propose de créer sa première cible, mais tout le reste lui reste ouvert.
• Chaque écran a une adresse et une seule. Quatre pages existaient en double. Vos favoris enregistrés sur les anciennes adresses continuent de fonctionner.
• La recherche ⌘K s’ouvre par-dessus la page au lieu d’occuper la barre du haut, et connaît désormais tous les écrans, pas six raccourcis figés.
• Les adresses de vos pages de travail — boîte de réception, vue d’ensemble, activité, synthèse IA, pages d’une cible — n’ont pas changé.

Corrigé

• Enregistrer une clé IA échouait dans certaines configurations.
• La page des règles d’alerte s’affichait pour tout le monde alors que seule l’administration peut les modifier.
• Se déconnecter depuis l’écran d’activation de la double authentification menait à une page introuvable.
• Un compte créé depuis l’administration ne pouvait pas se connecter. Il lui était demandé une vérification d’adresse e-mail qui n’avait jamais été envoyée. Un compte créé par un administrateur, avec son mot de passe, est désormais valable tout de suite.
• La vue d’ensemble ignorait le filtre de périmètre : sa grille se vidait pendant que les compteurs du haut continuaient de compter tout le parc.
• Les règles de surveillance d’un serveur sont vérifiées à la saisie. Un nom de tâche mal orthographié ou un seuil incohérent désactivait silencieusement une alerte : c’est maintenant refusé, avec le motif.

Corrigé

• Être co-propriétaire d’un groupe ne donnait pas accès à ses serveurs. Le groupe apparaissait bien dans la liste, mais son contenu restait vide : ni dans le catalogue, ni dans le filtre par groupe. Le partage portait sur le classement et s’arrêtait là, alors que c’est précisément le contenu qu’on cherche à partager. Un accès accordé sur un groupe ouvre désormais ses cibles membres, et se propage aux sous-groupes tant que l’héritage y est activé. Un accès en lecture reste en lecture ; seule une co-propriété autorise la modification. La propriété d’une cible, elle, ne se transmet jamais par un groupe : la supprimer ou la transférer reste réservé à son propriétaire.
• On ne voyait pas avec qui un groupe était partagé. La liste affichait des numéros (« #1 », « #6 ») au lieu des adresses, et le menu pour accorder un accès restait vide : il s’appuyait sur l’annuaire complet des comptes, réservé aux administrateurs. Les adresses s’affichent maintenant pour tout le monde, et le menu propose les personnes avec qui vous travaillez déjà — sans jamais exposer l’annuaire.
• Un co-propriétaire de groupe ne pouvait rien en faire. Il voyait le groupe, sans pouvoir le renommer, y ranger une cible, ni voir avec qui il est partagé. La co-propriété donne maintenant ces gestes ; supprimer le groupe reste réservé à son propriétaire.
• Ranger une cible dans un groupe demande désormais d’avoir le droit de la gérer. Un simple droit de lecture ne permet plus de la partager par ce biais.
• Le partage automatique d’un nouveau groupe se fait en lecture. Créer un groupe le partage toujours avec les co-propriétaires de vos cibles, mais en lecture seule : à vous de promouvoir qui doit pouvoir le modifier.
• Le filtre d’administration ne cache plus vos propres cibles. Le périmètre « Équipe » ne montrait que les cibles appartenant à un compte administrateur : une machine que vous co-possédez personnellement en sortait, et disparaissait du catalogue, de la vue d’ensemble et de son groupe. Un filtre d’administration ne retire désormais jamais ce à quoi vous avez un droit nominal. Et quand un écran est bien vidé par ce filtre, il le dit et propose de l’élargir en un clic.

Corrigé

• La création d’un groupe échouait en erreur pour tout compte non administrateur. L’écran répondait une erreur technique sans explication. La permission avait été ouverte côté application à la version précédente, mais la règle de cloisonnement de la base, elle, continuait de refuser l’enregistrement — un contrôle qui vérifiait l’existence de la ligne qu’on était justement en train de créer. Les administrateurs n’étaient pas touchés, ce qui a rendu le défaut invisible jusqu’à ce qu’un utilisateur essaie. Organiser ses cibles en groupes fonctionne maintenant pour tous, et personne ne peut pour autant créer un groupe au nom de quelqu’un d’autre ni le ranger sous l’arborescence d’un tiers.
• Le raccourci d’URL d’un groupe ne se remplissait qu’à la première lettre. Taper « Sebastien » ne proposait que s. Il suit maintenant la saisie, s’adapte aux accents (« Sébastien » donne sebastien), et reprend la main si on vide le champ après l’avoir modifié.

Ajouté

• Un groupe est désormais partagé avec les co-propriétaires de ses machines. Jusqu’ici un co-propriétaire voyait les machines mais pas les groupes qui les organisent : la co-propriété s’arrêtait à mi-chemin. Les personnes qui ont accès en lecture seule ne sont pas concernées — elles ont accès à une machine, pas au classement de son propriétaire.

Corrigé

• Un serveur d’intégration continue ne déclenche plus une alerte par tâche terminée. Chaque tâche de build tourne dans un conteneur jetable, créé pour l’occasion et détruit ensuite. StatHall traitait sa disparition comme la panne d’un service, donc ouvrait une alerte de gravité haute… qui ne pouvait jamais se refermer, le conteneur n’existant plus. Sur une machine de build, cela produisait une alerte de plus par jour, à vie. StatHall distingue désormais un service, censé rester en vie, d’un conteneur jetable qui a simplement fini son travail — et ne compte plus un arrêt demandé comme un incident.
• Une alerte dont le conteneur a disparu se referme. Y compris quand la disparition a eu lieu pendant que l’agent était arrêté : StatHall rapproche les alertes ouvertes de la liste réelle des conteneurs. Par prudence, il ne referme rien s’il n’a pas de liste fraîche — une machine muette ne doit pas voir ses incidents s’évaporer.

Ajouté

• Déclaration en lot des sondes de disponibilité. Les sondes vérifient, depuis l’extérieur, qu’un site répond bien le code attendu et dans combien de jours son certificat expire. Il fallait les créer une par une ; une seule commande les déclare toutes, sans toucher à celles qui existent déjà. Le code attendu est explicite par domaine : une sonde qui accepte « n’importe quelle réponse valide » laisserait passer une redirection inattendue ou une page d’erreur.

Corrigé

• Les compteurs d’une machine se remettent à jour tout seuls. Sur la fiche d’un serveur, les jauges (processeur, mémoire, disque, réseau) restaient figées sur les valeurs du moment où la page avait été ouverte : la mémoire disponible affichée pouvait dater de plusieurs heures. Elles suivent désormais le rythme des remontées de l’agent, une par minute. La date du dernier point est affichée au-dessus des jauges, en orange si elle vieillit.
• L’onglet « Sécurité » d’un serveur s’affiche en français (et en anglais). Il montrait ses identifiants techniques internes au lieu des libellés.
• Un serveur tout juste créé n’annonce plus « 0 faille ». Tant que l’inventaire logiciel n’est pas remonté, les compteurs affichent « — » : personne n’a encore regardé, ce n’est pas la même chose que « rien à signaler ».

Ajouté

• « Docker récupérable » dit enfin où. Un clic sur la tuile ouvre le détail : combien d’espace par famille (images, conteneurs, volumes, cache de build), la commande de nettoyage correspondante, et la liste des plus gros objets inutilisés avec leur taille. Le calcul lui-même était faux : il ne comptait que le cache de build et ignorait les images sans conteneur, les volumes orphelins et les conteneurs arrêtés — soit l’essentiel de ce qu’un nettoyage libère. La liste par objet demande l’agent 1.3.2.
• La mémoire indique le total. « 36,8 Gio disponibles sur 55,0 Gio » plutôt qu’une valeur seule, impossible à recouper avec le pourcentage affiché juste au-dessus.

Corrigé

• Le diagnostic IA d’un serveur, l’écran Notifications et l’onglet Sécurité étaient inutilisables. Les six tables ajoutées par la 2.8.0 étaient protégées par le cloisonnement multi-locataires de la base… mais sans la règle qui dit qui a le droit de voir quoi. Or une table protégée sans règle refuse tout : le diagnostic répondait en erreur sous un message « Diagnostic indisponible ». Aucune donnée n’a été exposée — le défaut ferme, il n’ouvre pas.
• La clé d’intelligence artificielle d’un serveur peut enfin être saisie depuis la console. L’onglet IA d’un serveur ne réglait que la fréquence d’analyse : il n’y avait aucun champ pour la clé, donc aucune analyse possible. La clé reste propre à chaque cible, pour qu’une application cliente ne paie jamais l’analyse d’un serveur.
• L’onglet Sécurité affichait son identifiant technique au lieu de son nom.

Ce qui change pour vous

• L’inventaire logiciel de vos machines remonte réellement. L’agent déclarait bien son inventaire de paquets… à une route qu’il n’appelait jamais, à cause d’un plafond dans sa négociation de version de protocole. L’onglet Sécurité restait donc vide, avec un agent actif, une télémétrie normale et aucun message d’erreur — le pire mode de panne : une fonctionnalité qui se croit livrée. Découvert en mettant trois machines réelles sous supervision.

Mettez à jour l’agent pour en bénéficier :

sudo apt update && sudo apt install stathall-agent

Ce qui change pour vous

• Vos alertes répondent aux quatre questions qu’on se pose vraiment. Qui est touché — « Serveur CMJ Test Systems », et non plus « cette app » pour une machine Unix. Quelle urgence — agir maintenant, dans la journée, ou planifier. Quel effort — correctif rapide, diagnostic à mener, ou dépendance à un tiers. Et est-ce nouveau — « déjà survenue 3 fois sur les 30 derniers jours, ouverte depuis 5 h ». Le tout avant la moindre valeur mesurée : les chiffres sont des preuves, pas le message.
• L’urgence n’est plus confondue avec la gravité. Une distribution en fin de support est critique et se règle par une migration planifiée ; un disque qui sature dans douze heures se règle tout de suite. Les deux sont désormais dits séparément, pour qu’une alerte critique ne réveille pas quand elle n’a pas à réveiller.
• Chaque type d’alerte explique ce que ça veut dire et quoi faire, en une phrase chacune. « Une tâche planifiée ne s’est plus exécutée depuis trop longtemps — typiquement une sauvegarde qui ne tourne plus », suivi de la commande de vérification. Les commandes sont affichées, jamais exécutées : StatHall surveille, il n’administre pas.
• L’objet de l’email suffit à trier sa boîte : [P0] vps-cmj · Disque bientôt plein — /mnt/data · Agir maintenant. Avant, tous les objets se ressemblaient, qu’il s’agisse d’un disque plein, d’un certificat expiré ou d’une sauvegarde morte.
• Le résumé groupé met en tête ce qui demande une action immédiate, marqué d’un éclair — un incident critique mais planifiable ne masque plus un incident majeur à traiter dans l’heure.
• Telegram va droit au but : quoi et où en première ligne, c’est tout ce qu’on lit sur un écran verrouillé.
• Mettre une machine sous supervision se fait maintenant en ligne de commande, avec ses règles de surveillance (fraîcheur des sauvegardes, seuils propres à la machine) posées du même geste — utile pour un parc, et pour l’auto-hébergement.

Corrigé

• L’instantané de santé quotidien échouait chaque nuit depuis sa mise en service, sans que rien ne le signale.

Ce qui change pour vous

• StatHall prévoit la saturation au lieu de la constater. Un disque, des inodes ou de la mémoire qui se remplissent régulièrement déclenchent une alerte avant d’être pleins, avec une échéance chiffrée (« plein dans environ 38 heures ») et de quoi juger la prévision. La méthode est robuste aux pics : un cache de build qui gonfle puis retombe ne déclenche rien.
• Une sauvegarde qui cesse de tourner est enfin détectée. Jusqu’ici, une tâche planifiée en échec alertait ; une tâche qui ne se déclenchait plus du tout — désactivée, horaire cassé, machine éteinte au créneau — passait inaperçue. C’est le scénario où l’on découvre le problème le jour où on a besoin de la sauvegarde.
• Vos alertes arrivent sur Telegram ou sur votre webhook. Un nouvel écran « Notifications » dans votre compte : vous y mettez votre jeton de bot ou votre URL, vous choisissez la portée (toutes mes cibles, tous mes serveurs, un groupe, une cible), la sévérité minimale, vos heures calmes — et une relance automatique si une alerte critique reste non acquittée. Un bouton « Tester » envoie un vrai message, tout de suite. Cela vaut pour toutes vos cibles, applications mobiles comprises.
• Un onglet Sécurité par serveur. Les failles connues de vos paquets installés, nommées, avec leur gravité et la version qui les corrige ; les mises à jour en attente ; la fin de support de la distribution ; les images de conteneurs obsolètes. Et parce qu’un serveur a toujours des failles sans correctif disponible, ce qui est actionnable passe d’abord — le reste se met en exception, avec une justification écrite. Une CI peut aussi pousser l’inventaire de ses dépendances applicatives (SBOM) et les voir suivies au même endroit.
• Le diagnostic IA regarde vraiment la machine. Il reçoit son identité, ses anomalies, ses prévisions, ses métriques de la semaine, ses tâches planifiées, ses journaux et ses failles — là où il ne voyait qu’un compteur d’anomalies. Les commandes qu’il propose sont affichées, jamais exécutées : StatHall surveille, il n’administre pas. Et une machine où rien n’a bougé ne consomme plus rien.
• L’agent Unix 1.3 voit beaucoup plus. Espace disque en gigaoctets et plus seulement en pourcentage, températures et état SMART des disques, processeur par cœur, temps volé par l’hyperviseur sur les serveurs virtualisés, consommation par conteneur Docker et espace occupé par les images et les caches de build, mises à jour disponibles au complet, et un filtre pour écarter le bruit répétitif des journaux.
• Trente jours d’historique visibles. Les graphiques d’un serveur étaient figés sur 24 heures alors que les données sont conservées bien plus longtemps : un sélecteur 24 h / 7 jours / 30 jours arrive.

Corrigé

• Un serveur avec une erreur disque ouverte affichait un score technique de 100 sur 100.
• Les alertes de journaux livrées début septembre — erreur disque, force brute SSH, processus arrêté anormalement — n’étaient jamais poussées sur mobile. Elles le sont.
• La clé d’intelligence artificielle d’une application pouvait être consommée, et son quota débité, pour analyser un serveur.
• Les journaux et le diagnostic IA d’un serveur étaient inatteignables depuis la barre latérale.

L’agent se met à jour par apt upgrade stathall-agent une fois la version publiée sur le dépôt.

Ce qui change pour vous

• La vue d’ensemble est accessible depuis l’application mobile. L’écran qui rassemble toutes vos cibles, leur santé et leurs liens « hébergé sur » refusait de s’ouvrir sur téléphone : il attendait une session de navigateur, que l’application n’a pas. Elle affichait donc un message d’indisponibilité, sur le seul écran du produit qui donne la vue globale.
• Le bouton « Mettre à jour » d’iOS ne mène plus dans le vide. Quand une version de l’application devient trop ancienne pour parler au serveur, l’écran de mise à jour proposait un lien App Store qui n’existait pas. Il ne propose plus rien tant que la fiche iOS n’est pas publiée, au lieu d’ouvrir une page introuvable.

Aucune mise à jour de l’application n’est nécessaire : ces corrections prennent effet à votre prochaine session.

Ce qui change pour vous

• Heures calmes à votre heure : la plage « ne pas déranger » de vos notifications était évaluée en temps universel, jamais dans votre fuseau. Un « 22:00 → 07:00 » réglé depuis la France agissait en réalité de minuit à neuf heures. Elle suit désormais l’heure de votre appareil.
• Le filtre « Anomalie » du journal de notifications ne montrait que les alertes : les acquittements et les résolutions, pourtant bien reçus, en disparaissaient. Les trois s’y affichent maintenant.
• La liste de vos cibles porte son état de santé — elle était la seule vue du produit à ne pas dire l’état de ce qu’elle listait — et le nombre d’utilisateurs touchés par un crash n’est plus systématiquement à zéro.
• L’historique des synthèses hebdomadaires est dans le bon ordre : la plus récente arrive en tête, y compris quand plusieurs semaines ont été produites d’un coup.
• Le fil d’activité se traduit : ses libellés étaient composés en français côté serveur et s’affichaient tels quels dans la version anglaise de l’application. Il se lit aussi désormais sur 7 ou 30 jours, au lieu d’une semaine figée.

Aucune mise à jour de l’application n’est nécessaire : ces corrections prennent effet à votre prochaine session.

Ce qui change pour vous

• Catégories des avis : elles sont désormais déterminées par le modèle de langage configuré sur votre application, celui qui rédige déjà vos synthèses hebdomadaires. Sur notre corpus de référence, les étiquettes erronées passent de 22 à 6 et les catégories manquées de 103 à 40 — deux catégories, « performance » et « ergonomie », n’étaient tout simplement jamais détectées auparavant.
• Rattrapage bien plus rapide : l’analyse d’un avis prenait une douzaine de secondes, elle se compte désormais en fractions de seconde. Un historique de plusieurs milliers d’avis est traité en une heure au lieu de plusieurs jours.
• Sans clé, rien ne change : une application sans modèle de langage configuré — ou dont le budget mensuel est atteint — continue d’être analysée par le classifieur local, sans interruption ni perte.

Ce qui change pour vous

• Étiquettes des avis : le classement automatique retenait des étiquettes sur de simples présomptions — un avis signalant un plantage repartait aussi étiqueté « prix » ou « livraison ». Le seuil de confiance a été relevé : environ deux étiquettes par avis désormais, contre quatre, et nettement moins de hors-sujet. Les avis déjà analysés ont été mis à jour au nouveau seuil.
• Certains avis n’ont plus d’étiquette du tout : c’est voulu. Quand aucune catégorie ne ressort clairement, mieux vaut ne rien afficher qu’une étiquette trompeuse — les filtres de la page Avis s’en trouvent plus fiables.
• En coulisses : les avis pour lesquels le modèle ne retenait aucune catégorie étaient ré-analysés en boucle à chaque cycle, sans fin. Corrigé — le traitement du retard d’analyse en est d’autant plus rapide.

Ce qui change pour vous

• Applications et serveurs de démonstration : le jeu de données de démonstration est désormais régénérable à la demande sur une date donnée. Il raconte un scénario complet sur quatre mois — une régression introduite par une mise à jour, l’afflux d’avis négatifs qui suit, le correctif, puis le retour à la normale — avec avis multilingues, crashs, anomalies, versions et journaux serveur cohérents entre eux.
• Synthèses IA de démonstration : les avis de démonstration sont analysés par les mêmes traitements que vos vraies applications — vectorisation des avis et des crashs, étiquetage automatique, rapprochement d’un crash avec les avis qui le décrivent, et synthèses hebdomadaires générées par le modèle de langage configuré.
• Rapprochement des crashs remontés par plusieurs sources : la fusion d’un même crash vu par deux outils (par exemple Sentry et Crashlytics) échouait silencieusement lorsque les deux remontées avaient été vectorisées. Corrigé.

Ce qui change pour vous

• Serveurs › Configuration › Agent : dès qu’un agent s’était connecté, l’onglet affichait à tort « Aucun token actif » et proposait d’en générer un nouveau — ce qui aurait coupé l’agent en place. Le token actif s’affiche de nouveau (dernier passage, hôte, adresse IP, version de l’agent), et une erreur de lecture est désormais signalée comme telle, avec un bouton Réessayer.
• Serveurs › Vue d’ensemble : sur les écrans de largeur intermédiaire, les cartes « Système » et « État de l’agent » ne chevauchent plus leurs libellés — les colonnes s’adaptent à la largeur de la carte et le nom d’hôte reste lisible.

Ce qui change pour vous

• Serveurs › Logs : un filtre activé se voit désormais au premier coup d’œil, y compris pour les niveaux INFO et DEBUG — coche, bordure pleine et fond teinté sur chaque puce active. Même traitement sur les filtres de la page Événements.
• Interface : les fonds et bordures teintés des badges, bandeaux et survols de boutons s’affichent désormais comme prévu, en clair comme en sombre (ils étaient silencieusement ignorés par le moteur de styles).

Ce qui change pour vous

• Serveurs : correction interne de l’enregistrement de l’état d’ingestion (aucun changement visible ; les données d’auto-diagnostic sont désormais stockées proprement).

Ce qui change pour vous

• Page Logs d’un serveur : elle ne charge plus indéfiniment. Si la liste est vide, elle dit pourquoi — agent hors-ligne ou pas encore installé, agent à mettre à jour, seuil de remontée trop haut, collecte en difficulté ou simplement filtres trop stricts — et propose l’action utile. Une erreur s’affiche comme une erreur, avec un bouton Réessayer ; une requête lente peut être annulée ; une liste longue se poursuit avec « Charger plus » au lieu d’être coupée en silence.
• Plus de sources de logs (agent Unix 1.2.0) : en plus de journald, les logs des conteneurs Docker et les fichiers applicatifs de /var/log (nginx, PostgreSQL, MySQL, Redis, MongoDB, PHP-FPM, fail2ban, mises à jour automatiques…) remontent dans le cockpit, filtrables par source. L’agent signale ce qu’il ne peut pas lire au lieu de se taire.
• Nouvelles alertes dérivées des logs : rafale d’erreurs sur un service, volume de logs anormal, erreurs disque du noyau, échecs sudo répétés, tentatives SSH massives, plantage d’un processus, collecte de logs dégradée. Elles se ferment d’elles-mêmes quand la situation redevient normale.
• Agent Unix 1.2.0 : lecture de journald plus sobre et plus robuste (mémoire bornée, rattrapage progressif après une coupure, plus de logs manqués à cause du fuseau horaire ou des messages longs), regroupement plus fin des lignes similaires, diagnostic visible dans le cockpit. Mise à jour par apt upgrade, sans changement de configuration ; les agents 1.1 continuent de fonctionner.
• Cockpit : un onglet resté ouvert plusieurs jours se met à jour tout seul à la version suivante, et les pages serveur ne restent plus bloquées sur un chargement lorsqu’une donnée manque.

Ce qui change pour vous

• Alertes système : une mise à jour de l’instance recrée ses workers en moins d’une minute ; l’alerte « aucun worker ne répond » ne part plus que si l’indisponibilité dure au moins trois minutes.
• Agents : la version 1.1.1 de l’agent Unix est annoncée (seuil de logs configurable, unités suivies en détail).

Ce qui change pour vous

• Groupes depuis la cible : l’en-tête de chaque application et de chaque serveur affiche ses groupes et permet d’en ajouter ou d’en retirer directement, sans ouvrir l’administration des groupes. Seuls les groupes que vous pouvez administrer sont proposés.

Ce qui change pour vous

• Logs serveur : la page relançait la même requête en continu et restait sur son indicateur de chargement, comme si les logs ne remontaient plus. Corrigé : la période demandée est figée à la minute et la page s’affiche immédiatement.

Ce qui change pour vous

• Sauvegardes : la sauvegarde nocturne de l’instance hébergée ne produisait que des fichiers vides. Le script est réécrit (fichier écrit seulement après succès, rotation garantie) et StatHall se surveille désormais lui-même : une sauvegarde absente, en échec, vide ou trop ancienne déclenche une alerte système par e-mail et dans l’application.
• ANR chronique : une nouvelle anomalie signale une app Android dont le taux d’ANR perçu reste au-dessus du seuil « mauvais comportement » de Google Play (0,47 %), même sans pic. Les chiffres Play livrés avec cinq jours de retard sont désormais pris en compte.
• Site : la page d’accueil reflète ce qui est réellement disponible (serveurs Unix, sites web) et ne reste plus en cache après une mise à jour.

Ce qui change pour vous

• Les agents serveurs remontent à nouveau leurs mesures. Une incompatibilité entre notre limiteur de débit et l’API d’ingestion faisait répondre une erreur 500 à chaque envoi d’agent, même quand les données avaient été enregistrées : l’agent rejouait alors indéfiniment le même lot. Corrigé, avec un test qui exerce désormais l’API avec le limiteur actif pour que cela ne se reproduise pas.
• Le même défaut touchait le changement de mot de passe, la vérification d’e-mail, l’annulation de suppression de compte, l’aperçu d’une règle et les actions sur les sondes : tous corrigés.

Aucune action de votre côté : la mise à jour est côté serveur.

Ce qui change pour vous

Cette version regroupe trois chantiers : la détection (les hausses d’ANR Android sont désormais suivies et notifiées, comme les chutes de crash-free, même quand Google livre ses chiffres avec deux jours de retard), la supervision de serveurs de bout en bout, et un cockpit temps réel.

Vos serveurs, vraiment supervisés

• Agent 1.1 : plus de vingt métriques (CPU, iowait, mémoire, swap, charge, disque et inodes par point de montage, réseau, entrées/sorties, pression système), état des conteneurs Docker, timers systemd (vos sauvegardes), redémarrage requis, processus tués faute de mémoire, top 5 des processus. Installation inchangée, mise à jour transparente.
• Sondes HTTP / TCP / TLS exécutées depuis le cockpit : votre site répond-il, avec quel délai, et dans combien de jours expire son certificat ? Une sonde en échec ou un certificat proche de l’expiration devient une anomalie notifiée par e-mail et sur mobile.
• Agent silencieux = alerte : un serveur qui ne répond plus est signalé (P1 puis P0), au lieu d’un simple changement de couleur.
• Seuils d’alerte réglables par serveur, cadence de remontée pilotée par le cockpit, rétention des données bornée.

Un cockpit qui se met à jour tout seul

• Vue d’ensemble : toutes vos cibles, apps et serveurs, triées par priorité, avec la topologie « hébergée sur ».
• Les anomalies, notifications et synthèses apparaissent en temps réel (plus de rafraîchissement toutes les 30 secondes), la boîte de réception se charge page par page et reste fluide au-delà de 200 tuiles.
• Chargement initial quatre fois plus léger, et le cockpit s’installe comme une application (écran d’accueil sur mobile et desktop).
• StatHall se surveille lui-même : planificateur, workers, connecteurs et fraîcheur des données remontent des alertes système.

Application mobile 2.5

• Hors ligne : lecture depuis le cache, actions (acquitter, résoudre, reporter) mises en file et rejouées au retour du réseau.
• Rafraîchissement en arrière-plan et badge des anomalies critiques.
• Notifications enrichies (titre, corps, action « Acquitter » directement depuis la notification), vue d’ensemble, liens app ↔ serveur, création d’une cible serveur avec QR code d’installation, seuils d’alerte, sondes et conteneurs sur la fiche serveur.

Ce qui change pour vous

StatHall évolue sur un point important : il n’y a plus de tarif ni d’abonnement. Le projet assume pleinement son ADN : un outil utile, offert simplement, sans relation de service contraignante.

Trois voies, aucun engagement

• Instance hébergée gratuite — app.stathall.com reste gratuit, dans la limite d’un usage raisonnable (« fair-use ») qui protège l’infrastructure partagée. Le service est fourni « tel quel », sans garantie de disponibilité ni support contractuel.
• Auto-hébergement open-source — le code de StatHall est publié en open-source (licence AGPL-3.0). Si vous avez besoin de plus que le fair-use, ou si vous préférez garder vos données chez vous, hébergez votre propre instance avec Docker Compose — sans limite et sans dépendance.
• Dons — la rémunération du projet est désormais volontaire : Buy Me A Coffee et GitHub Sponsors. Aucune contrepartie, aucune obligation.

Et le tier Pro / le paiement ?

Le tier Pro payant et le paiement par carte sont retirés. Plus de case « passer Pro », plus d’abonnement mensuel, plus de contrat de vente (les CGV sont supprimées). À la place, une page « Fonctionnement » explique simplement comment tout marche.

Besoin d’un quota relevé, d’un connecteur spécifique ou d’un coup de main ? Contactez-nous : on regarde au cas par cas, sans engagement.

Founding supporters

Les contributeurs Buy Me A Coffee historiques gardent une reconnaissance à vie et un profil de quotas étendu. Merci à eux.

Sous le capot

• Suppression de l’intégration de paiement et des données associées.
• Les limites de quotas existantes deviennent des garde-fous de fair-use, sans notion de prix.

Ce qui change pour vous

Deux nouveautés majeures pour désencombrer le cockpit quand on suit beaucoup de cibles, plus un détail clavier attendu.

L’Inbox regroupe intelligemment les éléments

Jusqu’ici chaque ligne s’affichait séparément : une version sortie sur iOS et Android = 2 lignes, une anomalie qui se répète noyait le flux. L’Inbox applique désormais une règle de regroupement adaptée à chaque type :

• Nouvelles versions — une seule tuile par version, listant les OS impactés avec leur date de sortie (ex. v1.2.1 · iOS 17/05 · Android 18/05). Le tri utilise la date la plus récente.
• Synthèses IA — une seule tuile par cible et par jour (les différents scopes Apple / Google / Global sont fusionnés, le plus complet est mis en avant).
• Anomalies — quand une même anomalie se répète pour une cible, une seule tuile affiche un compteur d’occurrences (N×) et la date de la dernière occurrence, avec la sévérité la plus élevée. Dépliable pour agir sur chaque occurrence ; une anomalie isolée reste une carte classique actionnable.

Filtre Équipe / Tous / Démo, partout (comptes admin)

Un administrateur qui supervise plusieurs comptes était noyé par le flux des autres équipes et par les cibles de démonstration. Un nouveau sélecteur global apparaît en haut de l’écran pour les comptes administrateurs, avec trois modes :

• Équipe — uniquement les cibles de votre équipe interne (par défaut).
• Tous — toutes les cibles réelles, hors démos.
• Démo — uniquement les cibles de démonstration (debug / vitrine).

Le filtre démarre sur Équipe à chaque nouvelle session, puis votre choix est mémorisé pour la session en cours et s’applique partout : Inbox, catalogue, applications, serveurs, tableaux de bord, compteur d’alertes du rail et sélecteur de cible. Les démos ne parasitent plus la vue standard.

Raccourci clavier sur Windows / Linux

Le raccourci d’ouverture de la recherche fonctionnait déjà avec Ctrl+K sur Windows et Linux, mais l’interface n’affichait que la version macOS (⌘K). L’indice clavier s’adapte désormais à votre système : ⌘K sur Mac, Ctrl+K ailleurs.

Côté mobile

L’application mobile aligne son Inbox sur ces règles : regroupement des anomalies par type (compteur + dernière occurrence) et des synthèses par jour. Les versions étaient déjà regroupées par OS.

Sous le capot

• Aucune migration de base de données.
• Règles de regroupement centralisées côté serveur pour le cockpit web.

Ce qui change pour vous

Cette version transforme le rail latéral gauche en véritable cockpit personnel : épinglez vos apps, vos serveurs, vos pages favorites, et recevez des notifications centralisées dans une boîte de réception in-app.

Épinglez n’importe quel écran

Le bouton ⭐ apparaît désormais dans tous les en-têtes : sur la page d’une app, d’un serveur, d’un onglet (Reviews, Crashs, IA…), d’une page globale (Activité, Catalogue, Synthèse IA, Règles). Un clic ajoute l’écran à votre rail, un second clic le retire.

Pastilles explicites au coup d’œil

Les vignettes du rail (40×40 px) embarquent deux informations visuelles :

• Icône type en haut à gauche (rocket pour une app, server pour un serveur, shield pour une vue admin, filter pour un filtre Inbox…)
• Icône but au centre (MessageSquare pour Reviews, AlertOctagon pour Crashs, Sparkles pour la synthèse IA, etc.)
• Initiales en bas pour distinguer plusieurs favoris du même type (DF, AS, PW…)

Au survol, un popover riche affiche le nom complet, la catégorie, l’onglet ciblé et trois actions (Ouvrir / Renommer / Désépingler).

Boîte de réception in-app

La cloche en bas du rail devient fonctionnelle : un compteur indique les notifications non lues (polling 30 s), un clic ouvre un drawer latéral qui centralise toutes les notifications du workspace.

Sources couvertes au lancement :

• Anomalies ouvertes (P0/P1) — notif aux owners et co-owners
• Anomalies acknowledgées par un autre user — notif aux watchers
• Anomalies résolues par un autre user — notif aux watchers

Pour chaque notification, vous pouvez : marquer comme lue (clic), supprimer (✕), tout marquer lu, effacer toutes les lues. Le clic ouvre directement la page cible.

Compteurs synchronisés en temps réel

Quand vous marquez une notification d’anomalie comme lue, le badge de la cloche se décrémente immédiatement. Quand vous acknowledgez une anomalie depuis l’Inbox, le badge ⚠ P0 se synchronise. Les deux compteurs restent cohérents en permanence via l’invalidation automatique du cache.

Sous le capot

• Nouvelle migration alembic c1f7e2b8d4a6 (favoris polymorphes : kind, target_url, target_id, target_section)
• Nouvelle migration alembic c1f7e2b8d4a7 (table user_notifications avec RLS own-user + index partiel sur les non lues)
• 6 endpoints REST pour la boîte de réception (list, unread-count, read, mark-all-read, delete, clear-read)
• Hooks insert_notification dans services/anomalies.py (session dédiée, isolation totale de la transaction principale)
• 18 tests backend supplémentaires (favoris polymorphes + endpoints notifications) — total 506 tests verts

Cette version est rétrocompatible : vos vues épinglées existantes (filtre Inbox) restent intactes (kind=inbox_filter par défaut).

Ce qui change pour vous (côté mobile)

Itération mobile 2.0.0-rc.10 qui termine la refonte UX/UI alignée sur le design « Lecteur Mobile » et la SPA V2.2.x. Deux crashes signalés sont corrigés, l’écran de réglages des notifications devient fonctionnel, et le vocabulaire est aligné avec la SPA (« Synthèse IA » → « Pulse »).

2 crashes Sentry corrigés

• Tap sur « Réglages notifications » dans Compte plantait l’app à l’ouverture de la page (XamlParseException sur une ressource manquante). Trois références internes corrigées, l’écran s’ouvre désormais normalement.
• Tendance 30 jours sur le détail d’une app plantait au rendu du graphique dans certains contextes (25 events Sentry). La cause : des labels d’axe X non initialisés étaient passés à la librairie charts. Tableau initialisé proprement, plus de crash.

Réglages des notifications maintenant cliquable

L’écran granulaire « Réglages par type d’évènement » est désormais ouvrable depuis Compte → ligne dédiée. Il propose une grille 6 types × 3 canaux (P0/P1/P2/Synthèses IA/Versions/Système × Push/Mail/Quiet), une section heures calmes (DND avec plage horaire, P0 toujours autorisé) et un bouton de test push avec feedback toast visuel immédiat. Les icônes par type (alerte rouge/ambre/indigo, sparkles violet pour Pulse, etc.) s’affichent maintenant correctement.

AppPickerSheet : distinction apps vs serveurs + badge anomalies

La feuille « Choisir une cible » distingue désormais visuellement les applications (icône fusée fond indigo soft) des serveurs (icône server fond gris). Le « 0 » brut à droite de chaque cible est remplacé par un badge rouge « N anom. » visible uniquement si la cible a des anomalies ouvertes — sinon rien (lisibilité). Les libellés passent de « Choisir une app / Toutes les apps » à « Choisir une cible / Toutes les cibles » pour refléter le caractère polymorphe (apps + serveurs) depuis V2 LOT 2.

Vocabulaire aligné avec la SPA — « Pulse »

La SPA V2.2.1 a renommé « Synthèse IA » en « Pulse » (Pulse avis, Pulse app, Pulse serveur). L’app mobile suit en rc.10 : filtre Inbox « Synthèses » → « Pulses », card teaser « ✦ Synthèse IA » → « ✦ Pulse », titre de page « Synthèse IA » → « Pulse », « Historique des synthèses » → « Historique des Pulses ». Cohérence côté Inbox SPA et mobile.

Activité enrichie côté backend

L’écran Activité de l’app mobile affichait jusqu’ici uniquement la release 2.0.0-rc.7 (la dernière enregistrée en BDD). Le backend ajoute 72 entrées d’historique de déploiement (12 versions backend × 6 services : api, frontend, marketing, worker-default, worker-sync, beat) couvrant les 22 derniers jours (V2.0.0-rc.8 → V2.2.9). L’écran Activité du mobile montre désormais un historique réaliste à côté des releases store des apps demo.

Sous le capot

• Backend ajoute le champ kind (application | server) au schéma AppCard retourné par l’API mobile, propagé depuis SupervisedTarget.kind. Permet à l’app mobile de différencier les cibles polymorphes.
• Nouveau CLI seed-demo-release-events (idempotent, skip si ≥ 30 rows déjà en BDD) pour enrichir l’historique Activité.
• Mobile passe à 2.0.0-rc.10 / build 41. Build Android = 0 erreur, 455 tests xUnit verts.
• Aucune migration BDD.

Ce qui change pour vous

Trois retours utilisateurs traités en une passe pour parfaire la cohérence visuelle du cockpit.

Les anomalies serveur reviennent dans l’Inbox

Depuis la refonte de l’Inbox en v2.2.7, seules les anomalies app (crash, note, avis négatifs) apparaissaient dans le flux. Les anomalies serveur (charge CPU/RAM/disque/load au-delà des seuils) étaient invisibles, créant un décalage avec le badge 5 P0 du rail qui les comptait quand même.

Désormais le compteur du rail correspond au compteur « critiques » de l’Inbox, et les anomalies serveur apparaissent comme « Métrique système élevée — Nom du serveur ». Clic → vue d’ensemble du serveur concerné.

Pastille de notification mieux ancrée + icônes du rail agrandies

Le badge rouge sur l’icône Inbox était positionné par rapport au bouton (40×40 px), donc il « flottait » loin de l’icône réelle. Il est maintenant ancré directement sur le coin de l’icône, avec un anneau pour le détacher du fond.

Les icônes principales du rail (Inbox / Activité / Catalogue / Synthèse IA / Règles / Admin / Cloche) passent de 18 à 20 px avec un trait plus marqué. Plus lisibles sur tous les écrans.

Couleurs d’état des tuiles plus contrastées

Les pastilles d’état sur les tuiles du catalogue (8×8 px) sont agrandies à 10×10 px et entourées d’un halo coloré. Les 4 états (rouge déconnecté, ambre stale, vert connecté, gris en attente) sont enfin distinguables d’un coup d’œil.

LED de cohérence sur l’en-tête du serveur

Le point de couleur dans l’en-tête d’un serveur (à côté du nom) s’aligne désormais sur l’état réel — auparavant il restait vert quelle que soit la situation, ce qui pouvait laisser penser à un serveur en bonne santé alors qu’il était « en attente » ou « déconnecté ». Le rendu est désormais identique entre l’en-tête et la tuile du catalogue.

Agent à mettre à jour — couleur dédiée violette

Nouveau signal visuel : un serveur connecté qui tourne sur une version d’agent strictement antérieure à la version la plus récente observée dans votre portefeuille passe en LED violette (au lieu de vert). La couleur est dédiée — distincte du orange (serveur silencieux) et du bleu (statut « En attente ») — pour éviter toute confusion.

Exemple : si vos serveurs Runner-Seb-Nuc et autres tournent en v1.0.5 et que demo-prod-debian reste en v1.0.0, ce dernier apparaît en violet dans le catalogue.

Dans le détail du serveur (vue d’ensemble), le champ Version agent affiche un petit badge violet ↑ v1.0.5 à côté du numéro de version, avec une info-bulle qui rappelle la version cible.

LED bleue dédiée pour « En attente »

Les serveurs en attente (jamais connectés) affichaient une LED grise dans le catalogue alors que la fiche détail montrait un pill bleu (En attente). Ces deux représentations sont désormais alignées sur la même couleur bleue (brand-blue), distincte du violet (agent à mettre à jour) et de l’indigo (CTA).

Légende des couleurs au catalogue

Une légende inline a été ajoutée sous la barre de filtres du catalogue pour rappeler ce que chaque pastille signifie :

• Connecté · sain (vert)
• Silencieux · à surveiller (orange)
• Agent à mettre à jour (violet)
• Déconnecté · critique (rouge)
• En attente · jamais connecté (bleu)
• Inconnu · pas de donnée (gris plein, visible comme une vraie pastille)

Les compteurs en haut de page (les petites pastilles colorées à côté du « N targets ») gagnent aussi un tooltip au survol pour la même information. Le filtre Santé dans la barre d’outils contient une nouvelle option « En attente » pour ne voir que les serveurs jamais connectés (utile pour les pré-installations).

Plus de tuiles par ligne

La grille catalogue gagne +1 colonne par taille d’écran : sur écran très large vous voyez maintenant 6 tuiles par ligne au lieu de 5, sur écran moyen 3 au lieu de 2, etc. Gain de ~17 % de largeur économisée par tuile.

Sous le capot

• Type d’anomalie server_metric_high désormais accepté par l’endpoint Inbox SPA.
• Pastille tuile : h-2.5 w-2.5 + ring-2 coloré, sans clip dans les noms tronqués (fix du débordement signalé par utilisateur).
• Pas de migration BDD.

---

Patch du 19/05 — retours utilisateurs

Une dizaine de retours rapides traités en un commit, toujours sur la 2.2.9 (pas de bump).

Reviews — la recherche et le filtre Version refonctionnent

La barre de recherche des avis ne cherchait que dans le contenu de l’avis ; taper « 28.3.1 » ou le nom d’un utilisateur ne renvoyait jamais rien. Elle parcourt désormais aussi le titre, l’auteur et la version. Le filtre Version, lui, n’envoyait pas la sélection au serveur — il restait visuel sans effet. Sélectionner « 28.3.1 » filtre maintenant correctement la liste.

Le sélecteur de versions a été refondu : combobox multi-sélection avec recherche intégrée, tri sémantique décroissant (les versions récentes d’abord), suffixe « · iOS / · Android » retiré (la version est un identifiant universel, le sélecteur Plateforme suffit pour cibler une OS). On peut cocher plusieurs versions et la liste des avis se filtre sur l’union.

Tous les filtres Reviews sont désormais dans l’URL (?q=… &version=…&platform=…&rating=…) : on peut bookmarker une vue, partager un lien, ou venir du module Versions et atterrir pré-filtré sur la release concernée.

Versions → Reviews en un clic

Sur la page Versions d’une app, le compteur d’avis de chaque ligne devient un lien direct vers /apps/:slug/reviews?version=X&platform=Y. Plus besoin de noter la version puis d’aller la chercher dans le filtre.

Bonus : ouvrir une carte « Version publiée » depuis l’Inbox ouvre la page Versions de l’app pré-filtrée et auto-dépliée sur la version concernée (déjà livré dans cette 2.2.9, mention pour rappel).

Inbox — synthèses dédupliquées

Les synthèses IA (avis Apple, Google, Global) générées sur la même date apparaissaient en 3 lignes côte-à-côte pour la même app. La synthèse Global est gardée (elle inclut Apple+Google) ; les scopes individuels restent disponibles dans Pulse avis.

Pulse avis (app) — l’écran ne ressort plus vide

La vue 3 colonnes (Global / iOS / Android) cherchait une synthèse dont les dates collaient pile aux 30 derniers jours. Comme les synthèses archivées couvrent des fenêtres figées (7 j, 30 j à date fixe…), la correspondance échouait presque toujours et chaque carte ressortait « Aucune synthèse disponible ». Le composant pioche désormais la dernière synthèse réussie par scope et affiche explicitement la plage couverte (« Période : DD/MM → DD/MM »).

Synthèse IA globale — plage de dates + chips enrichies

Le header de la Synthèse IA globale affiche désormais la plage de dates couverte (du DD/MM au DD/MM) en plus du libellé « Cette semaine / Semaine précédente / Mois ».

Les chips de cibles en bas de la synthèse étaient pauvres en information (juste un nom + une icône). Elles affichent désormais le compteur d’anomalies P0/P1 ouvertes (badge rouge ⚠ N quand

0, encadré rouge sur la chip) et la dernière version connue. Tri descendant : les cibles avec le plus d’anomalies critiques apparaissent en premier.

Groupes accessibles aux propriétaires

Les propriétaires d’apps/serveurs peuvent désormais consulter et gérer leurs groupes via /groups (nouvelle entrée dans la sidebar « Vues globales »). La création d’un groupe racine reste réservée au super-admin (le backend renvoie 403 sinon), mais la création de sous-groupes, l’édition, la suppression et la gestion des membres se font sans passer par le panneau admin.

Règles d’anomalies — message clair quand la table est vide

La page Règles d’anomalies affichait sèchement « 0 règles · 0 actives » quand la table était vide, sans expliquer pourquoi (les 9 règles par défaut auraient dû être seedées par la migration V2.2). Elle affiche désormais un encadré explicatif avec la commande à lancer côté API : python -m app.cli seed-anomaly-rules (idempotent grâce à un index unique sur la clé naturelle).

Email transfert de propriété — fix Outlook + bouton

Le logo carré dans le header des emails apparaissait vide sur Outlook (la teinte semi-transparente est ignorée → tombait sur blanc plein, donc « S » blanc sur blanc invisible). Fallback indigo foncé pour Outlook, voile blanc transparent sur les autres clients.

Le bouton « Voir l’app » dans l’email transfert de propriété a été refait en pattern bulletproof button (table + mso-padding-alt) pour qu’il garde ses paddings sur Outlook 2007-2019. Flèche → ajoutée pour clarifier l’intention.

Sous le capot

• Backend GET /apps/{id}/reviews accepte désormais ?version= répété (multi-valeurs). Le paramètre q cherche dans content + title + author + version_string.
• Schéma AIDigest exposé : period_from + period_to. Chips de cibles enrichies en open_critical + last_version côté payload.
• Backend app/services/inbox.py dédup les summaries par (target_id, date(generated_at)) avec priorité global > apple > google.
• Nouvelle CLI seed-anomaly-rules (idempotent via index unique partiel uq_anomaly_rules_natural_key).
• 0 migration BDD ; pas de nouveau secret ni de nouvelle dépendance.

---

Patch 2 du 19-20/05 — confidentialité super-admin + co-owner delete + icônes mobile

Break-glass désormais mandatory pour les super-admins

Avant : un super-admin pouvait consulter et configurer n’importe quelle application ou serveur sans rien demander, même ceux dont il ne fait pas partie de l’équipe. Le bouton « Demander un accès temporaire » était là, mais purement cosmétique.

Maintenant : un super-admin qui n’est ni propriétaire ni co-propriétaire d’une cible doit demander un accès temporaire (break-glass) pour la consulter comme pour la modifier. Sans grant actif, l’URL /apps/:slug ou /servers/:slug renvoie 404. Le propriétaire reçoit un email à chaque demande, et toutes les actions du super-admin sont auditées.

Les pages d’administration (utilisateurs, plans, audit log, système) restent librement accessibles — la restriction porte uniquement sur le détail des cibles métier.

Co-propriétaire ne peut pas supprimer une app/serveur

Le backend bloquait déjà la suppression (réservée au propriétaire principal), mais l’UI laissait le bouton « Supprimer » actif aux co-propriétaires — le clic échouait avec une erreur silencieuse. Le bouton est désormais désactivé pour les co-propriétaires, avec un encadré explicatif : « Action réservée au propriétaire ». Pour supprimer une app dont vous êtes co-propriétaire, demandez au propriétaire ou un transfert préalable.

Mobile — icônes harmonisées avec la SPA

L’écran de sélection de cible (mobile) affichait une fusée pour les apps et un rack pour les serveurs. La SPA, elle, utilise les emojis 📱 + 🖥 pour la même distinction. Les deux s’alignent désormais sur 📱 (application) + 🖥 (serveur), avec le carré coloré Aurora conservé pour différencier visuellement.

À déployer sur iPhone via ./scripts/deploy-ios-device.sh quand prêt — version mobile 2.0.0-rc.12 (build 43).

Ce qui change pour vous

Petite passe d’ergonomie sur la vue arbre du catalogue : les chaînes d’ancêtres vides sont désormais coalescées sur une seule ligne avec un breadcrumb, à la manière de VS Code qui rend src/components/layouts/ sur une seule ligne quand aucun dossier intermédiaire n’a de fichier direct.

Avant / Après

Sur une hiérarchie Client > Solution > Env > debian/ubuntu où seuls les groupes feuilles (debian, ubuntu) ont des cibles directes, vous voyez maintenant :

▾ Client › Solution › Env    8 inclus  ⚙
   ▾ debian                  4 cibles  ⚙
     [cards × 4]
   ▾ ubuntu                  4 cibles  ⚙
     [cards × 4]

au lieu de 6 lignes structurelles enchaînées.

Cas dynamiques

• Si vous ajoutez une cible directement dans le groupe « Client », Client cesse de coalescer et reprend sa propre ligne avec ses cards.
• Si un nouveau groupe apparaît au même niveau que Solution, le parent Client redevient un point de divergence (sa ligne apparaît, les sous-arbres continuent à coalescer).
• Les groupes complètement vides (ni membre direct, ni descendant avec contenu) sont masqués du catalogue. Ils restent visibles dans /admin/groups si vous voulez les configurer.

Bouton ⚙ Configurer

L’icône Configurer continue de pointer vers le dernier segment du breadcrumb (le groupe effectivement représenté par la ligne). Pour configurer un ancêtre coalescé, passez par /admin/groups.

Sous le capot

• Algorithme buildTreeSections réécrit en 2 passes (prune + emit).
• Le pliage en cascade est préservé.
• Pas de migration BDD, frontend-only.

Ce qui change pour vous

L’Inbox du SPA s’aligne sur l’app mobile : un flux unique chronologique qui mélange anomalies, synthèses IA et nouvelles versions détectées. Chaque ligne ouvre directement l’onglet pertinent de la cible concernée.

4 onglets de tri en haut

• Tout — feed chronologique complet (par défaut).
• Anomalies — uniquement les anomalies (statut filtre + sévérité filtre disponibles).
• Synthèses — uniquement les synthèses IA hebdomadaires.
• Versions — uniquement les nouvelles versions détectées.

L’onglet actif est persisté dans l’URL (?kind=).

Lignes lisibles d’un coup d’œil

Chaque carte du flux porte :

• Une bande de couleur à gauche : rouge P0, ambre P1, indigo Synthèse, violet Version.
• Un badge : sévérité pour les anomalies, ✨ Synthèse pour les IA, 🏷 Version pour les releases.
• Un titre pré-formaté (« Crashes en hausse — Demo Travel App », « Nouvelle synthèse hebdo », « v1.2.1 publiée »).
• Un sous-titre contextuel : plateforme/version pour anomalie, thèmes pour synthèse, plateforme pour version.

Lien « Ouvrir le contexte » par type

Le panneau détail à droite affiche le contenu spécifique et un bouton qui route vers le bon onglet de la cible :

• Anomalie app → page Anomalies de l’app
• Anomalie serveur → vue d’ensemble du serveur
• Synthèse → onglet Pulse Avis de l’app (/ia-reviews)
• Version → page Versions de l’app

Pour les anomalies, les actions Acquitter / Reporter / Marquer résolue restent disponibles.

Filtres et tabs

Quand vous sélectionnez Anomalies (ou Tout), un sélecteur Statut apparaît dans la barre de filtres (Ouvertes / Acquittées / Reportées / Résolues / Tout) — l’option statut a été déplacée des tabs vers la barre de filtres, pour cohérence avec le mobile.

Le filtre Période (24h / 3j / 7j / 30j) reste toujours visible.

Sous le capot

• Nouveau endpoint GET /api/v1/inbox — feed cross-source avec paramètres kinds, anomaly_status, window_days, limit.
• Le service backend agrège 3 sources en une seule réponse triée DESC par date d’apparition.
• Le BFF mobile garde son endpoint séparé inchangé (cursor pagination, etc.).
• Polling auto 60 s côté SPA.

Ce qui change pour vous

Trois améliorations qui rendent l’usage des groupes naturel pour ceux qui les utilisent au quotidien.

Le catalogue s’ouvre directement « Groupé par groupe »

Dès lors que vous voyez au moins un groupe, le catalogue bascule par défaut sur le mode Grouper par : Groupe. Si vous préférez un autre mode (Type / Santé), votre choix est persisté dans l’URL (?gb=type) et reste prioritaire sur le défaut automatique.

Vue arbre dépliée par défaut

Les sections groupes sont rendues avec indentation et chevron pliable. Tout l’arbre est déplié au premier affichage. Vous pouvez replier individuellement chaque branche, ou utiliser les boutons « Tout déplier / Tout replier » de la toolbar.

Le pliage est en cascade : replier un parent cache automatiquement ses descendants.

Vous êtes propriétaire ou co-propriétaire d’un groupe ? Vous pouvez l’administrer

Le bouton ⚙ Configurer apparaît dans le header de chaque section de groupe où vous avez les droits d’écriture (propriétaire, co-propriétaire direct, ou propriétaire d’un groupe ancêtre avec héritage activé). Un clic ouvre la page de configuration du groupe (General · Membres · Accès · Synthèse IA) — sans passer par l’administration super-admin.

L’administration super-admin de groupe reste accessible sur /admin/groups pour les opérations cross-comptes.

Sous le capot

• Champ can_write ajouté à chaque nœud de groupe dans l’API (1 requête SQL batch pour tous les groupes visibles).
• Nouvelle route /groups/:id/config non gardée par RequireAdmin — la RLS Postgres garantit le contrôle d’accès serveur-side.
• Pas de migration BDD.

Ce qui change pour vous

Le mode « Grouper par : Groupe » du catalogue affiche enfin une section par groupe avec les cibles correspondantes. Auparavant la bascule renvoyait toujours une seule section « Tous » — la fonctionnalité était inactive depuis V2.2.0-rc.1.

Sections par groupe + Sans groupe

Dans /catalogue, sélectionnez Groupe dans le sélecteur « Grouper par ». Vous voyez maintenant :

• Une section par groupe que vous administrez ou auquel vous avez accès, avec la grille de cibles correspondantes.
• Une section finale « Sans groupe » pour les cibles orphelines (non rattachées).

Une cible appartenant à plusieurs groupes apparaît dans chaque section concernée (sémantique « grouper par » standard).

Sous le capot

• L’endpoint GET /groups expose désormais la liste des membres directs pour chaque nœud (une seule requête SQL agrégée, RLS-aware).
• Pas de migration BDD, pas de breaking change : le payload est additif côté API.

Ce qui change pour vous

Cette version corrige un bug qui empêchait les propriétaires d’apps non super-admin d’éditer leur propre app, et refond la console d’administration des apps et serveurs avec un filtre par utilisateur pour gagner en clarté quand un workspace héberge plusieurs équipes.

Vous êtes propriétaire d’une app ? Le bouton « Configurer » fonctionne enfin

Si vous êtes propriétaire ou co-propriétaire d’une app, le bouton Configurer dans l’en-tête de l’app ouvre désormais directement les options : sources de données, paramètres de santé, équipe, synthèse IA, danger. Plus de redirection silencieuse vers la home — le piège vous touchait à chaque clic sur Configurer.

Idem pour les serveurs : le bouton Configurer route correctement les propriétaires vers la page de config du serveur sans passer par l’administration globale.

Refonte de l’administration Apps / Serveurs

Les pages Admin › Apps et Admin › Serveurs gagnent :

• Une barre de filtres Équipe / Tous / Utilisateur. Par défaut, vous ne voyez que les apps et serveurs possédés par l’équipe StatHall (super-admins). Sélectionnez un utilisateur pour basculer sur ses apps/serveurs.
• Un champ de recherche sur le nom ou le slug.
• Une colonne Propriétaire triable avec l’email du owner + une pastille ÉQUIPE (indigo) ou CLIENT (purple) calculée automatiquement.
• Un compteur live « N résultats » à droite de la barre.

L’état des filtres est persisté dans l’URL : partagez le lien /admin/apps?owner=42 pour pointer directement vers les apps d’un utilisateur.

Étiquette « Lecteur » devenue « Utilisateur »

Sur la page Admin › Utilisateurs, le rôle global user s’affichait « Lecteur ». L’étiquette induisait en erreur : un utilisateur peut être propriétaire de ses apps et y avoir tous les droits. La nouvelle étiquette Utilisateur est plus neutre.

Inbox : on voit la cible de chaque anomalie

Chaque ligne de l’Inbox affiche désormais Application · Nom de l'app ou Serveur · Nom du serveur sous le type. Le bouton « Ouvrir le contexte » route correctement vers la page Anomalies de l’app ou la vue d’ensemble du serveur (plus de lien cassé pour les serveurs).

Refonte du panel Membres des groupes

Sur la page d’un groupe, l’onglet Membres ne montre désormais que les membres effectifs (plus de mélange avec la liste complète des cibles visibles). Un bouton « + Ajouter des cibles » ouvre une modale avec recherche, filtres apps/serveurs, multi-sélection et action en lot « Tout sélectionner les résultats visibles ».

Sous le capot

• 0 migration BDD, fix purement frontend + permissions backend préservées (RLS Postgres inchangée).
• Nouveau composant UserPickerCombobox réutilisable (clavier d’abord : flèches, Enter, Esc).
• Nouveau hook useGroup(id) pour la résolution membres d’un groupe.
• 58 tests frontend verts.

Ce qui change pour vous

Fin de la refonte V2.2 « Inbox + Scope » : la finition apporte tout ce qui manquait pour rendre la version stable et utilisable au quotidien en mobilité.

Synthèses IA cross-source

Quatre nouveaux endpoints IA alimentent désormais l’interface :

• Synthèse IA hebdomadaire (cross-scope) : brief automatique tous les lundis matin, avec TLDR, points chauds et signaux à surveiller sur l’ensemble de vos cibles supervisées.
• Pulse app — vue globale : synthèse de santé d’une app (points forts, points faibles, recommandation prioritaire).
• Pulse avis : 3 colonnes adaptatives Global / iOS / Android selon les plateformes de l’app, chacune avec sentiment, positifs, négatifs, bugs signalés, demandes utilisateurs, tags et verbatims.
• Pulse serveur : synthèse d’activité 7 jours (incidents, highlights, recommandation opérationnelle).

Toutes les synthèses sont cachées 1 heure côté serveur. Sans fournisseur LLM configuré, l’interface affiche un récap structuré fallback (pas de page vide).

Règles d’anomalies appliquées en temps réel

Les règles d’anomalies que vous éditez depuis /rules sont maintenant lues directement par le moteur de détection (cascade target > groupe > type > tous). Un nouveau bouton Preview permet de prévisualiser « combien d’anomalies cette règle aurait déclenchées sur les 30 derniers jours » avant de l’enregistrer — calibrez vos seuils avec confiance.

Barre de commande / enrichie

• Targets membres : en mode chemin /lab/lab-debian/, le menu affiche désormais les cibles membres du groupe, plus seulement les sous-groupes.
• Édition inline des groupes : pressez ⌘+. sur un nœud groupe pour renommer, déplacer ou supprimer le groupe sans quitter la barre de commande.

Catalogue & Activité polis

• Catalogue : chaque carte affiche désormais la dernière version released de l’app (Apple ou Play, la plus récente).
• Activité : nouveau bandeau 5 colonnes au-dessus du feed (Évènements 7 j · Anomalies · Releases · Système · sparkline aujourd’hui par heure).
• Synthèse IA : la date de dernière génération s’affiche en format relatif (« il y a 2 h ») avec un indicateur visible pendant une régénération.

Vues épinglées partagées

Vous pouvez désormais partager une vue épinglée avec le reste de votre workspace : cochez « Partager cette vue » au moment de l’épinglage. Une petite icône 👁 distingue les vues publiques dans le rail. Lecture seule pour les autres membres.

Responsive mobile

L’interface est désormais utilisable confortablement sous 1024 px : un drawer slide-over remplace les barres latérales, accessible via le hamburger en haut à gauche. Tablette et mobile ne perdent plus aucune fonctionnalité.

Sous le capot

• Nouvelle migration alembic c1f7e2b8d4a5 (colonne pinned_views.is_public + policy RLS étendue lecture publique).
• Génération LLM cross-source via les fournisseurs déjà configurés (DeepSeek / OpenAI), pas de nouveau coût caché.
• Job Beat lundi 06:00 UTC : email.send_global_ai_digests enrichi avec le contenu réel (tldr, hotspots, watch list) plutôt qu’un placeholder.
• Refactor scope global vers React Context (mémoization + consistency cross-pages).
• Suite de tests : 488 tests backend + 58 tests frontend + scaffolding e2e Playwright. Aucune régression sur les écrans V2.1.

Cette version stabilise V2.2 dans sa forme définitive ; nous recommandons de mettre à jour dès que possible.

Ce qui change pour vous

Après quatre itérations rapides du cockpit en 24 h (V2.1.0), StatHall passe à une refonte UX profonde issue d’un audit ergonomique externe. Le pattern « Inbox + Scope » repose sur trois piliers : triage d’abord, commande au clavier, scope par groupe.

Inbox = home (remplace Vue globale)

L’écran d’accueil est désormais l’Inbox, une liste de triage des anomalies ouvertes. Vous savez en 5 secondes ce qui mérite votre attention ce matin — pas besoin de scroller un dashboard pour chercher les rouges.

• Statuts enrichis : ouverte / acquittée / reportée / résolue. Vous pouvez reporter une anomalie à demain et elle reviendra automatiquement dans l’Inbox quand la fenêtre expire.
• Vide = “Tout est calme” : si rien n’est en suspens, l’Inbox vous le dit clairement plutôt que d’afficher un dashboard à parcourir.

/portfolio redirige automatiquement vers /inbox — vos bookmarks restent valides.

Combobox unifié avec mode shell « / »

Le sélecteur de cible en haut devient un combobox central combinant trois modes :

1. Affichage idle = « tu es ici » (la cible courante, ou le scope actif, ou la vue en cours).
2. Mode libre (⌘K ou clic) = favoris, récents, scopes, groupes, actions, recherche fuzzy multi-token.
3. Mode shell (commence par /) = grammaire chemin façon Unix. /demo-fitness/cra + Tab + Entrée → vous atterrissez sur Demo Fitness, onglet Crashs. /lab/lab-debian/ → catalogue scopé sur le Lab Debian. Tab complète le préfixe commun ou cycle entre matches.

Le raccourci ? ouvre la cheat sheet complète. Plus besoin de clique-clique pour aller quelque part — tapez le chemin.

Groupes hiérarchiques de cibles

Vous pouvez maintenant regrouper vos targets en arbre : Client > Solution / Environnement > targets. Sémantique libre — client final, ligne de produit, env prod/staging/dev, peu importe.

• Une cible peut appartenir à plusieurs groupes (matrice produit × environnement supportée).
• Les droits d’accès sont hérités automatiquement vers les sous-groupes et leurs membres (par défaut ; débrayable par groupe).
• Toutes les vues principales (Inbox, Catalogue, Activité, Synthèse IA, Règles) sont filtrées par le scope global — sélectionnez « Acme » dans le combobox et tout est restreint à ce client.
• Le scope est dans l’URL (?scope=group:acme), donc partageable par lien direct.

5 vues principales

• Inbox (/inbox) : triage anomalies, statuts, filtres, drawer détail.
• Activité (/activity) : chronologie unifiée des releases, transitions d’anomalies et events système, groupée par jour.
• Catalogue (/catalogue) : grille des targets avec groupBy = groupe / type / santé, remplace /apps + /servers.
• Synthèse IA globale (/ai) : digest cross-scope hebdo qui agrège tout ce que vous voyez — anomalies critiques, releases, sentiment apps, patterns serveurs.
• Règles (/rules) : 9 règles d’anomalies par défaut, éditables par les admins. Héritables sur l’arbre des groupes.

Synthèse IA par cible — Avis ET Activité

L’onglet « Synthèse IA » d’une app prend un sous-toggle Avis / Activité :

• Avis = la synthèse des avis store (sentiment, points pos/neg, bugs signalés) — comme avant, déplacée depuis l’ancien onglet Synthèses.
• Activité = nouveau : résumé textuel des events, crashs, anomalies, patterns récurrents de la cible.

Les serveurs gagnent un onglet « Synthèse IA — Activité » équivalent (events systemd / apt / reboots).

Réception par mail au choix : un nouveau bloc dans /account/email-subscriptions vous laisse opt-in pour recevoir le digest globale et les synthèses target par mail à la cadence de votre choix (jamais / hebdo / mensuel). La cadence de génération côté cible reste pilotée par son propriétaire (panneau admin de l’app / serveur / groupe).

Mode admin clairement séparé

Quand vous entrez dans le panneau d’administration, un bandeau violet « Mode administration » apparaît dans le topbar et une sidebar dédiée à 3 groupes (Gestion / Produit / Système) prend la place de la navigation principale. Pour quitter, un bouton dédié revient à votre supervision quotidienne. Pas de confusion possible entre les deux espaces.

Vues épinglées personnelles

Vous pouvez épingler une vue Inbox filtrée (par exemple « P0 du client Acme ») et la retrouver d’un clic dans le rail. Les vues épinglées sont persistées en base de données, donc disponibles depuis tous vos appareils.

Sous le capot

• Le menu latéral 5 items remplace les 4 entrées V2.1 (Vue globale, Toutes les apps, Tous les serveurs, Anomalies). Les vues d’ensemble sont accessibles via le combobox.
• Le bandeau « Lecture seule » devient une bannière discrète et dismissible (par session).
• Le numéro de version dans le topbar ouvre un drawer changelog intégré.

---

Aucune action de votre part — la nouvelle ergonomie s’applique automatiquement à votre prochaine connexion. Les anciens liens /portfolio /apps /servers /apps/.../summaries redirigent vers les nouvelles routes.

Ce qui change pour vous

Un menu latéral repensé

Le menu latéral gauche du cockpit web est entièrement refondu en deux colonnes :

• Rail fin permanent (56px) avec les icônes de navigation globale : Vue globale, Toutes les apps, Tous les serveurs. Toujours visible, on switche entre vues en un clic depuis n’importe où.
• Panel contextuel (200px) à droite du rail qui s’adapte automatiquement à la route :
  • sur une app → sous-nav app (Dashboard, Reviews, Crashs, Versions, Roadmap, Anomalies, Synthèse IA)
  • sur un serveur → sous-nav serveur (Overview, Events)
  • sur le panneau admin → 3 groupes (Gestion / Produit / Système)
  • sur les vues d’ensemble → raccourcis Portfolio / Apps / Serveurs
  • sur le profil → Compte, Feedback, Soutenir

Plus besoin de passer par le sélecteur de cible en haut pour naviguer entre vos targets supervisés : un clic sur l’icône du rail fait le job.

Badge alerte anomalies critiques

Un nouveau bouton ⚠️ dans le rail affiche un badge rouge avec le nombre d’anomalies P0 ouvertes sur l’ensemble de vos targets. Cliquer → vous arrivez directement sur la vue cross-targets pour les acquitter.

Raccourci admin permanent

Pour les administrateurs, un bouton ⚙️ dédié dans le rail mène à /admin en un clic depuis n’importe quelle page.

Améliorations ergonomiques (déployées le même jour)

• Cards plus compactes sur les vues “Toutes les apps” et “Tous les serveurs” : grille plus dense (jusqu’à 5 cartes par ligne sur écran large).
• Tuiles KPI cliquables sur ces mêmes vues : un clic sur “Connectés” filtre la grille pour ne montrer que les serveurs connectés. Idem pour “Anomalies”, “Démo”, “Épinglées”.
• Tuiles KPI Portfolio navigables : “Applications” → /apps, “Serveurs” → /servers, “Anomalies ouvertes” → vue Anomalies.

Sous le capot

• Le shell unique remplace les 5 layouts précédents (app, serveur, admin, vues globales, profil) — plus simple à maintenir.
• Le menu reste accessible au clavier et compatible lecteur d’écran (rôle navigation, tooltips, focus visible).

---

Aucune action de votre part — la nouvelle ergonomie s’applique automatiquement à votre prochaine connexion.

Ce qui change pour vous

Trois vues d’ensemble pour superviser tout

Le cockpit web s’enrichit de trois nouveaux dashboards utilisateur, accessibles directement depuis le menu de cible en haut :

• Vue globale (/portfolio) — un coup d’œil sur tout : KPI agrégés, top des anomalies critiques, vos apps et vos serveurs côte à côte.
• Toutes les apps (/apps) — la liste complète de vos applications mobiles avec recherche, stats, et accès aux vues Reviews cross-app et Anomalies cross-app en onglets secondaires.
• Tous les serveurs (/servers) — la liste complète de vos serveurs Unix avec stats Connectés / Silencieux / Déconnectés.

Chaque carte est cliquable et vous mène directement au dashboard de l’app ou du serveur concerné.

Un nouveau menu de cible plus malin

Le menu en haut (« Choisir une cible ») gagne quatre nouveautés :

• Vues d’ensemble en haut du menu : raccourci direct vers les trois dashboards globaux.
• Favoris — épinglez vos cibles les plus consultées avec l’étoile au survol, elles remontent toujours en haut du menu.
• Récents — vos 5 dernières cibles consultées sont rappelées automatiquement.
• Pastille de santé sur chaque cible : verte si tout va bien, orange si attention, rouge si anomalie critique. Plus le point gris qui apparaît quand les données n’ont pas été synchronisées depuis 24h.

Le menu reste lisible même si vous supervisez plusieurs dizaines de cibles, grâce à la recherche cmdk + l’épinglage.

Sidebar admin réorganisée

Pour les administrateurs, le panneau admin (/admin) est désormais rangé en trois groupes thématiques clairs :

• Gestion : Apps, Serveurs, Utilisateurs, Validations.
• Produit : Plans tarifaires, Codes d’accès.
• Système : Système, Audit, Diagnostic push.

Plus de duplication entre la sidebar et le menu utilisateur en haut à droite — ce dernier ne garde plus qu’un seul raccourci Panneau admin.

Écrans admin remis au standard visuel

Les pages Plans tarifaires, Codes d’accès et Diagnostic push adoptent enfin le design Aurora Valhalla cohérent avec le reste du SPA : tables dans des cartes, inputs et boutons standardisés, états vides illustrés.

Sous le capot

• Un onglet Agent était présent dans la barre latérale des serveurs côté utilisateur — il était sans utilité (la gestion des tokens est exclusivement administrative) et a été retiré.
• Un token visuel cassé (bg-surface-card) qui rendait certaines cartes invisibles a été corrigé partout dans l’application.

---

Aucune action de votre part n’est requise — la nouvelle ergonomie s’applique automatiquement à votre prochaine connexion.

Ce qui change pour vous

Une app mobile plus cohérente

L’app StatHall Mobile (iOS + Android) reçoit une refonte visuelle complète. La navigation entre les écrans est plus fluide, les titres et les cartes adoptent un style commun (police Inter Tight, palette Aurora) et la barre de navigation native iOS est désormais alignée avec le reste de l’application.

Un cockpit à 5 onglets

La barre de navigation passe de 3 à 5 onglets : Inbox · Cibles · Santé · Activité · Compte. L’onglet « Apps » revient à son nom générique « Cibles » et liste par défaut toutes vos applications et vos serveurs supervisés — vous filtrez ensuite si vous le souhaitez.

Nouvel onglet « Santé »

D’un coup d’œil, retrouvez le score de santé global de votre portefeuille, décomposé en trois dimensions (tech / business / adoption), et la liste des cibles qui méritent votre attention en premier (santé inférieure à 70).

Nouvel onglet « Activité »

Une timeline temps-réel rassemble en un seul flux : déploiements détectés, nouvelles versions store iOS / Android, événements d’agent (systemd, mises à jour de sécurité APT…). Filtrez par type pour vous concentrer sur ce qui compte.

Liens app ↔ serveur visibles dans l’app

Sur la fiche d’une application, une section « Serveurs liés » liste les serveurs qui l’hébergent (relation hosted_on). À l’inverse, la fiche serveur affiche un raccourci vers l’application parente. Le tap sur une carte vous emmène directement vers le détail.

Sous le capot

Quelques nouveaux points de contact côté backend pour alimenter ces écrans (vue d’ensemble santé, feed activité, liens entre cibles), sans incidence sur vos données existantes. Le système d’agrégation reste local à votre tenant — rien ne sort de votre périmètre.

---

Pas d’action requise — cette version arrive automatiquement sur l’app mobile à votre prochaine ouverture.

Ce qui change pour vous

Un abonnement Pro pour soutenir le projet

Cette release introduit le tier Pro à 12 €/mois (TVA non applicable, art. 293 B du CGI), pensé comme une participation aux frais d’infrastructure plutôt qu’un produit commercial à SLA. Le tier gratuit reste intact pour les usages standards. Les Founding supporters historiques bénéficient automatiquement de 6 mois Pro offerts.

Le super-dashboard

Une nouvelle vue rassemble toutes vos cibles supervisées — applications et serveurs — sur un seul tableau de bord. Vous pouvez désormais lier une application à un serveur (relation hosted_on, depends_on, related) pour voir d’un coup d’œil l’état d’un groupe de services interdépendants.

Suivi de consommation et codes d’accès

Une page Consommation détaille votre utilisation quotidienne (appels API, événements ingérés, emails) et l’état de vos quotas. Une page Code d’accès permet de saisir un code promo ou un grant — utile pour les early adopters et les ambassadeurs.

Déploiements zéro-downtime

Sous le capot, les mises à jour de StatHall sont désormais déployées en rolling restart (démarrage du nouveau conteneur avant l’arrêt de l’ancien) avec rollback automatique en cas d’échec. Une page Historique des releases dans l’admin trace chaque déploiement.

Documentation enrichie

Trois nouvelles pages produit détaillent les serveurs Unix, le super-dashboard et l’agent push-only. Des guides « Démarrage rapide » ciblent les profils dev mobile, devops et freelance. La page Sécurité est actualisée avec les principes de l’agent.

Renforcement de la posture sécurité

Sauvegardes hors-site quotidiennes chiffrées (rotation hebdo / mensuelle sur 3 mois), maintenance page Traefik affichée en cas d’indisponibilité, historique des déploiements traçable pour faciliter le diagnostic.

---

Comme toujours, ces changements sont déployés progressivement et rétro-compatibles avec vos données existantes. Pas d’action requise de votre part.

Ce qui change pour vous

Un nouveau type de cible : le serveur Unix

StatHall ne se limite plus aux applications mobiles : vous pouvez désormais ajouter vos serveurs Unix à votre cockpit. Un agent léger, installé en une commande, pousse vos métriques système (CPU, RAM, disque), vos événements (services systemd, mises à jour de sécurité APT) et vos logs journald agrégés vers le cockpit — sans jamais ouvrir de port entrant sur votre serveur.

Un dashboard serveur dédié

Pour chaque serveur connecté :

• État de l’agent en temps réel — connecté, silencieux ou hors-ligne.
• Identité système déclarée par l’agent (hostname, distribution, kernel, CPU, RAM, fuseau).
• Métriques système sur 24 h, pré-agrégées par minute côté agent pour rester légères.
• Événements récents (arrêts de service, redémarrages, mises à jour de sécurité disponibles).
• Logs journald regroupés par template avec compteur d’occurrences.

Application mobile : nouvel onglet « Cibles »

L’app mobile compagnon affiche désormais vos applications et vos serveurs côte à côte dans un onglet unifié « Cibles ». Vous pouvez consulter le dashboard serveur en lecture seule depuis votre téléphone — utile pour jeter un œil quand vous êtes loin du bureau.

Pour qui ça change

• Tout le monde : nouvel onglet « Cibles » remplace « Apps » dans l’app mobile (le filtre permet de retrouver la vue app-only).
• Administrateurs : possibilité d’ajouter des cibles serveur depuis la console SPA (page « Admin » → « Serveurs »).
• Aucune action requise côté applications existantes — votre supervision d’apps mobiles continue exactement comme avant.

Sous le capot

• Auth agent par token Fernet opaque, chiffré au repos, lié strictement à un serveur (binding hostname).
• Stockage TimescaleDB + agrégats continus 1 min / 5 min / 1 h pour conserver l’historique léger.
• API mobile passée en v2 (clean cutover, pas de coexistence).
• Plus de 500 tests automatisés ajoutés sur cette livraison.

Ce qui change pour vous

Fini les identifiants techniques dans la carte « Top thèmes »

Juste après sa réparation, la carte « Top thèmes des avis » affichait les identifiants techniques des thèmes (praise, bug, ux, pricing…) au lieu de libellés lisibles.

C’est corrigé : les thèmes s’affichent désormais avec des libellés clairs et traduits — « positif », « performance », « demande de fonctionnalité »… — en français comme en anglais.

Pour qui ça change

Tous les utilisateurs du dashboard d’app. Changement d’affichage uniquement — rien à faire de votre côté.

Ce qui change pour vous

Un score d’adoption basé sur la tendance des utilisateurs actifs

La jauge adoption du dashboard affichait « aucune donnée ». Elle s’appuie désormais sur une vraie mesure : la tendance du nombre d’utilisateurs actifs quotidiens sur les 7 derniers jours, comparée aux 7 jours précédents. Stable, en hausse ou en baisse — vous voyez d’un coup d’œil si l’app gagne ou perd du terrain.

C’est un signal indépendant : il s’affiche à côté du score de santé sans le modifier. Quand l’historique est trop court pour comparer deux périodes, la jauge reste vide plutôt que d’inventer un chiffre.

La carte « Top thèmes des avis » remonte à nouveau des données

La carte qui résume les thèmes récurrents de vos avis — bugs, prix, ergonomie, demandes de fonctionnalités… — était vide pour toutes les apps. Elle est réparée et affiche de nouveau les thèmes dominants avec leur note moyenne.

Pour qui ça change

Tous les utilisateurs du dashboard d’app. Les données apparaissent automatiquement.

Ce qui change pour vous

Le même score, où que vous le regardiez

Le tableau de bord d’une app pouvait afficher un score de santé différent de celui de la liste de vos apps ou de l’application mobile — parfois du simple au double. En cause : le dashboard recalculait sa propre formule de son côté.

Désormais, le score de santé a une source de vérité unique. Le chiffre affiché sur le dashboard d’une app est exactement le même que dans la liste portfolio et sur mobile.

Le score respecte le profil de votre app

Si vous avez défini un profil de santé pour une app (e-commerce, jeu, utilitaire…), le score tient maintenant compte du filtre des avis pertinents : seuls les avis qui parlent réellement de l’app comptent, pas les avis hors-sujet. Une app peut ainsi passer d’une note brute de 3,5★ à une note pertinente de 4,5★.

Un barème de crash un peu moins sévère

La façon de noter le taux de sessions sans crash a été assouplie : environ 1 % de sessions qui crashent ne fait plus basculer une app dans le rouge.

Pour qui ça change

Tous les utilisateurs du web et du mobile. Le recalcul est automatique.

Ce qui change pour vous

Un score de santé plus juste pour les apps installées depuis longtemps

Le score de santé d’une app pénalisait à tort les applications qui tournent depuis des mois. Deux de ses composants comptaient des volumes bruts — le nombre total de crashes connus, le nombre d’avis négatifs — face à des plafonds fixes. Une app avec un historique naturellement large se retrouvait dans le rouge alors qu’elle se portait bien.

Désormais :

• le signal « crash » s’appuie uniquement sur le taux de sessions sans crash — un pourcentage, qui ne dépend pas de l’âge de l’app ;
• les avis négatifs sont comptés en proportion des avis récents, pas en valeur absolue.

Résultat : une app saine affiche un score sain, quelle que soit son ancienneté.

Le statut des anciennes erreurs se met à jour plus fidèlement

Au passage, les erreurs marquées comme résolues côté outil de suivi des crashes sont mieux réconciliées dans StatHall — le statut affiché reflète plus fidèlement la réalité.

Pour qui ça change

Tous les utilisateurs du web et du mobile. Le score se recalcule automatiquement — rien à faire de votre côté.

Ce qui change pour vous

Rien — et c’est voulu.

Cette version pose les fondations techniques de la V2 de StatHall. En coulisses, l’outil a été repensé pour pouvoir superviser, demain, bien plus que des applications mobiles : des serveurs Unix d’abord, puis des bases de données, des sites, des conteneurs — le tout dans le même cockpit.

Vos apps, exactement comme avant

Toutes vos applications, vos connecteurs, vos avis, vos crashes, vos synthèses IA et vos historiques sont inchangés. Aucune action de votre part, aucune reconfiguration : l’interface web et l’application mobile fonctionnent à l’identique. Le travail de cette version est entièrement interne.

Ce que ça prépare

StatHall passe du « cockpit unifié de vos apps mobiles » au cockpit universel de supervision. La prochaine étape, déjà en route : un type de cible Serveur Unix, avec un agent léger à installer en une seule commande.

Pour qui ça change

Pour personne, aujourd’hui. Cette version est une étape de fondation : elle n’apporte pas de nouvelle fonctionnalité visible, elle rend possibles celles qui arrivent.

Au programme

Sprint guidé par une seule question : comment respecter au mieux les utilisateurs et leurs données ? Trois chantiers complémentaires :

1. tu peux transférer la propriété d’une app sans passer par la suppression de ton compte ;
2. le périmètre d’accès des super-administrateurs StatHall est cadré pour s’aligner sur nos engagements RGPD (minimisation + traçabilité
   • notification immédiate) ;
3. petits ajustements de respect au quotidien : footer des emails épuré, message clair côté login quand ton compte est en cours de validation, mise à jour des CGU et de la Politique de confidentialité pour refléter l’ensemble.

Transférer la propriété d’une app

Quand tu n’as plus le temps de gérer une app et que tu veux passer la main à un membre de l’équipe :

• Va sur App · Équipe, puis clique sur Transférer la propriété.
• Choisis un destinataire parmi les co-propriétaires de l’app ou les super-administrateurs actifs.
• Le destinataire devient propriétaire principal et tu conserves un accès co-propriétaire pour ne pas perdre l’app de vue le temps de la passation. Toi et le nouveau propriétaire recevez un email de confirmation.

Le flow historique de transfert avant suppression de compte reste inchangé — l’action est juste désormais accessible en autonomie depuis l’onglet Équipe.

Périmètre d’accès des super-administrateurs

Pour rester en phase avec nos engagements de confidentialité, les super-administrateurs StatHall ne voient désormais que les métadonnées techniques d’une app dont ils ne sont pas membres : nom, slug, connecteurs configurés, statut de synchro. Les données métier — avis utilisateurs, synthèses IA, anomalies, crashs, métriques détaillées — ne leur sont accessibles qu’à l’une de ces conditions :

• ils sont propriétaires de l’app ;
• ils ont été ajoutés comme co-propriétaires ou lecteurs par un membre de l’équipe ;
• ils s’octroient un accès temporaire (1 à 72 heures) pour intervenir techniquement. Dans ce dernier cas, tu reçois un email immédiatement avec la raison saisie et la date de fin de l’accès, et tu peux le révoquer en un clic depuis la fiche de ton app.

Tous les accès temporaires sont tracés dans l’audit de l’app : tu sais qui s’est connecté, quand, pourquoi, et combien de temps.

Forced transfer sur demande d’un tiers (décès, licenciement…)

Quand StatHall doit transférer une app à la demande d’un tiers — un héritier, un service RH après le départ du propriétaire, un support officiel —, le super-administrateur peut désormais joindre un justificatif (PDF, PNG ou JPEG, 5 Mo max) au moment du forced transfer : acte de décès, attestation RH, mandat de représentation, etc.

Le justificatif est :

• facultatif mais fortement recommandé pour matérialiser la preuve de la demande ;
• conservé chiffré au repos pendant 3 ans, aligné sur la rétention des autres événements sensibles ;
• identifié par un hash SHA-256 enregistré dans le journal d’audit, garantissant qu’il ne peut pas être modifié a posteriori sans détection ;
• accessible aux super-administrateurs pour audit. L’ancien propriétaire peut en obtenir copie à tout moment en écrivant à contact@stathall.com — c’est le canal officiel de contestation.

Base légale : intérêt légitime (preuve d’opération, anti-fraude), documenté dans la Politique de confidentialité §2.4.

Emails plus respectueux et plus pro

• Refonte design complète : tous les emails StatHall portent désormais un hero coloré aux couleurs Aurora (dégradé indigo → violet) avec le wordmark et un sous-titre contextuel (« Sécurité », « Synthèse hebdo », « RGPD · Article 15 »…). Une fine bande multi-tons assure la transition vers le contenu, le bouton d’action reste sur la couleur primaire de la marque. Identité visuelle immédiate, qui que soit ton client mail (Gmail, Outlook, Apple Mail, Proton, etc.).
• Footer épuré : on retire le bloc nom + adresse + SIRET de pied de page de tous nos emails. Le seul lien légal qui subsiste est Confidentialité (pour que tu puisses toujours consulter la politique de protection des données depuis l’inbox). La mention d’édition à titre personnel reste accessible depuis les pages légales du site.
• Bloc « offre-moi un café » retiré des emails : on prépare un tier premium et on ne veut plus mélanger les signaux « projet à soutenir » et « service en cours de monétisation » dans la même inbox. Tu retrouves toujours le bouton de soutien dans la sidebar de l’app web et sur la page dédiée du site.

Login plus respectueux

• Message dédié pour les comptes en attente de validation : si tu essaies de te connecter avec un compte dont la demande publique n’a pas encore été validée par un administrateur, tu vois désormais un message clair (« Ton compte est en attente de validation ») au lieu de « Identifiants invalides ». L’erreur n’est dévoilée que lorsque ton mot de passe est correct — aucune information supplémentaire n’est exposée à un attaquant qui tâtonnerait.

Mentions légales mises à jour

• CGU (section 3) : nouveau découpage des rôles d’accès qui reflète la restriction du super-administrateur, ajout d’une section dédiée au transfert de propriété et d’une section dédiée à l’accès temporaire « break-glass ».
• Politique de confidentialité (section 2) : ajout d’une mention explicite sur le principe de minimisation appliqué aux super-administrateurs, des sections dédiées aux transferts de propriété et aux accès temporaires (avec notification immédiate au propriétaire et rétention 30 jours du journal d’audit).

Côté entreprise

• Nouvelle entrée d’audit pour chaque transfert (standalone ou forcé) et pour chaque accès super-administrateur temporaire.
• Le journal d’audit conserve l’historique des accès temporaires pendant 30 jours après leur expiration.
• Pas d’action requise côté propriétaires existants : tes apps gardent leurs configurations, leurs membres et leurs données métier intactes.

Au programme

Sprint d’ergonomie sur l’onglet Historique IA côté web, fiabilisation de la carte Synthèses dans l’Inbox mobile, refonte esthétique des emails transactionnels, alignement de l’ordre des onglets Synthèse IA sur mobile, et mise à jour des mentions légales.

Côté utilisateur — web

• Bouton « Régénérer » sur chaque ligne du tableau de l’Historique IA. Il ouvre la fenêtre de génération avec la période et la portée déjà préremplies. Tu peux relancer une synthèse à l’identique ou changer la portée (iOS, Android, Global) avant de confirmer.
• Bouton « Supprimer » sur chaque ligne, avec une fenêtre de confirmation explicite. La synthèse est effacée définitivement, mais reste régénérable si besoin (tout reste en base côté avis).
• Fenêtre « Générer un rapport manquant » : le voile sombre couvre désormais toute la page (avant, un bandeau restait visible en haut). Au passage, la fenêtre gagne la navigation clavier complète (Tab, Échap pour fermer).
• Messages d’erreur plus clairs : si tu choisis une période sans avis pour la portée demandée, le message explique le cas au lieu d’un cryptique « HTTP 404 ».

Côté utilisateur — mobile

• Inbox plus fiable : seules les synthèses réellement disponibles apparaissent dans l’onglet « Synthèses ». Les tentatives qui n’ont produit aucun contenu (par exemple parce qu’aucun avis n’a été reçu sur la semaine) ne remontent plus comme des cartes vides.
• Carte Synthèse plus lisible : la date et l’heure exactes de génération apparaissent désormais en clair sous le nom de l’app (« 11 mai · 02:00 »), en plus du compteur relatif déjà présent en haut-droite (« 20h »). Plus besoin de calcul mental.
• Fallback de titre : si la synthèse n’a pas de titre généré, la carte affiche « Nouvelle synthèse hebdomadaire » au lieu d’un blanc.
• Onglets Synthèse IA : l’ordre passe désormais à Global · Apple · Google, cohérent avec ce que tu vois côté web. Global reste la portée sélectionnée par défaut.
• Pile Synthèses dans l’Inbox : une seule carte par semaine désormais — qui résume les portées disponibles (« 30 avr. · Global · iOS · Android »). Un tap ouvre l’écran Synthèse IA où tu peux basculer entre les portées via les onglets, comme sur le web. Fini les trois cartes successives partageant la même date qui laissaient croire à un doublon.
• Pile Versions dans l’Inbox : même traitement appliqué aux releases de version. Une version cross-platform (iOS + Android) apparaît comme une seule carte « v1.1.0 » avec deux lignes « iOS · 15 mai » + « Android · 18 mai ». Une version mono-OS reste affichée avec une seule ligne. Un tap ouvre la timeline Versions de l’app.
• Tri ASC/DESC dans l’Inbox : nouveau bouton pill dans l’en-tête (« ↓ Plus récent » / « ↑ Plus ancien »). Tu peux désormais inverser l’ordre du fil pour remonter les éléments les plus anciens en premier. Le défilement infini reste fluide dans les deux sens. Pour les piles fusionnées (Synthèses par semaine, Versions par release), la carte se positionne sur la date la plus récente du groupe, peu importe le sens choisi.
• Inbox plus fluide à la lecture :
  • les Versions sont désormais positionnées dans le fil à leur date de diffusion réelle (celle affichée sur la card), pas à leur date d’ingestion. Une release diffusée il y a 2 mois mais rattrapée récemment ne remonte plus en tête à tort.
  • le défilement vers le bas (chargement des entrées plus anciennes) n’interrompt plus ta position : les nouvelles entrées s’ajoutent en queue sans rebatir toute la liste.
• Fix « tirer pour rafraîchir » qui tournait en boucle : sur l’Inbox et 5 autres listes (Anomalies, Avis, Crashs, Apps, Notifications), le spinner ne s’arrêtait jamais après le pull. Cas réglé — le spinner disparaît dès que la liste est rafraîchie.

Emails — refonte visuelle

• Tous les emails partagent désormais la même charte : header StatHall, signature, lien pour soutenir le projet et mentions légales. Quand un email est facultatif (alerte d’anomalie, synthèse hebdo), un lien « Gérer mes préférences » apparaît en bas — il ne s’affiche pas sur les emails essentiels (validation d’inscription, réinitialisation de mot de passe, etc.).
• Inscription :
  • Le lien d’activation continue d’expirer après 24 h.
  • Les administrateurs reçoivent désormais la notification d’une nouvelle demande après que la personne a validé son email (et non plus à la seconde du formulaire). Moins de bruit dans l’inbox admin, focus sur les comptes réellement en attente.
  • Un email automatique avertit l’équipe lorsqu’une vague d’inscriptions sans validation est détectée.

Mentions légales

Ajout dans la page CGU et dans la Politique de confidentialité :

• Éditeur : Sébastien Soulier, micro-entrepreneur
• Adresse : 12 Rue Georges Brassens, 32600 Lias, France
• SIRET : 10483848700015

Date de dernière mise à jour : 11 mai 2026.

Côté entreprise

Pas d’impact sur le schéma de données. Les actions de suppression de synthèse sont journalisées dans l’audit log comme toute action sensible.

Au programme

Cette version est une passe technique : pas de nouvelle fonctionnalité, mais un alignement complet sur les standards cybersécurité 2026 du web, du mobile et de l’infrastructure.

L’effort a porté sur des fondations qui doivent rester invisibles à l’usage : protocoles de transport, en-têtes navigateur, politiques de cache, gestion des sessions, journaux et télémétrie. Tout cela restera transparent pour vous — la posture est simplement plus robuste.

Côté utilisateur

Aucune action requise. Vos sessions, vos préférences et vos configurations existantes continuent de fonctionner comme avant. Une opération transparente de mise à jour des paramètres de votre compte est appliquée à votre prochaine connexion.

Côté entreprise

Pour les clients on-premise et les responsables sécurité, un audit détaillé est consigné dans la documentation interne. Les standards de cybersécurité applicables à toutes les évolutions futures sont formalisés et appliqués en continu.

Ce qui change pour vous

Le parcours Suppression de mon compte (page Compte → Confidentialité) a été entièrement repensé. Ce sprint apporte 6 améliorations côté sécurité et conformité RGPD.

Nouveau choix : suppression définitive ou anonymisation

Vous pouvez désormais choisir entre :

• Suppression définitive : tout est effacé (profil, préférences, credentials de connecteurs, notes, sessions). Comportement historique. Votre compte disparaît complètement de StatHall.
• Anonymisation : votre email, votre nom, votre mot de passe et vos préférences sont effacés, mais vos contributions (notes rattachées à des apps, anomalies que vous avez acquittées, avis taggés) restent sur la plateforme — sans plus pouvoir vous être attribuées. Utile si vous avez contribué et ne voulez pas effacer vos traces utiles.

Transfert des apps avant suppression

Si vous êtes propriétaire d’une ou plusieurs apps, le wizard vous propose maintenant de transférer l’ownership à un co-owner existant ou à un super-admin avant de fermer votre compte. Plus besoin de supprimer chaque app à la main : vous choisissez un destinataire dans une liste déroulante et un click suffit.

Double authentification pour supprimer

Si la 2FA TOTP est activée sur votre compte, le wizard exige le code 6 chiffres de votre app d’authentification (ou un code de récupération) en plus de votre mot de passe. Empêche un attaquant qui aurait votre password mais pas votre device 2FA d’initier une suppression.

Délai de rétractation 14 jours (au lieu de 30)

La fenêtre pendant laquelle vous pouvez annuler une suppression est réduite de 30 à 14 jours. Aligne sur les pratiques courantes (Apple Account Deletion, GitHub) tout en restant conforme aux recommandations CNIL (7-30 jours).

Compte verrouillé pendant la rétractation + cancel par email

Pendant les 14 jours, vous ne pouvez plus vous reconnecter à votre compte (le login renvoie une erreur dédiée). La rétractation se fait uniquement via le lien envoyé par email lors de la programmation. Cliquez sur le bouton “Annuler la demande” dans le mail — vous arrivez sur une page de confirmation, c’est tout.

Email de confirmation post-effacement

Une fois les 14 jours écoulés et l’effacement effectif, vous recevez un email de confirmation final selon le mode choisi :

• « Votre compte StatHall a été supprimé »
• « Votre compte StatHall a été anonymisé »

Pas obligatoire RGPD, mais courtoisie utilisateur — vous savez avec certitude que la demande a été honorée.

Sous le capot

• 1 migration Alembic ajoutant deux colonnes à la table users : delete_mode (NULL/'delete'/'anonymize') et delete_cancel_token (token aléatoire 256 bits servant au lien email).
• 4 nouveaux endpoints API : transfert candidats, exécution du transfert, suppression avec mode + TOTP, annulation par token public. Endpoint historique d’annulation (auth requise) conservé pour les comptes spéciaux.
• Login guard côté serveur : 403 dédié account_pending_deletion pendant la grace period, exception pour le compte technique de review Apple/Google.
• Audit log structuré : nouvelles actions account.anonymize.executed, account.delete.cancel_by_token, account.delete.transfer_ownership, toutes conservées 3 ans (preuve d’exercice du droit à l’oubli).
• Wizard frontend en 3 étapes (Mode → Transfert → Confirmation), nouvelle page publique /account/cancel-deletion?token=..., traductions FR et EN.
• Mobile : aucun changement (le mobile redirige vers le web pour la suppression depuis rc.19). Versions alignées : mobile + backend + SPA + marketing passent toutes en 1.0.0-rc.24.

Aucune action n’est requise de votre part. Si vous aviez une suppression programmée avant cette release, elle continue de fonctionner normalement avec le comportement historique (suppression définitive, fenêtre 30 jours préservée pour ces cas).

Ce qui change pour vous

Sur les pages Soutenir (sur le site, dans l’app web et dans l’app mobile), les boutons « Partager sur LinkedIn » et « Partager sur X » avaient un look un peu fade — soit du texte nu, soit une icône monochrome générique. C’est corrigé : les boutons arborent maintenant les vrais logos officiels des deux plateformes, avec leurs couleurs de marque exactes :

• LinkedIn : bouton bleu LinkedIn (#0A66C2) avec le logo officiel.
• X : bouton noir avec le logo X officiel (et inversé en blanc sur les thèmes sombres du site web, pour conserver le contraste).

Le bouton mobile affichait aussi « X / Twitter » : on a retiré la mention historique « Twitter », il dit désormais simplement « X » (alignement avec le rebranding officiel de la plateforme).

Aucune autre fonctionnalité ne change — c’est une release purement visuelle.

Sous le capot

• SPA : utilisation du package simple-icons (déjà installé pour les logos des connecteurs depuis V3.S10), aucune nouvelle dépendance. Composant interne <BrandIcon> qui rend le SVG path en fill-current pour respecter automatiquement la couleur du texte du bouton.
• Marketing : SVG inline directement dans le markup Astro (pas de dépendance ajoutée — site statique, bundle minimal).
• Mobile MAUI : 2 nouveaux SVG vectoriels dans Resources/Images/ (logos officiels Simple Icons sous licence CC0), compilés en MauiImage multi-densité par le build.
• Renommages de cohérence : la commande mobile ShareTwitterCommand devient ShareXCommand, l’URL d’intent passe à https://x.com/intent/post (canonique X depuis 2024, l’ancienne URL redirigeait déjà mais autant utiliser la bonne).
• Versions alignées : mobile + backend + frontend SPA + marketing passent toutes en 1.0.0-rc.23.

À noter que la balise <meta name="twitter:card"> reste telle quelle dans le <head> du site — c’est la convention Open Graph standard pour les previews de partage, X la documente toujours sous ce nom-là (la renommer casserait le rendu des aperçus dans les feeds).

Ce qui change pour vous

Cette version est exclusivement consacrée à un renforcement de la sécurité du site et de l’application web, suite à un test d’intrusion externe réalisé le 2026-05-10. Aucune nouvelle fonctionnalité, aucun changement visible dans l’interface — vous ne remarquerez rien au quotidien.

Pourquoi c’est important

Quand votre navigateur ouvre stathall.com, il reçoit une série d’instructions techniques qui définissent ce qu’il a le droit de charger : quels scripts, quelles images, vers quels serveurs il peut se connecter. Sans ces garde-fous, une faille dans une des bibliothèques utilisées par le site pourrait permettre à un attaquant d’injecter du code malveillant.

On a renforcé l’ensemble de ces protections, à la fois sur l’app (stathall.com) et sur le site vitrine (www.stathall.com).

Concrètement

• Politique stricte de chargement des ressources : le navigateur refuse désormais d’exécuter tout script, charger toute police ou se connecter à tout serveur qui n’est pas explicitement autorisé. Seul Cloudflare Turnstile (la protection anti-bot des formulaires de signup et reset password) est autorisé en plus de notre propre domaine.
• Isolation cross-site renforcée : votre onglet StatHall ne peut plus être espionné par un autre onglet ouvert sur un site tiers.
• Plus aucune information sur la version de notre serveur n’est exposée — un attaquant ne peut plus cibler de vulnérabilité spécifique liée à un numéro de version précis.

Sous le capot

• Configuration du reverse-proxy Traefik (qui sert stathall.com + www.stathall.com) enrichie : Content-Security-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, suppression du header Server.
• server_tokens off ajouté aux configs nginx du conteneur app et du conteneur site vitrine.
• Configuration Caddy (utilisée par les déploiements on-premise et l’environnement de dev local) alignée avec les mêmes protections cross-site.
• COEP require-corp non activé : casserait l’iframe Cloudflare Turnstile sur les formulaires d’authentification.
• Versions alignées : mobile + backend + frontend SPA + marketing passent toutes en 1.0.0-rc.22.

À côté de ce sprint, trois actions DNS restent à faire côté Infomaniak (configuration DKIM, nettoyage de TXT obsolètes) — sans impact utilisateur visible.

Ce qui change pour vous

Le bouton « Supprimer mon compte » ne crashe plus

Dans l’app mobile, taper sur Compte → Supprimer mon compte levait jusqu’ici une erreur de navigation. La cause : le nom de route interne entrait en collision avec l’onglet Compte. C’est corrigé — la page de redirection s’ouvre désormais sans erreur, et son bouton « Continuer sur stathall.com » ouvre proprement votre navigateur.

Liste de serveurs au login : retour au glissement seul

L’icône à droite de chaque environnement listé sur l’écran de login s’affichait sur certains téléphones comme un point d’interrogation rouge — la police d’icônes ne mappait pas toujours le glyph corbeille. On a retiré cette icône explicite : la suppression d’un environnement se fait désormais uniquement par glissement vers la gauche (Modifier · Supprimer), comme sur les écrans natifs iOS Settings ou Mail. La consigne est rappelée sous la liste : « Glissez un serveur vers la gauche pour le modifier ou le supprimer ».

Le tap sur la ligne fait basculer vers le serveur, sans ambiguïté.

Suppression de compte : déconnexion immédiate de tous vos appareils

Quand vous supprimez votre compte depuis le site web, toutes vos sessions mobile actives sont désormais invalidées dans la même opération. Avant : un device qui aurait conservé un refresh token pouvait théoriquement continuer à rafraîchir son accès pendant la fenêtre de grâce de 30 jours. Désormais : tous les refresh tokens mobile et tous les devices push sont révoqués en même temps que la programmation de la suppression. Vos apps mobile vous demanderont une nouvelle authentification immédiate, même pendant la grace period.

Cette logique vit dans un seul endroit côté serveur — toute suppression (web aujourd’hui, futurs canaux le cas échéant) déclenche le même comportement.

Sous le capot

• Mobile : route account-delete (à plat) au lieu de account/delete (qui était interprétée comme la section Compte → erreur Shell). XAML inchangé pour l’utilisateur.
• Backend : la révocation des MobileRefreshToken à la suppression a été déplacée du caller vers le service schedule_deletion lui-même. Centralisation : un seul code path à auditer.
• Test pytest dédié couvrant la cascade device + refresh tokens côté SPA.
• Versions alignées : mobile + backend + frontend SPA + marketing passent toutes en 1.0.0-rc.21.

Ce qui change pour vous

Le bouton « Soutenir » est maintenant explicite

Dans les headers d’Inbox et Apps de l’app mobile, le rond gradient avec l’icône café est devenu une pill plus large avec le mot « Soutenir » à côté de la tasse. Plus de doute possible sur ce que fait ce bouton — l’intention est clairement écrite.

C’est exactement la même formulation que le bouton dans la barre latérale du site web.

La suppression de compte n’est plus exposée par l’app mobile (côté serveur)

Suite à la décision rc.19 de rediriger la suppression de compte vers le navigateur web, les endpoints serveur correspondants ont été retirés du backend mobile :

• POST /api/mobile/v1/me/delete → supprimé.
• POST /api/mobile/v1/me/export-request → supprimé.

Cette action est plus qu’un nettoyage cosmétique : le périmètre d’attaque est réellement réduit. L’app mobile ne peut plus, même avec un token compromis, déclencher une suppression de compte ou un export. Ces deux opérations sensibles ne sont accessibles qu’à travers le SPA web (/api/v1/account/delete, /api/v1/account/export) où le parcours dédié est en place avec step-up auth + grace period.

Les rate limits et schémas associés ont aussi été retirés. La console d’audit personnel (GET /me/audit, lecture seule) reste disponible pour l’écran A13 du mobile.

Sous le capot

• Backend : 2 endpoints retirés, ~250 lignes de code mort supprimées dans me.py, schémas MobileDeleteAccountBody + MobileExportRequestResponse retirés, rate limits associés retirés, 6 tests pytest correspondants retirés.
• Mobile : IApiClient.DeleteMeAsync + RequestDataExportAsync
  • record AccountDeleteRequest retirés.
• SPA web : aucun changement — le flow de suppression reste intact dans Mon Compte → Confidentialité & RGPD.
• Versions alignées : mobile + backend + frontend SPA + marketing passent toutes en 1.0.0-rc.20.

Ce qui change pour vous

La suppression de compte se fait sur stathall.com

L’app mobile ne propose plus la suppression de compte directement dans l’app. Quand vous tapez sur Supprimer mon compte dans l’écran Compte, l’app affiche une page d’explication courte puis vous redirige vers stathall.com → Mon compte dans votre navigateur. La suppression effective se finalise là-bas.

C’est une décision de sécurité, pas une régression :

• La suppression d’un compte est irréversible (avec un délai de grâce de 30 jours, mais à terme : irréversible).
• Une action aussi critique mérite un parcours dédié dans le navigateur, où vous avez l’environnement habituel pour vérifier, exporter vos données, ré-authentifier votre identité.
• L’app mobile continue de couvrir tout le reste : profil, préférences, sessions, déconnexion. Seule la suppression finale est déplacée.

Concrètement, sur la page web vous pourrez :

1. Exporter vos données si vous le souhaitez (RGPD article 15 — copie complète de tout ce qui vous concerne).
2. Confirmer votre identité (mot de passe + 2FA si activée).
3. Lancer la suppression — un délai de grâce de 30 jours s’applique avant l’effacement complet, pendant lequel vous pouvez encore changer d’avis.

Conformité

Ce design est explicitement accepté depuis 2022 par les guidelines Apple App Store Review 5.1.1(v) et les exigences Play Store : un lien clairement indiqué vers une page web de suppression remplace l’in-app delete.

Sous le capot

• L’app mobile n’a plus accès à un endpoint de suppression côté backend mobile : ce périmètre d’attaque est retiré.
• Versions alignées : mobile + backend + frontend SPA + marketing passent toutes en 1.0.0-rc.19.

Ce qui change pour vous

Soutenir StatHall directement depuis Inbox et Apps

L’icône café dans un cercle gradient violet apparaît désormais en haut des onglets Inbox et Apps de l’app mobile, à côté de la loupe de recherche. Un tap vous emmène sur la page Soutenir, exactement comme le bouton dédié dans la barre latérale du site web. Plus besoin d’aller dans Compte pour le trouver — il est là où vous regardez naturellement quand vous utilisez l’app.

L’icône utilise désormais l’emoji ☕ standard pour un rendu identique sur iOS et Android, sans dépendre d’une police d’icônes.

Email pré-rempli quand vous changez d’environnement

Quand vous tapez sur un environnement sauvegardé depuis l’écran Setup ou Login et que ce profil est associé à un email (format Production - votre@email.com), l’app pré-remplit automatiquement le champ email sur l’écran de login. Vous n’avez plus qu’à taper votre mot de passe — un geste de moins.

Si vous tapez quelque chose dans le champ avant que l’app ait eu le temps de le pré-remplir, votre saisie est conservée — l’app ne vous écrase jamais.

Changelog public nettoyé

L’historique public sur www.stathall.com/changelog ne liste plus que les versions release-candidate (rc.1 à rc.18). Les versions de développement antérieures (alpha, pré-1.0) ont été retirées : elles documentaient des étapes internes avant le premier déploiement public et n’apportaient rien à un utilisateur final.

Le résultat : un historique chronologique propre, qui démarre au premier déploiement public stathall.com et avance versions par versions sans rupture.

Sous le capot

• Aucun changement backend ou base de données.
• Mobile : nouvelle icône Soutenir avec gestionnaire dans les vues Inbox et Apps. Pas de WebView intégré — les liens externes ouvrent toujours le navigateur système.
• Marketing : l’écran de tri du changelog reste celui de la rc.15 (par date descendante puis numéro de release). 26 fichiers retirés du dépôt, 0 fichier ajouté.
• Versions alignées : mobile + backend + frontend SPA + marketing passent toutes en 1.0.0-rc.18.

Ce qui change pour vous

Soutenir StatHall depuis l’app mobile

L’app mobile gagne une page Soutenir StatHall dans l’onglet Compte, juste au-dessus du bouton de déconnexion. Une carte gradient violet avec une icône café, discrète mais visible — vous ne pouvez pas la rater quand vous ouvrez vos paramètres, sans qu’elle vous coupe dans votre usage.

Tap dessus, vous arrivez sur une page dédiée qui explique :

• À quoi sert votre soutien (infra & hébergement, coûts des modèles IA des synthèses hebdo, temps de développement).
• L’engagement de transparence : aucun palier « premium ». Toutes les fonctions de StatHall restent gratuites et identiques que vous donniez ou non. Votre soutien finance l’existence du service, pas un accès privilégié.
• Une alternative pour ceux qui ne peuvent pas donner : faire connaître StatHall à d’autres devs ou product managers via un partage LinkedIn ou X / Twitter.

Le don passe par Buy Me a Coffee comme sur le site web — donation ponctuelle ou récurrente, à partir de quelques euros. Le bouton ouvre votre navigateur système ; l’app ne touche jamais votre moyen de paiement directement.

Changelog public allégé

Cette release inclut aussi un passage en revue complet des entrées de cette page (rc.1 → rc.16) pour retirer les détails internes qui n’avaient rien à faire en public — chemins de fichiers serveur, noms de modules ou de migrations base, paramètres précis de validation, identifiants d’outillage. Le contenu utilisateur reste intact ; seuls les détails techniques qui auraient pu guider une attaque ont été retirés.

Pour les équipes auto-hébergées

L’option VITE_DONATE_BMC que vous configurez côté SPA continue de fonctionner exactement comme avant. La nouvelle page mobile pointe en dur vers le BMC officiel de StatHall — ce n’est pas configurable per-instance pour le moment (rationale : si vous auto-hébergez, vous n’avez aucune raison d’afficher un bouton de don pour StatHall). Si ce point pose problème pour votre déploiement, ouvrez une issue.

Sous le capot

• Aucune modification backend ou base de données.
• Mobile : nouvelle page Soutenir + carte d’entrée dans l’onglet Compte. Le tap principal délègue au navigateur système pour préserver votre vie privée (aucun WebView intégré).
• Versions alignées : mobile + backend + frontend SPA + marketing passent toutes en 1.0.0-rc.17.

Ce qui change pour vous

Vos appareils mobiles, gérables aussi depuis le navigateur

Jusqu’à rc.15, la liste « Appareils connectés » n’était accessible que dans l’app mobile (Compte → Appareils). Si vous perdiez votre téléphone, ou si vous vouliez vérifier vos sessions ouvertes depuis votre poste de travail, vous deviez sortir votre device — un peu paradoxal.

Désormais, app.stathall.com → Mon compte → Sécurité affiche la même liste exactement, avec :

• L’icône Apple ou Smartphone selon la plateforme.
• Le nom personnalisé de l’appareil (« iPhone de Sebastien »).
• Le sous-titre combiné OS · modèle (« iOS 26.4 · iPhone16,1 »).
• Le temps relatif depuis la dernière activité (« Vu il y a 2 min », « Vu hier », « Vu 3 j »…).
• Un bouton Révoquer par appareil, avec confirmation inline (titre + description du risque + boutons Confirmer/Annuler).

Quand vous révoquez un appareil, sa session devient invalide immédiatement, plus aucune notification ne peut l’atteindre, et l’utilisateur doit se reconnecter pour retrouver ses données.

C’est exactement le même flux que sur mobile, accessible désormais des deux côtés.

Description du groupe Sécurité élargie

Le groupe Sécurité dans Mon Compte mentionne désormais « Double authentification (2FA), codes de secours et appareils connectés » au lieu de « Double authentification (2FA) et codes de secours », pour refléter le nouvel écran.

Ce qui change pour vous

La dernière release apparaît bien en premier

Sur la page /changelog, plusieurs versions publiées le même jour (rc.6 à rc.15 toutes datées du 10 mai 2026) pouvaient apparaître dans le mauvais ordre — rc.9 remontait au-dessus de rc.14.

Désormais, le tri considère le numéro de release-candidate quand plusieurs entrées partagent la même date de publication. La version la plus récente est toujours en haut, peu importe la cadence des releases sur une même journée.

Ce qui change pour vous

La liste « Appareils connectés » devient lisible

Avant rc.14, chaque appareil de la liste Compte → Appareils connectés affichait son nom suivi de trois lignes brutes : la plateforme en minuscules (« ios »), une date au format 10/05/2026 12:22, et un lien rouge « Révoquer » sans encadrement. Difficile de retrouver son iPhone d’un coup d’œil quand on a plusieurs sessions.

Désormais, chaque carte affiche :

• Une pastille indigo de 44 × 44 pt avec l’icône Apple ou Smartphone selon la plateforme — repère visuel immédiat.
• Le nom de l’appareil en titre, gras.
• Un sous-titre combiné « OS · modèle » (ex. « iOS 26.4 · iPhone16,1 ») — vous voyez la plateforme et le modèle exact en un seul regard.
• Un temps relatif (« Vu il y a 2 min », « Vu hier », « Vu 3 j »…) au lieu d’une date absolue à décoder.
• Le badge « Cet appareil » clairement positionné en haut à droite quand c’est la session actuelle.
• Un bouton Révoquer encadré en rouge plutôt qu’un simple lien — l’action destructive est visuellement reconnaissable.

L’espacement entre cartes passe à 10 pt pour respirer, et le message d’état vide est mis à jour pour refléter la rc.12 (l’app enregistre désormais l’appareil au login automatiquement, plus besoin d’autoriser les push avant qu’il apparaisse).

Ce qui change pour vous

Sessions stockées : validation défensive

L’app utilise vos identifiants de session stockés en local pour renommer automatiquement vos profils serveur avec votre email. Avant rc.13, la lecture ne vérifiait pas la cohérence des données — c’était sûr en pratique mais pas robuste contre une corruption de stockage ou un cas pathologique.

Désormais, plusieurs contrôles structurels sont appliqués avant toute utilisation : si l’un échoue, l’app garde le nom historique du profil au lieu de l’altérer avec une donnée invalide.

Changelog complété rc.7 → rc.11

Le site marketing affichait jusqu’à présent uniquement les versions rc.6 et rc.12 — toutes les itérations intermédiaires (rc.7 à rc.11) ont été ajoutées au changelog public, en français et en anglais. Vous pouvez maintenant retracer l’historique complet de l’app mobile, de la pile dépliable Inbox (rc.7) au refactoring complet de la gestion de serveurs (rc.11).

Ce qui change pour vous

Votre iPhone apparaît dans « Appareils connectés » même sans push

Avant rc.12, votre device n’apparaissait dans Compte → Appareils qu’après avoir accordé la permission notifications iOS / Android. Si vous l’aviez refusée ou simplement pas encore vue, la liste restait vide alors que vous étiez bien connecté. Désormais, l’app enregistre votre device dès le login, avec ou sans permission push : vous voyez toujours votre install dans la liste, et les notifications s’activent automatiquement le jour où vous accordez la permission.

L’appareil courant est en plus reconnu comme tel — utile pour la gestion multi-devices et pour ne pas se déconnecter par erreur du device sur lequel on est en train de faire le ménage.

Sécurité durcie

• Validation des liens : un lien ouvrant l’app est désormais accepté uniquement s’il pointe sur un domaine connu (le SaaS ou un environnement self-host enregistré).
• Révocation propre du device au logout : votre session mobile est invalidée côté serveur en même temps que votre déconnexion ; plus aucune notification ne peut atteindre un device dont vous vous êtes déconnecté.
• Diagnostics envoyés à Sentry : les emails et identifiants techniques présents dans les traces sont automatiquement masqués avant l’envoi.

Stabilité

• Plusieurs handlers UI qui pouvaient s’arrêter silencieusement en cas d’erreur sont désormais tracés sans interrompre l’app.
• Les composants qui s’abonnent à des événements globaux se désabonnent proprement à leur destruction → fin des fuites mémoire après plusieurs navigations entre Inbox / Apps / Compte.

Standards iOS HIG / Material 3

• Tap targets bumpés à 48 dp sur Android (vs 44 pt iOS, inchangé) pour respecter Material Design 3.
• Marges de safe area appliquées sur les écrans de détail manquants — plus de contenu qui passe sous la Dynamic Island ou sous l’encoche Android.
• Hiérarchie sémantique des titres ajoutée (Inbox, Apps, Compte) pour que VoiceOver / TalkBack annoncent correctement la structure de la page.

Versions alignées sur tout le stack

Cette release réaligne mobile + backend + frontend SPA + site marketing sur la même version 1.0.0-rc.12. Plus de décalage entre l’app et le service.

Ce qui change pour vous

Suppression depuis l’écran Setup pré-auth

Avant rc.11, la suppression d’un environnement était possible uniquement depuis le login (avec un compte actif) ou depuis Compte → Serveurs (post-auth). Si vous arriviez sur l’écran Setup initial avec plusieurs profils existants, vous ne pouviez pas faire le ménage avant de vous connecter.

Désormais, la liste « Continuer avec un serveur existant » de l’écran Setup expose le même swipe-to-delete que les autres écrans — glissez vers la gauche pour révéler le bouton Supprimer rouge, avec confirmation. Si c’est le dernier profil restant, l’app propose un Tout réinitialiser qui efface tout et vous renvoie sur l’écran Setup vide.

Liste de serveurs au design propre (style iOS Settings)

L’écran Compte → Serveurs est revu pour ressembler aux Réglages iOS natifs : conteneur arrondi unique, lignes plates avec séparateurs, hauteur minimum confortable par ligne. Le swipe gauche révèle Modifier (indigo) et Supprimer (rouge) en mode standard slide-over (pas d’auto-execute sur full swipe). Plus d’éclats de couleur ni de coins arrondis qui clippent mal pendant le drag.

Renommage automatique des profils existants

Si vous aviez plusieurs profils créés avant la rc.9 (donc sans suffixe email dans leur nom), ils étaient bloqués sur leur nom historique. Désormais, à chaque ouverture de l’écran login, l’app détecte le compte associé à chaque profil et renomme automatiquement en "{base} - {email}".

Ça marche pour stathall.com comme pour tout serveur custom (« Test » sur localhost, environnements on-premise, etc.). Le renommage est idempotent : si le suffixe est déjà présent, l’app ne fait rien.

Ce qui change pour vous

Une icône 🗑 visible sur chaque serveur

Le swipe-to-delete livré en rc.9 fonctionnait, mais beaucoup d’utilisateurs ne devinaient pas qu’il fallait glisser pour révéler l’action. Désormais, chaque profil non-actif de la liste « Basculer vers un autre serveur » affiche une icône corbeille rouge de 44 × 44 pt à droite — tap pour confirmer et supprimer. Le swipe reste disponible en bonus, mais l’action est immédiatement visible pour tout le monde.

« Gérer les serveurs » comme entry point principal

Le bouton « Modifier le serveur » sous le bloc actif devient « Gérer les serveurs » — son action sheet contient :

• Continuer avec stathall.com (si pas encore configuré)
• Modifier le serveur courant
• Ajouter un environnement
• Gérer les serveurs (nouveau) → ouvre la page complète Compte → Serveurs avec CRUD complet, possibilité de supprimer le profil actif après bascule, ou tout réinitialiser.

Le hint sous la liste est ré-écrit pour expliciter les 3 chemins : « Tape une ligne pour basculer · 🗑 pour supprimer · Modifier le serveur → Gérer les serveurs pour la liste complète ».

Ce qui change pour vous

Plus de profils « Production » qui s’empilent

Si vous tapiez plusieurs fois sur Continuer avec stathall.com depuis l’écran de login (par exemple parce que vous aviez réinstallé l’app), un nouveau profil « Production » apparaissait à chaque fois, toujours avec la même URL — au final, la liste « Basculer vers un autre serveur » devenait illisible.

Désormais, après chaque login réussi, votre profil actif est automatiquement renommé « Production - votre@email.com », et tout profil avec le même URL et le même email est consolidé. Si vous vous reconnectez avec le même email, le profil existant est réutilisé au lieu d’en créer un nouveau.

Si une autre personne se connecte au même serveur depuis le même device (cas rare en pratique, mais courant en QA), elle obtient son propre profil distinct — pas de collision.

Swipe-to-delete sur la liste de serveurs depuis le login

La liste « Basculer vers un autre serveur » de l’écran login expose désormais les mêmes actions que la page Compte → Serveurs : glissez vers la gauche sur une ligne pour révéler Modifier (indigo) et Supprimer (rouge) avec confirmation. Aucun besoin d’aller dans Settings pour faire le ménage.

Ce qui change pour vous

Le bouton retour fonctionne toujours

Avant rc.8, certains chemins retour pouvaient laisser l’app figée sur un écran d’erreur — typiquement quand vous reveniez depuis une notification push ou un deep-link vers le détail d’une anomalie. Cette release rend la navigation back robuste sur l’ensemble de l’app, avec un fallback explicite vers l’onglet d’origine. Plus de freeze, plus d’écran mort.

Inbox : plus de saut pendant le chargement

Quand vous scrolliez dans l’Inbox au moment où la pagination chargeait de nouveaux items, votre position de scroll pouvait sauter en haut de la liste. Désormais, votre position reste stable même si la source change pendant que vous lisez.

Accessibilité aux standards Apple HIG / Material Design

• Les boutons icônes (recherche, paramètres, retour) passent au minimum recommandé par Apple (« Touch Targets ») et Material 3 (« Accessibility »).
• Les labels et descriptions sémantiques sont enrichis pour que VoiceOver / TalkBack annoncent correctement chaque action.

Roadmap : le rendu Gantt arrive

L’écran Roadmap d’une app affiche désormais les phases DEV / TNR / REL en barres colorées proportionnelles, avec une ligne rouge verticale marquant l’instant courant — vous voyez d’un coup d’œil où en est chaque version.

Settings : Serveurs et Appareils, deux pages dédiées

Avant, Compte → Paramètres mélangeait tout. Désormais, Serveurs (gestion des environnements stathall.com / on-prem) et Appareils connectés (devices avec push) ont chacun leur page dédiée, avec swipe-to-delete et confirmation native.

Versions : auto-détection de plateforme

Sur l’écran Versions d’une app, si vous n’avez configuré que iOS ou que Android, l’app détecte automatiquement la plateforme avec des données et bascule dessus à l’ouverture. Le toggle iOS/Android est grisé pour la plateforme vide.

Synthèse IA : historique navigable

L’écran Synthèse IA d’une app affiche désormais en bas une rangée horizontale des synthèses passées — tap pour relire n’importe laquelle des dernières synthèses. Plus besoin d’aller chercher dans le navigateur web.

Ce qui change pour vous

Pile dépliable dans l’Inbox

Quand vous suivez plusieurs apps, l’Inbox pouvait devenir bavarde — chaque app génère sa synthèse hebdo et déclare ses nouvelles versions, ce qui pouvait noyer les vraies anomalies. Désormais, les synthèses et versions de la même app se regroupent automatiquement sous une ligne unique « 3 mises à jour · App X » que vous tapez pour déplier.

Les anomalies ne sont jamais regroupées : elles restent visibles individuellement parce que c’est sur elles que vous devez agir vite.

Nettoyage UX

L’onglet Apps retire le segmenté « Portfolio » qui n’apportait rien sur petit écran : on liste directement vos apps avec leur badge de santé, sans onglet supplémentaire à choisir.

Cette release inclut aussi des correctifs internes pour fluidifier les déploiements iOS sur les versions récentes du système.

Ce qui change pour vous

Une app mobile repensée autour de votre Inbox

L’app StatHall pour iOS et Android passe de cinq onglets à trois : Inbox · Apps · Compte. L’Inbox devient l’écran d’atterrissage et agrège dans un seul fil ce qui mérite votre attention sur toutes vos apps : anomalies, synthèses IA et versions détectées. Vous filtrez par type avec une rangée de chips, vous swipez pour acquitter en deux taps, et vous changez de scope (toutes les apps / une app spécifique) via une bottom sheet avec recherche.

L’onglet Compte rassemble enfin profil, préférences, sécurité & RGPD et support en quatre cartes claires.

Vos liens StatHall ouvrent l’app native quand elle est installée

Quand vous recevez une URL StatHall par e-mail, Slack ou SMS — du type https://app.stathall.com/apps/mon-app/anomalies/123 — votre téléphone ouvre directement l’app native si elle est installée, sur la bonne anomalie, sans passer par le navigateur. Sinon, la page web s’affiche normalement.

C’est ce qu’Apple appelle les Universal Links et Google les App Links. Aucune action de votre part : ça fonctionne dès l’installation de l’app rc.6 sur votre device.

Un score de santé visuel par app

L’écran de détail d’une app affiche désormais un HealthGauge circulaire qui résume sa santé globale, avec trois sous-scores détaillés en barres de progression : technique (crashs, ANR, performance), business (notes, avis, revenus pour les apps payantes), adoption (téléchargements, MAU, rétention). Vous identifiez en deux secondes ce qui plombe la note d’une app.

Timeline des versions et roadmap, en mobile

Deux nouveaux écrans accessibles depuis le détail d’une app :

• Versions — timeline iOS/Android avec les dates de release et les deltas de crash-free entre versions consécutives.
• Roadmap — vue Gantt swimlane (DEV / TNR / REL) en lecture seule pour suivre les jalons à venir sans ouvrir le web.

Notifications push mieux gérées

Un nouvel écran Notifications liste tous les push reçus avec horodatage et statut « lu / non lu ». Si les notifications système sont désactivées au niveau de l’OS, un bandeau inline vous rappelle d’ouvrir les Réglages — vous ne ratez plus une alerte critique parce que l’autorisation a été refusée par mégarde.

Pour qui ça change

Tous les utilisateurs de l’app mobile StatHall sur iOS et Android recevront la mise à jour rc.6 via TestFlight (iOS) et Internal Testing (Play Store). Aucune migration côté serveur n’est requise de votre part — les nouveaux écrans sont alimentés automatiquement.

Côté web, aucun changement visible cette fois : rc.6 est un sprint 100 % mobile.

Limites connues

• L’écran Roadmap sur mobile est en lecture seule — pour ajouter ou éditer une version, ouvrez l’app web.
• Les Universal Links s’activent côté serveur dès que les identifiants de signature iOS et Android sont configurés. Si vous voyez un lien s’ouvrir dans Safari/Chrome au lieu de l’app, c’est que le device n’a pas encore re-téléchargé le fichier d’association (Apple le rafraîchit toutes les 24 h).

Ce qui change pour vous

Vos crashs Android, même sans Crashlytics

StatHall remonte désormais les crashs Android directement depuis Play Vitals (la console qui alimente la fiche Play Store). Tous les utilisateurs avec un connecteur Google Play actif voient apparaître automatiquement les clusters d’erreurs (crash + ANR + non fatal) dans l’onglet Crashs, sans rien ajouter ni configurer.

Côté iOS, l’écosystème Apple ne propose pas d’API équivalente — vous restez sur Sentry ou Crashlytics pour les détails iOS.

Un seul clic pour ouvrir la console source

Chaque issue de crash gagne une icône externe à droite du titre. Un clic vous emmène directement sur la page de l’issue dans Sentry, Firebase Console ou Play Console — exactement la même issue, ouverte dans l’outil que vous utilisez pour la corriger.

L’URL est construite à partir des informations déjà saisies dans le connecteur. Pour la Play Console, un nouveau champ optionnel « Identifiant développeur Play » est apparu dans le formulaire Google : c’est le numérique visible dans l’URL de votre console. Sans, tout le reste fonctionne, on masque juste l’icône Play.

Crashlytics + Play Vitals : une seule ligne par crash

Quand le même crash Android est remonté à la fois par Crashlytics et par Play Vitals, StatHall fusionne automatiquement les deux lignes en une seule. La ligne canonique reste celle qui a le plus d’occurrences ; vous voyez les deux icônes externes côte à côte pour basculer d’un outil à l’autre, et un petit badge « Corrélé » explicite le rapprochement.

Le matching repose sur deux étapes : un match exact sur le titre normalisé, puis un fallback sur la similarité sémantique pour les cas où les libellés divergent.

Quatre badges pour aller à l’essentiel

Chaque crash issue peut maintenant porter quatre badges visuels distincts :

• Nouveau — issue vue pour la première fois ces 7 derniers jours.
• Régression — issue qui avait été résolue puis qui est réapparue. Information remontée directement depuis Sentry.
• Pic — volume d’occurrences récent significativement au-dessus de la moyenne 14 jours. Détection automatique avec hystérésis pour éviter les faux clignotements.
• Premier vu en vX.Y.Z — issue apparue avec votre version la plus récente. Premier signal d’une potentielle régression liée à la release.

Les badges sont conçus pour que vous repériez d’un coup d’œil ce qui mérite votre attention dans une longue liste de crashs.

Petits nettoyages d’interface

• L’ancien onglet « Accès » dans les paramètres d’une app a été supprimé : il faisait double emploi avec « Équipe », qui couvre tout (membres, invitations, rôles viewer/co-owner) depuis une seule vue.
• Le bouton « Ajouter une version » apparaissait trois fois sur la roadmap (en-tête, toolbar du Gantt, état vide). On a retiré le doublon de la toolbar du Gantt — il reste une seule occurrence visible quand vous regardez votre roadmap.

Pour qui ça change

Toute équipe qui a un connecteur Google Play actif. Les crashs Play Vitals apparaissent automatiquement à la prochaine synchronisation. Les badges et les deep-links sont visibles dès le premier rafraîchissement de l’onglet Crashs.

Si vous voulez activer le lien direct vers la Play Console sur les crashs, ouvrez Sources → Google → Identifiant développeur Play et collez le numérique extrait de l’URL de votre console.

Limites connues

• iOS reste asymétrique : Apple n’expose pas d’API publique stable pour les crash issues détaillées. Pour les crashs iOS, on s’appuie sur Sentry ou Crashlytics.
• L’API Play Vitals n’expose pas la notion de régression côté Google. Le badge « Régression » ne s’allume donc que sur les issues remontées par Sentry pour le moment.

Patchs livrés dans la journée

Plusieurs ajustements ont été déployés en prod le 6 mai dans la foulée du tag rc.4 initial — tous portent encore le tag rc.4 :

• Modifier juste le quota mensuel ou le modèle préféré sans re-saisir la clé API marche désormais. Avant : impossible d’enregistrer si la clé n’était pas re-tapée. Après : la clé reste optionnelle en édition, le serveur conserve la clé chiffrée existante.
• Carte Clé LLM simplifiée : suppression du bouton “Modifier” devenu redondant, l’œil de révélation n’apparaît qu’après saisie d’au moins un caractère, placeholder enrichi (« •••• xxxx — laisse vide pour conserver la clé existante »).
• Toggle Synthèse hebdo persiste désormais après refresh. Anciens comptes (qui avaient une fréquence héritage) restent actifs automatiquement.
• Défaut pré-génération automatique passé à dimanche 23:59 UTC (au lieu de lundi 00:00 UTC) — sémantique cohérente : le rapport est généré juste avant minuit le dimanche soir et couvre la semaine qui vient de se terminer (lun→dim).
• Légende “Comment ça marche” réécrite pour expliciter la fenêtre couverte avec deux exemples concrets, plus de référence vague à la “config par défaut”.
• Confirmation visuelle “Enregistré” sur tous les boutons Save user-facing — une pill verte qui auto-cache après 2.5s.

Ce qui change pour de vrai

Synthèse IA — pré-génération automatique paramétrable par app

• Le token LLM appartient désormais à l’app, pas à l’utilisateur. Avant : chaque utilisateur devait poser sa propre clé API DeepSeek ou OpenAI dans son compte ; en pratique, dans une équipe, soit personne ne le faisait, soit une seule personne le portait individuellement. Désormais : la clé se configure une fois par l’owner de l’app, dans les paramètres de l’app → onglet IA. Elle est masquée par étoiles (vous ne reverrez jamais la clé en clair après l’avoir saisie), avec un bouton « Tester la connexion » pour valider l’authentification avant le premier cycle.
• Pré-génération automatique hebdomadaire configurable au niveau de l’app : toggle on/off, jour de la semaine + heure UTC, et cases à cocher pour les portées générées (Global, iOS, Android — vous choisissez librement les combinaisons). La fenêtre couverte est les 7 jours pleinement écoulés avant la génération (par défaut, lundi 00:00 UTC à dimanche 23:59 UTC). Plus besoin que quelqu’un pense à cliquer « Générer » chaque lundi matin.
• Coût estimé affiché directement dans l’écran de configuration de l’auto-génération : nombre d’appels LLM par cycle + cumul utilisé ce mois sur le quota déclaré. Vous savez ce que vous payez avant d’activer.
• Plus de génération manuelle pour les utilisateurs. L’écran de consultation de la synthèse devient une vue de lecture pure : on y navigue les rapports déjà pré-générés, on n’en déclenche plus.

Lecture des synthèses — UX clarifiée

• Compteur de jours explicite sur la sélection de période : « Du 20/04/2026 au 26/04/2026 inclus = 7 jours ». L’inclusivité du second jour est matérialisée dans le texte pour éviter l’ambiguïté qui faisait croire qu’une plage 20→26 ne couvrait que 6 jours.
• Snap automatique sur le rapport pré-généré le plus proche. Quand vous choisissez une plage qui ne correspond exactement à aucun rapport pré-généré, un bouton « Aller au rapport le plus proche » apparaît avec un message clair, sans surprise silencieuse.
• Empty states plus parlants : les semaines sans avis sont rendues comme « Pas d’avis cette semaine » plutôt qu’une page blanche.

Préférences email — toggle simplifié

• L’utilisateur ne choisit plus le jour d’envoi de la synthèse hebdo. Le jour est imposé par la configuration de pré-génération de chaque app — c’est cohérent : on envoie le digest dès que le rapport est prêt. L’utilisateur garde un toggle yes/no pour s’abonner ou se désabonner par app.
• Les anciennes clés API du compte sont marquées comme dépréciées via un bandeau d’avertissement explicite. Vous pouvez les supprimer en un clic depuis votre compte ; elles n’ont plus aucun effet sur les synthèses depuis cette release.

Historique IA pour les administrateurs

• Nouvel onglet « Historique IA » dans les paramètres d’une app (super-admin uniquement). Tableau paginé de toutes les tentatives de génération — succès, semaines vides, clés manquantes, erreurs fournisseur ou quotas dépassés. Chaque ligne montre la date, la période couverte, la portée, l’origine (auto / manuel admin), le statut, le nombre d’avis et le coût réel.
• Bouton « Générer un rapport manquant » : permet à un admin de combler un trou (panne LLM, quota dépassé une semaine, clé absente au moment du cycle) sans rejouer le rapport déjà publié. Le rapport généré est marqué « manuel admin » dans l’historique pour traçabilité.

Performance — Dashboard et liste d’apps plus rapides

• Dashboard d’une app : le widget « Top thèmes 30j » est significativement plus rapide à charger sur les apps à fort volume d’avis. Gain attendu : -40 à -60 % sur la latence de chargement.
• Liste admin des apps : la requête « date du sync le plus ancien » est désormais agrégée en une seule passe au lieu d’une par app. Gain : -20 à -30 % sur la latence de la liste, proportionnel au nombre d’apps.
• Cache navigation : les écrans dashboard et liste portfolio gardent leurs données en cache 60 secondes (au lieu de 30 s) et 5 minutes en mémoire après changement d’écran. Plus de refetch redondant quand vous naviguez d’un onglet à l’autre.

Migration

• Aucune recopie automatique des clés LLM existantes du niveau utilisateur vers le niveau app. C’est une décision projet : on veut forcer un geste explicite de l’owner pour confirmer quelle clé est utilisée pour quelle app. Les apps sans clé app-level n’auront pas de synthèse pré-générée jusqu’à reconfiguration.
• Outil d’audit côté admin pour lister, par app, son owner et l’état de configuration des clés. Permet de notifier les bons owners post-deploy en quelques minutes.

Pour qui c’est important

Toute équipe qui utilisait jusqu’ici la synthèse IA. Avant la rc.4, le coût LLM reposait sur la clé d’une seule personne dans l’équipe, et la génération devait être déclenchée manuellement chaque semaine. Après : le coût se gère au niveau de l’app, la génération tourne toute seule le jour configuré, et l’équipe découvre le rapport en ouvrant l’écran.

Ce qui arrive ensuite

• Suppression effective des clés legacy au niveau utilisateur : livrée le même jour en rc.4.1.
• Cadence configurable au-delà de l’hebdo (bi-hebdo / mensuel) si des utilisateurs en font la demande.
• Génération à la demande pour les owners (pas seulement les super-admins).

Ce qui a bougé pour de vrai

Dashboard app — chargement nettement plus rapide

• Le tableau de bord d’une app ne charge plus les KPIs de toutes les autres apps de l’espace de travail pour en garder un seul. Avant : ouvrir le dashboard exécutait pour chaque app du workspace plusieurs requêtes inutiles puis filtrait côté application — la latence augmentait linéairement avec le nombre d’apps. Désormais : le filtre est appliqué côté base, on ne calcule que pour l’app demandée.

Scraper Play Store — 5 marchés → 16 (Amériques, Europe, DOM-TOM)

• Plus de marchés Play Store interrogés à chaque backfill pour capter les avis exclusifs aux storefronts régionaux (un avis posté depuis le Brésil ne remonte pas forcément dans le feed français ou américain). Couverture désormais : Europe (FR, GB, DE, ES, IT, NL, PL, PT) + Amériques (US, CA, BR, MX) + DOM-TOM (Guadeloupe, Martinique, Réunion, Guyane). L’Océanie est volontairement exclue.
• Pas de gain de profondeur temporelle : Google plafonne le feed public à environ 6 semaines, indépendamment du marché. C’est l’unique raison pour laquelle on n’a pas tout l’historique Android comme on l’a côté Apple.
• Pas de doublons malgré la multiplication des marchés : un avis vu dans un premier marché n’est pas re-traité quand le scraper passe au suivant.
• Compteur du backfill rectifié : la carte « Jobs récents » affichait jusqu’ici le nombre de fetchs (gonflé par les ré-itérations cross-marché du même avis). Elle reflète maintenant le nombre d’avis vraiment ajoutés à la base — cohérent avec le compteur affiché sur la carte « Avis Android » du dashboard.

Tagging des avis — fini les faux « bug » sur les plaintes de stock

• Le tagger ne confond plus le monde réel et l’application. Avant : un avis « rupture de stock pendant des jours » se voyait étiqueté bug + perf + UX. Après : si le texte ne parle pas de l’app, les pills bug / ux ne s’allument plus.
• Trois nouveaux labels métier pour les apps retail / livraison / restauration : stock (rupture, indisponibilité), livraison (délai, livreur, retrait magasin) et SAV (service client, support, accueil en boutique). Affichés dans une famille séparée « Hors app », visuellement distincte (pill ardoise).
• Suppression contextuelle des faux positifs résiduels : si un label métier domine clairement les labels applicatifs, les pills app faiblement scorées disparaissent automatiquement.
• Profil santé e-commerce durci : les avis tagués stock / livraison / SAV sont désormais explicitement exclus du score de santé business. La santé business e-commerce reflète vraiment la qualité applicative, pas les frictions du monde réel.
• Retag des avis existants : un admin peut réappliquer les nouvelles règles à l’historique en une commande. Sinon, le backfill quotidien ne touche que les avis nouvellement ingérés.

Dashboard app — première vue plus dense, plus rapide à lire

• Card « Note moyenne » étoffée : le grand chiffre 7j s’accompagne désormais de 2 baselines à droite — la moyenne 30j (signal moyen terme) et la moyenne globale calculée sur l’ensemble des avis présents en base. Sous chaque chiffre, le compteur d’avis (n=…) explicite la fragilité statistique du 7j sur les apps à faible volume — moins de 5 avis et la valeur 7j passe en gris.
• Quatre nouveaux widgets sur le tableau de bord :
  • Réponses 30j — pourcentage d’avis qui ont reçu une réponse de l’équipe support.
  • Dernière release — date relative par platform iOS / Android, badge ⚠ si plus de 90 jours sans release. Détecte les apps qui glissent dans la dormance.
  • Anomalies ouvertes — grille compacte P0 / P1 / P2 des anomalies encore en cours.
  • Top thèmes des avis (30j) — les 8 thèmes les plus récurrents avec la note moyenne par thème. Permet de voir d’un coup que « payment » est à 4.2★ pendant que « crash login » est à 1.8★.
• Layout réorganisé par lecture : santé → notes → adoption proxy → qualité reviews → tech / ops. Gain de scroll d’environ 40 %.

À venir au prochain sprint

• Utilisateurs actifs par version × OS avec pondération de l’impact (une régression sur une version à 1 % d’adoption pèsera moins lourd qu’une régression sur la version majoritaire). Reporté pour valider chaque source de données dans une fenêtre dédiée.

Backfill Google Play — bucket retiré

• Le bucket Google Cloud Storage disparaît du connecteur Google Play. Avant : il fallait provisionner et autoriser un bucket côté Play Console, copier son nom dans la fiche connecteur — en pratique presque personne n’arrivait à passer cette étape. Désormais : aucun bucket à configurer.
• Avis historiques : récupérés depuis la fiche publique Play Store, sur cinq marchés (FR, US, DE, ES, IT) en parallèle, avec déduplication automatique. Sur backfills répétés, on s’arrête dès qu’on retombe sur un avis déjà présent en base.
• Téléchargements historiques : remontés depuis l’API officielle Google, avec environ 1 an d’historique disponible. Même service account, zéro nouvelle permission à donner.
• Doc connecteur réécrite. Le guide d’installation Google tient désormais en trois étapes au lieu de cinq.

Pour qui c’est important

Toute personne qui essaie de rapatrier l’historique d’une app Android dans StatHall. Avant la rc.3, l’écran « Bucket GCS » bloquait littéralement le démarrage. Désormais, dès que le service account est validé, les imports historiques sont disponibles dans l’onglet Synchronisation sans configuration supplémentaire.

Limites assumées

• Le scrape des avis publics récupère ce que le Play Store expose publiquement (typiquement quelques milliers d’avis récents par marché). Pour les apps avec un très long historique, le tail ancien n’est plus rapatriable.
• L’historique des installs est borné à environ un an par l’API officielle. Antérieur impossible côté Google.
• Le scraping est un mécanisme best-effort — Google peut le couper sans préavis. La voie officielle reste l’unique source garantie pour les avis ≤ 7 jours.

Ce qui a bougé pour de vrai

• Fix « Jamais connecté » sur les comptes créés via invitation. Quand un nouvel utilisateur acceptait une invitation et créait son mot de passe inline, son compte apparaissait bien dans la liste admin mais avec « Jamais connecté » dans la colonne dernière connexion — alors qu’il venait juste de finir son onboarding et avait une session active. La date d’acceptation est désormais enregistrée comme première connexion, cohérent avec le login normal.
• Le test de connexion répond enfin. Quand vous cliquiez sur Tester la connexion dans la fiche d’un connecteur (Sentry, Apple, Google, Firebase) et que ça échouait, l’écran restait vide — aucun message, aucun signe que la requête avait été envoyée. Désormais une bandelette rouge apparaît systématiquement avec la cause : identifiants invalides, réseau coupé, erreur serveur, ou rate-limit.
• Le bouton Installer ne ferme plus la fiche en silence. Si l’enregistrement des credentials échoue, la fiche reste ouverte avec une bannière d’erreur explicite.
• Plus de faux warning « Package Android manquant ». Le formulaire Google Play affichait ce message à tort, même quand le package était bien renseigné à l’étape précédente. La chaîne entre les identifiants de l’app et le formulaire est réparée.
• Hotfix rate-limit silencieux. Une exception non capturée renvoyait des 500 silencieux sur certains appels rate-limités. Corrigé.
• Onglet Sources > Avancé clarifié. Les deux cartes (Google Play et Apple App Store Connect) étaient indistinguables. Désormais chaque carte affiche le logo officiel + le nom du connecteur, et le titre d’import historique précise la source. La carte Apple ne s’affiche plus que si le numéro vendor a été renseigné (sans lui la backfill Sales Reports échouait silencieusement).
• Bug d’affichage de traductions : certaines chaînes de l’onglet Sources s’affichaient en clé brute non traduite. Corrigé.
• Logo GitHub maintenant visible en dark mode (et Sentry au passage) : l’icône restait en quasi-noir sur fond gris très sombre, ratio de contraste insuffisant. Le fond du carré logo est désormais blanc en permanence — convention App Store / Play Store qui préserve la reconnaissance des marques en dark.
• Bucket GCS Google dans la fiche Google Play. Avant : carte séparée dans Sources > Avancé. Désormais : champ intégré au formulaire Google, comme le numéro vendor d’Apple. Le « Installer » persiste credentials + bucket en un seul clic.
• Imports historiques déplacés dans Synchronisation. Les outils de backfill Google + Apple ne sont pas vraiment de la « config » — c’est de la synchro spéciale one-shot. Ils vivent désormais en bas de l’onglet Synchronisation, visibles seulement si la source est prête à backfiller.

Pour qui c’est important

Toute personne qui essaie d’ajouter un connecteur Sentry, Apple App Store Connect, Google Play, ou Firebase à une app — soit grosso modo 100 % du parcours d’onboarding. Le bug silencieux rendait l’expérience kafkaïenne : on cliquait, rien ne se passait, on ne savait pas quoi faire. La rc.2 corrige ça en amont (propagation des bundle IDs) et en aval (les erreurs sont remontées dans l’UI).

Ce qui a bougé pour de vrai

• StatHall est en ligne. L’application tourne désormais à app.stathall.com (le SPA + l’API) et le site marketing — celui que vous lisez — à www.stathall.com. Aucun changement fonctionnel par rapport à la dernière version alpha : la RC marque la sortie du staging et le passage en conditions de production.
• Outillage de déploiement durci. L’install d’une nouvelle instance passe désormais sans intervention manuelle, même sur un serveur qui héberge déjà d’autres sites.
• Site marketing intégré au déploiement. Le site est buildé et servi à chaque release, en contenu 100 % statique, sans tracker injecté.
• Pas de changement de schéma de base ce sprint. C’est purement du go-live et de la consolidation.

Ce qui arrive ensuite

• Soak en production pour observer le comportement réel des connecteurs sur des apps live.
• Tag v1.0.0 stable une fois la checklist de sécurité validée.