Refondre une vieille interface ressemble souvent à un problème de peinture jusqu’au moment où l’on déplace le premier mur porteur.
Le calendrier de Thunderbird a accumulé des fonctions pendant des années. L’équipe de design le décrit aujourd’hui comme riche mais devenu à la fois daté visuellement et compliqué à parcourir.1 La première réaction n’a pourtant pas été de jeter l’écran entier. Elle a commencé par des éléments isolés, notamment la fenêtre de détail d’un événement.
Ce choix était pragmatique. Cette fenêtre formait un morceau suffisamment autonome pour être redessiné et testé sans réécrire toute la base du calendrier.1 Le problème est apparu ensuite : en améliorant les morceaux un par un, l’équipe créait aussi des différences entre eux. Les nouvelles décisions visuelles et fonctionnelles ne formaient pas encore un langage commun. Le billet résume le résultat sans détour : les éléments isolés commençaient à produire de l’incohérence et de la dette, autant côté design que développement.1
Le problème local finit par demander une vision globale
L’équipe est alors revenue à trois questions presque banales : à quoi ressemble la grille du calendrier selon la vue choisie, comment navigue-t-on dans le temps, et comment gère-t-on plusieurs calendriers et sources de données ?1
La réponse tient dans trois zones principales. La grille reste l’espace de travail central. Une barre de navigation se place au-dessus. Une barre latérale rassemble la gestion des calendriers et des sources.1 Cette sidebar peut se replier, justement parce que le même utilisateur ne lui donne pas la même importance selon qu’il travaille sur un portable étroit ou un grand écran.
Ce qui est intéressant n’est pas la disposition en trois colonnes ou la couleur des boutons. C’est le moment où l’équipe cesse de traiter les écrans comme une collection de tickets indépendants. Une petite amélioration locale peut être facile à livrer, mais plusieurs petites améliorations peuvent finir par fabriquer un système plus difficile à comprendre.
Thunderbird avait déjà traversé cette tension lors de la refonte Supernova. En 2022, le projet montrait une nouvelle direction pour le calendrier avec l’idée explicite de moderniser une interface ancienne tout en conservant la puissance attendue par ses utilisateurs historiques.4 La difficulté n’a donc rien d’un « avant / après » instantané. C’est un chantier lent où chaque nouveau composant doit cohabiter avec des comportements que certaines personnes utilisent depuis des années.
Les utilisateurs ne servent pas seulement à valider la maquette
La recherche menée cette année sur les réglages desktop montre la même méthode. Thunderbird a interrogé des utilisateurs sur la manière dont ils trouvent et comprennent les options, puis s’est servi des réponses pour orienter les priorités plutôt que pour simplement demander si une nouvelle maquette était « jolie ».2
Pour le calendrier, l’équipe a publié des propositions, lancé un sondage et recueilli des retours sur les fonctions qui comptent réellement : intégration des tâches, interopérabilité avec les plateformes, vues agenda, mini-mois et multi-semaines.1 Ces réponses ne deviennent pas automatiquement des features. Elles révèlent surtout les endroits où simplifier trop brutalement ferait perdre une capacité importante.
C’est un cas assez propre d’une idée qui revient souvent en logiciel créatif : la dette d’interface n’est pas seulement constituée de pixels anciens. Elle contient aussi des habitudes, des raccourcis, des exceptions et des chemins de travail dont la valeur n’apparaît pas dans une capture d’écran.
Le roadmap 2026 de Thunderbird place d’ailleurs l’amélioration du calendrier dans un chantier plus large qui touche aussi les réglages, la recherche, l’accessibilité et la cohérence générale du produit.3 Le calendrier n’est donc pas un skin isolé. Il doit rejoindre un langage commun qui est lui-même encore en mouvement.
La refonte n’est pas encore un produit fini
Le billet du 10 août parle bien d’une direction de design et de ce que l’équipe veut livrer prochainement. Il ne présente pas toutes les maquettes comme déjà disponibles dans la version stable.1 Thunderbird prévoit une mise en production progressive, puis de nouvelles boucles de test et de feedback.
Cette nuance rend le chantier plus utile à observer. L’équipe n’a pas « résolu le calendrier » avec un grand fichier Figma. Elle a d’abord choisi des pièces faciles à isoler, découvert que ces victoires locales pouvaient produire une nouvelle incohérence, puis remonté d’un niveau pour redéfinir la structure.
C’est une façon moins spectaculaire, mais probablement plus réaliste, de moderniser un outil ancien : réparer un morceau, regarder la dette qu’il déplace, puis décider si le prochain problème se trouve encore dans le morceau ou dans le système entier.