Une des difficultés lors du démarrage d’un projet informatique en France est de savoir si le développeur doit coder en français ou en anglais.

Dans notre imaginaire collectif de développeur, un projet informatique c’est un gros projet visible pour les utilisateurs finaux, développé par une société solide et visionnaire. Un projet à la pointe de la technique, avec une équipe soudée et qui aura un tel succès qu’il se fera racheté par une société internationale…​

La réalité est tout autre : beaucoup de sociétés développent en interne des outils spécifiques qui resteront pour le marché français et développés puis maintenus par des développeurs Français (souvent externalisé en ESN). Il peut s’agir de petits projets B2B (et donc qui ne brillent pas par leur visibilité auprès du grand public), ou alors des outils internes qui resteront dans le périmètre des applications de gestion pour gérer la RH, la comptabilité, les process métiers, etc.

Alors, s’il est évident que l’entreprise ou le projet dispose d’une équipe internationale, l'*anglais va s’imposer naturellement, il en est autrement de tous ces petits projets Franco-Français où l’adoption de l’anglais est loin d’être une évidence, et fait souvent l’objet de débats entre ceux qui ont une approche très théorique et veulent absolument coder en anglais "parce que les vrais développeurs codent en anglais" et ceux qui ont une approche plus conservative "On est en France, on code en Français".

Est-ce que la réalité ne se trouverait pas entre les deux ?

On peut revenir sur plusieurs fausses idées entendues :

"L’anglais est la langue commune des informaticiens".

Une équipe de développeur est loin d’être toujours constituée de développeurs Bac+5 ayant fait leur stage de fin d’étude aux USA et étant à l’aise en anglais. Ce serait une vision bien réduite du développeur. Comme partout, il y a des développeurs de tout age, de tout niveau (Bac+2 → Bac+5), mais également des développeurs qui issus de reconversion professionnelle, de mutation internes, etc.

De plus, lors processus de recrutement, même si le poste requiert un niveau minimum en anglais, ce dernier est rarement testé si la société n’a pas un contexte de développement international.
En pratique, tout le monde n’est pas à l’aise avec l’anglais et tout le monde n’en a pas le même niveau de compréhension.

"En entreprise, on code toujours en anglais"

Souvent entendu lors des cours d’informatique à l’Université, et source de déception dès l’entrée dans le monde du travail : beaucoup de projets sont en Français.

De manière plus large, c’est comme s’imaginer que tout le code est le fruit des meilleures techniques de développements, avec des algorithmes élaborés, bien documentés et donc codé en anglais.
La réalité est aussi beaucoup moins rose : il existe du patrimoine Legacy, codé "avec les moyens du bord", du code temporaire qui reste des années, du code à-la-va-vite-parcequ’on-est-pressé, du code réalisé sans cadre, sans s’imposer de règle de développement…​

"Coder en anglais pour anticiper un développement à l’étranger".

En effet, on ne sait jamais non plus de quoi l’avenir sera fait.

Et si en effet, pour beaucoup de sociétés privées, cette option a du sens en terme de stratégie de long terme (rachat par un plus gros groupe, expansion à l’international, etc..), ou bien pour réduire les coûts de développement (externalisation en offshore - même si c’est discutable), pour certains autres acteurs ce n’est pas envisageable.

C’est le cas des projets d’administrations publiques de certaines sociétés nationales qui vont privilégier des développements en interne, dans un contexte Français…​

Et si coder en français n’était pas une si mauvaise chose ?

La réalité est donc souvent plus pragmatique, et il faut souvent composer avec les sensibilités de chacun et du contexte du projet.

En France, dès lors que l’on travaille pour une société/institution nationale, il y’a fort à parier que cette sacro-sainte règle du “codage en anglais” ne soit pas prise en compte, et que l’on privilégie finalement un codage en français.

Quelques éléments peuvent nous aider à de comprendre pourquoi ce n’est pas forcément une mauvaise chose et s’en tirer en gardant du code de qualité.

Privilégier le Langage Omniprésent

En DDD, une notion importante est l’Ubiquitous Language, ce langage qui sert de langue commune entre le développeur et l’utilisateur.

En l’adaptant au contexte de développement Agile, le Product Owner, le Business Analyst et le Developpeur doivent se comprendre en utilisant des termes identiques. Ils se comprennent car ils utilisent le même jargon métier. Les concepts sont partagés et représentent une définition commune au sein de l’équipe Projet.

Et c’est là une des difficultés de développer en Anglais : Si l’équipe PO/BA rédige les US en Français et que le développeur code en anglais, il n’y a plus de langue commune.

Celà impose à l’équipe de traduire en permanence les concepts métiers, qui amène des confusions et est source de frustrations et d’erreurs.

Sans compter le manque de précision, les ambiguités et faux-amis apportés par certains éléments de langages qui peuvent atténuer la précision d’un concept ou en détourner le sens.

Eviter les ambiguités et faciliter la compréhension

Il est préférable de coder et de commenter dans un langage que l’on maitrise pour éviter les malentendus et pour faire apparaitre les subtilités de langage.

Comme on l’a vu précédemment, si l’anglais était fortement adopté et si tout le monde était à l’aise avec l’anglais, la question ne se poserait pas. Mais ce n’est évidemment pas le cas.

Certains ne sont pas à l’aise avec l’anglais, et - par fierté - ne vont peut-être pas l’admettre. Se forcer à coder en anglais alors que l’équipe n’est pas à l’aise risque de conduire à des nommages ou des commentaires peu précis, et des incompréhensions et donc à des sources d’erreurs, un manque de lisibilité et maintenabilité.

Il est préférable, dans ce cas, de coder en Français pour faciliter un nommage cohérent et précis tout en disposant de commentaires pertinents tirant parti des subtilités du langage maitrisé par l’équipe.

Coder en Français, OK, mais comment maintenir la lisibilité ?

Accepter d’avoir du code en Français, c’est indubitablement se confronter à du code en Franglais : le code issu de la conception et du langage Métier est en français, mais le code issu du langage, framework et librairie est en anglais.

Le mélange des deux mondes (Technique et Fonctionnel) impliquera donc indubitablement un mix Français/Anglais…​

Pour garder un code lisible et donc maintenable, il est important de s’imposer des règles et de rester cohérent sur l’application.

Entités et Services Métier

Pour les entités du modèle métier, les concepts calquent le langage commun entre les développeurs et le Product Owner / Business Analyst. Il est donc important qu’il soit en Français.

Les classes de Service qui s’appuient sur ces concepts métiers pour les manipuler via des méthodes doivent suivre la même approche. Les noms des méthodes manipulant les concepts Métiers doivent également rester en Français pour simplifier la compréhension, notamment lorsqu’il s’agit de processus métier.

On retrouve donc :

  • Les noms des classes du modèle métiers, leurs attributs et méthodes

  • Les classes de Service, et leurs méthodes

Quelques exemples : StatutCarte, CoordonneeBancaire, ̀Contact.nom, AideSaisie.categorie, UtilisateurService.creerFiche(),BudgetService.genererRapport(), CommandeService.cloturerCommande()

Quelques contre-exemples : UserService.createNouvelleFiche(), PaysService.exists(codeIso)

Eviter les mot-vides

Un mot-vide est un mot tellement commun qu’il n’apporte aucune information supplémentaire à la compréhension. Les mot-vides les plus courants que l’on peut retrouver dans les nommages sont "le", "la", "du", "de", "d'", "avec", "dans", etc.

FicheDeLiaison → FicheLiaison
UniteDOrganisation → UniteOrganisation
AideALaSaisie → AideSaisie
StatutDeLaDemande → StatutDemande

Briques Techniques

Les briques purement techniques de l’application, c’est-à-dire tous les concepts qui ne sont pas manipulés par les PO/BA/utilisateur et ne font donc pas parti du langage commun, doivent rester en Anglais. De plus, souvent, ces briques techniques se lient aux frameworks/librairies existants et il est donc préférable de garder les concepts manipulés par ces librairies/frameworks, sans chercher à les traduire.

On retrouve notamment les briques de configuration, les classes utilitaires, customisation et adaptations spécifiques au projet pour manipuler des concepts techniques particuliers (listener Kafka, intercepteur Spring, Sécurité, etc…​).

Quelques contre-exemples:

  • ExtensionFichierUtils : la notion d’extention de fichier est purement technique, cette classe devrait plutôt s’appeler FileExtensionUtils

  • checkConcurrenceAcces() (en franglais), n’est que purement technique et aurait donc du s’appeler checkAccessConcurrency().

La difficulté des briques technico-fonctionnelles

Comme on l’a vu précédemment : Les nommages au sein d’un fichier devraient être cohérents: soit tout en anglais (car purement technique), soit toutes en Français (car issu du Langage Commun).

L’utilisation de Franglais va indéniablement pointer le bout de son nez, notamment lors des liens techniques avec le langage ou les frameworks et librairies, que ce soit Hibernate, les conventions JavaBeans, Spring Data, etc.
Il faut en réduire l’usage aux seules nécessités techniques. Evidemment ici, tout dépend du langage et des frameworks utilisés…​

On retrouve quelques cas faciles :

  • Les getters/setters : getAccuseReception(), setUtilisateur()

  • Les suffixes des couches : FicheClientRepository, CarteAchatService, UtilisateurController

  • Les méthodes de Repository/DAO (dépendamment de la techno utilisée évidemment, mais Spring Data impose un nommage particulier) : findAllByNomAndAgeAfter()

Quelques exemples de Franglais qui peuvent être évités :

  • assertActiviteObligatoireValide est un contrôle métier peut donc être nommé intégralement en français controlerValiditeActiviteObligatoire.

  • UtilisateurService.findFicheById() (couche Service) aurait dû s’appeler rechercherFicheParId(). La méthode est bien nommée UtilisateurRepository.findFicheById() (couche Repository) à cause des conventions Spring Data JPA.

Mais tous ces cas de figure ne sont pas aussi simple : Des cas plus complexes se recontrent pour la gestion de Cache (des objets metiers sont en cache, mais la brique de gestion de cache est purement technique), le mapping (au sens large JSON, ORM, bean-bean, etc), la gestion de la sécurité (droits/habilitation), l’intégration de flux, le rejeu, le messaging, etc..

Il n’y a malheureusement pas de formule magique ici et pour ces cas, le Franglais semble inévitable…​

Garder à l’esprit une règle : L’important est de rester cohérent pour faciliter la lisibilité du code.
Ca veut dire cohérent :

  • avec le code existant : vérifier ce qui a déjà été fait et se calquer sur l’existant.

  • avec soi-même : vérifier que les nommages soient bien cohérents dans les différentes portions du code qui viennent d’être écrite ?

Quelques exemples de Franglais inévitables :

  • reindexAllEmploye() : la brique de recherche full-text est une brique purement technique (en anglais donc), mais l’entité indexée est nommée en français partout ailleurs dans le reste de l’application. Ici le franglais semble inevitable…​

  • JwtClaims buildClaims(Utilisateur utilisateur) : la brique de sécurité en place de forger un token JWT (en anglais donc) s’appuie sur une Entité Utilisateur en français…​

Conclusion

En quelques points :

  • Imposer absolument l’anglais n’a pas forcément toujours du sens : il faut savoir s’adapter au contexte de l’entreprise (ou du projet) et s’adapter au niveau linguistique de l’équipe présente et future (pensez à la maintenance future de l’application!).

  • Développer une application en Français, c’est s’exposer obligatoirement à du code en Franglais. Quoi qu’on fasse on ne pourra pas y échapper. Il faut l’accepter.

  • Il faut s’autoriser de la souplesse et ne pas vouloir tout traduire. Il faut avoir conscience des frontières :

    • Les termes techniques doivent rester en Anglais conformément aux conventions attendues par les langages/librairies/frameworks.

    • Les termes Métier doivent rester en Français pour assurer une cohérence lors des échanges avec le PO, BA et utilisateurs.

  • Une traduction (dans un sens ou dans l’autre) risque de réduire la compréhension par l’ensemble des membres du projet.

  • Une des clés de la maintenabilité est d’être cohérent sur l’application: Imposez-vous des règles pour les différentes typologies de fichiers et partagez-les entre développeurs.