Ce qu'on gardait pour soi

Il y a deux façons de cacher quelque chose. La première est délibérée. La seconde, beaucoup plus fréquente, consiste à poser une chose au premier endroit venu et à ne plus jamais y penser.

Notre changelog vivait dans la console d'administration, derrière une session. Cent-vingt-neuf entrées, écrites une par une depuis des mois, décrivant précisément ce que la plateforme sait faire de plus qu'il y a trois semaines. Personne, en dehors de l'équipe et des clients connectés, ne pouvait les lire. Notre feuille de route non plus — elle était même repliée, en haut de cette page, dans un bloc qu'il fallait penser à ouvrir.

Aucune de ces deux décisions n'avait été prise. Elles s'étaient produites.

Le paradoxe du prospect

La question que pose un prospect n'est presque jamais « qu'est-ce que ça fait ? ». Il le voit sur la page des fonctionnalités. Sa vraie question, celle qu'il pose rarement à voix haute, est : est-ce que ce truc est vivant ?

Un outil abandonné ressemble beaucoup à un outil récent. Même page d'accueil, mêmes promesses, mêmes captures d'écran. La seule différence observable de l'extérieur, c'est le rythme — et le rythme, ça se prouve avec des dates.

Nous avions cette preuve. Cent-vingt-neuf fois. Derrière un formulaire de connexion.

Une feuille de route qu'on lit ne bouge pas

Le second problème était plus embarrassant, parce qu'il était interne.

Notre feuille de route est honnête — c'est même sa seule règle. « Fait » y veut dire utilisable par un client, pas « le code existe ». « Partiel » porte toujours ce qui manque, précisément. Elle a été refondue une fois déjà parce qu'elle mentait par omission : une trentaine de lignes marquées « à faire » l'étaient depuis longtemps, et une feuille de route fausse est pire qu'absente, puisqu'on cesse de la lire.

Sauf qu'une feuille de route juste qu'on se contente de lire ne bouge pas non plus. Elle vivait à côté du travail réel : d'un côté un tableau de tâches où l'équipe passe ses journées, avec des cartes assignées, chronométrées, bloquées, déplacées ; de l'autre une liste immobile, consultée peut-être une fois par semaine, mise à jour à la main quand quelqu'un y pensait.

Elle est maintenant projetée dans le tableau. Une ligne devient une carte, dans trois colonnes — à faire, partiel, fait. Le geste se rejoue autant qu'on veut : le rapprochement se fait par titre, une carte déjà présente retrouve sa colonne et garde tout ce que l'équipe y a posé. Assigné, priorité, échéance, temps passé, commentaires : rien n'est écrasé.

Ce détail-là n'est pas un détail. Une synchronisation qui écrase le travail humain se lance une fois, puis plus jamais — et l'outil meurt sans qu'on ait le courage de le retirer. Elle ne supprime rien non plus : une carte qui ne correspond plus à aucune ligne est signalée, jamais effacée. Trancher entre « ligne renommée » et « carte ajoutée à la main » demande de savoir ce qu'on voulait ; un programme ne le sait pas.

Le sticky qui ne collait à rien

Dans la même passe, un défaut d'interface qui mérite d'être raconté, parce qu'il illustre une classe entière de bugs qu'aucun test ne voit.

Notre documentation compte plus de soixante-dix pages. Le lecteur affichait trois colonnes : le menu à gauche, le texte au milieu, le sommaire de la page à droite. La colonne de gauche était censée rester collée en haut de l'écran pendant qu'on descend dans un article — un sticky top-4, écrit là, visible dans le code.

Elle défilait avec la page.

La raison est mécanique : un élément collant a besoin d'un parent plus haut que lui. C'est dans cet espace-là qu'il « glisse ». Or notre colonne collante était posée à l'intérieur d'un conteneur qui était lui-même déjà collant, et dont la hauteur épousait exactement son contenu. Il n'y avait aucune marge de manœuvre. La propriété était bien appliquée ; elle n'avait simplement rien à faire.

C'est le même motif que le menu invisible dont nous parlions il y a quelques jours : rien n'est cassé, tout se rend, aucun test ne remonte quoi que ce soit — et le résultat à l'écran est faux. On ne trouve ces défauts-là qu'en regardant, jamais en compilant.

Et le texte a repris de la place

Tant qu'à ouvrir le capot : la troisième colonne est partie. Le texte était borné à soixante-douze caractères de large, ce qui est une excellente mesure pour de la prose — et une mesure absurde pour des pages remplies de tableaux et de blocs de code, qui se retrouvaient pincés sur un tiers de l'écran pendant que deux listes de liens occupaient le reste. Le sommaire de la page a rejoint la colonne de gauche, sous le menu, et le contenu a récupéré sa largeur.

Le menu, lui, a changé de voix. Ses intitulés étaient composés dans notre police de titre, en capitales : une signature de marque, parfaite sur trois mots, appliquée à soixante-dix noms de pages empilés dans une colonne étroite. Les titres se coupaient. Ce n'était plus une identité, c'était du bruit. Il porte désormais la police de lecture, en casse normale.

La règle n'a pas changé pour autant — un libellé isolé garde sa police de titre. C'est la longueur de la liste qui fait basculer, pas la nature de l'élément. Une charte graphique qui ne prévoit pas ses propres exceptions se fait contourner en silence, et ça finit toujours plus mal.

La leçon, s'il y en a une

Aucun de ces quatre problèmes n'était un bug. Le changelog fonctionnait. La feuille de route était exacte. La colonne collante appliquait sa propriété. Le menu affichait la bonne police.

Ils avaient tous la même forme : une décision juste, prise dans un contexte qui a changé, et jamais rouverte. Le changelog dans la console — quand il n'y avait que nous pour le lire. La feuille de route à côté du travail — quand elle tenait en dix lignes. Une mesure de lecture bornée — avant que la documentation ne se remplisse de tableaux. Une police de titre dans le menu — quand le menu comptait six entrées.

Ce sont les décisions les plus difficiles à voir, parce qu'elles ne produisent aucune alerte. Le seul moyen que nous ayons trouvé, c'est d'écrire pourquoi à côté de chaque choix, dans le code lui-même. Un commentaire qui dit ce que fait la ligne n'apprend rien. Celui qui dit quelle contrainte l'a imposée permet, six mois plus tard, de vérifier si la contrainte existe encore.

Le changelog est désormais lisible par tout le monde, la feuille de route aussi. Vous saurez donc si nous continuons.