Open source : esclave, liste noire… Quand la terminologie pose question

Mi-mai, Red Hat Enterprise Linux 9 faisait son entrée en version stable. Parmi les changements, il y en avait un d’ordre terminologique : dans l’API de configuration réseau NMstate, slave devenait port.

Le contexte : une démarche « inclusive » impliquant la suppression de termes connotés. Whitelist et blacklist, entre autres, sont aussi dans le viseur, avec l’idée de les remplacer par allowlist et denylist.

D’autres projets de la famille Red Hat ont connu des modifications de même teneur. Par exemple Ansible, l’an dernier.

Main remplace Master

Pour toutes les organisations, la branche par défaut s’appelle désormais main et non plus master. Whitelist et blacklist sont respectivement devenus enabled et reject. Tandis que master machine est devenu controller machine, dans la documentation… mais aussi dans le code. Avec, dans ce dernier cas, un temps d’adaptation : quatre versions d’ansible-core pendant lesquelles les termes en question resteront utilisables, en complément aux nouveaux.

Cette « période de transition » est l’un des éléments sur lesquels insiste l’Inclusive Naming Initiative (INI). Réunissant notamment Cisco, IBM, Intel, Microsoft et VMware, le groupement fait office de référence dans le domaine de la terminologie des projets informatiques. Au cœur de sa boîte à outils, un framework issu de la communauté Kubernetes et adapté pour couvrir d’autres technologies.

Inclusive Naming Initiative : un groupement, un framework

Ce framework permet d’évaluer la « sensibilité » des termes en tenant compte de leur étymologie et de leurs connotations culturelles. Il les classe sur trois niveaux.

Le niveau 1 correspond aux termes qu’on peut considérer comme les plus urgents à modifier. Le couple whitelist/blacklist y figure. Avec, comme substituts proposés, allowlist/denylist et allowedNouns/deniedNouns. Le duo master/slave y figure aussi. Avec, comme supplétifs suggérés, controller/doer, primary/replica, primary/secondary, leader/follower ou encore parent/child. Troisième terme classé dans cette catégorie : abort, qu’on conseille de remplacer par cancel, fail, end, halt, etc.

Dans les grandes lignes, le framework amène à classer un terme au niveau 1 si on répond par l’affirmative aux questions suivantes :

– Hors des contextes technologiques, le terme se réfère-t-il à un groupe de personnes ?
– Est-il potentiellement dénigrant hors desdits contextes ?
– Même s’il n’est pas directement nocif, divise-t-il nettement l’opinion ?

Les termes classés au niveau 2 répondront plutôt aux critères suivants : classistes ou ségrégationnistes, militairement connotés, associés à un genre, d’héritage facilement identifiable hors domaine technologique… Exemple : sanity check, à la place duquel l’INI préconise confidence check, coherence check, test ou verification.

Au niveau 3 se trouvent des termes flous, métaphoriques ou qui anthropomorphisent du code ou des machines. Exemple : segregate, à la place duquel l’INI préconise segment ou separate.

Le framework  doit s’assortir d’une méthode qui implique en premier lieu de distinguer quatre types de termes. Nommément, ceux qui :

– N’ont pas d’impact sur le code (= « non fonctionnels »)
– Ne servent qu’en interne (variables et fonctions locales, par exemple)
– Sont exposés en externe par API ou fichier de config
– Sont des dépendances pour d’autres projets

L’IETF a sa liste… et ses doutes

Les comptes rendus (2021, 2022) des sessions de l’INI sont publics. Ils laissent entrevoir les débats qui s’y tiennent. Par exemple pour le doublet parent/child. « Attention : parfois, ce sont les parents qui dépendent des enfants », peut-on lire en commentaire. Le tout accompagné d’une alternative : tree/branch ou branch/leaf. On peut aussi constater que le débat terminologique va au-delà des concepts purement logiciels : le cas des connecteurs mâles et femelles est par exemple évoqué.

D’IBM à la Fondation Linux, l’INI fait mention de quelques démarches annexes à la sienne. Elle signale aussi l’existence d’un document de référence au niveau de l’IETF (Internet Engineering Task Force), censé guider l’organisme dans l’élaboration de standards.

Ce document place aussi les paires whitelist/blacklist et master/slave en tête des préoccupations. Certaines des options qu’il inclut sont différentes de celles que proposent Red Hat et l’INI.

Par exemple, block/permit pour la première paire. Et, pour la deuxième, active/standby, writer/reader ou coordinator/worker. On y trouve aussi une section sur les termes à caractère métaphorique, comme man-in-the-middle, qu’on suggère de remplacer par on-path attacker. Et, en guise de sources de réflexion, diverses discussions qui ont eu lieu dans des communautés open source.

Parmi ces discussions, l’une a concerné Python. Elle avait donné lieu, en 2018, à l’abandon du terme master. La question s’est posée pour des dérivés tels webmaster, postmaster, master copy, master key, etc. Et pour d’autres termes comme kill. Sans qu’il y ait de suite pour ces différents cas.

Langage inclusif : vers un élan commun ?

Le « débat Python » s’est lui-même nourri de discussions plus anciennes auxquelles le document IETF fait aussi référence. Par exemple chez Drupal, où, à la mi-2014, primary/replica avait fini par prendre la suite de master/slave. Non sans opposition. Certains avaient suggéré de ne supprimer que slave, considéré comme le plus connoté. D’autres avaient appelé à s’en tenir au contexte technologique.

La même année, Django (framework Python) avait remplacé master/slave par leader/follower… lui-même remplacé peu après par primary/replica. Toile de fond à ce retournement : la crainte de certains que la première terminologie adoptée ne soit pas compréhensible par tous. Un élément qui se serait ajouté à l’absence de nomenclature commune avec d’autres projets. Heroku, par exemple, employait alors interchangeablement follower et slave. Tandis que PostgreSQL faisait de même entre master/slave et primary/standby.

Le « débat Django » avait donné lieu à un questionnement plus large : jusqu’où revoir la terminologie ? Faut-il aussi arrêter de parler de classes ? d’objets ? Questionnement qu’on a retrouvé la même année sur CouchDB… où on est allé jusqu’à suggérer qu’il valait mieux « fermer Internet », dont certains termes sujets à controverse constituaient la base. Puis quelque temps plus tard dans la communauté Redis.

Avec une réponse dominante : cela dépend des projets, de leur fonctionnement, de leur architecture. Master/slave peut s’appliquer autant à l’opposition entre des serveurs actifs et en veille qu’à des serveurs d’écriture et de lecteur. Ou à une application orchestrant de multiples répliques.

GitHub aussi a pris des mesures. À commencer par le renommage de la branche par défaut, doublée d’une redirection des liens et de paramètres additionnels pour les utilisateurs. Git a enclenché des démarches similaires.