Navigation – Plan du site

AccueilNuméros18-2VariaQuand les mots font des choses

Varia

Quand les mots font des choses

Analyse d’une controverse sur la terminologie inclusive à l’Internet Engineering Task Force (IETF)
When words do things. Analysis of a controversy on Inclusive Terminology at the Internet Engineering Task Force (IETF)
Cuando las palabras hacen las cosas. Análisis de una controversia sobre terminología inclusiva en el Internet Engineering Task Force (IETF)
Wenn Worte Dinge tun. Analyse einer Kontroverse über inklusive Terminologie bei der Internet Engineering Task Force (IETF)
Stéphane Couture et Pauline Rudaz

Résumés

Toujours plus d’institutions choisissent d’adopter un langage dit « inclusif » et le domaine de l’informatique n’y fait pas exception. Ceci ne vient pas sans certaines oppositions. Cet article étudie une controverse concernant l’introduction d’un guide pour l’usage de termes inclusifs au sein de l’Internet Engineering Task Force (IETF), un organisme clé de la gouvernance d’Internet. Les principaux arguments en faveur d’une terminologie inclusive soutiennent son importance pour accroître la diversité. À l’inverse, les arguments s’y opposant soulignent que le changement n’est pas significativement efficace pour ce but, et qu’il est techniquement complexe. Ces différents arguments font par ailleurs écho à ceux mobilisés dans d’autres contextes, et notre recherche montre bien que les infrastructures d’Internet sont l’objet de débats qui participent de controverses sociétales en cours.

Haut de page

Texte intégral

Introduction

1En avril 2021, le New York Times faisait état d’une bataille dans les milieux informatiques pour remplacer des termes offensants et parfois racistes comme celui de « maître-esclave » (Conger, 2021). L’article soulignait notamment le fort débat qui avait lieu à ce moment au sein de l’Internet Engineering Task Force (IETF). Peu connue du grand public, l’IETF est cependant une organisation clé de la gouvernance d’Internet, dont le rôle est de discuter, développer et publier les grands standards techniques et les protocoles d'Internet. Elle regroupe surtout des chercheurs en informatique et des ingénieurs provenant de grandes entreprises de télécommunications comme Verizon, Comcast ou Huawei. Depuis quelques années cependant, des organismes de la société civile – depuis longtemps partie prenante des discussions entourant les aspects réglementaires et les politiques publiques en lien avec la gouvernance d’Internet (Massit-Folléa, 2014 ; Raboy, Landry & Shtern, 2010) – tentent de s’engager de plusieurs manières dans les discussions hautement techniques de l’IETF pour y élargir la prise en compte des aspects éthiques et sociaux. C’est ainsi qu’a eu lieu entre 2018 et 2021, un long débat sur les « terminologies offensantes » dans les nomenclatures concernant les protocoles d’Internet.

2Ce débat est un cas intéressant pour analyser l’articulation des valeurs au sein des protocoles et infrastructures informatiques, en particulier dans un contexte de revendications grandissantes pour la décolonisation des savoirs et des sociétés et de leurs critiques associées (pour le contexte français, voir par exemple Blancel & Blanchard, 2022 ; Cohen & Simon, 2012). Sur le plan d’une anthropologie des techniques, l’analyse permet également de porter le regard sur les modes d’existence des protocoles informatiques, des artefacts ayant comme particularité d’agir en tant que spécification pour le développement d’applications ou d’architectures, mais qui existent également comme texte écrit – et donc lisible – dans un langage humain (l’anglais, la plupart du temps). Le choix d’aborder la terminologie inclusive permet ainsi de nous intéresser à l’aspect textuel des protocoles informatiques. Cet article cherche à répondre aux questions de recherche suivantes : comment les débats sociétaux sur l’utilisation de terminologies inclusives s’expriment-ils dans les milieux informatiques, et plus spécifiquement dans le cadre du développement de protocoles au sein de l’IETF ? Quelles sont les spécificités des documents et artefacts concernés par ces délibérations au sein de l’IETF ? Comment ces délibérations nous renseignent-elles sur l’articulation des valeurs au design des infrastructures numériques en général et des protocoles d’Internet en particulier ?

3Après avoir présenté notre cadre théorique et méthodologique, puis décrit la controverse, nous faisons ressortir trois niveaux d’analyse de celle-ci : 1) le débat lui-même comme catalyseur de mobilisation pour une plus grande diversité ; 2) le discours sur le pouvoir du langage ; 3) le statut ontologique des objets concernés (les « standards d’Internet » exprimés dans les documents nommés Request for Comments). Nous cherchons donc à contribuer aux études qui s’attardent au formatage matériel et technique des infrastructures d’Internet en analysant, plus précisément, la manière dont un artefact particulier spécifiant le fonctionnement d’Internet est également pétri de normes et de valeurs et évolue dans le même sens que les controverses sociales en cours.

Cadre théorique et méthodologique

Valeurs et politiques du design technologique

4Notre analyse s’inscrit dans le cadre de réflexions plus larges sur l’articulation des valeurs au design des technologies et infrastructures numériques et sur les interventions réalisées pour transformer ces configurations sociotechniques. De nombreux travaux ont montré que les technologies, en particulier celles constituant l’architecture d’Internet, sont loin d’être neutres, mais sont au contraire chargées de valeurs. Empiriquement, plusieurs travaux se sont par exemple consacrés à l’analyse des algorithmes (Cardon, 2013 ; Noble, 2018) et plus près de notre sujet, aux catégories et standards utilisés dans les infrastructures d’information (Bowker & Star, 2000). Star (2018, §44) soutient ainsi qu’« en matière d’infrastructure informationnelle, toutes les formes imaginables de variation dans la pratique, la culture et les normes sont inscrites au plus profond de la conception elle-même », que ce soit par exemple au niveau des choix de nomenclature, de réponse d’un formulaire, ou des indicateurs choisis pour rendre compte d’une réalité. Star note par exemple que ce n’est qu’en 2000 que les citoyen.es étasunien.nes ont pu cocher un choix de « race » dans les formulaires de recensement aux États-Unis (ce qui n’est pas le cas en France par exemple). DeNardis (2009) écrit pour sa part que « les décisions inscrites dans les protocoles intègrent des valeurs et reflètent les intérêts socioéconomiques et politiques des développeurs » (p. 10, notre traduction). D’ailleurs, s’appuyant sur ces réflexions, Musiani et al. (2015) constatent un « tournant vers les infrastructures dans la gouvernance d’Internet », notamment caractérisé par des recherches portant sur les valeurs et les normes au sein des infrastructures numériques.

5Dans une perspective similaire, des autrices ont plus spécifiquement mis l’accent sur les biais racistes véhiculés par les systèmes numériques (Benjamin, 2019 ; Noble, 2018 ; Nakamura & Chow-White, 2012). Benjamin (2019) soutient par exemple que plusieurs technologies numériques mettent en œuvre un nouveau « code Jim », en référence aux lois dites « Jim Crow » qui imposaient la ségrégation raciale aux États-Unis jusque dans les années 1960. Noble (2018) remarque que les algorithmes de recherche mettent en avant des résultats racistes, ce qui s’explique selon elle par le fait que la plupart des personnes qui y travaillent et occupent des postes importants sont encore et toujours des hommes blancs. Ce constat soulève ainsi l’importance pour le design de favoriser la diversité chez les personnes qui conçoivent les systèmes informatiques, de manière notamment à éviter les biais inconscients. Benjamin met toutefois en garde contre le « tokénisme » consistant à favoriser la diversité simplement à des fins rhétoriques ou promotionnelles. Elle note que les personnes qui définissent les « standards d’expression » (expression standards) ont le pouvoir sur toutes les autres qui doivent ainsi changer leur propre code d’expression (code-switching) ou être exclues. L’autrice appelle donc à transformer les normes dominantes plutôt que d’obliger les individus à se conformer à ces normes qui contribuent à reproduire un certain ordre raciste.

6Sur la question des interventions visant à transformer les configurations sociotechniques, mentionnons finalement les réflexions d’auteurs qui interrogent les modalités selon lesquelles les technologies, plateformes et infrastructures numériques devraient faire l’objet d’un questionnement démocratique. Feenberg (2004) propose ainsi de considérer la technique comme une nouvelle forme de pouvoir législatif et soutient l’importance d’étudier les conditions permettant un débat réellement démocratique sur ces choix techniques. En préface d’un ouvrage plus récent de Feenberg, Callon (2014) le rejoint en soulignant que le développement technique implique souvent l’émergence de groupes qui « critiquent, analysent et interprètent les techniques existantes ou à venir, pour montrer leurs limites, leurs conséquences indésirables, mais également pour imaginer de nouvelles options ». Il note aussi qu’« au cours de ce processus, ce ne sont pas seulement de nouvelles trajectoires techniques qui émergent, mais également de nouvelles identités sociales qui se forment et qui, une fois les choix faits, seront inscrites dans la matérialité des techniques » (p. 10). Ces différentes réflexions nous amènent à poser le regard autant sur l’articulation des valeurs au design des infrastructures et protocoles d’Internet que sur les possibilités d’interventions sociotechniques pour transformer ces ordres techniques existants et imaginer de nouvelles possibilités.

Les terminologies inclusives et le pouvoir des mots

7Étroitement liée à notre préoccupation centrale, la question des valeurs et des biais véhiculés dans le langage et les termes employés est aujourd’hui discutée dans plusieurs sphères sociétales et le domaine de l’informatique a également vu se développer plusieurs initiatives dans ce sens. En 2003 déjà, le comté de Los Angeles demandait à ses fournisseurs et contractuels d’arrêter d’utiliser les termes « master » et « slave » (Reuters, 2003). Suite à cela, des projets technologiques, notamment utilisés dans le développement de sites web, ont décidé à leur tour de ne plus utiliser ces termes. C’est ainsi le cas depuis 2014 de Django et Drupal, de Redis depuis 2017, puis de Python en 2018 après un débat animé entre les développeurs de ce langage de programmation (Oberhaus, 2018). Au niveau de l’élaboration des standards, l’Open Compute Project (OCP), qui regroupe des entreprises comme Meta (Facebook), Apple et Intel, publie en 2020 des recommandations de langage inclusif visant à ce « que la terminologie qui pourrait être considérée comme offensive soit éliminée de tout matériel » (Open Compute Project, 2020, p. 3). En 2021, l’International Committee for Information Technology Standards (www.incits.org) émet des lignes directrices sur la « terminologie inclusive », définie comme une « terminologie perçue ou susceptible d’être perçue comme neutre ou accueillante par toute personne, quels que soient son sexe, son genre, sa race, sa couleur, sa religion, etc. » (INCITS, 2021, p. 4). Reprenant quasiment à l’identique cette définition, le National Institute of Standards and Technology (NIST) aux États-Unis publie en 2021 un énoncé d’orientation (guidance) – qui jouera un rôle clé dans le récit que nous présenterons plus loin dans cet article – définissant le langage inclusif comme un langage qui « utilise des expressions et des termes susceptibles d’être perçus comme neutres ou accueillants par tous, indépendamment de leur sexe, de leur race, de leur religion, de leur âge, etc. » (Miller et al., 2021). On y recommande par exemple de remplacer les termes « master/slave » par des termes comme « primary/second », les termes « blacklist/whitelist » par « denylist/allowlist » (Miller et al., 2021, p. 1).

8Ces efforts de terminologies inclusives restent encore sujets à débat. Des développeurs issus de la communauté noire aux États-Unis ont fait valoir que le remplacement des termes « master-slave » est superficiel, et que les entreprises devraient apporter de réels changements pour soutenir les efforts contre le racisme (Landau, 2020). De manière plus générale, « l’écriture inclusive » fait également l’objet d'oppositions au-delà du domaine de l’informatique. On critique par exemple ces efforts comme étant une manifestation d’un déterminisme linguistique voulant que le langage à lui seul aurait la capacité de transformer les rapports de pouvoir dans la société (Develey, 2021 ; Sastre, 2017). Les changements de terminologie inclusive seraient donc avant tout un geste idéologique sans effets réels en ce qui a trait aux « vraies » discriminations, en plus de causer d’autres problèmes comme la lourdeur des efforts nécessaires pour réaliser ces changements. S’il faut rendre compte de ces critiques pour restituer notre analyse dans son contexte social plus large, mentionnons toutefois que notre objectif dans cet article n’est pas de statuer définitivement sur la pertinence de ces changements terminologiques, mais plutôt d’analyser la manière dont ces débats s’actualisent dans le contexte du développement des protocoles d’Internet. Notons toutefois que nous nous inscrivons pour notre part de manière générale dans une perspective épistémologique plus pragmatique et « performative » qui soutient que le langage possède effectivement un pouvoir d’action (Austin, 1970), en particulier dans sa capacité à performer les identités de genre mais aussi à faire violence, en ce qui concerne les discours haineux (Butler, 2004; 2006). Il ne s’agit cependant pas d’un déterminisme linguistique direct : les mots tirent plutôt leur pouvoir et leur force « de la répétition ou la citation d'un ensemble de pratiques antérieures qui font autorité » (Butler, 2004, p. 80). Il est par conséquent possible d’agir socialement sur ce pouvoir des mots, soit en les changeant soit en transformant leurs contextes associés. D’emblée, soulignons donc qu’autant sur les plans idéologiques qu’épistémologiques, nous sommes a priori plutôt en faveur de ces changements terminologiques bien que notre démarche ici consiste plutôt à laisser la parole aux acteurs et actrices.

Le cas de l’IETF

  • 1 Les débats présentés ici ont également eu lieu au sein de groupes de travail de l’Internet Research (...)

9Notre étude aborde les débats sur la terminologie inclusive dans le cadre de l’Internet Engineering Task Force (IETF). Créée en 1986, l’IETF est une organisation informelle devenue de facto l’organisme développant les standards d’Internet (Yates, 2019)1. Elle a pour mission de « produire des documents techniques qui influencent la manière dont les gens créent, utilisent et gèrent l’Internet » (mission de l’IETF, traduction libre). Les publications officielles et documents de travail produits par l’IETF sont nommés des Request for Comments (RFC). Les premiers RFC datent de l’époque de la création de l’ARPANET et visait alors, comme le nom l’indique, à obtenir des commentaires sur différents aspects du développement du réseau naissant. Depuis 1969 – donc bien avant la création de l’IETF – plus de 8 000 RFC numérotés ont été publiés. Aujourd’hui toutefois, même si le titre perdure pour des raisons historiques, ces documents ne sont plus sujets à délibération mais constituent plutôt les spécifications officielles et finales produites par l’organisme. Ce sont plutôt les Internet-drafts (désignés plus simplement dans cet article sous le terme drafts) qui ont aujourd’hui le statut de documents de travail ou d’ébauche servant aux délibérations internes.

10L’IETF est en principe une organisation « ouverte » à quiconque veut participer, bien qu’en pratique elle réunit surtout des personnes ayant les capacités techniques, les ressources financières et le temps de s’y investir (typiquement des ingénieurs et informaticiens dont la participation est financée par l’entreprise qui les emploie). Des rencontres de l’IETF se tiennent trois fois par année en présentiel (chaque rencontre réunissant environ 1000 personnes d’une cinquantaine de pays), mais c’est surtout en ligne que l’activité se déroule et ce, depuis bien avant la pandémie. Ainsi, lors de notre étude, on dénombrait environ 2500 courriels échangés par semaine sur les plus de 700 listes de diffusion. Tous ces échanges et tous les documents de travail de l’IETF sont archivés et accessibles publiquement et librement.

11Sur le plan de la gouvernance, les décisions s’appuient sur le principe d’un « consensus approximatif » (rough consensus) déterminé par la présidence de chacun des groupes de travail de l’IETF. Un document accepté par un groupe doit ensuite faire l’objet d’une délibération en plénière selon la même règle du consensus approximatif, consensus cette fois déterminé par le comité responsable du processus de standardisation, l’Internet Engineering Steering Group (IESG). Le président ou la présidente de l’IESG préside également l’IETF dans son ensemble, et est la personne qui, en dernière instance, détermine quels consensus approximatifs se dégagent des délibérations. Ces aspects de la gouvernance de l’IETF sont importants à comprendre pour bien saisir la dynamique du débat étudié.

12L’IETF est abordée ou citée depuis longtemps dans la littérature en sciences sociales, bien qu’on note depuis quelques années un renouvellement de l’intérêt pour cette organisation (DeNardis, 2009 ; Cath & Floridi, 2017 ; ten Oever, 2021). DeNardis place l’IETF au sein de la guerre sur la gouvernance d’Internet et de ce qu’elle appelle les « politiques du protocole » (DeNardis, 2009) tandis que ten Oever (2021) fait ressortir la persistance des imaginaires et des valeurs des débuts d’Internet parmi les ingénieurs de l’IETF. Cath & Floridi (2017) soulignent notamment la forte présence de représentants de grandes entreprises, par ailleurs majoritairement masculins et occidentaux (Cath & Floridi, 2017). Sur ce point, mentionnons qu’un sondage interne (IETF, 2021) énonçait que l’organisme avait « un gros problème avec le genre », en montrant que les femmes ne représentaient qu’environ 10 % de la communauté.

13Soulignons finalement que les valeurs et enjeux éthiques sont discutés depuis longtemps au sein de l’IETF, bien que de façon éparse. Dès 1989, l’organisme publiait un document intitulé Ethics and the Internet (Internet Activities Board, 1989), désapprouvant des activités qui, par exemple, perturbent l’utilisation d’Internet, compromettent l’intégrité de l’information et portent atteinte à la vie privée. Notons aussi un RFC publié en 2004 – donc bien avant les événements dont nous parlons – qui met clairement en avant qu’Internet n’est pas « sans valeur » : « The Internet isn’t value-neutral » (Alvestrand, 2004). Depuis quelques années, plusieurs interventions ont incité l’organisation à prendre davantage en compte les enjeux de diversité et d’équité ainsi que les droits de la personne. Cependant, ces interventions font face à divers obstacles. Dans une étude plus récente, Cath (2021) affirme que la manière dont les participants de l’IETF voient et comprennent les standards d’Internet sapent les efforts des personnes qui défendent les droits humains dans leur volonté d’influer sur les protocoles. En effet, ce sont surtout des valeurs telles que la connectivité, l’interopérabilité, l’ouverture et « l’innovation sans permission » qui sont mises de l’avant au sein de l’IETF (Cath, 2021), valeurs par ailleurs étroitement liées à celles de la liberté individuelle, de la libre association (Cath, 2021), ainsi qu’à des objectifs d’efficacité, de performance et d’accessibilité de l’information.

La controverse sur la terminologie inclusive au sein de l’IETF

Démarche d’analyse et portrait d’ensemble

14Sans s’y astreindre strictement, notre analyse s’inspire des méthodes d’études des controverses en sociologie des sciences et technologies (Lascoumes, 2002 ; Latour, 2007 ; Méadel, 2015). L’étude des controverses nous apparaît pertinente pour ouvrir les « boîtes noires » que constituent souvent les technologies et pour prendre conscience de la multitude d’avenues possibles dans le développement d’une technologie. Les études de controverses s’attardent souvent sur les débats qui prennent place dans l’espace public plus large et mettent l’accent sur les alliances entre les acteurs et les processus de stabilisation et de clôture. Sans éluder ces aspects, nous mettons ici davantage l’accent sur le contenu sémantique des discussions et des échanges entre les acteurs. La notion de controverse renvoie donc davantage pour nous à l’idée plus générale d’un débat ou d’une délibération. Nous allions aussi cette entrée par la controverse à l’approche d’Akrich (1987) qui, sans se revendiquer explicitement de l’analyse de controverses, soutenait qu’une bonne partie du travail de conception consiste à « inscrire » une certaine vision du monde dans le contenu technique du nouvel objet. Le travail d’analyse consiste donc à décrire les négociations et délibérations entre les acteurs concernant les attributs des usagers potentiels ou des objectifs d’une technologie, et à mettre en lumière comment le résultat de ces négociations s'exprime sous une forme technique.

15La controverse étudiée a eu lieu entre 2018 et 2021 sur différentes listes de discussions de l’IETF. Notons que notre analyse s’inscrit toutefois dans le cadre d’une recherche plus large. Nous avons ainsi participé à deux rencontres présentielles de l’IETF (en 2018 et en 2019), et observé plusieurs listes de discussions, de manière plus participative au début puis plus distante ensuite, ce qui nous a permis de mieux comprendre le contexte du cas étudié. Depuis 2020, nous avons ensuite entrepris une démarche plus systématique de « veille » : une fois par semaine, il s’agissait de repérer les discussions à caractère social ou du moins compréhensible pour des chercheurs et chercheuses en sciences sociales. Ces observations nous ont amenés à repérer la controverse ici présentée pour ensuite la documenter et la retracer à l’aide des archives de l’IETF. Dix-neuf « chaînes de message » totalisant 1473 courriels par 163 personnes entre le 14 septembre 2018 et le 18 mai 2021 ont fait l’objet d’analyse, sur quatre listes de discussions différentes. Nous référons dans ce texte à ces chaînes de courriel par les termes chaîne 01, chaîne 02, etc. De plus, quatre différents drafts, dont un canular, ont été proposés durant ces discussions, auxquels nous référons par les termes draft #1, draft #2 et draft #3 ainsi que directement au canular. Ceux-ci sont parfois ajournés et de nouvelles versions sont publiées. Sur le plan sociodémographique, il est difficile de caractériser avec précision le profil exact des participant.es à la controverse. Rappelons toutefois que l’IETF réunit avant tout un public d'informaticiens et d’ingénieurs, en très grande majorité des hommes qui agissent soit de manière autonome, soit en tant qu’employé d’une entreprise. Le profil des personnes engagées dans le débat semble correspondre au profil général. À titre d’exemple, voici un bref portrait des personnes - tous des hommes - ayant le plus intervenu dans l’ensemble des discussions :

  1. 105 messages : Informaticien, environ 60 ans, nationalité étasunienne, employé dans une grande entreprise étasunienne. Favorable au changement terminologique.

  2. 100 messages: Ingénieur en informatique, environ 60 ans, vivant aux États-Unis, participant à l’IETF depuis au moins 1996. En principe favorable à certains changements, mais en insistant sur les perturbations que cela peut entraîner.

  3. 68 messages: Ingénieur en sécurité, environ 40 ans, d'origine argentine, travaillant au sein d’une entreprise d’intelligence artificielle étasunienne. Favorable au changement, en insistant sur la nécessité d’être inclusif dans d’autres sphères d’activité.

  4. 67 messages: Ingénieur en sécurité, environ 60 ans, vivant aux États-Unis et travaillant dans une grande entreprise étasunienne. Nettement défavorable au changement terminologique.

16Finalement, décrivons ici les quatre listes concernées par la controverse :

  • Hrpc : liste du groupe de travail Human Rights Protocol Considerations, créé en 2015 pour discuter des manières de mieux prendre en considération les droits humains dans le développement des protocoles d’Internet. Ses membres actifs proviennent d’organismes de la société civile comme Article 19 ou Center for democracy and technology aux États-Unis. Ce sont les principaux protagonistes en faveur d’une terminologie plus inclusive.

  • Ietf : principale liste de discussions pour l’ensemble des personnes participant à l’IETF et où sont prises les décisions générales, en particulier concernant le développement des standards.

  • Gendispatch : liste du groupe General Area Dispatch dont le mandat est de discuter des nouvelles initiatives susceptibles d’affecter les processus de collaboration de l’IETF dans son ensemble.

  • Terminology : groupe de travail émergeant sur les questions de terminologie, et en particulier de terminologie inclusive. Ce groupe de travail sera abandonné en conclusion de la controverse.

  • 2 Ce caractère public est pleinement assumé par l’IETF qui affirme clairement son « engagement à la t (...)

17Notons que toutes les discussions et documents auxquels nous référons ici sont publics2. Cependant, pour donner suite à des discussions avec d’autres chercheur.es et participant.es de l’IETF, et afin d’éviter de mettre l’emphase sur des personnes ou des extraits polémiques particuliers, nous avons décidé ici de traduire en français les propos cités et de ne pas référer nominalement aux personnes concernées. Nous sommes conscients du risque que ce choix rende l’analyse parfois désincarnée à la lecture, mais nous croyons que cette approche permet de bien saisir la teneur des échanges et des arguments mobilisés et de faire ressortir les implications théoriques et analytiques de ceux-ci.

Tableau 1 : Résumé des différents moments de la controverse

Période

Sujet général

Liste

Nb msg

Nb pers

1

14 sept. 18
23 sept. 18

Mention du retrait officiel par la communauté Python de la terminologie master/slave.

hrpc

77

16

2

20 sept. 18
3 oct. 18

Discussions sur la diversité et les terminologies offensantes au sein des RFC.

ietf

121

58

3

22 oct. 18
30 oct. 18

Proposition d'un draft (version 00) sur la diversité, le pouvoir et la terminologie offensante.

hrpc

2

2

4

17 juin 20
14 août 20

Nouveau draft (version 01) adapté en fonction des commentaires.

gendispatch

32

16

5

23 juill. 20
11 août 20

Déclaration de l’IESG sur le langage oppressif qui invite ses participants à consulter l’ébauche.

ietf

452

82

6

25 août 20
27 août 20

Proposition par une autre personne d'une version du draft sur la terminologie (version 03).

gendispatch

10

6

7

25 août 20
26 août 20

Nouvelle version du draft #1 (version 04).

gendispatch

4

4

8

27 août 20
27 août 20

Discussions sur les drafts et les perturbations possibles des changements de terminologie.

gendispatch

23

8

9

11 fév. 21
31 mars 21

Proposition de charte pour un nouveau groupe de travail sur la terminologie inclusive.

gendispatch

169

33

10

23 fév. 21
5 mars 21

Questionnements sur les obstacles à l’inclusion et à la diversité au sein de l’IETF.

gendispatch

110

33

11

26 mars 21
14 avril 21

Demande de commentaires concernant la charte pour encadrer les travaux sur la terminologie.

terminology

19

10

12

1 avril 21
7 avril 21

Canular pour le premier avril, un draft ironique, qui présente le sujet de façon anodine par le rédacteur.

ietf

97

27

13

1 avril 21
18 avril 21

Discussions sur le rôle et le choix de la personne qui fera des recommandations de terminologie inclusive.

ietf

49

24

14

12 avril 21
14 avril 21

Mise à jour de la charte encadrant la création d'un groupe de travail sur la terminologie (TERM).

terminology

29

10

15

13 avril 21
21 avril 21

Discussions sur l’article paru
dans le New York Times.

ietf

150

50

16

23 avril 21
30 avril 21

Deuxième cycle de révision pour
la charte du groupe « TERM ».

terminology

57

22

17

23 avril 21
25 avril 21

Idem, mais sur la liste gendispatch.

gendispatch

11

7

18

29 avril 21
2 mai 21

Discussion sur les lignes directrices du NIST sur la terminologie inclusive.

terminology

24

17

19

3 mai 21
18 mai 21

Le président (IESG et IETF) annonce que l’IETF suivra les lignes directrices de NISTIR 8366.

terminology

37

15

Résumé des différents moments de la controverse. Chiffres obtenus manuellement puis reconfirmés en utilisant le logiciel R.

Début de la controverse : suivre l’exemple de Python

18La controverse débute le 14 septembre 2018 lorsqu’un message est envoyé sur la liste hrpc (considérations de droits humains dans les protocoles) faisant état de la décision de la communauté Python de supprimer officiellement les termes « master-slave » de sa terminologie [chaîne 01, septembre 2018]. En sept jours, ce débat suscite les réactions de seize personnes. D’emblée, certaines considèrent qu’il ne s’agit pas d’un enjeu sur lequel l’IETF doit s’attarder, et qu’il y a des enjeux plus importants à traiter :

  • 3 Tous les extraits présentés dans cette section ont été traduits par nous-mêmes.

Le fait même de consacrer du temps à cette discussion détourne le débat des véritables questions relatives aux droits humains et ne sert qu’à marginaliser encore davantage ce groupe au sein des gouvernements3 [chaîne 01, septembre 2018].

19Le débat se déplace ensuite sur la liste ietf, et aborde les enjeux de la diversité et des terminologies offensantes qu’on peut trouver dans les RFC [chaîne 02, septembre 2018]. La conversation est entamée par la même personne qui avait écrit sur le groupe hrpc. Elle souligne à nouveau que différents projets informatiques ont aboli l’utilisation de la terminologie maître-esclave, au profit d’autres termes comme « primary-secondary ». D’autres termes comme « blacklist » (pour faire par exemple référence aux adresses électroniques bloquées car diffusant du SPAM), sont abordés. La discussion prend ensuite une tournure plus générale sur la diversité dans l’IETF, les technologies offensantes et la pertinence même du groupe hrpc, qui choisit de s’intéresser à ces questions de terminologie plutôt qu’aux « vrais droits »

Je suis certain qu'aucun RFC n’a jamais réduit quelqu'un en esclavage, ni inscrit quelqu'un sur une liste secrète l’empêchant de travailler (c'est le sens réel du terme « liste noire » pour ceux qui connaissent leur histoire). Il existe des problèmes réels en matière de droits humains sur lesquels HRPC pourrait s'engager, mais il ne le fait pas [chaîne 02, septembre 2018].

20Le 22 octobre 2018, un premier draft (draft #1) est proposé sur le groupe hrpc [chaîne 03, octobre 2018], qui synthétise et répond aux commentaires adressés dans la discussion précédente. Ce draft propose d’abandonner la terminologie offensante pour des termes plus inclusifs en ciblant spécifiquement les termes master-slave et blacklist-whitelist, décrits comme « deux ensembles de termes qui sont normalisés au niveau technique, mais oppressifs au niveau sociétal » (draft #1). Des alternatives (primary-secondary, primary-replica, leader-follower) sont proposées.

21S’en suivent alors des arguments en faveur ou non du changement proposé. Les personnes se positionnant en défaveur de celui-ci évoquent des arguments tels que son caractère chronophage et complexe. Elles soulèvent encore une fois que consacrer du temps à cette discussion détourne l’attention des véritables questions relatives aux droits des personnes, comme la vie privée. Dans une autre perspective, elles soulignent aussi qu’il est difficile de trouver un équivalent sémantique à certains termes et elles soutiennent qu’il ne s’agit que d’abstractions, et qu’il n’y a pas de personnes humaines réellement opprimés puisque ces termes sont uniquement employés à des fins techniques :

Nous n'aimons pas entrer des codes hexadécimaux ou binaires, alors nous attribuons des noms à ces codes, nous regroupons ces codes en programmes et nous donnons des noms à ces programmes, etc. Mais cela ne change pas vraiment leur nature, sauf dans nos abstractions mentales : ce ne sont que des uns et des zéros qui s'entrechoquent [chaîne 01, septembre 2018].

22Cet extrait est intéressant car il met l’accent sur le fait que le changement des noms du code ne change pas vraiment la nature de ces codes eux-mêmes, mais seulement la manière de les désigner. Cet aspect du débat, bien que souvent implicite dans les échanges, aborde un aspect important de la particularité de notre objet, soit des spécifications écrites du fonctionnement d’un système informatique, et non pas le fonctionnement lui-même.

23Pour ce qui est des arguments en faveur du changement de terminologie, des personnes notent que ces termes ont un lourd bagage négatif, d’où l’importance de les changer. Ils sont utilisés dans des contextes professionnels et peuvent faire ressortir des émotions négatives et représenter un frein à l’inclusion de personnes de diverses origines, notamment au sein de l’IETF. Allant plus loin, certains expliquent que la diversité à l’IETF est importante, car les groupes présentant une plus grande diversité prendraient de meilleures décisions. Le changement de terminologie permettrait ainsi de démontrer la volonté de l’IETF de former une communauté plus diversifiée et inclusive :

Le problème est que ces termes « techniques » sont ensuite utilisés dans des contextes professionnels dans lesquels les personnes pour lesquelles ces termes ont des significations non techniques très puissantes sont obligées de les entendre encore et encore, ce qui n'est pas amusant pour elles [chaîne 01, septembre 2018].

Les groupes plus diversifiés prennent de meilleures décisions. Pour obtenir une diversité significative, il faut plus que de la bonne volonté générique et des déclarations de principe. De nombreux comportements différents peuvent contribuer à réduire la diversité des participants ou la diversité de la participation [chaîne 01, septembre 2018].

24En 2019, le sujet n’est pas abordé et ce n’est qu’en juin 2020 que la discussion ressurgit lorsqu’une nouvelle version du draft #1 est proposée [chaîne 04, juin 2020]. L’auteur de la nouvelle version justifie dans son message que son draft peut contribuer au « débat mondial actuel sur le racisme systémique et institutionnel [qui] a conduit plusieurs communautés technologiques à reconsidérer leur langage et leurs pratiques » [chaîne 04, juin 2020]. Plusieurs commentaires (32 messages) sont adressés pour améliorer le document, mais la discussion dévie surtout sur le postulat principal du draft, à savoir si les termes « master-slave » sont racistes ou non, en soulignant que ces termes ont toujours été utilisés sans intentions racistes :

Des expressions telles que « maître-esclave » ou « liste noire » ont été utilisées dans le passé sans intention d'exclure des personnes et sans s'engager dans des catégorisations raciales [chaîne 04, août 2020].

25Le 8 juillet 2020, une nouvelle version du draft #1 (03) est proposée, mais ne suscite pas d’échanges. Quelques jours plus tard, l’Internet Engineering Steering Group (IESG), le comité de l’IETF responsable de la gestion des discussions techniques et du processus de standardisation, déclare être contre le langage « exclusionnaire » et souligne soutenir la pertinence du débat autour du draft #1 [chaîne 05, juillet 2020]. Cette déclaration provoque de longs échanges (452 messages) et mène à la création du draft #2 [chaîne 06, août 2020] dont le but est de « reconnaître le coût réel d’un changement de terminologie et les risques qu’il comporte, tout en précisant que le changement est parfois nécessaire et que le fait de le retarder le rend plus coûteux, et non moins coûteux » [chaîne 065, août 2020]. Le 27 août 2020, un draft #3 est proposé, témoignant des désaccords sur le sujet. Il met de l’avant le fait que le changement terminologique n’apporterait qu’un faible bénéfice pour des coûts considérables, et que ces longs débats pourraient constituer « des distractions importantes et improductives » [chaine 07, août 2020].

26À cette même date, en réaction à ces deux nouveaux drafts, des précisions sont demandées afin d’approfondir le débat [chaîne 08, août 2020]. L’un des auteurs du draft #1 demande à ce que soit davantage étayé le postulat de perturbations importantes causées par le changement technologique. Une discussion s’en suit, mettant encore une fois en opposition deux opinions principales : d’une part, certaines personnes argumentent que l’expérience qu’elles ont accumulée grâce à leur ancienneté à l’IETF leur permet d’affirmer que le changement de terminologie peut créer des complications. D’autre part, des personnes mentionnent que le ressenti d’exclusion et le constat d’un manque de diversité au sein de l’IETF permet d’affirmer que certains termes devraient être changés.

Reprise du débat : une charte et un canular

27Après six mois de silence, le débat s'intensifie puis mène cette fois-ci à un certain consensus. À la mi-février 2021, une charte est proposée pour encadrer la discussion et un groupe de travail est créé pour établir des recommandations [chaîne 09, février 2021]. Dans les discussions qui suivent, les sujets des recommandations sont mentionnés. Des personnes écrivent qu’il serait bien de définir des principes pour juger quand le langage est « inclusif » et « exclusif », bien que cela n’est finalement pas réellement délimité. D’autres mentionnent être contre le bannissement de certains mots en invoquant la liberté d’expression. Certaines croient au contraire qu’il s’agit de donner des suggestions pour changer les termes plutôt que de les bannir. On retrouve aussi des arguments similaires à ceux mobilisés auparavant, en particulier le fait que le changement de terminologie n’aidera pas à augmenter la diversité à l’IETF. D’ailleurs, une discussion est aussi lancée à la même période pour discuter de manière plus générale des obstacles à l’inclusion et à la diversité au sein de l’IETF [chaîne 10, février 2021], ce qui montre bien que la discussion a des incidences dépassant le cadre strict de la terminologie.

28Le 26 mars 2021, l’IESG transmet la charte qui encadrerait la mission d’un groupe de travail sur la terminologie. Ce groupe aurait comme mandat de produire un RFC informatif contenant des recommandations sur l’utilisation d’une terminologie inclusive dans les documents techniques produits par l’IETF [chaîne 11, mars 2021]. Le groupe devrait aussi recommander une source externe mise à jour de façon indépendante, contenant des termes alternatifs, et ce, pour que l’IETF puisse s’aligner sur les activités plus larges de l’industrie technologique. Notons que dès sa création, la charte soutient que « les documents de l’IETF, y compris les RFC et les Internet-Drafts, sont plus efficaces lorsqu’ils utilisent une terminologie claire, précise et largement accessible à des lecteurs d’origines et de cultures diverses » [chaîne 11, mars 2021], ce qui dénote déjà une prise de position sur le sujet.

29Le 1er avril 2021, un nouveau draft est publié en tant que « poisson d’avril » en se moquant avec ironie du questionnement sur la terminologie inclusive [chaîne 12, avril 2021]. Le canular est immédiatement et vigoureusement dénoncé par le président de l’IETF qui, bien que n’ayant pas le pouvoir de le supprimer (étant donné les règles empêchant la suppression d’un document), affirme qu’il ne correspond pas au code de conduite de l’IETF car il est irrespectueux envers des efforts cherchant à rendre plus ouverte l’organisation. En réponse à cette condamnation, plusieurs personnes réagissent (97 messages au total), mais la discussion n’aborde plus le bien-fondé du draft ou du changement terminologique mais plutôt des enjeux de modération et de pouvoir au sein de l’IETF. D’une part, certains considèrent que la condamnation du canular s’apparente à de la censure et à une atteinte à la liberté d’expression. D’autre part, des personnes rappellent aussi que ce n’est pas la première fois qu’un draft ironique de ce type est publié, qu’il y a déjà eu des plaintes à ce propos dans le passé et qu’il est important de permettre aux personnes de se sentir à l’aise d’amener des débats sur ces enjeux sans subir de la moquerie.

30Toujours le 1er avril 2021, une personne réagit à la proposition de créer un groupe de travail sur la terminologie [chaîne 13, avril 2021] en interrogeant s’il sera du ressort de ce groupe de déterminer si un mot est inclusif ou non. La discussion amène un questionnement, à savoir qui devrait prendre cette décision : certains proposent lIESG, d’autres proposent le RFC editor (responsable de la mise en forme finale des RFC) ou alors d’engager des personnes spécialisées en dehors de l’IETF. Toutefois, il n’y a pas eu de consensus sur ce point.

31Le 12 avril 2021, la charte qui encadre le mandat du groupe de travail sur la terminologie (TERM) est mise à jour, ce qui génère beaucoup de commentaires [chaîne 14, avril 2021]. En effet, la charte affirme désormais que le mandat du groupe est de produire un RFC qui donne des « conseils », contrairement à la première version qui parlait de « recommandations », ce qui est perçu comme un amenuisement du mandat du groupe.

32Le 13 avril 2021 paraît l’article du New York Times (Conger, 2021) que nous avons cité en introduction, suscitant des réactions à l’IETF [chaîne 15, avril 2021]. Il y est notamment question de la vision des lecteurs et lectrices du New York Times et de leurs commentaires à cet article, de la nécessité de justifier le temps apporté à la question du changement de terminologie et de la manière de rendre l’IETF plus inclusive.

33Quelques jours plus tard, un deuxième cycle de révision de la charte fait l’objet d’autres discussions [chaîne 16, avril 2021 ; chaîne 17, avril 2021]. Tout au long de cette période, les arguments contre le changement terminologique sont similaires à ceux observés en 2018 : la terminologie actuelle n’est pas problématique; les efforts pour rendre l’IETF plus accessible sont exagérés et peu utiles ; il y a des choses plus importantes à régler ou plus utiles à faire pour favoriser l’inclusivité à l’IETF ; il s’agit de termes techniques ne désignant pas des personnes humaines. Des personnes notent aussi qu’il serait inutile de se concentrer sur la terminologie, car le changement devrait se faire dans la société avant de se faire dans les termes utilisés. À l’inverse, les arguments pro-changement réitèrent que de ne pas changer la terminologie offensante témoigne d’un manque de respect et d’empathie. Aussi, certains avancent que le changement de terminologie, même s’il ne symbolise qu’un petit pas, témoigne de la volonté de l’IETF de promouvoir plus d’inclusivité en son sein. Enfin, des personnes mentionnent que le langage et ses connotations évoluent et qu’il y a un devoir moral d’en rendre compte :

[...] Les dénotations et les connotations des mots évoluent. Il n'est pas facile de savoir quand et comment ils ont changé. Toutefois, s'ils ont changé au point de devenir offensants pour un groupe important de personnes, nous devrions y prêter attention [chaîne 12, avril 2021].

Clôture de la controverse : consensus autour de NISTIR

34Le 29 avril 2021, des personnes signalent une publication du National Institute of Standards and Technology (NIST) aux États-Unis, préconisant l’utilisation d’un langage inclusif dans le cadre d’activités d'élaboration de normes techniques (Miller et al., 2021), et proposent d’utiliser ce document comme base pour l’IETF [chaîne 18, avril 2021], plutôt que de poursuivre le travail d’établir des recommandations « internes ». Cette proposition suscite immédiatement l’enthousiasme au sein de la liste car elle permet d’avancer rapidement sur cet enjeu. Ainsi, selon les mots d’un intervenant, « la terminologie est 1 % du problème, et si ça nous permet de mettre ça de côté et de travailler sur les 99 % restants, tant mieux ». En particulier, les auteurs et autrices des trois différents « drafts » concurrents acceptent de se rallier à la proposition, ce qui permet au président de statuer qu’il y a désormais un « large consensus ». Le 3 mai, au sein d’une discussion [chaîne 19, mai 2021], le président de l’IETF émet les propositions suivantes, en lien avec la référence du NIST : 1) que la charte proposée du groupe de travail TERM (le charter text) soit abandonnée ; 2) que l’IESG recommande la norme NISTIR 8366 en tant qu’orientation pour les contributeurs de l’IETF ; 3) que les éditeurs de RFC recommandent cette norme pour guider les auteurs de drafts et de RFC. La semaine suivante, le 11 mai, l’IESG annonce officiellement qu’elle encourage les membres à utiliser NISTIR 8366. Le 18 mai, le président de l’IETF déclare finalement qu’un consensus a été atteint en faveur de NISTIR 8366 comme recommandation de terminologie pour l’IETF [chaîne 19, mai 2021].

35À la suite de cette déclaration, le guide de style des RFC a été modifié pour inclure la recommandation du NIST et on constate un arrêt effectif des débats de fond. Les débats laissent place à d’autres discussions concernant les manières dont l’IETF pourrait être plus inclusive, notamment face aux complexités des processus de travail de l’organisation. Notons finalement que cette clôture de la controverse, qui n’apparaît être que provisoire ou procédurale, semble en fait assez typique de la résolution des controverses en général. Comme le note Lemieux (2007, p. 207) :

les controverses sont beaucoup moins souvent tranchées qu’elles ne sont progressivement normalisées […]. Un tel accord procédural n’annule donc en rien le dissensus entre pairs. Il le reconduit et l’entretient au contraire, mais en occasionnant son déplacement collectif vers de nouveaux objets et de nouvelles interrogations, à savoir : ceux que l’internalisation de la controverse permet et suscite, c’est-à-dire intégrés institutionnellement à travers leur prise en charge par la communauté des pairs et les réponses nouvelles que celle-ci s’efforce de leur apporter.

Discussion

36Comme indiqué en introduction, trois niveaux d’analyse ressortent de la description de la controverse. D’abord, au niveau de la mobilisation, l’analyse confirme clairement la vitalité des discussions et des débats au sein de l’IETF, organisation peu connue du public et dans les sciences humaines, qui joue toujours un rôle prépondérant dans le développement d’Internet. Plus précisément, elle montre aussi l’effet qu’a eu au sein de l’organisation le geste politique par certains acteurs de mettre à l’agenda cette discussion. Au-delà de toutes considérations sur la force présumée du langage ou les conséquences des choix terminologiques, nous voyons que la seule proposition de favoriser des terminologies inclusives crée un large débat au sein de l’organisation autour des enjeux d’inclusion et de diversité, mais également autour des enjeux de pouvoir au sein même de l’organisation. Empiriquement, notre méthodologie consistant à « suivre un débat » (ou une controverse) a permis de porter le regard sur un moment où les valeurs et les biais possibles véhiculés par les systèmes techniques sont en cours de façonnement ou de re-façonnement. La controverse met en lumière la manière dont les processus techniques (codage, maintenance, etc.) sont eux aussi politiques, comme l’avance Feenberg (2004), puisqu’ils ont des impacts sur la vie des personnes marginalisées qui travaillent sur ces mêmes processus.

37Ensuite, au niveau du pouvoir du langage, les arguments reprennent essentiellement les termes du débat social plus largement tel que mentionné plus tôt (Develey, 2021 ; Sastre, 2017). Les personnes qui se positionnent contre le changement de terminologie, croient que ce changement serait chronophage, non prioritaire, en plus de nuire à certains aspects techniques, et surtout, que les mots employés pour métaphoriser des éléments de programmation tels que « master-slave » n’ont pas d’impact sur l’inclusion sociale. Cette perspective rejoint une certaine critique du déterminisme linguistique, bien que ce terme ne soit pas évoqué concrètement dans les conversations étudiées. Toutefois, soulignons que les arguments avancés en faveur du changement de terminologie sont plus nuancés qu’un simple déterminisme linguistique voulant qu’à lui seul le langage ait une force directe. Les arguments principaux mobilisés lors de la controverse sont, pour celles et ceux qui étaient en faveur du changement de terminologie, que l’usage d’une terminologie inclusive permet de respecter toutes les personnes contributrices et de symboliser la volonté de l’IETF d’améliorer son accessibilité et son inclusivité.

  • 4 Dans une discussion avec notre collègue François Cooren, celui-ci proposait de distinguer entre « ê (...)

38Un aspect particulier du débat dans le cas de l’IETF concerne cependant la spécificité de l’objet étudié, soit les protocoles d’Internet et leurs expressions au sein des RFC. Il est en effet vrai que le seul changement de terminologie ne constitue pas en soi un changement de design. Comme le note l’un des acteurs que nous avons cités, nous ne sommes pas ici dans un débat sur un changement du code « binaire » du fonctionnement informatique, mais uniquement sur les terminologies qui facilitent la construction et le façonnement de ces codes binaires. Par exemple, le remplacement des termes « master/slave » n’aura pas d’implication directe sur l’architecture que ces termes désignent, mais seulement sur la désignation elle-même4. En revanche, cela fait ressortir l’aspect matériel de tous ces textes et documents qui spécifient les protocoles et les standards de fonctionnement des technologies numériques que nous utilisons au quotidien. Bien qu’en « arrière-plan » (Bowker & Star, 2000), ces documents sont bel et bien écrits et lus par des personnes humaines en utilisant des termes qui peuvent eux-mêmes être sujets à débat. Par ailleurs, nous ne l’avons pas explicitement souligné, mais il est finalement pertinent de rappeler que tous les documents produits par l’IETF, ainsi que toutes les communications à propos de l’élaboration de ces documents se passent en anglais, favorisant de fait les personnes les plus confortables dans cette langue. Les choix linguistiques et terminologiques peuvent donc avoir pour effet - ou être perçus comme ayant pour effet - de favoriser l’inclusion ou l’exclusion de certaines personnes et favoriser à plus grande échéance une plus grande diversité de points de vue. Cette perspective rejoint donc celle de Benjamin, cité en début de texte, qui note le pouvoir des personnes qui définissent les « standards d’expression » (expression standards) au détriment de toutes les autres qui doivent ainsi changer leur propre code d’expression (code-switching) pour s’intégrer. Comme les scripts et le code source des logiciels, les protocoles et standards d’Internet ont une dimension expressive. C’est d’ailleurs ici que la contribution de notre article est sans doute la plus spécifique. En effet, si plusieurs efforts de recherche ont été consacrés aux valeurs et aux biais dans les algorithmes, dans le design des interfaces ou même dans l’architecture d’Internet, relativement peu d’attention a encore été consacrée aux textes décrivant le fonctionnement des systèmes techniques et au pouvoir d’agir qu’ils peuvent avoir dans leurs dimensions signifiantes.

39Mais finalement, quelles seront les conséquences de l’adoption de la norme NISTIR 8366 pour la collaboration entre les membres de l’IETF et le développement des infrastructures d’Internet plus généralement ? Il est évidemment difficile de répondre à cette question à partir de notre méthodologie qui se concentre surtout sur l’analyse des débats et propos des acteurs, et il nous semble important de rester prudent vis-à-vis une approche trop déterministe qui verrait une incidence directe des choix terminologiques sur les pratiques des personnes concernées ou les infrastructures numériques qu’elles développent. En revanche, dans ce débat, nous adhérons aux arguments des personnes qui soutiennent que l’adoption d’une terminologie plus « inclusive » est au moins susceptible de favoriser un climat de collaboration plus accueillant et ouvert pour des personnes issues de groupes historiquement marginalisés, notamment dans ces secteurs d’activités. Nous croyons aussi que cette ouverture est susceptible d’avoir un impact sur les infrastructures elles-mêmes, par exemple en permettant l’émergence d’innovations ancrées dans des sensibilités plus « situées » qui n’étaient pas nécessairement présentes au départ. Cette perspective rejoint plusieurs travaux en STS, notamment l’approche du « technoféminisme » de Wacjman (2004) qui soutient que l’engagement accru de groupes sociaux non traditionnellement engagés dans les métiers scientifiques ou techniques (l’approche de Wacjman s’attarde évidemment au cas des femmes, mais elle peut être à notre avis appliquée à tout groupe de personne) peut amener des changements significatifs au niveau du design même de technologies et des infrastructures. C’est donc ici qu’on peut voir l’influence possible et à plus long terme de ces choix technologiques sur le développement des infrastructures d’Internet.

40Soulignons d’ailleurs que ce débat sur les terminologies inclusives ne s’est pas passé en vase clos. Déjà, il est significatif que l’IETF ait décidé de référer à un document extérieur à sa propre organisation – NISTIR 8366 – pour orienter les choix de terminologies. Inversement, et bien que nous ne l’ayons pas mentionné auparavant, il est intéressant de constater que le document NISTIR 8366 fait lui-même référence à plusieurs autres initiatives semblables dans d’autres organisations techniques dont paradoxalement (et de manière récursive!) aux discussions au sein de l’IETF présentées ici (Miller et al., 2021). Rappelons aussi que ce débat semble avoir été entamé par un message faisant état du retrait officiel de la terminologie master/slave par la communauté Python, une communauté reconnue pour ses nombreuses démarches d’inclusivité, ayant par exemple réussi à passer de 1 % à 40 % de participation de femmes lors de ses conférences (Finley, 2021). Ce débat sur les terminologies inclusives s’inscrit dans un mouvement plus large qui doit aussi être pris en compte pour en évaluer les conséquences.

Conclusion

41La première partie du titre de notre article « Quand les mots font des choses » fait évidemment référence à l’œuvre phare d’Austin (1970), dans laquelle il explore la performativité du langage. Dans le cas de l’IETF, cette phrase prend un double sens. D’une part, les mots font des choses, puisqu’ils contribuent à la construction et à la maintenance des infrastructures d’Internet en spécifiant par des mots – toujours en anglais – le fonctionnement des protocoles d’Internet. Mais nous l’avons vu, les mots utilisés pour spécifier ces protocoles sont également perçus par beaucoup comme ayant un impact sur la participation et la diversité au sein de l’IETF. Finalement, et c’est sans doute le plus important ici, toute cette réflexion sur des mots a suscité un débat plus large au sein de l’organisation et a mobilisé des centaines de personnes sur deux années. Ce débat sur le choix de terminologie a donc surtout servi de catalyseur pour des réflexions plus profondes concernant les valeurs véhiculées au sein de l’IETF, son fonctionnement et l’accessibilité aux débats. Cette controverse donne de l’importance aux discours et à l’inclusion dans un domaine qui est en général fortement techno-centré. Changer des mots permet aussi de bousculer, de créer un tumulte, de discuter des raisons mêmes pour lesquelles ils font débat, jusqu’à changer l’ordre établi, et c'est dans ce sens que les mots font ici des choses. S'intéresser à la controverse sur la terminologie inclusive au sein de l'IETF permet de mettre en lumière un conflit de valeurs et les enjeux politiques liés à des choix de termes spécifiques à l’œuvre dans les discussions sur l’opérationnalisation d'Internet.

Cette étude a bénéficié d’un soutien financier du Fonds de recherche du Québec – Société et culture (programme de soutien à la recherche pour la relève professorale). Nous tenons aussi à remercier les personnes qui ont révisé anonymement les premières versions de cet article, ainsi qu’aux assistant.es de recherches Christopher Housseaux, Véronique Bolduc et Samantha Boucher pour l’aide apportée à différents moments de la recherche. Merci finalement à toutes les personnes qui nous ont donné des commentaires lors de nos différentes présentations orales.

Haut de page

Bibliographie

Alvestrand, H. T. (2004). A Mission Statement for the IETF (Request for Comments RFC 3935). Internet Engineering Task Force. https://doi.org/10.17487/RFC3935

Akrich, M. (1987). Comment décrire les objets techniques. Techniques et culture, 9, 49-64. https://doi.org/10.4000/tc.4999

Austin, J. L. (1970). Quand dire, c’est faire. Paris : Seuil.

Benjamin, R. (2019). Race after technology: Abolitionist tools for the new jim code. Social Forces, 98(4), 1-3. https://doi.org/10.1093/sf/soz162

Blancel, N. & Blanchard, P. (2022, 21 janvier). La « théorie décoloniale » ou l’invention d’un ennemi commun. Politis. https://www.politis.fr/articles/2022/01/la-theorie-decoloniale-ou-linvention-dun-ennemi-commun-43999/

Bowker, G.C. & Star, S. L. (2000). Sorting things out: Classification and its consequences. Cambridge, Massachusetts : MIT Press.

Butler, J. (2004). Le pouvoir des mots : Politique du performatif. Paris : Éditions Amsterdam.

Butler, J. (2006). Trouble dans le genre : Le féminisme et la subversion de l’identité (C. Kraus, Trad.). Paris : Éditions La Découverte.

Callon, M. (2014). Préface. Dans A. Feenberg, Pour une théorie critique de la technique (pp. 7-17). Montréal : Lux Éditeur.

Cath, C. & Floridi, L. (2017). The design of the internet’s architecture by the Internet Engineering Task Force (IETF) and human rights. Science and Engineering Ethics, 23(2), 449-468. https://doi.org/10.1007/s11948-016-9793-y

Cardon, D. (2013). Dans l’esprit du PageRank. Réseaux, 177(1), 63‑95.

Cath, C. (2021). The technology we choose to create: Human rights advocacy in the Internet Engineering Task Force. Telecommunications Policy, 45(6), 102-144. https://doi.org/10.1016/j.telpol.2021.102144

Cohen, J. & Simon, P. (2012). Décoloniser les savoirs : Internationalisation des débats et des luttes. Mouvements, 72, 7-10. https://doi.org/10.3917/mouv.072.0007

Conger, K. (2021, 13 avril). “Master”, “slave”, and the fight over offensive terms in technology. The New York Times. https://www.nytimes.com/2021/04/13/technology/racist-computer-engineering-terms-ietf.html

DeNardis, L. (2009). Protocol politics: The globalization of Internet governance. Cambridge, Massachusetts : MIT Press.

Develey, A. (2021, 30 mars). Pour ou contre l’écriture inclusive ? Deux linguistes débattent. Le Figaro. https://www.lefigaro.fr/langue-francaise/actu-des-mots/pour-ou-contre-l-ecriture -inclusive-deux-linguistes-debattent-20210330

Feenberg, A. (2004). (Re) penser la technique : vers une technologie démocratique. Paris : La Découverte/M.A.U.S.S.

Finley, K. (2021, 16 mars). How Python is building a welcoming community for women. GitHub. https://github.com/readme/featured/women-in-tech-python

IETF (2021). IETF Community Survey 2021. https://www.ietf.org/media/documents/IETF_Community_Survey_2021.pdf

INCITS (2021, 7 juin). INCITS Inclusive Terminology Guidelines. Consulté sur https://standards.incits.org/apps/group_public/download.php/131246/eb-2021-00288-001-INCITS-Inclusive-Terminology-Guidelines.pdf

Internet Activities Board. (1989). RFC 1087: Ethics and the Internet. IETF. Consulté sur https://tools.ietf.org/html/rfc1087

Landau, E. (2020, 6 juillet). Tech confronts its use of the labels “master” and “slave”. Wired. https://www.wired.com/story/tech-confronts-use-labels-master-slave/

Lascoumes, P. (2002). De l’utilité des controverses socio-techniques. Journal International de Bioéthique, 13 (2), 68-79. https://doi.org/10.3917/jib.132.0068

Latour, B. (2007). Description des controverses. Notes de cours en ligne. École nationale supérieure des Mines de Paris. http://www.ensmp.fr/~latour/cours/index.html

Lemieux, C. (2007). À quoi sert l’analyse des controverses ? Mil neuf cent. Revue d’histoire intellectuelle, 25(1), 191‑212. https://doi.org/10.3917/mnc.025.0191

Massit-Folléa, F. (2014). Internet et les errances du multistakeholderism. Politique étrangère, Hiver (4), 29-41. https://doi.org/10.3917/pe.144.0029

Méadel, C. (2015). Les controverses comme apprentissage. Hermès, La Revue, 73(3), 45-50. https://doi.org/10.3917/herm.073.0045

Miller, K., Alderman, D., Carnahan, L., Chen, L., Foti, J., Goldstein, B., Hogan, M., Marshall J., Reczek, K., Rioux, N., Theofanos, M. & Wollman, D. (2021). Guidance for NIST staff on using inclusive language in documentary standards (NISTIR 8366). NIST. https://doi.org/10.6028/NIST.IR.8366

Musiani, F., Cogburn, D. L., DeNardis, L. & Levinson, N. S. (eds.) (2015). The Turn to Infrastructure in Internet Governance. New York: Palgrave Macmillan.

Nakamura, L. & Chow-White, P. (2012). Race after the Internet. New York: Routledge.

Noble, S. U. (2018). Algorithms of oppression. New York University Press.

Oberhaus, P. (2018, 13 novembre). ‘Master/slave’ terminology was removed from python programming language. Vice. https://www.vice.com/en/article/8x7akv/masterslave -terminology-was-removed-from-python-programming-language

Open Compute Project (2020, 20 décembre). OCP Terminology Guidelines for Inclusion and Openness. https://www.opencompute.org/documents/ocp-terminology-guidelines-for-inclusion-and-openness (consulté le 12 mai 2022).

Raboy, M., Landry, N. & Shtern, J. (2010). Digital solidarities, Communication policy and multi-stakeholder global governance: The legacy of the world summit on the information society. New York: Peter Lang.

Reuters (2003, 26 novembre). 'Master'’and 'slave' computer labels unacceptable, officials say. CNN. https://edition.cnn.com/2003/TECH/ptech/11/26/master.term.reut/

Sastre, P. (2017, 4 octobre). L’écriture inclusive, ça marchera jamais (et tant mieux). Slate. http://www.slate.fr/story/152102/ecriture-inclusive-marchera-jamais

Star, S. L. (2018). L’ethnographie des infrastructures. Tracés. Revue de Sciences humaines, 35, 187‑206. https://doi.org/10.4000/traces.8455

ten Oever, N. (2021). “This is not how we imagined it”: Technological affordances, economic drivers, and the Internet architecture imaginary. New Media & Society, 23(2), 344362. https://doi.org/10.1177/1461444820929320

Wajcman, J. (2004). TechnoFeminism. Cambridge, G-B: Polity Press.

Yates, J. (2019). Values, media, and genres for standardization. Dans W. Aspray (ed.) Historical Studies in Computing, Information, and Society (pp. 51–82). Cham: Springer. https://doi.org/10.1007/978-3-030-18955-6_4

Haut de page

Notes

1 Les débats présentés ici ont également eu lieu au sein de groupes de travail de l’Internet Research Task Force (IRTF). Alors que l’IETF a comme mandat de développer les standards d’Internet, l’IRTF mène plutôt des recherches de plus long terme à ce propos. Si les deux organisations sont en principe distinctes, l’IRTF est cependant complètement intégrée dans l’espace sociotechnique de l’IETF, y partageant les mêmes sites web, dispositifs de communication et moments de rencontre au point où l’IRTF est la plupart du temps implicitement incluse dans les références à l’IETF. Nous adoptons aussi cette perspective en incluant implicitement l’IRTF en désignant l’IETF.

2 Ce caractère public est pleinement assumé par l’IETF qui affirme clairement son « engagement à la transparence » dans son énoncé sur la vie privée en avertissant que toutes les « contributions, soumissions, déclarations et communications » faites dans le cadre de ses opérations sont rendues publiques. https://www.ietf.org/privacy-statement/

3 Tous les extraits présentés dans cette section ont été traduits par nous-mêmes.

4 Dans une discussion avec notre collègue François Cooren, celui-ci proposait de distinguer entre « êtres sémiotiques » qui sont utilisés pour faire signe, et « êtres non-sémiotiques » qui sont davantage utilisés pour faire infrastructure. Les standards d’Internet, même s’ils spécifient l’infrastructure, ne constituent pas l’infrastructure mais plutôt des signes pour spécifier comment l’infrastructure devrait être établie, donc plutôt d’ordre sémiotique qu’infrastructurel.

Haut de page

Pour citer cet article

Référence électronique

Stéphane Couture et Pauline Rudaz, « Quand les mots font des choses »Revue d’anthropologie des connaissances [En ligne], 18-2 | 2024, mis en ligne le 01 juin 2024, consulté le 12 décembre 2025. URL : http://journals.openedition.org/rac/33264 ; DOI : https://doi.org/10.4000/11r9m

Haut de page

Auteurs

Stéphane Couture

Professeur agrégé au département de communication de l’Université de Montréal et membre régulier du Centre interuniversitaire de recherche sur la science et la technologie (CIRST) et du Laboratoire sur la communication et le numérique (LabCMO). Ses recherches portent sur l’articulation de valeurs culturelles et politiques au design des technologies numériques.
ORCID : https://orcid.org/0000-0002-2588-6456

Adresse : Département de communication, Université de Montréal, Pavillon Marie-Victorin, FAS. Case postale 6128, succ. Centre-ville, H3C 3J7, Montréal (Canada).
Courriel : stephane.couture[at]umontreal.ca

Articles du même auteur

  • L'identité franco-ontarienne dans Wikipédia
    Pluralisation of knowledge and minority cultures. Franco-Ontarian identity in Wikipedia
    Pluralización del conocimiento y culturas minoritarias. La identidad Franco-Ontariana en Wikipedia
    Paru dans Revue d’anthropologie des connaissances, 14-4 | 2020
  • Le cas du commit comme acte d’écriture
    The collective writing of software source code
    La escritura colectiva de código fuente informático
    Paru dans Revue d’anthropologie des connaissances, 6-1 | 2012

Pauline Rudaz

Coordonnatrice de recherche à l’École nationale d’administration publique du Québec et à l’Institut Universitaire SHERPA. Au moment de l’étude, elle était étudiante à la maîtrise en communication de l’Université de Montréal et assistante de recherche pour Stéphane Couture.
ORCID : https://orcid.org/0009-0001-3405-4205


Adresse : Département de communication, Université de Montréal, Pavillon Marie-Victorin, FAS. Case postale 6128, succ. Centre-ville, H3C 3J7, Montréal (Canada).
Courriel : pauline.rudaz[at]gmail.com; pauline.rudaz[at]umontreal.ca

Haut de page

Droits d’auteur

CC-BY-NC-ND-4.0

Le texte seul est utilisable sous licence CC BY-NC-ND 4.0. Les autres éléments (illustrations, fichiers annexes importés) sont susceptibles d’être soumis à des autorisations d’usage spécifiques.

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search