Coder en français ou en anglais ? Noms, accents et commentaires en Python

Style et lisibilité · Par la rédaction de Four Spaces · Publié le 2026-11-10

Gros plan sur une page de manuscrit médiéval écrite à l'encre brune, avec des notes serrées dans la marge de la page d'en face — Une page d'un manuscrit composite médiéval, bibliothèque de l'université de Bâle, A VII 42. Domaine public.

C'est une question que se pose tôt ou tard tout développeur francophone : faut-il écrire calculer_moyenne() ou compute_average(), et les commentaires en français ou en anglais ? Python laisse le choix, les guides de style donnent des repères, et l'administration française a même fixé sa propre règle. Voici ce que disent les textes, et comment trancher pour votre projet.

Ce que Python autorise : les accents sont permis

Jusqu'à Python 2, un identifiant ne pouvait contenir que des lettres ASCII, des chiffres et le tiret bas. Python 3 a levé cette limite en adoptant PEP 3131, « Supporting Non-ASCII Identifiers ». Sa justification parle directement aux francophones : beaucoup de programmeurs préfèrent nommer leurs classes et leurs fonctions dans leur langue plutôt que d'inventer une traduction anglaise, souvent approximative, du concept qu'ils veulent désigner.

Ce code est donc parfaitement valide :

def moyenne_élèves(notes):
    """Renvoie la moyenne des notes."""
    total_général = sum(notes)
    return total_général / len(notes)

PEP 3131 précise un détail qui a son importance en français : les identifiants sont convertis dans la forme normale Unicode NFKC lors de l'analyse du code. Un é peut s'écrire en un seul caractère ou en deux (un e suivi d'un accent combinant) selon l'éditeur ou le clavier ; pour Python, les deux graphies désignent le même nom. Nous l'avons vérifié avec Python 3.13 : une variable café écrite une fois avec le caractère précomposé, puis réaffectée avec la forme décomposée, ne crée pas deux variables. La normalisation va plus loin : la ligature typographique ﬁ est lue comme les deux lettres fi, si bien que ﬁchier et fichier sont un seul et même nom.

Ce que recommande PEP 8 : l'anglais pour ce qui circule

Le guide de style officiel, PEP 8, ne reprend pas cette liberté pour la bibliothèque standard. Sa section sur l'encodage des fichiers source pose que tous les identifiants de la bibliothèque standard doivent être en ASCII et devraient utiliser des mots anglais chaque fois que c'est possible, en admettant que beaucoup d'abréviations et de termes techniques ne sont pas de l'anglais. Elle ajoute une phrase que l'on oublie souvent : les projets open source destinés à un public mondial sont encouragés à adopter une politique semblable.

Pour les commentaires, PEP 8 est encore plus direct. Il s'adresse nommément aux « Python coders from non-English speaking countries » : écrivez vos commentaires en anglais, à moins d'être sûr « à 120 % » que le code ne sera jamais lu par des personnes qui ne parlent pas votre langue. Le reste du chapitre sur les commentaires vaut dans toutes les langues : des phrases complètes, une majuscule au début, des commentaires tenus à jour quand le code change. Notre guide des commentaires utiles (en anglais) détaille ces règles.

Il faut bien lire la portée de ces phrases. PEP 8 n'interdit pas le français dans un script d'analyse interne, un exercice de lycée ou une application métier : il fixe la règle de la bibliothèque standard et donne un conseil au reste du monde. Le guide rappelle d'ailleurs, dès son introduction, que la cohérence au sein d'un projet compte plus que la conformité au guide lui-même.

La règle de l'administration française

Les organismes publics français ont une réponse plus détaillée. La documentation de code.gouv.fr, publiée par la mission logiciels libres de la Direction interministérielle du numérique (DINUM), consacre une question à « Quelles langues utiliser pour mon code source et ma documentation ? ». Sa réponse distingue quatre cas :

les commentaires sont considérés comme faisant partie du code et doivent être écrits en anglais ;
si le code est développé en lien avec un référentiel, les noms de variables et de fonctions reprennent ce référentiel : un référentiel en français donne des noms en français ;
le manuel du développeur ou de la personne qui réutilise le projet (pour l'intégrer, le déployer…) doit être écrit en français ;
le manuel de l'utilisateur final doit être écrit en français.

La même documentation recommande de décrire les modalités de contribution en anglais, dans un fichier CONTRIBUTING.md à la racine du dépôt. Cette doctrine résout élégamment le dilemme des noms métier. Un logiciel qui calcule des prestations sociales manipule un « quotient familial », un « revenu fiscal de référence » ou une « allocation de rentrée scolaire » : les traduire en anglais produirait des noms que ni les juristes ni les agents ne reconnaîtraient, et qu'aucun dictionnaire ne rendrait de façon univoque. Garder quotient_familial rend le code vérifiable par rapport au texte réglementaire, tandis que la plomberie technique (lecture de fichiers, appels réseau, journalisation) reste en anglais comme dans le reste de l'écosystème Python.

Accents dans les noms : permis, mais rarement une bonne idée

Même quand on nomme en français, la plupart des équipes écrivent eleve plutôt que élève. Ce n'est pas une règle de Python, mais plusieurs raisons pratiques y poussent :

La saisie. Un collègue sur un clavier QWERTY, ou un outil qui génère du code, aura du mal à taper total_général à l'identique.
Les mélanges. Un projet où cohabitent eleve et élève devient vite source d'erreurs NameError, car ce sont deux noms différents pour Python.
Les outils. Ruff, avec sa règle PLC2401 (reprise de pylint), signale tout nom de variable ou de fonction contenant un caractère non ASCII. Avec ruff 0.16, notre exemple moyenne_élèves déclenche deux avertissements PLC2401, un pour la fonction et un pour total_général ; flake8 7.4 (pycodestyle 2.15), lui, ne dit rien.

Les accents restent bienvenus là où ils servent le lecteur : dans les chaînes de caractères affichées à l'utilisateur, dans les docstrings et les commentaires d'un projet francophone, dans les données. PEP 8 demande seulement, pour la bibliothèque standard, d'utiliser les caractères non ASCII avec parcimonie, de préférence pour des noms de lieux ou de personnes.

Le piège de la typographie française

Les francophones rencontrent un problème que les anglophones ignorent : la typographie. Un éditeur de texte ou un traitement de texte remplace volontiers l'apostrophe droite par l'apostrophe typographique (’, U+2019) et insère une espace insécable avant les deux-points, les points d'exclamation ou d'interrogation. Copié dans du code, ce texte passe inaperçu à l'œil mais pas aux outils. Avec ruff 0.16, ce fichier de deux lignes :

# Calcule l’âge de l’élève : version 2
MESSAGE = "Attention !"

déclenche, si l'on active les règles correspondantes, quatre avertissements : RUF003 pour chacune des deux apostrophes typographiques et pour l'espace insécable du commentaire, RUF001 pour l'espace fine insécable de la chaîne. Ces règles visent les caractères qui ressemblent à de l'ASCII sans en être, parce qu'ils peuvent masquer des erreurs ou du code malveillant. Elles ne font pas partie de la sélection par défaut de ruff, qui se limite à une partie des règles pycodestyle et pyflakes.

Si votre projet écrit volontiers ses messages et ses commentaires dans une typographie française soignée, le réglage allowed-confusables permet d'autoriser explicitement ces caractères :

[tool.ruff.lint]
allowed-confusables = ["’", " ", " "]

Avec cette configuration dans pyproject.toml, le même fichier passe sans avertissement. L'inverse est tout aussi défendable : imposer l'apostrophe droite partout dans le code, et réserver la typographie fine aux fichiers de traduction ou aux gabarits.

Comment trancher pour votre projet

Situation	Noms	Commentaires	Documentation
Bibliothèque open source à audience mondiale	anglais, ASCII	anglais	anglais (français en complément)
Logiciel d'un organisme public (code.gouv.fr)	langue du référentiel métier	anglais	français
Application métier d'une entreprise française	français pour le métier, anglais pour la technique	au choix de l'équipe, mais une seule langue	langue des lecteurs
Exercice, cours, projet de lycée	français sans accents, conventions PEP 8	français	français

Quelle que soit la case, la règle d'or est la même que pour le reste du style : écrire la décision dans le README ou le guide de contribution, et la faire vérifier par un outil plutôt que par la mémoire des relecteurs. Pour un usage scolaire, notre article sur le code lisible en NSI montre comment combiner noms français, docstrings et tests ; pour un organisme public, voyez ce qu'implique la publication d'un code source.

Sources

PEP 8, « Style Guide for Python Code », sections « Source File Encoding » et « Comments ».
PEP 3131, « Supporting Non-ASCII Identifiers » (normalisation NFKC, politique de la bibliothèque standard).
code.gouv.fr, documentation de la mission logiciels libres (DINUM), question « Quelles langues utiliser pour mon code source et ma documentation ? ».
Documentation de ruff, règles PLC2401 (non-ascii-name), RUF001 à RUF003 et réglage lint.allowed-confusables. Exemples exécutés avec Python 3.13, ruff 0.16 et flake8 7.4.