On reprend la série, en bifurquant légèrement (mais légèrement seulement) par rapport aux enquêtes, le thème le plus traité dans les quelques billets de cette année.
À quelques approximations près dans le texte : Claude Bernard en mécaniste, par exemple, c’est peut-être un peu trop rapide. On pourra aussi contester certaines techniques évoquées par l’auteur, comme les corrections de Bonferroni, mais ce n’est pas de la faute de Bruno Falissard, qui reconnaît leur côté très “frustre” (mais qui est étonnamment plus dur, je trouve, avec les méta-analyses par réseaux. [↩]
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. [↩]
