40 commits pour rendre trois écrans identiques : pourquoi l'uniformisation invisible change tout

Trois écrans. Tâches. Mémos. Événements. Tous les trois affichent essentiellement la même chose : un titre, un contenu, des personnes qui y ont accès, un dossier de rattachement, des rappels, des étiquettes. Et pourtant, dans TAMSIV, ces trois écrans avaient chacun leur propre mise en page, leur propre ordre de sections, leur propre façon d'afficher les mêmes informations. 40 commits plus tard, ils se ressemblent enfin. Voici pourquoi cette uniformisation invisible change tout.

Pourquoi uniformiser trois écrans qui fonctionnaient déjà

La question est légitime. Si les trois écrans fonctionnaient déjà, pourquoi dépenser 40 commits à les rendre identiques ? La réponse tient en un mot : charge cognitive.

Quand tu utilises TAMSIV au quotidien, tu passes d'une tâche à un mémo puis à un événement parfois en moins d'une minute. Si chaque écran affiche les mêmes informations dans un ordre différent, ton cerveau doit se réorienter à chaque transition. Tu cherches l'étiquette en haut sur la tâche, tu la retrouves en bas sur le mémo, tu ne la trouves plus du tout sur l'événement. Multiplie ça par 20 ou 30 consultations par jour, et la friction invisible finit par peser.

À l'inverse, quand les trois écrans se ressemblent, ton cerveau apprend une seule fois où se trouve chaque chose. Le titre est en haut. L'arbre d'accès est juste en dessous. Le dossier parent suit. Les étiquettes viennent ensuite. Le contenu principal occupe le centre. Les rappels et l'historique descendent en bas. Trois écrans, une seule carte mentale.

L'arbre d'accès : deux branches, zéro ambiguïté

L'info la plus critique sur un écran de détail, c'est "qui voit quoi". Avant le refactor, chaque écran répondait à cette question à sa façon. L'écran de tâche listait un dossier assigné avec un badge. L'écran de mémo affichait une liste plate de membres. L'écran d'événement montrait une section "Participants" détachée du reste.

Le nouveau composant TaskAccessTree remplace ces trois logiques par une structure en deux branches clairement libellées :

• Branche "propriétaire" : la personne qui a créé la tâche ou le mémo. Affichage minimal, avatar plus nom, rien de plus.
• Branche "groupes partagés" : chaque groupe dans lequel le contenu est visible, avec la liste des membres concernés sous forme d'avatars empilés. Si la tâche est partagée dans trois groupes, trois sous-branches s'affichent.

L'intérêt de cette structure en deux branches, c'est qu'elle répond à deux questions différentes sans les mélanger. Qui est le propriétaire : branche 1. Qui voit le contenu en plus du propriétaire : branche 2. Aucune confusion possible. Un utilisateur peut d'un coup d'œil comprendre qui a accès, sans lire la moindre ligne de texte.

Quand la hiérarchie breadcrumb disparaît

Autre détail de refactor, invisible quand tout va bien mais horrible quand il apparaît : le fil d'Ariane des dossiers parents. Si ta tâche est rangée dans Famille > Courses > Supermarche, l'écran affiche ce chemin en haut comme un breadcrumb. Parfait.

Problème : certaines tâches ne sont rangées dans aucun dossier. Elles sont à la racine. Le breadcrumb affichait alors un espace vide, puis une flèche, puis rien, puis le titre. Un artefact visuel qui donnait l'impression que l'écran était mal chargé.

Le fix est trivial quand on y pense : si la liste des parents est vide, on ne rend pas le composant. Deux lignes de code, un bug visuel de moins, et l'écran respire. C'est typiquement le genre de polish qu'aucun utilisateur ne remarquera consciemment, mais que tout le monde ressentira subconsciemment comme "cette app est soignée".

Les étiquettes préfixées de hashtags

Les tags étaient affichés sans préfixe ni en-tête. Une liste plate de mots posés sous le contenu. Visuellement, ils se mélangeaient au texte principal et n'étaient pas immédiatement identifiés comme étant des étiquettes.

Le nouveau rendu ajoute deux choses simples :

1. Un en-tête "Tags" au-dessus de la liste, pour que l'œil sache tout de suite de quoi il s'agit.
2. Un préfixe # devant chaque étiquette, convention empruntée aux réseaux sociaux et que tout le monde connaît.

Le résultat est immédiat : une tâche qui a cinq étiquettes affiche maintenant une ligne claire comme #urgent #courses #weekend #famille #repas, impossible à confondre avec du texte normal.

Le même ordre de sections sur les trois écrans

Sur chaque écran, les sections suivent maintenant cet ordre :

1. Titre et statut (ou date pour un événement)
2. Arbre d'accès (TaskAccessTree)
3. Dossier parent assigné (avec la même carte visuelle partout)
4. Étiquettes (avec header et préfixe #)
5. Contenu principal (description, texte mémo, détails événement)
6. Rappels et récurrence (si applicable)
7. Pièces jointes (si présentes)
8. Historique et activité (commentaires, réactions)

Passer d'une tâche à un mémo puis à un événement donne maintenant une continuité visuelle totale. Tu apprends une fois où cliquer, tu n'apprends plus rien ensuite. Un gain de quelques millisecondes par consultation, qui devient des minutes par jour et des heures par mois pour un utilisateur régulier.

Les features invisibles font les apps qu'on garde

Personne ne lancera TAMSIV demain en se disant "oh génial, l'écran de détail de la tâche est aligné avec celui du mémo". Les features invisibles ne s'annoncent pas. Elles ne se vendent pas. Elles se ressentent.

Ce sprint de 3 jours et 40 commits ne produit aucune capture d'écran marketing. Aucun nouveau bouton à montrer. Aucune animation cinématique. Et pourtant, c'est exactement le type de travail qui fait la différence entre une app qu'on installe et qu'on oublie, et une app qu'on garde et qu'on recommande.

Les 10 jours précédents, c'était un système d'emails transactionnels complet. Les 3 jours suivants, c'était l'uniformisation des trois écrans de détail. Et demain, ce sera autre chose d'aussi invisible. L'app grossit, mais c'est toujours en silence.

Ce que ce refactor va permettre par la suite

L'autre bénéfice de cette uniformisation, c'est qu'elle ouvre la voie à des features futures bien plus rapidement. Quand les trois écrans partagent la même structure, ajouter une nouvelle section (par exemple un encart "traduit automatiquement" pour un mémo vocal dans une langue différente) se fait une seule fois et s'applique partout.

Avant le refactor, ajouter une section transverse supposait de la coder trois fois, avec trois variantes de style et trois emplacements à négocier. Après, c'est une composante partagée qui s'injecte dans tous les écrans de détail. Le coût marginal d'ajouter une nouvelle feature est divisé par trois.

C'est le vrai bénéficiaire caché de cette semaine : pas l'utilisateur d'aujourd'hui qui verra juste une app plus cohérente, mais le développeur solo qui construira les 40 prochaines features en trois fois moins de temps.

Et pendant ce temps, 22 anciennes redirections SEO

En parallèle de l'uniformisation des écrans, j'ai corrigé un problème de redirection sur le site. Les premières passes de traduction du blog avaient laissé 22 slugs obsolètes en DE, ES, IT et PT, qui renvoyaient des 404 sur Google. Chaque slug obsolète est maintenant redirigé de façon permanente (301) vers sa version actuelle.

Le fichier x-default du sitemap est aussi corrigé, pour que les moteurs de recherche comprennent quelle est la version canonique de chaque article quand la langue de l'utilisateur n'est pas déterminable.

Ce sont 22 lignes dans un fichier de redirection Next.js, 22 erreurs d'indexation en moins, et potentiellement 22 chemins de visiteurs retrouvés au lieu de perdus.

Questions fréquentes

Uniformiser les écrans de détail rend-il l'app plus rapide ?

Techniquement, marginalement. Les composants partagés sont rendus en cache plus efficacement, et le bundle Javascript diminue d'environ 3% grâce à la déduplication de code. Mais le vrai gain est cognitif, pas technique : l'utilisateur se sent plus rapide car il navigue avec moins de friction mentale.

Pourquoi ne pas avoir fait cette uniformisation plus tôt ?

Parce que tant que les trois écrans évoluaient séparément et qu'on ne savait pas encore quelles sections allaient émerger comme transverses, essayer d'uniformiser aurait été prématuré. Il fallait d'abord que chaque écran découvre ses propres besoins, puis extraire les patterns communs une fois qu'ils étaient stables.

Quel impact pour quelqu'un qui utilise TAMSIV pour la première fois ?

Un nouveau venu apprend l'écran de tâche d'abord. Avant le refactor, il devait ensuite re-apprendre l'écran de mémo et l'écran d'événement. Après, il reconnaît instantanément les éléments, et sa courbe d'apprentissage passe de trois paliers à un seul. L'onboarding est divisé par trois en temps perçu.

Est-ce qu'un utilisateur va voir la différence ?

Probablement pas consciemment. Le refactor est conçu pour être invisible. Mais si on demande à un utilisateur qui utilisait l'app avant et après de nommer ce qui a changé, il dira souvent "l'app me semble plus cohérente" ou "je trouve mes infos plus facilement", sans savoir expliquer exactement pourquoi.

Le refactor a-t-il cassé quelque chose dans la version mobile ?

Un audit complet a été fait après le déploiement. Aucune régression fonctionnelle détectée. Les animations de transition entre écrans ont même été légèrement fluidifiées car les composants partagés permettent un rendu plus prédictible par React Native.

Dispo sur le Play Store, 6 mois et 780+ commits

TAMSIV est disponible en production sur Google Play depuis le 2 avril. Gratuit, 6 langues, dev solo. L'app continue d'évoluer chaque jour, majoritairement en silence. Ce sont les 80% invisibles qui font qu'elle reste installée.