Python : scripts et notebooks

J’y faisais allusion dans le précédent billet sur Annif, donc une petite digression sur les notebooks.

Ceci est donc un petit retour d’expérience sur mon usage (enfin, non-usage puis usage partiel) des notebooks Python.

Contexte

En arrivant à la BnF en 2016, je me suis mis à apprendre le langage de programmation Python parce que data.bnf.fr était écrit en Python. L’équipe avait donc développé une compétence technique sur l’utilisation de ce langage, pour satisfaire des besoins dans le traitement de données qui auraient aussi pu être satisfaits avec d’autres langages.

Depuis plusieurs années, j’écris donc des scripts (avec l’interface de développement ci-dessus, Visual Studio Code, qui est un éditeur adaptés pour divers codes, dont Python, mais n’est pas un framework de développement) qui me permettent de répondre à des demandes d’extractions ou de traitements divers liés à mon activité au département des Métadonnées de la BnF.

Le plus souvent, ces scripts me permettent de produire des fichiers Excel, donc quand je programme suite à la demande de collègues, ces derniers voient uniquement le résultat sous forme de tableaux.

S’ensuit un processus de travail assez bien rôdé, et plutôt satisfaisant :

• je rédige une version 1 du script, sur la base de consignes initiales assez simples
• ce qui produit une version 1 correspondante du rapport Excel
• le collègue analyse le résultat, fait une série de remarques
• je les prends en compte dans le code, fait une version 2 du script –> version 2 du fichier Excel
• et ainsi de suite jusqu’à ce que le résultat final soit satisfaisant

On alimente donc progressivement un document de suivi, organisé de manière antéchronologique (le document en question est géré dans une base de documents, logiciel Lotus Notes d’IBM, qui permet comme pour une page web d’intégrer des fichiers au sein d’un texte global)

Et sinon, quand je bricole des trucs dans mon coin en essayant de me souvenir de ce que j’ai fait, j’ai évidemment ce genre de dossiers que je redécouvre 1 ou 2 ans plus tard.

Les notebooks Jupyter : définition

La première copie d’écran ci-dessus montre un fichier qui est un script brut : il ne contient que du code et des commentaires, le tout conforme à la syntaxe de Python. On peut le faire exécuter par le fichier python.exe.

Exécution d’un script en appelant le programme python.exe, qui va se charger de le lancer

J’ai appris il y a 3 ans environ l’existence de « notebooks Jupyter« . Un notebook est un autre type de fichier, qui permet de mélanger du code et du commentaire en langage Markdown, ce qui permet d’avoir en plus de la mise en forme : on peut structurer le déroulé d’un programme en parties, sous-parties, avec des chapitres, des paragraphes, des listes, etc. qui précèdent et suivent les blocs de codes.

Ce qui est précédé de la mention Entrée [ ] est du code (et chaque bloc peut s’exécuter séparément, contrairement à un script « normal » qui s’exécutera d’un bout à l’autre), le reste est du commentaire.

Notebook : quoi-n’en-faire ?

Pendant plusieurs années, après avoir vaguement testé cet outil, je n’ai pas vraiment su dans quels cas l’utiliser.

Lorsque Google a mis en place Google Colab (une version cloud de Jupyter, hébergée dans Google Drive, mis en place vers 2019 ? — pour plus d’explications), j’ai trouvé deux cas d’usage très convaincants :

• tester rapidement un bout de code, et éventuellement le partager avec quelqu’un (une simple fonction, une expression régulière, etc.) et le tester ensemble
• faire des formations à Python, sans s’embarrasser de problèmes d’installations
  (parce que quand on forme des étudiants à un langage comme Python, on passe forcément trop de temps à résoudre les problèmes d’installation, de systèmes d’exploitation multiples, d’ordinateurs empruntés)

Mais pour ce qui est de programmes pour extraire, manipuler, corriger des données en masse, le script — comme fichier ne contenant que du code, s’exécutant d’un bout à l’autre, lancé souvent en ligne de commande — me semblait beaucoup plus satisfaisant. Notamment pour des raisons de performance : si l’ordinateur n’est pas occupé à afficher ce qu’il fait, il l’exécute souvent plus rapidement (l’affichage prend de la mémoire).

Faire du work in progress en temps réel

Et finalement j’ai réalisé qu’un notebook, mélangeant code et commentaires, ressemblait beaucoup au document de projet montré au tout début de ce billet : du code, du paratexte, des jeux de données.

Donc de plus en plus, quand je me lance dans un projet d’extractions/corrections qui va demander des allers et retours, je suis tenté d’ouvrir un notebook du projet (plutôt qu’un ensemble de fichiers, dont un baptisé readme.md).

Évolutions dans la manière de coder : pandas et matplotlib

L’utilisation d’une interface plus visuelle, qui permet de voir les traitements étape par étape (et non en se contentant des données en entrée, puis des fichiers en sortie) incite à faire des « rapports d’étape », c’est-à-dire voir un état des données au nème (mais pas dernier) traitement, sous forme de table (d’extrait de table) ou de graphe fournissant quelques stats (souvent, un histogramme de distribution).

Et pour cela je me suis mis à utiliser des librairies dont je n’avais pas l’usage (même si je connaissais leur existence : pandas (pour gérer des tableaux, alors que jusque là je gérais tantôt des listes de listes, tantôt des listes d’objets dont j’avais moi-même défini la classe — désolé si cette phrase est obscure) et matplotlib qui contient tout un tas d’outils pour générer des graphiques.

Je ne sais pas trop comment interpréter le fait que mon outil de saisie évolue influe sur ma manière de coder, alors que mes besoins (en tant que séries de transformation à infliger aux données) n’ont pas vraiment changer.

Des notebooks articulés avec ce blog

Et donc mon idée est aussi de concevoir certains notebooks en vue d’être articulés avec des billets de blogs, pour rendre compte du travail réalisé et, potentiellement, vous permettre de récupérer et ré-exécuter plus facilement du code (sait-on jamais?). A suivre notamment concernant Annif.

Exemple de notebook (extraction de données du SRU de la BnF [?])

Remarque supplémentaire sur le choix de Python

Comme je l’ai indiqué plus haut, je me suis mis à Python (après de nombreuses années passées avec XSL/XSL-T, mon premier amour) pour des raisons contextuelles : l’équipe que j’ai rejointe en 2016 connaissait ce langage-là.

Cet aspect conjoncturel, ou opportunisme (mon voisin de bureau le fait, donc je le fais) ne me semble pas anodin. Quand j’assure des formations à Python, et que j’essaie d’expliquer pourquoi se former à ce langage-là plutôt qu’à un autre (dans le monde des bibliothèques et des sciences de l’information), les 3 principaux arguments que je donne sont :

• aspect communautaire : Python a connu une croissance énorme dans le monde des humanités numériques, qui, dans le monde universitaire, est ce qui se rapproche le plus du monde des bibliothèques (au moins par le parcours disciplinaire de la majorité de ses membres)
• rapidité de prise en main pour des non-informaticiens
• intelligence artificielle

Bref, dans nos métiers il est utile de disposer d’outils pour manipuler les données (ou de disposer de gens qui savent utiliser les outils qui permettent de manipuler les données). Python est l’un de ces outils.