Publier du code Python dans un organisme public : obligations, licences et bonnes pratiques

Code public et données · Par la rédaction de Four Spaces · Publié le 2026-11-10

Des rangées d'étudiants lisant à de longues tables dans la salle de lecture de la Bibliothèque du Congrès vers 1900, avec des colonnes de marbre derrière eux — Étudiants dans la salle de lecture de la Bibliothèque du Congrès, photographiés par Frances Benjamin Johnston. Bibliothèque du Congrès, domaine public.

Dans une administration, une collectivité ou un établissement public, le script Python écrit pour automatiser un traitement n'est pas tout à fait un fichier comme un autre : en droit français, un code source est un document administratif. Cela ne veut pas dire qu'il faut tout publier du jour au lendemain, mais cela change la manière d'écrire, de documenter et de licencier le code. Voici les repères, tirés des textes et de la doctrine de l'État.

Un code source est un document administratif

Le point de départ est une phrase du CRPA, article L300-2, dans sa rédaction issue de la loi n° 2016-1321 du 7 octobre 2016 pour une République numérique. Elle énumère ce qui constitue notamment des documents administratifs : « les dossiers, rapports, études, comptes rendus, procès-verbaux », puis « correspondances, avis, prévisions, codes sources et décisions ». Avant même la loi, la Commission d'accès aux documents administratifs (CADA) l'avait admis dans un avis du 8 janvier 2015 (n° 20144578), que cite la documentation officielle.

Conséquence directe : un code source produit ou reçu par un organisme public dans le cadre de sa mission peut être demandé par n'importe qui, comme un rapport ou une décision. La documentation de code.gouv.fr, tenue par la mission logiciels libres de la DINUM, précise les conditions :

l'obligation de communicabilité porte sur les collectivités de plus de 3 500 habitants et les organismes publics de plus de 50 agents ;
l'organisme doit détenir la propriété intellectuelle du code ;
le code doit être « achevé » : dès qu'une version est mise en œuvre dans l'administration, elle l'est, même si elle porte un numéro inférieur à 1.0 ;
la communication ne doit pas porter atteinte au secret commercial et industriel, à la sûreté de l'État, à la sécurité publique ou des personnes, à la sécurité des systèmes d'information des administrations, ni à la recherche des infractions.

Pour une équipe Python, la conséquence pratique est simple : écrivez dès le départ comme si le dépôt devait un jour être ouvert. Un mot de passe en dur, un jeton d'API dans un fichier de configuration ou un commentaire désobligeant deviennent un problème le jour où le code est demandé. La documentation de code.gouv.fr consacre d'ailleurs une question à la détection et à l'effacement des secrets dans l'historique Git.

Choisir une licence dans la liste officielle

Publier ne suffit pas : sans licence, personne n'a le droit de réutiliser le code. Pour éviter la prolifération des licences, la loi pour une République numérique a prévu une liste fixée par décret, codifiée à l'article D323-2-1 du CRPA. Le portail data.gouv.fr présente cette liste en deux familles pour les logiciels :

Famille	Licences de la liste
Permissives	Apache-2.0, BSD-2-Clause, BSD-3-Clause, CeCILL-B, MIT
Avec obligation de réciprocité (copyleft)	CeCILL-2.1, CeCILL-C, GPL-3.0-or-later, LGPL-3.0-or-later, AGPL-3.0-or-later, MPL-2.0, EPL-2.0, EUPL-1.2

Toutes sont valables en droit français, rappelle code.gouv.fr, même si elles ne sont pas toutes rédigées en français ; ceux qui tiennent à un texte français peuvent retenir l'EUPL 1.2 ou l'une des licences CeCILL. Deux détails piègent souvent les projets Python : la GPL version 2 seule n'est pas dans la liste, et les licences listées sont les versions « ou ultérieures » de la GPL, de la LGPL et de l'AGPL. Si votre projet dépend de bibliothèques sous GPL, la compatibilité entre licences doit être vérifiée avant de choisir une licence permissive. Le fichier de licence se place à la racine du dépôt ou dans un répertoire LICENSES.

Notre analyse de l'inventaire des dépôts publics montre que ce point reste fragile : dans l'inventaire de septembre 2025, plus d'un dépôt Python sur quatre recensé sur GitHub ne déclarait aucune licence détectable.

Les fichiers que la doctrine recommande

La documentation de code.gouv.fr ne fixe pas de règles de style de code, et le dit : les bonnes pratiques générales de développement sortent de son périmètre. Elle recommande en revanche un socle de conventions « assez consensuelles » :

un README, qui explique ce que fait le code, comment l'installer et l'utiliser ;
un journal des modifications (ChangeLog) et un versionnement sémantique ;
des messages de commit structurés (conventional commits) ;
un code de conduite ;
un CONTRIBUTING.md à la racine, rédigé en anglais par convention, qui décrit comment contribuer.

Pour un projet Python, on peut traduire ce socle en quelques fichiers concrets : README.md, LICENSE, CHANGELOG.md, CONTRIBUTING.md, et un pyproject.toml qui déclare les dépendances et la configuration des outils de qualité. C'est dans ce dernier fichier que l'on fixe la longueur de ligne et les règles du linter (ruff, flake8) ou du formateur (black, ruff format), pour que tout contributeur obtienne le même résultat. Notre article (en anglais) sur l'adoption d'un guide de style dans un code existant montre comment le faire sans réécrire tout l'historique.

Côté langues, la règle de code.gouv.fr est précise : commentaires en anglais, noms de variables et de fonctions dans la langue du référentiel métier, documentation pour les développeurs et pour les utilisateurs en français. Nous la détaillons dans Coder en français ou en anglais ?

Dire jusqu'où l'on s'engage : les degrés d'ouverture

Publier ne veut pas dire promettre une maintenance. La doctrine propose quatre degrés, que l'on peut annoncer par un badge en tête du README :

A, contributif : le code est publié, les contributions extérieures sont activement recherchées et traitées ;
B, ouvert : les contributions sont traitées mais pas activement recherchées ;
C, publié : le code est publié, les contributions ne sont pas traitées ;
D, non communicable : le code n'est pas communicable au public.

Le niveau A est conseillé pour un logiciel qui remplit au moins deux des quatre critères proposés : être un module utile à d'autres logiciels libres, répondre à un besoin générique, devoir bientôt être maintenu par d'autres, ou avoir des utilisateurs au profil technique. Une bibliothèque Python de traitement de données ouvertes coche souvent les quatre ; un script d'import propre à un service, aucun. Un code que l'on ne maintient plus peut aussi être publié, à condition de l'indiquer clairement dans le README.

Pourquoi le style compte davantage quand le code est public

Un code interne n'a qu'une poignée de lecteurs, qui peuvent poser des questions à son auteur. Un code publié par un organisme public en a potentiellement beaucoup plus : citoyens qui veulent comprendre un calcul, chercheurs, autres administrations qui envisagent de le réutiliser, prestataires chargés de le reprendre. Les conventions de PEP 8 jouent alors leur rôle premier, que le guide rappelle dans son introduction : le code est beaucoup plus souvent lu qu'écrit.

Concrètement, avant d'ouvrir un dépôt Python :

passer un linter et un formateur, et versionner leur configuration ;
donner des docstrings aux fonctions publiques, surtout celles qui implémentent une règle de calcul, avec la référence du texte appliqué ;
retirer les secrets, les chemins propres à un poste et les données personnelles, y compris des tests et de l'historique ;
vérifier que la licence choisie figure dans la liste officielle et qu'elle est compatible avec les dépendances.

Le vérificateur en ligne de Four Spaces permet de contrôler un extrait sans rien envoyer à un serveur, ce qui convient aux codes encore internes ; pour un dépôt entier, mieux vaut un outil en ligne de commande intégré à l'intégration continue.

Sources

Code des relations entre le public et l'administration, article L300-2 (Légifrance).
code.gouv.fr, documentation de la mission logiciels libres (DINUM) : cadre juridique, communicabilité, licences, degrés d'ouverture, bonnes pratiques, langues.
data.gouv.fr, licences de réutilisation (liste prévue à l'article D323-2-1 du CRPA).