CAIRN.INFO : Matières à réflexion
linkThis article is available in English on Cairn International

1Le phénomène de l’open data ne constitue plus une nouveauté aujourd’hui. Pour de nombreuses administrations et entreprises publiques, l’ouverture de données est désormais systématisée à l’aide de plateformes numériques dont la gestion constitue un projet à part entier. Avec un recul de dix ans, les premiers bilans confirment qu’une nouvelle dynamique s’est durablement installée autour de la production, de la publication et de la réutilisation des données ouvertes (Cardon, 2019). Mais cette dynamique a fait également apparaître une série de nouvelles questions qui sont loin d’être résolues. Les acteurs doivent toujours articuler une pluralité de prescriptions pour ouvrir leurs données. L’open data apparaît en effet à partir de 2010, simultanément dans différents mondes sociaux lui associant chacun une signification particulière. Intimement lié à l’histoire de l’informatique, l’open data est d’abord défini à travers l’application des principes juridiques des logiciels libres à la publication de bases de données. Après le mouvement de l’open access militant pour la diffusion libre des connaissances dans le domaine scientifique [2], l’open data est défini ensuite par le courant de l’open government initié dans le champ politique, comme une application des principes de transparence dans la gouvernance démocratique aux États-Unis [3]. Ces principes sont enfin accompagnés par une série de critères techniques [4] proposés par le World Wide Web Consortium, pour définir le degré d’ouverture des données en fonction de leur capacité à être traitées automatiquement par des logiciels du web sémantique. Du domaine scientifique aux mondes informatiques, en passant par le champ politique, l’open data fait ainsi l’objet d’une pluralité de définitions selon les perspectives des mondes dans lesquels il apparaît. Certaines caractéristiques qui lui sont attribuées dans un monde sont reprises dans un autre, quand d’autres critères s’y voient, à l’inverse, occultées.

2Qu’il soit dans le but d’une « démocratisation » de l’accès aux connaissances, d’une « libération » des données publiques ou d’une amélioration de l’interopérabilité technique des données du web, l’open data est cependant formulé à l’égard des organisations comme une revendication commune et unifiée. Mais l’ouverture de données par les organisations de plus en plus hétérogènes et éloignées des mondes numériques soulève des enjeux de coopération dont la singularité se définit pour chacune dans le contexte spécifique de la production de leurs données. En effet, un des principaux enseignements tirés de la littérature portant sur l’open data consiste dans le fait que les données ne sont jamais ouvertes à l’état « brut », telles qu’elles sont produites au sein des organisations. Ce constat initialement développé dans le domaine de l’activité scientifique, où la donnée brute est qualifiée d’« oxymore » (Bowker, 2000 ; Gitelman, 2013), est tout aussi valable dans le monde des organisations. Avant d’être publiées, les données font l’objet d’un traitement particulier qui consiste à les nettoyer et à les contextualiser pour les rendre cohérentes et, surtout, compréhensibles par des tiers (Courmont, 2018 ; Denis et Goëta, 2017). Les premiers travaux réalisés sur le processus d’ouverture des données publiques en France attirent ainsi l’attention sur ce travail de coulisse qui consiste à « brutifier » les bases de données et à « invisibiliser » les conditions de leur fabrication (Denis et Goëta, 2016). Mais qu’en est-il du travail réalisé sur les bases de données, une fois que celles-ci sont publiées ?

3Par ailleurs, ces travaux attirent l’attention sur les dispositifs d’accompagnement qui permettent aux producteurs de données de cadrer leur réutilisation par des publics spécialisés (Dymytrova et Paquienséguy, 2017 ; Goëta, 2016). Si la contextualisation des données est une étape indispensable, ce cadrage nécessite aussi de constituer des espaces d’échange pour produire des définitions plus ou moins partagées entre des acteurs variés, non seulement avec les réutilisateurs des données, mais aussi tout un ensemble d’acteurs participant à la constitution de réseaux sociotechniques dans lesquels s’insèrent et circulent ces données (e.g. autres opérateurs, régulateurs du domaine des transports, usagers, etc.). Cette nécessité est d’autant plus forte au moment de l’ouverture des premiers jeux de données dans un nouveau domaine, au sein d’un écosystème d’acteurs établi qu’elle vient ainsi déstabiliser. Comment ces acteurs arrivent-ils à se coordonner autour de ce nouvel objet dont les définitions ne sont ni partagées ni encore stabilisées ?

La réutilisation des données et les enjeux de coopération : une immersion au sein de l’Open Railway Hackathon (ORH)

4Ces enjeux de coopération se traduisent souvent par la mise en place d’une plateforme numérique qui offre la possibilité de publier des données et d’échanger avec les réutilisateurs, afin d’accompagner les usages spécifiques qui peuvent en être faits dans des contextes variés. Si les données sont a priori publiées pour permettre une pluralité d’usages tels que des analyses pour les journalistes, des services pour les entreprises ou de la transparence pour les citoyens (Mabi, 2015), certaines de ces visées peuvent être encouragées par les producteurs de données. Un dispositif particulièrement prisé est celui des hackathons qui, portant sur une activité de programmation informatique, encouragent la réutilisation de ces données pour développer de nouvelles applications destinées aux usagers. Mot-valise entre hack et marathon, le terme est utilisé en référence aux rassemblements d’informaticiens et de passionnés qui s’auto-organisent, souvent sur plusieurs jours consécutifs, autour des activités de conception, de bidouillage et de hack informatique (Briscoe et Mulligan, 2014). Dans sa forme d’origine, ce dispositif renvoie ainsi à un univers de pratique technicisé : au sein d’ateliers, les participants coopèrent pour relever un défi ou résoudre un problème de nature bien souvent technique, pour développer des solutions et des outils partagés. Inscrivant la recherche de modes d’action et la production de techniques innovantes dans le domaine des communs, le hackathon est repris dans l’accompagnement de l’ouverture de données publiques (Goëta, 2013 ; Marquet, 2016) où il permet d’accéder à la fois au traitement des données ouvertes et à la dimension coopérative de ces activités dont le sens est produit conjointement par les producteurs et les réutilisateurs de ces données.

5Cet article propose de développer cette réflexion sur le traitement coopératif des données ouvertes en observant le cas de l’Open Railway Hackathon (ORH) qui est organisé en 2012 par un opérateur de transport ferroviaire européen, RailWay Company (RWC), autour des situations de perturbation [5]. La particularité de l’ORH est qu’il est organisé en interne, à destination des salariés de RWC qui sont invités à développer de nouveaux services à partir d’un échantillon de données ouvertes à cette occasion. Aux profils variés, une vingtaine de salariés provenant de différentes branches d’activité s’inscrivent à cet événement qui est présenté comme une nouvelle démarche d’innovation participative au sein de RWC. Ce groupe est composé de développeurs, de concepteurs de technologies d’information et de techniciens venant de différents départements des systèmes d’informations (SI), mais aussi de designers, d’analystes de supports commerciaux et même de quelques agents travaillant sur les quais des trains. La participation de ces salariés est avant tout motivée par la curiosité et la volonté de résoudre des problèmes récurrents auxquels ils sont confrontés au cours de leur travail quotidien, dans la gestion de situations perturbées. Au regard de l’hétérogénéité des profils, les organisateurs invitent ainsi un collectif de mentors composé d’une douzaine d’entrepreneurs et de hackers militants du mouvement de l’open data, pour les accompagner dans des domaines de compétences variés (e.g. cartographie, programmation, conception d’interfaces, etc.). L’ORH mobilise enfin de nombreux acteurs associés aux fonctions de communication et de marketing, ainsi que des cadres dirigeants de l’entreprise qui viennent explorer les potentialités de l’open data dans le développement de nouveaux services aux usagers.

6L’ORH se présente ainsi comme une configuration originale qui met les salariés de RWC dans un contexte d’activité dont ils ne maîtrisent pas nécessairement les principes d’organisation. Il met également les acteurs spécialisés dans l’open data face aux problématiques spécifiques d’un opérateur de transport ferroviaire. Si cette configuration de rencontre originale a bien une incidence sur le déroulement de l’ORH, nous en rendrons compte ici principalement du point de vue des activités réalisées autour des données [6].

Le développement d’applications comme « travail d’équipement » des données ouvertes : une ethnographie de l’activité technique

7Ce cas particulier, nous proposons de l’étudier au croisement de deux approches théoriques qui s’inscrivent dans le courant des Sciences & Technology Studies (STS). Une approche écologique des mondes sociaux qui est attentive à la diversité des perspectives autour des objets d’innovation (Star et Griesemer, 1989) permet de rendre compte des différentes définitions que les participants produisent conjointement au sein du hackathon. C’est ainsi que nous proposons notamment de mettre en évidence la manière dont le traitement des données est organisé en lien avec la perspective singulière que chacun des acteurs, producteurs et réutilisateurs développe autour des objectifs et de l’intérêt de ces données (Cefaï, 2015 ; Shibutani, 1955). Nous proposons ensuite de combiner cette approche avec une ethnographie de l’activité technique, attentive à la dimension matérielle et située des coopérations, montrant que la production de définitions partagées autour des données ouvertes ne repose pas seulement sur la perspective des groupes d’acteurs ni sur l’expression d’une normativité morale, mais aussi sur un univers de pratique spécifique qui devient accessible uniquement par l’observation des activités concrètes de travail.

8Ces deux approches, nous proposons de les articuler à travers une description des données ouvertes sur lesquelles portent les activités et qui permettent, malgré la diversité des acteurs engagés, d’organiser et de maintenir leur coopération au sein des équipes de l’ORH. C’est notamment autour des données ouvertes que celles-ci construisent une vision commune et coordonnent les efforts au sein d’un même projet. À cet égard, les données rappellent fortement les « objets intermédiaires » (Vinck, 1999) dont l’observation permet d’accéder aux processus de médiation et de traduction à travers lesquels ces acteurs réussissent à coopérer autour du développement d’applications de mobilité [7]. Dans le cas des hackathons, cette notion est utile pour décrire les coopérations qui se développent au sein des équipes ; mais elle permet également de saisir le réseau de relations plus large dans lequel ces activités s’inscrivent (e.g. producteurs de données, émetteurs de normes techniques, cadres dirigeants de l’entreprise, etc.). C’est ainsi, à travers une analyse des données comme objets intermédiaires que nous allons décrire les activités comme un travail d’équipement, c’est-à-dire une « activité collective qui consiste à s’accorder sur les éléments qu’il convient d’ajouter aux objets intermédiaires afin qu’ils s’inscrivent dans un espace d’échange entre acteurs plus ou moins hétérogènes » (Vinck, 2006, p. 66). Nous allons décrire ce travail en observant au plus proche la manière dont les participants dotent progressivement les données ouvertes de nouvelles propriétés pour les relier aux différents espaces de circulation des infrastructures informationnelles propres au domaine de la mobilité (Star et Ruhleder, 2010).

9En nous référant aux caractéristiques des objets intermédiaires qui agissent comme des marqueurs sociaux et temporels dans le processus de conception de nouveaux objets (Peters et al., 2010 ; Vinck, 2009), nous proposons de distinguer trois états des données ouvertes dont chacun relie des réseaux d’acteurs et mobilise des perspectives différentes : l’état initial des données, telles qu’elles sont publiées, l’état « combiné », telles qu’elles sont croisées entre elles, et l’état « intégré », telles qu’elles servent de ressources au sein d’une application produisant de nouvelles données. Nous proposons ainsi de décrire l’activité autour de ces trois états des données ouvertes, correspondant chacun à une phase distincte du développement d’applications (i.e. exploration des données ouvertes, croisement de bases de données et production d’interfaces), ainsi qu’à une manière spécifique de définir le caractère « ouvert » des données (i.e. selon la disponibilité, l’interopérabilité ou l’accessibilité). Pour chacune de ces phases, nous décrirons d’abord la structure commune des activités, composée par les ressources et les contraintes partagées du travail de développement d’applications. Nous rendrons ensuite compte des stratégies que les équipes développent dans le contexte spécifique de leur projet. À l’issue de cette analyse, nous verrons que l’originalité de ce hackathon réside moins dans la création d’innovations que dans la production de définitions plus ou moins partagées autour des données ouvertes qui se voient ainsi de plus en plus équipées pour agir à la frontière de mondes sociaux dont elles aident à coordonner les efforts autour de l’ouverture de nouvelles données (Vinck, 2009).

L’exploration des données et la définition de l’open data dans le domaine des transports

10Les critiques formulées par les participants à l’égard des données ouvertes par RWC constituent un bon moyen d’accéder aux enjeux de coopération soulevés par la réutilisation des données. Bien que le choix des outils et des méthodes de programmation soit une préoccupation centrale au début de l’ORH, c’est surtout la disponibilité de telle ou telle donnée qui rend apparents les conflits de perspective entre les producteurs et les réutilisateurs des données. Nous proposons ainsi de décrire cette phase exploratoire en deux temps. Nous proposons de revenir d’abord sur le corpus de données publiées par RWC, qui constitue le socle commun à partir duquel une pluralité de définitions est produite autour de la bonne manière d’ouvrir des données. C’est également sur la base de la disponibilité (et de l’indisponibilité) des données que les équipes développent des stratégies plus ou moins admises par les organisateurs pour les récupérer. C’est ce que nous verrons dans un second temps, à partir des activités de négociation et de détournement de données.

Comment faut-il ouvrir les données correctement ? Définitions multiples et conflits de perspective autour des bases de données ouvertes

11Au sein de l’ORH, les participants ont accès à un ensemble de données publiées dans des contextes variés. Tout d’abord, ils ont accès aux premiers jeux de données publiés au sein de la plateforme de RWC, dont les données dites statiques portant sur les horaires théoriques des trains, les équipements des gares et les coordonnées géographiques des points d’arrêt des lignes ferroviaires. Cinq autres fichiers sont publiés à l’occasion de l’ORH, regroupant des données telles que les bornes d’appel en gare, les tarifs des abonnements, les voyageurs montant en gare, ainsi que les entrées et les sorties de lignes ferroviaires qui connaissent d’importantes perturbations. Enfin, certaines données jugées sensibles sont mises à disposition uniquement aux participants de l’ORH, à travers des modalités d’accès passagères, via des serveurs sécurisés et des licences spécifiques préparées pour cet événement. Il s’agit d’échantillons de vrais mails adressés aux agents et des API (Application Programming Interface) permettant d’accéder à des données ayant un niveau de granularité plus important à propos des perturbations. Des mentors s’accordent pour dire qu’au-delà du nombre très limité de jeux de données publiés sur la plateforme, cette mise à disposition exclusive ne correspond pas à une véritable pratique de l’open data :

12

Là, c’est fun, mais ce n’est pas du tout de l’open data. Même durant le hackathon, il faut utiliser un nom d’utilisateur et un password pour accéder et télécharger les données. Ce n’est pas open quoi !
(Conversation informelle, Gérard, développeur indépendant)

13La perspective des salariés est cependant bien différente. Ces derniers doivent en effet faire face à un nouveau type de données par rapport à celles auxquelles ils ont habituellement accès au sein de l’entreprise : cadrées par des licences juridiques, mises à disposition dans des formats techniques qui en réduisent la complexité, certaines de ces données sont même reconstituées à partir de zéro, à l’occasion des hackathons. Dans cette phase expérimentale où la définition des données ouvertes n’est pas encore stabilisée, l’ORH devient le terrain par excellence où une pluralité de perspectives est mise en visibilité autour de leur caractère « ouvert », débattu ici du point de vue de leur disponibilité.

14Dans la plupart des hackathons organisés autour de l’open data, le manque de données fait en effet l’objet de discours normatifs et de débats parfois houleux sur les politiques adoptées par les fournisseurs. Pour les plus militants, l’ouverture sélective des données va à l’encontre des principes sous-jacents de l’open data. Les organisations doivent ouvrir des données qui sont au cœur de leur fonctionnement. Sinon, la démarche peut être décrédibilisée comme une stratégie de communication appelée openwashing, c’est-à-dire qui laisse croire que l’initiative s’inscrit dans le mouvement de la culture libre, sans que cela soit véritablement le cas :

15

Personne n’est contre le fait qu’une boîte qui ouvre des données en profite pour faire de la com’. Mais c’est beaucoup de construction, de discours autour de l’ouverture, sans jamais faire les choses simples qui ont été demandées à l’origine. L’objectif, c’est que les services publics publient au moins ce qu’ils utilisent en interne pour la prise de décision et pour le fonctionnement normal.
(Entretien, André, ingénieur informatique)

16Une problématique consiste ainsi à disposer de données « intéressantes » pour le développement d’applications. À cet égard, les développeurs constatent que les données ouvertes sont pour la plupart de nature statique : elles portent sur des horaires théoriques et des emplacements géographiques. Or, dans le domaine des transports, ce sont davantage celles dynamiques qui présentent le plus d’intérêt : les réutilisateurs sont nombreux à demander un accès à des données en temps réel prenant en compte les retards des trains ou encore, des données « fraîches » prenant en compte les travaux et tout autre changement lié à l’infrastructure et aux services associés :

17

Les données temps-réels sont super importantes. C’est surtout sur ces données dynamiques que tu vas te baser pour développer un service. Sinon, qu’est-ce que tu fais avec des données statiques ? Je ne vais pas développer une appli révolutionnaire avec le fichier du nombre de quais par gare…
(Entretien, Gérard, développeur indépendant)

18L’ouverture de ces données relève cependant plusieurs difficultés que le hackathon permet de mettre en visibilité. C’est ce dont témoigne Lucie concernant les données temps-réels :

19

Il y a des trucs qui me choqueront toujours. C’est quand un mec m’agresse en disant : « et vos données temps-réels ? ». Mais il faut déjà que je fasse les développements techniques. Mais ça, c’est difficilement entendable par les développeurs. Si je t’ouvre les données temps-réels sur une seule ligne, tu vas dire que je me fous de ta gueule. Et ça serait légitime. Donc il faudrait que je t’ouvre toutes les données du pays. Il faut imaginer la base, les informaticiens, le travail qu’il y a derrière.
(Entretien, Lucie, chargée de l’information multimodale, RWC)

20Les demandes formulées lors des hackathons révèlent l’ampleur du travail à fournir pour ouvrir correctement des données. Au contraire de ce que laissent penser les promoteurs de l’open data, celui-ci ne peut se résumer à la publication de données, telles qu’elles existent au sein des organisations. Il est l’issue d’un processus organisationnel qui doit être pensé, négocié et mis en œuvre collectivement. La diversité des producteurs de données en interne présente à elle seule une difficulté. Chacune des données incarne des enjeux plus ou moins déterminants selon les acteurs dont le rapport aux données se construit à travers les caractéristiques de son activité. Certains producteurs sont par exemple plus sensibles aux enjeux de sécurité. C’est le cas des ingénieurs de transports qui travaillent sur l’infrastructure ferroviaire. Pour ces derniers, l’ouverture de données et, plus largement, la transparence serait une pratique à risque, pouvant par exemple faciliter les attentats. Même si les développeurs pointent avec ironie que « les terroristes n’attendront pas d’avoir des données ouvertes pour poser des bombes », ces enjeux doivent cependant être entendus par ceux qui veulent les convaincre à ouvrir leurs données.

21Ainsi, la décision d’ouvrir des données ne suffit pas : elle nécessite d’établir des compromis entre les différents producteurs de données au sein de RWC. Elle repose également sur un travail supplémentaire pour harmoniser des jeux de données produites et structurées différemment par ces derniers. C’est ce dont témoignent Élise à propos des données de l’équipement des gares et Germain à propos des données relatives aux matériaux utilisés dans la construction des chemins de fer :

22

La donnée, elle n’existe pas toujours. Parfois, tu te rends compte que tes interlocuteurs n’ont pas exactement la même donnée. Parfois, c’est juste une différente interprétation des choses. Par exemple, les gares n’ont pas toujours les mêmes noms. On doit créer des codes pour dire que c’est la même gare. Donc tu te retrouves à compiler, à produire toi-même la donnée.
(Entretien, Élise, chargée des partenariats, RWC)

23

Il faut que les données puissent se matcher déjà entre elles. Ça nécessite de les retravailler, de réfléchir sur la signification de chacune, de trouver un point d’entrée pivot qui permet de les connecter. Sur les matériaux par exemple, la personne m’a envoyé un fichier « .doc » parce qu’il travaille comme ça. Et dans ce fichier, tu as des tableaux qu’il avait structurés bizarrement. Tu ne pouvais rien en faire.
(Entretien, Germain, chargé de l’open data, RWC)

24Certains jeux de données font ainsi l’objet d’un travail de compilation et d’harmonisation, au point de reconstituer parfois entièrement les fichiers qui sont demandés par les réutilisateurs. Un travail supplémentaire peut également être nécessaire pour « nettoyer » et compléter les données. Bien que, selon les promoteurs de l’open data, « c’est mieux d’avoir des données incomplètes maintenant que de les avoir dans un an » [8], les considérations liées à la qualité des données sont centrales pour les producteurs de données. Une pluralité de perspectives nourrit ainsi les débats autour des bonnes pratiques, dont certaines sont contradictoires : ce qui présente un caractère déficient pour les uns peut être valorisé par les autres. Les participants, quant à eux, requalifient les données ouvertes selon les besoins spécifiques de leur projet. En multipliant les points d’exploration et d’expérimentation, le hackathon leur permet de développer des solutions selon une pluralité de contextes de réutilisation des données. Différentes approches d’ouverture de données peuvent ainsi se construire, être mises en visibilité et parfois en action par les équipes. Voyons maintenant les stratégies que celles-ci développent pour effectivement disposer et rendre disponibles des données.

Dans hackathon, il y a hack : négociations et détournements autour de la disponibilité des données

25À l’origine, le hackathon repose sur une logique de contournement créatif et de bricolage, de récupération et de recyclage, d’essais et d’erreurs. Dans l’absence de matériaux conventionnels et coûteux, des façons inventives de travailler avec les « moyens du bord » y sont développées comme une pratique de détournement (Certeau, 1990). Bien que le hackathon organisé dans le monde des organisations reformule cet « art de faire » sous forme d’une exploration cadrée, il offre néanmoins la possibilité aux participants de négocier de multiples manières : des compromis peuvent émerger, tout comme des transgressions peuvent se produire au nom de l’ingéniosité des solutions proposées. Dans le cas des données en temps réels, une solution intermédiaire est par exemple d’ouvrir des données archivées. Cette solution implique le développement d’algorithmes permettant de calculer les probabilités d’incidence, de retard et d’affluence, à partir des données historiques du trajet recherché :

26

En discutant, on m’a dit : « si tu me donnes déjà l’historique des retards, de la ponctualité de tes trains, je pourrais faire des statistiques pour savoir les chances que la personne a d’arriver à l’heure. Ça vous montrera ce qu’on peut faire si on avait les données temps-réels ». Ce n’est pas bête, je n’y avais pas du tout pensé. […] Je me rends compte qu’il y a beaucoup d’autres données qu’on peut mettre à dispo, sans pour autant qu’il y ait un risque.
(Entretien, Lucie, chargée de l’information multimodale, RWC)

27Cette stratégie propose ainsi d’établir un compromis pour convaincre les producteurs de données à ouvrir les données en temps réels. Parmi les stratégies possibles, elle est sans doute celle qui repose le plus sur une activité de négociation. D’autres équipes optent cependant pour une méthode de démonstration plus laborieuse qui consiste à produire les données par elles-mêmes. Dans le contexte du hackathon, il arrive ainsi que certains aillent sur le terrain pour vérifier, collecter et compiler les données dont ils ont besoin. C’est le cas de l’équipe qui développe un calculateur d’itinéraires alternatifs en cas de perturbations. Choisissant de se concentrer sur quelques gares, l’équipe s’y rend pour vérifier les différents moyens de transport dont les données sont soit inexistantes soit indisponibles : des bornes de vélos en libre-service aux stations de taxis, ils recensent les données nécessaires pour développer un prototype. Ces stratégies peuvent parfois déborder du cadre du hackathon. C’est le cas par exemple d’une équipe qui, ayant besoin de la liste des escalateurs et des ascenseurs sur les quais, envisage de produire ces données en s’associant à OpenStreetMap (OSM), une base de données cartographiques libres constitués comme Wikipédia de manière contributive :

28

Nous, on croit beaucoup à OSM. On va rassembler 50 mecs et on va se balader toute la journée dans une gare pour compter les marches, mesurer leur hauteur, localiser les ascenseurs, prendre la distance entre le train et le quai parce qu’en banlieue, tu as 40 cm ! C’est un travail de titan, c’est sûr, mais comme on ne peut pas avoir les données, on va refaire le mapping nous-mêmes et on va les mettre en licence libre.
(Entretien, Gérard, développeur indépendant)

29Ces stratégies, qui cherchent avant tout à convaincre les organisations à ouvrir davantage de données, ne laissent cependant pas toujours la place à la négociation. Une pratique répandue dans les hackathons est notamment celle du scraping des données, qui consiste à les extraire automatiquement, sans attendre qu’elles soient ouvertes. Cette technique est en effet abondamment employée parmi les « hackers civiques » pour montrer l’utilité démocratique de l’ouverture des données (Peugeot, 2010). Renvoyant à un détournement technique des contraintes juridiques, elle consiste à récupérer des données propriétaires fournies par un service web via un programme informatique qui envoie des requêtes successives pour collecter l’ensemble des réponses et reconstituer ainsi la base de données. Au cours des hackathons, il arrive que des équipes s’assistent mutuellement dans la pratique du scraping pour dénoncer le manque de données. C’est le cas d’un atelier organisé lors d’un autre hackathon où plusieurs équipes se réunissent pour commenter les lignes de codes projetées sur un grand écran.

30Portant sur le scraping de données liées aux transports, cet atelier est auto-organisé par des participants qui développent un calculateur d’itinéraire multimodal au sein duquel une très grande variété de données doivent être intégrées. À cet égard, le scraping ne se présente pas seulement comme le moyen d’accéder à des données qui ne sont pas libres de droits, mais aussi comme la manière la plus rapide et efficace de procéder à cette intégration afin de produire un prototype fonctionnel dans les délais. Au lieu de récupérer des bases de données en consultant le service de chacun des opérateurs, les participants discutent de la possibilité de récupérer directement les données qui résultent de leur combinaison, à partir du calculateur d’itinéraire en ligne d’une Autorité Organisatrice du Transport (AOT). Face à l’ambition du hack, les participants rappellent les récits de hackers ayant contraint des organisations à ouvrir des données et réactualisent le slogan selon lequel « mieux vaut demander le pardon que la permission ». S’il n’y a rien de plus naturel que de hacker lors d’un hackathon, cela ne va cependant pas sans créer un dilemme pour les fournisseurs de données. Pour ces derniers, le scraping représente en effet « le côté négatif des hackathons » : bien qu’il permette de démontrer l’intérêt d’ouvrir davantage de données, il nourrit aussi, de manière paradoxale, les craintes conduisant à renforcer leur protection.

31Cela dit, l’ORH offre un cadre de négociation bien plus diplomatique où ce sont davantage les mentors qui développent des stratégies pour encourager l’ouverture de toujours plus de données. Ainsi, un atelier de réflexion sur les bonnes pratiques est proposé pour produire un argumentaire qui sera présenté en aparté aux cadres dirigeants au sein de RWC. Cet atelier clandestin porte lui aussi sur l’exploration des données : les mentors élaborent une carte représentant les données ouvertes et celles qu’ils recommandent d’ouvrir. Parallèlement, ils listent une série d’arguments face aux barrières qu’ils identifient à l’ouverture de données (e.g. « peur d’être dépassé », « inertie de l’entreprise », « relations syndicales », etc.) et recensent les différents composants de ce qui représente pour eux une réelle démarche d’open data : y figurent les formats de données à adopter, les modes d’accès qu’il faut mettre en place ainsi que les interactions à avoir avec les réutilisateurs. Il ne faut en effet pas réinventer de nouveaux formats, mais choisir ceux qui respectent le plus la structure des données, telles qu’elles existent au sein des SI de l’entreprise. De la même manière, il ne faut pas réécrire de nouvelles licences qui imposent des contraintes supplémentaires à celles qui existent déjà dans les licences traditionnellement utilisées dans l’open data. Au-delà du choix et de l’identification des données à ouvrir, ces recommandations se formulent aussi sur la base de problèmes récurrents rencontrés au cours du croisement de données d’origines variées. Voyons maintenant comment les enjeux de coopération émergent et se traduisent dans cette activité qui s’organise cette fois-ci autour d’une nouvelle caractéristique des données ouvertes, celle de leur interopérabilité qui devient centrale dans le développement d’applications de mobilité.

Le croisement de données d’origines variées et la production de l’information-voyageur

32Si le suivi des transformations des objets intermédiaires permet de repérer les phases distinctes des activités de conception (Vinck, 2009), les données ouvertes représentent à cet égard un cas particulier. Une fois publiées, elles sont téléchargées, dupliquées et retravaillées séparément et différemment au sein de chaque équipe. Dans cette configuration, les objectifs de traitement des données ouvertes se voient démultipliés avec le nombre de projets. Suivre les transformations qu’elles subissent permet ainsi d’accéder à la diversité des activités de recherche, de lecture, de comparaison et de test auxquelles doivent se prêter les participants pour intégrer les données dans le cadre de leur projet. Ces transformations sont d’autant plus révélatrices dans le développement d’applications de mobilité où le croisement de données est une préoccupation centrale pour obtenir une « information-voyageur » qui soit cohérente du point de vue de l’usager [9]. Elles font émerger de nouveaux problèmes liés à la structuration interne des données qui doivent s’intégrer à cette infrastructure informationnelle reliant un réseau d’acteurs bien plus étendu et varié (e.g. AOT, émetteurs de normes, autres opérateurs qui produisent et/ou ouvrent des données, etc.). Nous proposons de revenir sur ces problèmes communs qui caractérisent le développement d’applications de mobilité, avant de décrire les stratégies singulières que les équipes développent pour combiner plus facilement des données provenant de sources variées, dans le contexte spécifique de leur projet.

La contextualisation des données et le choix des formats : le cas du GTFS dans le domaine des transports

33Les données ouvertes sont toujours publiées avec un ensemble d’informations préparé par les fournisseurs pour assurer leur bonne utilisation. Il s’agit par exemple de la date de publication, la période couverte, la fréquence de mise à jour et l’historique des bases de données publiées. Au sein de la plateforme de RWC, on y retrouve également un espace d’échange animé par des demandes de précision sur les données. Les réutilisateurs sont nombreux à pointer les insuffisances des bases de données qui peuvent être par exemple incomplètes ou comporter des doublons. Certaines des erreurs sont visibles au parcours du fichier, tandis que d’autres se révèlent une fois que les données sont intégrées dans l’application, à partir des résultats erronés. Aussi, les données peuvent paraître trop épurées ou, à l’inverse, incompréhensibles par des acteurs éloignés au domaine des transports.

34Nous retrouvons là des problématiques abondamment étudiées dans les travaux réalisés en STS, sur le partage de données et la constitution d’infrastructures informationnelles (Bowker et al., 2009 ; Edwards et al., 2007 ; Star et Ruhleder, 2010). Dans le domaine scientifique, ces travaux montrent que les données sont toujours produites dans une écologie pratique, de manière située. À ce propos, « sans modèles, il n’existe pas de données », dit Paul Edwards, dans son étude sur le traitement des données météorologiques (Edwards, 2010). Sans entrer dans le détail de ces analyses, retenons ici l’idée selon laquelle les données sont toujours construites par rapport à des questions, avec des instruments de mesure, et qu’elles équipent des activités définies (Bowker et Star, 2000 ; Edwards et al., 2007 ; Star et Ruhleder, 1996). Leur ouverture nécessite alors un travail supplémentaire : les producteurs doivent contextualiser les données en explicitant les modèles qu’ils utilisent aux réutilisateurs qui, quant à eux, doivent acquérir de nouvelles connaissances et parfois développer des compétences spécifiques pour comprendre à la fois la structuration et la signification des données.

35Ainsi, un débat central est celui de la nature « brute » des données. En effet, après les avoir identifiées, les fournisseurs doivent faire une extraction de leur SI et choisir un format pour les représenter et les stocker [10] en dehors de ceux-ci. Dans le jargon informatique, c’est ce que les développeurs appellent la sérialisation :

36

Tu prends une donnée qui est structurée d’une façon et tu l’écris dans un format. Tu as un choix à faire. Si on considère qu’il y a des gens qui ont les compétences informatiques pour déchiffrer les formats, il n’y a pas de perte. Les données vont juste être bornées au sens où tu ne vas pas exporter l’ensemble des SI. Il n’y a pas de modification de la structure même des données. Justement, quand il y en a, on est nombreux à le critiquer.
(Entretien, André, ingénieur informatique)

37Pour les promoteurs de l’open data, le choix du format joue un rôle important. C’est lui qui détermine la manière dont les données sont décrites, contextualisées et mêmes sémantisées. Certains formats permettent par exemple d’attribuer davantage de métadonnées. D’autres sont conçus pour faciliter le transfert de données dynamiques qui doivent être régulièrement mises à jour. Dans l’ouverture de données liées aux transports, c’est le GTFS qui se voit généralisé [11]. Publié comme un format dit ouvert, le GTFS est composé de trois éléments : la liste des catégories de spécifications (e.g. arrêt, réseau, itinéraire, trajet, etc.), la définition des champs dans chacune des catégories (e.g. stop_id, stop_code, stop_name, etc.) et, enfin, le schéma relationnel de ces champs (voir la figure 1, ci-dessous).

Figure

Liste des catégories (à gauche) et schéma relationnel (à droite) des attributs du format GTFS

Figure

Liste des catégories (à gauche) et schéma relationnel (à droite) des attributs du format GTFS

38Si le choix des formats est important, c’est parce qu’ils déterminent ainsi la richesse des données, c’est-à-dire leur degré de granularité et les spécifications selon lesquelles elles sont reliées entre elles. Cette granularité et ces relations dépendent cependant fortement du domaine d’activité dans lequel ces données sont produites et échangées. C’est ce dont témoigne l’expression de la « professionnalisation de la donnée » :

39

On met beaucoup l’accent sur le côté geek, mais pas suffisamment sur la professionnalisation de la donnée. Mais tu as besoin de la connaissance métier pour faire de l’information-voyageur comme tu en as besoin pour comprendre ce que signifie un lit dans la base de données d’un hôpital.
(Entretien, Joseph, développeur, prestataire de RWC)

40Les données sont ainsi toujours construites par rapport à des conventions et des normes qui régulent les activités qu’elles décrivent. Le choix des formats repose précisément sur la nécessité de les expliciter. Des exigences parfois contradictoires peuvent alors émerger selon le contexte spécifique du croisement que les équipes cherchent à faire pour développer leur application respective. Tout d’abord, le format doit permettre de représenter les données de manière la plus fidèle à leur structure d’origine, telles qu’elles sont organisées au sein du SI de l’opérateur. C’est ce dont témoigne Clément, un contributeur d’OSM qui participe à l’ORH en tant que mentor :

41

Plus c’est proche de la façon dont la base est formatée en interne, mieux c’est. Plus tu as de la manipulation sur les données, plus tu as des risques qu’elles soient dénaturées. Sinon, tu te retrouves avec des fichiers GTFS qui ont été moulinés à la hache, ça te génère des millions de lignes d’informations alors que le format d’origine est beaucoup plus cohérent.
(Conversation informelle, Clément, ingénieur informatique)

42Pour certains, il faut que le format permette de comprendre la signification de telle ou telle donnée, de saisir les nuances qui existent entre par exemple les zones et les poteaux d’arrêt, entre arrêt physique et commercial. Si la plupart de ces notions sont compréhensibles par les développeurs, ce n’est pas le cas des données qui sont au cœur de l’activité de transport ferroviaire :

43

Heureusement, dans 70 % des cas, le langage sera compréhensible par le grand public. C’est le cas des données connexes : les données culturelles, financières, etc. Par contre, il y a la nécessité d’adapter des données métiers qui sont au cœur de la production de service de faire rouler des trains. C’est le cas des horaires où tu as plein de normes qui, déjà pour des gens qui travaillent dans le milieu du ferroviaire, sont très dures à comprendre, et c’est des experts ! La force de GTFS, c’est que ça se lit très vite par le code et ça s’intègre vite, c’est bien pour prototyper dessus.
(Entretien, Germain, chargé de l’open data, RWC)

44Au-delà d’une clarification des significations des notions utilisées dans les bases de données, il faut aussi que le format prenne en compte les règles de fonctionnement qui sont associées aux activités que les données sont censées décrire. C’est ce dont témoigne Joseph à propos d’une convention propre au domaine des transports que les réutilisateurs doivent connaître pour lire correctement les données ouvertes à travers le format GTFS :

45

Une règle, c’est l’interdiction de trafic local. Quand tu as un transporteur régional qui fait de l’interdépartemental, il n’a pas le droit de desservir deux arrêts dans la même commune. Parce que sinon il fait de la concurrence aux transporteurs locaux qui peut être jugée comme déloyale. Donc il n’a pas le droit de vendre des billets. Et dans l’information-voyageur, tu ne dois pas faire ressortir cette information-là. Même si ça s’arrête dans les deux gares, il s’arrête que pour laisser descendre les gens. Et ce type de règles métiers par exemple, GTFS ne traite pas. Donc si tu ouvres tes données comme ça, il va y avoir des applications qui vont proposer des itinéraires qui ne seront pas possibles.
(Entretien, Joseph, développeur, prestataire de RWC)

46Ainsi, pour que les réutilisateurs puissent utiliser ces données correctement, sans connaître ces règles métiers, l’opérateur doit les formater telles qu’elles sont construites et normalisées dans le domaine des transports. Dans les échanges de données entre eux ou avec les AOT, les opérateurs de transports utilisent des formats dont les spécifications sont émises par des organismes de normalisation. La plupart utilisent par exemple des formats qui reposent sur NEPTUNE (Norme d’Échange Profil Transport collectif Utilisant la Normalisation Européenne) et sur SIRI (Service Interface for Real-time Information) ; le premier facilitant l’échange de données théoriques et le second, celui de données en temps réels pour produire successivement une information multimodale et à l’échelle européenne. Or ces formats normalisés ne sont ni simples à comprendre ni faciles à manipuler. Ils ont un niveau de détail élevé et ils peuvent être plus ou moins bien complétés :

47

J’ai la granularité dans la norme qui me permet de dire par exemple que je peux prendre le bus avec le fauteuil roulant, mais par contre je n’ai pas l’info. J’ai la case pour le dire, mais il faut encore qu’elle soit remplie.
(Entretien, Joseph, développeur, prestataire de RWC)

48Ainsi, le choix des formats n’est pas sans incidence sur le développement d’applications qui repose sur le croisement de données provenant d’opérateurs variés. Cela est d’autant plus valable dans le cadre d’un hackathon où les temps sont courts et les services produisent pour la plupart une information multimodale à destination des voyageurs. C’est dans ce contexte que des formats simplifiés comme le GTFS se voient généralisés dans l’ouverture de données liées aux transports et adoptés par RWC malgré qu’il s’accompagne d’une simplification pouvant parfois être à l’origine de nouvelles difficultés :

49

La problématique, c’est l’utilisation simple des données. Et le GTFS est très bien parce qu’il ne prend pas 50 milliards de notions. Si tu veux avoir une visualisation rapide de tes données, il suffit que tu l’injectes et pouf, tu vois tous tes arrêts sur une carte. Tu vois l’essentiel des informations sans même avoir besoin de coder. Après, c’est limité pour faire des choses plus avancées.
(Entretien, Joseph, développeur, prestataire de RWC)

50Le GTFS ne permet donc pas de développer des fonctionnalités avancées. Il est cependant utile pour élaborer une cohérence des spécifications des données de transports dans le but de les croiser avec des données provenant de sources variées. Dans l’absence de standards, la multiplicité des formats fait ressortir plusieurs aspects du traitement des données. Surtout aux débuts de l’open data dans le domaine des transports, cette activité nécessite de mobiliser des connaissances de plusieurs domaines pour comprendre la structuration des données (e.g. informatique, géomatique, transports, etc.) et de retravailler les modes classificatoires pour les rendre sémantiquement compatibles et techniquement interopérables. Les équipes sont donc investies dans des activités de lecture et d’interprétation pour repérer des référentiels communs. Face aux incompatibilités, ils doivent détecter les origines des erreurs qui émergent au cours du croisement de données (i.e. code, fichiers sources, bases combinées, etc.). Ces travaux de vérification et de correction « augmentent » les données ouvertes par différents opérateurs qu’ils aident ainsi à rendre plus cohérentes entre elles, par un travail d’intégration supplémentaire :

51

La qualité des résultats dépendra énormément de la qualité des données d’entrée et dès qu’il y a plusieurs sources, il faut les intégrer correctement. Des données de deux opérateurs, même si elles sont très cohérentes, si je les empile de façon bête et méchante, le calcul va donner un itinéraire inutile parce que je n’ai dit nulle part qu’il faut marcher 10 minutes pour passer de l’un à l’autre.
(Entretien, André, ingénieur informatique)

52Les participants doivent développer des patchs, c’est-à-dire des morceaux de code informatique qui permettent de résoudre ou de contourner les problèmes identifiés. Au cours de ces activités, des standards émergent et équipent les données qui, en se reliant ainsi à des infrastructures plus ou moins partagées, sont dotées progressivement par de nouvelles propriétés. Voyons maintenant comment les équipes développent différentes stratégies d’équipement afin de faciliter le croisement de données.

Questions d’interopérabilité et création de technologies-passerelles : l’exemple d’OpenStreetMap (OSM)

53Un exemple particulièrement frappant est celui de l’utilisation de la base de données d’OSM pour résoudre ces questions d’interopérabilité. Avec un fort composant géographique, les données de transports sont en effet souvent représentées sur un support cartographique qui permet de visualiser des emplacements et des trajets, à la fois de manière statique et dynamique. La carte constitue ainsi un support privilégié dans le développement d’applications, allant du plus simple calcul d’itinéraire à des fonctionnalités plus complexes comme la simulation des temps de trajets en fonction des heures d’affluence ou de points d’intérêts. Une stratégie abondamment employée lors des hackathons est alors de s’appuyer sur la base de données OSM. Celle-ci a l’avantage d’être gratuite et de fournir des données « fraîches », continûment mises à jour et corrigées par ses contributeurs. Elle présente aussi l’intérêt d’avoir plusieurs couches d’informations permettant de géolocaliser des éléments fort variés (e.g. bancs publics, aménagements cyclables, monuments historiques, etc.). OSM relève enfin d’un haut degré de précision : il existe par exemple 28 valeurs différentes pour annoter les barrières qui contrôlent l’accès sur les routes. Ces données sont directement codifiées par des coordonnées géographiques selon le système géodésique standard qui est employé par le système GPS. Elles sont également catégorisées au sein de la base comme des points d’intérêts (e.g. restaurant, bar, parc, etc.). Ainsi, les participants recourent à OSM non seulement pour visualiser des données, mais aussi pour accéder à des ensembles d’éléments localisés qui sont déjà mis en cohérence au sein d’une seule et même base de données. Cela dit, ils doivent tout de même rapprocher les données ouvertes avec celles d’OSM.

54Une manière de faire cela est de créer des « jointures » à travers lesquelles les développeurs intègrent au sein du code, la possibilité de faire des requêtes parmi plusieurs bases de données. Cette pratique nécessite de trouver des informations communes entre ces fichiers pour produire une base combinée, virtuelle et temporaire. C’est sur ce principe que la majorité des applications fonctionne pour produire une nouvelle information à partir de différentes sources de données. La complexité des jointures se situe cependant dans la manière de trouver les équivalences entre des bases structurées différemment : plusieurs gares peuvent avoir la même désignation au sein d’une même base de données ou, au contraire, une même gare peut avoir plusieurs désignations dans différentes bases de données. Pour cela, il existe en effet le code attribué par l’Union Internationale des Chemins de fer (UIC) qui constitue le seul identifiant stable et unique dans toutes les bases de données de transports [12]. Les participants doivent désormais développer des manières ingénieuses de créer des jointures et de définir des « relations » entre ces données de transports et la base d’OSM. C’est ce dont témoigne Judes qui, en tant que mentor à l’ORH, accompagne les équipes dans l’utilisation d’OSM :

55

On se casse la tête pour faire des jointures. L’idéal, c’est de les faire avec les codes de l’Institut de Statistique National [ISN]. Tu fais une table de correspondance avec l’UIC pour voir le nombre de gares dans chaque commune. Pour faire ça, il faut faire une requête géo-spatiale, parce que tu n’as pas de correspondance entre les polygones des communes et les codes UIC des gares. Et encore, je ne parle pas d’une jointure sémantique au sens verbe, mot, nom, identifiant.
(Entretien, Judes, contributeur OSM)

56À travers la création de jointures, les participants développent ainsi des « technologies-passerelles » pour interconnecter plusieurs systèmes jusque-là incompatibles. Cette notion est formulée par Paul Edwards dans ses travaux portant sur les activités d’assimilation de données, pour analyser les modèles de prévision météorologique permettant de réconcilier des bases de données provenant de sources variées (Edwards, 2010 ; Edwards et al., 2007 ; Egyedi, 2001). Au-delà des formats tels que GTFS, les jointures avec la base d’OSM constituent elles aussi des passerelles qui, parce qu’elles proposent un moyen standardisé de croiser des données, confèrent par-là, une plus grande flexibilité aux réutilisateurs qui en manipulent une pluralité. Ainsi, ces derniers réorganisent les données au sein des applications en fonction de la structure convenue de la base d’OSM et, ce faisant, contribuent à leur enrichissement, leur augmentation et, in fine, à leur équipement (Vinck, 2006).

57Bien entendu, le croisement des données ouvertes par RWC avec celles d’OSM ne se présente pas systématiquement comme une augmentation ; il présente d’ailleurs de nombreuses complexités pour que RWC bénéficie de ce travail d’équipement [13]. Cela dit, du point de vue de l’activité, il s’agit tout de même d’un travail d’équipement qui permet aux contributeurs d’OSM de concevoir des outils d’intégration des données de transports dans la base et des techniques de croisement de données de nature différente. Pour RWC, ce sont ces activités qui constituent la source principale de retours d’expériences sur les données ouvertes et, ainsi, le pivot de multiples débats conduits au sein de l’entreprise autour de l’équipement des prochaines données à ouvrir :

58

Ce qui est intéressant, c’est que tu as plein de feed-back. C’est peut-être ça d’ailleurs pour moi la première utilité. Ça nous permet de voir les demandes techniques sur les formats et les architectures des API. On savait qu’il y avait un intérêt pour ces évolutions-là, mais le simple fait d’être confronté à des demandes concrètes, ça nous fait dire : « OK, on y va ».
(Entretien, Germain, chargé de l’open data, RWC)

59Au-delà de ces feed-back contextuels, des relations privilégiées avec les contributeurs d’OSM se tissent également autour de la correction, de l’enrichissement des données de RWC. C’est l’exemple des fichiers envoyés en avant-première aux contributeurs d’OSM qui, sur la base d’un accord informel, vérifient leur qualité, les corrigent et les renvoient au RWC.

60

La première vérification, c’est si la gare est bien placée. Il faut que le développeur le fasse aussi parce que son service est basé dessus. Ensuite, on regarde si les données attributaires sont dans la base. On les rajoute, on les corrige et on enrichit OSM de façon systématique. Ensuite, on renvoie ce fichier corrigé au RWC. Il y a parfois des milliers de corrections. J’en ai vu par exemple des gares localisées dans le golfe de Guinée parce que la latitude et la longitude égale zéro, donc tu es à l’équateur. RWC peut aussi récupérer cette donnée via l’API d’OSM.
(Entretien, Judes, contributeur OSM)

61Si les coopérations peuvent ainsi déborder du cadre des hackathons, c’est cependant au sein de ces derniers que des définitions plus ou moins partagées sont construites autour du caractère « ouvert » des données débattues du point de vue de leur interopérabilité. Retravaillées selon des structures convenues, les données acquièrent ainsi des propriétés qui leur permettent de s’intégrer au sein d’infrastructures de données variées (i.e. ferroviaire, cartographique). Cette intégration est cependant réalisée dans le cadre de développement de nouveaux services de mobilité destinés aux usagers finaux des transports. C’est notamment à travers les applications que les données se relient à l’infrastructure plus globale de l’information-voyageur où elles peuvent a priori circuler entre des mondes encore plus variés.

L’intégration des données ouvertes au sein de nouvelles applications de mobilité

62Suivre les données ouvertes au sein de l’ORH permet de comprendre comment elles sont progressivement transformées par les équipes en des applications de mobilité. Pour illustrer cette traduction des données ouvertes dans le registre de services aux usagers, un dernier état qu’il convient de mentionner est celui des données intégrées, c’est-à-dire telles qu’elles servent de ressources au sein des applications, pour produire de nouvelles données (Loukides, 2010). En multipliant les interfaces entre les usagers et les opérateurs, ces applications participent elles aussi à équiper les données qui peuvent désormais circuler au sein de l’infrastructure de l’information-voyageur décentralisée vers les terminaux mobiles des usagers. Cette mise en circulation repose sur une activité d’interfaçage entre différentes sources de données rendues accessibles via des API. La structure commune de cette activité se définit avant tout par les contraintes temporelles du hackathon : les équipes doivent produire un prototype fonctionnel à la fin du week-end et, pour ce faire, elles développent une pluralité de stratégies permettant de présenter l’application du point de vue de l’usager. Nous proposons maintenant de voir cette activité en deux temps, pour montrer que même si les équipes simulent le développement de services aux usagers, la plupart des productions sont en réalité loin d’être des prototypes fonctionnels, prêts à être véritablement utilisées par ces derniers. Cette troisième et dernière partie souligne que les applications permettent néanmoins de faire circuler les données ouvertes dans un tout autre monde, celui des cadres dirigeants de l’entreprise qui évaluent les projets à la fin du week-end, du point de vue de leur capacité à nourrir une dynamique d’innovation de service aux usagers.

Activités de prototypage rapide : le cas des Interfaces de Programmation d’Applications (API)

63Nous l’avons dit, la production d’une information-voyageur cohérente du point de vue de l’usager est au cœur du développement d’applications de mobilité. La cohérence de cette information repose entre autres sur le respect des modèles spécifiques des données de transports. Si les formats permettent de maintenir l’intégrité des données, ils ne suffisent pas pour autant aux réutilisateurs pour développer des applications de manière entièrement autonome. En effet, la cohérence de l’information-voyageur dépend fortement de la capacité des données à décrire efficacement le monde physique dans lequel circulent les usagers. Les travaux de rénovation réalisés par ci et des retards accumulés par là doivent ainsi être pris en compte pour produire une information pertinente du point de vue de ces derniers. Comme en témoigne Gérard, les développeurs prêtent une attention particulière à la fréquence de mise à jour des données, avant de les utiliser :

64

La première chose qu’on regarde, c’est la fréquence des mises à jour. Je n’utilise pas des données si elles sont mises à jour une fois par an. Ce n’est pas la peine de développer un service dessus. Si une semaine plus tard, il y a des travaux, ton résultat, il est obsolète. Quand un fournisseur ouvre des données, il faut qu’il les maintienne à jour, sinon ça n’a plus d’utilité.
(Entretien, Gérard, développeur indépendant)

65Les données intégrées acquièrent ici de nouvelles significations ; elles ne sont plus simplement évaluées en tant qu’information rendue disponible ni du point de vue de leur interopérabilité avec d’autres données, mais renvoient également à des conditions de stabilité qui permettent de les inscrire dans une logique durable de service aux usagers. Une solution abondamment employée est alors celle des API qui constituent un moyen alternatif à la publication de fichiers. Elles consistent en des protocoles d’échanges de données à travers lesquels les développeurs peuvent envoyer des requêtes aux serveurs des fournisseurs où les données sont stockées. Elles permettent ainsi d’interfacer rapidement des logiciels avec différentes sources de données, en y associant une série de règles d’utilisation.

66Les premiers usages des API se font en effet dans l’industrie du logiciel, dans le but de réduire les dépendances autour du travail de développement. En délimitant les activités, elles permettent aux acteurs de travailler à distance, de manière distribuée et coopérative (De Souza et al., 2004). Dans le contexte du web social, les API sont par ailleurs à l’origine d’un nouveau modèle d’innovation fondé sur la coopération horizontale entre des services qui s’échangent des données (Aguiton et Cardon, 2008) [14]. C’est précisément dans ce contexte que de nouveaux modèles économiques émergent autour des données : les API confèrent notamment aux fournisseurs la possibilité de contrôler les modalités d’accès et les conditions d’usage des données, afin de les cadrer selon des objectifs de rentabilité. L’ouverture de données à travers des API ne va donc pas sans produire, à nouveau, une pluralité de perspectives autour du caractère « ouvert » des données qui est débattu cette fois-ci à travers les modalités d’accès. Pour certains, les API permettent d’avoir un accès permanent à des données fraîches, sans pour autant intégrer l’ensemble des données et alourdir le fonctionnement des applications :

67

On n’est pas dans du dépôt, mais du flux. Il faut simplifier la vie des développeurs et ne pas les faire télécharger tout un fichier pour utiliser uniquement une donnée.
(Entretien, Augustin, développeur indépendant)

68Bien que l’intégration d’API ne dispense pas les développeurs de la lourde tâche de combiner des données, certains estiment qu’elles les libèrent d’une partie du travail d’exploration des bases dont le niveau de précision peut devenir une contrainte dans l’intégration des données. En fin de compte, pour qu’une donnée soit « ouverte », il ne suffit pas qu’elle soit disponible, il faut aussi qu’elle soit facile à réutiliser. C’est ce dont témoigne Joseph qui travaille à la mise à disposition des API de l’entreprise :

69

Un développeur, il s’en fout en fait. Lui, ce qu’il veut, c’est d’avoir une application qui répond à un besoin fonctionnel pour l’utilisateur. L’information-voyageur, ce n’est pas son métier et surtout, il ne doit pas rentrer dedans, parce que si chaque personne doit être expert, tu perds l’intérêt de l’open data. Il faut donc fournir quelque chose qui soit facile à utiliser. Mais du coup, certains considèrent que c’est moins ouvert que ça devrait l’être.
(Entretien, Joseph, développeur, prestataire de RWC)

70Pour d’autres, les API présentent cependant plusieurs difficultés. D’abord, elles traduisent une opacité produite entre autres par la technicisation des données auxquelles seuls les initiés au traitement informatique peuvent accéder. Ensuite, les API permettent de procéder à une ouverture contrôlée des données. Pour les utiliser, les développeurs doivent s’identifier et accepter une série de contraintes liées aux méthodes, à la quantité et à la périodicité des requêtes qu’ils peuvent envoyer. Les spécifications techniques des API expliquent que, pour des raisons de traçabilité, tous les accès se font avec une identification. Si les développeurs codent parfois des scripts pour automatiser des requêtes, les fournisseurs peuvent, quant à eux, limiter les requêtes en nombre et en fréquence pour éviter la saturation de leurs serveurs. Chaque identifiant possède ainsi des quotas d’appels autorisés par minute. Parallèlement à leur propriété de passerelles, les API font ainsi naître de multiples liens de dépendance : toute modification de l’API implique par exemple un ajustement de la part des développeurs. Le fonctionnement de l’application dépend de la stabilité des conditions d’accès définies par le fournisseur qui peut les faire évoluer à tout moment. Bien entendu, ce n’est pas lors d’un hackathon que ces services vont être effectivement développés : au cours de cette phase initiale, les architectures des API ne sont pas encore stabilisées. Mais, le développement d’applications au sein d’un hackathon ne peut s’en passer : les équipes-projets recourent à des API pour simuler la production d’un résultat pertinent au cours de la démonstration.

Du code à l’image et vice versa : stratégies démonstratives autour des applications aux usagers

71Au sein de cette simulation en grandeur nature, les équipes sont toutes prises au jeu pour produire un résultat tel qu’il est censé se présenter aux usagers. Au total, six applications sont développées pour améliorer la gestion des situations perturbées : un outil de crowdsourcing permettant aux voyageurs de signaler des problèmes, un outil de visualisation de l’état du trafic et de calcul d’itinéraires alternatifs, un chatbox entre les voyageurs et les agents à proximité, un outil de coordination entre les commerçants et les clients au sein des gares, un outil de visualisation des perturbations liées à une gare et aux lignes qui la desservent, un tableau de bord permettant d’historiciser des données provenant de sources variées autour d’une incidence en particulier.

72Toutes ces applications s’appuient sur les données ouvertes par RWC ; mais elles ne sont pas toutes développées au sein de l’ORH à travers une activité d’intégration de données. Certaines équipes privilégient l’interfaçage d’API pour développer un prototype fonctionnel et choisissent un ou deux exemples pour le démontrer. C’est le cas de l’équipe qui se concentre sur une ligne en particulier et qui développe les interfaces-utilisateurs autour d’une gare précise pour montrer au jury la manière dont l’application est censée fonctionner. Cette stratégie leur est soufflée par un mentor qui les accompagne dans l’extraction de données à partir de la base d’OSM :

73

Sur OSM, tu dois d’abord sélectionner toutes les gares d’une ligne, puis extraire les données des autres moyens de transport autour de ces gares. Bon, sachant qu’il faut que vous développiez un proto, le mieux est que vous preniez une seule gare sur cette ligne et que vous intégrez toutes les données multimodales pour faire la démo.

74Certaines équipes arrivent ainsi à produire des prototypes qui, même s’ils se concentrent sur une ou deux requêtes, fonctionnent. Bien que ces stratégies varient selon la complexité des applications, il arrive aussi que des équipes cherchent à reproduire l’image d’un prototype complet, sans pour autant réussir à le faire fonctionner. Ces équipes misent davantage sur la traduction visuelle de la capacité des applications à répondre aux « besoins » qu’elles ont identifiés. Si toutes les équipes produisent des représentations pour découper socialement et temporellement le travail de développement (Peters, Faulx et Hansez, 2010), le poids de ces représentations peut se mettre plus ou moins au cœur de l’activité de prototypage d’applications. Ces équipes se concentrent alors sur la représentation graphique et fonctionnelle des applications qui invisibilise le traitement technique des données, pour mettre en scène le service que celles-ci doit rendre aux usagers. Elles emploient par exemple des maquettes préfabriquées pour représenter esthétiquement des interfaces telles qu’elles s’afficheraient sur des écrans de smartphones ou de tablettes des usagers.

75Durant les hackathons, la création d’images peut ainsi prendre une place importante. Mais lorsque les représentations graphiques prennent le dessus, de nouvelles tensions peuvent aussi émerger. Des participants peuvent notamment se désinvestir progressivement. C’est le cas de Dorian, un salarié de la DSI qui, bien qu’il participe en tant que designer, confie son malaise à propos des orientations prises par son équipe. Au lieu de se concentrer sur le fonctionnement de l’application, il rapporte que celle-ci se penche davantage sur la production d’images statiques pour restituer l’expérience de l’usager :

76

Ah, un prototype qui tourne… Tout le monde dit que c’est extraordinaire et qu’il faut apprendre à travailler plus vite. […] Mais la plupart des choses sont fakes. On n’a pas le temps de faire afficher de réelles données, donc là, on va afficher des images statiques qui vont montrer que ça peut s’afficher. Il faut faire le beau…
(Conversation informelle, Dorian, informaticien, RWC)

77Le fonctionnement des prototypes peut ainsi rapidement se fondre dans la nature performative des présentations produites à destination du jury. Si le travail des équipes porte effectivement sur l’équipement des données qui acquièrent de nouvelles propriétés quand elles sont intégrées au sein des applications, il faut ainsi noter que celles-ci, plutôt que de s’intégrer réellement dans l’infrastructure de l’information-voyageur, sont davantage mobilisées par les membres du jury comme des « preuves de concept » (Rosental, 2012) pour convaincre les décideurs à ouvrir davantage de données. C’est ainsi, à travers les démonstrations d’application au jury que les données acquièrent de nouvelles significations, deviennent accessibles par des publics non techniciens et se dotent in fine de nouvelles capacités de coordination entre ce monde encore plus éloigné, malgré la diversité de leurs perspectives sur l’ouverture de nouvelles données.

Conclusion

78Le mouvement des données ouvertes n’est plus à ses débuts ; il fait désormais partie d’un tableau plus large qui s’intéresse davantage à la massification et au traitement algorithmique des données (Kitchin, 2014). Mais si nous n’avions pas gagné une telle familiarité aujourd’hui avec ce phénomène, nous pourrions sans doute mieux saisir l’originalité d’une telle démarche dont la généralisation occulte les inquiétudes, les hésitations et les tâtonnements qui l’ont jusque-là accompagnée. Restituer ces derniers permet de mettre en perspective cette brève histoire de l’open data dont l’originalité ne s’est pas rangée là où les organisations l’ont initialement situé dans l’amélioration du service public par l’innovation de nouvelles applications. Cette visite ethnographique de l’ORH permet notamment d’accéder aux enjeux de coopération qui se formulent avec l’ouverture des premiers jeux de données et dont la résolution reste aujourd’hui toujours d’une grande actualité. Cet article confirme notamment que l’ouverture de données n’est jamais une simple mise à disposition de bases de données, telle qu’elle est demandée par les mondes militants et entrepreneurs de l’open data. Si les premiers travaux ont justement mis en évidence le travail de préparation préalable qui est fourni dans les coulisses par les producteurs de données (Goëta, 2016), cet article prolonge cette réflexion au sein d’un hackathon où celles-ci sont retravaillées par les réutilisateurs sur le devant de la scène, dans le développement d’applications de mobilité. On peut en conclure deux apports principaux.

79Le premier est que cette analyse permet d’accéder à un stade particulier, où les acteurs explorent de nouveaux modèles d’organisation et apprennent à travailler, sur fond d’incertitudes, autour d’un objet émergeant dont les tenants et les aboutissants ne sont pas encore clairement connus ni maîtrisés. S’il est nécessaire dans les processus d’innovation de construire une vision plus ou moins partagée de ces objets, le hackathon agit comme un espace interstitiel qui permet d’inscrire conjointement les enjeux de la production et de la réutilisation des données, dans le contexte spécifique d’une multitude de projets. Au sein de cet espace, différentes approches sont mises en visibilité et des représentations communes peuvent être négociées. À cet égard, nous dirons que le hackathon permet d’ouvrir la boîte noire des données. Il met non seulement en débat les propriétés formelles de ce nouvel objet, mais fait également émerger des exigences contradictoires au sein de l’univers de pratique des différents acteurs engagés. Cette donnée doit par exemple être à la fois suffisamment contextualisée et facile à comprendre par des publics éloignés. Elle doit être intéressante et facilement réutilisable pour développer des applications, mais ne doit pas être pour autant technicisée. Le hackathon constitue ainsi un dispositif d’ouverture de ces objets et des connaissances encore « sauvages » qu’ils mobilisent et dont la production échappe encore aux institutions et aux organisations concernées. Il est évalué par sa capacité à accroître l’exploration et à multiplier des définitions concurrentes sur la valeur, l’intérêt ou encore la qualité des données.

80Le second apport de cette analyse porte ensuite sur la nature du travail sur les données. En réalité, si l’objectif est de développer de nouvelles applications, c’est bien autour de la disponibilité, de l’interopérabilité et des modalités d’accès des bases de données que les activités se voient coordonnées. Ainsi, le développement d’applications se présente comme un faisceau d’activités qui contribuent à les équiper. La description de ces activités met en évidence un processus d’équipement à travers lequel les jeux de données sont comparés, combinés et mis en scène à travers des propriétés qui leur permettent de coordonner à leur tour des acteurs provenant de mondes hétérogènes, autour du processus d’ouverture de nouvelles données. La structure commune de ces activités de développement et les stratégies singulières des acteurs autour des bases de données permettent d’identifier trois principaux états à travers lesquels ces derniers sont reliés à des appuis conventionnels et à des espaces de circulation plus ou moins partagés avec ces différents cercles d’acteurs. À travers les activités d’exploration, de croisement et d’interfaçage, les données sont retravaillées du point de vue des éléments structurels partiellement communs aux mondes des transports et de l’innovation numérique. La standardisation de formats comme le GTFS ou l’intégration des données de transports dans la base d’OSM à travers les identifiants uniques en sont les meilleures illustrations de cet équipement progressif des données dans l’infrastructure de l’information-voyageur qui est partagée ensuite par les opérateurs et les usagers. Enfin, les prototypes d’applications présentées du point de vue des usagers traduisent les données dans les termes d’un service pour être rendues accessibles par les mondes plus éloignés des cadres dirigeants de RWC.

81En passant d’un état ouvert à celui intégré, les données ouvertes acquièrent ainsi progressivement des propriétés d’objets-frontières qui contribuent à l’articulation des différentes définitions développées par des mondes sociaux hétérogènes (Star, 2010 ; Star et Griesemer, 1989 ; Trompette et Vinck, 2009, 2010). Si le hackathon permet d’équiper les données, notons que ce travail ne suffit pas pour autant à en faire de véritables objets-frontières qui permettent d’autonomiser les coopérations entre ces acteurs variés. En effet, si les équipements sont, d’une part, négociés à travers les retours d’expérience et, d’autre part, co-construits à travers le détournement, le croisement et l’intégration des données, ils ne sont cependant pas associés directement aux données telles qu’elles sont publiées. Pour cela, les fournisseurs de données doivent réaliser un travail d’organisation supplémentaire pour identifier les données intéressantes, choisir les bons formats, corriger les erreurs, harmoniser les référentiels, stabiliser les API et mettre en place une coordination à part entière pour systématiser l’ouverture de nouvelles données. Celle-ci représente ainsi des enjeux organisationnels et culturels qui font l’objet d’une analyse séparée.

Notes

  • [1]
    L’auteure tient à adresser ses plus vifs remerciements à Patrice Flichy pour ses conseils et son soutien. Elle remercie également Gaël Musquet et Andrew Byrd qui l’ont guidée dans les méandres des bases de données.
  • [2]
    http://opendefinition.org/ (consulté en septembre 2018).
  • [3]
    http://www.opengovdata.org/home/8principles (consulté en septembre 2018).
  • [4]
  • [5]
    Cet article repose sur une enquête de terrain réalisée entre les années 2011 et 2013 dans le cadre d’une recherche doctorale, sur le programme open data de RWC (Trupia, 2019). Les matériaux empiriques sont recueillis à travers une démarche d’observation participante, lors de trois rassemblements durant chacun le temps d’un week-end. Il repose également sur la réalisation d’entretiens semi-directifs (n=20) avec les différents groupes de participants, à la fois au sein de RWC et en dehors, parmi ceux qui accompagnent l’ouverture des données et l’organisation de hackathons par RWC. Le journal de terrain et les conversations informelles sont complétées par l’observation de la plateforme de publication de données. L’ensemble des propos d’acteurs est anonymisé par des pseudonymes pour respecter leur confidentialité et certaines précisions sur leur poste ont été enlevées pour des raisons de clarté.
  • [6]
    Ainsi, nous aborderons moins la spécificité du hackathon du point de vue de son inscription dans le monde des organisations où il accompagne une dynamique de transformation organisationnelle et culturelle associée de plus en plus à leur transition numérique. Le cadrage des interactions entre la grande organisation et le monde de l’innovation numérique au sein de l’ORH fait cependant l’objet d’une analyse à part, présentée au sein d’une publication séparée.
  • [7]
    Les objets intermédiaires renvoient à la fois à l’idée d’une médiation, c’est-à-dire d’« inscription de quelque chose dans la matière de l’objet » et à celle de traduction « selon laquelle le passage d’un registre à l’autre, par exemple le passage de l’intention à la réalisation, ne se fait pas sans transformation » (Vinck, 2009, p. 56). Cette notion est employée pour mettre en évidence le rôle structurant des instruments matériels dans la coordination d’acteurs hétérogènes (e.g. designer, ingénieur, fabricateur, etc.) dans la conception de nouveaux produits (Jeantet, 1998).
  • [8]
    Ce propos formulé d’abord par le fondateur d’OKFN est ensuite popularisé par Tim Berners-Lee dans son intervention intitulée « The next web », lors d’une conférence TED. http://www.ted.com/talks/tim_berners_lee_on_the_next_web.html (consulté en septembre 2018).
  • [9]
    Dans le domaine des transports, ce terme exprime l’idée d’une infrastructure informationnelle dont la production renvoie à une activité à part entière, qui consiste à harmoniser des données produites d’une manière distribuée, au sein d’un réseau d’humains (e.g. informaticien du centre des opérations, agent de sécurité, vendeur en gare, etc.) et de non-humains (e.g. SI, voie ferrée, condition météorologique, etc.), et à redistribuer cette information à travers une diversité de supports (e.g. écran, annonce vocale, signalétique, etc.) aux usagers.
  • [10]
    Notons ici la distinction qui est faite par les développeurs entre d’une part les éléments de langages qui décrivent les catégories de données et, plus largement, la classification qui forme la structure de la base de données et, de l’autre, les formats d’échange par lesquels ces données sont stockées de façon structurée, sans que la structure ne soit figée.
  • [11]
    Ce format initialement intitulé Google Transit Feed Specifications est développé en 2005 par un salarié de Google pour faciliter l’intégration de données de transports dans son service de cartographie, Google Maps, et son calculateur d’itinéraire, Google Transit. Se généralisant dans l’ouverture de données de transports, il est renommé General Transit Feed Specifications et ses spécifications techniques sont rendues publiques par Google qui propose d’y apporter des modifications au sein d’un groupe de discussion en ligne animé par ses salariés.
  • [12]
    L’UIC émet des standards pour uniformiser les conditions de construction et d’exploitation des chemins de fer à l’échelle internationale (e.g. écartement des voies, sécurité du réseau, etc.). Le code UIC, quant à lui, est standardisé pour faciliter l’échange de données international entre des compagnies ferroviaires.
  • [13]
    Si l’entreprise met à jour régulièrement ces données sur la base OSM, elle risque par exemple d’écraser les modifications apportées par les contributeurs entre-temps. Aussi, sans identifiants uniques des données sur OSM, il peut devenir complexe d’identifier les provenances des données suite à de nombreuses modifications.
  • [14]
    C’est le fameux exemple de Google Maps dont les « tuiles » qui constituent le fond de carte sont, dès les premières semaines de son lancement en 2005, scrapées par un développeur qui les intègre dans une application de recherche d’appartements à San Francisco. Au lieu de poursuivre le développeur en justice pour avoir hacké son service, l’entreprise décide de l’embaucher et rend publique une API pour encourager d’autres à développer des applications sur la base de Google Maps (Plantin et Valentin, 2013 ; Rieder, 2008).
linkThis article is available in English on Cairn International
Français

Si l’open data n’est plus une nouveauté aujourd’hui, il soulève cependant des questions qui sont, elles, loin d’être résolues par les producteurs et les réutilisateurs de données. Cet article propose une immersion au sein d’un hackathon organisé autour des premiers jeux de données ouvertes par un opérateur de transport ferroviaire, pour comprendre comment celles-ci sont coproduites par les réutilisateurs qui les intègrent dans des applications de mobilité. En combinant une approche écologique des mondes sociaux avec une ethnographie de l’activité technique, il montre que l’originalité de celle-ci réside moins dans le développement d’applications tel que les producteurs de données l’ont initialement espéré que dans le travail d’équipement des données ouvertes par de nouvelles propriétés permettant de les intégrer à des infrastructures informationnelles variées, à travers des définitions plus ou moins partagées à la frontière de mondes sociaux dont elles aident à coordonner les efforts autour de l’ouverture de nouvelles données.

  • donnée ouverte
  • objet intermédiaire
  • travail d’équipement
  • objet-frontière
  • infrastructure informationnelle
  • activité technique

Références

  • AGUITON C., CARDON D. (2008), Web participatif et innovation collective, Hermès, CNRS, vol. 50, n° 1, p. 75-82.
  • En ligneBOWKER G.C., BAKER K., MILLERAND F., RIBES D. (2009), « Toward Information Infrastructure Studies: Ways of Knowing in a Networked Environment », in HUNSINGER J., KLASTRUP L., ALLEN M. (dir.), International Handbook of Internet Research, Dordrecht, Springer Netherlands, p. 97-117.
  • En ligneBOWKER G.C., STAR S.L. (2000), Sorting Things Out: Classification and Its Consequences, Cambridge, Mass., MIT Press, 396 p.
  • En ligneBOWKER G.C. (2000), Biodiversity Datadiversity, Social Studies of Science, vol. 305, n° 5, p. 643-683.
  • BRISCOE G., MULLIGAN C. (2014), « Digital Innovation: The Hackathon Phenomenon », Working Paper No. 5, London, Queen Mary University.
  • CARDON D. (2019), Culture numérique, Paris, Sciences Po, 432 p.
  • CEFAÏ D. (2015), Mondes sociaux. Enquête sur un héritage de l’écologie humaine à Chicago, SociologieS, Dossier « Pragmatisme et sciences sociales : explorations, enquêtes, expérimentations », [En ligne] Disponible à l’adresse : https://journals.openedition.org/sociologies/4921 (consulté le 23/04/2021).
  • CERTEAU M. (1990), L’invention du quotidien. I. Arts de faire, Paris, Gallimard.
  • COURMONT A. (2018), De la « donnée » à la « donnée ouverte » : les épreuves de l’ouverture des données, Statistique et Société, vol. 5, n° 3, p. 19-23.
  • DE SOUZA C., REDMILES D., CHENG L.T., MILLEN D., PATTERSON J. (2004), « Sometimes you need to see through walls: a field study of application programming interfaces », Conference on Computer-Supported Cooperative Work (CSCW 2004), November, Chicago, p. 63-71.
  • DENIS J., GOËTA S. (2016), « “Brutification” et instauration des données. La fabrique attentionnée de l’open data, i3 », Working Papers Series, 16-CSI-01.
  • DENIS J., GOËTA S. (2017), « Les facettes de l’Open Data : émergence, fondements et travail en coulisses », dans Big data et traçabilité numérique. Les sciences sociales face à la quantification massive des individus, Paris, Collège de France (Conférences), p. 121-138.
  • DYMYTROVA V., PAQUIENSEGUY F. (2017), La réutilisation et les réutilisateurs des données ouvertes en France : une approche centrée sur les usagers, Revue internationale des gouvernements ouverts, vol. 5, p. 117-132, [En ligne] Disponible à l’adresse : https://ojs.imodev.org/index.php/RIGO/article/view/204/338 (consulté le 23/04/2021).
  • EDWARDS P.N. (2010), A Vast Machine: Computer Models, Climate Data, and the Politics of Global Warming, Cambridge, Mass., The MIT Press, 552 p.
  • EDWARDS P.N., JACKSON S.J., BOWKER G.C., KNOBEL C.P. (2007), « Understanding Infrastructure: Dynamics, Tensions, and Design », Working Paper, workshop « History and Theory of Infrastructure: Lessons for New Scientific Cyberinfrastructures ».
  • EGYEDI T. (2001), Infrastructure flexibility created by standardized gateways: The cases of XML and the ISO container, Knowledge, Technology & Policy, vol. 14, n° 3, p. 41-54.
  • En ligneGITELMAN L. (2013), Raw Data Is an Oxymoron, Cambridge, Mass., MIT Press.
  • GOËTA S. (2013), « Intéresser à la réutilisation des données : la participation des développeurs aux concours d’applications open data », 3es Journées doctorales du GIS : Participation du public, décision, démocratie participative, 22-23 novembre 2013, Bordeaux.
  • GOËTA S. (2016), Instaurer des données, instaurer des publics : une enquête sociologique dans les coulisses de l’open data, Thèse de doctorat en Sociologie, Paris, ENST, 267 p.
  • En ligneJEANTET A. (1998), Les objets intermédiaires dans la conception. Éléments pour une sociologie des processus de conception, Sociologie du travail, vol. 40, n° 3, p. 291-316.
  • KITCHIN R. (2014), The Data Revolution: Big Data, Open Data, Data Infrastructures and Their Consequences, London, Sage, 241 p.
  • LOUKIDES M. (2010), « What is data science? The future belongs to the companies and people that turn data into products », O’Reilly Media, [En ligne] Disponible à l’adresse : https://www.oreilly.com/radar/what-is-data-science/ (consulté le 23/04/2021).
  • En ligneMABI C. (2015), La plate-forme « data.gouv.fr » ou l’open data à la française, Informations sociales, vol. 191, n° 5, p. 52-59.
  • MARQUET C. (2016), Des services connectés pour améliorer l’accessibilité des gares ?, Espace Populations Sociétés, n° 2 [En ligne] Disponible à l’adresse : http://journals.openedition.org/eps/6344 (consulté le 23/04/2021).
  • En lignePETERS S., FAULX D., HANSEZ I. (2010), Le rôle des objets-frontière dans le découpage temporel et social d’une innovation de service, Revue d’anthropologie des connaissances, vol. 4, n° 1, p. 65-86.
  • PEUGEOT V. (2010), Les enjeux publics, économiques et citoyens de l’ouverture des données : l’expérience britannique, Document numérique et société, 15-16 novembre, Aix-en-Provence.
  • En lignePLANTIN J.C., VALENTIN J. (2013), Données ouvertes et cartographie libre, Les Cahiers du numérique, vol. 9, n° 1, p. 85-107.
  • RIEDER B. (2008), Entre marché et communauté : une discussion de la culture participative à l’exemple de Google Maps, Ludovia 2008 : Do it yourself 2.0, Aug 2008, France, p. 282-292.
  • ROSENTAL C. (2012), Éduquer par les démos. Usages de démonstrations de logiciel en situation d’apprentissage, Occasional Paper, Institut Marcel Mauss-CEMS, n° 8, [En Ligne] Disponible à l’adresse : http://cems.ehess.fr/docannexe/file/3008/eduquer_par_les_demos_claude_rosental.pdf (consulté le 23/04/2021).
  • En ligneSHIBUTANI T. (1955), Reference Groups as Perspectives, American Journal of Sociology, vol. 60, n° 6, p. 562-569.
  • En ligneSTAR S.L. (2010), Ceci n’est pas un objet-frontière !, Revue d’anthropologie des connaissances, vol. 4, n° 1, p. 18-35.
  • En ligneSTAR S.L., GRIESEMER J.R. (1989), Institutional Ecology, “Translations” and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39, Social Studies of Science, vol. 19, n° 3, p. 387-420.
  • En ligneSTAR S.L., RUHLEDER K. (1996), Steps Toward an Ecology of Infrastructure: Design and Access for Large Information Spaces, Information Systems Research, vol. 7, n° 1, p. 111-134.
  • En ligneSTAR S.L., RUHLEDER K. (2010), Vers une écologie de l’infrastructure, Revue d’anthropologie des connaissances, vol. 4, n° 1, p. 114-161.
  • En ligneTROMPETTE P., VINCK D. (2009), Retour sur la notion d’objet-frontière, Revue d’anthropologie des connaissances, vol. 3, n° 1, p. 5-27.
  • En ligneTROMPETTE P., VINCK D. (2010), Retour sur la notion d’objet-frontière (2), Revue d’anthropologie des connaissances, vol. 4, n° 1, p. 11-15.
  • TRUPIA D.V. (2019), Une ethnographie de l’innovation ouverte : le cas de « La Cantine Numérique », Thèse de doctorat en Sociologie, Noisy-Champs, Université Paris-Est, 650 p.
  • En ligneVINCK D. (1999), Les objets intermédiaires dans les réseaux de coopération scientifique : contribution à la prise en compte des objets dans les dynamiques sociales, Revue française de sociologie, vol. 40, n° 2, p. 385-414.
  • VINCK D. (2006), L’équipement du chercheur : comme si la technique était déterminante, Ethnographiques.org, 9 [En Ligne] Disponible à l’adresse : https://www.ethnographiques.org/2006/Vinck (consulté le 23/04/2021).
  • En ligneVINCK D. (2009), De l’objet intermédiaire à l’objet-frontière. Vers la prise en compte du travail d’équipement, Revue d’anthropologie des connaissances, vol. 3, n° 1, p. 51-72.
Dilara Vanessa Trupia [1]
Université Gustave Eiffel, LATTS, INSERM
  • [1]
    L’auteure tient à adresser ses plus vifs remerciements à Patrice Flichy pour ses conseils et son soutien. Elle remercie également Gaël Musquet et Andrew Byrd qui l’ont guidée dans les méandres des bases de données.
Cette publication est la plus récente de l'auteur sur Cairn.info.
Mis en ligne sur Cairn.info le 22/06/2021
https://doi.org/10.3917/res.228.0095
Pour citer cet article
Distribution électronique Cairn.info pour La Découverte © La Découverte. Tous droits réservés pour tous pays. Il est interdit, sauf accord préalable et écrit de l’éditeur, de reproduire (notamment par photocopie) partiellement ou totalement le présent article, de le stocker dans une banque de données ou de le communiquer au public sous quelque forme et de quelque manière que ce soit.
keyboard_arrow_up
Chargement
Chargement en cours.
Veuillez patienter...