Pourquoi un nom se mesure en pixels et non en caractères
Le budget d'un nom d'interface se calcule en pixels, parce que chaque lettre n'occupe pas la même largeur. Je développe Dynasty Nova, un jeu de stratégie spatiale par navigateur. En reprenant les 61 noms de ses bâtiments, recherches, vaisseaux et défenses, une question simple s'est posée : combien de lettres tient une carte ?
La réponse habituelle est une limite en caractères, du genre « 20 maximum ». Elle ne survit pas au test de la vraie carte. Dans la version de travail de nos noms, « Manipulation Ionique » compte 20 caractères et mesure 146 px. « Projecteur balistique » en compte 21 et n'en mesure que 143. Le nom le plus long est le plus étroit.
D'où vient un seuil de 147 px
Un seuil de largeur vient du composant qui affiche le nom, jamais d'une préférence de style. Ici, la carte compacte pose le nom sur une seule ligne, tronquée par des points de suspension. Le bandeau garde une gouttière de 16 px de chaque côté.
Le calcul de la place réelle
Sur le viewport de référence de 414 px, la vignette de la carte fait 179 px de large. On retire deux gouttières de 16 px : 179 − 32 = 147 px utiles. Tout nom plus large est coupé, et personne ne lira la fin de « Navigation Transdimensionnelle ».
La mesure avec la vraie police
La largeur se mesure avec la police du produit, à sa taille réelle, jamais avec une moyenne. Ici, c'est du Lexend Regular en 14 px. À titre indicatif, 147 px correspondent à environ 20 caractères, pour une avance moyenne de 7,25 px par lettre. Ce repère aide à écrire, mais seule la mesure tranche.
Ce que la mesure a révélé sur les noms existants
Sur les 61 noms de la production, 16 dépassent le seuil de 147 px. Le jeu avait cherché un équivalent original à chaque nom commun. Il y a perdu deux choses : la lisibilité de la fonction et la place dans la carte.
Le problème ne touche pas tout le catalogue. La médiane des 61 noms est de 133 px, donc sous le seuil. Il se concentre sur quelques noms très longs : « Navigation Transdimensionnelle » occupe 221 px, soit 50 % de plus que la place disponible.
Figer la grille avant de proposer un seul nom
Une grille d'acceptation de textes se fige avant qu'un seul nom soit proposé, sinon elle justifie les choix au lieu de les mesurer. C'est le principe de la grille d'acceptation des images générées par IA, appliqué ici aux textes. La nôtre date du 17 septembre 2026.
Des portes mécaniques, une réponse binaire
Chaque porte répond par oui ou non, sans note. La largeur en est une. Trois autres portes automatiques complètent le contrôle :
- Collision → pas de mot partagé avec une entrée non liée dans l'arbre des technologies ;
- Mot creux → aucun radical porté par trois entrées ou plus (« stellaire » apparaissait quatre fois, dans trois familles) ;
- Nomenclature → deux éléments par nom pour les bâtiments et les recherches, vérifiés sur 37 noms sur 37.
Le choix entre deux noms recevables reste un jugement humain. La grille écarte, elle ne désigne pas le meilleur.
Exécuter la grille sur l'existant avant de s'y fier
Une porte qui ne rejette rien ne mesure rien, et on le découvre en l'exécutant sur les noms existants. La porte « rang » devait vérifier qu'un mot d'échelle (corvette, croiseur, cuirassé) suit l'ordre réel des structures. Exécutée, elle ne rejetait personne : elle est devenue un simple diagnostic.
Une autre porte, la « notion du code », a été retirée le jour même. Elle ramenait les noms vers ceux d'OGame, l'inverse du but. Chaque changement de la grille est daté et justifié, et les noms déjà jugés sont rejugés.
Le nom n'est que la moitié du texte
Une carte d'interface porte au moins deux textes distincts, et chacun a son propre budget. Le nom tient sur une ligne. La tagline de la carte et la description longue de la fiche sont deux fentes différentes, avec deux contraintes différentes.
La tagline : 155 px sur quatre lignes
La tagline de la carte dispose de 155 px de large sur quatre lignes, puis elle est coupée net. Le calcul est le même que pour le nom : 179 px de colonne moins 24 px de marge droite. Le corpus écrivait 57 mots en médiane et n'en montrait que onze. Quarante-quatre entrées sur 61 mettaient le même paragraphe dans les deux fentes.
La description longue : la première phrase avant le pli
Dans la fiche, la description se replie sur trois lignes avec un lien « Voir plus ». Sur le viewport de référence, il reste 318 px de large, soit environ 119 caractères avant le pli. Un lecteur curieux déplie, mais tout le monde lit la première phrase : elle doit se suffire à elle-même.
J'ai donc ajouté une porte « ouverture » : la première phrase tient avant le pli. Sur la version de travail, la part moyenne du texte visible avant le pli passe de 27 % en production à 52 %.
Appliquer la méthode à votre propre interface
Cette méthode se transpose à tout composant dont le texte est contraint : carte, liste, bouton, onglet, notification. Six étapes suffisent.
- Mesurez la place réelle du composant, avec sa gouttière et sa troncature éventuelle, pas celle de la maquette ;
- Fixez le seuil en pixels, et notez l'équivalent en caractères comme simple repère ;
- Mesurez avec la vraie police à sa taille réelle, par exemple avec
getBoundingClientRectoucanvas.measureTextdans le navigateur ; - Séparez les fentes : un texte pour la carte, un autre pour la fiche ;
- Faites tenir l'essentiel avant le pli des textes repliables ;
- Figez le seuil avant d'écrire, puis exécutez-le d'abord sur l'existant.
Un nom qui déborde n'est pas un problème de style, c'est un défaut mesurable. La même logique guide la densité d'une interface : on juge un élément là où il s'affiche, pas sur la maquette.
