Une pratique inspirée par d’autres

Ma pratique de la veille informationnelle évolue régulièrement depuis mes années de master. Je n’avais aucune appétence pour ce type de travail au départ, en partie à cause des outils couramment utilisés pour faire de la veille, qui ne me plaisent pas – signets sociaux, tableaux de bords, alertes mail, etc. Au fil du master et jusqu’au début du doctorat, j’ai découvert progressivement les thématiques qui m’intéressent le plus professionnellement, ce qui m’a amené à accroître ma recherche d’information mais sans pour autant l’organiser de manière systématique. Inscrit sur Twitter, je n’y ai pas non plus mené un vrai travail de veille : j’ai surtout utilisé ce réseau comme canal de communication, pour diffuser mes billets, présentations et articles.

Et puis il y a un an, tout a changé : Antoine Fauchié a temporairement arrêté de publier sa veille. Antoine enseignait en master publication numérique à l’Enssib quand j’y étais étudiant. C’est à ce moment-là que j’ai commencé à suivre sa veille. Cette source a été très importante pour moi ces cinq dernières années ; ce n’est pas exagérer que lui attribuer un rôle structurant dans mon éducation professionnelle et intellectuelle. Le sevrage a été difficile et a servi de déclencheur à une prise de conscience : mon métier nécessite d’être connecté à des flux de veille de qualité, et si jamais ils viennent à manquer, eh bien il faut les créer soi-même Coïncidence : le jour même où je publie ce billet, Antoine redémarre sa veille. Il était temps !
.

Cela fait donc un an que je construis patiemment une vraie veille. J’ai rationalisé mon réseau d’abonnements et d’abonnés Twitter. J’ai commencé à éplucher les sources de mes sources et à systématiser l’exploration des liens présents dans les articles que je lis. J’ai principalement investi les flux RSS, stimulé par l’utilisation du fabuleux NetNewsWire. Je complète cette pratique avec la consultation périodique de certains sites (ex : Hacker News). Je suis abonné à une ou deux newsletters et listes de diffusion mais le principe des alertes mail liées à des requêtes sur des moteurs de recherche ne me convient toujours pas ; aujourd’hui encore, ma seule alerte mail porte sur la requête « Paul Otlet » dans Google Scholar.

Je ne garde pas ce travail pour moi : j’ai aussi commencé à participer plus activement à la circulation des informations, principalement sur Twitter. Depuis novembre 2020, je me suis mis à formater mes « tweets de veille » de manière un peu plus pratique et reconnaissable : titre, description, lien. Et connaissant le caractère instable des médias sociaux, je souhaite aujourd’hui organiser ce travail de micro-blogging autour d’une plateforme que je maîtrise : mon site.

Le temps n’a pas levé mes réticences envers certains outils classiques de la veille. Le modèle des signets sociaux par exemple ne me convient toujours pas. D’abord concernant la dimension sociale : je recherche plutôt une forme de conversation, ce à quoi Twitter correspond mieux, et je préfère ne pas me disperser sur plusieurs réseaux sociaux. Ensuite concernant la logique de publication : un véritable workflow de veilleur professionnel nécessite souvent des APIs et des tableaux de contrôle, ce qui ne m’attire pas du tout. Je souhaite plutôt façonner mon propre espace éditorial et définir ma pratique de publication par rapport à une technique que je maîtrise de bout en bout. Je préfère que ma veille soit lente car artisanale : des descriptions rédigées soigneusement, qui témoignent d’une curation réfléchie, et des listes fabriquées à la main, capables de survivre à toutes les migrations informatiques.

La liste comme objet éditorial

Ce dernier point me tient particulièrement à cœur. Les curieux qui seraient allés voir comment mon site est fabriqué se seront peut-être étonnés de ne pas trouver de script pour fabriquer le flux RSS, ou bien de constater que ma page d’accueil est entièrement écrite à la main : eh non, ce n’est pas un Makefile qui ajoute les dernières parutions dans le fichier index.md, c’est moi.

Il y a une raison à cela : j’ai été échaudé par mon expérience avec les générateurs de sites statiques clé en main comme Jekyll ou Hugo. Sur le papier, les fonctionnalités d’automatisation de ces outils apportent un confort non négligeable. Ils peuvent notamment s’occuper de générer des listes de contenus destinées à l’affichage (ex : page « Publications ») ou à la diffusion (ex : flux RSS). La liste est virtuelle, au sens où elle doit être actualisée par l’interprétation d’une ligne de code. Tout ça fonctionne très bien, jusqu’au jour où on veut changer d’outil : tout ce qu’on sait automatiser avec l’ancien générateur de site, il faut alors réapprendre à l’automatiser avec le nouveau. Or, bien que j’aime beaucoup le principe de la programmation éditoriale Architecture de l’information et fabrication d’objets éditoriaux à l’aide de techniques associées à la programmation : variables, booléens, boucles conditionnelles, etc.
, je ne suis pas pour autant programmeur. Ce ré-apprentissage est donc potentiellement fastidieux et chronophage, et j’ai décidé de procéder autrement.

Ce n’est pas une question de faisabilité technique. Depuis septembre 2020, mon site est fabriqué avec Pandoc, lequel est tout à fait capable d’automatiser la construction de contenus en s’appuyant sur des données structurées en YAML par exemple. Ce n’est pas non plus une question de capacité d’apprentissage : j’ai écrit une fois que j’étais incapable de reproduire une fonctionnalité de Zettlr dans BBEdit et j’ai finalement réussi à le faire quelques temps après. Non, c’est une décision consciente : je ne souhaite pas déléguer la création des listes au programme qui s’occupe de générer le site.

Tout l’intérêt des générateurs de sites statiques, c’est que le contenu reste à l’abri des contingences et de l’imprévu : les données sont stockées dans des formats légers, pérennes, faciles à lire et écrire, ce qui leur permet de survivre à toutes les migrations. Le passage de Jekyll à Pandoc m’a fait réaliser que la liste est un type de contenu très important sur mon site, au même titre que les textes. Blog, publications, flux RSS et désormais veille : ces listes ne sont pas simplement des objets compilés après coup mais des produits éditoriaux conçus de façon active. Je pense que Pandoc va servir de socle à ma pratique pendant longtemps mais rien n’est jamais certain, ni la maintenance du logiciel, ni mes choix d’utilisation. C’est pourquoi j’ai décidé de sortir les listes de la catégorie des contenus virtuels pour en faire des fichiers à part entière.

D’un point de vue pratique, la partie la plus longue c’est l’amorce de la liste : il faut rassembler les informations, définir un format d’écriture, et tester sa mise en œuvre. Cette étape est grandement facilitée quand on connaît les techniques de manipulation du format texte comme les expressions régulières, que je maîtrise bien contrairement à la programmation. Une fois la structure de la liste définie, il n’y a plus qu’à empiler les informations au fil du temps.

Cela ne signifie pas que toute automatisation doit être proscrite. On peut se créer des modèles, des petits fragments d’architexte ou plastigrammes aurait dit Yves Jeanneret ; c’est ce que je fais pour les listes les plus structurées, en m’appuyant sur des fonctionnalités de mon éditeur de texte comme les placeholders. On peut aussi utiliser des scripts chargés d’incrémenter les différentes listes, comme par exemple pandoc-rss. L’automatisation a un intérêt : « il faut parfois perdre un peu de temps au début pour en gagner beaucoup ensuite », comme dit mon directeur de thèse. Mais chaque chose en son temps : si une idée simple peut être exécutée rapidement de façon manuelle, alors d’un point de vue pragmatique c’est déjà une excellente solution.