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

Trois ecrans. Taches. Memos. Evenements. Tous les trois affichent essentiellement la meme chose : un titre, un contenu, des personnes qui y ont acces, un dossier de rattachement, des rappels, des etiquettes. Et pourtant, dans TAMSIV, ces trois ecrans avaient chacun leur propre mise en page, leur propre ordre de sections, leur propre facon d'afficher les memes informations. 40 commits plus tard, ils se ressemblent enfin. Voici pourquoi cette uniformisation invisible change tout.

Pourquoi uniformiser trois ecrans qui fonctionnaient deja

La question est legitime. Si les trois ecrans fonctionnaient deja, pourquoi depenser 40 commits a les rendre identiques ? La reponse tient en un mot : charge cognitive.

Quand tu utilises TAMSIV au quotidien, tu passes d'une tache a un memo puis a un evenement parfois en moins d'une minute. Si chaque ecran affiche les memes informations dans un ordre different, ton cerveau doit se reorienter a chaque transition. Tu cherches l'etiquette en haut sur la tache, tu la retrouves en bas sur le memo, tu ne la trouves plus du tout sur l'evenement. Multiplie ca par 20 ou 30 consultations par jour, et la friction invisible finit par peser.

A l'inverse, quand les trois ecrans se ressemblent, ton cerveau apprend une seule fois ou se trouve chaque chose. Le titre est en haut. L'arbre d'acces est juste en dessous. Le dossier parent suit. Les etiquettes viennent ensuite. Le contenu principal occupe le centre. Les rappels et l'historique descendent en bas. Trois ecrans, une seule carte mentale.

L'arbre d'acces : deux branches, zero ambiguite

L'info la plus critique sur un ecran de detail, c'est "qui voit quoi". Avant le refactor, chaque ecran repondait a cette question a sa facon. L'ecran de tache listait un dossier assigne avec un badge. L'ecran de memo affichait une liste plate de membres. L'ecran d'evenement montrait une section "Participants" detachee du reste.

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

• Branche "proprietaire" : la personne qui a cree la tache ou le memo. Affichage minimal, avatar plus nom, rien de plus.
• Branche "groupes partages" : chaque groupe dans lequel le contenu est visible, avec la liste des membres concernes sous forme d'avatars empiles. Si la tache est partagee dans trois groupes, trois sous-branches s'affichent.

L'interet de cette structure en deux branches, c'est qu'elle repond a deux questions differentes sans les melanger. Qui est le proprietaire : branche 1. Qui voit le contenu en plus du proprietaire : branche 2. Aucune confusion possible. Un utilisateur peut d'un coup d'oeil comprendre qui a acces, sans lire la moindre ligne de texte.

Quand la hierarchie breadcrumb disparait

Autre detail de refactor, invisible quand tout va bien mais horrible quand il apparait : le fil d'Ariane des dossiers parents. Si ta tache est rangee dans Famille > Courses > Supermarche, l'ecran affiche ce chemin en haut comme un breadcrumb. Parfait.

Probleme : certaines taches ne sont rangees dans aucun dossier. Elles sont a la racine. Le breadcrumb affichait alors un espace vide, puis une fleche, puis rien, puis le titre. Un artefact visuel qui donnait l'impression que l'ecran etait mal charge.

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'ecran 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 soignee".

Les etiquettes prefixees de hashtags

Les tags etaient affiches sans prefixe ni en-tete. Une liste plate de mots poses sous le contenu. Visuellement, ils se melangeaient au texte principal et n'etaient pas immediatement identifies comme etant des etiquettes.

Le nouveau rendu ajoute deux choses simples :

1. Un en-tete "Tags" au-dessus de la liste, pour que l'oeil sache tout de suite de quoi il s'agit.
2. Un prefixe # devant chaque etiquette, convention empruntee aux reseaux sociaux et que tout le monde connait.

Le resultat est immediat : une tache qui a cinq etiquettes affiche maintenant une ligne claire comme #urgent #courses #weekend #famille #repas, impossible a confondre avec du texte normal.

Le meme ordre de sections sur les trois ecrans

Sur chaque ecran, les sections suivent maintenant cet ordre :

1. Titre et statut (ou date pour un evenement)
2. Arbre d'acces (TaskAccessTree)
3. Dossier parent assigne (avec la meme carte visuelle partout)
4. Etiquettes (avec header et prefixe #)
5. Contenu principal (description, texte memo, details evenement)
6. Rappels et recurrence (si applicable)
7. Pieces jointes (si presentes)
8. Historique et activite (commentaires, reactions)

Passer d'une tache a un memo puis a un evenement donne maintenant une continuite visuelle totale. Tu apprends une fois ou 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 regulier.

Les features invisibles font les apps qu'on garde

Personne ne lancera TAMSIV demain en se disant "oh genial, l'ecran de detail de la tache est aligne avec celui du memo". 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'ecran marketing. Aucun nouveau bouton a montrer. Aucune animation cinematique. Et pourtant, c'est exactement le type de travail qui fait la difference entre une app qu'on installe et qu'on oublie, et une app qu'on garde et qu'on recommande.

Les 10 jours precedents, c'etait un systeme d'emails transactionnels complet. Les 3 jours suivants, c'etait l'uniformisation des trois ecrans de detail. 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 benefice de cette uniformisation, c'est qu'elle ouvre la voie a des features futures bien plus rapidement. Quand les trois ecrans partagent la meme structure, ajouter une nouvelle section (par exemple un encart "traduit automatiquement" pour un memo vocal dans une langue differente) 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 a negocier. Apres, c'est une composante partagee qui s'injecte dans tous les ecrans de detail. Le cout marginal d'ajouter une nouvelle feature est divise par trois.

C'est le vrai beneficiaire cache de cette semaine : pas l'utilisateur d'aujourd'hui qui verra juste une app plus coherente, mais le developpeur solo qui construira les 40 prochaines features en trois fois moins de temps.

Et pendant ce temps, 22 anciennes redirections SEO

En parallele de l'uniformisation des ecrans, j'ai corrige un probleme de redirection sur le site. Les premieres passes de traduction du blog avaient laisse 22 slugs obsoletes en DE, ES, IT et PT, qui renvoyaient des 404 sur Google. Chaque slug obsolete est maintenant redirige de facon permanente (301) vers sa version actuelle.

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

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

Questions frequentes

Uniformiser les ecrans de detail rend-il l'app plus rapide ?

Techniquement, marginalement. Les composants partages sont rendus en cache plus efficacement, et le bundle Javascript diminue d'environ 3% grace a la deduplication 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 tot ?

Parce que tant que les trois ecrans evoluaient separement et qu'on ne savait pas encore quelles sections allaient emerger comme transverses, essayer d'uniformiser aurait ete premature. Il fallait d'abord que chaque ecran decouvre ses propres besoins, puis extraire les patterns communs une fois qu'ils etaient stables.

Quel impact pour quelqu'un qui utilise TAMSIV pour la premiere fois ?

Un nouveau venu apprend l'ecran de tache d'abord. Avant le refactor, il devait ensuite re-apprendre l'ecran de memo et l'ecran d'evenement. Apres, il reconnait instantanement les elements, et sa courbe d'apprentissage passe de trois paliers a un seul. L'onboarding est divise par trois en temps percu.

Est-ce qu'un utilisateur va voir la difference ?

Probablement pas consciemment. Le refactor est concu pour etre invisible. Mais si on demande a un utilisateur qui utilisait l'app avant et apres de nommer ce qui a change, il dira souvent "l'app me semble plus coherente" ou "je trouve mes infos plus facilement", sans savoir expliquer exactement pourquoi.

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

Un audit complet a ete fait apres le deploiement. Aucune regression fonctionnelle detectee. Les animations de transition entre ecrans ont meme ete legerement fluidifiees car les composants partages permettent un rendu plus predictible 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'evoluer chaque jour, majoritairement en silence. Ce sont les 80% invisibles qui font qu'elle reste installee.