Faut-il coder en français ?

Article écrit par François Vantomme

Voici une question qui me taraude depuis quelque temps et à laquelle je souhaite apporter le fruit de mes réflexions et des échanges que j’ai pu avoir avec mes consœurs et confrères. Alors, faut-il coder en français ? Eh bien, ça dépend…

Oui ça évidemment, on vous demande de répondre par oui ou par non, alors « ça dépend » ça dépasse !

— Le Père-Noël est une ordure

C’est-à-dire que la question est complexe et demande d’être contextualisée pour pouvoir y apporter des éléments de réponse ou, à tout le moins, des axes de réflexion.

Au service de la France

Le contexte le plus évident qui nous vient à l’esprit quand on commence à se poser ce genre de question, c’est celui d’un projet réalisé par une équipe francophone, pour un commanditaire francophone, à destination d’un public francophone. Là, on en arrive vite à se demander pourquoi coder en anglais ? Quel intérêt à cela ? Qu’a-t-on à y gagner ?

C’est vrai que dans ce genre de situation, la question semble légitime. L’anglais n’étant généralement pas la langue maternelle d’un francophone, il en maîtrisera moins les subtilités. De plus, il y a fort à parier que la majorité des communications et échanges au sein de l’équipe, mais aussi avec le client et les utilisateurs se feront en français. Et ce n’est pas sans incidence, car si le choix de la terminologie s’est porté sur l’anglais, ça implique alors pour bien se comprendre en toute situation de tenir à jour un lexique bilingue, de manière à partager un vocabulaire commun. Si au contraire, le français avait été employé pour nommer toute chose dans l’application, nous aurions pu éviter cette étape de traduction parfois maladroite pour ne pas dire casse-gueule.

MOÏSE, Qu’est-ce qui vous a pris de répondre au téléphone ?
ANDRÉ MERLAUX, Eh bien (hésitant), le téléphone sonnait. Et j’ai décroché.
MOÏSE, La logique m’échappe. (silence) Je ne comprends pas.
ANDRÉ MERLAUX, Le téléphone… (silence) J’ai pensé que…
MOÏSE, Vous n’êtes pas à la Sécurité sociale Merlaux. La moindre information mal interprétée peut déclencher une guerre mondiale. (silence) Une guerre mondiale !

— Au service de la France, saison 1, épisode 1

Soyons honnêtes, il est très rare qu’un lexique soit défini, et encore plus rare qu’il soit partagé entre les équipes métier chez le client et les équipes techniques chez le prestataire. Alors maintenir un lexique bilingue relève de l’utopie ! Pourtant il est crucial de se comprendre. Lorsqu’on échange avec notre client, lorsqu’on souhaite réaliser un produit qui répond à ses besoins, il est nécessaire de comprendre ces besoins. Pour ce faire, il nous faut impérativement parler un langage commun. Et ce langage doit être celui du client. Il ne nous appartient pas en tant que prestataire d’imposer à notre client un vocabulaire qui lui est étranger. Notre métier consiste à comprendre le sien, puis à le modéliser le plus fidèlement possible sous la forme d’un programme informatique. À la lecture du code, tout ce qui fait la spécificité, la particularité, la nature unique du métier de notre client doit transpirer. Si votre client exerce dans le domaine médical, par exemple, il conviendra de parler de patient et non d’utilisateur.

Ce langage commun est appelé ubiquitous language par Eric Evans dans son livre « Domain Driven Design » ; un langage omniprésent donc, à la fois dans les échanges, mais également dans le code source.

Zazie dans le métro

Tout bien considéré, on se dit pourquoi pas tenter la chose ! Allons-y, faisons transparaitre le vocabulaire métier dans notre code ! Oui mais…

– glup, c’est d’un compliqué… Ah ! enfin, des mots que tout le monde connaît… vestalat… vésulien… vétilleux…euse… ça y est ! Le voilà ! Et en haut d’une page encore. Vêtir. Y a même un accent circonchose. Oui : vêtir. Je vêts… là, vous voyez si je m’esprimais bien tout à l’heure. Tu vêts, il vêt, nous vêtons, vous vêtez… vous vêtez… c’est pourtant vrai… vous vêtez… marant… positivement marant… Tiens… Et dévêtir ?… regardons dévêtir… voyons voir… déversement… déversoir… dévêtir… Le vlà. Dévêtir vé té se conje comme vêtir. On dit donc dévêtez-vous. Eh bien, hurla-t-il brusquement, eh bien, ma toute belle, dévêtez-vous ! Et en vitesse ! A poil !

— Zazie dans le métro de Raymond Queneau

Les errances du langage et une syntaxe malmenée font la singularité de cette œuvre de Raymond Queneau. C’est aussi ce qui caractérise les courageuses tentatives de l’emploi du français dans des bases de code, le génie en moins. Oui, ne nous mentons pas, quand on code en français, ça donne généralement quelque chose comme ça :

describe "DossierMailer" do   it "creates a commentaire" do     expect(DossierMailer).       to have_received(:notify_new_commentaire_to_instructeur).       with(dossier, instructeur_with_instant_message.email)   end end 

Aïe, ça pique les yeux. On a ici un exemple où l’effort a été fait d’utiliser le vocabulaire métier. On y retrouve « Dossier », « commentaire » ou encore « instructeur ». Mais l’effort s’arrête là puisqu’on se retrouve avec un mélange maladroit de français et d’anglais qui dessert l’objectif. Tout d’abord, la lecture s’en trouve malaisée, le cerveau fait des nœuds, ne sachant plus s’il lit un mot anglais ou français. Essayons de faire un peu mieux :

describe "ExpediteurDeDossier" do   it "crée un commentaire" do     expect(ExpediteurDeDossier).       to have_received(:notifier_d_un_nouveau_commentaire_a_l_instructeur).       with(dossier, instructeur_avec_message_instantane.courriel)   end end 

Ce n’est là que mon ressenti, mais je ne suis pas certain qu’on ait clarifié grand-chose… En fait, on butte sur plusieurs contraintes du langage et autres particularités de la langue. Tout d’abord, l’évidence : les mots clés du langage, ici Ruby, et des DSL comme celui de RSpec sont en anglais. Quand bien même vous feriez l’effort de traduire le DSL de RSpec en français, il vous serait impossible de redéfinir les mots réservés du langage.

Ensuite, la langue. On s’aperçoit, dès lors qu’on aborde des considérations techniques, que le vocabulaire associé est très souvent en anglais et il peut être difficile de trouver une traduction fidèle en français. Prenez « mailer » dans l’exemple ci-dessus, que j’ai maladroitement traduit par « expéditeur », faute de mieux. On remarque ici une perte de sens. On comprend bien que quelque chose sera envoyé, mais le fait que ce soit un courriel est totalement passé sous silence. Plutôt qu’« expéditeur de dossier », il aurait été plus correct de parler d’« expéditeur de courriel concernant un dossier ». Si vous aviez dans l’idée de vous limiter à des lignes de 80 caractères, vous pouvez oublier !

L’empire des signes

Notez aussi l’absence des diacritiques ! Ruby, comme bien d’autres langages, a beau supporter parfaitement UTF-8, on ne voit pour ainsi dire jamais un seul caractère accentué lorsque les variables sont en français. Et pourquoi diable !? Rien ne nous empêche de nommer nos variables Expéditeur ou message_instantané, pour reprendre l’exemple ci-dessus. Et en effet, c’est syntaxiquement valide du point de vue du langage. Mais j’y vois bien une contre-indication ou du moins quelque argument qu’on pourrait y opposer : ces caractères ne sont pas toujours facilement accessibles au clavier, cela va dépendre de sa disposition et si vous avez opté pour Qwerty, Dvorak ou Colemak, les touches accentuées vous seront moins facilement accessibles. Et je ne parle même pas des ligatures qu’on trouve par exemple dans sœur ou ex_æquo !

Maintenant, laissons là notre contexte franco-centré et imaginons que nous collaborions à un projet open source initié par un Japonais. En parcourant le code, on pourrait y lire ceci :

module Japanize   class Parser     def initialize(sequence)       @sequence = sequence     end      def parse       @sequence.split('　').map do |s|         s.split(/#{助詞.join("|")}/)       end.flatten.map do |s|         if 動詞[s]          動詞[s]         elsif 数字[s[0]]          NumberConverter.convert(s)         end       end     end   end end 

Ah tout de suite, à moins d’être japonisant, on fait moins le malin ! Même la coloration syntaxique du blog botte en touche ! Et pour cause : bien que ce code soit totalement valide et fonctionnel, l’utilisation de kanjis pour nommer les méthodes nous place dans une situation pour le moins inconfortable.

Lorsque Yukihiro «Matz» Matsumoto a commencé à développer Ruby en 1995, il a utilisé des mots-clés anglais, mais il écrivait toute la documentation en japonais ! En 2001, quand est publié Programming Ruby, la quasi-totalité de la documentation était encore en japonais. C’est pourquoi ce langage fut si peu utilisé en dehors de son archipel natal durant ses premières années. Mais à présent, c’est un langage utilisé à travers le monde, et le fait qu’il soit né au Japon n’a qu’un intérêt historique. Si le langage avait utilisé des mots-clés en hiragana, il aurait eu beaucoup plus de mal à gagner en popularité.

Ce qui nous amène à l’internationalisation. Les choses évoluent ; les contextes aussi. Il se peut qu’un projet soit amené à rencontrer un public plus vaste que prévu. Autant quand il s’agit d’un projet français à destination d’un ministère ou d’une collectivité territoriale, on peut raisonnablement penser que la langue vernaculaire sera le français ; autant quand il s’agit d’une suite bureautique, on a de bonnes raisons de mettre cette affirmation en doute.

The Office

Une évolution de contexte, c’est justement ce qui est arrivé à StarOffice. Initialement développé par l’entreprise allemande Star Division, ce projet a été libéré en 2000 suite au rachat de l’entreprise par Sun, donnant ainsi naissance à OpenOffice et ouvrant la porte à une communauté internationale de contributeurs. Seul hic, la base de code comportait quelque 100 000 lignes de commentaires en allemand ! La traduction de ces commentaires en anglais s’est étalée de 2011 à 2018.

Et on ne parle ici que de documentation ! Imaginez si les classes, les méthodes, les variables et autres constantes étaient elles aussi formulées en allemand… ç’aurait été une autre paire de manche !

Alors quoi ?

Nous venons de voir que choisir de coder et documenter en français peut avoir de forts impacts, tant positifs que négatifs. C’est pourquoi il est important que ce choix soit fait en conscience. Et si vous optez pour le français, faites-le pleinement ! Cela évitera des résultats hybrides dont tout le monde se serait bien passé. Écrivez votre code en français, dans la limite des possibilités offertes par votre langage et des conventions de nommage. Mais rédigez aussi vos commits, vos tests et votre documentation en français.

Ce faisant, les échanges avec le métier seront plus fluides. Pas besoin de traduire le langage métier en langage technique, et vice-versa. La terminologie gagnera aussi en précision. Lorsqu’il s’agit d’un domaine métier ayant un vocabulaire riche et précis (légal, médical…), et que celui-ci vous est transmis en français, trouver une correspondance en anglais peut s’avérer délicat voire hasardeux quand on n’est ni bilingue, ni du métier. Au final, le code et tout ce qui aura été produit traduiront avec une grande fidélité le besoin exprimé par le client si l’on s’épargne la phase de traduction.

Si au contraire vous optez pour l’anglais, c’est correct. Mais soyez rigoureux et vigilant ; veillez à ce que des termes français ne se glissent pas au beau milieu de votre code ou d’une description de merge request. Efforcez-vous aussi à rédiger dans un anglais correct plutôt qu’un globish saupoudré de franglicismes.

Rédigé en français, le code n’est plus accessible aux non-francophones. À l’inverse, rédigé en anglais il sera peut-être moins abordable pour qui n’est pas à l’aise avec cette langue. Dans les deux cas, cela pose la question de l’inclusion et de l’intégration au sein de votre entreprise ou communauté.

Peu importe votre choix, assumez-le, faites-le vôtre, et itérez pour trouver le compromis qui, selon votre contexte, vous permettra d’en tirer le meilleur bénéfice.