Le hackathon : un dispositif à la frontière des mondes numériques

Mot-valise entre hack et marathon, le hackathon est un terme utilisé pour la première fois en 1999, par des développeurs du système d’exploitation libre Unix et les employés en marketing de Sun Microsystems, en référence aux rassemblements d’informaticiens et de passionnés consacrés à des activités de conception, de « bidouillage » et de hack informatique pour résoudre un défi technique (Briscoe et Mulligan 2014) [1]. Certains inscrivent les hackathons dans la continuité des LAN party, des rassemblements de joueurs qui utilisent un réseau local (Local Area Network) pour jouer à des jeux vidéo parfois pendant plusieurs jours consécutifs durant lesquels on alterne jeu, boissons caféinées et siestes sans quitter les lieux. En une décennie seulement, ce format a fait son chemin jusqu’au monde des organisations où il prend une tout autre réalité. Si les hackathons ont fait l’objet de plusieurs travaux réalisés successivement dans le monde des hackers (Coleman 2010), des initiatives citoyennes (Haywood 2013 ; Ermoshina 2018), de la recherche scientifique (Gruson-Daniel et de Quatrebarbes 2017) et du service public (Goëta 2013 ; Marquet 2016), il n’existe à l’heure actuelle pas ou peu de travaux réalisés sur son appropriation par les entreprises, dans des secteurs plus traditionnels de l’industrie. Comment se fait-il qu’un tel format puisse évoluer jusqu’à ce monde a priori bien éloigné ? Comment est-il réapproprié par les entreprises dans le but de faire participer les usagers et les employés dans la conception de nouveaux services ? Et qu’est-ce qu’il permet de produire concrètement ?

Le hackathon d’entreprise ne ressemble évidemment pas aux rassemblements de hackers  : il est souvent organisé sous la forme d’un concours d’applications et il n’est pas celui qui encourage le plus à hacker. Ici, les activités ne portent pas tant sur la résolution de problèmes techniques que sur la diffusion d’un produit ou le développement d’un service par une entreprise organisatrice. S’inscrivant dans le mythe des start-up californiennes, les projets sont évalués en raison de leur visée entrepreneuriale, comme des innovations de service pouvant aboutir à la création d’une nouvelle société. Des ressources sont identifiées en amont (bases de données, briques technologiques, etc.) et une série de supports est produite pour établir les conditions juridiques et techniques de leur utilisation par les participants. Le déroulé, les consignes et les problématiques sont formalisés dans des documents distribués aux participants qui doivent s’y conformer pour remporter le prix désigné. Un jury est soigneusement sélectionné et des critères d’évaluation mettent l’accent dès le début sur l’aspect innovant des applications à développer. La composition des équipes est d’autant plus importante que celles-ci se constituent autour d’une idée de service dont le développement peut faire l’objet d’une coopération a posteriori, avec l’entreprise organisatrice. Parfois, des points d’étape sont prévus pour s’assurer du bon déroulement du travail au sein des équipes et des mentors sont invités pour les accompagner dans des domaines de compétences variés. Enfin, le hackathon d’entreprise est aussi fortement médiatisé car ici, ce n’est ni la direction des systèmes d’information (DSI) ni celle de la recherche et du développement, mais souvent, les professionnels du marketing et de la communication qui prennent en charge leur organisation.

Objet d’un engouement au début des années 2010, cette reprise des hackathons par les organisations portait à croire qu’il suffit d’emprunter un format provenant des mondes numériques pour laisser libre cours à la créativité des salariés dont l’heureuse rencontre au sein d’un environnement jovial serait à l’origine de la création de projets nouveaux et originaux. Aussi séduisante soit-elle, cette idéalisation a aussitôt cédé la place aux déceptions quant à la capacité de ces dispositifs à créer des services numériques, et encore moins, des innovations de rupture. Les participants sont nombreux à rapporter des problèmes de coopération au sein des équipes et à insister sur l’impossibilité de produire des prototypes fonctionnels en 48 heures seulement. Certains attirent l’attention sur le caractère parfois banal des idées proposées par les équipes qui, pour la plupart, ne poursuivent pas le développement des projets initiés au sein de l’événement. Les résultats peuvent ainsi paraître comme étant bien plus rudimentaires que ceux initialement imaginés par les entreprises. S’ils n’anticipent pas un accompagnement pour assurer la survie des projets, ces acteurs peuvent eux aussi se voir reprochés d’utiliser le hackathon uniquement à des fins de communication. Nombreux sont ainsi ceux qui dénoncent le statut ambigu de ces rassemblements qui mettent les contributions bénévoles au profit d’une organisation. Pourtant, ces entreprises sont toujours de plus en plus nombreuses à s’en saisir dans le contexte spécifique de leur activité. Cela est sans doute l’indice que les principaux usages ne se sont pas construits là où ils étaient attendus, dans l’innovation de services.

Pour les acteurs provenant des secteurs plus traditionnels de l’industrie, l’organisation d’un hackathon relève en effet d’une double prétention. Elle se présente tout d’abord comme une manière d’apprivoiser les nouveaux objets qui émergent dans les mondes numériques, en organisant la rencontre avec les acteurs qui les développent et qui les utilisent. L’organisation de rencontres implique alors de résoudre une série de tensions pour faire coopérer des acteurs provenant de mondes sociaux hétérogènes dont les perspectives, les temporalités et les modes opératoires relèvent souvent d’exigences contradictoires autour de ces nouveaux objets [2]. Pour les organisations, le hackathon se présente ensuite comme un moyen d’expérimenter de nouvelles méthodes de travail et de développer la « culture numérique » des salariés. Il s’agit ainsi d’un moyen de s’imprégner de l’esprit exploratoire, expérimental et, surtout, entrepreneurial des mondes de l’innovation numérique. Or, là encore, la mise en place de ce type de dispositif ne va pas sans susciter des tensions au sein des organisations qui deviennent les lieux de confrontation à ce nouveau monde, confrontation pour laquelle le hackathon est initialement proposé comme solution.

Une immersion ethnographique au sein d’un hackathon interne d’une entreprise : le cas de l’Open Railway Hackathon

Comment ces nouveaux dispositifs organisent-ils la confrontation entre des mondes, c’est-à-dire des perspectives et des modes d’action hétérogènes ? Comment les tensions inhérentes à cette rencontre sont-elles résolues ? Cet article propose de développer cette réflexion à travers une immersion ethnographique dans l’expérience de l’Open Railway Hackathon (ORH), un hackathon interne organisé en 2012 par un opérateur ferroviaire européen, RailWay Company (RWC), autour du développement de nouveaux services par ses propres agents, pour les aider à mieux gérer les situations de perturbation, à partir des jeux de données ouvertes par RWC [3].

L’ORH se présente comme une situation de rencontre singulière entre les salariés d’une grande entreprise et un collectif composé de personnalités des mondes numériques qui sont invités en tant que mentors et membres du jury, à la fois pour encadrer et évaluer le travail des premiers. Au nombre d’une vingtaine, les salariés proviennent, pour la plupart, de différentes branches d’activités. Ils sont composés de développeurs, de concepteurs de technologies d’information, de techniciens, de designers, d’analystes et même de quelques agents travaillant en gare et sur les quais des trains. Le collectif de mentors, quant à lui, est composé d’une douzaine de personnalités identifiées pour accompagner les équipes dans des domaines variés (programmation informatique, logiciels libres, données cartographiques, etc.). Bien qu’il ne se revendique pas comme tel, ce collectif véhicule des représentations associées au monde des hackers. La plupart sont affiliés à des mouvements politiques qui diffusent l’idée de rendre les connaissances plus ouvertes et les organisations plus transparentes (open gov., open access, etc.). Cela dit, ces mentors ne participent pas à l’ORH pour accompagner les équipes dans les pratiques du hacking. Moyennant une rémunération proposée par l’entreprise, ils sont engagés dans une interprétation plus souple de l’éthique hacker (Himanen 2001 ; Levy 1994), pour accompagner les équipes dans l’esprit plus entrepreneurial du web et des mash-ups dans lequel de nouvelles applications sont développées à partir de l’interfaçage de services existants. D’autres interviennent dans le design de services, le développement business d’applications mobiles et l’exercice du pitch [4] devant des investisseurs, ici incarnés par les membres du jury.

Ce cas présente ainsi plusieurs intérêts. Le premier est qu’il offre l’opportunité rare d’observer la manière dont une organisation traditionnelle se saisit d’un nouvel objet (l’open data), en même temps qu’un format de coopération issu de la culture des hackers qu’elle expérimente pour la première fois. Une spécificité du cas étudié réside ainsi dans la temporalité suivant laquelle l’ORH est organisé : celle de l’exploration des pratiques, la constitution de collectifs de travail et la mise en place d’outils qui précède et accompagne la négociation des perspectives autour des données ouvertes. À ce titre, le hackathon est un excellent analyseur des enjeux de coopération qui émergent avec le développement de nouveaux objets dont le statut est encore flou pour ces organisations. L’autre intérêt de ce cas est lié à la situation de rencontre singulière qu’il permet de produire, entre les salariés de l’opérateur ferroviaire et un collectif d’acteurs ancrés dans les mondes « ouverts » du numérique. L’originalité du ORH tient ainsi à cette confrontation qu’il permet de créer entre des acteurs qui lui associent des significations et des objectifs variés. Au-delà de nouveaux services, le but de cette rencontre des mondes est aussi de produire une simulation d’une manière autre de travailler. L’observation de l’ORH permet alors d’accéder à la construction d’une nouvelle réalité, en action, à travers les interactions, à un moment où les catégories ne sont pas encore élaborées autour des tenants et des aboutissants des hackathons pour des entreprises éloignées des mondes numériques.

De l’analyse du cadre des coopérations vers une définition du « dispositif-frontière »

Comment cette rencontre a priori improbable a-t-elle pu avoir lieu ? Comment les salariés se sont-ils vus embarqués, et quelles formes de coopération le hackathon leur a-t-il permis de développer ? Précédemment, nous avons proposé de décrire ces coopérations à partir d’une ethnographie de l’activité technique qui porte sur les jeux de données ouvertes par RWC (Trupia 2021). Le présent article propose d’élargir la focale pour décrire les configurations coopératives qui se constituent cette fois-ci à l’échelle de l’événement, au niveau des interactions collectives entre les différents groupes d’acteurs qu’il arrive à enrôler en tant qu’équipe-projet, mentors et jury.

Cet article repose ainsi sur une application particulière de l’analyse écologique qui porte sur la manière dont le dispositif du hackathon arrive à cadrer les coopérations, malgré la diversité des objectifs qui lui sont associés par ces différentes catégories d’acteurs [5]. Ici, la notion de dispositif est employée dans une acception souple, comme un agencement d’éléments hétérogènes composé d’objets, de règles et de mots (Dodier et Barbot 2016). Dans le cas du hackathon, cet assemblage est composé notamment d’objets et d’outils techniques (bases de données, prototypes d’applications, etc.), d’énoncés et de consignes (développer des services, utiliser les données ouvertes, etc.) autour d’une problématique (gérer les situations perturbées, améliorer l’information-voyageur, etc.) dont la résolution nécessite de faire coopérer des mondes variés (opérateurs, start-up, collectifs numériques, etc.). Le constat est que si le hackathon parvient à cadrer les coopérations entre ces mondes, c’est grâce à la constitution d’un assemblage qui est à la fois suffisamment bien défini à l’avance et tout aussi flexible pour accueillir des stratégies de participation variées. Ce dispositif est ainsi régi par une double logique de coordination. D’une part, les participants sont invités à coopérer au sein des équipes auto-constituées. D’autre part, ces équipes-projets sont mises en concurrence face à un jury qui doit les évaluer. Au sein de cette structure commune, les participants développent, quant à eux, une pluralité de stratégies selon les objectifs spécifiques qu’ils y associent.

À travers le cas de l’ORH, cet article propose ainsi de décrire conjointement le cadre des coopérations et les stratégies de participation, en trois temps, correspondant chacun à une configuration différente des interactions : la constitution d’équipes autour des idées de services, le travail des équipes accompagnées par des mentors et la démonstration des projets devant le jury. Au fil de cette analyse, l’article identifie progressivement les caractéristiques « frontière » du hackathon, prolongeant ainsi le concept d’objet-frontière dans le cas d’un dispositif au sein duquel les acteurs provenant de mondes sociaux hétérogènes arrivent à coopérer, malgré la diversité des perspectives, des temporalités et des modes opératoires [6]. Il montre qu’au-delà d’une flexibilité organisationnelle et interprétative, le hackathon agit également comme une instance normative qui véhicule un certain nombre d’idéaux plus ou moins partagés par les acteurs dont il qualifie les rapports et ordonne les interactions autour des principes provenant des mondes de l’innovation numérique (agilité, autonomie, etc.), pour développer notamment la « culture entrepreneuriale » des salariés. À l’issue de cette analyse, l’article propose ainsi de définir la notion de « dispositif-frontière » non seulement comme un cadre d’action suffisamment flexible qui rend possible la confrontation de mondes variés, mais aussi comme un cadrage dont les propriétés lui sont associées par les acteurs engagés, selon le contexte spécifique de leur activité. Poussons maintenant la porte et entrons concrètement dans le hackathon.

Vendredi. La constitution d’équipes-projets : un art de s’associer, agilement ?

L’endroit a été choisi avec attention ; il reflète le souci d’une ambiance chaleureuse, conviviale, à la fois studieuse et suffisamment confortable pour accueillir les salariés venant travailler le temps d’un week-end. Les participants sont accueillis à l’entrée par une personne qui vérifie leur inscription. Une fois à l’intérieur, ils récupèrent un badge sur lequel ils écrivent leur nom et indiquent, selon un code de couleur, leur statut : rouge pour équipe, jaune pour mentor et vert pour juré. Les participants aux équipes sont invités à ajouter d’autres couleurs selon qu’ils sont designer, développeur ou porteur d’idée. Ces catégories traduisent la composition minimale des équipes. Sur une seconde table, une série d’objets est ensuite offerte aux participants. Le « kit de survie », tel que les organisateurs l’appellent, est composé de tee-shirts, de clés USB, de crayons, tous étiquetés avec le nom de l’événement. Si l’offre de goodies constitue un trait commun de ces événements, un participant initié remarque cependant que « c’est bien brandé pour un événement interne… ».

Une fois enrôlés et équipés, les participants s’installent progressivement dans la salle, en attendant que l’événement démarre à 18 heures. De nombreux participants se connaissent déjà. Mais cette attente est aussi animée par de nouvelles rencontres. Par rapport à d’autres hackathons, ces sociabilités prennent une forme particulière : au-delà de l’appartenance à une même organisation, c’est aussi l’étrangeté de cette configuration qui leur fait support. Certains expriment leur refus de travailler pendant le week-end. Ils passent seulement « pour voir », par curiosité. D’autres contribueront au travail des équipes, mais avec un engagement modéré. C’est le cas de Dorian, un informaticien qui participe en tant que designer : « je ne voulais pas trop coder ce week-end ». Des mentors et des membres du jury sont aussi présents ; certains ne font que passer, tandis que d’autres viennent de l’étranger et resteront durant toute la durée de l’événement.

Le but de cette soirée est d’organiser l’association des acteurs autour des projets. Elle démarre ainsi avec les mots d’introduction des organisateurs qui présentent le cadre officiel de l’événement. Si le hackathon permet de réunir une pluralité de perspectives, la production de ce contexte dépend notamment de la compréhension des règles du jeu et de l’accord commun sur ce cadre proposé. Les organisateurs présentent ainsi les trois grandes étapes, communes à tous : le pitch des idées et la formation des équipes le vendredi soir, le hack dès le samedi matin et ce, jusqu’au classement des équipes et à la remise des prix le dimanche soir. Le premier moment clé du hackathon consiste ainsi en la constitution des équipes autour des idées. Nous proposons maintenant de revenir sur les modalités d’interaction communes à travers lesquelles les participants sont invités à s’associer, avant de présenter les différentes stratégies qu’ils développent pour constituer des équipes-projets.

Du mythe des rencontres heureuses aux difficultés pratiques de constituer une équipe

À la fin de sa présentation, l’animatrice invite le public à un moment d’échanges informels : « rendez-vous dans une heure pour inscrire les équipes ». Des groupes de discussion se forment autour des problématiques de transports, des idées d’application, des fonctionnalités techniques et des données ouvertes. Des situations d’usage sont énoncées comme autant d’expérience subjective de la mobilité, en tant qu’usagers du réseau ferroviaire. Certains dessinent des schémas sur du papier cartonné tandis que d’autres montrent des exemples sur l’écran de leur ordinateur pour illustrer leur idée. Parfois, la disponibilité des données est débattue du point de vue des droits d’usage ou des modalités d’accès. Pendant ce temps, certains circulent entre les groupes, écoutent les discussions des uns et passent aux suivants. D’autres échangent avec les organisateurs ou se voient isolés en prenant l’apéritif. Malgré l’apparence détendue, ce moment est décisif dans la coordination des activités : c’est là que des objectifs communs sont définis, que les ressources nécessaires pour les atteindre sont identifiées et que les équipes se constituent autour des idées.

En règle générale, l’organisation de concours nécessite d’établir, toutes choses égales par ailleurs, les mêmes conditions de participation pour tous les participants. Dans le cas des hackathons, il existe ainsi une pluralité de méthodes pour que les équipes se forment au même moment, avec les mêmes contraintes (tirage au sort, préinscription, etc.). Parfois, les consignes et les thématiques ne sont révélées qu’au démarrage : les participants doivent concevoir une idée sur le tas, au cours des premières interactions. Les acteurs emploient abondamment le terme de « sérendipité » pour décrire ces heureuses rencontres. À l’origine, ce terme désigne dans le monde de la recherche scientifique, le fait que certaines découvertes se font par accident (van Andel et Bourcier 2008). Dans ce contexte, il permet de décrire les rencontres hasardeuses comme des moteurs de créativité où il revient aux acteurs de tirer parti de l’imprévu et de l’intégrer dans leur stratégie initiale. Les figures d’engagement qui dominent ces événements sont alors celles de la curiosité et de l’attitude exploratoire, toutes deux caractéristiques des logiques d’usages d’Internet (Auray 2011).

Contrairement à ce qu’elle laisse penser, la constitution des équipes est cependant issue d’un processus bien plus cadré qu’une auto-organisation spontanée. Dans la plupart des hackathons, les organisateurs institutionnels favorisent une réflexion préalable : un statut de porteur d’idée est établi et, parfois, il est demandé aux participants de choisir leur profil au moment de leur inscription. Cela permet d’assurer un nombre suffisant de projets, ainsi que de participants qui, en étant venus sans idée, peuvent s’y associer. Idéalement, cette logique d’appariement veut que ces deux groupes se rencontrent au démarrage, essayent de se convaincre mutuellement et négocient pour réunir les compétences nécessaires au développement de leur projet. Cela dit, cette constitution « agile » des équipes pose de multiples difficultés : les visions du projet peuvent diverger, les ressources peuvent être plus ou moins disponibles et la composition d’une équipe pluridisciplinaire peut s’avérer difficile selon les motivations spécifiques de chacun.

La participation peut reposer par exemple pour certains, sur une incitation financière : la plupart des hackathons proposent un prix et parfois une bourse aux gagnants pour qu’ils continuent à développer leur projet après l’événement. L’incitation monétaire est cependant loin d’être la seule explication. De la même manière que les développeurs de logiciels libres, les participants aux hackathons sont animés par une pluralité de motivations : le plaisir de la programmation et le désir de se rendre utile (Benkler 2011), la succession de don et de contre-don et l’entrelacement de l’intérêt à et de l’intérêt pour (Coris 2007), l’adhésion à une idéologie du partage (Crémer et Gaudeul 2004 ; Proulx et Couture 2006), le développement et la démonstration de compétences pouvant être valorisées sur le marché du travail (Lerner et Tirole 2003), ou encore, le sentiment d’accomplissement associé au fait de contribuer à une œuvre collective et la reconnaissance qui s’ensuit (Lakhani et Wolf 2003). Plus récemment, ces motivations sont associées au désir de réaliser un « travail complet » qui dépasse les séparations entre travail et loisir (Flichy 2017). Parmi les publics des hackathons, nombreux sont aussi ceux qui y participent pour développer et consolider leur réseau de relations professionnelles. Du point de vue des activités, ces rassemblements se présentent enfin comme des opportunités d’apprentissage qui portent aussi, au-delà des connaissances partagées explicitement, sur des compétences tacites acquises au cours de la pratique (Collins 2010).

Le cas de l’ORH présente cependant plusieurs spécificités. La principale réside dans le contexte d’association singulier qui se constitue par la coprésence de salariés appartenant à des départements et à des niveaux hiérarchiques variés au sein de RWC. Ce contexte se présente pour certains salariés comme une véritable « arène des habilités » (Dodier 1993) où ils doivent faire la preuve de leurs compétences, voire de leur virtuosité. Pour les organisateurs, il s’agit d’une expérience d’apprentissage coopérative qui constitue sans doute la dimension la plus recherchée. C’est ce dont témoigne Naomi, un des consultants qui accompagne l’organisation de l’ORH pour amorcer une « nouvelle dynamique » au sein de RWC :

Il y a deux objectifs : développer des projets et faire rencontrer des cultures complètement différentes. Tu as les cheminots et le monde des hackathons, des start-up, de l’agilité. C’est une question culturelle, de changement de méthodes de travail, quand les gens qui débarquent des start-up encadrent les salariés. (Conversation informelle, Naomi, consultante indépendante).

Si le hackathon d’entreprise cadre ainsi cette association à travers des objectifs d’apprentissage d’une nouvelle « culture », les participants peuvent cependant développer différentes stratégies pour atteindre leur propre objectif qui consiste, in fine, à développer de nouveaux projets. Voyons maintenant comment les équipes se constituent concrètement au sein de cet univers de moyens associés à l’autonomie et à l’agilité.

Des stratégies d’association qui transgressent l’esprit du hackathon

S’il revient aux équipes de résoudre les difficultés d’organisation, le principe d’autonomie ouvre aussi la possibilité de développer des stratégies de détournement. Un cas typique est celui des équipes préconstituées et professionnalisées dans la participation aux hackathons. C’est l’exemple des membres de Geekli.st, un réseau socioprofessionnel de développeurs informatiques dont certains participent régulièrement aux concours avec une même équipe préconstituée. De la même manière, il arrive que certains participent avec des collègues de travail et utilisent le hackathon pour mettre en visibilité leur projet. Bien que cette visée entrepreneuriale soit appréciée par les organisateurs, elle ne peut cependant être ouvertement encouragée. Elle suscite la réaction d’autres participants dont certains estiment qu’il s’agit d’une transgression de l’esprit du hackathon. C’est le cas par exemple d’une équipe qui est invitée par un représentant du RWC. Leur idée est préalablement prototypée et lors des pitchs, des voix s’élèvent parmi le public pour contester cet usage du hackathon : le représentant du RWC semble avoir là transgressé les limites implicites de ce qui, dans ces espaces d’auto-organisation, est considéré comme acceptable par un public initié.

Ces différentes stratégies permettent ainsi d’anticiper et de combler certaines difficultés de constituer des équipes sur le tas. Ainsi, dans des hackathons où les équipes se constituent au lancement, à partir des pitchs d’idées, il peut par exemple arriver qu’un porteur d’idée ne puisse pas convaincre les autres de s’associer à son projet et qu’il finisse par le développer en solitaire. Après tout, les participants ont choisi d’y venir sur leur temps de loisir et doivent pouvoir sélectionner les projets sur lesquels ils vont travailler. C’est aussi le cas des équipes qui se voient décomposées et recomposées au fil du week-end selon la fluidité des interactions : certains ne sont pas d’accord avec les orientations prises par le porteur d’idée, tandis que d’autres finissent par se greffer à une autre équipe avec laquelle ils ont de meilleures affinités. Il arrive même que des participants se désistent sans prévenir.

Ces situations sont cependant moins envisageables à l’ORH où certains se connaissent déjà et sont en présence de leur employeur. Aussi, l’ORH est précédé d’un appel à idées qui aide les équipes à se constituer. Le formulaire d’inscription permet d’anticiper la répartition des compétences et de garantir une composition pluridisciplinaire pour la réalisation des idées gagnantes. Les mentors sont sélectionnés et invités pour faire face aux incertitudes que présente l’auto-organisation aux yeux des organisateurs. Cela dit, ce n’est pas pour autant que les équipes arrivent à se constituer : les participants sont confrontés aux problèmes qui émergent malgré et parfois à cause de ce cadrage serré. La formalisation de certaines idées en amont de l’événement introduit une asymétrie d’engagement parmi les participants dont certains peuvent se sentir « abandonnés ». C’est ce dont témoigne Walid, un ancien conducteur de train qui travaille à la préparation des plans opérationnels de transports au sein de RWC :

C’est difficile, car il y a des gens qui réfléchissent depuis 10 jours à une idée et c’est difficile d’apporter une vision au projet. Les gens ne veulent pas faire de compromis. (Conversation informelle, Walid, Gestionnaire de moyens, RWC)

Environ une heure après, une des animatrices annonce le début des pitchs. Ceux-ci doivent décrire en seulement quelques minutes ce que l’application est censée apporter. Ils doivent être à la fois suffisamment clairs pour convaincre, et rythmés pour capter l’attention. Comme sur la place de marché, il faut savoir vendre une idée. Point de passage obligé, l’exercice n’est pas nécessairement maîtrisé par l’ensemble des participants qui passent l’un après l’autre pour présenter leur idée :

Bonjour, je suis chargé d’info-voyageur. Mon boulot, c’est de coordonner les annonces de retards et de perturbations. Vous imaginez bien le genre de situation avec les voyageurs (rires du public). Donc l’idée, c’est de développer une appli qui nous permet de leur proposer des trajets alternatifs en cas de perturbations.

Nous, on veut développer un chatbox entre le client et l’agent qui est le plus proche ou le plus à même d’y répondre.

Dans d’autres hackathons, on entend souvent les initiés formuler les idées sous forme de promesses pour « révolutionner » les pratiques existantes, connecter des mondes qui ne se parlent pas habituellement, trouver les « meilleures » solutions à des problèmes qui sont présentés comme s’ils n’avaient jamais été traités par quiconque auparavant. Dans la mesure où les participants s’expriment dans un air de jeu, l’ambition et la séduction sont ainsi encouragées. Pour exceller dans le pitch, il faut notamment savoir être en concurrence tout en gardant une attitude « bon enfant ». À cet égard, certains mentors identifient les difficultés éprouvées par les salariés à la culture de travail qu’ils associent à la grande entreprise :

Les participants ne sont pas habitués à travailler comme ça. Ils sont habitués à faire des réunions avec dix personnes en costard cravate… La prise de parole en public ou la préparation rapide de pitch, sélectionner les informations, les adapter au public, ils ne sont pas agiles (…) Tu sens qu’ils vont être lourds. (Entretien, Gérard, développeur indépendant)

Certains mentors vont jusqu’à juger les participants avec mépris, comme étant « des formés et pas des formateurs ». L’aspect compétitif se traduit cependant selon Naomi par la présence de salariés provenant de différents centres informatiques : « Il y a quand même un esprit de compétition », assure-t-elle avant d’ajouter en se donnant un air savant, « mais il faut les accompagner ». Si les équipes pourront développer une pluralité de stratégies de participation, les mentors sont ainsi invités à les orienter dans un cadrage particulier, celui des entrepreneurs, start-up ou indépendants, qui sont les principaux développeurs des applications numériques. Quant aux équipes, six arrivent à se constituer ainsi, pour développer 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, une 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, un tableau de bord permettant d’historiciser des données autour d’un incident en particulier. Une fois que toutes les équipes sont inscrites, l’événement est officiellement lancé. Quand la plupart des participants se dirigent vers la sortie, certains s’installent en groupe pour commencer à travailler.

Samedi. Le travail et l’accompagnement des équipes, entre autonomie et débrouillardise

De retour le lendemain matin, les participants se mettent rapidement au travail. À partir de ce moment-là, aucune instruction n’est formellement donnée : à part un « point d’étape » collectif prévu avec les mentors autour des jeux de données, ce sont les équipes qui doivent organiser leur travail pour produire un prototype jusqu’à la fin de l’événement. Si le porteur d’idée semble avoir une légitimité particulière, son intervention au sein des équipes n’est pas similaire à celle d’un « chef de projet ». La définition et la répartition des rôles doivent faire l’objet d’un accord commun, indépendamment des compétences de chacun. En fin de compte, les participants s’y engagent bénévolement. Nous proposons maintenant de revenir sur cette diversité des modes d’engagement et sur les difficultés de l’auto-organisation. Nous aborderons ensuite les stratégies que les participants développent pour produire les projets au sein des équipes.

Cadrage temporel des objectifs et modes d’engagement pluriels des participants

Les hackathons se déroulent souvent le week-end et cela constitue une contrainte importante pour les publics salariés. Ainsi, ce sont davantage des publics indépendants et entrepreneurs qui y participent le plus souvent. Si les équipes sont soumises aux mêmes contraintes temporelles pour développer les projets, en 48 heures seulement, les activités s’organisent cependant aussi selon les disponibilités de chacun : certains y participent pendant quelques heures, d’autres y restent toute une journée, mais repartent en fin d’après-midi et, enfin, il y a toujours ceux qui restent pour continuer à travailler pendant la nuit. Une organisation flexible s’impose au sein des équipes et c’est sans doute cette flexibilité qui introduit, par la même occasion, une dimension ludique sans laquelle l’événement ne saurait mobiliser les participants. Cette flexibilité s’exprime également dans le travail des équipes : peu importe le temps consacré, ici, c’est bien la mobilisation créative des ressources disponibles qui semble primer.

Si très peu de règles sont formalisées dans les hackathons, la plupart suivent un séquençage particulier qui rythme le travail en équipe. Une méthodologie est formalisée au sein du monde des entreprises, à travers une représentation schématique baptisée le « double diamant » qui sert de modèle pour les organisateurs de l’ORH. Forme compressée et simplifiée des étapes traditionnelles du développement d’un projet numérique, cette abstraction sert à modéliser l’organisation du travail de prototypage au sein des équipes-projets. D’abord, l’exploration du problème sous forme de brainstorming où il s’agit d’évaluer les alternatives et d’en sélectionner quelques-unes pour les présenter en séance plénière. Ensuite, c’est par test et itération que l’équipe développe concrètement le projet, à la fois en termes de développement informatique et de design d’interface. C’est en suivant ce modèle que les scénarii sont conçus en amont jusqu’au plus petit détail par les organisateurs en prévoyant par exemple des ateliers de travail en commun ou des sessions de formation pour accompagner les équipes-projets. Le groupe de mentors peut également orienter les équipes selon leur spécialité. Quant à celles-ci, même si elles sont libres d’interpréter les règles du jeu, la plupart respectent et même parfois demandent aux organisateurs de préciser ce cadrage en amont.

Le travail des équipes est ainsi réalisé durant des courtes séquences où les participants conçoivent un projet, organisent les étapes concrètes de sa réalisation et se répartissent les tâches pour les effectuer. Lors du passage d’une phase de développement à l’autre, les équipes doivent également produire une série d’arbitrage sur lesquels ils doivent s’accorder. Au cours de ces interactions, des conflits peuvent se cristalliser. Pour certains, ces contraintes ne sont simplement pas réalistes : on entend ainsi dire que « l’on n’innove pas véritablement lors d’un hackathon ». Au-delà des questions d’organisation, cela s’explique par des raisons techniques :

Développer un prototype fonctionnel, c’est utopique de dire que tu peux le faire en 48 heures. Normalement, on va voir un dév, on montre le projet et on demande : « ça prend combien de temps ? ». Le hackathon, c’est la démarche inverse. Tu te débrouilles pour montrer la trame de ton idée. (Entretien, Gérard, développeur indépendant)

Ce mentor à l’ORH en témoigne, ce sont les participants présents et les ressources tant matérielles que temporelles qui conditionnent le développement des projets au sein d’un hackathon. Les activités s’ordonnent et se définissent ainsi d’abord à travers ce cadre, comme une agrégation toujours singulière d’idées, de contenus et de code informatique. Voyons maintenant comment les équipes font face à ces contraintes partagées.

Développer des projets en 48 heures : une manière de contraindre les équipes à être créatif ?

Prototyper de nouveaux services en 48 heures ne va bien entendu pas de soi, avec les seules ressources mises à disposition par les organisateurs. Si le hackathon repose originellement sur une logique de contournement créatif, de tâtonnement et de bricolage, et si les façons inventives de travailler avec les « moyens du bord » y sont développées comme une forme de détournement (de Certeau 1990), cet « art de faire » s’apparente davantage à une prescription dans le cas de l’ORH. Les participants peuvent et même doivent importer des ressources par eux-mêmes. C’est ce témoigne Germain, un consultant de RWC sur l’open data pour qui, « sur un hackathon, tu n’as même plus besoin de coder, tu utilises des format-types et c’est pour ça que tout le monde va si vite ». Cela dit, dans les temps limités du hackathon, ce ne sont pas toujours des prototypes fonctionnels qui sont développés. Il arrive ainsi que des projets soient prototypés sous forme de maquettes, dont l’aspect technique se traduit davantage par une activité de bricolage informatique entre des outils, des logiciels et des formats préexistants. Dans certains cas, le prototype peut même voir son fonctionnement réduit à une simple formulation abstraite permettant d’illustrer une idée. C’est ce dont témoigne Dorian, informaticien de RWC, qui avoue lors d’une conversation informelle que « la plupart des choses sont fake (« fausses »). On n’a pas le temps d’afficher de réelles données, donc là, on va afficher des images statiques qui vont montrer que ça peut s’afficher ».

Bien qu’il n’existe aucune restriction ni consigne quant à la nature des productions, les équipes choisissent souvent de développer des applications mobiles. Ces stratégies de développement ne sont pas spécifiques à l’ORH : les équipes conçoivent rarement des prototypes de matériels informatiques (hardware) et quand elles le font, ceux-ci viennent toujours en support à une application téléchargée sur un terminal mobile. C’est le cas d’une équipe qui développe, lors d’un autre hackathon, une application permettant d’alerter sur les derniers passages du métro via un bracelet connecté. Celui-ci est prototypé grâce à un participant qui amène son module Arduino contenant un circuit intégré et du matériel de soudure. Parmi les dix projets, c’est celui-ci qui attire le plus l’attention du public qui exprime notamment une certaine lassitude face aux applications mobiles désormais banalisées. Par ailleurs, la plupart des projets présentés à l’ORH s’alignent sur les attentes des organisateurs de RWC. Ici, seulement une application semble sortir du lot, parce que « décalée ». Il s’agit de l’application permettant de mettre un usager en relation directe avec un cheminot à proximité. Lors d’une conversation, Naomi s’interroge notamment sur l’« acceptabilité » de l’idée par les cadres dirigeants de l’entreprise :

Je ne sais pas si ça va marcher, car ça remet en cause le mode d’organisation : ce n’est plus la RWC et les usagers, c’est les cheminots avec les usagers. C’est génial comme idée, mais ça touche à un enjeu interne. (Conversation informelle, Naomi, consultante indépendante)

Si les équipes sont libres de développer une pluralité de stratégies, elles ne produisent cependant pas toutes des projets capables de contourner les contraintes de l’événement de façon radicalement nouvelle. La nouveauté, en revanche, réside dans les manières de présenter ces projets. Les participants peuvent par exemple privilégier un prototype fonctionnel ou une présentation théorique. Ils peuvent miser sur l’aspect novateur de l’idée ou sur sa capacité à résoudre un problème technique. Dans ce cas-là, ce sont non seulement les maquettes qui arrivent le mieux à mettre en scène les idées, mais aussi les équipes qui maîtrisent le mieux l’art de la démonstration qui sont valorisées. Voyons maintenant comment les projets sont présentés à travers le cadrage entrepreneurial des démonstrations.

Dimanche. Les démonstrations et la production de rôles entrepreneuriaux

Le dernier jour, la configuration des lieux a évolué. Certaines équipes ont dormi sur place tandis que d’autres ont continué à travailler pendant la nuit. Cette atmosphère de fatigue va cependant progressivement se dissiper dans l’après-midi : en se rapprochant du temps des démonstrations, les échanges s’intensifient et les mouvements s’accélèrent. Avec le compte à rebours projeté sur le grand écran, les équipes sont prises dans une précipitation pour finaliser leurs travaux. À l’ORH, plus d’un expriment leur agacement quant à la qualité du travail contraint par le temps. En faisant des allers-retours entre l’interface de programmation et une carte géographique, Gérard assure qu’il n’a jamais codé aussi « salement » de sa vie. En tapant frénétiquement sur les touches de son clavier, il affirme dans un air agité que même s’il a dépassé les limites de la fatigue, il se sent malgré tout, dans une « forme olympique ».

Parallèlement, l’équipe se précipite pour préparer la présentation du projet, sous la forme d’une intervention orale, accompagnée d’un diaporama. Cette préparation demande souvent de revenir sur les différentes représentations produites au cours du week-end pour en construire le récit, le storytelling. Pour entraîner les équipes, un pitchcamp est prévu avec l’un des mentors invités à cet effet. Les équipes doivent ensuite faire une « démo » pour présenter publiquement le fonctionnement du dispositif technologique et démontrer l’originalité ou la capacité de celui-ci à résoudre les questions jugées décisives (Rosental 2009). Au-delà de leur rôle de « preuves de concept », les démos aident ainsi à construire le réseau dans lequel ces projets prennent sens (Rosental 2007). D’abord, elles font entrer de nouveaux acteurs face auxquels les équipes sont mises en concurrence : les membres du jury composés à la fois par des personnalités du monde de l’innovation numérique et des cadres dirigeants de RWC. Elles imposent ensuite une série de contraintes (trouver de bons exemples, argumenter sur sa faisabilité, etc.) qui reconfigurent les pratiques instrumentales et organisationnelles de la présentation de projets. Commençons donc par décrire la structure commune de cette activité pour présenter ensuite les stratégies que les équipes développent pour convaincre le jury.

La routine du pitch et l’entraînement des équipes au « tous entrepreneurs »

Les animateurs commencent à préparer la scène pour accueillir les présentations. Les membres du jury commencent eux aussi à arriver. Quelques-uns ont assisté au lancement de l’événement, mais la plupart ignorent le travail des équipes. De la même manière, ils ne sont pas tous connus des participants : directrice générale, directeur des services, directrice de la communication, etc. Ces « témoins » prennent leur place à droite de la scène. En citant un tweet envoyé par un des participants, Zoé annonce le début des présentations :

« On n’a pas besoin d’être hacker pour imaginer les applis de demain ». Et bien, c’est très vrai ! Vous êtes nombreux à travailler dans des filières métiers qui n’ont rien à voir avec l’informatique. Merci d’avoir participé à cette expérimentation…

La cérémonie commence par rappeler les critères d’évaluation et les prix pour les trois lauréats. Évidemment, les projets doivent être principalement jugés selon les objectifs annoncés au début de l’événement, c’est-à-dire selon l’utilisation des données ouvertes par RWC. Mais d’autres critères sont également définis. Dans la plupart des hackathons, produire un projet à partir de zéro (from scratch) et présenter un prototype fonctionnel sont des critères importants. Ce n’est pas le cas de l’ORH. Ici, le jury doit évaluer les applications surtout du point de vue de leur caractère innovant, c’est-à-dire de leur potentiel à produire des « changements visibles pour les usagers de RWC ». Les équipes doivent par ailleurs argumenter sur l’utilité de leur projet pour les voyageurs et le travail quotidien des cheminots. Un autre critère est celui de la performance technique, c’est-à-dire l’ingéniosité de l’intégration et du croisement de données. Aussi, il importe que les applications soient faciles à comprendre et à manier. Le jury doit ainsi évaluer l’interface, c’est-à-dire son design et son ergonomie, du point de vue des usagers. Enfin, les organisateurs proposent d’évaluer la « faisabilité technique et financière » des projets. Les équipes se voient ainsi enrôlées dans des start-up fictives, soucieuses des attentes des marchés, capables de proposer des scénarii relatifs à l’utilité économique de leur projet et disposées à promettre des livrables avant d’avoir les moyens de réalisation. La démonstration des projets est un jeu de rôle grandeur nature qui simule une réalité entrepreneuriale. Si cet aspect n’est pas toujours pris en compte par les équipes qui peuvent développer des idées décalées, des projets artistiques ou des applications sans réelle utilité, ce cadrage est pris au sérieux dans les hackathons d’entreprise qui, organisés habituellement pour organiser les relations de celles-ci avec des réseaux d’acteurs variés, véhiculent implicitement de nombreux horizons marchands, comme se faire embaucher, faire financer un projet ou devenir prestataire de l’entreprise.

Les consignes qui encadrent la présentation des projets sont communiquées à l’avance par les organisateurs. Les équipes doivent renseigner, sur un diaporama standardisé, un descriptif de l’idée, des données utilisées, des cas et des scénarii d’usage concret et des précisions sur les développements nécessaires pour en faire un service prêt à être déployé. Sur la base de cette forme imposée, une série de recommandations est également communiquée informellement aux participants. Le ton favorisé lors des présentations est celui d’une vulgarisation. En leur rappelant que les membres du jury ne sont pas tous des initiés, les organisateurs recommandent aux équipes de ne pas s’attarder sur les explications techniques. Avec l’horizon d’un prix à gagner, celles-ci doivent ainsi se mettre au service de l’efficacité du récit. La routine du pitch repose idéalement sur la création d’une intrigue par une situation problématique, la démonstration de la solution et l’argumentation en faveur de sa faisabilité. À partir de ce cadre commun, les équipes, quant à elles, peuvent développer plusieurs stratégies de démonstration pour séduire et convaincre les membres du jury. Voyons comment elles s’y prennent pour enrôler à leur tour leur public.

Présentation des projets et stratégies démonstratives

La première équipe prend sa place sur scène. Le participant qui démarre le pitch fait défiler son diaporama sur le grand écran, pour rythmer son discours. Les gestes et les expressions mimétiques du pitcheur contribuent à focaliser l’attention du public. Les pitchs les plus appréciés sont ainsi ceux qui engagent les corps dans la mise en scène des idées. Des plaisanteries ou des anecdotes participent elles aussi à susciter l’adhésion des auditeurs qui réagissent aux configurations originales s’éloignant des formalités. Quant aux contenus des projets, les réactions du jury ne s’alignent pas toujours avec celles du public : quand le premier insiste sur les qualités esthétiques des interfaces, il arrive que les seconds appellent à une évaluation des aspects plus techniques des projets.

Au sein de l’ORH, les équipes s’alignent davantage sur les critères d’évaluation proposés par les organisateurs. Ainsi, les stratégies permettent de constater surtout la performance des données ouvertes dans le développement de services aux agents et aux usagers de l’opérateur. En commentant les données, la plupart des équipes mobilisent, sur les recommandations des mentors, le narratif des résultats. Elles développent ainsi une diversité de gestes démonstratifs à travers lesquels les données sont manipulées par l’usager. Si l’ensemble des équipes doit anticiper des scénarii d’usages qui permettent d’incorporer les applications dans la vie des usagers, une stratégie démonstrative consiste à s’effacer derrière un ou plusieurs personnages fictifs placés dans des situations problématiques. Pour naturaliser davantage la prise en main de l’application, l’orateur se retourne ensuite vers le public et demande : « Qui n’a pas vécu une telle situation ? ».

L’élaboration de scénarii d’usage et la construction de ces récits reposent ainsi sur les connaissances des usagers quant à leur expérience subjective de la mobilité. Elles demandent cependant aussi de maîtriser la démonstration du dispositif matériel qu’il s’agit de faire fonctionner. C’est notamment à travers les « démos » que les équipes présentent les fonctionnalités qu’il faut activer. Elles recourent parfois à une mise en scène souvent construite au cours du week-end pour équiper le travail démonstratif : certains projettent des vidéos des lieux en activité, quand d’autres représentent des acteurs qui manipulent les applications. C’est le cas d’une équipe qui, tels des metteurs en scène, fait un repérage des lieux pour jouer et enregistrer une représentation théâtrale permettant de mettre leur application en situation. Face au risque du dysfonctionnement du matériel, quelques manipulations sont enregistrées à l’avance et la démo s’effectue en commentant oralement ces vidéos.

Menées avec conviction, ces stratégies démonstratives invisibilisent souvent le processus à travers lequel les projets sont développés. C’est précisément pour cela qu’il est demandé aux équipes de finir leur présentation par des estimations budgétaires permettant d’évaluer les coûts du développement technique des applications pour en faire un « produit minimum viable ». Le choix de ce jargon n’est pas anodin : c’est à travers lui que les applications sont redéfinies au-delà de leurs caractéristiques techniques, comme des opportunités marchandes. C’est aussi à travers ce jargon que les équipes cherchent à intéresser les acteurs de l’entreprise au développement ultérieur des projets et, ainsi, à élargir l’horizon des hackathons au-delà de la délibération des prix. C’est en ces termes que l’événement est clos par la directrice générale de RWC : « Maintenant, la question est de savoir comment on va accompagner les cheminots pour développer ces projets ».

Caractéristiques « frontières » des dispositifs d’innovation ouverte

Originaire d’une culture hacker, le hackathon est repris par de plus en plus d’entreprises éloignées des mondes numériques, pour coopérer avec ces derniers. La rencontre de ces acteurs hétérogènes lors d’un événement, autour d’un objet émergent et au statut flou tel que les « données ouvertes », ne semble pas pour autant aller de soi. Précédemment, nous avons mis en évidence comment le terrain du hackathon permet de rendre visible et de faire coexister une pluralité de perspectives par des acteurs qui expriment chacun des attentes différentes de l’ouverture des données (Trupia 2021). Dans le présent article, nous avons prolongé cette analyse en nous focalisant sur l’hétérogénéité des formes de coordination qui se développent à l’échelle de l’événement où les interactions sont cadrées selon trois configurations qui se constituent successivement entre les participants au sein des équipes, entre les équipes accompagnées par les mentors et enfin face au jury. Au sein de cette écologie particulière qui reconfigure les rapports sociaux à travers une répartition des rôles préalablement définis, les participants développent une pluralité de stratégies selon les motivations, les modes d’engagement et les attentes spécifiques de chacun.

Produisant parfois son propre débordement, le hackathon atteste ainsi d’une certaine flexibilité organisationnelle : si un cadre d’action commun parvient à se constituer, c’est précisément parce qu’il permet de transgresser parfois les règles, en vue d’atteindre les objectifs énoncés. Il en va de même pour les interprétations du hackathon qui offre suffisamment de possibilités pour convenir à des univers de représentation aussi variés que celui des hackers, des managers d’entreprises et, dans une moindre mesure, celui des salariés. Chacun parvient finalement à en faire un usage cohérent avec le monde auquel il appartient, en légitimant son point de vue. Au-delà de la pluralité des configurations coopératives, c’est bien cette flexibilité qui permet au hackathon de multiplier, au sein d’un même espace, les registres et les projets dans lesquelles les données ouvertes sont intégrées. Ainsi, c’est à travers la notion du « dispositif-frontière » que sont révélées ces formes de flexibilité sans laquelle le hackathon ne saurait tenir ensemble des perspectives, des temporalités et des modes opératoires si variés.

Si le principal apport théorique de la notion d’objet-frontière se situe dans sa capacité à décrire la nature du travail coopératif en l’absence de consensus, son application au dispositif du hackathon permet ainsi de s’interroger sur la manière dont un cadre d’action commun arrive à se constituer malgré la diversité des acteurs engagés. L’apport de cette notion ne se limite cependant pas au constat d’une flexibilité organisationnelle et interprétative qui caractérise ce type d’événement reposant avant tout sur le bon vouloir des participants. Pour ne pas vider la charge conceptuelle de l’objet-frontière, il est essentiel de capturer ce que cette notion véhicule également sur le plan de la standardisation (Trompette et Vinck 2009   : 16). Dans le cas du musée de zoologie, Star et Griesemer rendent compte de cette dimension infrastructurelle, à travers les méthodes standardisées et la production d’objets (Star et Griesemer 1989). Quant au cas du hackathon, l’incorporation de standards passe par une scénographie sociale et une logique de situation particulière qui, prises ensemble, reconfigurent les pratiques instrumentales et organisationnelles à travers des principes provenant des mondes de l’innovation numérique. Ainsi, les participants sont d’abord invités à pitcher des idées originales pour constituer des équipes-projets de manière agile. Ils sont ensuite censés s’organiser de manière autonome pour les développer de manière créative, avec les moyens du bord. Enfin, les équipes doivent convaincre les membres du jury, tels des entrepreneurs, que leur application est non seulement celle qui répond le mieux aux besoins des usagers, mais qu’il s’agit aussi de celle qui offre les perspectives de développement les plus prometteuses au-delà du contexte de l’événement.

Le hackathon agit ainsi comme un dispositif-frontière non seulement parce qu’il constitue un cadre d’action suffisamment flexible qui rend possible la confrontation de mondes variés, mais aussi parce qu’il exerce un cadrage dont les propriétés sont coproduites par les acteurs engagés, selon le contexte spécifique de leur activité. Le cas de l’ORH rend compte de l’organisation des hackathons dans le monde des entreprises où ils sont saisis comme une instance normative pour développer la « culture numérique » des salariés dont les rôles et les interactions sont mis en forme à travers les principes entrepreneuriaux qui caractérisent les mouvements de transformation valorisés dans les discours managériaux des grandes entreprises (Ughetto 2018).