Depuis des décennies, l’ingénierie partage sans doute un principe de base : les noms comptent. Autrement dit, un pont, une valve, un composé chimique ou un instrument chirurgical reçoivent des noms qui disent quelque chose sur leur fonction, leur forme ou leur objectif. Personne n’attend de créativité littéraire dans un manuel technique : ce qu’on attend, c’est de la clarté. Cependant, selon le programmeur Salih Muhammed, quelque chose ne va pas dans le monde du logiciel ces dernières années.

Aujourd'hui, nous vivons avec des listes d'applications, de bibliothèques de développement et de plateformes cloud peuplées de serpents, de dieux nordiques, d'animaux et, en général, de mots qui n'ont absolument aucun sens par rapport à ce qu'ils font réellement.

Cette tendance, qui pour beaucoup peut paraître mignonne ou inoffensive, a selon Mahomet un coût bien réel que nous payons en attention, en mémoire et en effort mental. Il appelle cela une « taxe cognitive ». Confucius en parlait déjà dans ses « Entretiens » :

« Zǐ lù a dit : Si le monarque de Wèi décidait que le maître devienne souverain, que ferait le maître en premier ?

« Le professeur a dit : il faudrait rectifier les noms. »

« Zǐ lù a dit : feriez-vous cela ? le professeur est un pédant ! pourquoi les rectifier ? »

« Le professeur a dit : Parce que si les noms ne sont pas corrigés, alors les mots ne sont pas efficaces ; si les mots ne sont pas efficaces, alors les choses ne sont pas exécutées (…). »

Quand le nom cesse d'aider

Richard Stallman, l'une des figures historiques du logiciel libre, a souligné dans une récente conférence quelque chose qui devrait être évident, mais qui ne l'est plus : Les outils doivent avoir des noms qui vous aident à vous souvenir de ce qu'ils font..

Le problème n'est pas qu'il y ait un nom créatif ici ou là. Le problème est que l’exception est devenue la norme. Aujourd’hui, il est courant d’entendre des descriptions techniques qui ressemblent plus à un poème surréaliste qu’à une architecture informatique :

« Nous utilisons Viper pour la configuration, Cobra pour la ligne de commande, Melody pour WebSockets, Casbin pour les autorisations et Asynq pour les files d'attente de travail. »

Du point de vue de l'auditeur, cette phrase nécessite un effort supplémentaire immédiat : s'arrêter, mapper chaque nom à sa fonction réelle, consulter de la documentation ou effectuer des recherches mentales forcées. De tous les noms, seul le dernier a quelque chose à voir avec sa fonction : Asynq C'est une bibliothèque pour le traitement asynchrone des tâches et des files d'attente de travaux dans Go (file d'attente des travaux).

Dans une autre ingénierie, cela n'arriverait pas

Imaginons le même phénomène transféré à d'autres domaines. Un ingénieur civil ne parlerait pas de renforcer un bâtiment avec le système « ThunderFalcon ». Un cardiologue ne dirait pas qu’il va implanter un « Butterfly X » au lieu d’un stent coronaire. Et un chimiste ne nomme pas une molécule « Steve » pour la rendre drôle.

Quiconque a étudié la chimie sait, en effet, que la nomenclature des composés n'est pas quelque chose qui est laissé au hasard : il est préférable que quelque chose ait un nom long avant de ne pas savoir clairement à quoi on fait référence.

Durant les premières années de l’informatique, ce même principe était la norme. Des outils comme 'grep' (impression d'expressions régulières globales), 'soif' (éditeur de flux), 'diff' (différence) ou 'chat' (enchaîner) n’étaient pas très lyriques, mais fonctionnels. Les premiers langages de programmation suivaient également cette logique : FORTRAN, COBOL, BASIC, SQL. Même lorsqu’il y avait des abréviations, le sens était là.

Muhammed ne sait pas exactement quand le problème a commencé, mais il souligne que la dérive s'est accélérée avec deux phénomènes : la montée de la culture startup et la multiplication des logiciels ouverts sur des plateformes comme GitHub.

Nommer un produit de consommation avec un mot accrocheur a du sens lorsque des millions sont investis dans le marketing et le positionnement. « Google » a pu se permettre d'être un mot sans signification préalable car il est devenu un verbe fondé sur l'omniprésence. Mais une bibliothèque technique comptant quelques dizaines ou centaines d’utilisateurs ne dispose pas de ce coussin culturel.

Pourtant, de nombreux développeurs ont commencé à imiter ce style : le résultat est un écosystème saturé de noms qui ne décrivent rien et qui obligent tout le monde à faire un travail supplémentaire : quand quelqu'un tombe sur une dépendance appelée « libsodium », il doit s'arrêter et se demander « De quoi s'agit-il ? De la cryptographie ? Pourquoi « sodium » ? Est-ce une blague chimique ?

Ce petit effort mental ne nécessite que quelques secondes, il est vrai, mais dans un projet moderne, avec des dizaines ou des centaines de dépendances, ces secondes sont multipliées. Au cours d’une carrière professionnelle, cela implique des montagnes d’efforts mentaux consacrés non pas à résoudre de vrais problèmes, mais à déchiffrer des étiquettes arbitraires.

L'autre point de vue

Cependant, sur les forums HackerNews, tout le monde n'accepte pas qu'il y ait eu un « âge d'or » des bons noms qui a ensuite été perdu. En fait, l’une des réponses les plus votées le résume par une phrase dévastatrice :

« Cela n'est pas devenu incontrôlable pour les développeurs, nous ne l'avons jamais eu entre nos mains, point final. »

L'une des premières réactions du forum a été de démanteler l'idéalisation d'Unix « classique » et des premiers noms de logiciels. Des exemples sont cités tels que :

• GNU, un acronyme récursif (c'est-à-dire, s'incluant lui-même : « GNU's Not Unix »).
• awk, initiales du nom de famille (d'après ses créateurs Aho, Weinberger et Kernighan).
• dd, peut-être le cas le plus extrême : personne ne semble être d’accord sur ce que cela signifie réellement.

D’autres reconnaissent que tous n’ont pas de noms totalement dénués de sens. mais que beaucoup ne fonctionnent que dans un contexte historique et culturel bien précis… et que si on ne le sait pas, le nom cesse d'être un indice et devient un hiéroglyphe. Le cas de l'application 'Bison' est paradigmatique : il s'agit de la version GNU de Yacc (« Yet Another Compiler-Compiler »), qui sonne comme « yak » (un animal apparenté au bison).

La familiarité et la clarté ne sont pas les mêmes

Une idée qui revient dans le débat est que le sentiment que quelque chose est une « bonne réputation » est généralement rétrospectif : lorsqu'un outil est utilisé pendant des années, son nom devient transparent par pure habitude, et non parce qu'il est intrinsèquement bon.

De nombreux participants admettent sans vergogne qu’ils utilisent quotidiennement les applications susmentionnées sans se souvenir déjà – ou sans jamais savoir – de la signification de ces acronymes : ainsi, le nom cesse d’être sémantique et devient un simple identifiant arbitraire, comme le serait n’importe quel mot inventé.

De ce point de vue, le problème n’est pas tant le nom que le volume : aujourd’hui le nombre d’outils, de bibliothèques et de frameworks a explosé ; Il y a des milliers de nouveaux projets chaque année, et la charge cognitive ne vient pas du fait qu'un nom est rare, mais du trop grand nombre de noms à apprendre.

Marketing, recherche et référencement

Un autre argument récurrent est d’ordre pratique : le nom doit être unique et facile à trouver. Dans un monde dominé par les moteurs de recherche (et désormais aussi par les modèles linguistiques), appelez votre projet 'client http«Cela peut être descriptif, mais c'est une très mauvaise option lorsque vous souhaitez que l'utilisateur recherche de la documentation à ce sujet.

Cela ne justifie bien sûr pas l’utilisation de noms complètement arbitraires… mais cela explique pourquoi de nombreux développeurs recherchent des mots distinctifs, même au détriment d’une clarté immédiate.

Il n'y a donc pas de problème ?

Pas tout à fait. Même si de nombreux participants considèrent la plainte initiale comme exagérée, il existe également un consensus implicite : nommer les choses est difficile et bien le faire est rare.

Certains commentaires mettent en avant un point intermédiaire très intéressant : les noms fonctionnent mieux lorsqu’il y a un rapport, même métaphorique, avec ce que fait l’outil. Bison fonctionne parce qu'il s'agit de « GNU Yacc » ; le sodium car il provient de NaCl ; grep car il fait référence à une action spécifique dans ed.

Le problème surgit lorsque la relation disparaît complètement et que le nom devient un événement privé sans ancrage partagé.

À Xataka | Les numéros de version n'ont aucun sens : pourquoi certaines applications optent-elles pour la version 1.0 et d'autres pour la version 100.0 ?