---
title: "Changelog — StatHall"
description: "Historique public des versions publiées de StatHall. Ce qui change à chaque release, rédigé pour les utilisateurs."
lang: fr
canonical: "https://www.stathall.com/changelog/"
updated: "2026-10-23"
---

# Historique des versions

Chaque release publiée, rédigée pour les utilisateurs. Les détails techniques complets vivent dans le dépôt source.

## v3.11.12 — Redémarrer sans fausse alerte, une Inbox qui va à l'essentiel

_2026-10-23_

### Un redémarrage volontaire n'ouvre plus d'alertes

Redémarrer une machine ouvrait des alertes « Conteneur en mauvais état » ou « Service en échec » : l'agent photographiait l'extinction elle-même. L'agent 1.3.22 annonce l'extinction et n'envoie que ce qu'il a mesuré avant. Les alertes qu'un redémarrage avait laissées ouvertes se referment d'elles-mêmes dès que la machine est saine.

### Un redémarrage imprévu est signalé

À l'inverse, une machine qui redémarre sans s'être éteinte proprement (arrêt brutal, plantage, coupure de courant) ouvre désormais l'alerte « Redémarrage imprévu », en priorité basse.

### L'Inbox va à l'essentiel

Par défaut, l'Inbox ne montre que les alertes P0 et P1. S'il n'y en a aucune, elle montre aussi les P2. Vous pouvez en écarter un serveur ou une application : un bandeau rappelle ce qui est écarté, et les notifications ne changent pas. Le nom du serveur a désormais sa propre ligne dans la liste.

### « Je m'en occupe » plutôt qu'« Acquitter »

Le geste ne change pas : il arrête les rappels. L'alerte reste ouverte jusqu'au retour à la normale, qui la referme seul. Sur le téléphone, le nouveau libellé arrive avec la prochaine version de l'app.

### Les erreurs de journal se voient

Un serveur dont les journaux contiennent des erreurs l'affiche au catalogue et sur sa fiche, avec le nombre d'erreurs des dernières 24 h et un lien vers ses logs.

### Les démos restent dans « Démo »

Sur le téléphone, le périmètre « Tout » ne montre plus les machines de démonstration, comme sur le site.

## v3.11.11 — Failles Docker repérées plus tôt, groupes pour se classer

_2026-10-20_

### 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 ».

## v3.11.10 — Roadmap : l'édition à qui peut éditer

_2026-10-20_

### 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.

## v3.11.9 — Roadmap : créer une version, masquer l'historique

_2026-10-20_

### 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.

## v3.11.8 — « À traiter » ne montre plus ce qui est réglé

_2026-10-19_

### 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.

## v3.11.7 — Construit sur Node 24

_2026-10-15_

### 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.

## v3.11.6 — Une faille corrigée se ferme dans les minutes

_2026-10-14_

### 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.

## v3.11.5 — Un score de santé qui s'explique

_2026-10-14_

### 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.

## v3.11.4 — Des alertes mémoire plus justes pour les conteneurs

_2026-10-12_

### 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.

## v3.11.3 — Une panne de conteneur, une seule alerte

_2026-10-12_

### 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.

## v3.11.2 — Des exports Excel deux fois plus rapides

_2026-10-09_

### 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.

## v3.11.1 — Des exports Excel fiables sur un parc entier

_2026-10-09_

### 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.

## v3.11.0 — Vos données en Excel ou en CSV, prêtes pour un tableau croisé

_2026-10-09_

### 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.

## v3.10.4 — Moins de fausses alertes sur les journaux

_2026-10-06_

### 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.

## v3.10.3 — Renforcement de la posture de sécurité

_2026-10-05_

### Sécurité

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

## v3.10.2 — Renforcement de la sécurité des comptes

_2026-10-05_

### Sécurité

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

## v3.10.1 — Renforcement de la sécurité des comptes

_2026-10-05_

### 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.

## v3.10.0 — Un accès API en lecture seule, pour vos écrans de confiance

_2026-10-04_

### 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é.

## v3.9.0 — Les fins de support, sur une échelle à part

_2026-09-30_

### 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.

## v3.8.32 — Aucune version bêta proposée comme correctif

_2026-09-29_

### 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.

## v3.8.31 — Le serveur signale chaque changement d'une alerte critique à l'application

_2026-09-29_

### 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.

## v3.8.30 — Une faille corrigée ferme son alerte le jour même

_2026-09-29_

### 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.

## v3.8.29 — Des alertes d'image justes, et les SBOM qui alertent

_2026-09-29_

### 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.

## v3.8.28 — Une faille, une ligne

_2026-09-29_

### 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é.

## v3.8.27 — Les failles de vos conteneurs et des paquets Docker

_2026-09-28_

### 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.

## v3.8.26 — La bonne version dans les alertes d'image

_2026-09-28_

### 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.

## v3.8.25 — Images en retard : pas d'alerte pendant un déploiement

_2026-09-28_

### 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.

## v3.8.24 — Les images de conteneurs en retard sont signalées

_2026-09-28_

### 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.

## v3.8.23 — Des commandes prêtes à copier, sur le bon service

_2026-09-28_

### 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.

## v3.8.22 — La bonne version dès la première visite

_2026-09-28_

### 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.

## v3.8.21 — Un seul regroupement par série de plantages

_2026-09-27_

### 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é.

## v3.8.20 — Des incidents qui se ferment, une veille de failles plus rapide

_2026-09-27_

### 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.

## v3.8.19 — Moins de fausses alertes sur les conteneurs

_2026-09-26_

### 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.

## v3.8.18 — L'agent indique d'où vient chaque paquet

_2026-09-26_

### 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.

## v3.8.17 — Les failles ont enfin leur gravité, et une seule alerte par serveur

_2026-09-26_

### 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.

## v3.8.16 — Des failles comptées au plus juste sur vos serveurs

_2026-09-26_

### 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.

## v3.8.15 — Les failles des serveurs Ubuntu enfin chiffrées, et les versions à venir déjà prévues

_2026-09-26_

### 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.

## v3.8.14 — Un service stable toute la nuit, et moins de fausses alertes

_2026-09-26_

### 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.

## v3.8.13 — Le cockpit reste réactif, même avec de nombreux onglets ouverts

_2026-09-26_

### 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.

## v3.8.12 — Une politique de confidentialité complète, et la suppression de compte expliquée

_2026-09-25_

### 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](https://www.stathall.com/docs/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.

## v3.8.11 — Passe de sécurité avant l'arrivée de l'application sur les stores

_2026-09-25_

### 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.

## v3.8.10 — Le site public se lit mieux, par vous comme par les moteurs

_2026-09-25_

### 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.

## v3.8.9 — Les listes de cibles se chargent à nouveau partout

_2026-09-24_

### 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.

## v3.8.8 — Vos groupes repliés vous suivent partout

_2026-09-23_

### 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.

## v3.8.7 — Le catalogue se souvient de vos groupes repliés

_2026-09-23_

### 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.

## v3.8.6 — « Retour » ramène d'où vous venez

_2026-09-23_

### 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.

## v3.8.5 — Un accès en double se voit

_2026-09-23_

### 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à.

## v3.8.4 — Un compteur compte ce que l'écran montre

_2026-09-23_

### 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`.

## v3.8.3 — Des alertes calibrées type par type

_2026-09-23_

### 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.

## v3.8.2 — Le profil d'une machine passe avant une règle générale

_2026-09-23_

### 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.

## v3.8.1 — Le profil « Runner CI » fait taire le processeur

_2026-09-23_

### 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.

## v3.8.0 — Chaque alerte dit quoi et combien

_2026-09-23_

### 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.

## v3.7.3 — Les liens ouvrent aussi l'APK Android

_2026-09-23_

### 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.

## v3.7.2 — Filtrer la boîte de réception

_2026-09-23_

### 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.

## v3.7.0 — Les services tiers qu'on ne surveillait pas

_2026-09-22_

### 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.

## v3.6.0 — Quarante alertes, trois incidents

_2026-09-22_

### 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.

## v3.5.0 — La détection regarde enfin la bonne mesure

_2026-09-22_

### 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.

## v3.4.0 — Une alerte dit quand elle a été mesurée

_2026-09-21_

### 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.

## v3.3.0 — Le bas des listes, la session qui dure, et l'IA qui se nomme

_2026-09-21_

### 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.

## v3.2.0 — Le téléphone ne fait plus que constater

_2026-09-21_

### 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.

## v3.1.3 — Ce qui s'est réglé tout seul se voit encore

_2026-09-18_

### 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.

## v3.1.2 — Une alerte par incident, et rien du compte précédent

_2026-09-18_

### 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.

## v3.1.1 — Une alerte se lit sans plisser les yeux

_2026-09-17_

### 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.

## v3.1.0 — La configuration de l'assistant se règle depuis le cockpit

_2026-09-16_

### 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.

## v3.0.1 — L'aide, revue après vos premiers retours

_2026-09-16_

### 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.

## v3.0.0 — Vos backends cloud, une app qui passe la main au cockpit, et une aide qui répond

_2026-09-16_

### 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](https://www.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.

## v2.9.1 — Une alerte qui dit vrai

_2026-09-15_

### 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.

## v2.9.0 — Un seul menu, et plus rien qui se cache

_2026-09-15_

### 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.

## v2.8.7 — Partager un groupe partage enfin ce qu'il contient

_2026-09-14_

### 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.

## v2.8.6 — Créer un groupe fonctionne pour tout le monde

_2026-09-14_

### 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.

## v2.8.5 — Fin du bruit d'alerte sur les serveurs de build

_2026-09-14_

### 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.

## v2.8.4 — Des jauges qui bougent, un onglet Sécurité en français, un « récupérable » qui dit où

_2026-09-14_

### 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.

## v2.8.3 — Trois écrans qui refusaient de s'ouvrir

_2026-09-13_

### 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.

## v2.8.2 — La veille de failles reçoit enfin ses données

_2026-09-13_

### 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
```

## v2.8.1 — Une alerte qui se comprend sans ouvrir le cockpit

_2026-09-13_

### 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.

## v2.8.0 — Vos serveurs vous préviennent avant la panne

_2026-09-12_

### 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.

## v2.7.8 — La vue d'ensemble s'ouvre enfin depuis le mobile

_2026-09-10_

### 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.

## v2.7.7 — L'application mobile reçoit enfin les bons chiffres

_2026-09-10_

### 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.

## v2.7.6 — Catégories d'avis nettement plus justes

_2026-09-09_

### 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.

## v2.7.5 — Étiquetage des avis plus juste

_2026-09-09_

### 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.

## v2.7.4 — Espace de démonstration remis à jour

_2026-09-09_

### 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é.

## v2.7.3 — Onglet Agent fiable, cartes serveur lisibles

_2026-09-08_

### 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.

## v2.7.2 — Filtres des logs plus lisibles

_2026-09-08_

### 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).

## v2.7.1 — Correctif technique sur l'état d'ingestion des serveurs

_2026-09-08_

### 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).

## v2.7.0 — Logs de serveur fiables : Docker, fichiers, et une page qui explique ce qu'elle affiche

_2026-09-07_

### 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.

## v2.6.5 — Plus de fausse alerte « aucun worker » pendant une mise à jour

_2026-09-07_

### 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).

## v2.6.4 — Gérer les groupes d'une app ou d'un serveur depuis sa page

_2026-09-07_

### 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.

## v2.6.3 — Correctif : la page Logs d'un serveur tournait en boucle

_2026-09-07_

### 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.

## v2.6.2 — Sauvegardes fiables et surveillées, alerte sur un taux d'ANR chronique, accueil à jour

_2026-09-06_

### 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.

## v2.6.1 — Correctif : les agents serveurs étaient rejetés (HTTP 500) par le rate-limit

_2026-09-06_

### 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.

## v2.6.0 — Serveurs supervisés de bout en bout, détection fiable, cockpit temps réel et app mobile hors ligne

_2026-09-05_

### 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.

## v2.4.0 — StatHall devient gratuit et open-source — plus d'abonnement, des dons et l'auto-hébergement

_2026-06-12_

### 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.

## v2.3.0 — Inbox regroupée par type + filtre Équipe / Tous / Démo pour les admins

_2026-05-20_

### 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.

## v2.2.3 — Favoris polymorphes + boîte de réception in-app — votre cockpit personnalisé

_2026-05-19_

### 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).

## v2.0.0-mobile-rc.10 — App mobile rc.10 — refonte des réglages notifications + cohérence avec la SPA

_2026-05-19_

### 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.

## v2.2.9 — Inbox — anomalies serveur visibles + rail plus lisible + tuiles plus denses

_2026-05-18_

### 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).

## v2.2.8 — Catalogue arbre — chemins compactés style VS Code

_2026-05-18_

### 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.

## v2.2.7 — Inbox web — anomalies + synthèses + versions dans un seul flux

_2026-05-18_

### 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.

## v2.2.6 — Catalogue groupé par défaut + arbre pliable + admin de groupe pour ses propriétaires

_2026-05-18_

### 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.

## v2.2.5 — Grouper par groupe — pour de vrai cette fois

_2026-05-18_

### 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.

## v2.2.4 — Vos propres apps enfin éditables + admin Apps/Serveurs filtrable par utilisateur

_2026-05-18_

### 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.

## v2.2.2 — Finition Inbox + Scope — synthèses IA cross-source, règles d'anomalies en temps réel, mobile responsive

_2026-05-18_

### 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.

## v2.2.0-rc.1 — Refonte UX « Inbox + Scope » — Inbox = home, groupes hiérarchiques, mode shell « / »

_2026-05-18_

### 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.

## v2.1.0-rc.2 — Refonte du menu latéral — Rail + Panel persistants

_2026-05-17_

### 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.

## v2.1.0-rc.1 — Cockpit universel — refonte ergonomique

_2026-05-17_

### 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.

## v2.0.0-rc.8 — App mobile — nouveau cockpit 5 onglets et refonte design system

_2026-05-17_

### 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.

## v2.0.0-rc.7 — StatHall V2 — cockpit universel, abonnement Pro et super-dashboard

_2026-05-17_

### 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.

## v2.0.0-rc.6 — StatHall supervise aussi vos serveurs Unix

_2026-05-15_

### 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.

## v2.0.0-rc.5 — Des libellés clairs sur les thèmes d'avis

_2026-05-14_

### 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é.

## v2.0.0-rc.4 — Un vrai score d'adoption + la carte « Top thèmes des avis » réparée

_2026-05-14_

### 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.

## v2.0.0-rc.3 — Un score de santé cohérent partout — dashboard, liste et mobile

_2026-05-14_

### 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.

## v2.0.0-rc.2 — Le score de santé reflète mieux la réalité de vos apps

_2026-05-14_

### 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é.

## v2.0.0-rc.1 — Les fondations de la V2 : un socle prêt à superviser bien plus que vos apps

_2026-05-14_

### 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.

## v1.0.0-rc.27 — Transfert de propriété, scope super-administrateur cadré, emails et login plus respectueux

_2026-05-13_

### 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.

## v1.0.0-rc.26 — Historique IA, Inbox mobile fiabilisé, refonte des emails, mentions légales

_2026-05-12_

### 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.

## v1.0.0-rc.25 — Renforcement de la posture sécurité

_2026-05-10_

### 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.

## v1.0.0-rc.24 — Suppression de compte — refonte RGPD complète (transfert d'apps, anonymisation, 2FA)

_2026-05-10_

### 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).

## v1.0.0-rc.23 — Boutons de partage — vrais logos LinkedIn + X officiels

_2026-05-10_

### 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).

## v1.0.0-rc.22 — Durcissement de sécurité — protections navigateur renforcées

_2026-05-10_

### 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.

## v1.0.0-rc.21 — Fix crash « Supprimer mon compte » dans l'app + déconnexion mobile immédiate à la suppression web

_2026-05-10_

### 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`.

## v1.0.0-rc.20 — Bouton Soutenir avec texte dans les headers, et endpoints mobile de suppression retirés du backend

_2026-05-10_

### 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`.

## v1.0.0-rc.19 — Suppression de compte : redirection vers le web depuis l'app mobile

_2026-05-10_

### 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`.

## v1.0.0-rc.18 — Soutenir StatHall toujours à un tap, email pré-rempli au login, et changelog public nettoyé

_2026-05-10_

### 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`.

## v1.0.0-rc.17 — Soutenir StatHall directement depuis l'app mobile + relecture du changelog public

_2026-05-10_

### 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`.

## v1.0.0-rc.16 — Gestion des appareils connectés disponible sur le site web — révoquez vos sessions mobile depuis Mon Compte

_2026-05-10_

### 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.

## v1.0.0-rc.15 — Fix tri du changelog public — la dernière version est désormais bien en haut de la liste

_2026-05-10_

### 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.

## v1.0.0-rc.14 — Nouvelle carte « Appareils connectés » : icône plateforme, OS + modèle combinés, et temps relatif (« vu il y a 2 min »)

_2026-05-10_

### 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).

## v1.0.0-rc.13 — Validation défensive des sessions stockées + complétion du changelog

_2026-05-10_

### 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).

## v1.0.0-rc.12 — Apparition automatique de votre iPhone dans la liste des appareils + durcissement sécurité + alignement de version sur tout le stack

_2026-05-10_

### 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.

## v1.0.0-rc.11 — Suppression de serveurs depuis l'écran Setup, swipe propre dans la liste, et renommage automatique des profils existants

_2026-05-10_

### 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.

## v1.0.0-rc.10 — Le bouton Supprimer devient explicite — plus besoin de deviner qu'il fallait glisser

_2026-05-10_

### 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 ».

## v1.0.0-rc.9 — Anti-doublons sur la liste de serveurs : un seul profil par couple (URL × email), même si vous vous connectez plusieurs fois

_2026-05-10_

### 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.

## v1.0.0-rc.8 — Navigation back robuste, accessibilité aux standards Apple HIG, et un Inbox qui ne saute plus pendant le chargement

_2026-05-09_

### 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.

## v1.0.0-rc.7 — Inbox plus lisible — vos synthèses et nouvelles versions se regroupent automatiquement par app

_2026-05-09_

### 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.

## v1.0.0-rc.6 — Refonte de l'app mobile : un Inbox unifié, des liens qui ouvrent directement l'app, et un score de santé en un coup d'œil

_2026-05-08_

### 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).

## v1.0.0-rc.5 — Crashs des stores Android, deep-links vers vos outils, badges « nouveau / régression / pic » sur chaque issue

_2026-05-07_

### 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.

## v1.0.0-rc.4 — Synthèse IA repensée : token au niveau de l'app, génération automatique paramétrable, et expérience de lecture clarifiée

_2026-05-06_

### 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).

## v1.0.0-rc.3 — Refonte Dashboard app, scraper Play Store élargi à 16 marchés, tagging plus juste et dashboard plus rapide

_2026-05-05_

### 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.

## v1.0.0-rc.2 — Fix ergonomie chaîne connecteurs — feedback visible, plus de silence

_2026-04-30_

### 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).

## v1.0.0-rc.1 — Premier déploiement public — app.stathall.com + www.stathall.com

_2026-04-30_

### 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.