devfool/studio
← blog
article2026-09-04·10 min de lecture

Nommer les choses : le plus petit des grands problèmes

Établi d'atelier avec étiquettes vierges, plume et encrier, sous lesquels flottent une cité miniature, une amphore et une ombre indistincte

Il existe, dans tout projet, un moment étrange : la chose existe déjà, et elle n'a pas encore de nom. Une cité qu'on voit très bien — ses quais, ses cordages, son odeur de goudron et de poisson séché — mais qu'on ne peut pas encore appeler. Une fonction dont on sait exactement ce qu'elle fait, et devant laquelle le curseur clignote parce qu'il faut bien écrire quelque chose entre le mot-clef et la parenthèse. Ce moment dure parfois trois secondes, parfois trois jours. On a tendance à le traiter comme une formalité administrative, une étiquette à coller sur un bocal déjà rempli. C'est à peu près l'inverse qui se produit.

Deux choses difficiles

Les programmeurs se transmettent depuis une vingtaine d'années une phrase attribuée à Phil Karlton, ingénieur chez Netscape : « There are only two hard things in Computer Science: cache invalidation and naming things. » Il n'y a que deux choses difficiles en informatique : invalider un cache, et nommer les choses. Le site tenu par sa famille rappelle que la formule n'est pas née devant un tableau blanc lors d'une revue d'architecture, mais sur le chemin du gymnase, avant un match de volley entre collègues. Les meilleures maximes de métier ont souvent cette origine-là.

La blague tient tout entière dans le contraste. L'invalidation de cache est un problème que tout le monde reconnaît comme redoutable : savoir quand une donnée conservée en mémoire a cessé d'être vraie relève parfois de la divination. À côté, nommer semble être une tâche de fin de journée, celle qu'on garde pour quand on est fatigué. Puis on essaie. Et l'on découvre que « nommer les choses » est un raccourci pour « comprendre exactement ce dont on parle et où passent les frontières ». Ce qui est, effectivement, la partie la plus difficile du travail.

Un mauvais nom ne fait pas planter le programme. Il fait pire : il installe un malentendu confortable. Une variable appelée data ou un personnage appelé « le Sage » vous laissent croire que la question est réglée alors qu'elle n'a même pas été posée. Six mois plus tard, quelqu'un — souvent vous — ouvrira le fichier et devra reconstituer par déduction ce que l'étiquette aurait dû dire. En fiction, le mécanisme est identique : un royaume nommé à la hâte devient un royaume dont on ne sait rien, et cette ignorance se propage à tout ce qu'on écrit ensuite.

Le nom colle-t-il à la chose ?

La question est vieille. Elle occupe un dialogue entier de Platon, le Cratyle, sous-titré selon les traditions « De la justesse des noms ». Deux positions s'y affrontent devant Socrate. Hermogène défend la thèse conventionnaliste : les noms sont des étiquettes, elles valent par l'accord de ceux qui les emploient, et l'on pourrait aussi bien appeler un cheval autrement. Cratyle, disciple d'Héraclite, soutient la thèse naturaliste : il existe pour chaque chose une dénomination qui lui est naturellement adaptée, et les noms en usage imitent, par leurs sons, la nature de ce qu'ils désignent. Socrate, fidèle à ses habitudes, ne donne raison ni tout à fait à l'un ni tout à fait à l'autre : il se livre d'abord à une longue série d'étymologies — les astres qui courent, thein, auraient donné les dieux, theoi — avant de nuancer sérieusement l'idée qu'on puisse atteindre les choses par leurs noms.

Ce qui m'intéresse ici n'est pas la solution du dialogue, mais le fait que sa question soit exactement celle de l'artisan. Puis-je appeler ma cité n'importe comment, ou bien existe-t-il, quelque part, un nom qui lui va ? La réponse pratique tient peut-être dans un compromis : à l'échelle du monde inventé, tout est convention, on décide ; à l'échelle du lecteur, tout est nature, il n'a que les sons. Il ne connaît pas la langue que vous avez ébauchée dans un carnet. Il entend des attaques dures ou molles, des voyelles ouvertes ou fermées, un rythme. Et il en tire, en une fraction de seconde, une hypothèse sur le climat, la rudesse, l'ancienneté du lieu. Cette hypothèse, vous ne la contrôlez qu'en amont, par le choix des sonorités. Après, il est trop tard.

L'enfant de la colère

Les Grecs ont poussé loin cette idée que le nom est un condensé de destin. Au chant XIX de l'Odyssée, la vieille nourrice Euryclée reconnaît Ulysse à la cicatrice de sa cuisse, et le récit remonte à la naissance du héros. C'est le grand-père maternel, Autolycos, qui le baptise : puisqu'il est arrivé lui-même irrité contre beaucoup d'hommes et de femmes sur la terre nourricière, que l'enfant porte le nom tiré de cette colère. Le verbe grec odyssomai dit à la fois haïr et être haï, et le nom d'Odysseus fait de lui, dès le berceau, l'enfant de la rancune — celui qui en inspirera et celui qui en subira.

Il faut être honnête sur le statut de cette étymologie : c'est une étymologie poétique, non une reconstruction linguistique. Les spécialistes considèrent l'origine du nom comme incertaine, possiblement pré-hellénique, donc étrangère au grec. Mais c'est justement ce qui la rend précieuse pour nous. L'étymologie antique ne cherchait pas l'origine historique d'un mot : elle cherchait à révéler un sens, à faire apparaître le lien entre un nom et un destin. C'est un geste de conteur, pas de philologue. Et c'est très exactement ce que fait un auteur quand il baptise un personnage en sachant ce qui l'attend au chapitre douze.

« Le nom vient d'abord »

Tolkien a formulé le renversement le plus radical sur ce point. Dans une lettre de 1955 destinée à préparer une notice pour le New York Times Book Review, il explique que l'invention des langues est le fondement de son travail, et que les histoires ont plutôt été faites pour fournir un monde aux langues que l'inverse. Il ajoute que, chez lui, le nom vient d'abord et que l'histoire suit.

On croit généralement qu'on nomme ce qu'on a inventé. Tolkien dit le contraire : le nom est parfois l'invention elle-même, et le récit n'est que la manière de découvrir ce que ce nom contenait déjà. On n'est pas obligé de bâtir deux langues complètes pour en tirer une méthode. Il suffit d'accepter que le vocabulaire soit un lieu de travail à part entière, au même titre que l'intrigue ou les personnages — et qu'un mot juste puisse produire une scène, une coutume, un conflit.

Un monstre nommé grue

L'histoire suivante devrait figurer dans tous les manuels de conception. À la fin des années 1970, au MIT, l'équipe de Zork a un problème de design : dans les zones obscures, il faut une conséquence. Sans lumière, le joueur ne doit pas simplement piétiner ; il doit risquer quelque chose. Dave Lebling, grand lecteur de Jack Vance, emprunte au cycle de la Terre mourante une créature nommée grue et l'installe dans le noir. Le jeu ne la décrit pratiquement jamais. Il se contente de signaler qu'il fait nuit noire et qu'on risque fort d'être dévoré. Vance, de son côté, avait probablement pêché le mot dans un verbe anglais archaïque, apparenté à celui qui a donné gruesome, et qui signifiait frissonner d'horreur.

Un nom a donc fait, à lui seul, le travail d'un paragraphe de description et d'une règle de jeu. Il est court, il sonne mal — au bon sens du terme —, il ne ressemble à rien de connu, et il porte en anglais un arrière-goût de frisson que le joueur ressent sans pouvoir le formuler. C'est le rendement maximal d'un choix lexical : deux syllabes, et le noir devient dangereux. Quarante-cinq ans plus tard, la phrase est devenue un mème (https://knowyourmeme.com/photos/1904561-super-smash-brothers-ultimate), ce qui est une manière statistique de mesurer la justesse d'un baptême.

Le langage omniprésent

Le développement logiciel a fini par théoriser cette exigence. Dans Domain-Driven Design (2003), Eric Evans propose la notion de langage omniprésent : un vocabulaire unique, rigoureux, partagé par les développeurs et par les gens du métier, et employé identiquement dans les réunions, dans la documentation et dans le code lui-même. L'idée de départ est une observation très simple : la plupart des malentendus coûteux naissent de la traduction permanente entre deux vocabulaires parallèles. Si l'expert dit « dossier » et que le code dit record, quelqu'un traduit en silence, et un jour la traduction se trompe.

Un monde de fiction souffre de la même maladie. Si la même monnaie s'appelle trois choses selon les chapitres, si un peuple change discrètement de nom entre la carte et le glossaire, ce n'est pas un détail d'édition : c'est le signe que le monde n'est pas encore stabilisé dans la tête de son auteur. La bible d'univers n'est rien d'autre qu'un langage omniprésent avec des majuscules.

Reste le geste le plus intimidant : renommer tard. Dans un environnement de développement, c'est un raccourci clavier, et les outils garantissent qu'aucune occurrence n'est oubliée. Dans un manuscrit, c'est un chercher-remplacer suivi d'une relecture inquiète, parce que le nom d'un lieu se décline, s'accorde, apparaît dans un jeu de mots trois cents pages plus loin. La difficulté technique n'est pas la même, mais la question morale est identique : accepte-t-on de payer aujourd'hui le prix d'une clarté qui servira pendant des années ?

Petite méthode, sans garantie

De tout cela, je tire quelques règles de travail, valables autant pour un module que pour une baronnie.

Prononcez le nom à voix haute. Le lecteur le fera intérieurement, et un nom imprononçable devient, dans sa tête, une forme visuelle floue qu'il saute — ce qui revient à effacer votre personnage.

Donnez à chaque nom important une attaque distincte. Deux noms qui commencent par la même syllabe dans le même chapitre se volent mutuellement leur relief, et le lecteur fatigué finit par les confondre.

Tenez une cohérence sonore par culture. C'est ainsi que le lecteur apprend une géographie sans jamais lire la carte : il entend qu'un lieu appartient au Nord.

Assumez les noms provisoires, mais marquez-les. Un TODO dans le code, un balisage voyant dans le manuscrit. Le nom temporaire non signalé est la meilleure façon de publier une place forte appelée « Machinville ».

Enfin, quand un nom résiste vraiment, ne forcez pas : c'est presque toujours que la chose elle-même n'est pas claire. Le blocage n'est pas un manque d'inspiration, c'est un diagnostic. Écrivez trois lignes sur ce que cette chose fait dans l'histoire, et le nom se présente souvent tout seul.

Ce que promet un nom

Sur la page des créations du studio cohabitent deux registres qui n'ont rien à voir : d'un côté Épeiros, Rhaelos, Quendi, les Skasimos ; de l'autre des outils qui s'appellent img-opti ou UberCron. Les uns cherchent à faire entendre une côte, une flotte, une menace ; les autres à dire en un coup d'œil ce que fait le programme. Mais la contrainte est la même, et elle est la plus vieille du métier : le nom est la première chose que rencontre celui qui arrive. Avant la première page, avant la première ligne de code, il promet quelque chose. Tout le reste du travail consiste à tenir cette promesse.

Et vous, quel est le nom qui vous a fait rester — celui d'un livre, d'un lieu, d'une créature — et qui, avant même de savoir de quoi il s'agissait, vous avait déjà convaincu ?

Sources