souvent c’est un vœu pieux, et/ou la visée d’une externalisation du développement dans un pays où le développement coute beaucoup moins cher.
Je suis moi-même indépendant et n'ai quasiment jamais travaillé sur un projet où il n'y avait pas un dev freelance non-francophone bien que les projets soient franco-français. C'est tellement facile, rapide et pas cher de trouver un chinois, indien, péruvien, polonais, ukrainien, sud-africain, camerounais, marocain (et oui je sais que les 2 derniers sont francophones mais ils ont l'habitude eux aussi de travailler en anglais donc c'est plus naturel pour eux dans le code). Bref ça peut arriver très vite cette externalisation, même sur des petits projets.
Sinon, je suis d'accord avec tout le reste, en particulier :
le code n’est pas perçu comme « de l’anglais » mais « du code », avec sa structure, sa grammaire et son vocabulaire propre. Pour le dire autrement : lire du code, ça n’est pas lire des phrases. Que ce code soit partiellement en « anglais » (en « code » donc, le langage de programmation) et partiellement en français ne me pose pas de problème.
Je code en anglais. Je suis une bille en anglais même si je progresse, mais je travaille dans une entreprise où mon équipe a des polonais (en freelance ils ne sont pas payés moins que moi), anglais, américains, suédois,… sur du logiciel libre.
Ma perception est que le problème est moins l’anglais que notre capacité à nous moquer les uns des autres sur la qualité de notre anglais et même de notre français.
La majorité des problèmes que tu décrit seraient tout à fait vivable si on arrêtait de faire les coqs à jouer à l’académicien.
Ma perception est que le problème est moins l’anglais que notre capacité à nous moquer les uns des autres sur la qualité de notre anglais et même de notre français.
La majorité des problèmes que tu décrit seraient tout à fait vivable si on arrêtait de faire les coqs à jouer à l’académicien.
Le problème principal que je décris dans ce billet n’est absolument pas dans la perception du niveau d’anglais et dans le temps perdu à corriger autrui ou à chercher la perfection linguistique. Ces points peuvent correspondre à la partie « insécurité linguistique ».
Le problème principal, c’est la différence d’efficacité entre un travail dans une langue parfaitement maitrisée et un travail dans une langue mal maitrisée. Et cette différence peut être massive, et ce même si la qualité du langage n’est pas perçu comme un problème par les intervenants.
Un environnement de travail peut être bienveillant sur le plan linguistique et complètement inefficace parce que les gens n’auront pas les capacités à exprimer facilement des idées complexes, à comprendre ces idées, à les transmettre, à les documenter, etc. à cause de la langue.
Posté par barmic 🦦 .
Évalué à 2 (+0/-0).
Dernière modification le 29 juin 2025 à 10:13.
Ce n’est que mon point de vu mais mon expérience majoritairement local (ça ne fait qu’un an que je suis dans un contexte international), j’ai l’impression d’avoir vu plus de problème lié à de l’implicite qu’à un défaut de maitrise du français.
Mon avis c’est que c’est désagréable parce qu’on fait tout pour que l’anglais le soit, mais que ça n’a pas une grande importance.
Le ne suis pas contre de coder en français (comme je disais c’est l’un des conseils du DDD), mais par défaut ce sera forcément l’anglais pour ne pas ajouter une barrière comme celle que les contributeurs d’OOo/LibO ont eu à faire face avec de l’allemand. Mais là aussi c’est personnelle l’accessibilité m’intéresse plus que l’efficacité.
En fait j’ai la même impression pour l’usage de l’anglais que pour gérer une prod par exemple. C’est douloureux au début parce qu’on est mal préparé.
Je ne te suis pas : le billet parle du problème de maitrise de l’anglais dans un contexte francophone.
Les exemples d’une équipe internationale (supposément : non-francophone) sont donc hors sujet ; c’est même explicite dans le dernier point de la dernière section :
Enfin, autorisons-nos à coder en anglais si c’est pertinent. Parce que le but de ce billet n’est absolument pas de dire que c’est à proscrire : il faut se poser la question de la pertinence et être conscient que cette décision a des impacts non négligeables sur la productivité des équipes.
Je ne te suis pas : le billet parle du problème de maitrise de l’anglais dans un contexte francophone.
C’est l’exemple de LibO qui te fait dire ça ? LibO est basé sur OOo lui même basé sur StarOffice. StarDivision avant d’avoir était racheté par Sun était une entreprise allemande. Ils ont codés au moins en partie en allemand et il aura fallu un effort spécifique de la document fundation des années plus tard pour que le projet perde cet allemand.
Je suis d’accord que c’est un exemple et pas une généralité, mais c’est un exemple de comment l’usage d’une langue peut devenir une dette technique douloureuse.
Tu dis :
Enfin, autorisons-nos à coder en anglais si c’est pertinent.
Comment StarDivision aurait pu mieux évaluer cette pertinence ?
Moi je dis l’inverse : « autorisons-nos à coder en français si c’est pertinent ».
Il y a un truc, par contre, qui est typique, et un peu agaçant, c'est quand on confère un sens spécifique - voire magique - au terme anglais alors que son équivalent en français porte le même sens. Ça mène à utiliser des termes dont on ignore le sens en français, qui deviennent des termes-concepts, au sens un peu flou. Des trucs comme thread, stack, log, proxy, prompt, policy… Ça pourrait ressembler à du jargon mais ça n'en est pas vraiment. C'est vraiment la situation ou le terme en français est considéré comme "incorrect" car supposé ne pas avoir le même sens - alors que si. Souvent, il se cache dessous une mauvaise maîtrise du concept.
Dans mon cas, ça m'est arrivé à trois reprises d'être dans une équipe qui s'internationalise (avec des États-uniens, Italiens, Allemands), et avoir toute la doc et les noms de variables en anglais au départ a bien aidé. C'est vrai que ça peut être un frein si tu embauches une personne qui a un niveau d'anglais moyen.
Anecdote amusante, j'ai acheté un bouquin d'apprentissage au Python1, écrit par un Français, et les noms de variables sont carrément avec des accents, c'est assez amusant à considérer :). Du coup dans l'interpréteur interactif, j'ai essayé avec des noms de variables dans une langue qui se lit de droite à gauche, ça donne de drôles de trucs en terme de gestion du curseur 😅.
Apprenez à programmer en Python, de Vincent Le Goff, qui est pas mal du tout2 pour apprendre ce langage. ↩
Il y a aussi Scripting Python sous Linux de Christophe Bonnet qui est bien, plus orienté cas pratiques. ↩
Perso je me suis amusé une fois sur un projet perso en Python/Django à tout coder en français avec accents, pour voir les limites de la démarche. Et bah en fin de compte ça passe assez bien. Les plus gros bugs que j'ai eu concernent la coloration syntaxique de mon éditeur préféré.
par exemple nous autres, les francophones, on a tendance à abrévier "nombre" en "nb", qui est peu compris par les anglophones (ou les non-francophones), et il faut préférer "num" : num_cars sera mieux compris que nb_cars.
idem pour notre KO (c'est plus dans les rapports de test que dans les noms de variables) qu'on oppose à OK. j'ai déjà dû expliquer, alors que un NOK est toujours compris.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Imagine du code québecois : nb_chars ? Tu comptes les caractères ou les voitures ?
Ma parade est d'utiliser des noms de variable, de classe, de fonction… à rallonge, quitte à exaspérer mes collègues :).
Ça pourrait donner nombre_de_voitures ou number_of_cars (mais je mettrais plutôt cars_count ou quantity_of_cars).
Au final, je crois que le plus important est d'essayer d'être cohérent et d'éviter les mélanges. Et dès qu'on utilise des bibliothèques tierces, ça devient super difficile (EndEntity vs end_entity vs endentity ?)
Posté par barmic 🦦 .
Évalué à 3 (+1/-0).
Dernière modification le 28 juin 2025 à 09:26.
idem pour notre KO (c'est plus dans les rapports de test que dans les noms de variables) qu'on oppose à OK. j'ai déjà dû expliquer, alors que un NOK est toujours compris.
Je m'en étais jamais rendu compte. Knock out et KO sont tout de même largement utilisés pas uniquement en box. Qu'ils soient surprenant oui, mais de là à ne pas le comprendre. C'était avec des américains ou des anglais ?
Après sans barrière de langue particulière j'ai pas réussi à faire comprendre que index c'est aussi le nom de structure de données et pas seulement un indice.
Époque où j'étais chez Intel, donc il y avait pas mal de monde (style de boîte qui tourne 24h/24), mais il me semble bien que c'était un Ricain qui m'avait fait confirmer style "you mean not OK right ?"
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Peut être il voulait simplement vérifier que le « KO » n'était pas le fruit d'une main engourdie ; plutôt que de faire expliciter le sens de l'acronyme.
# _« Freelance Offshore »_ ou « Prestataire indépendant à l’international »
Posté par Faya . Évalué à 4 (+2/-0).
Je suis moi-même indépendant et n'ai quasiment jamais travaillé sur un projet où il n'y avait pas un dev freelance non-francophone bien que les projets soient franco-français. C'est tellement facile, rapide et pas cher de trouver un chinois, indien, péruvien, polonais, ukrainien, sud-africain, camerounais, marocain (et oui je sais que les 2 derniers sont francophones mais ils ont l'habitude eux aussi de travailler en anglais donc c'est plus naturel pour eux dans le code). Bref ça peut arriver très vite cette externalisation, même sur des petits projets.
Sinon, je suis d'accord avec tout le reste, en particulier :
Le mélange des genres ne va pas me gêner.
# commentaire en français
Posté par Nicolas Boulay (site web personnel) . Évalué à 7 (+4/-0).
J'avoue que je code en anglais, mais la doc et les commentaires sont en français : c'est plus concis, plus précis et plus rapide pour tout le monde.
"La première sécurité est la liberté"
# bof
Posté par barmic 🦦 . Évalué à 2 (+2/-2).
Je code en anglais. Je suis une bille en anglais même si je progresse, mais je travaille dans une entreprise où mon équipe a des polonais (en freelance ils ne sont pas payés moins que moi), anglais, américains, suédois,… sur du logiciel libre.
Ma perception est que le problème est moins l’anglais que notre capacité à nous moquer les uns des autres sur la qualité de notre anglais et même de notre français.
La majorité des problèmes que tu décrit seraient tout à fait vivable si on arrêtait de faire les coqs à jouer à l’académicien.
Après le DDD conseil d’utiliser la langue locale.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: bof
Posté par BAud (site web personnel) . Évalué à 3 (+2/-1). Dernière modification le 27 juin 2025 à 20:33.
je n'ai pas bien compris : ils sont payés autant que toi et tu n'es pas là bas à boire de la bonne vodka ?
pozdrowiena
[^] # Re: bof
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Le problème principal que je décris dans ce billet n’est absolument pas dans la perception du niveau d’anglais et dans le temps perdu à corriger autrui ou à chercher la perfection linguistique. Ces points peuvent correspondre à la partie « insécurité linguistique ».
Le problème principal, c’est la différence d’efficacité entre un travail dans une langue parfaitement maitrisée et un travail dans une langue mal maitrisée. Et cette différence peut être massive, et ce même si la qualité du langage n’est pas perçu comme un problème par les intervenants.
Un environnement de travail peut être bienveillant sur le plan linguistique et complètement inefficace parce que les gens n’auront pas les capacités à exprimer facilement des idées complexes, à comprendre ces idées, à les transmettre, à les documenter, etc. à cause de la langue.
La connaissance libre : https://zestedesavoir.com
[^] # Re: bof
Posté par barmic 🦦 . Évalué à 2 (+0/-0). Dernière modification le 29 juin 2025 à 10:13.
Ce n’est que mon point de vu mais mon expérience majoritairement local (ça ne fait qu’un an que je suis dans un contexte international), j’ai l’impression d’avoir vu plus de problème lié à de l’implicite qu’à un défaut de maitrise du français.
Mon avis c’est que c’est désagréable parce qu’on fait tout pour que l’anglais le soit, mais que ça n’a pas une grande importance.
Le ne suis pas contre de coder en français (comme je disais c’est l’un des conseils du DDD), mais par défaut ce sera forcément l’anglais pour ne pas ajouter une barrière comme celle que les contributeurs d’OOo/LibO ont eu à faire face avec de l’allemand. Mais là aussi c’est personnelle l’accessibilité m’intéresse plus que l’efficacité.
En fait j’ai la même impression pour l’usage de l’anglais que pour gérer une prod par exemple. C’est douloureux au début parce qu’on est mal préparé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: bof
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Je ne te suis pas : le billet parle du problème de maitrise de l’anglais dans un contexte francophone.
Les exemples d’une équipe internationale (supposément : non-francophone) sont donc hors sujet ; c’est même explicite dans le dernier point de la dernière section :
La connaissance libre : https://zestedesavoir.com
[^] # Re: bof
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
C’est l’exemple de LibO qui te fait dire ça ? LibO est basé sur OOo lui même basé sur StarOffice. StarDivision avant d’avoir était racheté par Sun était une entreprise allemande. Ils ont codés au moins en partie en allemand et il aura fallu un effort spécifique de la document fundation des années plus tard pour que le projet perde cet allemand.
Je suis d’accord que c’est un exemple et pas une généralité, mais c’est un exemple de comment l’usage d’une langue peut devenir une dette technique douloureuse.
Tu dis :
Comment StarDivision aurait pu mieux évaluer cette pertinence ?
Moi je dis l’inverse : « autorisons-nos à coder en français si c’est pertinent ».
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: bof
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4 (+2/-0). Dernière modification le 30 juin 2025 à 00:10.
Non, c’est le fait que c’est moi qui ait écrit ce billet, donc je suis plutôt bien placé pour savoir de quoi il parle.
Ce billet est basé à la fois sur mon expérience personnelle et sur des expériences lues ou entendues ailleurs. D’ailleurs je ne suis pas le seul à tenir ce genre de discours, cf par exemple https://n.survol.fr/n/code-en-francais et sa suite https://n.survol.fr/n/anglais-ou-francais
Oui, c’est ce que dit 90 % du billet aussi.
La connaissance libre : https://zestedesavoir.com
# Devenir une équipe internationale
Posté par cg . Évalué à 6 (+4/-0).
Hello, chouette billet !
Il y a un truc, par contre, qui est typique, et un peu agaçant, c'est quand on confère un sens spécifique - voire magique - au terme anglais alors que son équivalent en français porte le même sens. Ça mène à utiliser des termes dont on ignore le sens en français, qui deviennent des termes-concepts, au sens un peu flou. Des trucs comme thread, stack, log, proxy, prompt, policy… Ça pourrait ressembler à du jargon mais ça n'en est pas vraiment. C'est vraiment la situation ou le terme en français est considéré comme "incorrect" car supposé ne pas avoir le même sens - alors que si. Souvent, il se cache dessous une mauvaise maîtrise du concept.
Dans mon cas, ça m'est arrivé à trois reprises d'être dans une équipe qui s'internationalise (avec des États-uniens, Italiens, Allemands), et avoir toute la doc et les noms de variables en anglais au départ a bien aidé. C'est vrai que ça peut être un frein si tu embauches une personne qui a un niveau d'anglais moyen.
Anecdote amusante, j'ai acheté un bouquin d'apprentissage au Python1, écrit par un Français, et les noms de variables sont carrément avec des accents, c'est assez amusant à considérer :). Du coup dans l'interpréteur interactif, j'ai essayé avec des noms de variables dans une langue qui se lit de droite à gauche, ça donne de drôles de trucs en terme de gestion du curseur 😅.
Apprenez à programmer en Python, de Vincent Le Goff, qui est pas mal du tout2 pour apprendre ce langage. ↩
Il y a aussi Scripting Python sous Linux de Christophe Bonnet qui est bien, plus orienté cas pratiques. ↩
[^] # Re: Devenir une équipe internationale
Posté par Pol' uX (site web personnel) . Évalué à 3 (+1/-0).
Perso je me suis amusé une fois sur un projet perso en Python/Django à tout coder en français avec accents, pour voir les limites de la démarche. Et bah en fin de compte ça passe assez bien. Les plus gros bugs que j'ai eu concernent la coloration syntaxique de mon éditeur préféré.
Adhérer à l'April, ça vous tente ?
[^] # Re: Devenir une équipe internationale
Posté par gUI (Mastodon) . Évalué à 8 (+5/-0).
et même là, méfiance !
par exemple nous autres, les francophones, on a tendance à abrévier "nombre" en "nb", qui est peu compris par les anglophones (ou les non-francophones), et il faut préférer "num" :
num_carssera mieux compris quenb_cars.idem pour notre KO (c'est plus dans les rapports de test que dans les noms de variables) qu'on oppose à OK. j'ai déjà dû expliquer, alors que un NOK est toujours compris.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Devenir une équipe internationale
Posté par cg . Évalué à 5 (+3/-0).
Imagine du code québecois :
nb_chars? Tu comptes les caractères ou les voitures ?Ma parade est d'utiliser des noms de variable, de classe, de fonction… à rallonge, quitte à exaspérer mes collègues :).
Ça pourrait donner
nombre_de_voituresounumber_of_cars(mais je mettrais plutôtcars_countouquantity_of_cars).Au final, je crois que le plus important est d'essayer d'être cohérent et d'éviter les mélanges. Et dès qu'on utilise des bibliothèques tierces, ça devient super difficile (EndEntity vs end_entity vs endentity ?)
[^] # Re: Devenir une équipe internationale
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0).
C'est de toutes façons la bonne solution. Je me suis jamais plaint de noms à rallonge (*), par contre je me suis plaint de code incompréhensible.
(*) Si, quand ils étaient à rallonge… mais faux parce que la variable avait changé de rôle entre temps mais pas de nom
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Devenir une équipe internationale
Posté par Pol' uX (site web personnel) . Évalué à 1 (+0/-1).
Pourtant les vrais programmeurs n'utilisent que des noms de variables à une lettre.
Adhérer à l'April, ça vous tente ?
[^] # Re: Devenir une équipe internationale
Posté par barmic 🦦 . Évalué à 3 (+1/-0). Dernière modification le 28 juin 2025 à 09:26.
Je m'en étais jamais rendu compte. Knock out et KO sont tout de même largement utilisés pas uniquement en box. Qu'ils soient surprenant oui, mais de là à ne pas le comprendre. C'était avec des américains ou des anglais ?
Après sans barrière de langue particulière j'ai pas réussi à faire comprendre que index c'est aussi le nom de structure de données et pas seulement un indice.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Devenir une équipe internationale
Posté par BAud (site web personnel) . Évalué à 3 (+2/-1).
des indiens je pense ;-)
[^] # Re: Devenir une équipe internationale
Posté par cg . Évalué à 5 (+3/-0).
Des Indiens d'Inde, d'Amérique du Nord ou d'Amérique du Sud :p ?
[^] # Re: Devenir une équipe internationale
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Époque où j'étais chez Intel, donc il y avait pas mal de monde (style de boîte qui tourne 24h/24), mais il me semble bien que c'était un Ricain qui m'avait fait confirmer style "you mean not OK right ?"
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Devenir une équipe internationale
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Peut être il voulait simplement vérifier que le « KO » n'était pas le fruit d'une main engourdie ; plutôt que de faire expliciter le sens de l'acronyme.
Adhérer à l'April, ça vous tente ?
# tout aussi dangereuse
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
La tendance à utiliser le nom d'un produit et sa fonction.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.