Code en français

« C’est ridi­cule ce getTauxRemboursementSecu(). Le code on le fait en anglais.

(refor­mu­la­tion libre de débats trou­vés sur Twit­ter)

Je ai eu ce débat quasi­ment dans chaque équipe que j’ai traversé. Les réponses n’ont pas toujours été les mêmes et — sans vous dire quoi faire dans votre situa­tion spéci­fique, bien que mon avis géné­rique soit assez tran­ché — je peux au moins parta­ger les expé­riences.

Ils ont choisi l’an­glais

Pour autant que je m’en souvienne ça a été décidé par cohé­rence, parce que c’est comme ça que ça se fait dans le déve­lop­pe­ment, parce que le langage lui-même est en anglais, ou/et pour avoir un jour des colla­bo­ra­teurs non fran­co­phones dans l’équipe.

Déci­sion facile

Je n’ai vu aucune équipe reve­nir sur cette déci­sion. Elle est comprise, accep­tée et respec­tée par tous. Tous savent ou pensent savoir parler assez anglais pour ça. Ça a même pu fait partie des critères de recru­te­ment (et peut-être que le fait que ça soit un critère de recru­te­ment a pu influen­cer la déci­sion).

Cohé­rence limi­tée

Atten­tion toute­fois à l’ar­gu­ment de cohé­rence dans le code pour avoir tout en anglais. On déchante en fait rapi­de­ment avec des cas spéci­fiques. Pour avoir vécu juste­ment le cas de l’in­tro­duc­tion, comment traduire « sécu­rité sociale » dans le taux de rembour­se­ment de la sécu­rité sociale ?

C’est un nom propre et utili­ser un terme géné­rique n’a pas trop de sens voire pour­rait induire en erreur si un jour il s’agit effec­ti­ve­ment d’al­ler à l’in­ter­na­tio­nal avec d’autres orga­nismes. Garder le terme français fait un peu sauter les argu­ment de cohé­rence et d’uni­for­mité du code.

Le problème appa­raît de toutes façons dès qu’on va à l’in­ter­na­tio­nal, qu’on soit en anglais ou en français, parce qu’il va falloir intro­duire des termes de plusieurs langues. Il reste que pour une équipe franco-française avec un produit français, on déchante un peu sur le béné­fice de cohé­rence attendu.

Jusqu’où aller

La limite n’est pas facile à trou­ver. Le code en anglais a parfois trans­piré sur les commen­taires de code, sur les discus­sions d’ar­chi­tec­ture et sur les propo­si­tions de chan­ge­ment (oui, j’ai traduit « pull request », que vas-tu faire ?), puis les commen­taires de ces demandes dans GitHub, les docu­men­ta­tions tech­niques, etc.

La limite est celle qui se trace entre la tech et le produit : le produit conti­nue à travailler dans leur langue natu­relle. L’idée d’ajou­ter une fron­tière supplé­men­taire entre tech et produit ne va malheu­reu­se­ment pas trop dans le sens que je souhaite pour mes équipes.

La seule équipe qui n’a pas eu ce problème c’était une équipe réel­le­ment inter­na­tio­nale sur plusieurs pays, dans une boite US. Eux n’ont jamais eu à se poser la ques­tion.

Les termes métiers

Où que soit la limite, j’ai souve­nir de diffi­cul­tés pour passer d’une langue à l’autre, de la créa­tion de lexiques pour nos termes et concepts métiers dans les diffé­rentes langues, et de débats sur comment repré­sen­ter tel ou tel concept juri­dique ou jargon spéci­fique qui n’a pas d’équi­valent dans une autre langue.

C’est moins simple qu’il n’y parait. Je crois qu’à chaque fois l’équipe s’est fait prendre par des faux amis, des traduc­tions malheu­reuses, et des termes impré­cis ou qui se sont révé­lés trop géné­riques, au point de poser problème.

C’est même arrivé dans une équipe qui travaillait sur un produit pour le Royaume Uni. Chan­ger un terme métier après coup parce qu’on a utilisé le mauvais dans tout l’en­vi­ron­ne­ment de déve­lop­pe­ment, c’est très loin d’être une évidence. Je pense qu’ils vivent encore avec un terme qui repré­sente des choses diffé­rentes suivant qu’il est utilisé dans le code ou dans le métier et par les utili­sa­teurs. C’est géné­ra­le­ment exac­te­ment la situa­tion qu’on cherche à éviter.

On ne maîtrise pas l’an­glais

Je crois que c’est mon préa­lable. La croyance que tout le monde parle anglais dans la tech est fausse. Presque tout le monde sait lire de l’an­glais tech­nique, avec un niveau de compré­hen­sion variable. La plupart savent écrire de l’an­glais, mais souvent avec un niveau de voca­bu­laire plutôt basique.

L’an­glais n’est pas maîtrisé, les nuances ne sont pas dispo­nibles, le voca­bu­laire reste géné­rique, les conno­ta­tions ne sont pas comprises ou pas voulues. On est parfois sur le niveau de langue d’un enfant de mater­nelle, mêlé à d’autres personnes qui ont une maîtrise assez élevée.

Un frein à la commu­ni­ca­tion

L’ef­fet majeur que j’ai vu, c’est toute­fois le frein à la commu­ni­ca­tion.

Le métier du déve­lop­pe­ment infor­ma­tique est majo­ri­tai­re­ment un métier social. L’enjeu n’est pas de taper des lignes mais de comprendre le métier, d’y trou­ver des solu­tions, et de faire avan­cer ensemble des projets. La commu­ni­ca­tion est au cœur.

L’an­glais qui trans­pire sur les commen­taires du code, c’est déjà un peu de frein. On utilise du voca­bu­laire moins précis et quelques faux amis. Ce n’est pas dit que la compré­hen­sion y gagne alors que les commen­taires sont déjà trop souvent sous-esti­més.

Avec de vrais impacts

Quand les échanges des propo­si­tions de modi­fi­ca­tion et des discus­sions d’ar­chi­tec­ture étaient fait en anglais, on avait une vraie perte mesu­rable : Des échanges moins cordiaux et plus d’in­com­pré­hen­sions.

Person­nel­le­ment je l’in­ter­prète parce qu’un langage mal maîtrisé, sans nuances, ça ne permet pas d’être effi­cace. On n’ex­plique pas les concepts de la même façon à un enfant de mater­nelle, et pour­tant on maîtrise souvent les langues étran­gères moins bien qu’un enfant de mater­nelle.

S’il y a une limite que je fixe­rais si jamais je devais passer à l’an­glais dans une équipe unique­ment française, c’est de ne pas dépas­ser les fichiers de code. Les demandes de modi­fi­ca­tion, les discus­sions d’ar­chi­tec­ture et tous les échanges ne doivent se faire que dans la langue la mieux maîtri­sée par l’équipe.

Ils ont choisi le français

Et les autres ? J’ai aussi eu des équipes qui ont choisi le français. Le code est alors mixte. Les fonc­tions pure­ment tech­niques sont géné­ra­le­ment en anglais. Les termes métiers sont par contre repris tels quels. Parfois ça donne même des noms de fonc­tion à moitié en français et à moitié en anglais, et pas qu’à cause des préfixes comme get ou set.

Déci­sion faible

C’est moche, peu convain­cant, ça semble bancale. La ques­tion se repose de temps en temps et les parti­sans de l’an­glais n’ont jamais semblé vrai­ment consi­dé­rer qu’on avait pris la bonne déci­sion (alors qu’en passant à l’an­glais, les parti­sans du français consi­dé­raient la ques­tion tran­chée défi­ni­ti­ve­ment et ne la relançaient pas). J’in­ter­prète ça comme une frus­tra­tion latente sur les inco­hé­rences qu’on rencontre quoti­dien­ne­ment.

J’ajou­te­rai que plus l’égo est grand, plus cette frus­tra­tion est impor­tante, surtout pour ceux qui sont en haut de la courbe de Dunning-Kruger avec l’im­pres­sion du « on ne fait pas comme il faudrait pour que ce soit bien fait, moi je sais comment il faudrait faire mais ils ne sont pas au niveau ».

Sans défaut

Pour autant, je n’ai jamais rien constaté comme problème si ce n’est cette frus­tra­tion de ceux qui aime­raient passer à l’an­glais.

Les termes métiers sont compris et parta­gés à l’iden­tique dans toute l’en­tre­prise. Les termes utili­sés sont tous compris par tous. Les échanges sont fluides. Les personnes se comprennent (et quand ce n’est pas le cas, le voca­bu­laire n’en est pas la source). Le code n’est pas plus diffi­cile à utili­ser pour autant, quand bien même il y aurait ce mélange de langues.

Et donc ?

Mon biais est proba­ble­ment évident. La pureté théo­rique rencontre souvent la réalité pratique. Le senti­ment de cohé­rence me semble bien bien moins impor­tant que les problèmes rencon­trés en utili­sant plusieurs langues dans l’en­tre­prise.

Tant que je peux utili­ser le français dans une entre­prise française consti­tuée à 90% de fran­co­phones, la ques­tion ne se pose quasi­ment plus pour moi.

Peut-être qu’un jour le person­nel de l’en­tre­prise devra s’in­ter­na­tio­na­li­ser, soit avec des bureaux dans d’autre pays, soit par un rachat. On prévoit ça comme un avenir souhai­table pour la crois­sance mais est-ce que ça va vrai­ment arri­ver ? À quelle échéance ? Est-ce qu’han­di­ca­per l’en­tre­prise en atten­dant est vrai­ment un bon inves­tis­se­ment ?

On parle souvent de dette tech­nique. Passer à l’an­glais trop tôt, est pour moi une vrai dette, majeure. Il est possible que l’in­ves­tis­se­ment soit perti­nent. Dans les cas que j’ai rencon­tré, c’était surtout une erreur.

---

J’ajou­te­rai : Atten­tion aux déci­sions prises par l’égo et par l’as­pi­ra­tion à faire ce qu’on pense que les autres font ou devraient faire. C’est un vrai facteur de mauvaises pratiques.

Plutôt que sélec­tion­ner mes recru­te­ment en fonc­tion du niveau en anglais, je préfère filtrer pour éviter les personnes qui mettent trop d’égo dans leurs choix et inter­ac­tions.