Ouvrir un projet numérique

Pourquoi ouvrir son projet

Ouvrir le code d’un service public, c’est bien plus qu’un geste technique. C’est reconnaître que le logiciel est aussi un bien commun, produit par et pour la collectivité.

Les idées reçues

Ouvrir son code suscite encore des interrogations légitimes, souvent fondées sur des idées reçues qu’il est utile de clarifier. Quand on parle d’ouvrir le code d’un service public, les mêmes réactions reviennent souvent. Des inquiétudes très concrètes, compréhensibles, mais qui méritent d’être éclairées.

« Et si une entreprise réutilise notre code ?
Ce serait plutôt une bonne nouvelle. Cela veut dire que votre travail est utile, qu’il répond à un besoin réel. Si une entreprise s’en saisit, vous gagnez en impact, en visibilité et, souvent, en retours techniques. À ne pas ouvrir, on ne gagne rien: on empêche simplement d’autres de construire à notre suite.

« Et si quelqu’un faisait un fork du projet ? »
Rien de grave. Un fork ne vous retire rien : votre dépôt reste la référence. La plupart des forks ne vivent pas longtemps, ou finissent par renvoyer des améliorations. L’ouverture permet ce type d’expérimentation, sans vous priver de quoi que ce soit.

« Et si quelqu’un refermait le projet ? »
Impossible sur votre version : ce qui a été ouvert le reste. Changer de licence exige l’accord de tous les détenteurs de droits. Vous gardez la main, le nom, l’historique et la gouvernance du projet.

« Et si on perdait la maîtrise ? »
Ouvrir, ce n’est pas céder. Vous décidez toujours de ce qui entre dans le code, des évolutions et de la feuille de route. Accepter une contribution est un choix, pas une obligation.

« Et si ouvrir posait un risque de sécurité ? »
Le code public n’embarque pas de secrets opérationnels. Son ouverture augmente l’auditabilité, accélère la détection et la correction des vulnérabilités, avec un canal de divulgation responsable pour garder la main.

Argent public = code public

Ouvrir le code n’est pas seulement une bonne pratique : c’est une obligation légale.

Les codes sources produits ou reçus dans le cadre d’une mission de service public sont considérés comme des documents administratifs, au même titre que tout autre contenu, selon la (Ouvre une nouvelle fenêtre) CADA, avis n°20144578 du 8 janvier 2015.

Ils doivent être publiés lorsque leur diffusion présente un intérêt économique, social, sanitaire ou environnemental, conformément à l’esprit de l’open data et aux articles (Ouvre une nouvelle fenêtre) L323-2 et (Ouvre une nouvelle fenêtre) D323-2-1 du Code des relations entre le public et les administrations.

Dans chaque ministère, les AMDAC (administrateurs ministériels des données, des algorithmes et des codes sources) coordonnent cette politique et accompagnent les équipes dans leurs démarches d’ouverture.

→ Pour en savoir plus consultez la ressource Guide juridique du logiciel libre dans l’administration

Un levier pour l’action publique

Ouvrir son code, c’est transformer une contrainte réglementaire en levier de transformation. L’ouverture permet de :

Améliorer la qualité du logiciel grâce aux relectures et retours extérieurs ;
Renforcer la sécurité par la transparence et la relecture par les pairs ;
Faciliter la mutualisation entre administrations, en évitant de redévelopper ce qui existe déjà ;
Favoriser la souveraineté numérique et l’indépendance vis-à-vis des fournisseurs privés ;
Valoriser l’investissement public en faisant de chaque code une ressource réutilisable par d’autres services ou territoires.

Définir sa stratégie d’ouverture

Ouvrir, c’est d’abord penser le projet dans son ensemble. Le code en fait partie, mais l’enjeu est plus large : ce que l’on partage, avec qui, et comment cela vit dans le temps. Avant d’ouvrir, prenez le temps de définir à quoi sert votre projet, pour qui vous l’ouvrez et jusqu’où vous souhaitez aller.

1. Clarifier la finalité du projet

Un projet ouvert fonctionne s’il répond à un besoin réel pour votre organisation, mais aussi pour la communauté qui pourrait s’y intéresser.

Demandez-vous :

Quel problème concret ce projet résout-il ?
Quelle valeur crée-t-il pour d’autres (administrations, usagers, partenaires) ?
En quoi l’ouverture du code ou de la démarche améliore-t-elle le résultat : transparence, mutualisation, innovation, diffusion d’un standard, souveraineté numérique ?

2. Identifier les publics concernés

Un projet ouvert s’adresse à plusieurs cercles :

Les utilisateurs finaux (qui utilisent ou bénéficient du projet, sans nécessairement contribuer).
Les contributeurs potentiels (pairs, développeurs, agents publics, chercheurs, collectivités, etc.) capables d’améliorer ou de maintenir le projet.

Posez-vous ces questions :

Qui sont vos utilisateurs ? Où se trouvent-ils ? Qu’attendent-ils ?
Qui sont vos contributeurs naturels ? Ont-ils les compétences, la motivation ou l’intérêt pour participer ?

Plus votre public cible est clair, plus il sera simple de bâtir une communauté solide.
Évaluez aussi votre capacité à entretenir la relation dans le temps : animer, répondre, documenter. L’ouverture suppose un engagement durable, pas seulement un geste initial de publication.

3. Définir le périmètre et le modèle d’ouverture

Tous les projets n’ont pas vocation à être ouverts au même degré. Déterminez :

Le périmètre : projet complet ou éléments ciblés (code, documentation, modules, scripts, configurations…).
Le modèle d’ouverture :
- Dépôt public consultable,
- Logiciel libre pleinement documenté et maintenu,
- Commun numérique avec gouvernance et contribution ouvertes.

Choisissez le modèle qui correspond à vos moyens, vos objectifs et votre maturité.

4. Poser le cadre juridique et organisationnel

L’ouverture implique des choix clairs sur les droits et la gouvernance. Vérifiez :

La licence la plus adaptée (voir le (Ouvre une nouvelle fenêtre) guide juridique interactif et le Guide juridique du logiciel libre dans l’administration)
La compatibilité des dépendances logicielles,
Les rôles et règles de décision (qui maintient, qui valide, qui publie ?),
La place donnée aux contributions extérieures : comment elles sont proposées, examinées et intégrées, et dans quels cas elles peuvent orienter les évolutions du projet.

5. Décision attendue

À l’issue de ce cadrage, formalisez :

Ce que vous ouvrez,
Pourquoi vous l’ouvrez,
Sous quel cadre (licence, gouvernance, niveau d’ouverture),
Et à quel rythme (publication initiale, ouverture progressive, expérimentation contributive…).

Ouvrir le code

Ouvrir le code, c’est aller au-delà de la simple mise en ligne d’un dépôt. Cela consiste à choisir une licence claire, soigner la documentation et assurer la conformité juridique et technique du projet. L’objectif est de rendre le code lisible, réutilisable et partageable par d’autres, dans des conditions sûres et transparentes.

Définir le bon niveau d’ouverture

Cette étape consiste à traduire votre stratégie d’ouverture en décisions concrètes : définir le niveau d’ouverture du code selon vos objectifs et vos moyens, puis choisir la licence la plus adaptée pour encadrer la réutilisation et la contribution.

Pour savoir si le code source d’un logiciel développé ou utilisé par votre organisme public est communicable, vous pouvez utiliser le (Ouvre une nouvelle fenêtre) guide juridique interactif proposé par la DINUM.

Tous les logiciels produits par des acteurs publics n’ont pas vocation à être ouverts au même degré. Pour évaluer le bon niveau d’ouverture, appuyez-vous sur quatre critères simples :

Modularité – le logiciel peut être réutilisé comme un module par d’autres projets.
Généricité – il répond à un besoin partagé au-delà de votre organisme.
Reprise – il a vocation à être maintenu ou développé par d’autres.
Profil des utilisateurs – les usagers ont les compétences ou l’intérêt pour contribuer.

Les quatre niveaux d’ouverture

🟦 Niveau A – Contributif
Le code est publié et les contributions extérieures sont activement recherchées, écoutées et intégrées.
→ Recommandé pour les logiciels répondant à au moins deux critères.
🟩 Niveau B – Ouvert
Le code est publié et les contributions extérieures sont acceptées, mais non recherchées activement.
→ Recommandé pour les logiciels répondant à au moins un critère.
🟧 Niveau C – Publié
Le code est rendu public, sans ouverture à la contribution.
→ Pertinent pour les logiciels spécifiques ou peu réutilisables (par ex. un outil interne métier).
🟥 Niveau D – Non communicable
Le code n’est pas publiable, selon le cadre juridique défini par la loi pour une République numérique.
→ Réservé aux cas où le logiciel ne répond à aucun critère d’ouverture et contient des éléments non communicables.

Ces critères ne sont pas des règles strictes, mais des repères pour situer votre projet. Ils permettent de :
- Prioriser les projets à ouvrir en premier.
- Concentrer les efforts sur ceux à fort potentiel contributif.
- Clarifier la posture de l’administration quand il s’agit d’une simple mise à disposition.

Communiquer le niveau d’ouverture

Dans le fichier README.md de votre dépôt, indiquer clairement le degré d’ouverture de votre projet.

Choisir sa licence

Une licence logicielle définit les droits et obligations entre les auteurs d’un logiciel et ses réutilisateurs.

Les licences libres permettent d’utiliser, copier, modifier et redistribuer le code, tout en encadrant les conditions de réutilisation.

Deux grandes familles existent :

Les licences permissives, qui offrent une large liberté de réutilisation, y compris commerciale.
Exemples : (Ouvre une nouvelle fenêtre) MIT, (Ouvre une nouvelle fenêtre) Apache 2.0, BSD, CeCILL-B, Licence Ouverte 2.0.
Les licences à réciprocité (copyleft), qui imposent de conserver la même licence lors de la redistribution, pour garantir que les améliorations restent accessibles à tous.
Exemples : (Ouvre une nouvelle fenêtre) GPL, AGPL, MPL, EUPL.

La doctrine de la DINUM recommande de privilégier les licences permissives, afin de faciliter la réutilisation des codes produits par les administrations.

Cependant, lorsqu’une réutilisation commerciale sans retour de contribution fait courir un risque pour l’intérêt général, une licence à réciprocité peut être plus adaptée.

Pour éviter la prolifération des licences, (Ouvre une nouvelle fenêtre) une liste officielle des licences utilisables par les administrations est fixée par décret (article D.323-2-1 du Code des relations entre le public et les administrations).

Pour en savoir plus :

Publier son code

Publier son code permet d’être utile à d’autres et de bénéficier de leurs retours. Il est donc essentiel de le faire proprement, avec un code clair et documenté, pour en faciliter la réutilisation, la contribution et renforcer la crédibilité du projet.

Choisir la bonne vitrine

Publier, c’est d’abord choisir un hébergement adapté et durable. Par défaut, les dépôts doivent être publiés sous l’organisation de votre administration, sauf si le projet porte une marque propre ou un commun inter-administrations. Selon vos besoins (visibilité, intégration continue, authentification), vous pouvez utiliser une forge ministérielle ou une plateforme largement reconnue (GitHub, GitLab, etc.).

Si vous créez une nouvelle organisation, pensez à nous en informer pour nous puissions la référencer et faciliter la mise en relation avec d’autres administrations menant des travaux similaires.

Informez-nous

Nommer clairement

Un bon nom oriente sans explication. Il doit permettre de comprendre qui porte le projet et à quoi il sert, tout en restant clair et mémorisable.

Organisation

Utilisez le nom de l’administration ou de la structure qui porte le projet comme organisation principale. Évitez les acronymes instables ou liés à une direction interne, préférez des noms explicites et pérennes. Exemple durable : github.com/etalab/ plutôt que github.com/DISIC/.

Si vous créez une organisation dédiée, notamment pour une marque de projet, indiquez-le à la DINUM pour qu’elle puisse la référencer et la rendre visible auprès d’autres administrations. Cela évite de dupliquer des initiatives similaires.

Dépôt

Choisissez un nom de dépôt qui décrit la finalité du projet, plutôt qu’un identifiant technique. Préférez collectivites-cartographie à proj-ccx-v2. Un bon nom facilite la découverte, la réutilisation et la reconnaissance du projet dans le temps.

Vérifier la disponibilité

Avant de publier, vérifiez que le nom n’est pas déjà utilisé :

Cherchez sur les plateformes de code (GitHub, GitLab, etc.) pour éviter la confusion.
Vérifiez les domaines ou comptes associés (site web, réseaux sociaux).
Consultez, si besoin, la (Ouvre une nouvelle fenêtre) base mondiale des marques de l’OMPI pour écarter tout risque de conflit.

Clarté avant tout

Privilégiez la simplicité à l’originalité. Un nom clair se comprend, se traduit et se retrouve facilement. Exemples :

(Ouvre une nouvelle fenêtre) Panoramax, une alternative ouverte à Street View.
(Ouvre une nouvelle fenêtre) Base Adresse Nationale, qui explicite sa fonction.

→ Pour aller plus loin : (Ouvre une nouvelle fenêtre) opensource.guide/legal/

Préparer la publication

Avant de rendre le code public, vérifiez qu’il est propre, complet et compréhensible :

Supprimez toute information sensible (mots de passe, adresses internes, données confidentielles).
Intégrez les mentions de copyright nécessaires.
Vérifiez que la plateforme d’hébergement est bien configurée (droits d’accès, webhooks, CI/CD).

Ajoutez ensuite les fichiers essentiels à toute publication :

README

C’est la première porte d’entrée de votre projet. Un bon README explique à quoi sert le projet, pourquoi il est utile, comment démarrer et où trouver de l’aide. Il aide aussi à comprendre la maturité du projet et le type de contributions possibles.

Vous pouvez y préciser, selon votre situation :

comment installer ou tester le projet,
les objectifs, licences ou modes de contribution,
ou au contraire, indiquer que le projet n’est pas encore ouvert aux contributions.

Un README clair et accueillant facilite la réutilisation et encourage les premiers retours. Inspirez-vous des guides :

(Ouvre une nouvelle fenêtre) makeareadme.com ou de ce (Ouvre une nouvelle fenêtre) modèle de README.

Autres fichiers clés

Un CHANGELOG pour suivre les évolutions ( (Ouvre une nouvelle fenêtre) keepachangelog.com)
Des commits lisibles et structurés ( (Ouvre une nouvelle fenêtre) conventionalcommits.org)
Des tags de version conformes au (Ouvre une nouvelle fenêtre) versionnement sémantique
Facultativement, des outils pour améliorer la lisibilité et valoriser les contributeurs : (Ouvre une nouvelle fenêtre) gitmoji et (Ouvre une nouvelle fenêtre) allcontributors.org

Donner de la visibilité

Une fois le code publié, faites savoir qu’il existe et qu’il vit :

Publiez des releases taguées et ajoutez des mots-clés pour le référencement.
Liez le dépôt à la documentation et à ses pages associées (site, API, guide d’usage).
Mentionnez le dépôt dans les présentations, appels à commun ou bilans de projet.

Publier proprement, c’est permettre à d’autres de s’appuyer sur votre travail plutôt que de le dupliquer. C’est aussi la première marche vers une culture de mutualisation et de collaboration durable.

Langue du code et de la documentation

Le code source s’écrit dans un langage de programmation (par exemple JavaScript), mais aussi dans une langue naturelle. Les commentaires font partie du code et doivent être rédigés en anglais, afin de faciliter la lecture et la contribution par d’autres développeurs.

Si le projet s’appuie sur un référentiel métier en français, les noms de variables et de fonctions doivent rester en français pour conserver la cohérence du domaine.

Pour la documentation :

le manuel technique (installation, intégration, déploiement) doit être rédigé en français,
le manuel utilisateur final doit également être disponible en français.

Ouvrir à la communauté

Ouvrir à la communauté, c’est faire du projet un espace de collaboration.
Cela passe par la mise en place de règles de contribution, une gouvernance ouverte et une animation régulière pour encourager la participation.
L’objectif est de construire une dynamique collective où chacun peut apporter, apprendre et faire évoluer le projet ensemble.

Ouvrir à la contribution

Rendre son dépôt public est une première étape ; l’ouvrir à la contribution en est une autre.

Pour que d’autres puissent participer, il faut leur montrer comment faire et dans quel cadre. C’est le rôle du fichier CONTRIBUTING.md, placé à la racine du dépôt. Ce document explique comment contribuer, selon la nature du projet :

signaler un bug ou proposer une amélioration,
suggérer une nouvelle fonctionnalité,
traduire la documentation, enrichir des données, ou même organiser un événement.

Le ton compte autant que le fond. Un message d’accueil clair et bienveillant, à l’image de (Ouvre une nouvelle fenêtre) celui d’Active Admin (“Merci d’envisager de contribuer...”), aide les nouveaux venus à se sentir légitimes.

Il peut aussi préciser les types de contributions attendues, la feuille de route du projet et les bons canaux de contact.

Pour les débutants, identifiez quelques premières contributions simples (petites corrections, relectures, documentation) et étiquetez-les dans vos issues. Cela facilite les premiers pas et augmente les chances de participation utile.

Si le projet implique des contraintes de qualité, de sécurité ou de conformité réglementaire, vous pouvez ajouter des règles spécifiques ou un processus de validation clair.

Certains projets choisissent aussi d’encadrer les apports par un Developer’s Certificate of Origin (DCO) ou un Contributor License Agreement (CLA), selon le niveau de formalisation souhaité.

Enfin, pensez à relier votre guide de contribution depuis le README : c’est souvent la première page que les visiteurs consultent.

Pour aller plus loin :

Lancer et animer la communauté

Le lancement d’un commun ou d’un projet libre ne repose pas sur un grand événement, mais sur la construction progressive d’un petit noyau actif.

Les grands lancements peuvent attirer beaucoup de monde, mais si ces nouveaux venus arrivent dans un endroit inactifs, ils seront vite découragées et ce sera impossible de relancer l'activité derrière . À l’inverse, démarrer modestement avec un petit noyau actif permet d’expérimenter, de consolider les rôles et de créer les bonnes dynamiques de collaboration.

Commencez petit, mais commencez clair. Identifiez un premier cercle de personnes motivées, échangez régulièrement avec elles et documentez chaque étape.
Publiez la feuille de route, les choix techniques et les discussions importantes dans des issues ou pull requests. Cela permet à d’autres de comprendre, de suivre et de rejoindre le projet sans devoir tout redemander.
L’équipe GitLab en a fait un principe : leur (Ouvre une nouvelle fenêtre) manuel communautaire documente tout, du fonctionnement des réunions à la stratégie de contribution.

La réactivité joue aussi un rôle clé. Répondre vite, même brièvement, montre que les contributions comptent.
(Ouvre une nouvelle fenêtre) Une étude de Mozilla a montré que les contributeurs recevant une revue de code sous 48 heures revenaient bien plus souvent contribuer à nouveau.
Remercier, expliquer, et valoriser les apports, même modestes, nourrit la confiance et l’envie de participer.
Donnez aussi un espace public de discussion à votre communauté : un forum, un salon de discussion, ou des issues ouvertes. Cela permet à chacun de poser des questions, de lire les échanges passés et de monter en compétence.

Évitez les messages privés récurrents qui dispersent l’énergie et privilégiez des canaux collectifs — tout en prévoyant un mode de contact confidentiel pour les questions de sécurité ou de modération (à l’image d’ (Ouvre une nouvelle fenêtre) Arduino).
Vous pouvez compléter par des temps d’échanges réguliers en visioconférence pour accueillir les nouveaux ou valider des propositions.

→ Pour aller plus loin consultez le (Ouvre une nouvelle fenêtre) Guide de création de communauté d'un commun IGN

Définir des règles de conduite

À mesure qu’un projet gagne en visibilité, il attire des profils variés et multiplie les points de vue. Pour préserver un climat sain, il est essentiel d’établir un cadre clair et bienveillant.

Le code de conduite fixe les règles de comportement, les attentes et les procédures en cas de problème. Il protège autant les participants que les mainteneurs.

Placez-le à la racine du dépôt et reliez-le depuis le README. Le (Ouvre une nouvelle fenêtre) Contributor Covenant constitue une excellente base, déjà utilisée par des projets majeurs comme Kubernetes ou Rails.

Un cadre, toutefois, ne suffit pas sans une culture d’échange respectueuse.

Les projets ouverts les plus durables sont ceux où les responsables montrent l’exemple : écoute, patience, reconnaissance des apports.

Gardez en tête que derrière chaque contribution se trouve une personne avec son expérience, son temps limité et ses contraintes. Un retour constructif vaut mieux qu’une critique sèche.

Quand des désaccords émergent, adoptez la posture d’un facilitateur : recadrez les échanges si besoin, apaisez les tensions et gardez trace des décisions prises.

Montrer du leadership dans ces moments-là, c’est assurer la continuité du projet et la cohésion du groupe.

Pour aller plus loin :

(Ouvre une nouvelle fenêtre) Empathy in Open Source, par Sindre Sorhus
(Ouvre une nouvelle fenêtre) Building Community, guide complet sur la construction de communautés ouvertes
(Ouvre une nouvelle fenêtre) https://opensource.guide/code-of-conduct

Vérifier avant d’ouvrir

Avant de cliquer sur “Publier”, assurez-vous que :

☐ Le code est propre : aucune donnée sensible (mots de passe, adresses internes, logs, etc.) ne reste dans le dépôt.

☐ Les mentions de copyright et la licence sont bien intégrées pour encadrer les droits d’usage et de contribution.

☐ Le README présente clairement le projet : son objectif, comment l’utiliser, comment démarrer et où trouver de l’aide.

☐ Le guide de contribution ( (Ouvre une nouvelle fenêtre) CONTRIBUTING.md) explique comment participer, signaler un bug ou proposer une amélioration.

☐ Le code de conduite définit les règles de comportement attendues pour garantir un climat de collaboration respectueux.

☐ La documentation permet une prise en main rapide du projet et facilite les premiers pas des nouveaux venus.

☐ La plateforme d’hébergement (GitHub, GitLab, forge ministérielle, etc.) est correctement configurée : droits d’accès, intégration continue, webhooks…

Ressources

Ressources par la DINUM

Guide juridique interactif sur la publication des codes …

Publié le mardi 11 novembre 2025

Guide juridique du logiciel libre dans l’administration