De la technogénie* appliquée aux données
*Technogénie : subst. fém. « Ingénierie appliquée à la conception de systèmes techniques d’entretien » (Termes nouv. Sc. Techn. 1983). Ortolang, CNRTL
Simon Talaga, moniteur-étudiant au service numérique de la recherche pour la saison 2022-2023, développeur web diplômé de MMI Bordeaux et masterant dans le cadre du master Philosophie co-habilité PSL-EHESS, revient sur un cas d’étude rencontré au cours de sa mission à l’INHA.
L’outil présenté dans cet article et qui permet un export amélioré des données d’une sélection de notices AGORHA vers un format de tableur bureautique, sera bientôt mis à disposition de tous les utilisateurs de la plateforme.
Le quotidien d’un moniteur-étudiant dans le Service numérique de la recherche (SNR) de l’INHA consiste principalement en des missions de « structuration », « d’harmonisation », ou encore « d’enrichissement » de données issues des nombreux programmes de recherche de l’établissement. Derrière ces termes quelque peu abstraits se cache une réalité aussi prosaïque qu’indispensable, qui se dévoile mieux dans les exigences de performance accompagnant l’exécution de celles-ci : il faut que « chaque chose soit à sa place », que les données soient « propres ». Il faut se débarrasser des « scories », réaliser de bons « alignements » ou encore « résorber » d’éventuels doublons… C’est dans les mêmes termes que l’on décrit le travail d’un homme ou d’une femme dits « de ménage », cette personne silencieuse, consciencieuse, et indispensable qui s’occupe chaque jour d’aménager les espaces, c’est-à-dire de les rendre habitables, afin que les affaires quotidiennes s’y déroulent, idéalement, sans friction dans une ambiance chaleureuse. En l’occurrence, c’est au service du « cyber » espace qui structure aujourd’hui les habitudes de travail intellectuel de la communauté ouverte des chercheurs et des chercheuses que notre travail se consacre. Ce préfixe provenant d’un mot grec signifiant le « gouvernail », il serait encore plus juste de dire que nous en sommes les gouvernant.e.s ! Mais « harmoniser » est un bien grand mot : nous ne faisons pas de Feng-Shui.
On entend parfois clamer que ces métiers devraient, comme tous les métiers « invisibilisés » dit-on, être « mis en lumière ». C’est juste. Mais il faut se souvenir que bien souvent, l’invisible est justement l’objet de leur visée. Le terme plus général de « curation », que les data scientists emploient pour qualifier toute activité de production, validation, ou enrichissement de données structurées, recèle cette facette sémantique dans son cœur étymologique. Il vient de la curatio, la cure, dont on dit parfois que l’objectif est d’atteindre un certain silence des organes. Et dans ce grand panoptique qu’est notre monde numérique, qui veut tout voir, maximiser la « visibilité » en toute « transparence », nos métiers qui en constituent le socle nous rappellent peut-être la positivité et la valeur propre de l’invisible. Mais viser l’invisible, cela demande, paradoxalement, une faculté d’observation à l’affût ! Seule une perception aiguisée est à même de juger de ce qui est trop saillant. Il faut savoir reconnaître la petite virgule qui « fait tache » là où tel format bibliographique préconisait l’usage d’une autre ponctuation, comme l’on remarquerait l’auréole ténue imprimée par une goutte de thé sur le guéridon.
Certes, la métaphore a ses limites : les impuretés numériques ont moins tendance à resurgir que leurs contreparties matérielles. Le nettoyage a une fin : il peut, en droit sinon en fait, être définitivement achevé, lui. Devait-il être repris, ce serait lorsque le modèle de données, standard de structuration et donc critère de propreté serait lui-même devenu poussiéreux ! Peut-être est-ce cela même, la perspective d’ôter enfin au nettoyage sa dimension structurelle de répétition, perçue comme aliénante, qui ferait tout l’attrait de cette occupation. Un beau jour, au fur et à mesure de mes tâches, entre l’épluchage de catalogues de vente en quête des bonnes dimensions des œuvres d’une collection mise aux enchères, et le brossage d’une masse de liens pour les faire pointer dans la bonne direction, on me confia celle qui s’avèrera être la racine d’une innovation.
Une extension hypertélique* pour dépasser le « travail du clic »
*Hypertélie : subst. fém. « Terme de biologie emprunté par le philosophe des techniques Gilbert Simondon pour désigner l’évolution d’une lignée d’outils vers un fonctionnement sur-adapté à une fonction précise et à un milieu donné. »
AGORHA cachait dans ses recoins une fonctionnalité problématique : son export d’une sélection de « notices » agrégée par l’utilisateur au format CSV (comma separated values). Une notice est un terme de documentaliste pour désigner ce que les étudiants nomment d’ordinaire des « fiches » : des documents plus ou moins courts recensant une somme d’informations à propos d’une référence bibliographique (telles que les auteurs, le titre, la date de parution, … jusqu’à la lisibilité de l’écriture d’un manuscrit !). Une des originalités d’AGORHA consiste à avoir étendu cette notion à quatre autres entités pertinentes dans le contexte de l’histoire de l’art : les œuvres, les personnes, les collections, et surtout les événements.
D’un point de vue technique, les données exportées étaient de qualité correcte. Mais d’un point de vue utilisateur, le format de présentation rebutait à l’unanimité par sa technicité même. Cela entravait donc fortement l’exigence d’aisance à la réutilisation (pour créer, par exemple, des data visualisations), critère pourtant de prime importance dans toute politique d’ouverture des données (open data), conformément aux principes FAIR (Facile à trouver, Accessible, Interopérable, Réutilisable). Tout ingénieur ou chercheur qui rencontrait un jour le besoin d’accéder à une vue d’ensemble de plusieurs notices à la fois gaspillait ainsi de longues demi-heures dans sa journée de travail à cuisiner ces exports selon sa propre recette pour les rendre plus digestes, sans n’être jamais pleinement satisfait du résultat. L’« éclatement de colonnes » était ainsi devenu l’un de ces termes institués normalisant ce qui n’était pourtant que le prototype de la tâche rébarbative et superflue dont tout le monde se passerait volontiers.
Lorsqu’un jour l’équipe me délégua cette besogne, un plan m’apparût ..! Le plan d’un lavomatique numérique, entièrement sur-mesure ! Inspiré, croyais-je, par Ada Lovelace en personne ! À moins que je ne me sois simplement souvenu d’une remarque de Jean-Christophe Carius en réunion de service. Ayant développé une collection d’outils internes baptisée AGORHA+, celui-ci suggérait d’acculturer l’équipe à une posture réflexive sur ses gestes, ou plutôt ses clics habituels, de manière à révéler les opportunités d’automatisation ad hoc qui lui faciliteraient la vie. Projet résolument hypertélique. Me souvenant aussitôt, dans le même élan, d’une théorie sur l’évolution des techniques relayée par Manuel Charpy d’InVisu qui spéculait que les améliorations d’une lignée d’outils tendaient à faire passer, par degrés, leurs usagers « de la sueur à la surveillance », le sens de cette mission transcendante se mit alors à résonner en moi : léguer à mes successeurs un moyen de remplir leur office sans efforts pour qu’ils se consacrent sereinement à leurs études, que dis-je, un moyen de réaliser plus pleinement leur véritable « être-moniteur-étudiant » : faire du monitoring !
Le plan
Les spécifications
- Le cœur de fonctionnalité : le nettoyage en trois phases : prélavage, lavage, essorage !
En guise de prélavage, la suppression de balises superflues et la distinction entre les guillemets de la spécification CSV et les guillemets du texte. Pour le lavage, restructuration complète des données, parsing (analyse, interprétation et traduction) en tableau d’objets JSON, puis renommage de la nomenclature technique.
Enfin, en guise d’essorage, la suppression des colonnes vides et la filtration des champs pertinents, ce qui réduit grandement la taille du tableau de données, permet de mieux s’y repérer et facilite la comparaison de ses entrées.
La filtration exclura notamment les champs « machine », et ne gardera, pour les champs codant des dates complexes, qu’un unique champ « synthétique » qui les résume (ex : « après -399 av. J.-C. ») aplanissant la granularité de leur mémorisation dans AGORHA. Dans l’idéal, elle sera paramétrable, puisque c’est la fonctionnalité la plus sensible au contexte d’utilisation de l’outil.
- Un système de pagination.
Les sélections de notices pouvant contenir des milliers d’entrées, et chaque entrée pouvant contenir plusieurs milliers de colonnes, le nombre d’éléments que l’interface utilisateur devrait être capable de gérer relève de l’ordre du million. Cette charge étant très difficile à traiter par le navigateur, il faudra donc mettre en place un système de pagination efficace pour éviter que la page web s’écroule sous le poids des données.
- Un système de notification de l’avancement du traitement en temps réel
Donner une nouvelle forme à autant de données nécessite des calculs importants. Même si le programme s’achève plus vite que celui d’un lavomatique classique (et que le serveur chauffe à plus de 40°C), il n’en reste pas moins que des utilisateurs impatients, mis face à une « boîte noire qui tourne » pourraient être tentés de rafraîchir la page durant un long traitement dont ils ne voient pas le bout. J’ai voulu que ce système prenne la forme d’une console : certes, il y aura toujours une « boîte noire » au milieu de la page, mais au moins du texte rassurant s’y affichera à intervalles réguliers ! Pour mettre en place cette fonctionnalité, il faut cependant compter sur un protocole de transfert de données synchrone entre le client et le serveur, que fournissent des technologies de type WebSocket.
- Un service d’export en feuille Excel
Les feuilles de calcul Excel constituent un standard bien ancré dans la pratiques des données des chercheurs, proposant de puissantes techniques d’analyse sans nécessiter de connaissances trop pointues en algorithmie ou en statistiques. C’est donc le format de sortie idéal pour que l’application soit réellement à leur service, se fondant avec leurs habitudes. Il faudra profiter au maximum des possibilités supplémentaires que ce format autorise par rapport au CSV (fusion de cellules, colorisation du texte, …) pour que le fichier, dès l’ouverture, permette une navigation optimale et sans coutures.
Quelques détails sur l’implémentation

Bien que mon plan ne comprenait aucun détail particulier concernant sa mise en œuvre, j’ai fait le choix d’utiliser le framework Node.js, une solution permettant l’exécution de code JavaScript par le serveur web (historiquement, le code JavaScript n’était destiné qu’à être interprété par le navigateur des visiteurs d’un site, aussi appelé le « client »), pour plusieurs raisons :
- L’utilisation d’un langage unifié à travers toutes les strates de l’application. Ce choix se justifie par l’échange de données au format JSON, qui est nativement supporté par JavaScript et dont la syntaxe est très facile à prendre en main, lors des appels à des API externes ainsi qu’entre toutes ses composantes spécialisées.
- Sa communauté très active, qui développe et maintient de très nombreux packages (bibliothèques logicielles ou “modules”) accessibles facilement via le gestionnaire de paquets
npm
- Enfin, une envie personnelle de longue date d’expérimenter avec cet écosystème, d’en mesurer la richesse.
Il a fallu notamment réaliser un mapping efficace de la nomenclature technique des champs vers leur label préconisé. Or, tous types de notices confondus, le nombre de champs à traduire s’élève à plus d’un millier ! De quoi se demander si l’on ne devrait pas faire machine arrière et se remettre à « éclater des colonnes » docilement… Fort heureusement, toutes ces informations existaient déjà ! Elles étaient contenues dans le métamodèle d’AGORHA. Il m’a suffit simplement d’écrire quelques requêtes avec JSONPath pour extraire de ce précieux gisement ces informations clés (qui s’y cachaient à différentes « couches » ou niveaux d’imbrication) puis de les grouper par type de notices dans un nouveau fichier JSON. Grâce à cela, j’avais l’outil de travail le plus simple à ma disposition : une table de correspondance !
Le code source complet de l’application sera bientôt disponible en accès ouvert sur le Gitlab de l’INHA. Les sélections de notices étant publiques, toute personne intéressée pourra donc s’en emparer, et si besoin, l’améliorer.
Démonstration de l’interface

À peine inventé, déjà « disrupté » ?
Le 7 juillet 2023, les souscripteurs d’un abonnement à ChatGPT, le prototype d’agent conversationnel utilisant l’intelligence artificielle produit par OpenAI, se sont vus ouvrir l’accès à une fonctionnalité dont l’impact s’annonce considérable : l’« interpréteur de code ». Ce dernier autorise une version remaniée du grand modèle de langage GPT-4 à s’atteler aux requêtes que lui soumet son interlocuteur en écrivant, puis en exécutant du code Python dans un environnement « bac à sable » dédié et sécurisé (Jupyter Notebook). Le résultat obtenu est ensuite réinjecté dans le « fil de raisonnement » produit par le modèle, ce qui permet à sa réponse d’être rythmée de phases scrupuleusement « analytiques ». Il devient ainsi non seulement capable d’obtenir des résultats plus fiables et déterministes pour certains problèmes qui tendaient jusqu’ici à le mettre en échec, mais étend au passage considérablement le champ de ses possibilités. Le voilà à présent capable de créer des graphiques et des cartes à la volée, promettant d’impacter imminemment le métier de data scientist, parmi bien d’autres.
Qu’en est-il pour les moniteur-étudiants, voire les ingénieurs documentaires ? Serait-il possible que cet « interpréteur de code » ne soit qu’à quelques spécifications bien formulées de pouvoir résoudre le cœur de la problématique qui m’a tant occupé ? En informatique, il existe une interchangeabilité entre les « programmes » et les « données ». Exécuter un programme consiste classiquement à écrire son nom dans une invite de commande (command prompt), à quoi l’on ajoute une série de données en entrée (les « arguments »). Mais le programme lui-même peut être considéré comme un argument en entrée pour le « compilateur » ou « l’interpréteur de code » qui le fait fonctionner. Mon programme pourrait-il aujourd’hui se condenser en une poignée de caractères bien choisis en entrée de ce nouveau modèle de langage, qui serait alors capable de produire un fichier CSV correctement nettoyé ? Existerait-il donc à portée de main une reductio ad promptum de ce travail ?
Il fallait que j’en aie le cœur net. Et quel meilleur moyen que de lui confier l’humble mission d’« éclater et renommer des colonnes » ? J’ai donc ainsi passé quelques heures à prendre mes marques avec ce nouvel outil, à reformuler itérativement mes demandes en fonction des réponses qu’il me proposait. Ses demi-solutions étaient au départ bien décevantes : je me rendais compte alors que c’est moi qui n’étais pas assez clair ! Logé une petite heure dans cette spirale vertueuse, j’aboutis finalement à une version « optimale » de 145 mots, 777 caractères. « Optimale », car c’est celle qui résout effectivement la tâche à partir d’une conversation neuve et sans répliques intermédiaires. La « générativité » serait-elle l’un des critères de la clarté, voire de l’élégance d’une explication ? Ce dont je suis du moins certain, c’est que j’aurais difficilement été capable de résumer le fonctionnement de mon propre algorithme aussi succinctement sans ce simulacre de dialogue où je tenais le rôle d’une gouvernante stricte et sévère rouspétant contre le travail bâclé d’un nouveau membre de son personnel domestique !

L’organisation de la réponse en sections fournit un moyen de dévoiler en un clic quelques extraits du code produit, ainsi que les résultats intermédiaires obtenus après leur exécution. Ce faisant, elles permettent de superviser la stratégie explorée, et si besoin, de relancer le modèle ou de réutiliser le code sur notre propre machine. De plus, en allégeant ainsi l’interface textuelle, l’utilisateur risque moins de perdre de vue la progression logique. L’ultime ligne, quant à elle, est un lien vers le fichier de sortie de l’ensemble du processus, mis à disposition dans un espace de stockage temporaire. J’ai cliqué. Je crois que je m’y attendais, tout compte fait. Le fichier était impeccable.


Certes, mon application initiale est plus rapide. Certes, son interface est plus conviviale. Certes, ses fonctionnalités sont plus riches. Certes, elle ne contient aucune part stochastique, et garantie donc de réussir à tous les coups. Elle fonctionne depuis n’importe quel poste de travail, sans nécessiter aucune connexion internet. Les traitements qu’elle effectue étant une routine du Service numérique de la recherche, susceptibles d’être effectués par une multitude d’agents différents, ces caractéristiques représentent assurément un avantage.
Mais pour des problématiques ponctuelles ? Pour des traitements encore plus hypertéliques, pour lesquels il serait peu avantageux de mandater un développeur, prestataire ou en interne, prêt à passer des jours à programmer un logiciel dédié via les méthodes traditionnelles ? Si ma fonctionnalité centrale s’est vue si vite recréée, dans une version, je présume, informatiquement efficiente (je confesse ne pas avoir audité le code, mes compétences en langage Python laissant à désirer), rien n’empêcherait de répéter l’opération avec les autres modules, puis de se contenter de connecter entre elles ces petites « boites noires ».
Pour nos humbles métiers, où les compétences en programmation peinent à se répandre et où les tâches répétitives face à l’écran, bien que monnaie courante, se laissent difficilement subsumer, ces modèles ont des airs de panacée. Ils semblent promettre de convertir, tous ceux qui parmi nous prennent le temps d’apprendre à les manier, en professionnels de la technogénie des données. Est-ce à dire que les ingénieurs documentaires ont vocation à évoluer, aussitôt que faire se peut, en « ingénieurs du prompt » (prompt engineer) qui plus est ? Est-ce à dire que parmi le « patrimoine intellectuel » de leurs services figurera à l’avenir quelque base de donnée associant une liste de problèmes rencontrés à une liste de prompts collaborativement construite ? Au regard de ces résultats si prometteurs, lors même que ces technologies n’en sont qu’à leurs balbutiements et que leur dynamisme est grisant, je ne pense pas prendre de risques démesurés en répondant par l’affirmative.