# Des structures de données à la structure du monde

Giulia Ferretti

► To cite this version:

Giulia Ferretti. Des structures de données à la structure du monde. Humanistica 2024, Association francophone des humanités numériques, May 2024, Meknès, Maroc. hal-04698373

HAL Id: hal-04698373

https://hal.science/hal-04698373v1

Submitted on 16 Sep 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Des structures de données à la structure du monde : rôle performatif et sémantique des APIs

## Giulia Ferretti

Université de Montréal

giulia.ferretti@umontreal.ca

## Résumé

Les structures de données organisent les connaissances en catégories distinctes et les rendent accessibles en ligne, contribuant ainsi à définir le réel. Visant une clarté absolue, les architectures de données sélectionnent et organisent les traits fondamentaux des objets qu'ils traitent. Les modèles qu'ils proposent contribuent donc à affirmer l'influence d'Internet sur notre façon de connaître et de penser le monde. Comment mettre en lumière la contribution des structures de données sur le sens des objets qu'elles représentent ? Comment favoriser une réflexion collective quant à leur influence sur la réalité qui nous entoure ?

En interrogeant deux APIs (*Application Programming Interfaces*), je montre comment les infrastructures techniques nous poussent à re définir les objets décrits par ces technologies et, en même temps, j'étudie les idées précon çues et les intérêts humains enregistrés dans les structures de données examinées.

## 1 Introduction

À une époque où nos choix et nos opinions sont souvent gouvernés par le traitement de big data (Chun, 2016), raisonner rigoureusement sur les stratégies culturelles et commerciales liées aux pro ducts et services qui nous sont proposés en ligne est une tâche de plus en plus difficile : l'analyse de ces services et les résultats qui suivent nos prompts ne révèlent pas les processus computationnels sous jcents, qui nous deviennent ainsi de plus en plus inaccessibles. Pourtant, ces processus ont une forte valeur sémantique et contribuent activement à la performativité des services web et à leur influence sur nos choix et nos opinions. L'étude des APIs (*Application Programming Interfaces*) web est une porte d'entrée intéressante, bien que partielle, vers l'observation de ces structures techniques et de la manière dont elles interagissent avec le contexte humain, culturel, politique, social et économique à partir duquel les services web eux-mêmes prennent

forme. Ce papier vise donc à expliciter le rôle per formatif et sémantique des APIs web.

## 2 Hypothèse de travail

Les APIs web garantissent l'accessibilité, l'in teropérabilité et le traitement à grande échelle de structures de données de toutes tailles (Neumann et al., 2021). Pour ce faire, elles organisent l'inf ormation dans des arborescences de catégories, généralement aux formats JSON ou XML, asso ciant une série de paramètres à une série de valeurs. L'accès à ces informations est possible grâce à la création de chemins logiques qui permettent aux ordinateurs de parcourir l'arborescence jusqu'à re trouver les paramètres recherchés. Pour ce faire, il est nécessaire de réaliser des requêtes particulières (en anglais *queries*) respectant les paramètres, les règles syntaxiques, les catégorisations et les asso ciations cognitives déterminées par les fournisseurs des APIs et par la structure du Réseau lui-même.

La rédaction d'une requête API dépend donc de la compréhension d'un système de pensée et d'un environnement informatique : c'est un acte à la fois technique et herméneutique (Marino, 2020). Pour que les requêtes réussissent, il est nécessaire d'ac cepter l'appropriation et l'adoption de pratiques dis cursives et techniques, donc l'implémentation d'un protocole (Snodgrass et Soon, 2019), lui-même dé terminé par les décisions des fournisseurs et par la structure protocolaire du Web (Galloway, 2004).

Si la structuration de tout protocole relève de l'établissement d'une dynamique relationnelle (Galloway, 2004), les fournisseurs d'APIs, en sé lectionnant et en rendant visibles les ressources et les paramètres qui les définissent, établissent le récit lié à cet établissement. Un récit qui, d'une part, montre l'intérêt et l'utilité de cette sélection de paramètres et, d'autre part, déséquilibre cette dynamique relationnelle en faveur des fournisseurs d'APIs : les paramètres déterminent les informa tions auxquelles on peut accéder, donc les opéra-
tions que l'on peut faire, celles que l'on ne peut pas faire, et les services web que l'on peut construire.

## 3 Deux cas d'étude : Google Books et Europeana

Prenons l'exemple de l'API Books v1 développée par Google Books<fnref n="1" /> et de la Search API proposée par le projet Europeana<fnref n="2" />. Elles sont toutes deux des implémentations du style architectural REST (Representational State Transfer), qui requiert l'identification d'une ou plusieurs entités abstraites (ou ressources) ayant des identifiants uniques, eux-mêmes détaillés par un ensemble de paramètres (ou représentations). Ces derniers fournissent ainsi une définition très concrète des ressources. Les APIs d'Europeana et de Google Books sont apparemment similaires parce qu'elles sont de nature extensive, conçues pour assimiler dans leur structure d'énormes quantités de données relatives à des objets culturels provenant de contextes totalement hétérogènes : les ressources de la Search API d'Europeana correspondent aux objets du partrimoine culturel (Cultural Heritage Objects) et celles de l'API Books correspondent aux volumes et aux collections (Bookshelves) liées aux comptes de chaque utilisateur-rice. Face à des objets aussi généraux, on pourrait s'attendre à deux APIs haulement standardisées et politiquement ou économiquement neutres. Cependant, cette objectivité est démentie dès de la requête la plus simple.

**Diversité linguistique.** Si la présence du paramètre *LangAware* permet à l'API d'Europeana d'afficher des traductions multilingues des valeurs les plus couramment recherchés, les paramètres de Google Books – à l'exception des titres – sont exprimés en anglais, ce qui garantit des structures JSON plus légères et rapidement parcourables. Privilégier l'exhaustivité et le multilinguisme à la rapidité et à la facilité de traitement des données est un choix à la fois technique et culturel, fondé sur des priorités tout aussi techniques, éthiques, politiques et économiques.

**Valeurs.** Si l'attention portée par Europeana à la qualité et à l'exhaustivité de ses données est

mise en avant par le paramètre completeness, Google Books montre sa volonté de s'adapter aux sensibilités des lecteurs en intégrant le paramètre *maturityRating* dans son API. Ces systèmes d'évaluation sont des implémentations techniques, mais ils définissent également ce qui est important pour Europeana et Google Books en matière de ressources culturelles. Ils portent un jugement de valeur sur les objets représentés par les deux API et peuvent influencer leur utilisation futures, car ils correspondent aux filtres des futures requêtes API. Cependant, ces évaluations sont essentiellement subjectives : d'une part, Google Books ne précise pas les critères de son système de notation et, d'autre part, le critère completeness d'Europeana dépend de l'adhésion des objets représentés par l'API au modèle de données élaboré par la même institution (Europeana Data Model). Ce modèle a lui-même été structuré sur la base d'une sélection restreinte de structures de données préexistantes et des analyses d'une équipe d'experts « du domaine des bibliothèques, des musées, des archives et des collections audiovisuelles »<fnref n="3" />, inévitablement placées dans un contexte historique et culturel. Il reflète donc une compréhension particulière des objets décrits par l'API et des informations nécessaires pour les définir.

**Catégorisation des ressources.** Les entrées précisant la nature des ressources archivées dans Google Books sont placées dans des listes de valeurs, correspondant à la clé JSON *categories*. Cette énumération est parfois incomplète, voire incorrecte, comme en témoigne notamment Nunberg 2011. En revanche, Europeana permet d'attribuer des tags à ses entités dans une API supplémentaire entièrement consacrée aux annotations, ce qui permet d'obtenir des étiquettes riches et structurées<fnref n="4" />. Ici, l'exigence de flexibilité et de rapidité de Google Books et le besoin d'exhaustivité d'Europeana émergent à nouveau.

**Références externes et internes.** Alors qu'Europeana considère obligatoires les propriétés indiquant la provenance institutionnelle des objets et des métadonnées insérées dans l'API (notamment edm: oliProvider, edm: IsShownAt ou edm: isShownBy), Google Books ne propose

<footnote n="1">1. La documentation de l'API Books est disponible sur ce lien page : https://developers.google.com/books/docs/v1/using?hl=fr. Dernière consultation : 3 mai 2024.</footnote>

<footnote n="2">2. La documentation de la Search API est disponible sur ce lien : https://pro.europeana.eu/page/search. Dernière consultation : 3 mai 2024.</footnote>

<footnote n="3">3. Voir l'Europeana Data Model for Cultural Heritage, 2023.</footnote>

<footnote n="4">4. La documentation de l'Annotation API d'Europeana est disponible sur ce lien : https://pro.europeana.eu/page/annotations. Dernière consultation : 24 juin 2024.</footnote>
pas forcement des ressources provenant de l'extérieur de son propre environnement. Le paramètre *canonicalVolumeLink*, par exemple, mène à la page Google Play contenant les versions ebook ou audiobook des volumes visés. D'une part, le modèle économique holistique de Google émerge une fois de plus, d'autre part, le système Europeana a besoin de légitimer l'information et son rôle dans le domaine scientifique en citant les institutions pertinentes. La référence à une telle institution n'est certainement pas indispensable, ni pour la subsistance technique de l'API, ni du point de vue de sa cohérence sémantique. Par cette imposition, Europeana propose et systématise son point de vue sur son rôle et sur le rôle des institutions dans le monde de la culture.

**Accessibilité.** De même, si Google Books facilite et accélère la familiarisation avec l'API, en laissant l'utilisation des fonctionnalités de base de son API libre de toute identification, Europeana exige une identification au moyen d'une clé API dès la première utilisation, et se réserve le pouvoir de révoquer les droits d'accès si ses données sont utilisées à des fins incompatibles avec les objets d'Europeana 5. Il s'agit ici de la nécessité pour Europeana de protéger son image de tous usages qui porte atteinte à son rôle institutionnel et d'autorité et, d'autre part, de la construction par Google d'un écosystème qui attire le plus grand nombre de personnes possible. Il s'ensuit, une fois de plus, que les logiciels et les sites créés à partir des APIs de Google Books et d'Europeana reflètent leurs modèles économiques et culturels.

D'une part, une réalisation aussi linéaire et fluide que possible est montrée et réalisée techniquement ; d'autre part, une architecture complexe faisant bon usage des métadonnées fournies par les bibliothèques et les institutions muséales est racontée et implémentée. Le modèle politique et économique des deux institutions émerge dans la structure technique des deux APIs.

# 4 La performativité de la syntaxe

Sur la base des deux exemples présentés, nous observons que les APIs incarnent des synthèses et des négociations entre différentes tendances, à la fois techniques et culturelles, syntaxiques et sémantiques, politiques, économiques et infrastructures. Les APIs web implémentent techniquement

ces tensions, les mettent en œuvre et les clarifient. Elles apparaissent comme des processus stabilisant la négociation entre différentes tendances et, d'autre part, comme des occasions matérielles promouvant et catalysant cette négociation.

Les APIs, en tant qu'interfaces et clefs de lecture sémantiquement orientées, ne garantissent pas totalement la transparence quant au fonctionnement des structures de données auxquelles elles donnent accès. Toutefois, elles amènent les fournisseurs à formaliser et à mettre en œuvre leurs intérêts et leurs objectifs dans des infrastructures techniques. L'influence des APIs sur l'utilisation de l'information qu'elles structurent découle donc de la manière dont des contraintes diverses se spécifient et s'influencent mutuellement dans des contextes matériels spécifiques, à la fois techniques et sociaux. Dans un processus hétérogène mais ontologiquement unifié, les APIs issues de croisements de pensées, de pratiques et de mécanismes engendrent des actions, des usages, des catégories conceptuelles, et des outils 6.

# Bibliographie

Bruno Bachimont. 2010. *Sens de la technique*, 1ère édition édition. Encre marine, Paris.

Karen Barad. 2007. *Meeting the Universe Halfway: Quantum Physics & the Entanglement of Matter & Meaning*, illustrated édition. Duke University Press, Durham.

Jacopo Bodini, Mauro Carbone, Gemma Serrano, et Graziano Lingua, éditeurs. 2020. *L'Avenir des écrans*. Mimesis, Sesto San Giovanni.

Wendy Hui Kyong Chun. 2008. On "Sourcery", or Code as Fetish. *Configurations*, 16(3):299–324.

Wendy Hui Kyong Chun. 2016. Big Data as Drama. *English Literary History*, 83(2):363–382.

Europeana. 2023. The Europeana Data Model for Cultural Heritage.

Alexander R. Galloway. 2004. *Protocol: How Control Exists after Decentralization*. MIT Press, Cambridge, Mass.

Alexander R. Galloway. 2006. Language Wants To Be Overlooked: On Software and Ideology. *Journal of Visual Culture*, 5(3):315–331.

N. Katherine Hayles. 1993. Virtual Bodies and Flickering Signifiers. *October*, 66:69–91.

Jun Li, Yingfei Xiong, Xuanzhe Liu, et Lu Zhang. 2013. How Does Web Service API Evolution Affect Clients? In *2013 IEEE 20th International Conference on Web Services*, pages 300–307.

<footnote n="5">5. Voir le conditions d'utilisation de la clé API d'Europeana sur la page dédiée. Dernière consultation : 14 mai 2023.</footnote>

<footnote n="6">6. Cette réflexion s'inscrit dans la continuité des théories du néo-matérialisme, développées notamment par Karen Barad 2007 et Marcello Vitali-Rosati 2020</footnote>
Lev Manovich. 2002. *The Language of New Media*. The MIT Press, Cambridge, Mass.

Deanna Marcum et Roger C. Schonfeld. 2021. *Along Came Google: A History of Library Digitization*. Princeton University Press.

Mark C. Marino. 2020. *Critical Code Studies*. The MIT Press, Cambridge Massachusetts.

Andy Neumann, Nuno Laranjeiro, et Jorge Bernardino. 2021. *An Analysis of Public REST Web Service APIs*. *IEEE Transactions on Services Computing*, 14(4):957–970.

Geoffrey Nunberg. 2011. *Le musée des erreurs de Google Books*. *Books*, 21.

Eric Snodgrass et Winnie Soon. 2019. *API Practices and Paradigms: Exploring the Protocological Parameters of APIs as Key Facilitators of Sociotechnical Forms of Exchange*. *First Monday*, 24(2).

Marcello Vitali-Rosati. 2020. *Pour une théorie de l'éditorialisation*. *Humanités numériques*, 1.