Le contexte : une démarche « inclusive » impliquant la suppression de termes connotés. Liste blanche et liste noireentre autres, sont aussi dans le viseur, avec l’idée de les remplacer par liste d’autorisation et liste de refus.
D’autres projets de la famille Red Hat ont connu des modifications de même teneur. Par exemple Ansible, l’an dernier.
Principal remplacer Master
Pour toutes les organisations, la branche par défaut s’appelle désormais principale et non plus Maître. Liste blanche et liste noire sont respectivement devenus activé et rejeter. Tandis que machine maître est devenu machine de contrôleur, dans la documentation… mais aussi dans le code. Avec, dans ce dernier cas, un temps d’adaptation : quatre versions d’ansible-core pendant, 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 bureau de référence dans le domaine de la terminologie des projets informatiques. Au cœur de sa boîte à outils, un cadre issu de la communauté Kubernetes et adapté pour couvrir d’autres technologies.
Inclusive Naming Initiative : un groupement, un cadre
Ce cadre 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 correspondent aux termes qu’on peut considérer comme les plus urgents à modifier. Le couple liste blanche/liste noire je comprends. Avec, comme substituts proposés, liste d’autorisation/liste de refus et autorisésNos/refuséNoms. Le duo maître/esclave y figure aussi. Avec, comme supplétifs proposés, manette/auteur, primaire/réplique, primaire/secondaire, chef/disciple ou encore parent/enfant. Troisième terme classé dans cette catégorie : avorterqu’on conseille de remplacer par annuler, échouer, fin, arrêtetc.
Dans les grandes lignes, le cadre 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 sensiblement 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 domaines technologiques… Exemple : verification sanitaireà la place préférée l’INI préconise test de confiance, contrôle de cohérence, test ous vérification.
Au niveau 3 se trouvent des termes flous, métaphoriques ou qui anthropomorphisent du code ou des machines. Exemple : séparerà la place préférée l’INI préconise segment ous séparé.
Le cadre 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 configuration
– 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/enfant. « Attention : parfois, ce sont les parents qui dépendent des enfants », peut-on lire en commentaire. Le tout accompagné d’une alternative : arbre/bifurquer ous bifurquer/feuille. 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 normes.
Ce document place aussi les paires liste blanche/liste noire et Maître/trimer en tête des préoccupations. Certaines options qu’il inclut sont différentes de celles que proposent Red Hat et l’INI.
Par exemple, bloquer/permis pour la première paire. Et, pour la deuxième, actif/veille, écrivain/lecteur ous coordinateur/ouvrier. On y trouve aussi une section sur les termes à caractère métaphorique, comme l’homme au milieuqu’on suggère de remplacer par attaquant sur le chemin. 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 des Python concernées. Elle avait donné lieu, en 2018, à l’abandon du terme Maître. La question s’est posée pour des dérivés tels webmestre, maître de poste, original, la clef maitresseetc. Et pour d’autres termes comme tuer. 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, primaire/réplique avait fini par prendre la suite de Maître/trimer. Non sans opposition. Certains avaient proposé de ne supprimer que trimer, considéré comme le plus connoté. D’autres avaient appelé à s’en tenir au contexte technologique.
La même année, Django (cadre Python) avait remplacé Maître/trimer par chef/disciple… lui-même remplacé peu après par primaire/réplique. Toile de fond à ce retour : 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 disciple et trimer. Tandis que PostgreSQL faisait de même entre Maître/trimer et primaire/Etre prêt.
Le « débat Django » avait donné lieu à un questionnement plus large : jusqu’où revoir la terminologie ? Faut-il aussi arrêter de parler de cours ? 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. Maître/trimer peut s’appliquer autant à l’opposition entre les serveurs actifs et en veille qu’à des serveurs d’écriture et de lecteur. Ou à une application orchestrant de multiples répliques.
GitHub est aussi une prise de mesures. À commencer par le renommage de la branche par défaut, doublée d’une redirection des privilèges et de paramètres additionnels pour les utilisateurs. Git a enclenché des démarches similaires.
