Ou L‘histoire de l’écriture de mon premier programme informatique…
Ou encore Comment je n’en pouvais plus de pointer des références bibliographiques à la main…
Remontons un peu en arrière…
Une fois que la section « CV » sera entièrement renseignée, il me sera plus facile d’exposer certaines expériences, que j’aimerais partager. En attendant, je fais un petit résumé ici de ma formation, histoire de resituer un peu les choses…
D’abord philo, ensuite objo…
J’ai obtenu une maîtrise de philosophie en 2001, après avoir un peu traîné à la fac de Reims (mais pas trop), et surtout après avoir effectué mon objection de conscience (17 mois indemnisés un peu plus que la solde du trouffion de base, mais de belles rencontres et une expérience enrichissante !)
Des cours du soir au Cnam…
En parallèle de ma formation à la fac, j’étais inscrit aux cours du Cnam Champagne-Ardenne (devenu Cnam Grand-Est), à Reims, histoire de valider certaines compétences que je possédais déjà, étant un peu un geek avant l’heure (j’ai connu les débuts de l’informatique, mais pas les dinosaures, je précise pour les enfants). J’ai alors suivi alors des cours d’administration de serveurs web (et découvert les joies de Linux…)
…puis un boulot au Cnam
J’ai pu ensuite encore approfondir mes connaissances dans ces domaines puisque le Cnam – au vu de mes bons résultats et du fait que nous cherchions tous les deux, lui un assistant informatique, moi du boulot – avait décidé de m’embaucher.
J’en ai profité pour vivre ma première expérience de négociation salariale ratée, mais comme je n’espérais alors pas plus que le SMIC et que ma maîtrise de philosophie me garantissait, grâce aux conventions collectives, un chouïa supplémentaire, tout s’est bien terminé et je suis parti pour un demi emploi-jeune, un CDD de 30 mois (arf).
Prog., web et BDD…
J’y ai alors appris les bases de la programmation en Java, javascript et PHP ; découvert les joies des bases de données PostGreSQL et MySQL (directement administrées sous Linux, dans les règles de l’art) ; j’ai aussi appris à développer des sites web, avec le logiciel Dreamweaver – j’ai eu, plus tard, l’occasion de tenir moi-même deux cours du soir sur ce logiciel. Si j’avais pu penser, à l’époque, que j’utiliserais ces compétences dans le cadre d’un emploi au Muséum de Paris, je n’y aurais pas cru !
…et enfin, découverte d’InDesign !
Par la suite, j’ai continué mon expérience au Cnam de Reims en devenant Assistant communication, chargé du site web et de la réalisation de supports de communication de la structure, principalement les catalogues des formations proposées. La réalisation se faisait alors sous Microsoft Publisher, avant que je puisse suivre une formation gratuite dispensée par Adobe à Paris, à l’issue de laquelle j’étais reparti avec ma toute première licence officielle d’InDesign CS2.
Mon passage par le Cnam, c’est donc la découverte de la programmation, du logiciel InDesign, de mes premières expériences en termes d’édition papier et de mise en ligne de site web… Les graines étaient, pour ainsi dire, semées.
Un mix improbable
Car les compétences que j’ai le plus développées dans mon emploi actuel sont en rapport direct avec ces premières expériences et ce que j’avais appris en cours du soir à cette époque. J’ai découvert ainsi que l’on pouvait utiliser le langage javascript sous InDesign, pour manipuler du texte cette fois.
Un outil (Javascript et InDesign) et de la matière (les articles qui me sont soumis, et qui contiennent de nombreuses données éditoriales, mais aussi de biodiversité), il ne m’en fallait pas plus pour avoir envie d’étendre mes compétences dans ce domaine…
Ne manquaient plus alors qu’un objectif et une utilité : le Muséum me les a fournis.
Mon arrivée au Muséum
C’était en novembre 2009, par voie de concours. D’un côté, J’estime avoir eu une chance inouïe de décrocher ce poste d’Assistant d’édition au Muséum, sans avoir spécialement de formation dans le domaine (dans le BAP F, comme je le sais maintenant) ; d’un autre côté, la chance, il faut bien la tenter, et il faut croire aussi que les autres concurrents avaient été moins bons (ou plus mauvais) que moi. J’étais peut-être le seul à être allé voir dans Wikipédia, la veille de l’oral du concours, ce qu’étaient la « systématique » et la « taxonomie » (deux domaines d’expertise du Muséum), allez savoir. Toujours est-il que j’ai eu le poste : c’est comme ça que je suis entré aux Publications du Muséum.
mais c’était quand même mythique !
D’ardus débuts
Bon, c’était pas l’horreur, au contraire, même. J’étais (et je suis toujours) très bien entouré, et les personnes qui m’ont accueilli m’ont enseigné toutes les bonnes ficelles pour me défendre face aux chercheurs, qui ne sont pas tous faciles… Il n’empêche que je venais juste d’intégrer les fonctions de secrétaire d’édition de la revue Geodiversitas, la revue de Paléontologie du Muséum, et qu’il fallait que j’intègre illico toutes les règles de l’édition scientifique de cet établissement prestigieux.
à mon arrivée au Muséum… (hiver 2009)
C’était alors parti pour un marathon trimestriel : prépa des figures, coulage de l’article, 1ère relecture, corrections, 2ème relecture par quelqu’un d’autre, re-corrections, échanges avec les auteurs, relecture du BAT imprimeur, tout ça répété 10 à 12 fois tous les 3 mois… Et ça n’est pas terminé aujourd’hui !
Mais je reviens à mes moutons électriques, qui rêvent de bouts de code, et qui voudraient savoir, comme vous (si vous en êtes là, vous lirez bien la suite jusqu’au bout), comment j’en suis arrivé à écrire des programmes au lieu (ou en plus) de relire et de corriger des articles ?
Du code et des Codes
Dans les difficultés de l’apprentissage du métier d’éditeur (on dit comme ça maintenant), outre la découverte des Codes de nomenclature zoologique puis botanique (qui régissent les règles à suivre pour décrire de nouvelles espèces), la relecture des articles est clairement – pour moi – l’étape la plus fastidieuse.
Et au sein même de cette étape, une partie est encore plus fastidieuse que le reste : pointer les références. Je me suis donc mis à repousser le moment où il fallait que je me résolve à pointer ces fichues références, à tel point qu’il ne finissait par me rester, à la fin de chaque sprint de trois mois, plus que des références à pointer…
Mais cette vérification essentielle, en quoi consiste-t-elle exactement ?
Tu (te) tires ou tu pointes ?
Le principe de la science est basé sur la reproductibilité de la recherche. Les résultats originaux publiés doivent donc être accompagnés de la liste des travaux sur lesquels ils s’appuient – la bibliographie – et pour chaque affirmation basée sur l’un de ces travaux, doit être indiquée la référence exacte, avec éventuellement la page correspondante, via ce que l’on appelle un « appel de référence ».
Il est donc possible, théoriquement, de reproduire la démarche suivie par les chercheurs – y compris via les lectures auxquelles ils se sont référés – pour en arriver aux résultats qu’ils publient.
Ajoutez à cela que les chercheurs et les journaux scientifiques sont évalués en fonction du nombre de citations que leurs travaux génèrent (c’est-à-dire à chaque fois qu’un autre article cite leur publication, comme dans la capture ci-dessus), vous comprendrez que la vérification de la correspondance texte/bibliographie doive être effectuée aussi rigoureusemlent que possible (lire cet article pour vous en convaincre si nécessaire).
Impossible d’éviter, donc, un pointage des références sans faille : tous les appels dans le texte doivent correspondre systématiquement à une entrée dans la bibliographie, et toutes les entrées de la bibliographie non citées au moins une fois dans le texte doivent disparaître.
Ce travail, fastidieux et essentiel, est aussi terriblement chronophage… Malgré tout, l’horizon n’était alors, pas totalement obscur…
C’est une bonne situation, ça, script ?
Les prémisses de l’affaire se résument donc ainsi : une tâche répétitive à l’envi, la nécessité permanente de gagner du temps et le fait de disposer d’un outil extraordinairement efficace – InDesign, dont je découvrais les arcanes un peu plus chaque jour.
Tout cela m’a amené à imaginer la première ébauche d’une solution à mon problème…
Un GREP pour les trouver tous…
Comme vous l’avez compris, parcourir un texte pour rechercher les appels de références est fastidieux. Il ne faut pas en manquer, même s’ils se présentent sous des formes très différentes (ex. : Linnaeus 1753 ; Merle & Pinson 2005, 2007a, b ; Rouge-George et al. 2012, 2014c). Et tous sont répétés de nombreuses fois. Va-t-on se souvenir de quelles références ont déjà été appelées, et lesquelles jamais encore ? Pour ma part, je n’ai jamais réussi, et j’ai toujours été obligé de vérifier…
Donc, main gauche : le texte de l’article. Main droite : la bibliographie. Pour chaque appel rencontré dans le texte, on parcourt la biblio pour vérifier que la référence correspondante est bien présente. Et si la bibliographie est organisée par ordre alphabétique, les appels, eux, apparaissent dans un ordre aléatoire. On remonte donc sans cesse au début de la bibliographie, pour la redescendre à nouveau, en quête de l’entrée correspondant à l’appel repéré. Et on recommence…
De monc côté, je manipulais déjà, dans InDesign, les recherches par expressions régulières, dites “Grep”. À l’origine, le Grep est un programme UNIX de recherche de chaînes de caractères ; le nom provient de l’une des commandes d’un éditeur de texte d’UNIX, dont la syntaxe était :
:g/re/p
Cette commande signifiait : “rechercher Globalement les correspondances avec l’expression rationnelle (en anglais, Regular Expression), et imprimer (Print) les lignes dans lesquelles elle correspond” (source).
Dire tant de choses en si peu de lettres… C’est presque de la poésie.
Dans InDesign, Grep permet donc d’effectuer des recherches de manière plus souple, trouvant ainsi de larges panels d’occurrences variées. Par exemple, au lieu de chercher en deux fois « Linnaeus 1753 » d’abord, puis « Linnaeus 1757 », il suffit de chercher :
Linnaeus 175(3|7)
Pour trouver tous les « Linnaeus 175 » suivis d’un « 3 » OU d’un « 7 ». Forcément, ça rend la fonction de recherche plus efficace…
Dès lors, je me suis pris au jeu de trouver une expression Grep qui correspondait à tous les appels de références dans un texte donné… Et après pas mal de tâtonnements, j’ai trouvé ça :
(((du\s|Du\s|del\s|Del\s|van\s|Van\s|von\s|Von\s|De\s|de\s|der\s|Der\s|den\s|Den\s|mac|mc)+)?((\u(\l|-|’)+)+\s)((&\s)((du\s|Du\s|del\s|Del\s|van\s|Van\s|von\s|Von\s|De\s|de\s|der\s|Der\s|den\s|Den\s|mac|mc)+)?((\u(\l|-|’)+)+\s))?(et\sal.\s)?)(?<=)(((|[)?(((16|17|18|19|20)\d\d)((\l(-\l)?(,\s)?)+)?((?!\d))((,|\s?;)\s)?)+()|])?)
Cette expression permettait de trouver une bonne partie des occurrences correspondant à des appels de références pour ensuite, par exemple, les mettre facilement en couleur (et donc mieux les repérer). Cette requête permettait donc de trouver les appels plus facilement, mais cela ne résolvait pas mon problème pour autant :
Un autre programme, écrit par Peter Kahrel, intitulé « GREP Query Manager« , soit « gestionnaire de requêtes GREP » permet de manipuler des requêtes GREP écrites préalablement, et notamment de générer une liste des occurences, triées alphabétiquement et dédoublonnées… (le script est dispo ici).
Dès lors, il est devenu possible de générer une liste complète, triée et dédoublonnée de tous les appels présents dans un texte donné, d’imprimer cette liste et de la comparer à la bibliographie très simplement. L’opération de pointage a ainsi perdu tout son côté fastidieux, du fait que les deux listes sont parallèles (même tri alphabétique) et qu’il est très facile d’identifier les manques d’un côté, et les entrées bibliographiques non citées de l’autre.
Je dois le reconnaître, j’étais assez fier du résultat de mes expériences. Savourant dorénavant le plaisir de cette phase auparavant pénible, je me suis contenté de cette solution pendant un temps…
…et aux références les lier
Mais après quelques fascicules publiés et quelques centaines de références pointées, les limites de la procédure ont commencé à apparaître. Si elle n’était pas très compliquée à mettre en place – mes collègues ont donc pu l’utiliser sur leurs propres articles – le pointage se faisait toujours sur la version papier, et il fallait ensuite appliquer les corrections et compléter la bibliographie, avec l’aide de l’auteur, dans le fichier InDesign d’origine.
Entre-temps, j’avais découvert qu’InDesign permettait de manipuler les recherches Grep (voir plus haut) depuis de petits programmes écrits en javascript qu’on lance directement depuis l’interface du logiciel.
J’avais alors été confronté à une limite du système de rechercher/remplacer utilisant des expressions régulières, car il n’était pas possible d’effectuer de calculs sur le résultat de la requête. Il est très facile, par exemple, de rechercher une page citée dans le texte sous ce format : “p. 47”. Pour cela, on entre la requête :
p. 47
Imaginons, donc, que vous changiez la photo de la page 47 de place, par exemple pour la déplacer page 32, et que vous vouliez mettre à jour tous les appels à cette photo. Il suffirait de rechercher la chaîne ci-dessus et de la remplacer par :
p. 32
C’est le cas standart d’utilisation du rechercher/replacer dans n’importe quel logiciel.
Mais si vous insérez une page au début de votre document, et que vous souhaitez mettre à jour les appels en leur ajoutant donc “1” (les appels à la page 47 deviennent des appels à la page 48, etc.) le rechercher/replacer systématique ne suffit plus. Une étape de calcul est nécessaire pour parvenir à ce résultat, étape que seul un script va permettre d’effectuer.
Je disposais donc de tous les outils pour améliorer ma procédure de pointage des références ; j’ai donc écrit trois programmes, qui réalisaient les opérations suivantes :
- étape 1 (la plus facile) : un programme “lit” le texte et repère tous les appels à des références, en utilisant la requête Grep décrite plus haut (la grosse) ; les appels sont colorisés, avec une palette spécifique au programme (non utilisée dans le document) ; ils pourront ainsi être facilement repérés par la suite ;
- étape 2 (la plus tordue) : un autre programme “ »lit” la bibliographie, et transforme chaque entrée en référence courte (voir exemple ci-dessous) ; une balise portant le nom de la référence courte est ensuite déposée devant l’entrée de bibliographie correspondante ; par exemple, l’entrée de bibliographie :
O’Dogherty L., Carter E. S., Dumitrica P., Gorican Š., De Wever P., Bandini A. N., Baumgartner P. O. & Matsuoka A. 2009b. — Catalogue of Mesozoic radiolarian genera. Part 2: Jurassic-Cretaceous, in O’Dogherty L., Gorican Š. & De Wever P. (eds), Catalogue of Mesozoic radiolarian genera. Geodiversitas 31 (2): 271-356. https://doi.org/10.5252/g2009n2a4
Génère une référence courte de type :
O’Dogherty et al. 2009b
O’Dogherty est le premier auteur d’un article qui comporte plus de 2 auteurs, on utilise donc l’expression « et al. » pour créer la référence courte. Pour les articles à un seul auteur, la référence courte ressemble à “Pinson 2004”, et pour les articles à deux auteurs, “Merle & Pinson 2012”. C’est également sous ces différentes formes que les appels se présentent dans le texte.
À ce stade, on dispose donc d’une série de balises créées automatiquement et positionnées devant les entrées de bibliographies, et d’une série d’appels repérés automatiquement dans le texte. Il ne reste plus qu’à faire correspondre les deux…
étape 3 (la plus compliquée à mettre en place) : un dernier programme recherche les appels précédemment repérés, et pour chacun d’eux, parcourt la liste complète des balises ; si un appel correspond au nom d’une balise, un lien hypertexte est créé de l’appel vers la balise ; si aucune balise ne correspond, l’appel est surligné dans une couleur caractéristique, permettant d’extraire ensuite facilement une liste de références à demander à l’auteur.
À la fin de la procédure, les appels liés sont “éteints”. Il ne reste plus, d’un côté, que les appels surlignés (ceux dont l’entrée bibliographique est manquante), et une série de références vers lesquelles aucun lien n’a été créé (aucun appel vers ces références n’a été trouvé dans le texte, elles doivent donc être supprimées) :
Une dernière étape reste nécessaire pour parfaire le travail réalisé par l’ordinateur, qui ne fait que de 80% à 90% du travail de manière fiable (pas besoin de vérifier). Les 20% qui restent sont à corriger par l’éditeur ou l’éditrice, avec l’aide d’outils spécifiques. Néanmoins, le pointage des références se fait enfin de manière automatique. Ouf.
Cette fois, les limites de ce premier programme sont vite apparues, quand j’ai voulu le faire adopter par mes collègues du pôle Périodiques du Muséum. En effet, les trois programmes avaient été développés au fil de l’eau, et étaient, disons, un peu fragiles dans leur fonctionnement. Il fallait les lancer dans le bon ordre et vérifier auparavant que les styles et les couleurs utilisées existaient bien dans le document. Et surtout, il renvoyait des erreurs bien pourries.
Rien de tel pour décourager un utilisateur, que de devoir faire appel au service informatique (moi) pour comprendre le message d’erreur qu’un programme vient d’afficher à l’écran…
Mon programme était donc très fonctionnel, mais surtout sur mon propre ordinateur, et pour moi.
Enfin, ce script était limité : il ne repérait que les appels “simples” ; ainsi dans “Merle 2009, 2010a, b; Pinson 2012, 2014; Rouge-George 2018a, b”, il ne voyait que “Merle 2009; Pinson 2012; Rouge-George 2018a” ; les références implicites, c’est-à-dire non précédées d’un nom d’auteur (“Merle 2010a”, “Merle 2010b”, “Pinson 2014” et “Rouge-George 2018b”) étaient ignorés, forçant ensuite à les lier manuellement. Et comme dans le cas ci-dessus, la majorité des appels sont complexes, on se retrouve loin des 80/20 visés.
Il était donc encore possible d’améliorer le programme, adopté malgré tout par l’équipe des Publications scientifiques – après corrections des bugs et solide auto-formation – parce qu’ils/elles sont tous formidables, et que ça valait le coup quand même !
Mais cela a pris cette fois quelques années…
linkElements v1.0 (nom de code Whaou !)
Quelques années à écrire d’autres programmes, à préparer d’autres articles, à participer aux projets de sémantisation de la chaîne de production des périodiques aussi, qui se confrontait alors aux mêmes problématiques que moi (dont le fameux pointage des références…) ; quelques années aussi à accumuler des informations, des liens, des scripts venus d’ailleurs, jusqu’à ce que je découvre ça : https://scriptui.joonas.me/
Ce site web permet de construire des interfaces graphiques élaborées pour InDesign, très facilement. C’est une pépite d’ingéniosité accessible librement ! Et pour les mauvaises langues, les sources sont publiées sur GitHub (je les ai même forkées, au cas où elles disparaissent…)
Et là, le déclic !
Disposer d’un moyen de créer des interfaces sous InDesign va me permettre d’échanger avec les utilisateurs de mes programmes ; dès lors, terminés les messages absconcs et les débugages fastidieux ; finies les approximations de détection, inutile la création des styles et des couleurs. Je me prenais à rêver de l’outil idéal, la machine parfaite, celle qui pointe toutes mes références d’un simple clic…
Alors je m’y suis collé. Ça a quand même pris quelques dizaines d’heures de développement, vu que je manque un chouïa de méthode, et le produit fini est un peu obèse ; mais, pour paraphraser le compagnon d’une collègue qui a lu mon code : « Dans la vie, ya ceux qu’écrivent des scripts compréhensibles, et ya les autres » . Moi, visiblement, je fais partie des autres. Mais il a aussi ajouté « C’est pas parce qu’on comprend pas que ça marche pas« , et ça aussi, c’est bien vrai.
Donc, après quelques semaines de développement, j’ai pu annoncer la première version officielle de mon script de pointage de références, nommé « linkElements » (ben oui, c’est en anglais, je bosse avec des collègues européens aussi). L’interface permet de régler les options du programme et affiche le résultat des opérations au fur et à mesure de leur déroulement :
La détection des appels dans le texte a aussi été améliorée, afin de prendre en compte les appels complexes, réduisant d’autant l’étape manuelle de correction à la fin de la procédure (voir plus haut). Aujourd’hui, avec un article bien préparé, le taux de pointage automatique peut atteindre 90%, voire plus :
Mais une petite démonstration vaut mieux que de longs discours ; voici un GIF animé de démonstration du script linkElements, de la création des balises à la liaison appels/références, en passant par la détection des appels (en violet), le tout en une seule passe :
Je ne m’étends pas plus sur le fonctionnement de ce script en particulier (je le ferai dans un autre article), son intérêt ici résidait dans le fait que c’était le premier à être aussi finalisé, et que son adoption par mes collègues en a été, cette fois, d’autant plus facile.
Aujourd’hui, ma problématique consiste à pouvoir continuer d’utiliser ce programme – et bien d’autres – dans le cadre de la mise en place de la chaîne de production sémantique des périodiques du Muséum. Pas par principe, ou pour éviter une dépense gâchée, mais bien parce que j’aurais du mal à faire un bond en arrière tel que je serais de nouveau obligé de pointer des références… à la main !
Conclusion
J’ai découvert, dans ce que j’appellerait la programmation éditoriale, un moyen de réunir mes appétences pour la mise en place de mécanismes techniques complexes d’un côté, et pour le traitement de l’information de l’autre (celle contenue dans les articles scientifiques et qui mérite d’être disséminée le plus rapidement possible, la défense de ce qu’il reste de biodiversité en dépend, au moins en partie).
Alors quand je regrette de ne pas l’avoir découverte plus tôt, cette martingale, je me dis que j’aurais aussi bien pu passer à côté, et je suis content !
Depuis ce premier script de pointage de références, j’en ai bien sûr écrit d’autres, que je présenterai et publierai petit-à-petit dans le section Code de ce blog.
