Note technique
Cellule Innovation numérique pour la Connaissance - alexandre.liccardi@ofb.gouv.fr, rel. francois.hissel@ofb.gouv.fr et gaelle.deronzier@ofb.gouv.fr.
Version 1, décembre 2022.
La publication des codes sources (interfaces, scripts, algorithmes, ressources numériques pour rejouer les calculs d’une publication…) développés par les services publics est une obligation forte de la Loi pour une République numérique de 2016, les codes sources étant par nature des documents administratifs. Les solutions de publication de code (services Git par exemple) et les catalogues de ressources sont nombreux : il est nécessaire de structurer les pratiques en interne aux services publics pour mieux accompagner les potentiels participants (voir le rapport “Pour une politique publique de la donnée” de 2020 de la mission parlementaire Bothorel).
Cette note se base sur les travaux de la cellule Innovation numérique pour la Connaissance. Elle propose des recommandations de publication de code source informatique relatifs aux activité de Connaissance en interne, en particulier sur le domaine du traitement des données. Les consignes présentées proposent une approche volontaire non contraignante, qui se base sur des pratiques précédentes hétérogènes (voir travaux précédents de la cellule : sur les codes sources, sur les outils en interne).
Au même titre que l’open data (publication / ouverture des données), l’open source (publication / ouverture des codes informatiques) est porteur d’enjeux socio-économiques forts et un important vecteur de la transparence de l’État. Concernant directement les activités de Connaissance de l’OFB, la cellule Innovation numérique pour la Connaissance a identifié les objectifs :
d’information et de porter à connaissance : transparence et reproductibilité des outils de l’action publique ;
de communication scientifique et technique et de reproductibilité : participation à des méthodes spécifiques, matériel accompagnant les publications scientifiques par exemple (exemple d’un dépôt de code d’un ingénieur biométricien expert) ;
de collaboration : permettre à d’autres services et d’autres acteurs, notamment les communautés de développeurs, de modifier les productions et de les améliorer, selon un protocole plus ou moins administré selon la volonté des auteurs (exemple de GéoNature) ;
de capitalisation en interne des ingénieries, afin d’assurer la traçabilité et la reprise à la fois des réflexions qui ont permis le traitement des cas, à la fois leur code-source ;
d’appropriation des outils numériques : publier ses codes sources participe à la culture du numérique et à ses dynamiques (voir Stratégie Numérique pour la Connaissance). Les réutilisateurs doivent retrouver, sur des outils simples d’accès et familiers, l’essentiel des informations permettant la reproductibilité et la description complète des réalisations (principes portés par les dynamiques interministérielles et la politique de contribution aux logiciels libres) ;
de publicité et de rayonnement des services, en visant l’amélioration de la visibilité des compétences en interne.
Pour aller plus loin :
Sur un plan technique, les codes informatiques utilisés par les projets Connaissance sont généralement séparables en trois catégories :
Enfin, certains algorithmes développés sont utilisés pour produire des indicateurs ou des cartographies techniques diffusés par l’OFB en open-data (par exemple dans le cadre de l’observatoire national de la biodiversité). L’ouverture et la publication de la méthode de calcul participent de la transparence même de l’indicateur ou du produit. À ce titre, la diffusion de ces algorithmes est obligatoire.
De manière générale (voir les interprétations du CRPA), les codes publiés ne doivent ni porter atteinte aux missions de l’Etat et/aux instructions en cours (en permettant notamment des intrusions ou la divulgation d’informations), ni compromettre des contrats en cours (travail en cours de prestataires), ni porter préjudice à l’image des établissements publics (codes à finalité scientifique non validés).
Ces conditions, qui visent par exemple le traitement de données sensibles (espèces à forte valeur économique, informations couvertes par un secret statistique...) et les codes en cours de développement par les prestataires et les développeurs, imposent deux modes de gestion : un mode complètement public, qui correspond à la diffusion sur une plateforme externe (type Github), un mode à accès restreint, hébergé localement (type GitLab).
Par leur mission d’expertise et de conseil, les cellules fonctionnelles Outils et Innovation numérique pour la Connaissance sont compétentes pour émettre des avis sur le respect de ces conditions, l’opportunité de l’ouverture des codes, et, de manière générale, la qualité des codes exposés.
Une démarche de recensement des codes développés à publier, à entreprendre par chaque service hiérarchique de l’OFB porteur de projet(s) Connaissance, est recommandée par la cellule Innovation numérique pour la Connaissance sur la base du volontariat. Cette démarche aura pour but de dresser l’inventaire des codes applicatifs à publier par projet, et pourra bénéficier de l’aide des membres de la cellule Innovation numérique pour la Connaissance et de la cellule Outils sur l’année 2023. Le SOAD à la DSUED propose d’ouvrir la marche dès le premier trimestre.
Un tableau de déclaration des codes pouvant faire l’objet d’un avis des cellules fonctionnelles est mis à disposition via la GED, dont un espace permet le dépôt sécurisé des codes à qualifier (les accès de travail peuvent être demandés à alexandre.liccardi@ofb.gouv.fr ou gregoire.etot@ofb.gouv.fr).
Les agents OFB ont une activité de publication de code importante, cependant pour beaucoup peu visible et non pérennisée, car éclatée par auteur ou par projet. Dans la mesure du possible et sur les plateformes de diffusion qui le permettent, il est recommandé de rassembler les codes publiés dans le cadre des missions de l’établissement sous une même structure publiante (organisation sur les plateformes dédiées).
Concernant la publication de codes sources sur les plateformes publiques d’exposition de code informatique, la solution de rattacher au cas par cas les projets à l’organisation OFB spécifiquement créée est proposée (démarche volontaire des développeurs).
Sur les plateformes de publication de ressources, le diffuseur de informations est directement la structure (data.gouv) ou l’auteur sous rattachement de la structure (recherche.data.gouv).
Une liste des entités fédératrices est maintenue sur le DataLab de la cellule Innovation numérique pour la Connaissance.
Le choix de la plateforme de diffusion dépend du public visé (diffusion publique, ouverte à tous, ou privée, restreinte au groupe projet ?), des conditions de production (via une prestation en cours ?), de l’objectif recherché (mutualiser, échanger, valider, voir / diffuser, participer) et du domaine d’application (traitement des données, recherche…).
Le dépôt sur Github est généralement préconisé lorsque l’agent ou l’établissement cherchent à diffuser largement le code et à impliquer des personnes externes dans son amélioration (participation), car ce service est le plus fréquenté des services d’hebergement de code et de gestion de projet de développement informatique avec près de 60 millions d’utilisateurs actifs.
Une entité fédératrice est créée : l’organisation OFB. Chaque porteur de répertoire peut associer le projet à cette organisation et lui transférer la propriété, si le projet concerne bien une action officielle (validée par direction) de l’OFB. C’est une démarche volontaire de la part des chargés de mission et ingénieurs.
Des alternatives existent à Github, comme Bitbucket ou GitLab. Ces solutions sont généralement moins orientée ouverture de code et davantage production : leur usage n’est pas recommandé (mais pas interdit).
L’OFB propose, via sa DSI, un service de dépôt de code : le Gitlab officiel de l’OFB. Ce service de dépôt et de collaboration permet une gestion fine des utilisateurs par la DSI (contacter pascal.perrier@ofb.gouv.fr), ainsi qu’un hébergement en propre (sur serveur OFB) des codes sources. L’ensemble des codes diffusés par cette plateforme est réalisé dans le cadre des missions de l’OFB : il n’y a donc pas d’organisation d’affiliation.
L’utilisation de cette plateforme en mode privé (limitation de l’accès aux participants aux projets ou aux personnes en faisant la demande explicite) est très fortement recommandée pour :
Un mode public (ouverture du code à tous) est aussi possible, il ne permet cependant pas la participation d’agents extérieurs.
Le Gitlab officiel de l’OFB est donc recommandé pour les projets en cours de prestation, ou pour les projets dans lesquels une participation externe n’est pas attendue, ou encore pour les projets publics dont les agents contributeurs ne souhaitent pas créer de compte Github. -->Certaines structures utilisent déjà des outils en interne similaires à ceux cités, notamment Gitlab pour Patrinat. Il n’est pas demandé de modifier l’organisation précédente pour les travaux en interne.
Un projet peut tout à fait être hébergé en mode privé sur le le Gitlab officiel de l’OFB et, en parallèle, en mode participatif sous Github en vue de rassembler une communauté. La version sous Gitlab correspondra alors à un archivage de la dernière version intégrée par un projet à maîtrise d’ouvrage directe OFB, et la version Github correspondra à une version collaborative.
Certains codes sources sont directement diffusés par l’applicatif métier auquel ils contibuent. C’est par exemple le cas de SEEE, qui donne accès aux codes sources et aux méthodes d’indicateurs, à côté de leur service de calcul en ligne. De telles publications sont gérées au sein de chaque projet et ne sont pas concernés par cette note.
D’autres projets préexistent aux initiatives OFB (et disposent de dépôts déjà utilisés) ou font l’objet d’une coordination externe à l’OFB (par exemple, SISPPEO est hébergé par INRAE). C’est aussi le cas de développement visant des publics métiers spécifiques, comme les Administrations et Collectivités territoriales qui peuvent utiliser la forge ADULLACT. Le dépôt du GBIF France rend accessible les codes de certains projets Patrinat, et plus largement les codes applicatifs des organisations affiliées.
La présente note ne concerne pas ces projets, qui gardent leur gouvernance précédente.
Afin de permettre une meilleure diffusion des logiciels développés par l’Etat et une meilleure appropriation du SILL (socle de logiciels libres), le pôle logiciels libres d’Etalab propose un catalogue référençant les dépôts de codes créés par les administrations publiques (y compris internationales). Le référencement sur ce catalogue est très conseillé pour les codes publiés en mode public sur le Gitlab officiel de l’OFB ou via Github, mais aussi pour l’ensemble des codes non référencés par ces plateformes, que les auteurs souhaiteraient rattacher à leurs projets OFB. Il s’agit ainsi d’une voie d’accès complémentaire aux productions des agents.
Si les services d’hébergement et de gestion de codes sources en ligne performent pour l’exposition de produits de développements informatiques, certaines publications scientifiques et techniques demandent une gestion documentaire par dossiers de fichiers versionnés et disposant d’un identifiant unique. Ces plateformes permettent d’exposer des dossiers projet, chaque projet contenant les ressources nécessaires à sa documentation, sa rejouabilité et à la compréhension de ses résultats.
NB. Cette note ne s’intéresse pas à l’archivage des projets, mais uniquement à la partie exposition des codes, lorsqu’il est nécessaire que ces codes fassent partie d’un lot de ressources et qu’un service de type git (gestion collaborative et dynamique) n’est pas attendu.
La nouvelle plateforme (entrepôt de données de recherche) recherche.data.gouv.fr fournit des fonctionnalités équivalentes à Zenodo, mais s’inscrit dans l’écosystème *.gouv.fr en se spécialisant sur les données de recherche. Plusieurs services spécifiques dédiées sont ainsi instanciés :
L’utilisation de recherche.data.gouv.fr est donc ici préconisée, dès lors que l’objectif de la publication est un datapaper et/ou que l’objectif de la diffusion est essentiellement la publication de données en ligne, correspondant à des travaux de recherche, notamment dans le cadre du respect de l’obligation de dépôt des données associées aux articles des chercheurs.
L’OFB dispose d’une entité de rattachement sous recherche.data.gouv.fr, à laquelle il est demandé de rattacher les productions professionnelles des agents. La plateforme propose une licence par défaut : la licence ouverte 2.0.
Zenodo, initialement OpenAIRE Orphan Record Repository, propose un espace de stockage de 50 Go par projet. Cet outil d’archivage et d’exposition de ressources a été conçu par le CERN dans le cadre du programme de recherche “Horizon 2020” ; il vise à fournir un support de diffusion aux travaux scientifiques et techniques dont le domaine cible ne dispose pas de plateforme dédiée.
Zenodo bénéficie d’avantages considérables, qui en font une plateforme recommandée par la cellule Innovation numérique pour la Connaissance pour la diffusion des études scientifiques et techniques :
Il est souvent demandé aux contributeurs d’affilier leurs productions à un journal ou à une communauté identifiée. Une communauté OFB est créée en tant qu’unité fédératice.
Un code informatique publié sous Zenodo peut prendre plusieurs formes : soit via une archive copiée sur le dépôt (à favoriser lors de la publication de versions, qui seules permettent de rejouer les études), soit via l’ouverture d’un projet Gitlab ou Github qui sera cité. Rien n’empêche l’ouverture des ressources via Zenodo pour l’archivage et la version, et via Github pour la collaboration.
Une liste complète des licences à considérer est diffusée par la mission Etalab.
Si le cadre contractuel du projet et les bibliothèques logicielles mobilisées le permettent, il est conseillé d’utiliser une licence sans obligation de réciprocité (dite copyleft faible), qui impliquent que les redistributions utlérieures, modifiées ou non, ne sont pas contraintes à reprendre la licence initiale. En effet, l’OFB considère que la réappropriation de codes par des tiers est souhaible, y compris à des fins commerciales. Les licences CeCILL-B pour les logiciels et Etalab v2 pour les données sont ainsi conseillées.
La publication passe nécessairement par un contrôle de qualité en interne, qui ne doit cependant pas décourager les utilisateurs ou générer trop de travail. La cellule Innovation numérique pour la Connaissance propose la checklist suivante, qui doit faire l’objet d’une autovalidation avant publication, et dont seulement certains items sont obligatoires.
Les membres de la cellule Innovation umérique pour la Connaissance peuvent être mobilisés pour des questions relatives à cette liste, ou pour accompagner le contrôle préalable aux publications.
| Item checklist | Obligatoire ? | Précision |
|---|---|---|
| Une documentation récapitulative claire (objectifs, schémas…) est présente |  |
A minima : informations permettant la compréhension et la reprise, schémas d’architecture générale |
| Le readme est renseigné | |
Un readme est un document de présentation, il ne se substitue pas à une documentation de reprise |
| Un exemple exécutable ou un service d’exécution permet l’utilisation | Parmi les exemple : 101 (guide B.A.-BA), tutoriel, mode ergonomique (Jupyter par exemple)… | |
| Les principales fonctions et classes sont commentées | |
La documentation doit être spécifique, concise et précise, les générations automatiques étant insuffisantes |
| Chaque bloc de code est renseigné | Non obligatoire, mais tout code publié doit être lisible | |
| Chaque fichier est listé, identifié, décrit | Selon la plateforme et la complexité des arborescences publiées | |
| Les ressources sont fournies et téléchargeables | |
Il ne doit pas manquer de ressources bloquantes à l’exécution (jeux de données par exemple) |
| Les crédits de réalisation sont adressés | |
Les auteurs et leur structure d’accueil doivent être identifiables |
| Une licence est choisie et citée | |
Via un dispositif dédié, ou à défaut dans la description de manière explicite et visible. |
| Il existe un compilateur ou interpréteur libre associé au code | |
En plus du code, s’assurer que le langage fait l’objet de spécifications ouvertes avec un compilateur de référence |
| Pas de vulnérabilité connue exploitable (a fait l’objet d’un scan) | Selon outillage proposé par les services informatiques | |
| Pas de login / mots de passe / infos de connexion | |
Par principe de sécurité, la divulgation de codes professionnels est proscrite |
| Bibliothèques listées et gérées (dont versions) | |
Selon projet et mode de développement, en particulier les dépendances logicielles |
| L’absence d’intérêt commercial, ou de contrat en cours |  |
Par principe (responsabilité du contributeur) |
| La preuve de l’innocuité de la publication du code | |
Par principe (responsabilité du contributeur) |
| La maturité technique et scientifique des codes publiés. | |
Par principe (responsabilité du contributeur) |
