Comment la langue peut cultiver l’inclusivité dans la technologie

En informatique, des termes tels que « maître/esclave », « liste noire » et « liste blanche », « tuer », « désactiver » et « abandonner » sont utilisés depuis des décennies par les programmeurs, les centres de services informatiques et même les utilisateurs. Malgré leur sens apparemment inoffensif en informatique, ces termes ont récemment fait l’objet de critiques pour leurs nuances raciales perçues, leur nature agressive et insensible.

Pourtant, peu a été fait pour changer le lexique. Avec des termes et un langage nuisibles ancrés dans les systèmes informatiques, les bases de code, la documentation et un éventail d’autres référentiels, la suppression est complexe. Trouver des mots plus inclusifs sur lesquels tout le monde peut s’entendre est également un défi, tout comme s’assurer que tout le monde utilise réellement les nouveaux termes.

Le besoin d’une terminologie inclusive n’est pas nouveau, mais l’injustice persistante a renforcé les mouvements de protestation politique et sociale et accru la sensibilisation à la question à l’échelle mondiale. La demande des employés et du public pour des améliorations en matière de diversité, d’équité et d’inclusion (DEI) est devenue un catalyseur de véritable changement. Grâce aux engagements des PDG à l’échelle mondiale, il n’y a jamais eu de meilleur moment pour apporter des changements significatifs aux initiatives commerciales DEI.

En ce qui concerne l’informatique, les DSI ont une opportunité unique d’agir maintenant pour adopter une approche de nommage plus inclusive pour les services informatiques dans l’ensemble de l’entreprise et, par la suite, dans le secteur. La langue n’est qu’un domaine, mais elle peut avoir et a un effet d’entraînement. Accorder plus d’attention à l’utilisation de mots inclusifs peut déclencher un cercle vertueux, attirant l’attention sur la nécessité d’autres pratiques inclusives.

Voici cinq étapes que les DSI peuvent suivre pour promouvoir un langage et des termes informatiques plus inclusifs, conduisant à une culture organisationnelle plus forte et plus inclusive.

Étape 1 : Constituez un groupe de travail avec le DSI à la barre

Les preuves montrent que le fait de s’attendre à ce que les employés assument volontairement des rôles liés à la DEI « au-delà » peut diluer l’impact et les progrès. Par exemple, si un DSI est informé par son PDG qu’il doit rejoindre le comité DEI de l’organisation, il peut le faire par obligation mais jouera un rôle passif, en supposant que le “vrai” travail DEI est effectué par les RH. Ce type de responsabilité collective signifie vraiment que personne n’est responsable en fin de compte, ce qui conduit les initiatives DEI à ne pas atteindre leurs objectifs.

S’il y a une incitation ou une conséquence attachée à l’atteinte ou à l’échec des objectifs DEI – comme affecter la note de performance et/ou la prime d’un employé – cela peut donner à l’initiative un vrai mordant. Par exemple, si l’un des objectifs de performance formels du DSI est lié au déploiement d’un langage inclusif dans l’ensemble de l’organisation informatique, cela offre une motivation plus spécifique et exploitable pour faire progresser la DEI dans l’ensemble de l’entreprise.

Pour lancer une initiative d’inclusivité linguistique, le CIO doit réunir une équipe multidisciplinaire et diversifiée pour y participer pendant une durée convenue (minimum de 12 mois). Incluez des membres de l’informatique ainsi que des parties prenantes de toute l’entreprise pour co-créer une vision et un objectif convaincants. Le CIO et les membres restants du groupe de travail peuvent alors prendre en charge les objectifs de l’initiative dans le cadre de leurs plans de développement formels et individuels.

Étape 2 : Concevoir un cadre d’évaluation pour la terminologie informatique

La langue, comme la culture, est complexe et en constante évolution. Différents termes peuvent avoir des significations différentes pour les individus de divers groupes. Un cadre robuste peut aider le groupe de travail à évaluer la terminologie informatique dans une perspective multidimensionnelle et multiculturelle. Les DSI peuvent envisager d’adapter les cadres existants pour simplifier ce processus, tels que le cadre librement disponible initialement développé par le groupe de travail sur le nommage de Kubernetes et adopté par l’initiative de nommage inclusif.

Le cadre doit définir une série de questions, ou « portes », pour déterminer si un terme est inclusif. Classez chaque porte par ordre de danger potentiel, la porte 1 étant la plus stricte. Par exemple:

• La porte 1 pourrait demander si le terme fait référence à un groupe de personnes dans des contextes extérieurs à la technologie et s’il est potentiellement dénigrant.
• La porte 2 pourrait demander si le terme a des connotations militaristes ou violentes, s’il est classiste ou s’il est fortement associé à un genre.
• La porte 3 pourrait demander si le terme est évocateur ou s’il attribue des qualités humaines aux systèmes technologiques.

Si le terme échoue au test à n’importe quelle porte, il doit être remplacé. Si le terme passe une porte, il peut passer à la porte suivante. En utilisant l’exemple susmentionné, on peut voir que des termes technologiques tels que “liste noire/liste blanche” ou “maître/esclave” échoueraient à la porte 1. Des termes tels que “marshal/unmarshal” échoueraient à la porte 2, tandis qu’un terme comme “heures de travail” échouerait à la porte 3.

Étape 3 : Identifiez les termes de remplacement et la liste de mots informatiques alternatifs

Une fois le cadre d’évaluation créé, concentrez-vous sur la compilation d’une liste de termes actuellement utilisés en informatique qui peuvent être considérés comme potentiellement dangereux ou excluants. Recueillez les commentaires de l’ensemble de l’organisation informatique sur les conditions de remplacement suggérées à l’aide de sessions d’écoute des employés et d’enquêtes pour vous assurer qu’aucune nuance culturelle n’est oubliée.

Le groupe de travail peut ensuite utiliser le cadre pour déterminer si les termes de la liste sont potentiellement problématiques. Adoptez un état d’esprit « en cas de doute, remplacez » pour tout terme qui manque de consensus. Il vaut mieux remplacer maintenant que regretter plus tard.

Pour les termes jugés devoir être remplacés, réfléchissez à d’autres termes, tels que “liste de blocage/liste d’autorisation” au lieu de “liste noire/liste blanche”. Recherchez des commentaires extérieurs pour suggérer des termes de remplacement en tirant parti de recherches tierces telles que les suggestions de l’Internet Engineering Task Force pour une terminologie inclusive ou les directives de l’American Psychological Association pour un langage sans préjugés. Faites en sorte que la liste des conditions de remplacement proposées et leurs alternatives soient librement accessibles en ligne pour que les employés des TI puissent les consulter et suggérer des ajouts.

Étape 4 : Mettre en œuvre un plan de remplacement

Une fois que la liste de mots alternatifs est complète, le groupe de travail peut commencer le processus de rectification du langage non inclusif. Cela peut être une tâche complexe; avec des termes et un langage nuisibles probablement utilisés dans une pléthore de bases de code, d’API et de bibliothèques, cela nécessite une approche méthodique.

Le groupe de travail doit d’abord décider s’il mettra à jour le langage qui existe déjà dans l’environnement d’exploitation ou s’il va commencer à utiliser de nouveaux termes à l’avenir. Changer le langage existant intégré dans la documentation actuelle et historique est un effort important, mais cela peut valoir la peine car il communique fortement un engagement envers un langage inclusif.

Il existe différents degrés de complexité et de risque selon l’endroit où le terme est utilisé. Par exemple, les mots de la documentation ou des pages Web peuvent être mis à jour à l’aide d’un simple “rechercher et remplacer”. Cependant, les noms de fonction ou les directives de configuration qui sont exposés en externe, par exemple via une API ou un fichier de configuration, nécessitent un plan de dépréciation pour éviter le risque d’interrompre les déploiements de production.

Plus un mot ou un terme a de dépendances, plus le risque et l’impact potentiel sont grands. Implémentez les modifications dans un environnement de test lorsque cela est possible, en utilisant des environnements intermédiaires pour vérifier l’impact sur la production. Assurez-vous que les changements planifiés sont communiqués aux communautés internes et externes, y compris les propriétaires d’applications, les fournisseurs et les tiers.

Étape 5 : Mener une campagne de « nouveau départ linguistique »

Les termes nuisibles font partie du lexique informatique depuis des décennies, ainsi quelques e-mails citant la nécessité de remplacer certains termes technologiques ne suffiront pas à provoquer un réel changement. Changer l’état d’esprit et les comportements dans la façon dont le langage est perçu et utilisé dans l’informatique nécessitera des efforts continus.

Lancez une campagne de “nouveau départ linguistique” en formant un conseil consultatif linguistique inclusif, qui continue de régir le processus de promotion d’un langage informatique inclusif. Ce groupe doit saisir toutes les occasions de diffuser le message selon lequel un langage inclusif est important. Les DSI peuvent régulièrement présenter l’initiative et ses progrès lors des assemblées publiques à l’échelle de l’informatique et de l’organisation. En utilisant le pouvoir de la responsabilité sociale, demandez aux employés de signer un engagement en ligne où ils s’engagent à utiliser un langage plus inclusif à la fois dans leur écriture/codage et dans leurs paroles.

Le CIO a également la possibilité d’influencer le changement dans son réseau externe. Partagez avec vos partenaires stratégiques le « pourquoi » derrière cette initiative, l’analyse de rentabilisation de l’utilisation d’un langage inclusif et les nouveaux termes qu’ils peuvent entendre utiliser par le personnel informatique. Pour aider les fournisseurs à adopter un langage plus inclusif, soyez explicite avec les attentes et partagez les détails de l’initiative.

Le CIO et le groupe de travail seront confrontés à des refus et des objections inévitables à chaque étape de ce processus au sein de l’organisation. Les employés s’opposeront à “perdre du temps” à ces efforts, déclareront cela comme un problème de “pente glissante”, déploreront “l’annulation de la culture” et s’opposeront au changement de langage qui est utilisé depuis longtemps sans que “personne ne s’y oppose auparavant”. Pour sortir de ces objections, démêlez des scénarios et anticipez des objections spécifiques. Communiquez de manière proactive avec des FAQ détaillées pour atténuer les inquiétudes et minimiser les voix dissidentes.

Le langage est un outil puissant et les DSI ont une réelle opportunité de passer à une culture plus inclusive en faisant évoluer le langage informatique. Avec une approche méthodologique et globale, les DSI peuvent faire leur part pour accompagner un changement culturel durable dans leurs organisations.