Historique des versions

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.