1.1 Science ouverte et reproductible

🖥️ Diapositives du cours — Séance 01 (mer. 30 sept.)

La science ouverte et reproductible est la norme de travail de ce cours. Chaque devoir et le projet final sont notés en partie sur un critère : quelqu’un d’autre pourrait-il réexécuter votre analyse et retrouver votre résultat ? Cette page explique ce que cela signifie en pratique : la science ouverte, les principes FAIR, les licences, la citation des données, les prépublications (preprints), et pourquoi la reproductibilité (reproducibility) compte davantage encore maintenant qu’une grande partie du code est écrite par l’IA.

Deux compléments à cette leçon (qui ne la remplacent pas) :

Qu’est-ce que la science ouverte ?¶

La science ouverte est la pratique qui rend les produits de la recherche — données, code, méthodes et articles — accessibles à d’autres pour être examinés, réutilisés et prolongés. En géosciences, ce n’est pas un idéal abstrait. La plupart des données de ce livre (formes d’onde sismiques, positions GNSS, imagerie satellitaire, réanalyses climatiques) existent parce que des agences et des chercheurs les ont publiées ouvertement — en France, pensez aux formes d’onde d’Epos-France (ex-Résif), aux positions GNSS du RENAG, aux données du BRGM ou de Météo-France. Quand vous publiez votre propre travail de la même manière, vous bouclez la boucle.

La science ouverte a plusieurs composantes :

• Données ouvertes : observations et données dérivées déposées dans des archives, avec leur documentation.
• Code ouvert (open source) : code d’analyse publié sous une licence qui en permet la réutilisation.
• Méthodes ouvertes : flux de travail décrits (ou scriptés) assez bien pour être répétés.
• Accès ouvert : articles lisibles sans barrière payante, souvent via les prépublications.

La reproductibilité est le fil qui relie les quatre. Un résultat est reproductible si quelqu’un qui dispose de votre code et de vos données peut régénérer vos figures et vos nombres. Il est réplicable si quelqu’un, avec de nouvelles données et son propre code, parvient à la même conclusion. Ce cours note la première et vise la seconde.

Les principes FAIR¶

Les principes FAIR (Wilkinson et al., 2016) décrivent ce qui rend des données utiles aux autres :

• Findable (trouvables) : les données ont un identifiant pérenne (un DOI), des métadonnées riches, et sont indexées dans un catalogue interrogeable.
• Accessible (accessibles) : les données se récupèrent par un protocole standard (HTTPS, pas « écrivez à l’auteur »).
• Interoperable (interopérables) : les données utilisent des formats ouverts et documentés (CSV, NetCDF, HDF5, GeoTIFF) et des vocabulaires standard, pour être lisibles depuis tout langage et tout outil.
• Reusable (réutilisables) : les données portent une licence claire et assez d’information de provenance pour qu’un tiers juge si elles conviennent à son usage.

Quand vous assemblerez un jeu de données prêt pour l’IA au chapitre 2, vous appliquerez ces principes à vos propres produits : archiver les données, documenter la provenance, joindre une licence, obtenir un DOI.

Les données géoscientifiques sont souvent des données de lieu, et les données de lieu peuvent porter des obligations qu’un fichier de licence ne capture pas — réglementations locales, accords avec des communautés, politiques nationales de données. Avant de considérer la publication ouverte comme allant de soi, vérifiez les conditions dans lesquelles les données ont été collectées.

Licences¶

Sans licence, les autres ne peuvent légalement ni réutiliser ni modifier votre travail, même déposé dans un dépôt public. « Public » ne veut pas dire « sous licence ». Chaque dépôt que vous créez dans ce cours porte donc un fichier de licence.

Licences logicielles. Les choix open source courants :

• MIT et BSD : permissives. Chacun peut réutiliser le code, y compris commercialement, à condition de conserver la mention de copyright. La plupart des bibliothèques scientifiques Python (numpy, pandas, scikit-learn) les utilisent.
• GPL : copyleft. La réutilisation est permise, mais les œuvres dérivées doivent porter la même licence.

choosealicense.com guide le choix. Pour les travaux du cours, MIT est un choix par défaut raisonnable. Le chapitre licences du Turing Way offre une discussion plus complète.

Licences pour données et textes. Les licences logicielles sont écrites pour du code et conviennent mal aux données. Pour les jeux de données, la documentation et les figures, utilisez Creative Commons :

• CC-BY : réutilisation avec attribution. Le choix courant pour les jeux de données et les articles.
• CC0 : versement au domaine public, sans condition. Courant pour des données où le suivi de l’attribution est impraticable.

Un dépôt qui contient à la fois du code et des données peut porter deux licences — par exemple MIT pour le code et CC-BY pour les données — la répartition étant précisée dans le README.

Ce que contient un dépôt réutilisable¶

Au-delà de la licence, un dépôt que d’autres (y compris votre futur vous) peuvent utiliser comporte :

• README.md : la pièce maîtresse de la documentation. Ce qu’est le projet, comment l’installer, l’usage de base, comment le citer, où trouver de l’aide. Voir awesome-readme pour de bons exemples. Un bloc de citation en BibTeX y a sa place :

  @software{MLGeo,
  authors = {The GeoSMART team},
  year = 2023,
  doi = {10.5281/zenodo.7838345}
  }

• LICENSE : comme ci-dessus. Un texte distinct pour le logiciel et pour les données peut être nécessaire.

• CONTRIBUTING.md : quelles contributions sont bienvenues et comment les proposer. Awesome contributing guides donne des exemples.

• Une spécification d’environnement : pixi.toml et pixi.lock, ou environment.yml, ou requirements.txt, pour que l’environnement logiciel puisse être reconstruit (voir 1.3).

Les leçons Intermediate Research Software Development des Software Carpentries traitent le sujet en profondeur software_carpentries_intermediate.

Citation des données et DOI¶

Un DOI (Digital Object Identifier, identifiant numérique d’objet) est un identifiant pérenne qui résout vers un jeu de données, un article ou une version de logiciel pour toujours, même si l’URL d’hébergement change. Des données avec un DOI se citent comme un article — c’est ainsi que les producteurs de données sont crédités, et c’est pourquoi les archives exigent que vous citiez les données que vous utilisez. Quand ce livre télécharge des données GNSS du Nevada Geodetic Laboratory en 1.7, nous citons Blewitt et al. (2018). Faites de même pour chaque jeu de données de votre projet.

Zenodo, opéré par le CERN, attribue des DOI gratuitement et s’intègre à GitHub : liez votre dépôt une fois, et chaque release GitHub est archivée sur Zenodo avec son propre DOI, automatiquement. C’est ainsi que vous rendrez votre projet final citable. GitHub documente le processus ici. Les archives disciplinaires (PANGAEA, EarthScope, les centres de données nationaux — en France, Epos-France pour la terre solide, ou les pôles de données Data Terra : Theia, ForM@Ter, AERIS, ODATIS) jouent le même rôle pour les données d’observation.

Prépublications¶

Une prépublication (preprint) est le manuscrit rendu public avant (ou pendant) l’évaluation par les pairs. En sciences de la Terre, les principaux serveurs sont EarthArXiv et ESS Open Archive (ESSOAr). Les prépublications rendent les résultats disponibles des mois, voire des années, avant les revues ; elles portent un DOI et sont citables. La plupart des revues de géosciences autorisent la prépublication ; vérifiez la politique de la revue. Lire des prépublications fait aussi partie du travail bibliographique hebdomadaire de ce cours, avec la prudence d’usage : une prépublication n’a pas encore été évaluée par les pairs — lisez-la avec le même œil critique que vous apprendrez à porter sur les sorties de l’IA.

La reproductibilité à l’ère de l’IA¶

On pourrait croire que les assistants IA rendent la reproductibilité obsolète : si le code peut être régénéré à la demande, pourquoi l’archiver ? C’est l’inverse qui est vrai.

• Le code généré par l’IA n’est pas déterministe. Posez deux fois la même question au même assistant : vous n’obtiendrez pas deux fois le même code. Le seul enregistrement de ce que vous avez réellement exécuté est le code que vous avez validé (commit), dans l’environnement que vous avez verrouillé.
• Le volume augmente, l’examen par ligne diminue. Un assistant peut produire en quelques minutes une analyse qui a l’air de fonctionner. Qu’elle calcule bien ce que vous croyez est une autre question — et la réponse se trouve dans le code validé, pas dans votre souvenir du prompt (la consigne donnée à l’assistant).
• La provenance inclut désormais l’IA. Déclarer quels outils ont été utilisés, et pour quoi, fait partie des méthodes, exactement comme nommer les bibliothèques logicielles et leurs versions. La politique du cours est en 1.8.
• La vérification est le nouveau goulot d’étranglement. Quand le code ne coûte rien, l’objet reproductible — environnement verrouillé, données épinglées, flux de travail scripté, sorties validées — est ce qui permet à un humain (vous, un coéquipier, un relecteur) de contrôler le travail efficacement.

Le chapitre 5 développe tout cela en un flux de travail complet : environnements en fichiers de verrouillage, versionnage des données, suivi des expériences. Pour l’instant, la règle est simple : tout ce qui a produit une figure ou un nombre dans votre projet est validé, sous licence et réexécutable.

Pour aller plus loin¶

• The Turing Way the_turing_way_community_2022_6909298 — le manuel de référence de la recherche reproductible
• Wilkinson et al. (2016), The FAIR Guiding Principles