Ce blog évoque assez régulièrement, et parfois conjointement, la quantification comme activité sociale d’une part, et les statistiques (ou l’analyse de données) d’autre part—sujets que j’ai pu combiner, ce semestre, sous la forme d’un enseignement de Master :
La formule du cours (moitié atelier pratique, moitié exposés) est encore un peu trop baroque à mon goût, et la bibliographie est excessivement francophone, en particulier au vu du public du Master visé, très internationalisé ; mais c’est la première version que je mets en ligne1.
Le versant qualitatif du cours est un simple remâché de l’agenda scientifique identifié il y a déjà bien longtemps par le regretté Alain Desrosières2 ; la version actualisée de cet agenda est, de mon point de vue, celui d’Espeland et Stevens, qui est le seul texte, avec un chapitre sur le jargon des statistiques, que je demande pour ce cours.
Le plan donne mes sources, dont un blog dont j’ai déjà parlé, celui du projet ACQUA (ex-AGLOS). J’ai encore des dizaines de dossiers de références diverses et variées à verser dans le plan de cours, ou directement dans le projet, qui possède un volet bibliographique. Tout ceci devra néanmoins attendre que les copies arrêtent de pleuvoir…
J’ai déjà expérimenté avec une formule similaire l’an dernier. [↩]
Et par d’autres, bien sûr : Donald Mackenzie, Theodore Porter, James C. Scott, Libby Schweber, Harry Woolf… [↩]
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 code1
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 scientifiques2.
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.
Un Makefile, de même qu’un script R plus complet, aurait aussi la possibilité d’actualiser les résultats inclus dans les articles ou les slides liées au code. En attendant, cela fait longtemps que je me dis qu’il faudrait que j’écrive des Makefiles, et ne le fais jamais. [↩]
Stata vient aussi de se mettre aux documents dynamiques avec Markdown, mais traînera toujours derrière des langages plus flexibles et entretenus par des communautés d’utilisateurs plus larges et dynamiques. À ma connaissance, SAS et SPSS sont dans les choux… Fin de partie ? [↩]
J’en avais déjà parlé, et peu de choses ont changé dans le plan de cours. En revanche, j’ai fait intervenir deux artistes, qui ont – excellemment – bien expliqué leur projet (en cours) de cartographie sensible de mon quartier parisien1, et j’ai complètement réécrit mes slides :
La séance s’est focalisée sur la visualisation spatiale, qui sert, évidemment, à faire des cartes, un sujet que je trouve très bien documenté en français((Voir par exemple le site Visionscarto et le blog Carnet (neo)cartographique.)), mais pas que : typiquement, beaucoup de réseaux, en tout cas dans les domaines qui m’intéressent, peuvent avoir une version “spatialisée”, c’est-à-dire où les coordonnées sont fixes et signifiantes.
Les slides contiennent quelques détails sur le projet de cartographie sensible mentionné plus haut, mais je ne veux pas trop en dire pour ne pas perturber leur travail.
Dans les slides, vous trouverez aussi notamment une mention de Magrit, l’excellent outil de cartographie en ligne produit par l’UMS RIATE, et quelques-unes des non moins excellentes slides d’Arthur Charpentier et al. sur “La ville en économie”.
Enfin, à la toute fin des slides, vous trouverez deux renvois vers deux petits exercices pratiques avec R, que je n’ai pas eu le temps de faire tourner en classe…
… mais qui suivent de près des billets plus complets, d’Arthur Charpentier (le même) pour la fameuse carte du choléra à Londres par John Snow en 1854, et de François Keck pour le package rleafmap, repéré sur le blog d’Arthur (encore lui).
Ce billet répond à une question soulevée par quelques étudiants dans un cours de méthodes de travail numérique, mais je me dis que certains lecteurs de ce blog peuvent aussi avoir l’utilité des trucs et astuces ci-dessous. Et puis l’enchaînement avec le billet précédent me plaît.
Supposons que vous ayez visionné l’excellent documentaire “Libye, anatomie d’un crime”, et que vous puissiez en avoir besoin à l’avenir, pour citation dans un exposé, dans un cours, ou dans toute autre présentation qui relèverait de l’exception pédagogique1, et pour laquelle vous souhaiteriez, par exemple, utiliser des captures d’écran du documentaire.
Si vous souhaitez conserver une copie du documentaire, c’est techniquement toujours possible : votre navigateur Web doit pouvoir lire cette copie pour vous montrer une version “streaming” (flux) du documentaire. La seule différence entre une copie temporaire (streaming) et une copie permanente est l’emplacement mémoire où vous allez stocker cette copie, et sa persistance.
Pour sauvegarder cette copie, il va vous falloir quelques outils :
Un navigateur Web qui vous permette de repérer facilement le fichier de streaming ;
Un terminal qui puisse exécuter quelques commandes simples ;
Et de quoi lire le résultat final tout en prenant des captures d’écran.
La dernière étape est la plus simple, et bien que tout le monde semble utiliser VLC (création française, cocorico) pour lire de la vidéo, je préfère de très loin mpv, qui beaucoup plus souple (configurable) et que je trouve plus élégant.
1. Identifier le fichier de streaming
Pour la première étape, je conseille Google Chrome avec l’extension Video DownloadHelper afin de localiser le fichier de streaming au format .m3u8, c’est-à-dire la version Unicode / UTF-8 du standard M3U, que l’on utilise souvent en multimédia.
Lancez la vidéo dans votre navigateur afin d’activer la lecture du stream : l’extension va automatiquement détecter le flux, que vous pourriez aussi (mais plus laborieusement) localiser en inspectant, à l’aide de ses Developer Tools, les ressources chargées par le navigateur.
En cliquant sur l’extension (en haut à droite, en bleu), vous aurez plusieurs choix de streams, en fonction de la qualité du flux que vous souhaitez sauvegarder. Passez à la prochaine étape en cliquant sur la flèche entourée en rouge, en choisissant une bonne résolution vidéo :
Contentez-vous, ensuite, de copier l’adresse du fichier .m3u8, afin d’éviter que l’extension ne vous demande d’utiliser sa propre solution de sauvegarde du flux (ce qui se produira si vous demandez à télécharger le fichier plutôt qu’à simplement en copier l’adresse) :
À ce stade, votre presse-papiers contient une adresse de type
… où le serveur appartient à un CDN assez connu, Akamai, et où l’on retrouve bien l’extension m3u8 en fin d’adresse ; notez aussi le protocole/langage SMIL, également courant en multimedia.
Si vous téléchargez et inspectez le contenu du fichier .m3u8, vous y trouverez les adresses de tous les fichiers .ts (MPEG-TS) que le stream mobilise pour faire défiler la vidéo ; ce sont ces fichiers que l’on va télécharger, puis fusionner en un seul fichier final :
(Note : personnellement, à ce stade, je désactive l’extension Video DownloadHelper dans mon navigateur, afin d’éviter qu’elle ne consomme de la mémoire – et n’analyse le contenu des pages Web que je consulte… – lorsque je ne m’en sers pas.)
2. Passer le stream à ffmpeg
Il va à présent vous falloir télécharger la librairie ffmpeg, qui permet de faire tout et n’importe quoi avec des fichiers vidéo.
L’installation et l’utilisation de ffmpeg demandent de savoir utiliser un terminal ; pour installer la librairie sur macOS, vous aurez préalablement installé Homebrew, et utiliserez cette commande2 :
brew install ffmpeg
La librairie ffmpeg permet notamment de “concaténer” (de chaîner, de joindre, de fusionner) des fichiers vidéo. On pourrait télécharger soi-même les fichiers vidéo listés dans le fichier .m3u8, puis les “chaîner” à la main3 ou avec ffmpeg. Mais il y a encore plus simple :
… où l’adresse (tronquée) entre guillemets est un simple copier-coller de celle que vous avez copiée à l’étape précédente, et où le résultat final (le documentaire en entier) s’appelle final.mp4, car on souhaite convertir le résultat au format MPEG-4, lisible avec n’importe quel logiciel de lecture vidéo qui pourrait se trouver sur l’ordinateur de votre salle de cours.
La commande va télécharger l’intégralité des fichiers vidéo listés dans le fichier .m3u8, avant de les convertir au format souhaité. Vous risquez de voir s’afficher des avertissements sans importance au passage — ne vous inquiétez pas, car à moins que vous n’ayez plus d’espace disque ou autre scénario relativement improbable, tout va bien se passer :
Votre documentaire est prêt à l’emploi. Bon visionnage !
J’insiste : il s’agit d’une exception accordée par le droit français, ce qui signifie que tout autre usage doit être accompagné d’une démarche visant à comprendre si des coûts de (re)diffusion peuvent s’appliquer. [↩]
Sur Windows, vous ferez ce que vous pourrez avec les moyens du bord, que je connais mal, et sur Linux, vous installerez vous-même la librairie, en fonction de votre distribution. [↩]
Vous l’aurez compris à la lecture de l’introduction, cette série de billets va parler de recherche empirique, reproductible, et donc très largement informatisée, au sens : conçue, et pour partie exécutée – en matière de production des résultats – face à un écran d’ordinateur.
Du coup, dans cet épisode intermédiaire, je souhaite rajouter quelques mots sur l’équipement informatique du chercheur lambda. Dans leur introduction, Gentzkow et Shapiro ne mentionnent qu’un seul logiciel :
Saying [empirical researchers] should spend more time thinking about the way they write code would be like telling a novelist that she should spend more time thinking about how best to use Microsoft Word.
Ne nous en tenons pas à ça.
La ligne de commande
Lorsque l’on cherche à rendre un protocole de recherche reproductible de part en part, ou lorsque l’on commence à avoir besoin (ou l’envie ; et ce sera notre prochain épisode) d’automatiser ce protocole de recherche, il faut commencer à bidouiller avec la ligne de commande :
Essayez, ce n’est pas si compliqué : sur macOS, ouvrez l’application “Terminal”1, qui vous ouvrira automatiquement une session dans un shell semblable à ceux que l’on ouvre sur n’importe quelle machine Unix2, et tapez simplement :
uptime
Voilà, vous y êtes.
Il s’agit du même shell qu’utilisé dans le billet où j’explique comment sauvegarder un flux vidéo en deux manipulations basiques. Par défaut, il s’agit d’un shell de type Bash, mais vous vous en fichez : tout ce qui compte est de savoir que vous en passerez par là pour accomplir une partie de vos manipulations.
Les éditeurs de texte simple
Lorsque vous aurez besoin d’écrire vos scripts (vos suites de commandes), vous le ferez soit dans un éditeur3 dédié à un langage de programmation spécifique (Stata, RStudio, PyCharm…), soit dans un éditeur en texte “simple” ou “brut” (plain text editor). Ce dernier outil va vous être extrêmement utile, et il vous faut quelque chose de mieux que Notepad ou TextEdit.
Sur Windows, allez voir du côté de Notepad++ ; sur Mac, allez voir du côté de TextMate, mon éditeur favori parce qu’il est extrêmement rapide à l’ouverture. D’autres éditeurs, plus lourds, ont néanmoins l’avantage d’être plus puissants et multi-plateformes : essayez Atom ou Visual Studio Code.
Un éditeur en texte simple ressemble à ça :
Rien d’exceptionnel ici, si ce n’est que vous remarquez tout de suite que les lignes sont numérotées, et que la syntaxe du fichier (ici, Markdown) colorise certaines parties du texte (ici, le lien Web, reconnu par l’éditeur grâce à son préfixe “http[s]://“).
Le même éditeur va vous permettre de composer dans n’importe quel langage de programmation — ci-dessous, un peu de Python qui me sert à télécharger les émissions de France Culture tout en les renommant pour que je puisse les archiver plus vite4 :
Vous voilà équipé. Faisons le point :
Votre ordinateur est une architecture matérielle sur laquelle est posé votre système d’exploitation ; et vous avez l’habitude d’utiliser cet ordinateur via des logiciels comme Microsoft Word. Nous n’y reviendrons pas, car…
Pour écrire du code, il va falloir programmer, c’est-à-dire écrire du code informatique, dans un ou plusieurs langages ; vous allez le faire via des éditeurs spécialisés, ou via un éditeur de texte (simple, plutôt que “riche”, comme Microsoft Word).
En plus de cet éditeur, vous allez aussi passer, de temps à autre, par la ligne de commande (le “terminal”, le shell), qui à l’inverse des autres logiciels cités aux deux points précédents, est toujours pré-installé, car il fait partie intégrante de votre système d’exploitation.
Dans le dossier “Utilitaires”, mais j’espère que vous utilisez Spotlight ou un launcher comme Alfred pour ouvrir vos applications… [↩]
Sur Windows, vous aurez à explorer les différentes alternatives : PowerShell, le successeur de CMD.EXE, ou bien faire tourner Linux sous Windows grâce à Windows Subsystem for Linux (WSL). [↩]
Nous y reviendrons, exemples à l’appui. Ces éditeurs sont souvent appelés des “IDE”. Si vous écrivez du code, vous passez plus de temps dans ces éditeurs que sur Microsoft Word. [↩]
Le code ne devrait pas vous convenir, et c’est du mauvais Python (3.x) de débutant, mais si vous le voulez, il est en ligne. [↩]
