Skip to content
Guide pour l'ouverture des logiciels libres des organismes publics
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.gitignore
LO.md
README.org
cadre-juridique.org
hors-scope.org

README.org

Open data logiciels : prioriser les ouvertures et bien communiquer

À qui s’adresse ce guide ?

Ce guide s’adresse aux organismes publics, et plus particulièrement aux personnes chargées de l’ouverture des codes sources logiciels dans ces organismes.

À quoi sert-il ?

Ce guide sert à aider les organismes publics à définir une politique d’ouverture des logiciels libres qu’ils produisent, dans le cadre de la mise en oeuvre de la loi pour une République numérique du 7 octobre 2016.

Il vient en complément de la Politique de contribution aux logiciels libres de l’État, publiée en mai 2018, laquelle est doublement limitée: (1) elle ne s’adresse pas aux collectivités territoriales ; (2) elle acte le principe selon lequel les agents publics peuvent publier du code source et contribuer à des logiciels libres, mais elle n’aide pas les organismes publics à répondre à la question « Quels logiciels ouvrir en priorité ? »

Ce guide a pour vocation de répondre aux questions :

  • Quels logiciels ouvrir en priorité ?
  • Comment bien communiquer autour de la publication d’un logiciel libre ?

Prérequis et compléments

Ce guide suppose que vous avez bien compris ce que ce document n’est pas, que vous avez pris connaissance de la politique de contribution aux logiciels libres de l’État et du cadre juridique dans lequel s’applique la communicabilité des codes sources logiciels produits par des organismes publics.

Quels degrés d’ouverture pour les codes sources ?

Nous proposons de distinguer les quatre degrés d’ouverture suivants :

📘 Niveau A - contributif
Le code source est publié, les contributions extérieures sont activement recherchées et traitées.
📗 Niveau B - ouvert
Le code source est publié, les contributions extérieures sont traitées mais non activement recherchées.
📙 Niveau C - publié
Le code source est publié mais les contributions extérieures ne sont pas traitées.
📕 Niveau D - fermé
Le code source n’est pas publié.

Quels logiciels ouvrir à quel degré ?

Tous les logiciels développés par un organisme public n’ont pas vocation à être ouvert au même degré.

Nous proposons deux critères :

  1. Le logiciel est-il un module utile à d’autres logiciels libres (ou un logiciel « monolithique » sans utilité pour d’autres logiciels libres) ?
  2. Le logiciel répond-il a un besoin générique (ou à un besoin spécifique à l’organisme qui le produit) ?

Le niveau A est recommandé pour les logiciels répondant à ces deux critères ; le niveau B est recommandé pour ceux répondant seulement au critère de généricité ; le niveau C pour ceux ne répondant qu’au critère de modularité.

Pour les logiciels ne répondant à aucun des deux critères, le niveau D est admissible, tant qu’aucun citoyen n’exige la communication du code source en question, selon le cadre juridique définit dans la loi pour République numérique.

Bien sûr, ces critères sont grossiers et relatifs  : la modularité et la généricité ne s’évaluent pas dans l’absolu. Mais ces deux notions aident à prioriser les ouvertures logicielles. Le but est de savoir où mettre de l’énergie pour augmenter les contributions reçues et données.

Exemples de mise en oeuvre

  • Une collectivité territoriale développe un outil de correction grammaticale pour LibreOffice. Ce logiciel est un module d’un logiciel libre existant et il répond à un besoin générique : il est pertinent d’en faire un logiciel libre « contributif » (niveau A).
  • Une administration développe un outil pour organiser la collecte de données sur le web (scraping). C’est un outil web « monolithique_» mais qui répond à un besoin rencontré hors de l’administration : il peut être publié comme logiciel libre « ouvert » (niveau B).
  • Une administration centrale développe un thème pour les sites qu’elle publie à l’aide de Jekyll. Ce thème est un module d’un logiciel libre existant mais il répond à un besoin spécifique de l’organisme public : son code source peut être publié, mais sans recherche active de contributeurs ni maintenance particulière à l’égard des contributions extérieures (niveau C).

Chaque organisme peut tenter de prioriser les logiciels à ouvrir en fonction de ces critères.

Comment encourager les contributions (niveau A) ?

Lorsque vous souhaitez encourager les contributions sur les logiciels libres que vous publiez, quelles bonnes pratiques mettre en oeuvre ? Ci-dessous une liste non-exhaustives d’idées :

  • Ajoutez ces sections dans votre README:
    • Auteur : qui est l’auteur ? Comment le contacter ?
    • Licence : quelle est la licence ? Avec un lien vers votre fichier LICENSE.md dans le dépôt.
    • Contributions : souhaitez-vous des contributions ? Si oui, sur quels aspects de votre projet ? En fonction des profils de contributeurs, par où peuvent-ils commencer ? Éventuellement, vous pouvez préciser ici quelle est la gouvernance du projet (qui décide et comment).
  • Utiliser des mots-clefs pour votre dépôt :
  • Utiliser des mots-clefs pour vos issues :

Vous trouverez d’autres conseils sur www.firsttimersonly.com.

Dans tous les cas : expérimentez et communiquez !

Comment bien communiquer sur un logiciel libre ?

Voici quelques recommandations lorsqu’une administration communique sur la mise à disposition d’un logiciel libre.

Mettre un lien vers le site web du projet

Les projets libres ont souvent une page web dédiée. C’est le point d’entrée pour les utilisateurs et les contributeurs potentiels. À défaut d’un site web, la page de README.md du logiciel suffira.

Dire où trouver les dépôts de code source

Lorsqu’on annonce un logiciel libre, le premier réflexe d’un développeur sera d’aller voir le code source : pour comprendre le problème que le logiciel aide à résoudre, pour connaître la licence et les conditions de contribution au logiciel.

Indiquer qui contribue déjà au code source

Lorsqu’une administration publie du code source libre, elle a peut-être développé le code elle-même, ou bien l’a financé. Elle a peut-être reçu de l’aide d’autres agents publics ou de citoyens. Savoir qui est en charge de la gouvernance du projet et qui sont les auteurs est une information importante.

Indiquer si des contributions sont attendues

En général, on ouvre le code source d’un logiciel parce qu’on espère des contributions extérieures. Ce n’est pas systématiquement le cas pour un organisme public, qui peut simplement souhaiter rendre son code source public, sans vouloir gérer des contributions. Dans les deux cas, il est important d’anticiper les attentes en étant très explicite à ce sujet.

Prévenir les équipes qui développent le logiciel

Dès qu’on annonce un logiciel libre, il faut s’attendre à ce qu’il soit testé et à ce que des questions soient posés ou des retours de bugs envoyés. Le mieux est de prévenir les équipes qui développent le logiciel pour que celles-ci puissent se montrer réactives. La première impression qu’on donne à la communauté des utilisateurs et des contributeurs potentiels est importante.

Rappeler pourquoi le code source est libre

Une administration peut avoir plusieurs raisons de publier le code source des logiciels qu’elle développe ou fait développer.

En général, on peut se référer à l’un des trois piliers évoqués par la loi pour une République numérique pour la gestion des systèmes d’information : maîtrise, pérennité, indépendance.

Montrer comment le logiciel dépend d’un écosystème

Les logiciels libres sont souvent construits à partir d’autres logiciels libres et peuvent parfois servir de briques pour d’autres solutions. C’est important d’en avoir conscience en communiquant sur le logiciel, car une critique émise (ou un retour de bug) pourra en fait porter sur un logiciel qui n’est pas développé par l’équipe.

Si le logiciel est sensible question sécurité, dire ce qui a été fait et va être fait

Pour la communication autour de forts enjeux liés à leur sécurité, il est important de souligner ce point dans la communication, en indiquant ce qui a été fait et ce qui sera fait.

Par exemple, si le logiciel a fait l’objet d’un audit de sécurité par l’ANSSI ou si le logiciel a déjà été testé auprès d’agents qui s’y connaissent bien en sécurité, dire quand et quels ont été les résultats. Si une opération de “bug bounty” (chasse aux bugs) est prévue, dire quand et quelles sont les attentes.

Maintenance de ce document et contributions

Ce document est maintenu par Bastien Guerry à Etalab.

Pour toute question, vous pouvez écrire à opensource@data.gouv.fr ou directement à bastien.guerry@data.gouv.fr.

Vous pouvez aussi contribuer avec des suggestions en ouvrant une issue ou en proposant une pull request.

Licence

2018-2019 Direction interministérielle du numérique et du système d’information et de communication de l’État.

2018-2019 Les contributeurs accessibles via l’historique du dépôt.

Les contenus accessibles dans ce dépôt sont placés sous Licence Ouverte 2.0. Vous êtes libre de réutiliser les contenus de ce dépôt sous les conditions précisées dans cette licence.

You can’t perform that action at this time.