Les enjeux de reproductibilité sont grands : les personnes n’ont pas tellement intérêt à créer des procédés scientifiques reproductibles. Il fallait attendre longtemps avant que d’autre puissent reproduire ce que le chercheur avait fait. A l’époque, on s’appuyait sur des témoins oculaires de bonne naissance (gentlemen) pour attester de la véracité des expériences.
De là est naît la Royal Society of Science. Cette société met en place un nouveau concept de témoin virtuel. On renseigne sur papier toutes les étapes de notre expérience afin que tout gentlemen puisse le vérifier. C’est l’ancêtre de la publication. Cette technique garantissait la légitimité mais pas la reproductibilité. Même si on décrit tout, il existe toujours un savoir tacite, un savoir qu’on ne parvient pas à expliciter.
Cela est toujours vrai aujourd’hui (Laser TEA américain non reproductible par les britanniques jusqu’à ce qu’un américain les aide).
Il faut arriver à décider ce qu’il faut reproduire ou non, les enjeux ne sont pas les même en fonction du domaine. Il y a des domaines ou la notion de reproductibilité est difficilement cernable (anthropologie).
Pourquoi une crise : une peur de la perte de la légitimité scientifique, besoin de transparence (open access), enjeux politique, mauvaise technique statistique (boite noire). Cette crise a débuté en 2015/2016. Certains journaux en ont fait leur ligne éditoriale. Nature publie en 2016 une étude sous forme de questionnaire montrant que nous seulement personne n’essayait de reproduire les études et que quand on le faisait, cela ne fonctionnait pas.
Chapitre 1 : la reproductibilité est une histoire complexe
Il est difficile d’avoir un consensus autour de la définition de la reproductibilité car beaucoup de domaines différents s’emparent de la notion et n’en ont pas la même utilisation. D’une manière générale, c’est un moyen d’augmenter la fiabilité en science mais ce n’est pas toujours nécessaire et pas toujours suffisant. D’autres questions se posent : on base le concept sur le fait de reproduire alors qu’on est jugé sur l’originalité de notre recherche en science. A travers l’histoire, beaucoup on essayait de reproduire des expériences sans y parvenir et on mit la main sur le plus gros frein : le savoir tacite, c’est-à-dire le savoir de l’expérimentateur qu’il n’a pas réussi ou pas jugé important de noter mais qui ne permet pas la reproduction des résultats sans y avoir accès.
La reproductibilité qui est donné comme standard de la science est en fait un idéal inatteignable. "Pour être certain qu'une expérience a été bien conduite, on a besoin de savoir si elle donne le bon résultat. Mais pour savoir en quoi consiste le bon résultat, on a besoin de réaliser une expérience bien conduite. Mais pour savoir si une expérience a été bien conduite, ad infinitum. La "régression de l'expérimentateur" démontre (selon Collins, 2016) que l'expérience seule ne peut forcer un scientifique à admettre un résultat auquel il est déterminé à s'opposer.
Chapitre 2 : 6 catégories de reproductibilité
Leonetti (2016) propose 6 catégories d’activité scientifiques pour lesquelles la reproductibilité n’a pas forcément le même sens ni la même importance.
1) Reproductibilité computationnelle
Si avec un fichier de donnée et des instructions, on peut reproduire les résultats finaux.
Certains domaines ne visent pas à la reproduction car cela n’a pas de sens (anthropologie). Ils se concentrent donc sur la documentation du processus de production des données, la réflexivité (le chercheur établit la liste de ses propres influences comme son humeur du jour, etc.).
Il est donc dangereux d’imposer la reproductibilité globale comme standard car cela pourrait ghettoïser les sciences ne rentrant pas dans ce standard.
Chapitre 3 : la crise et le discours de crise
On remarque que la crise correspond au début du mouvement de l’Open Access, la rébellion contre les éditeurs scientifiques cachant la science au plus grand nombre. Par la même occasion, on demande plus de transparence et que les recherches puissent être reproductibles.
Plusieurs domaines ont été touché par cette crise :
• La psychologie : les études apparaissent souvent au grand public, toujours obligé de prouver que c’est une science, cette crise a créé une profonde introspection permettant de souligner les bonnes pratiques et de s’y plier.
• Les essais cliniques : en 2012, une publication démontre la généralisation de nombreux essais cliniques alors que les résultats étaient négatifs, les financements des laboratoires privés posent également question.
• La méta-science : on remarque des problèmes de bonnes pratiques statistiques souvent dénoncé et donc médiatisé.
Chapitre 4 : La reproductibilité computationnelle
La statistique est vedette de la crise car elle est beaucoup impliquée dans les domaines médiatiques et elle est utilisé par les non-experts et facile à dramatiser.
Reproductibilité expérimentale : on remarque qu’il n’y a pas une seule méthode scientifique, il faut donc définir ce sur quoi les chercheurs se base pour la validité des expériences (jamais universel).
On a tendance à la penser inviolable, mais les logiciels aussi peuvent être tricked et orienter les résultats. De plus, une grande partie de l’activité est réalisé par des chercheurs dont ce n’est pas le métier. De plus, il est difficile de répondre à toutes les demandes en termes de libre accès, de perfs, etc. pour un logiciel (un business model est difficilement enviseable).
Reproductibilité et transparence
Introduction
Quand la reproductibilité n’est pas possible ou pas souhaitable, ce sont les enjeux de la transparence qui prédominent. Janz (2018) distingue trois types de transparence :
• Data transparency : fournir les données sur lesquelles se base l’analyse
• Production transparency : expliciter les protocoles qui ont permis l’obtention des données.
La pratique de la pre-registration est très positive : on partage nos données et/ou nos codes informatiques, nos hypothèses, notre plan d’analyse afin d’éviter le HARKing (hypothesizing After the Results are Known). La tenue d’un cahier de laboratoire peut également aider à ceci.
La transparence, c’est rendre visibles les éléments qui nous ont permis d’obtenir les résultats obtenus. Il faut donc une traçabilité optimale. On peut faire beaucoup d’erreurs ou polluer les résultats par nos biais, il faut donc être transparent pour repérer les erreurs le plus vite possible et les corriger.
Utiliser des logiciels en open source développe cette transparence. On peut se créer un codebook afin d’améliorer cette transparence.
Le mieux est d’inclure les rubriques suivantes dans le codebook :
• Intitulé du code
• Courte description des finalités du code
• Critères d'inclusion
• Critères d'exclusion
• Exemples typiques : sélection de quelques cas qui illustrent le mieux les critères d'utilisation
• Exemples atypiques : sélection de cas extrêmes, atypiques pour lesquels l'usage du code est requis
• "presque, mais non" ("close, but no") : des cas où l'on serait tenté.e d'utiliser le code, alors que les données ne correspondent pas
On peut également utiliser un gestionnaire de références bibliographiques et des outils de contrôle de versions. Veiller à utiliser des sources exhaustive et représentative et ne pas tomber dans le biais de sélection. Il faut aussi gérer ses sources pour ne pas faire des erreurs de reporting, faire dire à l’auteur autre chose que ce qu’il a dit ou transformer avec son prisme un propos qu’il a tenu. Il faut respecter le formalisme pour que la référence soit accessible à tous. Les logiciels tel que Zotero permettent en open source de gérer ceci. Il possède même un plugin dédié au suivi des articles rétractés. Il faut quand même améliorer et rectifier les données importées (qualité des articles), avoir une méthode de tri et d’organisation des données, annoter les notices. Le souci c’est que grâce à ces logiciels on multiplie les articles ! Il faut donc analyser sa bibliothèque avec sa question de recherche pour filtrer les articles.
Il peut être important d’avoir un outil de suivi des versions des logiciels.
Les logiciels reproductibles ® sont valorisés dans le recrutement universitaire. Les données sont de plus en plus collectables et même certaines revues demande que le code et les données soient fournis avec l’article.
Quand on travaille à plusieurs, des outils de représentation du workflow comme Graphviz peuvent être utiles. Aussi, pour documenter le plus possible les projets, des outils de Tasks Management System comme Trello peuvent être utiles.
MODULE 1 : Cahier de note, cahier de laboratoire
Introduction
Le cahier de note est le support (papier ou numérique) sur lequel nous stockons nos informations au fil des recherches.
Nous utilisons tous des cahiers de notes
Nous écrivons tous mais pas sur les mêmes supports. Certaines notes sur le papier, sur le tableau, en fonction de notre domaine, de notre matériel, et du nombre de personnes qui travaillent ensemble. A la fin de chaque séance, il faut faire le tri tout en gardant toutes les pistes (fausses ou bonnes). Il est important d’indexer de la façon la plus optimale possible pour retrouver les traces dans plusieurs années. On doit noter les conditions et les paramètres de la manipulation expérimentale sur on est dans le cadre d’une expérience. Si on utilise un cahier de laboratoire il faut qu’il soit grand et solide car il subit beaucoup de mauvais traitements. Il doit porter le nom de celui qui écrit pour chaque observation et doit être rigoureusement daté. Les expériences ratées doivent être consignées également car les recommencer serait une perte de temps et connaître les conditions d’échec d’une manipulation fait avancer la recherche. Pour chaque donnée, il est important de lui donner un numéro d’identification correspond à l’endroit auquel on en parle dans le cahier.
Un aperçu historique de la prise de notes
Nous avons commencé à prendre des notes sur des tablettes (tabula) de cire avec des stylets qui gravaient les notes. Ces stylets peuvent effacer les notes prises ce qui donne l’expression tabula rasa (faire table rase). Ensuite nous sommes passé au volumen (rouleau de papyrus sur lequel on écrit en colonnes). Mais son utilisation n’est pas pratique, il faut dérouler d’un côté et enrouler de l’autre et lire à voix haute car les mots n’ont pas de séparation. Nous passons ensuite au codex grâce à deux innovations (les reliures et le développement du parchemin, peau animale, dû à une interdiction du papyrus). La rubrication, les grosses lettres d’une couleur différentes, est utilisé pour signaler que les paragraphes sont séparés. Ensuite, à l’invention de l’imprimerie, la couleur coûte trop chère, on remplace les rubriques par des blancs (saute une ligne). Les chinois ont commencé à utiliser le papier au 6 siècles avant JC.
Du fichier texte au langage de balisage léger
Un fichier texte donne quelque chose de lisible quand il est ouvert avec un éditeur de texte. Un éditeur de texte permet de créer et de modifier des fichiers textes. Les logiciels de traitement de texte ne sont pas des éditeurs de texte, ils sont plus puissants et ne sortent pas les fichiers en format texte.
Il est important d’utiliser des fichiers texte car ils utilisent les caractères UTF-8 (Universal Character Set Transformation Format – 8 bits). Ils sont toujours lisibles avec un éditeur de texte des années plus tard et les logiciels d’indexation les exploitent complétement. Malheureusement, avec les fichiers texte, on ne peut pas ajouter de lien, mettre une police en évidence ou se corriger comme avec Word. Les informaticiens ont donc créé un langage de balisage (HTML). Ce langage ne peut pas être lu directement par un humain, il faut un éditeur spécialisé. Ils ont donc créé un langage de balisage léger qui est un type de langage de balisage utilisant une syntaxe simple, conçu pour qu’un fichier en ce langage soit aisé à saisir avec un éditeur de texte simple et facile à lire dans sa forme non formatée. Un bel exemple est le logiciel Markdown, on tape le texte et il le traduit automatiquement en format HTML. On peut donc travailler avec des fichiers texte, écrire rapidement des notes et les organiser.
Markdown : # pour définir une nouvelle section, le titre à côté sera le titre, ## pour définir une nouvelle sous-section. Pour un hyperlien, on note entre parenthèse le titre et entre d’autres parenthèse l’URL du site. < ! pour écrire des commentaires (ils n’apparaissent pas dans la version finale). Voir didacticiel de Jean-Daniel Bonjour pour savoir tout faire (https://enacit.epfl.ch/cours/markdown-pandoc/).
Pandoc : R studio utilise déjà Pandoc. Il permet de modifier la sortie des langages texte en PDF ou autre (https://enacit.epfl.ch/cours/markdown-pandoc/#commande_pandoc).
Text Encoding Initiative (TEI) est un format de balisage standard qui garantit une accessibilité à long terme. Il permet de baliser de façon intelligente le texte étudié. Les balises standards permettent un meilleur partage de l’information sans dépendre d’un logiciel en particulier. Il s’appuie sur le langage XML et est un dictionnaire de balises couvrant la plupart des situations. Ceci est particulièrement utile en SHS ou l’on s’appuie énormément sur les textes d’autres auteurs. Il permet de mettre l’accent sur la sémantique des objets représentés. Il permet de se construire un patrimoine numérique stable dans le temps.
Pérennité et évolutivité des notes avec la gestion de version
La pérennité des notes sera obtenue en multipliant les copies et en sauvegardant le plus possible notre texte. On peut le faire avec un format texte avec DokuWiki. Cependant, on ne peut modifier qu’une page à la fois. C’est là que les logiciels de gestion de version sont utiles, ils vont examiner les fichiers et suivre les corrections d’une arborescence de fichiers. Je peux facilement accéder à la liste de changements qui ont été effectué, par qui et quand. Je peux également accéder aux détails des modifications apportées avec les différences entre les versions anciennes et nouvelles. De là, je peux décider de revenir en arrière si je le souhaite. On peut alors modifier plusieurs fichiers simultanément. Git est cependant un peu plus difficile à utiliser. Une sauvegarde centralisée est disponible sur Github et les membres du projet en ont une version intégrale.
J’ai pu pratiquer GitLab, on peut même avoir accès facilement au projet des autres.
Les gestionnaires de versions sont apparus dans les années 70. Ils permettent de conserver un historique des modifications sans dupliquer les dossiers de sauvegardes, de sauvegarder les données (et historique) sur des ordinateurs distants et de fusionner automatiquement des fichiers édités par plusieurs personnes. Il en existe beaucoup, mais on va s’intéresser à Git. Il a été créé en 2005 pour le projet du noyau Linux par Linus Torvalds. C’est un projet énorme de plusieurs millions de lignes de code (+20m) et 14 000 développeurs. Au vu de la taille du projet, il était nécessaire d’avoir un logiciel qui puisse gérer l’historique. La différence avec Dropbox, c’est qu’avec Git, tout est explicite, il faut donc lui dire ce que l’on veut synchroniser pour qu’il le fasse. On peut grâce à la commande git add demander à git de conserver une certaine modification. Avec git commit, on peut demander de faire le checkpoint (date, commentaire) en indiquant l’état stable que l’on souhaite enregistrer. On peut retourner à la version que l’on veut, comparer les différences entre plusieurs versions. Tout ce qui a été commité est sauvegardé et accessible. Git clone créait un historique vierge local et git push envoie ce clone sur le serveur Git. On synchronise automatiquement la branche principale de notre projet, si on synchroniser les autres branches, il faut les nommer.
Quand on travaille à plusieurs, il faut bien faire git push pour enregistrer sur le serveur nos modifications et git pull sur on veut récupérer la dernière version du projet sur le serveur. Même si on travaille en même temps, si c’est sur des parties différentes, git demandera à faire un git pull avant de faire un git push et il fusionnera les modifications. Si c’est sur la même partie, il y a un conflit, le dernier qui souhaite modifier devra donc choisir quelques modifications on garde entre les siennes et celles des collègues. Donc collaborer c’est gérer un historique distribué ! Vu que chacun a tout l’historique, rien de peut menacer les versions (même si le serveur disparait). Le mieux est de travailler avec le format texte.
Github et Gitlab sont des plateformes d’hébergement gratuites de projets publics, ils ont des interfaces web et gèrent des permissions et des utilisateurs. C’est un réseau social de développeurs pour travailler, montrer son activité (stats, émulation, gestion de communauté, issues, correction de bugs, revue de code). Un fork c’est quand le projet est visible mais pas modifiable par tous et qu’on fait la demande de pouvoir le sauvegarder sur son espace personnel pour faire des git pull request.
Github sont les leaders du marché mais il reste un logiciel propriétaire. Pour les projets publics, ils ne demandent rien mais si c’est privé, cela reste gratuit seulement pour les étudiants et les académiques.
Gitlab sont l’alternative gratuite. Il y a une instance publique et une instance institutionnelle pour qui veut. Il faut choisir en fonction du type de projet (public besoin de monde : github), si confidentialité (git institutionnel).
Rstudio est une interfaces graphiques lié à Git.
Les étiquettes et logiciels d’indexation pour s’y retrouver
DocFetcher permet de trouver facilement parmi de nombreux fichiers un mot dans ceux-ci. Il précise le nombre d’occurrence du mot. Grâce à Markdown (et ses < :! Commentaires :>) ont retrouver facilement nos commentaires peu importe le type de fichier.
DocFetcher a besoin qu’on lui indique les fichiers à fouiller (index à partir d’un dossier). Il va effectuer l’indexation rapidement. On peut taper un mot et il nous donne la collection de fichiers correspondante.
ExifTool aide à ajouter des notes et des commentaires pour pouvoir aider DocFetcher a les trouver en fonction de notre demande. Il permet d’une façon plus générale de visualiser et de modifier les métadonnées.
