Coulisses : la cloche qui ne crie pas, les notifications d'une application refaites

Notre première notification utile est arrivée noyée au milieu de tout ce qui ne demandait rien. Cinq retours en une session, une cause simple, et une refonte livrée le jour même : le récit d'une avalanche que nous avons fabriquée nous-mêmes.

Le 31 août 2026, la première utilisation réelle de notre cloche de notifications a produit cinq retours en une session (notes internes de l'équipe). La boîte annonçait comme neuf tout l'existant et listait les demandes de validation de tous les produits à la fois. Nous l'avons refaite le jour même.

Une cloche qui avait raison trop souvent

L'idée de départ tenait : quand une équipe d'agents travaille pendant que vous faites autre chose, il faut un endroit qui dise ce qui s'est passé et ce qui attend votre décision. La première version disait tout. Chaque produit jamais ouvert, chaque document laissé en attente des semaines plus tôt, chaque essai abandonné remontait dans la même liste, au même niveau que la seule chose qui comptait. Deux causes se sont additionnées. La boîte lisait toutes les demandes de validation en attente, alors que l'atelier n'en présente jamais qu'une à la fois. Et rien ne se souvenait de ce que vous aviez déjà vu avant la mise à jour, donc tout le passé arrivait d'un coup, étiqueté comme neuf.

Trois décisions prises en une soirée

La première : sur le produit ouvert, la cloche n'affiche que la demande de validation en cours, celle qui bloque la suite, jamais la pile. La deuxième : les notifications survivent à la fermeture de l'application, parce qu'une alerte qui disparaît quand vous quittez le logiciel ne sert à rien à quelqu'un qui travaille par soirées. La troisième : un seul panneau, trié, ce produit d'abord, puis ce qui s'est passé ailleurs. Nous avons ajouté un bouton « Effacer ce qui est fini », qui range les événements clos sans toucher aux décisions en attente. Ces trois décisions ont un point commun : elles retirent de l'information de l'écran. Nous avons hésité, parce qu'une notification retirée est une notification que quelqu'un cherchera un jour. La réponse a été de déplacer au lieu de supprimer : ce qui ne s'affiche plus dans la cloche reste consultable dans le fil d'activité, filtrable produit par produit, et ce fil se remplit à l'ouverture de l'application plutôt qu'après le premier travail.

Une réponse, une bannière

Un défaut plus discret nous a coûté autant de crédit auprès de l'utilisateur : chaque réponse d'un agent pouvait empiler plusieurs bandeaux d'information dans la conversation. Une réponse affiche maintenant une bannière, au plus. Le bouton d'action des messages éphémères, noir par défaut faute d'avoir été habillé, est repassé à la charte de couleurs du reste de l'application. Ces deux corrections ne changent aucune capacité du produit : elles changent la quantité de bruit qu'il faut traverser pour trouver la ligne qui demande votre décision, et c'est le même problème que celui décrit dans notre deuxième passe de retours beta.

Le défaut trouvé sur une capture d'écran

Le lendemain de la publication, une capture d'écran a montré un reste : un brief de marque, écrit seul par Léa, apparaissait comme une décision en attente dans tous les vieux produits d'essai, et la ligne renvoyait à l'accueil au lieu du Studio. Corrigé, republié le jour même. Nous voulions numéroter cette correction 0.1.15.1 : impossible, un numéro de version tient en trois nombres, ce fut donc 0.1.16. Les autres lignes qui remontaient de vieux projets, elles, étaient de vraies demandes de validation restées ouvertes : la réponse est d'archiver les essais, pas de faire taire la cloche.

La règle que nous nous imposons maintenant

Toute nouvelle source d'événement passe par le même point d'entrée, jamais par un second chemin. C'est la seule garantie qu'une notification ne puisse pas exister en double, ni échapper au tri, ni contredire ce que le fil d'activité affiche. La leçon générale vaut au-delà de notre cas : un système qui notifie doit d'abord savoir ce que vous avez déjà vu. Sans cette mémoire, la première mise à jour transforme tout l'existant en alertes, et l'utilisateur apprend à ignorer la cloche en une soirée. Nous avons eu de la chance sur le calendrier : le défaut est apparu chez nous avant d'atteindre nos deux testeurs, qui auraient pris la même rafale à leur propre mise à jour.

Ce que ça vous dit d'un outil

Quand vous testez un logiciel qui travaille en votre absence, ouvrez sa boîte de notifications après deux semaines d'usage, pas le premier jour. Comptez les lignes qui appellent une décision de votre part et celles qui vous informent d'un fait révolu. Si le rapport penche du mauvais côté, vous cesserez de la regarder, et le produit perdra le seul canal qui pouvait vous dire qu'un travail attend votre accord. Chez nous, cette décision reste le point où tout s'arrête tant que vous n'avez pas répondu, ce qui rend la lisibilité de la cloche non négociable.