Écriture inclusive dans les logiciels : laissez-nous choisir !

Vous souvenez-vous de l’écriture inclusive ?

Depuis l’invasion de l’Ukraine, et même avant avec la pandémie de Covid, je trouve qu’on entend moins parler d’elle. Il n’y a qu’en temps de paix qu’on accorde de l’importance aux caprices de militants qui, gagnés par l’ennui, cherchent désespérément un sens à leur vie. Au moins, les crises que nous connaissons auront remis certaines choses à leur place pour un moment… Mais je n’entrerai pas plus dans ce débat ; ce n’est pas l’objet de ce billet.

Au fil des années, l’écriture inclusive s’est fait une petite place. On en lit sur Internet, dans la publicité, les courriels, la propagande politique. Ce n’est pas très grave, il suffit de regarder ailleurs. Le problème est qu’elle a aussi fleuri dans certains logiciels et, là, il n’y a pas de moyen d’y échapper. Soit il faut l’accepter, soit il faut changer d’outils ; c’est l’écriture inclusive ou rien.

Je trouve dommage que certains développeurs, militants ou par effet de mode, se permettent d’imposer un système d’écriture, qui plus est très contesté, à leurs utilisateurs. C’est particulièrement le cas dans le monde des logiciels dits « libres », ce qui est un comble. Je pense notamment à WordPress, le système de gestion de contenu le plus populaire, qui se fait des nœuds au cerveau pour mettre son logiciel en adéquation avec ses « valeurs d’inclusivité et de promotion de la diversité ». L’usage du mot « utilisateur » dans l’interface d’administration leur a beaucoup posé problème ; il était qualifié de « point particulièrement complexe et ‹ sensible › »…

Je suis de ceux qui pensent qu’on devrait avoir le choix. Il ne me choquerait pas, de la même façon, que les personnes qui se sentent « oppressées » par l’écriture traditionnelle – je n’en connais pas personnellement mais il paraît qu’elles existent – puissent choisir de basculer leurs applications en écriture inclusive.

Serait-ce si difficile de laisser le choix entre écriture traditionnelle et écriture inclusive aux utilisateurs de logiciels et d’applications ? Je suis certain que non.

Je publie ce blogue grâce à Dotclear – je vous le recommande. Dans les paramètres, j’ai choisi la langue « fr – français ». Mais cette option est très générale ; elle ne prend pas en compte les variations linguistiques qui peuvent exister au sein d’une même langue. Par exemple, le français n’est pas parlé ni écrit de la même façon dans toute la francophonie. C’est pourquoi les logiciels proposent parfois plusieurs versions : le français de France (fr-FR), le français canadien (fr-CA), etc.

En général, le paramètre de langue comprend donc un à deux « éléments » : la sous-balise de langue qui détermine la langue (fr pour « français » selon la norme ISO 639-1), et la sous-balise régionale qui lui associe une aire géographique (FR pour la France, suivant cette fois la norme ISO 3166 code alpha-2).

Ce qui est moins connu, c’est qu’on peut utiliser un troisième élément : la sous-balise de script, composée de quatre caractères, et qui permet de préciser le système d’écriture. Ainsi, le français en braille s’écrit fr-Brai, et le russe en alphabet cyrillique ru-Cyrl. Et il est possible de combiner les trois sous-balises. Un exemple d’actualité : ru-Cyrl-UA.

On pourrait donc très bien utiliser la sous-balise de script pour signaler l’utilisation de l’écriture traditionnelle ou de l’écriture inclusive. Je propose fr-Trad pour la traditionnelle et fr-Incl pour l’inclusive.

Ainsi, chacun serait libre de choisir son français et cela permettrait, à mon avis, d’apaiser certaines tensions – vous ne trouvez pas que les gens sont particulièrement à cran depuis quelque temps ? Les uns sont très opposés à l’écriture inclusive, les autres sont trop zélés, et on en arrive à des disputes stériles sur les réseaux sociaux voire dans le monde réel.

Techniquement, il est vrai que cela demanderait un peu plus de travail aux développeurs ; ils devraient préparer un fichier de langue supplémentaire, certes, mais il est très facile de convertir un texte traditionnel en écriture inclusive. C’est l’histoire de quelques points médians ; même moi je peux le faire.

Reste un problème : les logiciels suivent souvent la langue du système sur lequel ils s’exécutent. Alors, il faudrait que les systèmes d’exploitation eux-mêmes proposent le choix entre écriture traditionnelle et écriture inclusive suivant ce modèle :

• fr-FR pour ceux qui, en France, se moquent du type d’écriture de leurs applications ;
• fr-Trad-FR pour ceux qui préfèrent l’écriture traditionnelle ;
• fr-Incl-FR pour ceux qui préfèrent l’écriture inclusive.

Concrètement, voilà ce qui se passerait :

Admettons que je sois l’heureux possesseur d’un iPhone et que, lors de son premier lancement, je choisisse la langue fr-Incl-FR, car je vis en France et que je partage les « valeurs d’inclusivité et de promotion de la diversité ».

Si j’installe une application pour laquelle le développeur, français et de tendance conservatrice, propose une seule variante de français, fr-FR, en écriture traditionnelle, alors je n’aurai pas le choix : l’application sera en français de France et en écriture traditionnelle.

Si, en revanche, le même développeur finit par proposer, en plus, une version fr-Incl-FR, alors l’application s’affichera en écriture inclusive de mon côté, et en écriture traditionnelle à la fois chez ceux qui le souhaitent (fr-Trad-FR) et ceux qui s’en moquent (fr-FR).

Tout le monde serait satisfait. Même les développeurs et traducteurs qui, comme ceux de WordPress, sont actuellement obligés de proposer des traductions alambiquées résultant d’un en-même-temps contre-nature.