Le bug que rien ne signale

« J'ai toujours un souci avec les dropdown qui sont invisibles quand je clique dessus. » Une phrase, aucune capture, aucun écran nommé. Et un défaut qui, vu du code, n'existait pas.

Chercher un défaut qui n'en est pas un

Le premier réflexe a été d'automatiser : ouvrir chaque menu de la console, sur vingt pages, en thème clair et sombre, sur grand écran et en 390 pixels, puis mesurer. Le panneau est-il opaque ? Oui. Est-il dans l'écran ? Oui. Quelque chose le recouvre-t-il ? Non. Sa taille est-elle nulle ? Non.

Le balayage n'a rien trouvé. Deux fois. Ce qui aurait pu passer pour une bonne nouvelle était en réalité le cœur du problème : je cherchais une panne, et il n'y en avait pas. Le menu fonctionnait parfaitement. Il était simplement de la même couleur que ce qu'il y avait derrière.

Deux couleurs à un pour cent l'une de l'autre

Notre interface est sombre par parti pris. Le fond de page est un presque-noir ; la bordure standard est un presque-noir légèrement moins noir. Entre les deux, un rapport de contraste de 1,07 pour 1 — la limite du visible étant, selon les usages, autour de 3 pour 1.

Un panneau de menu portait le fond de page comme fond, et cette bordure-là comme seule délimitation. Et notre charte interdit les ombres portées : le parti pris est plat et anguleux. Résultat mécanique : un menu qui a exactement la couleur de la page, entouré d'un trait qu'on ne perçoit pas. On clique, du texte apparaît, et rien n'indique qu'il y a un panneau. Sur une zone vide, on peut croire qu'il ne s'est rien passé.

Ce n'est ni une erreur de code, ni une erreur de composant. C'est la rencontre de deux décisions justes prises séparément — une palette très resserrée dans les noirs, et un refus des ombres — dont personne n'a calculé le produit.

La correction qu'il ne fallait pas faire

La réponse évidente est d'éclaircir le panneau : on le décolle du fond, l'affaire est réglée. Sauf que la teinte immédiatement plus claire est déjà employée — c'est celle du survol d'une entrée de menu. Éclaircir le panneau jusqu'à elle aurait rendu le survol invisible à son tour. On aurait déplacé le défaut d'un cran, et on l'aurait retrouvé un mois plus tard sous une autre formulation.

La bonne correction était donc l'autre : garder le fond, rendre le bord visible. Une bordure dérivée de la couleur inverse — claire sur le sombre, sombre sur le clair — qui suit le mode d'affichage au lieu d'en privilégier un. Pas d'ombre réintroduite : la charte reste ce qu'elle est.

Ce qu'un test peut et ne peut pas voir

Nos tests relisent le code et refusent des motifs qui ont déjà cassé la production une fois. Ils sont efficaces contre les régressions de structure : une route sans filtre, un composant hors de son emplacement, une page sans bouton de menu. Ils sont aveugles à ceci, parce qu'il n'y a rien de structurellement faux à écrire.

Le garde-fou ajouté ne vérifie donc pas que le menu existe — il vérifie qu'aucun panneau flottant ne s'appuie sur la bordure de page pour se détacher, et que la correction ne s'inverse pas vers la mauvaise solution. C'est une règle de rapport entre deux décisions, pas une règle sur une ligne de code. Elle a été validée en réintroduisant le défaut, comme toutes les autres.

Ce que ça dit du reste

Il y a une catégorie de défauts que les outils ne verront jamais : ceux où tout fonctionne. Un contraste trop faible, une hiérarchie visuelle inversée, un libellé qui ment, un bouton parfaitement placé pour le pouce droit et hors d'atteinte du gauche. Ils ne se trouvent qu'en regardant, ou en écoutant quelqu'un qui regarde.

C'est aussi pour ça qu'un signalement en une phrase, sans capture et sans écran nommé, vaut mieux que pas de signalement du tout.