Une série de billets visant à commenter (pas à traduire) le guide de Gentkow et Shapiro (2014). Précédemment : Ép. 1 (Introduction), Ép. 1.5 (Informatique).
L’informatique utilise un principe simple : ne pas se répéter. Tout ce qui peut faire l’objet d’une automatisation doit l’être, afin d’éviter de perdre du temps à ré-implémenter quelque chose qui l’a déjà été par le passé, ou qui aurait pu être conçu de manière programmatique, c’est-à-dire automatisé.
Si l’on cherche à sophistiquer un peu ce mot d’ordre, on en arrive rapidement à des distinctions comme celle entre programmation impérative et programmation fonctionnelle, mais dans le contexte de la recherche scientifique, on a surtout besoin de formuler quelques principes plus généraux :
- Comme pour une recette de cuisine ou une partition de musique, tout ce qui peut être automatisé, c’est-à-dire reproduit à partir d’un protocole d’enquête codifié et reproductible à l’identique, mérite de l’être, ne serait-ce qu’à des fins pédagogiques ou parce que la recherche requiert de fournir ces protocoles à des fins de publication ;
- Tout ce qui peut être “scripté“, c’est-à-dire décrit comme l’exécution d’une suite d’étapes (les actes et les scènes au cinéma ou au théâtre), mérite aussi de l’être, afin d’en permettre la reproduction la plus simple et la plus rapide, et éventuellement, son amélioration future, dans un objectif de cumulativité.
Gentzkow et Shapiro donnent des exemples avec Stata : ils décrivent l’utilisation de scripts (do-files dans le jargon Stata) mis à la chaîne les uns des autres, dont l’exécution finale est déléguée à un script Windows. L’ensemble est aussi transparent que possible et devrait rester réplicable à l’identique quelques années au moins : mission accomplie.
Quand je code en R (exemple), je n’automatise quasiment jamais jusqu’à utiliser un Makefile, mais j’inclus toujours beaucoup de documentation sous la forme d’un ou plusieurs README, et laisse aussi souvent un fichier “make.r” qui remplit la fonction d’un “Makefile R” qui serait limité à l’exécution du code
L’autre technique d’automatisation, probablement la plus moderne et la plus appropriée, consisterait à développer le principe des notebooks (documents dynamiques : voir Jupyter, knitr et R Markdown) jusqu’à ce qu’ils puissent générer des documents collant encore plus au format des textes scientifiques.
C’est exactement ce qui est en train de se développer avec Radix for R Markdown, qui me semble extrêmement prometteur. Il faut aussi garder un oeil sur l’automatisation d’autres tâches que l’écriture, comme le peer review : la “chaîne de travail” du Journal of Open Source Software, entièrement conçue sur GitHub, est extrêmement innovante en la matière.