Historique des versions

Ce qui change pour vous

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

L’Inbox regroupe intelligemment les éléments

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

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

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

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

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

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

Raccourci clavier sur Windows / Linux

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

Côté mobile

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

Sous le capot

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

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

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

2 crashes Sentry corrigés

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

Réglages des notifications maintenant cliquable

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

AppPickerSheet : distinction apps vs serveurs + badge anomalies

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

Vocabulaire aligné avec la SPA — « Pulse »

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

Activité enrichie côté backend

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

Sous le capot

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

Ce qui change pour vous

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

Épinglez n’importe quel écran

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

Pastilles explicites au coup d’œil

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

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

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

Boîte de réception in-app

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

Sources couvertes au lancement :

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

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

Compteurs synchronisés en temps réel

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

Sous le capot

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

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

Ce qui change pour vous

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

Inbox = home (remplace Vue globale)

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

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

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

Combobox unifié avec mode shell « / »

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

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

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

Groupes hiérarchiques de cibles

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

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

5 vues principales

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

Synthèse IA par cible — Avis ET Activité

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

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

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

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

Mode admin clairement séparé

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

Vues épinglées personnelles

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

Sous le capot

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

---

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

Ce qui change pour vous

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

Synthèses IA cross-source

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

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

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

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

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

Barre de commande / enrichie

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

Catalogue & Activité polis

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

Vues épinglées partagées

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

Responsive mobile

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

Sous le capot

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

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

Ce qui change pour vous

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

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

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

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

Refonte de l’administration Apps / Serveurs

Les pages Admin › Apps et Admin › Serveurs gagnent :

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

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

Étiquette « Lecteur » devenue « Utilisateur »

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

Inbox : on voit la cible de chaque anomalie

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

Refonte du panel Membres des groupes

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

Sous le capot

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

Ce qui change pour vous

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

Sections par groupe + Sans groupe

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

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

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

Sous le capot

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

Ce qui change pour vous

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

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

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

Vue arbre dépliée par défaut

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

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

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

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

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

Sous le capot

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

Ce qui change pour vous

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

4 onglets de tri en haut

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

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

Lignes lisibles d’un coup d’œil

Chaque carte du flux porte :

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

Lien « Ouvrir le contexte » par type

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

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

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

Filtres et tabs

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

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

Sous le capot

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

Ce qui change pour vous

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

Avant / Après

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

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

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

Cas dynamiques

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

Bouton ⚙ Configurer

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

Sous le capot

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

Ce qui change pour vous

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

Les anomalies serveur reviennent dans l’Inbox

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

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

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

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

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

Couleurs d’état des tuiles plus contrastées

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

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

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

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

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

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

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

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

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

Légende des couleurs au catalogue

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

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

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

Plus de tuiles par ligne

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

Sous le capot

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

---

Patch du 19/05 — retours utilisateurs

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

Reviews — la recherche et le filtre Version refonctionnent

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

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

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

Versions → Reviews en un clic

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

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

Inbox — synthèses dédupliquées

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

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

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

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

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

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

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

Groupes accessibles aux propriétaires

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

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

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

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

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

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

Sous le capot

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

---

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

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

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

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

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

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

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

Mobile — icônes harmonisées avec la SPA

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

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

Ce qui change pour vous

Une app mobile plus cohérente

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

Un cockpit à 5 onglets

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

Nouvel onglet « Santé »

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

Nouvel onglet « Activité »

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

Liens app ↔ serveur visibles dans l’app

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

Sous le capot

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

---

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

Ce qui change pour vous

Un abonnement Pro pour soutenir le projet

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

Le super-dashboard

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

Suivi de consommation et codes d’accès

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

Déploiements zéro-downtime

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

Documentation enrichie

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

Renforcement de la posture sécurité

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

---

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

Ce qui change pour vous

Un menu latéral repensé

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

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

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

Badge alerte anomalies critiques

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

Raccourci admin permanent

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

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

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

Sous le capot

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

---

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

Ce qui change pour vous

Trois vues d’ensemble pour superviser tout

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

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

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

Un nouveau menu de cible plus malin

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

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

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

Sidebar admin réorganisée

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

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

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

Écrans admin remis au standard visuel

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

Sous le capot

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

---

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

Ce qui change pour vous

Un nouveau type de cible : le serveur Unix

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

Un dashboard serveur dédié

Pour chaque serveur connecté :

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

Application mobile : nouvel onglet « Cibles »

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

Pour qui ça change

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

Sous le capot

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

Ce qui change pour vous

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

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

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

Pour qui ça change

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

Ce qui change pour vous

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

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

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

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

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

Pour qui ça change

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

Ce qui change pour vous

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

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

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

Le score respecte le profil de votre app

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

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

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

Pour qui ça change

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

Ce qui change pour vous

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

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

Désormais :

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

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

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

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

Pour qui ça change

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

Ce qui change pour vous

Rien — et c’est voulu.

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

Vos apps, exactement comme avant

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

Ce que ça prépare

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

Pour qui ça change

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

Au programme

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

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

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

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

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

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

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

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

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

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

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

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

Le justificatif est :

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

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

Emails plus respectueux et plus pro

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

Login plus respectueux

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

Mentions légales mises à jour

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

Côté entreprise

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

Au programme

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

Côté utilisateur — web

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

Côté utilisateur — mobile

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

Emails — refonte visuelle

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

Mentions légales

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

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

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

Côté entreprise

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

Au programme

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

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

Côté utilisateur

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

Côté entreprise

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

Ce qui change pour vous

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

Nouveau choix : suppression définitive ou anonymisation

Vous pouvez désormais choisir entre :

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

Transfert des apps avant suppression

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

Double authentification pour supprimer

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

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

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

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

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

Email de confirmation post-effacement

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

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

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

Sous le capot

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

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

Ce qui change pour vous

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

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

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

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

Sous le capot

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

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

Ce qui change pour vous

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

Pourquoi c’est important

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

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

Concrètement

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

Sous le capot

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

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

Ce qui change pour vous

Le bouton « Supprimer mon compte » ne crashe plus

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

Liste de serveurs au login : retour au glissement seul

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

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

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

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

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

Sous le capot

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

Ce qui change pour vous

Le bouton « Soutenir » est maintenant explicite

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

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

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

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

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

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

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

Sous le capot

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

Ce qui change pour vous

La suppression de compte se fait sur stathall.com

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

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

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

Concrètement, sur la page web vous pourrez :

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

Conformité

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

Sous le capot

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

Ce qui change pour vous

Soutenir StatHall directement depuis Inbox et Apps

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

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

Email pré-rempli quand vous changez d’environnement

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

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

Changelog public nettoyé

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

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

Sous le capot

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

Ce qui change pour vous

Soutenir StatHall depuis l’app mobile

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

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

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

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

Changelog public allégé

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

Pour les équipes auto-hébergées

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

Sous le capot

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

Ce qui change pour vous

Vos appareils mobiles, gérables aussi depuis le navigateur

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

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

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

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

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

Description du groupe Sécurité élargie

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

Ce qui change pour vous

La dernière release apparaît bien en premier

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

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

Ce qui change pour vous

La liste « Appareils connectés » devient lisible

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

Désormais, chaque carte affiche :

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

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

Ce qui change pour vous

Sessions stockées : validation défensive

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

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

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

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

Ce qui change pour vous

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

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

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

Sécurité durcie

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

Stabilité

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

Standards iOS HIG / Material 3

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

Versions alignées sur tout le stack

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

Ce qui change pour vous

Suppression depuis l’écran Setup pré-auth

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

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

Liste de serveurs au design propre (style iOS Settings)

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

Renommage automatique des profils existants

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

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

Ce qui change pour vous

Une icône 🗑 visible sur chaque serveur

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

« Gérer les serveurs » comme entry point principal

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

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

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

Ce qui change pour vous

Plus de profils « Production » qui s’empilent

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

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

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

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

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

Ce qui change pour vous

Le bouton retour fonctionne toujours

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

Inbox : plus de saut pendant le chargement

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

Accessibilité aux standards Apple HIG / Material Design

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

Roadmap : le rendu Gantt arrive

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

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

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

Versions : auto-détection de plateforme

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

Synthèse IA : historique navigable

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

Ce qui change pour vous

Pile dépliable dans l’Inbox

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

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

Nettoyage UX

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

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

Ce qui change pour vous

Une app mobile repensée autour de votre Inbox

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

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

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

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

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

Un score de santé visuel par app

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

Timeline des versions et roadmap, en mobile

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

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

Notifications push mieux gérées

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

Pour qui ça change

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

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

Limites connues

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

Ce qui change pour vous

Vos crashs Android, même sans Crashlytics

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

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

Un seul clic pour ouvrir la console source

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

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

Crashlytics + Play Vitals : une seule ligne par crash

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

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

Quatre badges pour aller à l’essentiel

Chaque crash issue peut maintenant porter quatre badges visuels distincts :

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

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

Petits nettoyages d’interface

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

Pour qui ça change

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

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

Limites connues

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

Patchs livrés dans la journée

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

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

Ce qui change pour de vrai

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

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

Lecture des synthèses — UX clarifiée

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

Préférences email — toggle simplifié

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

Historique IA pour les administrateurs

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

Performance — Dashboard et liste d’apps plus rapides

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

Migration

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

Pour qui c’est important

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

Ce qui arrive ensuite

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

Ce qui a bougé pour de vrai

Dashboard app — chargement nettement plus rapide

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

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

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

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

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

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

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

À venir au prochain sprint

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

Backfill Google Play — bucket retiré

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

Pour qui c’est important

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

Limites assumées

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

Ce qui a bougé pour de vrai

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

Pour qui c’est important

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

Ce qui a bougé pour de vrai

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

Ce qui arrive ensuite

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