Python scientifique reproductible
Le code scientifique commence souvent comme un notebook exploratoire ou un petit script. C'est approprié tant que la question évolue encore. Les problèmes apparaissent lorsque ce même prototype devient, sans documentation, la chaîne de production d'une figure publiée ou d'une décision d'ingénierie.
Une structure de projet minimale
Un projet durable doit séparer :
- les données d'entrée immuables ou provenant de sources externes ;
- le code d'analyse importable ;
- les tests et cas de référence ;
- la configuration et les paramètres ;
- les figures, tableaux et rapports générés ;
- la documentation expliquant comment reproduire les résultats.
Les noms exacts des répertoires importent moins que le fait de rendre explicites les dépendances et le flux des données.
Environnement et dépendances
Un fichier pyproject.toml fournit un emplacement standard pour les métadonnées du
paquet, les exigences Python et la configuration des outils. Les dépendances doivent
être contraintes assez précisément pour recréer un environnement fonctionnel, sans
prétendre qu'un verrouillage d'environnement garantit la validité scientifique.
La version de Python, les bibliothèques natives importantes, les hypothèses liées au système d'exploitation et les commandes externes doivent également être documentées lorsqu'elles influent sur les résultats.
Vérifications qualité
Le formatage et le linting améliorent la cohérence, tandis que le typage statique peut révéler des hypothèses incorrectes sur les structures de données et les interfaces. Les tests doivent se concentrer sur les propriétés du domaine plutôt que sur les seuls détails d'implémentation :
- lois de conservation et cohérence dimensionnelle ;
- comportement aux limites et face aux entrées invalides ;
- accord avec des cas analytiques ou calculés indépendamment ;
- invariance sous des transformations qui ne devraient pas modifier le résultat ;
- tests de régression pour les défaillances déjà observées.
Provenance des données
Les données brutes doivent rester inchangées. Les étapes de nettoyage et de transformation doivent être implémentées sous forme de code, avec les enregistrements rejetés ou corrigés explicitement consignés. Chaque résultat généré doit pouvoir être relié aux données d'entrée, aux paramètres et à une révision logicielle.
Déterminisme et incertitude
Les graines aléatoires sont nécessaires à la répétabilité, mais insuffisantes pour une validation robuste. Les bibliothèques numériques, l'exécution parallèle et le matériel peuvent encore influencer les résultats. Plus important encore, répéter exactement le même calcul ne vérifie pas que la méthode ou les hypothèses sont correctes.
La reproductibilité permet de reconstruire le résultat. La crédibilité scientifique exige en plus une analyse de sensibilité, une évaluation des incertitudes et une validation indépendante.
Surface de commande recommandée
Une petite interface en ligne de commande ou une cible Make peut définir des
opérations comme check, test, analyse et report. L'objectif est qu'une autre
personne puisse reconstruire les artefacts publiés sans reproduire la succession de
clics interactifs de l'auteur.