# Objectifs du module 2 : La vitrine et l'envers du décor - Extension de la traçabilité aux calculs et à ses résultats - Intégration du code et des résultats dans un document du type rapport technique / article scientifique ## Introduction Nous sommes souvent bien moins organisés que ce que nous prétendons être. -> qu'est-ce qu'un document computationnel ? Celui-ci permet d'accéder à la fois à la vitrine et à l'envers du décor, c'est-à-dire d'améliorer la traçabilité des calculs, de présenter facilement les travaux, et d'accèder aux calculs sous-jacents à une analyse. Environnements présentés : Jupyter, Rstudio et Emacs/Orgmode Jupyter : plus adapté pour coder en Python. ## Exemples de travaux aux résultats discutés - économie : politiques d'austérité Travaux de Reinhart et Rogoff Le débat a été long car les données n'ont pas été publiées dans leur intégralité - imagerie cérébrale Signes d'activité cérébrale chez le poisson mort -> met le doigt sur des problèmes méthodologiques - fausses structures de protéines - Code d'analyse aurait inversé deux colonnes de données - Rétractations Ces problèmes sont présents dans tous les domaines scientifiques. La rigueur et la transparence sont alors de mise. ## Pourquoi est-ce difficile Difficultés rencontrées lors des tentatives de reproduction d'expériences - manque d'informations : - données et sources, - choix effectués (hypothèses sous-jacentes à l'analyse, etc.) . Choix non expliqués = choix suspicieux - ordinateur : source d'erreur - point and click - les tableurs : erreurs de programmation et de manipulation de données - pile logicielle complexe et mal maîtrisées (logiciels propriétaires qui fonctionnent comme des boîtes noires) Problème : programmer, c'est dur ; mais il faut vérifier que chacune des briques de l'analyse est valable - manque de rigueur et d'organisation - pas de backup - pas d'historique (manque de gestion de versions) Dimension culturelle et sociale : - article = version **simplifiée** de la procédure - tracer et rendre dispo les informations : exige du temps Tout rendre public ? - les faiblesses deviendraient évidentes -> c'est normal, tout travail a ses faiblesses - quelqu'un peut trouver une erreur -> oui, mais il faut que les erreurs soient connues - quelqu'un pourrait en tirer avantage -> importance d'un article méthodologique (Github : entre la plateforme de développement et le réseau social ; mettre ses travaux à disposition montre la propriété intellectuelle) - les données peuvent être sensibles (ex : infos sur le vote, etc) -> se poser des questions éthiques, vérifier l'accessibilité des données **Outils à éviter et alternatives** - outils, formats et services propriétaires : - adopter le format texte - logiciels et langages de programmation libres - répliquer les données à plusieurs endroits, si possible issus d'alternatives libres - outils "intuitifs" : tableur, interfaces graphiques -> utiliser R ou Python *Expliciter augmente les chances de trouver les erreurs et de les éliminer* Ressources complémentaires intéressantes : [How computers broke science – and what we can do to fix it](https://theconversation.com/how-computers-broke-science-and-what-we-can-do-to-fix-it-49938) Recommandations issues de cet article : - minimiser le point-and-click et utiliser des scripts - utiliser les formats non-propriétaires - organiser systématiquement les fichiers (voir par exemple [ici](https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1000424) pour la biologie computationnelle) [Sur les boots camps destinés aux chercheurs - quelques indices de bonnes pratiques dans cet article](https://www.nature.com/news/boot-camps-teach-scientists-computing-skills-1.15799) [Les erreurs dans les spreadsheets en biologie](https://qz.com/768334/years-of-genomics-research-is-riddled-with-errors-thanks-to-a-bunch-of-botched-excel-spreadsheets/) ## Le document computationnel : principe Objectif essentiel de ce type de document : permettre une transparence la plus complète possible - Données : obtenues sur des machines - Analysées et visualisées, échangées avec des collègues - Allez-retours entre acquisition et analyses de données Au bout de tout cela : publication : une jolie histoire, des figures convaincantes, mais pas moyen de voir tout le travail sous-jacent Objectifs méthodologiques de la recherche reproductible : - Inspecter - Refaire : vérifier, corriger les erreurs Partie émergée d'un document computationnel : la vitrine Document initial : son environnement Exemple : notebook Jupyter (qui possède une console Python en interne): - fragments Markdown - fragments de code Cette console est "vivante", ce qui incite à écrire les bours de code petit à petit Chaque zone est ensuite transformée vers un seul document Markdown On peut choisir de partager le document final ou le document computationnel. Différents outils mais un même principe : - un seul document avec explications, code, résultats des exécutions : permet inspection et vérification, réexécution - session : la console vérifie que les variables sont persistantes - export vers un autre format Différences entre les trois outils sont relativement mineures et portent sur : syntaxe, interopérabilité des langages, contrôle offert lors de l'export OrgMode est pratique pour LateX ## Travailler avec les autres Pour produire un document prêt à l'impression à partir d'un document computationnel, il faut choisir dans tous les cas : - quelles cellules cacher ? - le bon style Cela demande d'avoir un environnement parfaitement configuré. **Comment convaincre ses co-auteurs de faire des efforts ?** Plusieurs réactions et approches possibles face à un nouvel outil. Dans ce cas, il faut assurer le service après-vente : compatibilibité avec les environnements. Mais pratique pour la vérification. Si les co-auteurs sont réfractaires : il faut utiliser un document classique, avec notamment les figures générées. **Partager avec les autres** - Avec Rstudio : Rpubs : pas pérenne - Dropbox et autres : pérénnité, accès... - Gitlab / Github : on peut soit - tout rendre public - faire le ménage et archiver l'état courant dans un type compagnon -> outils Runmycode, archives ouvertes telles que HAL, figshare, zenodo **Notes prises à partir des questions** "Enfin, d'expérience, on surestime toujours la longévité des documents conservés sous forme numérique. La meilleure façon d'archiver est probablement d'imprimer le code source avec de l’encre d’archivage sur du papier non acide et le confier à un archiviste expérimenté qui en fera des copies et les disséminera dans des lieux sûrs. C'est une technique qui pourra sembler archaïque aux plus jeunes mais qui a fait ses preuves." A quoi se préparer quand on utilise un document computationnel : a. En laissant mes co-auteurs accéder et modifier facilement mon code, ils risquent de tout casser b. Mes collaborateurs risquent de se rendre compte que je code comme un cochon et que je bidonne mes résultats (en imaginant que ça soit le cas... ;) c. Je n’aurai plus d’excuse pour ne pas relire et vérifier le code de mes collaborateurs d. Il faudra que mes co-auteurs et moi-même nous assurions que ça fonctionne sur chacune de nos machines et ça nous prendra du temps e. Il faudra installer des tas de trucs compliqués alors que nos machines ne sont pas à jours Avantages de l'utilisation et de la publication d'un document computationnel : a. Ce sont des outils relativement faciles à prendre en main, ce qui permet au plus grand nombre de se les approprier et de comprendre mon travail b. Ces outils permettent d’avoir dans un seul document (1) un aperçu des données (2) du code (3) les résultats de calculs, et surtout (4) des explications sur comment ces trois types d’objets s’articulent les uns avec les autres c. Cela permet d’être transparent sur la façon dont on arrive à telle ou telle conclusion d. Cela permet à d’autres de plus facilement réutiliser tout ou une partie de nos procédures de calcul ## Ressources complémentaires [A R markdown template for academic manuscripts](http://svmiller.com/blog/2016/02/svm-r-markdown-manuscript/)