Des papiers aux données : saisie informatisée, traitement automatisé et visualisation du fichier de commandes du Laboratoire de graphique de l’École des hautes études en sciences sociales

Par Kervegan, Paul, Hector. Étudiant de master 2 en « Technologies numériques appliquées à l’histoire » à l’École nationale des chartes et ancien stagiaire aux Archives nationales dans le cadre de l’ANR DesignSHS

Deux boîtes en métal et en plastique ; dedans, plusieurs centaines de fiches répertoriant une partie des commandes passées au Laboratoire de graphique¹ de l’École des Hautes Études en Sciences Sociales (EHESS). À première vue, les articles Arch. Nat. 20150774/22 et 20150774/23 semblent être des documents purement fonctionnels, qui décrivent entre 1000 et 1500 commandes passées au Laboratoire entre 1958 et 1987. La valeur de ces articles n’apparaît qu’après une analyse plus précise. Au-delà de son rôle fonctionnel, ce fichier de commandes retrace la vie d’un laboratoire précurseur de la visualisation de données, qui a modelé sur près de trente ans la conception de la cartographie et la manière dont l’information se lit.

Du Laboratoire de graphique de l’EHESS à l’ANR DesignSHS : sémiologie, graphisme et culture visuelle

Le laboratoire est créé en 1954 et disparaît en 2000² . C’est grâce aux historiens Lucien Febvre et Charles Morazé que le laboratoire est créé au sein de la VI^e section de l’École pratique des hautes études (EPHE). Lorsque la VI^e section de l’EPHE devient l’EHESS, le laboratoire passe sous la tutelle de cette nouvelle institution. C’est à cette occasion qu’il devient le « Laboratoire de graphique ». Dirigé par Jacques Bertin (de 1954 à 1984) puis par Serge Bonin (jusqu’en 1992), ce laboratoire défend une conception « complète », intellectuelle et esthétique, de la visualisation et de l’analyse de données. Cette conception, synthétisée par Jacques Bertin – figure tutélaire, voire étouffante, du laboratoire –, est théorisée dans la Sémiologie graphique qu’il publie en 1967. La graphique ne se limite pas à un médium : elle sert autant à produire des cartes imprimées que des « matrices ordonnables »³ et des logiciels⁴. La graphique est un système intellectuel complexe⁵, fait d’ensembles « de signes qui permet[tent] de transcrire des relations de différence, d’ordre ou de proportionnalité existant entre des données qualitatives ou quantitatives » (Bonin, 1998 : 18). Grâce à la sémiologie graphique, il n’y a pas besoin de lire une image et de la décrypter : tout doit être visible en un clin d’œil. Si cette méthode semble tomber en désuétude après les années 1990, elle participe à créer des bases théoriques solides à la représentation de données. Elle continue d’être influente aujourd’hui, alors que la visualisation est plus populaire que jamais (Johanna Drucker, 2020).

C’est dans ce contexte que débute, en 2021, l’ANR DesignSHS, dont l’objectif est de « développer une réflexion portant sur les cultures visuelles des sciences sociales et sur les pratiques émergentes du design graphique et de la datavisualisation⁶, tout en mobilisant les outils propres à ces champs dans une démarche globale de recherche-création » (DesignSHS, 2021). Pour faire ce retour au laboratoire de Bertin, travailler à partir des productions graphiques ne suffit pas : il faut également revenir aux activités du laboratoire, à son fonctionnement quotidien et aux formes de travail qui s’y sont développées. C’est dans ce but qu’a eu lieu, durant l’été 2021⁷, la saisie informatisée des articles 22 et 23 du versement 20150774 : le « fichier de commandes » du laboratoire, conservé par les Archives nationales, qui décrit la réalisation des différentes productions. Les commanditaires, le thème et le contexte de la commande y sont mentionnés, ainsi que les superviseur.euse.s et exécutant.e.s des commandes au sein du laboratoire. De même, les fiches décrivent les matériaux employés, les techniques mises en œuvre, la durée de réalisation et parfois même le coût d’exécution. Si toutes ces informations peuvent être présentes, le fichier de commandes est rarement aussi exhaustif : la quantité d’informations varie grandement d’une fiche à une autre, de même que la structure des fiches elles-mêmes. Le fichier de commandes étant lacunaire, l’analyse qui suit présente nécessairement des zones d’ombre ; de plus, cette analyse ne porte pas sur l’intégralité du fichier, mais seulement sur la partie qui en a déjà été retranscrite. Le fichier de commandes n’étant pas organisé de manière chronologique, l’analyse qui suit porte sur 667 commandes (sur un total compris entre 1100 et 1500 fiches) datant de 1958 à 1987, où les commandes passées par des revues sont sous-représentées (puisque les revues forment un corpus à part dans le fichier de commandes, qui n’a pas été totalement retranscrit).

Modéliser un fichier de commandes : des textes à la donnée

Avant de décrire la méthode et les résultats de cette mission, une question doit être posée : que veut dire « faire la saisie informatisée d’un fichier de commandes » ? Il ne s’agit pas « seulement » d’un transfert du papier vers l’ordinateur – même si ce transfert a représenté une grande part du travail. Faire la saisie informatisée, c’est passer de l’objet matériel au fichier « dématérialisé »⁸ ; c’est aussi passer du texte rédigé à la donnée — c’est fractionner l’original pour pouvoir l’exploiter. Il ne suffit donc pas de retranscrire le texte des fiches sur un fichier informatique. De plus, un document informatique n’est pas seulement un moyen de conserver des informations : des données structurées peuvent être exploitées, analysées et transformées.

Avant de faire la saisie, il a donc fallu analyser le fichier de commandes pour comprendre quelles d’informations sont fournies et comment elles sont structurées. Cette première analyse devait permettre d’extraire un modèle de données qui puisse être implémenté sous la forme d’un tableur ; chaque entrée de ce tableur servirait à décrire une commande. Une difficulté apparaît très vite à l’analyse des documents : le fichier de commandes a été enrichi pendant plus de trente ans. Les informations qu’il contient, l’organisation des fiches et leur degré de précision varient énormément au fil des années et en fonction de la personne chargée de remplir le fichier. Certaines fiches listent tou.t.e.s les exécutant.e.s, les étapes de réalisation et citent même des discussions, voire des différends avec le ou la commanditaire. D’autres, malheureusement, ne donnent que le sujet de la commande, sans même être datées.

La modélisation du fichier de commandes a été menée avec l’aide de Cécile Fabris, responsable du pôle Éducation/recherche des Archives nationales, et grâce aux conseils de Pauline Charbonnier et Florence Clavaud, du Lab des Archives nationales. Grâce à ce modèle, les données des commandes sont ordonnées en cinq sections. Les trois premières contiennent les informations figurant sur le fichier de commandes ; les sections quatre et cinq servent à enrichir le fichier d’informations supplémentaires.

• La première section est consacrée aux données « du côté du commanditaire » : son nom, le nom de la commande, la personne pour qui la commande est passée, le détail des différentes productions attendues et techniques qui seront mises en œuvre.

• Les données relatives à l’exécution de la commande, « du côté du laboratoire », font l’objet d’une seconde section. C’est là que sont décrits le nom du responsable du traitement de la commande, le nom des exécutant.e.s ainsi que le détail des différentes étapes de réalisation.

• Une troisième section décrit les dates de début et de fin d’exécution de la commande.

• La quatrième section sert à décrire les commandes à l’aide de listes de mots clés : pays, continent et période concernés par la commande, discipline, destination (article, thèse, monographie…) et type de commande (carte, graphiques, traitement de données…). Enfin, cette section sert aussi à indiquer le degré de précision des fiches.

• Une dernière section doit contenir des renvois vers les articles du fonds du Laboratoire de graphique conservés par les Archives nationales, afin de faire le lien entre les fiches de commandes et les productions auxquelles elles ont donné lieu.

Le parti pris a été de faire la modélisation la plus complète possible pour les fiches et de faire mention, si besoin, d’informations manquantes. Chaque commande dispose d’un identifiant unique qui permet de la situer dans l’ensemble du fichier.

Le principe de cette modélisation était de fractionner les fiches en données unitaires, hiérarchisées et aussi précises que possibles, afin de traduire le fonctionnement du laboratoire tout en rendant possible l’exploitation des données. L’objectif n’était pas de traduire la matérialité des deux articles. La description de l’état des fiches a donc été abandonnée ; de même le langage originel des fiches a été remplacé par des formes normalisées qui permettent de réduire l’ambiguïté.

La méthode de saisie et la modélisation ont été définies par deux autres principes. Premièrement, il fallait mettre en place une solution techniquement simple, légère et pérenne. Une implémentation technique en base de données relationnelle⁹ aurait pu permettre une meilleure structuration et une meilleure mise en lien des données ; cependant, c’est une solution relativement lourde d’un point de vue technique, qu’il faut apprendre à utiliser. Le modèle décrit ci-dessus a donc été implémenté sur un tableur. Afin de permettre sa pérennité technique, celui-ci est conservé dans des formats de fichier ouverts. Contrairement aux formats propriétaires, ceux-ci ne dépendent pas d’un seul acteur et ne risquent donc pas de devenir obsolètes si celui-ci en venait à mettre fin à leur développement. Pour que le fichier informatisé soit pérenne, il ne suffit pas que les informations qu’il contient soient accessibles. Elles doivent aussi être compréhensibles ; les fiches ont donc été décrites avec un vocabulaire contrôlé et documenté.

Deuxièmement, cette saisie informatique a lieu au tout début d’un projet financé pour quatre ans ; l’un des objectifs du projet est d’exploiter et de visualiser les données produites. Cela implique de penser le fichier informatique en fonction de ses usages futurs. Le problème, c’est qu’il est impossible de savoir comment le fichier sera utilisé ! Nous avons donc cherché à rendre les données les plus unitaires possibles. 31 colonnes – dérivées des cinq sections du modèle – ont été utilisées pour décrire les commandes ; certaines colonnes ont étés subdivisées à l’aide de « séparateurs », comme celle décrivant les étapes de réalisation de la commande. Cela permet d’accéder à chaque étape des commandes de façon unitaire. Dès lors il est possible d’automatiser l’analyse de l’exécution des commandes : combien d’étapes sont nécessaires, quelles étapes sont les plus souvent décrites dans les fichiers, par qui sont-elles mises en œuvre…

Et après ? Réconciliation des données, analyse et visualisation du fichier de commandes informatisé

La modélisation du fichier menée à son terme et la saisie effectuée, il devient possible de tirer parti du fichier de commandes. Avant tout, le fichier informatisé a été « nettoyé » avec OpenRefine, un outil open-source qui permet la réconciliation de données, c’est-à-dire la mise en lien et l’agrégation des données proches. Cette étape a permis de revenir aux principes établis pendant la phase de modélisation. Par exemple, les noms des différent.e.s membres du laboratoire ont été normalisés : les mêmes personnes ont pu y être nommées par leur prénom, leur nom de jeune fille, leur nom de mariage ou encore leurs initiales !

Pour faire des premières analyses statistiques du fichier de commandes, une interface en ligne de commande¹⁰ (CLI) a ensuite été programmée avec Python. Cet outil permet une « lecture distante » du fichier de commandes. Les fiches déjà saisies fournissent en moyenne 72 %¹¹ des informations modélisées dans le tableur (les colonnes sont remplies à 72%). L’information la moins souvent donnée par les fiches est le descriptif des différentes cartes et graphiques à réaliser pour une commande : sur 667 fiches entrées dans le tableur, 552 ne comportent pas d’informations sur cet aspect. Cela représente 83 % des fiches ! À l’inverse, c’est le nom du ou de la responsable de la commande (c’est-à-dire, un membre de l’institution passant commande chargé.e de suivre le déroulement de la commande) qui est le plus souvent mentionné par les fiches : cette information est présente sur 99 % d’entre elles. Les mêmes personnes sont très souvent mentionnées pour tous les types de fonction que peuvent occuper les commanditaires : la personne passant la commande, l’auteur.ice pour qui la commande est passée et le responsable de la commande sont les mêmes personnes dans 83 % des fiches. Le membre du laboratoire supervisant la réalisation d’une commande est identique à la personne exécutant la commande dans seulement 66,5 % des cas. À l’inverse, les commanditaires sont bien plus souvent nommé.e.s que les membres du laboratoire : seules 6 fiches ne donnent pas de nom de commanditaire, alors que 144 fiches ne nomment aucun.e membre du laboratoire. Pour finir, cet outil permet de voir à quel point les fiches détaillent l’exécution de commandes : en moyenne 2,5 étapes d’exécution sont décrites ; si beaucoup de commandes n’évoquent pas le processus de réalisation, la fiche la plus détaillée retrace à elle seule 12 étapes d’exécution différentes !

Ces différentes statistiques aident à mieux comprendre comment sont structurées les fiches, et quel rôle elles occupent au sein du laboratoire. En moyenne, les détails sur la réalisation d’une commande sont moins importants que le descriptif de la commande elle-même. Cependant, lorsque l’exécution d’une commande est décrite, cette description prend souvent plus d’importance que la description de la commande elle-même. En général, les fiches ont donc tendance à être des descriptifs de commandes, plutôt que des moyens de suivre le déroulement des travaux en cours. L’analyse du fichier confirme également que le modèle établi en début de saisie correspond aux documents traités. Plus généralement, cet outil montre l’utilité de suivre des principes rigoureux pendant la saisie : ils permettent la nomralisation le fichier, et donc la mise au point de méthodes automatisées d’analyse quantitative. Les données produites par cette application permettent pour finir de voir les apports de la programmation aux sciences humaines : il a été relativement facile d’automatiser l’analyse de 667 commandes, décrites sur un total de 31 colonnes ; cette analyse peut également être relancée une fois la saisie informatisée du fichier complétée, sans qu’il n’y ait besoin de modifier le CLI. Par ailleurs, l’outil peut très facilement être augmenté de nouvelles fonctionnalités, et donc permettre de nouvelles analyses.

Enfin, les données du fichier de commandes peuvent être visualisées en graphiques pour rendre l’information plus facilement lisible, comme l’a montré Louis Vignaud¹². En utilisant les logiciels ElasticSearch et Kibana ont servi à exploiter les données après les avoir traduites au format JSON, qui est plus manipulable qu’un tableur. Rendre les données manipulables permet de les traiter de plusieurs manières ; il est aussi possible de les croiser pour produire différents types de visualisations, sans pour autant avoir à modifier les données. En croisant le champ « Type de commande » avec la date d’exécution de la commande, il apparaît par exemple que les activités du laboratoire changent totalement pendant son existence. Pendant les années 1960, le laboratoire se consacre pour l’essentiel à la réalisation de cartes, ainsi que de quelques graphiques. Jusqu’à la fin des années 1960, les graphiques accaparent le laboratoire autant que les cartes ; les autres techniques restent minoritaires. À partir des années 1970, ces formats « traditionnels » sont supplantés par les matrices ordonnables et d’autres méthodes de visualisation propres au Laboratoire de graphique. Cette popularisation de nouvelles techniques correspond aux développements de la sémiologie graphique, théorisée par Bertin en 1967. Une recherche à facettes – par auteur.ice ou commanditaire, par exemple – permet d’étudier plus spécifiquement des parties du corpus, et donc de réaliser des analyses plus détaillées. Plusieurs filtres peuvent être combinés pour arriver à des résultats d’une grande précision : il est par exemple possible de rechercher les commandes réalisées sur une certaine période, pour un.e certain.e auteur.ice et avec une certaine technique. L’utilisation de logiciels comme Kibana et ElasticSearch est particulièrement intéressante d’un point de vue d’expérience utilisateur¹³ : le tableur, un format assez austère et rigide, peut être interrogé via un véritable moteur de recherche. Des données scientifiques peuvent être parcourues de la même manière que l’on fait une recherche sur internet. Cela permet une confluence de pratiques : la recherche scientifique peut être faite avec des méthodes accessibles à n’importe quel utilisateur ou utilisatrice d’internet.

Conclusion

Bien plus qu’une simple « saisie informatisée », le travail sur le fichier de commandes du Laboratoire de graphique de l’EHESS a donc permis un travail tout au long de la vie de la donnée, depuis sa modélisation jusqu’à l’analyse et la valorisation. Si les nouvelles technologies facilitent le traitement et la visualisation des données, il faut maintenir un regard critique : les logiciels déterminent les types de savoirs produits, et peuvent donc finir par contraindre et limiter la recherche scientifique (Masure, 2017 : 68-71, 93-98). Celle-ci ne peut pas seulement être pensée en termes d’expérience utilisateur. La qualité scientifique de l’information doit primer sur des questions de confort d’utilisation et de manipulation. C’est l’intérêt de faire le travail de saisie avec un format « simple » et facilement transformable, comme le tableur : il garde les informations intactes, sans pour autant contraindre les futures transformations et l’exploitation de celles-ci.

BIBLIOGRAPHIE

Archives nationales, Laboratoire de cartographie (Paris ; 1954-200). Notice de producteur FRAN_IR_058399. Disponible en ligne :

https://www.siv.archives-nationales.culture.gouv.fr/siv/rechercheconsultation/consultation/ir/consultationIR.action?irId=FRAN_IR_058399 (consulté le 13.02.2022).

Bachimont, B., « Préservation culturelle numérique », dans Teruggi, D. (dir.), Musique et technologie. Préserver, archiver, reproduire, Paris, INA, coll. « Portraits polychromes », 2013, p. 11-32, n° 21.

Bonin, S., « Les problèmes rencontrés dans l’utilisation d’une matrice ordonnable », L’espace géographique, n° 6/4, 1977, p. 218-232. Disponible en ligne : https://www.persee.fr/doc/spgeo_0046-2497_1977_num_6_4_1737 (consulté le 13.02.2022).

Bonin, S., « Le développement de la graphique de 1967 à 1997 », Comité Français de Cartograhie, n° 156, 1998, p. 17-25. Disponible en ligne : http://www.lecfc.fr/new/articles/156-article-4.pdf (consulté le 13.02.2022).

Campolo, A., « Signs and Sight: Jacques Bertin and the Visual Language of Structuralism », Grey Room, n° 78, 2020, p. 34–65.

Drucker J., 2020, Visualisation. L’interprétation modélisante, Paris, Éditions B42, coll. « Esthétique des données », 2020, 200 p.

DesignSHS, Site internet de l’ANR DesignSHS, 2021. Disponible en ligne : https://laboratoire-graphique.fr/ (consulté le 13.02.2022).

Masure, A., Design et humanités numériques, Paris, Éditions B42, coll. « Esthétique des données », 2017, 152 p.

Schijver, E., « Culture hacker et peur du WYSIWYG », Back-office, n°1, 2017, 144 p. Disponible en ligne : http://www.revue-backoffice.com/numeros/01-faire-avec/eric-schrijver-culture-hacker-peur-wysiwyg (consulté le 13.02.2022).

Wikipédia, Expérience utilisateur, 2021. Disponible en ligne : https://fr.wikipedia.org/wiki/Exp%C3%A9rience_utilisateur (consulté le 14.02.2022).

---

---