<figure><img src="image_1.png" /></figure>

HAL
open science

# Valoriser l'espace d'apprentissage des Hackathons par l'approche des territoires créatifs

Inès Guguen-Gicquel, Sabine Cullmann

► To cite this version:

Inès Guguen-Gicquel, Sabine Cullmann. Valoriser l'espace d'apprentissage des Hackathons par l'approche des territoires créatifs. XVIIème colloque de l'AGeCSO, FNEGE - Dauphine, May 2024, Paris, France. hal-04631679

HAL Id: hal-04631679

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

Submitted on 2 Jul 2024

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

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

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Valoriser l'espace d'apprentissage des Hackathons par
l'approche des territoires créatifs

Sabine Cullmann

Faculté des Sciences Économiques et de Gestion, Université de Strasbourg, Beta (UMR 7522)

sabine.cullmann@unistra.fr

Inès Guguen-Gicquel

IUT de Saint-Nazaire, Nantes Université, LEMNA EA 4272

ines.guguen-gicquel@univ-nantes.fr

Résumé

Les Hackathons sont l'illustration par excellence de la mise en œuvre d'espaces de co-construction de savoir sous contrainte temporelle, ils ont été repris dans de nombreux domaines et ont développé une scénarisation impressionnante pour augmenter considérablement l'attractivité de l'événement. Cependant, peu de recherches portent sur la manière dont ces équipes de projet *ad hoc* se constituent et se structurent, sur leurs dynamiques et leur effet global sur la cocréation de savoir dans un contexte soumis à des fortes contraintes. Effectivement, un Hackathon se positionne dans le paradoxe des contraintes de la co-créativité et de la mise en tension entre liberté et contrainte. L'objectif de notre travail est de répondre à cette question par une approche en entonnoir : des *Grounds* en général, aux contraintes spécifiques aux Hackathons puis les dynamiques de développement de savoir. Notre recherche a été menée pendant un Hackathon en santé et repose sur l'analyse de trois études de cas, documentées pendant les cinquante heures de l'événement à l'aide de vidéos et d'observations. Notre analyse permet de décomposer i) la dynamique d'un Hackathon et de ses acteurs appartenant aux différents territoires créatifs, et ii) les dispositifs de coordination du processus de transformation d'une idée créative vers l'innovation et d'apprentissage commun.

Mots-clés : Hackathon, co-créativité, équipes de projet, espace d'apprentissage, études de cas

Abstract

Hackathons serve as an exemplary illustration of ephemeral spaces for the collaborative construction of knowledge under constraints. They have been embraced in numerous domains and have developed a impressive script to considerably enhance the appeal of the event. However, there is a deficit of empirical research that focuses on the way these *ad hoc* project teams are constituted and structured, on their dynamics, and on their overall impact on the co-creation of knowledge in a context subject to significant constraints. Indeed, a hackathon is paradoxical in that it is both constrained by the necessity for co-creativity and subject to the tension between freedom and constraint. The objective
of our research is to address this question through a funnel approach, beginning with an examination
of the broader context of *Grounds*, then focusing on the specific constraints associated with
hackathons, and finally, analyzing the dynamics of knowledge development within this context. Our
research was conducted during a health hackathon and is based on the analysis of three case studies,
documented during the fifty hours of the event using videos and observations. The analysis allows us
to deconstruct the following elements: i) the dynamics of a Hackathon and the actors involved,
belonging to the different creative territories; and ii) the coordination mechanisms for converting a
creative idea into innovation and shared learning.

Keywords: Hackathon, co-creativity, project teams, learning space, case studies
# Valoriser l'espace d'apprentissage des Hackathons par l'approche des territoires créatifs

## INTRODUCTION

Apparu vers la fin des années 1990 (Briscoe et Mulligan, 2014), le ‘marathon de hackers’, le Hackathon, a été conçu pour développer un code en communauté sous la pression temporelle d’un week-end. Depuis, ce mode de cocréation sous contraintes a été repris dans de nombreux domaines et augmenté d’une forte scénarisation pour en démultiplier l’attractivité. Il n’est pas surprenant que des organisations aient tenté de transposer cette construction d’événement complexe, combinant des contraintes et espaces d’autonomie, pour stimuler les capacités créatives de leurs collaborateurs.

En parallèle, la recherche académique s’intéresse, elle aussi, fortement à ce phénomène depuis des années (Angarita et Nolte, 2020 ; Briscoe et Mulligan, 2014 ; Russo, 2011) avec une progression de recherches en nombre ces dernières années sur des thématiques différentes et variées : l’innovation digitale (Briscoe et Mulligan, 2014), la santé (Angelidis, Berman et al., 2016), comme levier de la créativité (Bokoko, 2020), sa capacité transformationnelle (Dionne et Carlile, 2016), des études sur le phénomène Hackathon (Endrissat, 2018 ; Fabbri, Toutain et Glaser, 2018), des guides pour organiser un Hackathon (Pe-Than, Nolte et al., 2022 ; Nolte, Pe-Than et al., 2020 ; Pe-Than, Nolte et al., 2018), des revues de littérature et de perspectives de recherche (Falk, Nolte et al., 2022 ; Flus et Hurst, 2021), au niveau du design (Gréselle-Zaïbet, Kleber et Dejoux, 2018), comme outil d’apprentissage dans un cadre pédagogique<fnref n="1" /> (Kienzler et Fontanesi, 2016 ; Nandi et Mandernach, 2016), l’entrepreneuriat (Irani, 2015), le devenir des projets après le Hackathon (Nolte, Chounta et Herbsleb, 2020), en entreprise (Pe-Than, Nolte et al., 2022 ; Ronfaut, 2014), ou encore des aspects

<footnote n="1">¹ Ces études portent sur une méthode d’apprentissage par la préparation des étudiants avant le Hackathon (Kienzler et Fontanesi, 2016), sur le mode Hackathon comme outil pédagogique (Nandi et Mandernach, 2016) ou encore sur un Hackathon pédagogique (Gréselle-Zaïbet, Kléber et Dejoux, 2016).</footnote>
d'organisation de travail (Schulte, Nolte et al., 2022; Söderberg, 2021; Yong, 2021; Zukin et Papadantonakis, 2018; Gregg, 2015).

Cependant, peu de recherches portent sur la manière dont ces équipes de projet *ad hoc* se constituent et se structurent, sur leurs dynamiques et l'effet global sur la co-créativité dans un contexte soumis à des fortes contraintes. Pe-Than, Nolte et al. (2022) apportent des éléments venant de Hackathons d'entreprise. Tuckman (1965) identifie, au niveau psychologique, un séquençage de dynamiques dans des petits groupes, repris par Trainer et al. (2016) pour les Hackathons (voir aussi Pe-Than et Nolte et al., 2022) mais sans que les contraintes, hormis temporelles, soient prises en considération. Or, un Hackathon se positionne dans le paradoxe des contraintes de la co-créativité et de la mise en tension entre liberté et contrainte. L'objectif de notre travail est de répondre à cette question par une approche en entonnoir : des *Grounds* en général et de leurs dynamiques de création de savoir, aux contraintes spécifiques aux Hackathons jusqu'aux dynamiques de fonctionnement des équipes.

Pour ce faire, nous ouvrons notre analyse au niveau le plus large du concept des *Grounds* de Cohendet, Grandadam et Simon (2010) et des travaux de Cohendet, Parmentier et Simon (2017) sur les processus de co-construction de l'innovation dans les *Grounds*. Nous supposons un lien entre les caractéristiques des *Grounds*, la tension née des contraintes du processus et du projet, et la réalisation co-créative des projets dans un Hackathon. Avec Cohendet et al. (2017, p. 9), nous considérons le processus d'un Hackathon comme un processus d'apprentissage et de création sociale de savoir. Nous reprenons les concepts présentés par Pe-Than, Nolte et al. (2022) venant de Hackathons d'entreprise pour comprendre la constitution d'équipes, et les travaux de Tuckman (1965) et de Trainer et al. (2016) sur les dynamiques dans les équipes pour comprendre leur influence sur la capacité de dépasser les limites de la créativité.

Notre recherche a été menée pendant le Hacking Health Camp 2016 de Strasbourg. Nous avons sélectionné au hasard trois projets parmi les vingt-trois projets élus par les quatre cents participants.
Il s'agit de trois études de cas, documentées durant les cinquante heures de l'événement à l'aide de vidéos et d'observations.

Par conséquent, voici notre questionnement de recherche : sous l'influence des *Grounds* et des contraintes de co-créativité imposées dans le cadre d'un Hackathon, de quelle manière les équipes projet se structurent et se coordonnent-elles, quelles sont leurs dynamiques et effets sur la stimulation de la créativité, et quel est le processus d'apprentissage et de création sociale de savoir. Notre objectif est de comprendre à l'aide de trois études de cas le rôle de la constitution, des dynamiques et de la coordination d'équipes de projets de Hackathon dans le processus de la transformation d'une idée innovante vers une co-créativité sous contrainte.

# 1. CADRE CONCEPTUEL DE LA RECHERCHE ET POSITIONNEMENT PAR RAPPORT A LA LITTERATURE

La littérature scientifique sur les Hackathons reste relativement limitée (Pe-Than, Nolte *et al.*, 2022 ; Endrissat, 2018 ; Dionne et Carlile, 2016 ; Briscoe et Mulligan, 2014) bien que les entreprises soient friandes de cet outil (Pe-Than, Nolte *et al.*, 2022 ; Ronfaut, 2014). Plus précisément, la co-conception créative sous contraintes dans cette forme de communauté *ad hoc* et éphémère n'est pas étudiée, pas plus que l'étude des dispositifs de management du processus d'innovation.

Afin de compléter ces recherches, nous développerons notre analyse en entonnoir, et enrichirons trois volets de ce cadre :

- Le concept des *Grounds* (Cohendet, Grandadam et Simon, 2010) et les processus de co-construction de l'innovation dans les Grounds d'un Hackathon pour positionner les Hackathons : nous supposons que le concept des *Grounds* se reflète dans le Hackathon qui lui-même se structure selon les *Grounds*, à savoir l' *Underground* avec les participants, le *Middleground* avec les organisateurs et l' *Upperground* avec des organisations sponsors et partenaires. Nous supposons également que le processus de co-construction de l'innovation se retrouve dans le séquençage du Hackathon : de l'intention de l'idée créative émise sur le *Sparkboard*, mis en place sur la
plateforme de l'événement, à la phase de séduction qui correspond aux *pitchs* puis du marché de vendredi soir, jusqu'au *Landing* durant lequel ont lieu les présentations finales de dimanche soir.

- La co-conception créative sous contraintes dans les Hackathons se déroule dans le *Middleground* du Hackathon avec des contraintes de processus émanant de la scénarisation de l'événement et les contraintes de projets en fonction de leur cahier des charges ; ce paradoxe de contraintes de la co- créativité encadre la tension entre liberté et contrainte.

- Nous utilisons des concepts récents de coordination et de dynamiques de projets (Pe-Than, Nolte et al., 2022; Trainer et al., 2016) au-delà de l'agilité etc. afin de capter des particularités, éventuelles, de projets de Hackathon pour décrypter les équipes *ad hoc* d'un Hackathon et pour comprendre leur capacité à dépasser les limites de la créativité.

## 1.1. Présentation d'un Hackathon à travers le concept des Grounds et des processus de co-construction de l'innovation dans les Grounds d'un Hackathon

### 1.1.1. Le Hackathon à travers le concept des Grounds

Chacune des strates des *Grounds* (Cohendet, Grandadam et Simon, 2010) se compose d'un ensemble d'acteurs, de processus et de dynamiques impliqués dans la création d'idées créatives et de savoirs qui s'auto-alimentent continuellement. Dans cette approche, un Hackathon fait partie du *Middleground* qui relie l'*Under-* et l'*Upperground*. Les dynamiques du *Middleground* sont conditionnées par la réalisation d'événements, tels qu'un Hackathon, comprenant des projets qui engagent des communautés locales à collaborer (les projets présentés), de manière circonscrite dans l'espace et le temps.

Cependant, dans une approche plus microsociale, ce *Middleground*, qu'est le Hackathon, peut répliquer lui aussi ces trois strates. *L'Upperground* est constitué des entreprises qui mobilisent des projets et des collaborateurs comme porteurs de projets. Elles apparaissent en tant que sponsors, gratificateurs de prix et de récompenses, ou partenaires de l'événement. Ces entreprises et institutions apportent des projets internes et ouverts à la communauté dans le cadre de l'événement. Le Hackathon
devient également un espace de publicité et de communication pour l'entreprise à travers les
cérémonies de remises de prix et les différentes présentations et valorisations durant l'événement. Ce
faisant, il incarne un espace permettant d'identifier des acteurs et des compétences créatives à recruter
et des projets à s'approprier. Pour l'Upperground, le Hackathon est un terroir fertile d'acculturation
et d'apprentissage, une opportunité de marché. Le Middleground du Hackathon même est constitué
par la communauté des organisateurs qui ont créé ce lieu de rencontre entre l'Upper- et
l'Underground avec ces codes et des processus (d'exploration et d'exploitation) de co-conceptions
créatives sous contraintes (de projets et de processus). Finalement, l'Underground du Hackathon est
celui des participants, des porteurs de projets, des passionnés cherchant à apporter un don à la
communauté, dans la tradition du Logiciel Libre (von Krogh, Haeflinger et al., 2012), où
l'Underground procure ainsi l'espace des projets présentés à la communauté.

1.1.2. Les processus de co-construction de l'innovation dans les Grounds d'un Hackathon

Cohendet, Parmentier et Simon (2017) identifient trois grandes phases du processus d'idéation<fnref n="2" />, à savoir i) l'Intention, ii) la génération d'idées ou le *Spark*, iii) la conceptualisation de l'idée ou la Construction sociale et iv) la mise en œuvre ou le *Landing*.

L'Intention et l'étincelle de l'idée initiale, le *Spark*, reviennent à l'individu et représentent le lancement de la création collective. Dans le cadre du Hackathon, ce *Spark* est lancé par les porteurs de projet avec une idée de projet créatif, évoquant des émotions, des désirs, décrivant et provoquant des besoins pour stimuler et engager l'équipe créative. L'outil du *Spark* est le *Sparkboard* mis en place par le *Middleground*, les organisateurs du Hackathon. Ce *Spark* donnera du sens au Hackathon.

La troisième phase de la conceptualisation de l'idée correspond à la phase de la construction sociale des idées (Callon, 1999) : la création et le partage de sens et le partage de l'idée. Les porteurs des projets doivent séduire lors des *pitchs* de présentation, trouver des alliés dans le cadre du marché, le vendredi soir, ce qui les oblige à trouver toutes les compétences nécessaires pour constituer une

<footnote n="2">² Nous revenons sur ce processus dans le cadre de la partie 1.3.2. Étapes et dynamiques de la constitution de l'équipe : *Forming, Storming, Norming & Performing*.</footnote>
équipe, apprendre collectivement, nourrir communément les idées créatives avec du savoir dès le diner de vendredi soir, faire avancer, évoluer, progresser et faire émerger les projets.

La dernière phase, celle de la mise en œuvre, permet la reconfiguration de l'idée et sa transformation (vendredi à dimanche). L'idée est assez mature pour la présentation finale devant un jury (dimanche après-midi). Les porteurs des projets et leurs équipes reçoivent des prix, des récompenses et des aides pour poursuivre leurs projets. Le rôle du *Middleground* Hackathon en tant que *Knowledge Broker* prend ici toute son importance car il met en relation l'*Underground* des projets avec l'*Upperground* des organisations : elles ont accès aux projets créatifs et aux compétences et proposent des ressources pour accélérer l'émergence et la transformation en projets innovants.

Comme dans la construction commune de savoir, celle-ci est adaptative, incrémentale et itérative. Cependant, comme dans tout projet créatif et innovant cherchant l'adaptabilité et la réactivité face aux informations nouvelles, le projet est planifié et permet d'organiser le ou les objectifs, les jalons réguliers de validation du savoir crée, l'organisation des tâches et des livrables, le monitoring des contraintes et des ressources. Les équipes de projet du Hackathon bénéficient de la proximité spatiale inhérente à l'événement pour améliorer la réactivité et la créativité requises pour manager les changements continuellement apportés au projet pendant les cinquante heures du Hackathon. Les livrables intermédiaires et finaux pour la présentation finale du projet devant le jury sont planifiés ainsi que leurs spécifications.

Notre recherche vise à identifier les dispositifs spécifiques dans le cadre d'un Hackathon qui permettent aux porteurs de projet de coordonner plus ou moins habilement le processus de transformation d'une idée créative vers une innovation. Nous chercherons donc à savoir dans quelle mesure les dispositifs de coordination de la créativité et les dynamiques des équipes éphémères jouent le rôle de frein ou d'accélérateur du processus de développement de l'innovation dans le processus d'apprentissage et de création sociale de savoir.
## 1.2. La co-conception créative sous contraintes dans un Hackathon

Nous pouvons distinguer essentiellement deux formes de contraintes (voir aussi Russo, 2011) : les contraintes de processus et les contraintes de produit voire du projet. Un Hackathon procure un champ d'observation de cette tension spécifique entre liberté et contrainte que constitue le paradoxe des contraintes de la co-créativité.

### 1.2.1. Les contraintes de processus

Bien qu'il soit couramment admis que la pression tue la créativité (Amabile, 1996), le parti pris d'un Hackathon consiste justement à se dérouler généralement en cinquante heures maximum du lancement de l'événement le vendredi soir jusqu'à la présentation finale des *pitchs* des projets aboutis et de leurs résultats ou conclusions durant le dimanche après-midi par les équipes devant le jury. Les organisateurs s'appuient sur ce cadencement (Nolte, Pe-Than et al., 2020 ; Briscoe et Mulligan, 2014), une scénarisation et des outils (Schulte, Nolte et al., 2022) pour créer la dynamique propre et appréciée du Hackathon (Dionne et Carlile, 2016). Les participants au Hackathon connaissent et acceptent ces contraintes, notamment la pression temporelle qui conditionne et rythme le travail de l'équipe.

Selon Amabile (1996), la non-disponibilité de ressources et de compétences peut provoquer un sentiment d'inconfort ayant pour conséquence la mort précoce du projet. Si lors du marché et de la constitution des équipes du Hackathon (vendredi soir) le porteur d'un projet ne peut réunir toutes les compétences requises par les organisateurs, il doit abandonner son projet (en revanche, il peut rejoindre un autre). Csikszentmihalyi (1997) observe en revanche un risque d'endormissement si les ressources sont trop confortablement disponibles. La chasse aux ressources et compétences relativement rares dans un Hackathon, durant le marché, prévient ces deux écueils.

Une trop forte standardisation de routines et de processus, comme des routinisations d'outils d'idéation tels que le Brainstorming, peut, selon Hargadon et Sutton (1996) inhiber la co-créativité. En revanche, elle peut être stimulante si l'environnement est approprié et constructif. Un Hackathon
se déroule selon un cadre prédéfini constitué d'étapes (*pitchs*, marché, constitution des équipes, travail en équipe, *pitchs* finaux), avec une routine de repas, de coaching, de sessions de formation et de répétition, et du yoga, des massages et des sessions de karakó et de fête nocturnes pour temporiser entre standardisation rassurante et stimulation environnementale.

Les contraintes de processus qui sont données et mises en scène par les organisateurs peuvent avoir un impact sur la manière selon laquelle le travail des équipes sera fait. L'objectif et le bénéfice de ces contraintes sont de maintenir la dynamique et la tension toute particulière et propre à un Hackathon.

### 1.2.2. Les contraintes de projet

Dans le cadre d'un Hackathon, les contraintes de projet sont données premièrement par le porteur du projet avec l'objet du projet mais aussi, à un autre niveau, par les organisateurs en ce qui concerne les critères d'évaluation à respecter et appliqués par le jury. Les contraintes du projet peuvent limiter les alternatives de la solution créative. Elles peuvent restreindre ou modifier le résultat prévu ou l'intention du projet. En revanche, elles peuvent être utiles dans le cas de certaines équipes dispersées mais au risque de ne pas obtenir un résultat optimal.

Le cahier des charges (objectif, client, marché, profitabilité, ressources humaines, management de la propriété industrielle, etc.) détermine les attentes par rapport au produit attendu, les objectifs du produit voire du projet et la manière selon laquelle l'équipe les réalise. En tant que contrainte interne, il peut limiter la flexibilité du processus créatif. Cependant, le cahier des charges donne aussi du sens au projet. Son effet est positif quand il s'agit de clarifier et d'organiser le travail créatif.

Si le client et / ou le marché impose des contraintes trop importantes, celles-ci peuvent également pousser les équipes à sortir de leur zone de confort et à percevoir des idées nouvelles. Le but des projets d'un Hackathon est également de générer des solutions créatives qui sont utiles et nouvelles pour le client (Amabile, 1996). Cet élément n'est pas nécessairement pris en considération par les porteurs de projets, ce qui justifie que les organisateurs imposent des compétences complémentaires, le coaching des équipes par les experts et des sessions de formation avant et pendant le Hackathon.
En effet, les questions de profitabilité et de modèle économique, ou encore le management de la propriété industrielle, par exemple, émergent souvent pour la première fois dans ce type de contexte et doivent être traitées rapidement au risque, sinon, de détourner trop fortement l'attention et de freiner la créativité de l'équipe.

La particularité des contraintes de produit données, au cours d'un Hackathon, de manière explicite par les organisateurs et les porteurs de projets aura un impact sur le résultat du travail des équipes et sur l'ensemble de la compétition à laquelle participent les équipes.

### 1.2.3. Contraintes et créativité

*In fine*, nous mettons notre focus sur deux éléments clés qui conditionnent la co-créativité sous contraintes.

Les participants d'un Hackathon acceptent la forte pression temporelle dans un cadre de probabilité élevée de pensée créatrice car ils se sentent en mission (Amabile, Hadley et Kramer, 2002).

L'acceptation des contraintes et la volonté de donner à la communauté rappellent les travaux de von Krogh, Haeflinger et al. (2012) sur la pratique sociale observée dans les communautés de logiciels libres et que « *people's pursuit of visible carrots is at times interrupted by the larger quest for the invisible gold at the end of the rainbow* » (idem, p. 23). Cette perception de valeur peut être considérée comme cohérente avec la motivation « *care*» de von Krogh (1998).

C'est dans ce champ ambivalent que les équipes doivent œuvrer pour stimuler leur créativité et mettre en œuvre le processus d'apprentissage et de création sociale de savoir, au sein d'un groupe constitué spontanément de membres inconnus, dès le début du Hackathon, dans le but exclusif d'atteindre le résultat escompté.
## 1.3. Constitution, dynamiques et coordination d'équipes de projet

La littérature sur le management de projets dans le cadre de Hackathons (Angarita, Nolte, 2020) s'appuie généralement sur des éléments de l'agilité (Bokoko, 2020), sur des méthodes telles que le Design Thinking (Gréselle-Zaïbet, Kleber et Dejoux, 2018) ou des outils de travail utilisés comme le Slack lors d'un online-Hackathon (Schulte, Nolte, Spikol et Chouta, 2022). Enfin, Trainer et al. (2016), sur la base des travaux de Egolf et Chester sur la communication réussie dans des groupes et équipes (2013), et les études de Pe-Than, Nolte et al. (2022) concernant des Hackathon d'entreprise offrent des concepts complémentaires et nouveaux.

Pour notre analyse, nous nous concentrons sur la combinaison de ces concepts : l'origine de la constitution de l'équipe, les différentes étapes de leur dynamique, et l'effet de la proximité spatiale sur le mode de la coordination de l'équipe et de l'apprentissage. Ces concepts nous permettrons de retracer des similitudes et des différences entre un Hackathon classique et un en entreprise, de la capacité des équipes à créer des dynamiques en vue de la cocréation sociale de savoir.

### 1.3.1. La constitution de l'équipe : distinguer PET & FT

L'organisation des équipes et des questions de coordination sont plus particulièrement reprises par Pe-Than, Nolte et al. (2022). Dans leur analyse des Hackathons d'entreprise, ils identifient deux types de projets, à savoir les équipes préalablement existantes ('pre-existing teams' : PET) et les équipes spontanément formées ('flash teams' : FT). Toutes les équipes de Hackathons d'entreprise se caractérisent par une forme de 'familiarité' (Trainer et al., 2016) et partagent avant tout les mêmes savoirs, valeurs, normes et objectifs de l'entreprise et de communauté de travail. Les participants des FT apprécient le réseautage, de faire de nouvelles connaissances et d'apprendre avec et des autres, tandis que les PET considèrent l'engagement dans le Hackathon comme une preuve de leurs compétences appréciées par le management et de leur loyauté à l'entreprise.

Cependant, les PET et les FT se différencient au niveau de la coordination et de leur capacité de concevoir des innovations.
La coordination des équipes PET s'avère très proches de celle des projets de tous les jours auxquels les équipes sont confrontées dans leur travail quotidien. L'innovation développée se maintient plutôt à l'intérieur de ce cadre. En revanche, les équipes FT appliquent un mode de travail ajusté au Hackathon et définissent des rôles de coordination nouveaux en les adaptant à la situation et à l'événement ; leurs innovations dépassent les frontières du travail conventionnel. Plus particulièrement, dans les FT, où s'exprime fortement l'esprit de communauté, on observe la production volontaire et spontanée de savoir dont un membre de l'équipe a besoin. C'est justement ce que les membres d'un FT apprécient: la création sociale de savoir complémentaire et nouveau pour chaque membre de l'équipe, de pouvoir rafraîchir leurs compétences existantes par le bénéfice tiré de la simple exposition aux personnes et à leurs compétences nouvelles, diverses et variées (Pe-Than, Nolte et al., 2022, p. 305). Les PET, en l'occurrence, préfèrent généralement développer le savoir requis pour réaliser le projet. La familiarité donne un avantage aux PET car elle permet d'utiliser et d'exploiter davantage du savoir existant.

Si l'on transfère ce constat aux Hackathons non-entreprise, donc classiques, on peut observer que certaines équipes sont déjà préconstituées, au moins partiellement, avant le Hackathon, et qu'elles participent en tant qu'équipe portant leur projet commun. Le *Sparkboard* permet aux participants de s'informer des projets avant le Hackathon et de communiquer aux porteurs leur intérêt. Au moment du marché, ces équipes peuvent être complétées par des volontaires. On peut également observer des équipes qui se constituent spontanément tels que les FT. Et ils existent des versions hybrides entre PET et FT. Les participants d'un Hackathon recherchent la construction cognitive d'idées nouvelles afin de les transformer dans un projet innovant.

### 1.3.2. Étapes et dynamiques de la constitution d'équipe : Forming, Storming, Norming & Performing

Les travaux de Trainer et al. (2016) analysent, entre autres, la formation et les dynamiques d'équipe dans le cadre de Hackathons technologiques dans le but d'aborder des questions sociales. Ces
recherches leur permettent d'observer différentes étapes de la constitution d'équipes, à savoir le *Forming*, le *Storming*, le *Norming* et le *Performing* (Tuckman, 1965 ; voire aussi Egolf et Chester, 2013, cit. in Trainer et al., 2016). Bien que le modèle de Tuckman identifie des étapes de constitution d'une équipe, nous observons une proximité intéressante avec le phasage et le processus d'apprentissage et de création sociale de savoir de Cohendet et al. (2017, pp. 7) : Intention, *Spark*, Construction sociale et *Landing*.

Dans la phase de la constitution de l'équipe, le *Forming*, il s'agit d'identifier la nature de l'activité et du projet et de comprendre l'objectif, les compétences et les savoirs requis pour s'approprier et réussir le projet. Selon Cohendet et al. (2017, p. 19), l'Intention sert également à la définition de l'objectif commun et de l'identification des problèmes. Durant l'étape suivante, le *Storming*, apparaissent les conflits potentiels alors que les membres de l'équipe construisent leurs places et leurs positionnements au sein de l'équipe en cours de constitution. En l'occurrence, la phase *Spark* cherche la génération d'idées en utilisant des outils spécifiques, mais ne soutient pas la structuration de l'équipe. La troisième phase, le *Norming*, permet à l'équipe d'échanger des informations sur les tâches à réaliser, d'organiser le travail et de développer à la fois des process et styles de travail, par exemple le découpage des sections de travail, les routines de réunion agile, le mode de communication pour transférer ou encore valider les contenus de travail. Cette 'normation' apparaît également chez Cohendet et al. (2017) et permet la construction sociale de sens partagé, de construire l'identité et la valeur. Au cours de la dernière étape, le *Performing*, l'équipe travaille efficacement avec une interaction émotionnelle minimale tout en adhérant aux normes établies préalablement : l'équipe réalise le projet, le *Landing*.

Ces étapes de constitution des équipes et le phasage et le processus d'apprentissage et de création sociale de savoir d'un Hackathon sont aisément observables, même si chaque équipe les franchit à son rythme et sont caractéristiques des modes de fonctionnement de projet.
### 1.3.3. Coordination d'équipes : Radical collocation & Team coordination

Dans leurs recherches, Pe-Than, Nolte et al. (2022) et Trainer et al. (2016) se réfèrent à l'effet de la collocation radicale sur la coordination d'équipes. Effectivement, si les membres d'une équipe collaborent dans un espace physique unique, les résultats montrent qu'elles sont généralement davantage auto-dirigées, motivées et se libèrent des contraintes autres que le temps. Cette concentration spatiale exerce aussi un impact sur leurs pratiques, leurs normes et la proximité développée parmi les membres de l'équipe, ce qui permet d'optimiser *in fine* la collaboration (Pe-Than, Nolte et al., 2022, p. 284).

En effet, dans un Hackathon, les membres d'une équipe sont réunis dans un seul espace commun (seul dans une salle ou dans un espace partagé avec d'autre équipes), adoptent un mode de coordination partagé et se soumettent à la contrainte principale de l'événement : une durée de cinquante heures. Cette collocation radicale favorise la familiarité, le partage des mêmes normes, valeurs et pratiques de travail, entre collaborateurs (Trainer et al., 2016, p. 2).

Cependant, concernant le choix de projet, les PET qui ont déjà travaillé ensemble, partagent déjà des normes et objectifs. Cette homologie peut leur permettre de s'organiser vers les consensus plus rapidement. Les FT, en revanche, ne disposent pas de cette condition préalable et choisissent leurs projets selon d'autre critères.

La définition de l'objectif partagé du projet voire de l'équipe s'avère alors fondamentale pour les équipes d'un Hackathon. Comme d'ailleurs dans tous les projets !

Notre recherche a pour objectif d'enrichir les concepts présentés, et ce sur trois niveaux d'analyse, à savoir :

i) Le rôle des *Grounds* dans un Hackathon permettant aux porteurs de projet de coordonner le processus de transformation d'une idée créative vers une innovation, et les dispositifs de coordination de la créativité et les dynamiques des équipes ;
ii) Le champ ambivalent de la co-créativité sous contrainte dans lequel l'équipe œuvre pour stimuler la créativité et la motivation, équipe constituée spontanément et de membres inconnus afin de développer le résultat escompté ;

iii) L'origine de la constitution de l'équipe, les différentes étapes de leur dynamique, et l'effet de la proximité spatiale sur le mode de la coordination et de création de savoir de l'équipe.

Notre recherche s'inscrit dans ce cadre conceptuel et nous permet de répondre au questionnement suivant : dans le cadre d'un Hackathon, de quelle manière les équipes se constituent-elles ? Quel processus de collaboration et quel mode coordination peut-on observer ? Pour ce faire, nous analysons trois études de cas réalisées lors d'un Hackathon.

## 2. METHODOLOGIE : ETUDES DE CAS

Pendant le Hacking Health Camp 2016 de Strasbourg, trois projets parmi les vingt-trois projets élus par les quatre cents participants ont été sélectionnés au hasard. Suivant les recommandations d'Eisenhardt (1989), nous comparons ces trois projets d'innovation du domaine de la santé afin d'analyser ces trois processus de transformation d'une idée créative vers une innovation.

Durant ces cinquante heures du Hackathon, ces trois projets ont été observés (observation non-participante ou shadowing<fnref n="3" />), filmés et photographiés. Ces documents ont été décryptées à l'aide de grilles d'analyse intégrant les éléments du cadre conceptuel présenté préalablement : le processus de co-construction de l'innovation dans les Grounds d'un Hackathon, la co-construction créative sous contraintes, et la constitution, les dynamiques et la coordination d'équipes de projet d'un Hackathon.

Conformément à notre cadre conceptuel, nous supposons que ce dispositif se traduit à deux niveaux, à savoir :

i) Dans le contexte propre de cette créativité organisationnelle sous contrainte avec les éléments de structuration (la plateforme Slack, conférences, sessions d'entrainement, karaoke et fête

<footnote n="3">³ Le shadowing ou l'observation non-participante sont des méthodes ethnographiques et sociologiques pour réaliser une observation in-situ et in vivo avec un segment réduit d'utilisateurs observés afin de collecter des données qualitatives concernant des interactions, des relations, des pratiques et des comportements plutôt que des déclarations (voir aussi Sirris et al., 2022).</footnote>
nocturne), d'accompagnement (coachs et experts, staff, journalistes) et une scénarisation
(animations, pitchs, marchés, repas) et

ii) Dans le mode de fonctionnement au niveau du management de projets, les rôles des membres d'équipes, le rôle et le mode de management des porteurs de projets, de la gestion de conflits, et dans l'élaboration et la présentation finale des livrables.

Ces trois projets (rendus anonymes) sont :

1. Le projet Plateforme : une plateforme de mise en relation d'acteurs de santé,

2. Le projet Jeux : un jeu vidéo pour un enfant handicapé,

3. Le projet Casque : un casque pour des patients atteints d'un AVC (Accident Vasculaire Cérébral).

Reste à préciser que les conditions de travail des trois équipes sont bien conformes à la collocation radicale de Trainer et al. (2016) et tout de même pas identiques : les projets Plateforme et Casque sont dans deux salles différentes avec trois à quatre autres équipes, soient avec une quarantaine de personnes dans chaque salle qui sont par conséquence très animées et bruyantes. Cependant, chaque projet dispose d'un espace propre et dédié avec des outils tels que de grandes tables, paperboards etc.

Le projet Jeux est seul dans une salle avec le même équipement. Pour le repos, les organisateurs mettent à disposition des chaises de repos et des matelas dans les salles de travail et dans des salles spécifiques de repos. Sont mis à la disposition de tous les participants tout au long du Hackathon : des repas, collations, boissons de tout type, massages, sessions de yoga, karakó la nuit pour éveiller les esprits, événements surprise (vidéos *freezing*), ateliers, conférences, *interviews*, etc.

La description des projets se compose de deux parties, i) la constitution de l'équipe et ii) le processus de collaboration.

## 2.1. Projet 1 : Une Plateforme de mise en relation d'acteurs de la santé

### 2.1.1. La constitution de l'équipe

Vendredi soir, le projet Plateforme est présenté lors des *pitchs* par les porteurs, un couple Néerlandais.

Le but du projet initial est d'élaborer une solution pour s'auto-recruter entre médecins et d'autres
porteurs de compétences pour créer des solutions *ad hoc* du domaine de santé. Les porteurs prévoient
la possibilité d'évaluer et d'effectuer des recherches sur ce réseau communautaire (avec comme
critères, par exemple, les compétences et le temps disponible ou le niveau d'engagement pour un
projet). Il s'agit d'une sorte de nouveau *LinkedIn* ou de *Facebook* dédié aux projets de type
Hackathon. L'objectif est un prolongement du projet après le Hackathon avec l'évaluation des
participants pour constituer un historique des participations antérieures permettant une évaluation des
projets.

L'équipe constituée lors du marché compte douze personnes ; elle est l'équipe la plus
internationale du Hackathon : des Allemands, Polonais, Italiens, Français, et Néerlandais, avec des
compétences variées : médecins, informaticiens, ingénieurs, entrepreneurs, scientifiques et des
attentes très diverses. La langue partagée est l'anglais. L'équipe compte aussi des hackers et pas de
réel patient (inutile dans le projet de toute façon).

2.1.2. Le processus de collaboration

Le processus de cette équipe se divise en deux grandes étapes, à savoir

i) Un tour de table de presque vingt-quatre heures pour connaître les attentes de chaque membre et de définir voire s'accorder sur l'objectif du projet,

ii) La conception et le codage de la solution, et, en simultané, la préparation du *pitch* final.

Phase 1

Pour démarrer la collaboration, l'équipe fait un tour de table très détaillé afin de présenter, avec beaucoup d'introspection, les participants, et faire connaître les attentes, les idées et les besoins de chacun par rapport au Hackathon et par rapport au projet élu. Ce tour de table de vendredi soir à samedi après-midi a pour conséquence que le projet ne rentre en phase de schématisation conceptuelle uniquement qu'au bout de vingt-quatre heures de travail. Au moment de l'observation, les deux porteurs ont beaucoup de mal à recadrer les choses ; ils relancent au fur et à mesure la discussion à l'aide d'outils et de concepts et d'input de littérature rapidement présentés.
Tous les membres de l'équipe souhaitent créer ou développer du réseau et faire des rencontres professionnelles et de projets ; certains, par exemple, cherchent à exploiter l'événement pour recruter pour leur propre compte et l'assument d'ailleurs. L'équipe se met finalement d'accord sur les grandes lignes de l'objectif commun du projet, en intégrant l'apport de chacun et ceci sous la modération des porteurs : une plateforme qui permet de mettre en relation des acteurs de la santé. Quelques membres de l'équipe révoquent cet objectif en énonçant des doutes et des pistes d'améliorations éventuelles.

## Phase 2

Pendant que les développeurs démarrent l'application, la porteuse du projet se réunit avec quatre membres de l'équipe à la cafétéria pour préparer la structuration et la logique de l'argumentation du pitch final. Ils revalident l'objectif de la plateforme et organisent une réunion avec des coachs en entrepreneuriat et design. L'input des coachs est restitué à l'équipe ce qui relance une discussion et un peaufinage de la stratégie animé par le porteur du projet, et l'équipe s'applaudit. Hormis les développeurs qui codent, chacun s'occupe individuellement ou en petite équipe d'un livrable qui composera le savoir nécessaire pour la présentation finale et le soumet à l'équipe pour discussion. Un membre propose une ébauche de présentation finale, critiqué par un autre membre en tant que trop compliqué ; le porteur du projet réplique avec « *and your proposition ?* » avec le résultat que la porteuse réorganise et travaille la présentation. En réponse aux questions posées par le porteur « *where is the added value ?* » et « *what can we show ?* », les membres de l'équipe s'expliquent mutuellement le projet, et vont de l'engagement vers le consentement – seuls trois membres ne sont pas encore convaincus. Le projet final prend forme, il est, comme le dit un membre, « 20 minutes avant la fin, le projet est différent et plus complexe qu'au début » et l'équipe s'applaudit. Le porteur observe l'équipe ; il laisse l'équipe présenter le projet au coach entreprise & projet et répondre à ses questions. Le coach demande beaucoup de temps pour comprendre le projet et pour faire des propositions qui semblent sortir de la stratégie des porteurs du projet ; le porteur reprend et redirige l'équipe. Les porteurs et deux membres travaillent sur le nom du projet et la démo finale, aidés par
un coach et deux étudiantes en design qui demandent finalement une rémunération pour l'utilisation du logo développé ensemble en dehors de l'événement.

Le dimanche est essentiellement utilisé pour finaliser la démonstration technique, l'argumentation, la logique et le déroulement du *pitch* final de trois minutes. Le projet Plateforme est présenté peu après 17h, et le projet est récompense par un prix.

## 2.2. Projet 2 : Des Jeux vidéo pour un enfant handicapé

### 2.2.1. La constitution de l'équipe

Le projet Jeux est issu de la collaboration d'une école de design et de codage et d'une association de membres et d'amis de la famille d'un enfant atteint d'une maladie rare. Cet enfant de onze ans ne peut s'exprimer qu'avec ses yeux et en penchant sa tête à gauche et à droite. Le porteur du projet, le cousin de l'enfant, a proposé ce projet au directeur de l'école qui lui l'a proposé au Hacking Health Camp afin d'accélérer le développement du jeu.

Par conséquent, l'équipe projet s'est créée avant l'événement et se compose au total de huit personnes identifiées avant l'événement : le porteur du projet, un graphiste et ami du porteur, ainsi que six étudiants de l'école qui se sont (a priori) portés volontaires pour participer au projet et au Hackathon. Cinq étudiants sont des développeurs en première année, et un étudiant est développeur en troisième année, qui utilisera ce projet pour son mémoire, et il est désigné en tant que chef d'équipe. S'y greffera, lors du Hackathon, une orthophoniste dont le projet n'a pas été élu mais qui souhaite participer au projet.

Le cahier des charges a été défini préalablement par le porteur du projet avec les parents de l'enfant notant ses préférences pour les jeux de courses, les voitures et les Pokémons, ainsi que ses capacités pour utiliser une tablette oculaire.

### 2.2.2. Le processus de collaboration

Le phasage présenté a été identifié par le graphiste lors du Hackathon. Il a défini trois phases :
i) À partir de vendredi soir, le planning du projet avec objectifs, tâches etc. et une grande phase de travail jusqu'au départ d'une personne le samedi matin,

ii) La finalisation des jeux jusqu'à samedi soir, et

iii) Dimanche, la préparation de la démonstration et le livrable final.

## Phase 1

Puisque presque toute l'équipe se connaît d'avant l'événement, le porteur du projet précise l'idée du projet, les objectifs généraux, les contraintes et les exigences fonctionnelles liées à l'enfant comme seul utilisateur du jeu à développer.

Après le départ du porteur vers 23h, le chef d'équipe propose la planification du développement qu'il a préparé préalablement. Il énonce les objectifs intermédiaires et finaux, ainsi que le déroulement temporel idéal. A partir de ce moment, un membre de l'équipe propose une alternative, critique et met l'autorité du chef d'équipe continuellement en question. Ce conflit d'autorité se poursuit tout au long de la nuit, éclate le lendemain vers 11h et se termine par le départ de ce membre.
Les autres membres de l'équipe soutiennent plus ou moins ouvertement le chef d'équipe et tentent, en vain, de calmer leur collègue pour qu'il reste. Le porteur du projet revient peu après le départ de ce membre.

Pendant cette première phase, chaque membre de l'équipe accepte les tâches et livrables auxquels il s'est engagé, les produit et les soumet, en cas de besoin, aux autres membres de l'équipe pour connaître leur retour et validation le cas échéant.

Physiquement, les membres sont groupés autour la grande table, une personne travaille debout, le graphiste à un autre table et le membre qui partira est seul assis par terre. Le chef d'équipe répond aux questions des autres, aide et propose des solutions ; il demande également de l'aide ou d'un retour en cas de besoin.

## Phase 2

Après le départ du membre d'équipe opposant, le chef d'équipe reprend son travail pour le corriger et finaliser en plus des tâches à réaliser. Les autres membres poursuivent leurs développements,
interrompus par des discussions, validations et compléments. Vers 17h, une réunion avec sept coachs (design, entrepreneurat, etc.) a pour objectif d'ouvrir la réflexion de l'équipe et du porteur du projet afin de mieux répondre aux exigences du jury. Une multitude d'idées est proposée par les coachs mais l'équipe ne s'y reconnaît pas car elles ne sont pas en phase avec le projet partagé qu'est un jeu pour l'enfant et non pas une commercialisation pour un dispositif multi-joueurs tel que proposé par des coachs. L'équipe poursuit le développement de deux jeux.

Le porteur du projet comprend la difficulté de la présentation finale et lance une discussion avec l'équipe pour récolter leurs avis. Il soumet la possibilité de faire la présentation lui-même ou par quelqu'un de l'équipe.

### Phase 3

Pendant que les développeurs finalisent les jeux, le porteur, l'orthophoniste et un membre travaillent avec un coach en communication sur la présentation finale. Ils changent le nom du projet afin de mieux faire ressortir la fonctionnalité principale qu'est la manipulation oculaire des jeux et la double connotation : l'enfant comme acteur « I Act ».

Ils développent le phasage de la présentation, l'utilisation de vidéos et de manipulation directe sur scène, un logo, le discours. Le porteur propose à nouveau le rôle du présentateur, invite les autres membres de participer à la présentation. Ils valident son rôle pour la présentation et la démo communément. La présentation finale a lieu à 16h et le projet est décerné de deux prix.

## 2.3. Projet 3 : Un Casque pour des patients atteints d'un AVC

### 2.3.1. La constitution de l'équipe

L'équipe du projet Casque pour des patients atteints d'un AVC se compose de médecins et scientifiques d'un hôpital ainsi que d'informaticiens d'une *start-up* spécialisée dans la simulation d'interventions médicales et de codeurs. Le projet a été lancé avant le Hackathon, l'engagement des participants de départ est grand car ils envisagent de le poursuivre après le Hackathon.
L'équipe compte au total onze personnes : l'initiateur et porteur du projet est médecin à l'hôpital, tout comme sa compagne ; une biologiste et chargée de projets à l'hôpital, cinq membres de la *start-up* dont les deux fondateurs plus trois développeurs, ainsi que trois personnes recrutées lors du marché du Hackathon avec des compétences complémentaires. Parmi ces onze participants, deux ne sont pas présents en permanence, mais apportent activement leur savoir le dimanche pour aider à la préparation du *pitch* final avec des compétences spécifiques liées à l'entrepreneuriat. La langue de travail entre le porteur, sa compagne, la biologiste et les fondateurs de la *start-up* est l'anglais, celle des développeurs français.

Le cahier des charges a été défini en grandes parties avant le Hackathon qui sert d'accélérateur du projet et qui a pour objectif d'être poursuivi après l'événement.

### 2.3.2. Le processus de collaboration

Après une première présentation du projet à l'équipe constituée vers 23h30, les sept membres, le porteur, sa compagne, la biologiste et les quatre développeurs, se présentent mutuellement ainsi que leurs compétences. Le porteur reste très timide en tant qu'animateur du projet, contrairement à sa compagne qui le soutient ; en parallèle, la biologiste, par son expérience, essaie de prendre le lead en proposant une stratégie. Le porteur prend au fur et à mesure les décisions avec le soutien fort de sa compagne, et la biologiste continue d'être force de proposition.

Le phasage de ce projet est légèrement différent des projets précédents. Puisque le projet a déjà démarré avant le Hackathon, il se compose essentiellement de deux phases :

i) La production de l'application et celle de la collecte d'information nécessaire pour élaborer le scénario de la démonstration, et

ii) La préparation du pitch final.

#### Phase 1

La biologiste propose un planning de travail afin de faciliter la préparation du pitch final. Le porteur du projet et sa compagne invitent la biologiste à préparer ensemble le scénario du projet et les
développeurs à travailler sur l'application. Les deux modes de travail sont appliqués, et cette phase
de travail dure toute la nuit.

Phase 2

A partir de samedi matin environ 10h, le porteur du projet, sa compagne et la biologiste poursuivent
le développement du business model, définissent les objectifs (inscrits et fixés aux fenêtres) et
discutent le plan du scénario de la démo avec la to-do-liste. Le mode de fonctionnement est agile,
chacun travaille de son côté : le porteur avec sa compagne, la biologiste et les développeurs ; ils
échangent peu oralement mais partagent des données sur GoogleDoc. La biologiste prépare la
présentation vidéo, ils échangent des informations afin de développer une stratégie pour le projet. Les
codeurs avancent.

Lors de la visite de deux journalistes auxquels la biologiste explique le projet, le porteur du projet
reste assis et continue à travailler avec sa compagne. Une réunion de préparation du pitch est
organisée avec les onze membres de l'équipe dans une salle à part. La biologiste propose le
déroulement de la réunion et demande si tout le monde est d'accord que le porteur présente le projet
lors du pitch final qui durera trois minutes ; ils distribuent les rôles de chacun pour le pitch afin que
chacun puisse répondre aux questions du jury. L'équipe se met d'accord sur le déroulement du pitch :
une minute de vidéo, une minute de texte lu par le porteur pour expliquer et une minute de
démonstration de l'application réelle. Le porteur, sa compagne, la biologiste, et les deux fondateurs
de la start-up tentent d'anticiper des questions potentielles, peaufinent l'argumentation et évoquent
la Réalité Virtuelle, tandis que les codeurs restent très calmes. Cette présentation sera finalisée jusqu'à
dimanche midi avec la vidéo, l'application et la démonstration en directe. La présentation finale a
lieu à 17h et le projet est récompensé d'un prix.

3. RESULTATS ET DISCUSSION

L'objectif de notre recherche est de mieux comprendre les effets des *Grounds* et du processus d'apprentissage et de création sociale de savoir, des contraintes, de la constitution et des dynamiques
sur la coordination des équipes en vue de transformer une idée innovative vers une co-construction créative. Par conséquent, la présentation de nos résultats se structure selon les axes conformes à notre cadre conceptuel, à savoir :

1. Le positionnement et la composition des équipes et des individus dans le cadre des *Grounds*,

2. L'impact des contraintes sur les groupes, les individus et les projets,

3. La constitution et les dynamiques des équipes ainsi que leur effet sur la créativité, l'innovation et la création socialement organisée de savoir.

**3.1. Le positionnement et la composition des équipes et des individus dans le cadre des Grounds**

Selon Cohendet, Grandadam et Simon (2010), le Hackathon est un événement du *Middleground* permettant aux individus venant essentiellement de l'Underground de travailler pendant cinquante heures sur des projets de manière altruiste. L'Upperground, id est les organisations, y participe en tant que sponsor, partenaire mais potentiellement aussi avec des projets. Un regard plus profond permet d'identifier, de manière microsociologique, l'origine des porteurs et des projets et le positionnement des équipes et des individus dans le cadre des *Grounds*, donnant potentiellement des explications complémentaires et relatives à notre objectif.

Le projet Plateforme est un réel projet de l'Underground, apporté par deux Néerlandais et avec une équipe spontanément créée d'individus attirés par l'esprit du Hackathon et voulant faire don de leur temps, motivation et engagement. La collaboration se passe à un niveau égalitaire, seuls les porteurs de projets interviennent parfois pour faciliter le travail. Le projet fonctionne plutôt comme une communauté telle que décrite par von Krogh, Haeflinger et al. (2012) et von Krogh (1998).

Le projet Casque apparaît comme un projet présenté par une organisation, l'hôpital, en partenariat avec une *start-up* pour compléter l'équipe apportant de compétences supplémentaires. Le projet ressemble plus à un projet d'Upperground. Seuls les codeurs recrutés lors du marché du Hackathon représentent l'Underground. Puisque le projet a été lancé et préparé bien avant le Hackathon,
l'événement permet de concentrer le travail sous la pression temporelle, de profiter des compétences de codeurs *Underground* et de gagner éventuellement un prix sous forme d'accompagnement (conseil, financier). L'organisation du projet du travail à réaliser est donnée par l'équipe de l'hôpital, les codeurs n'y interviennent pas. Le projet est représentatif d'une organisation et reflète des structures et un fonctionnement de l'*Upperground*.

Le projet Jeux représente une forme hybride. Il s'agit d'un projet apporté par un membre de la famille d'un enfant handicapé, donc un *Underground*, en partenariat avec une école de codeurs, un *Upperground*, qui propose à des élèves de participer dans le cadre de leur formation ; une partie des élèves sera évaluée sur leur participation. L'équipe est complétée par une personne recrutée lors du marché. L'apport de nouvelles idées et les négociations qui en suivent se passent principalement parmi les 'adultes' voire *Upperground* du projet : le porteur, le graphiste, et encore un membre de la famille consulté pour valider les compétences de l'enfant. Les élèves codeurs se laissent essentiellement guider par le porteur et soumettent parfois des idées. Hormis l'aspect 'école' en tant qu'organisation, le projet présente un fonctionnement plutôt *Underground*.

Les trois projets ont été récompensés sur la base des critères d'innovation et de créativité. On peut donc présumer que le fait qu'un projet soit à majorité *Upperground* (projet Casque) n'est pas plus ou moins créatif qu'un projet *Underground* (projet Plateforme) ou qu'un projet hybride (projet Jeux). Cependant, cette analyse doit être approfondie par des éléments complémentaires suivants.

## 3.2. L'impact des contraintes sur les groupes, les individus et les projets

Notre recherche confirme les résultats d'Amabile, Hadley et Kramer (2002) : les participants du Hackathon acceptent la forte pression temporelle dans un cadre de forte probabilité de pensée créatrice car ils se sentent en mission !

La scénarisation du Hackathon avec sa variété d'actions créé une dynamique spécifique et un enthousiasme tout particulier qui emportent et stimulent les participants. Ils ne perçoivent plus réellement les contraintes du processus, seule la pression temporelle est omniprésente, surtout à partir
de dimanche matin quand les présentations finales doivent être finalisées. Cette contrainte est acceptée, elle conditionne le Hackathon et le transforme en réel challenge.

En revanche, les contraintes de projet sont perçues différemment dans les trois projets. Dans l'équipe Casque, ces contraintes sont données et gérées par le porteur et les personnes venant de l'hôpital ; les codeurs ne sont concernés que dans la mesure où ils doivent développer les codes pour l'application. Ils reçoivent un cahier des charges technique et l'améliorent selon leurs compétences. Les coachs s'adressent au porteur, sa compagne et la biologiste pour apporter un peaufinage du travail. Le projet Jeux affiche en plus une contrainte extérieure pour les élèves, mais leur participation est volontaire, donc fidèle à l'Underground, et renforce l'expression de leur motivation et engagement. L'apport des coachs est perçu comme une perturbation car ils tentent d'apporter une dynamique commerciale au projet tandis que l'équipe favorise le développement d'un jeu pour un enfant spécifique. Le projet Plateforme fait abstraction des contraintes pour permettre à l'équipe de trouver un consensus sur l'objectif du projet. Cette discussion démarre le vendredi soir et se termine en grande partie samedi soir, se poursuit momentanément encore la nuit de samedi à dimanche et se termine uniquement le dimanche matin. Ce n'est qu'ensuite que l'équipe s'organise pour prendre en considération les éléments à développer pour la présentation et fait appel aux coachs pour compléter leur réflexion.

Les projets Casque et Jeux fonctionnent plutôt avec un mode d'organisation de travail classique avec une structure hiérarchique. Le projet Plateforme, cependant, s'autogère et s'attribue les tâches à réaliser au sein de l'équipe. Puisque le projet Plateforme ne démarre le développement réel de son projet que très tardivement comparé aux autres projets, l'équipe fait clairement appel aux coachs pour qu'ils apportent leurs expertises et les aident à élaborer tous les éléments nécessaires pour la présentation finale ; l'équipe 'achète' le conseil dont ils ont besoin.

Les contraintes ont influencé les trois projets différemment : les projets Casque et Jeux ont suivi une progression relativement classique dans l'élaboration des tâches selon le cahier des charges indiqué par les porteurs respectifs. En revanche, le projet Plateforme consacre deux-tiers du week-
end pour déterminer une thématique partagée par tous et de créer un esprit de communauté pour stimuler l'innovation et une créativité collective.

## 3.3. La constitution et les dynamiques des équipes, auteurs de la création sociale de savoir

### 3.3.1. La constitution des équipes PET et FT, la collocation radicale et l'effet sur l'innovation

Bien que Pe-Than, Nolte et al. (2022) aient observé, dans le cadre de Hackathons d'entreprise, la distinction entre des équipes PET et FT et l'effet de la proximité spatiale sur la capacité de ces équipes à dépasser (ou non) les frontières de l'innovation (idem ; Trainer et al., 2016), nous pouvons observer des similitudes dans un Hackathon classique.

Naïvement, on suppose que les équipes se constituent spontanément lors du marché, qu'à la limite, les participants prennent connaissance des projets et expriment éventuellement un intérêt pour un projet à l'aide du *Sparkboard* des projets mis en place sur la plateforme de l'événement. Or, parmi les vingt-trois projets du Hackathon observé, deux des trois projets sélectionnés au hasard présentent des caractéristiques PET et seulement un est un véritable FT. Le projet Casque et le projet Jeux peuvent être perçus en tant que projet PET car ils sont majoritairement constitués avant et pour le Hackathon et seuls quelques codeurs recrutés lors du marché complètent l'équipe. L'organigramme du projet est prédéfini, les codeurs recrutés s'y soumettent et les projets se déroulent quasiment (hormis peu de conflits) comme prévu. Le Hackathon permet à ces deux projets de profiter de la pression temporelle de l'événement et de s'appuyer sur des compétences complémentaires pour avancer sur les projets sans, visiblement, qu'une attente particulière de dépasser les frontières de l'innovation ait été anticipée préalablement. La familiarité existait déjà dans les équipes d'origine ; les participants recrutés semblent s'adapter assez facilement aux groupes de projet (cette facilité peut s'expliquer par le fait qu'il s'agit de habitués de Hackathon). C'est l'avantage majeur des PET : bénéficier de leur familiarité afin d'exploiter les connaissances existantes. Le Hackathon booste le développement de l'innovation, ce qui est légitime dans un tel événement.
Cependant, le projet Plateforme, le plus diversifié et international, correspond à l'attente idéalisée d'un projet Hackathon avec ses avantages et ses inconvénients : le temps consacré à la formulation d'un objectif commun et à la formation d'une équipe est très chronophage – mais permet par la suite de mieux s'organiser et de se coordonner dans la réalisation du projet. Ce projet FT fait apparaître le plus clairement les quatre phases du processus de création sociale de savoir. Ce projet manifeste également le plus explicitement l'apprentissage observé par Pe-Than, Nolte et al. (2022). Dans ce projet, chacun présente sa motivation à participer au Hackathon, à l'équipe et au projet avec ses attentes personnelles, besoins de transferts vers d'autres aspects de leurs vies, et les projections personnelles et professionnelles, ce qui crée des liens culturels et des rapprochements professionnels ou par affinités. Le groupe discute très ouvertement et montre un grand intérêt à chaque individu. Le besoin de stimulation est maximal. Ce tour de table rappelle les 'alcooliques anonymes', mais le mode d'organisation est exploité pour renforcer au maximum l'importance du soutien du groupe à l'individu et son accueil dans une communauté, et ce n'est pas anodin. La valorisation de la dimension sociale et d'écoute est extrêmement forte et ouvre les frontières de la co-créativité. Le besoin d'auto-expression est très développé également. D'ailleurs, rien ne laissait présager que le groupe allait réussir le challenge car d'autres projets paraissaient être en cours de réalisation, quand la Plateforme se cherchait encore.

Dans les deux projets Casque et Jeux, la création sociale de savoir reste limitée au niveau des livrables à réaliser par chacun, fidèles à la culture de PET, exploitant les connaissances existantes et l'avantage de la familiarité. En revanche, le projet Plateforme considère plus nécessairement ce que recherche les FT : la création sociale de savoir, les compétences existantes et le bénéfice tiré de la simple exposition aux personnes et aux compétences nouvelles, diverses et variées (Pe-Than, Nolte et al., 2022, p. 305).
### 3.3.2. Le phasage des dynamiques des équipes et la gestion de conflits

Le séquençage de la constitution de (petites : Tuckman, 1965) équipes, à savoir le *Forming*, le *Storming*, le *Norming* et le *Performing* (Tuckman, 1965 ; Trainer et al., 2016) correspond, au niveau de la structure du groupe, à un modèle de relations interpersonnelles et à la façon dont les membres agissent et interagissent les uns avec les autres, et, au niveau de l'activité et de la tâche, du contenu de l'interaction lié à la tâche à accomplir (Tuckman, 1965, p. 66).

Les projets Casque et Jeux peuvent alors être considérés comme des PET, à quelques nuances près, en fonction du nombre de membres recrutés lors du Hackathon. Selon le séquençage de Tuckman (1965) et de Trainer et al. (2016), nous pouvons observer quelques conflits entre les porteurs des projets et un membre du 'middle management' voire du *Middleground* : dans le projet Casque, c'est la biologiste, et dans le projet Jeux, un élève en fin d'étude et le graphiste. Ils agissent en tant que *Knowledge Broker*.

Le projet Casque est formé avant le Hackathon. L'orientation du projet, la dépendance entre les membres, les strates hiérarchiques et les rôles sont définis entre l'équipe hôpital avec, d'un côté, le porteur et sa compagne, la biologiste (qui n'est déjà plus au même niveau que le porteur), et la *start-up* qui joue le rôle de sous-traitant et, de l'autre côté, les codeurs. Les tâches sont distribuées, le mode agile partagé. Néanmoins, la biologiste est frustrée car ses propositions ne sont pas retenues par le porteur. Cette phase de *Storming* de la biologiste dure d'ailleurs relativement longtemps, tandis que la *start-up* et les codeurs ne s'en préoccupent visiblement pas. On observe un séquençage à deux temps, celui de la majorité de l'équipe du *Forming*, un quasi-inexistent *Storming*, un focus rapide sur le *Norming* afin d'accéder au plus vite au *Performing*, l'action constructive, et la raison pour laquelle tout le monde participe à l'événement. En parallèle à ceci, la biologiste semble rester longtemps dans le *Storming* car elle n'abandonne pas et repropose régulièrement ses idées jusqu'à ce que le porteur accepte des propositions avec la conséquence que la biologiste quitte la phase de *Storming* et soutient le projet pour accélérer vers le *Performing*.
Le projet Jeux fait face à un autre scénario. L'équipe se connaît, s'est constituée avant le Hackathon et démarre tout de suite. L'équipe passe, semble-t-il, du *Forming* au *Performing* directement. Les premiers conflits du *Storming* apparaissent lors d'une courte discussion apparemment anodine le dimanche soir au cours de laquelle toute l'équipe se positionne contre un élève qui met en doute la légitimité du porteur de projet. L'équipe s'impatiente pour commencer le travail et poursuivre le *Performing*. Les discussions tournent autour de l'intégration des idées de l'équipe sur les fonctionnalités et sur le rôle du leader du projet. Ce *Storming* s'exprime dans le positionnement physique des membres dans la salle : tout le monde travaille autour de la même table de manière centrique, l'élève de manière excentrique seul dans un coin. L'élève fait des propositions pour apporter des idées non validées par les autres ce que provoque une escalade jusqu'à ce que l'élève quitte le projet. L'ambiance est plus détendue et l'expérience commune semble lier les autres davantage. La cohésion de l'équipe fait face à une personne qui se sent forcée à abandonner au lieu de s'intégrer. Le *Performing* continue et les participants s'entraident mutuellement.

Le projet Plateforme, quant à lui, demeure jusqu'à dimanche matin dans la phase *Forming*, agrémentée par des discussions à la perspective de recherche de lien communautaire immédiat, de recherche de filiation et pairisation de long terme, de recherche d'information sur la possibilité de la part des participants actuels sur un éventuel engagement dans un autre horizon que le Hackathon. Pour cette équipe, le Hackathon représente un moyen de décloisonnement social. Cette équipe mixe les séquences de *Forming*, peu de *Storming* et de *Norming* comme un processus itératif et non nécessairement séquentiel. Le mode de gestion de conflit, si y en a, est très pacifiste, démocratique et consensuel. Comparé aux équipes Casque et Jeux, cette capacité de gestion est potentiellement liée à l'âge des membres (plus élevé que les élèves et les codeurs : des *Underground*), la situation professionnelle et socio-économique (des médecins, entrepreneurs, scientifiques : des *Middle-voire mêmes des Uppergrounds*) et la diversité de nationalité exprimant une probable maturité sociale. Ce groupe doit très certainement énormément valoriser l'intérêt collectif de ce type de projets et en retirer une fierté personnelle extrêmement élevée.
### 3.3.3. La coordination des équipes et le rôle du porteur de projet dans la création de savoir

Non seulement dans un Hackathon, si les membres d'une équipe collaborent dans un espace physique unique, elles sont généralement davantage auto-dirigées, motivées et les familiarités développées parmi les membres de l'équipe permettant d'améliorer la collaboration (Pe-Than, Nolte et al., 2022, p. 284). Cependant, et au-delà des dynamiques des équipes, le rôle du porteur de projet est nécessaire pour mener à bien le développement d'un projet de l'innovation vers un projet abouti dans un contexte de co-créativité sous contrainte.

Pour rappel, les projets Casque et Plateforme sont localisés dans des grandes salles avec d'autres projets ; la collocation radicale est de mise.

Le projet Plateforme profite de l'auto-coordination de l'équipe. Néanmoins, les porteurs suivent scrupuleusement l'avancement des discussions et de l'évolution du projet. Ils notent tous les inputs. De temps à temps, ils évoquent un auteur, un livre ou un canevas d'analyse pour enrichir, stimuler la discussion et approfondir les propos. Ils restent très attentifs. Les membres de l'équipe affichent un comportement positif et soutiennent les propos voire les commentent. L'échange demeure très vivant. Les porteurs ont visiblement compris qu'ils ne peuvent pas diriger l'équipe sans leur laisser l'espace et le temps de créer une communauté qui partage les mêmes valeurs et le même objectif (même si parfois des discussions et des mises en question pour vérifier le bien-fondé des idées surgissent). En cas de divergences d'avis, un des deux porteurs crée avec quelques membres de l'équipe un groupe de travail pour développer une solution sans que ceci freine l'avancement du projet. Le mode de coordination est agile et constructif. Une fois que l'objectif du projet est déterminé et partagé, les porteurs incitent l'équipe à se départager librement les tâches de façon à produire la présentation finale. L'équipe affiche un esprit d'entrepreneur et de communauté selon von Krogh, Haeflinger et al. (2012) et von Krogh (1998).

Le projet Casque suit une coordination relativement hiérarchique telle que nous l'avons déjà décrit plus haut. Le porteur a déterminé le projet, les compétences dont il a besoin, il a constitué l'équipe principale avec sa compagne, la biologiste et les experts de la *start-up*. Le recrutement des codeurs
représente un bonus de main d'œuvre. Les membres ayant accepté ceci, hormis le *Storming* de la
biologiste, le mode de travail est basé sur la concentration et la tranquillité. La progression est
constante. Le mode de coordination du projet est agile dans un cadre prédéterminé avec les rôles et
responsabilités définis. Tout de même, le porteur et sa compagne ne parlant que l'anglais, le porteur
doit s'appuyer sur la biologiste pour la délégation de sa coordination : elle devient l'interprète et la
traductrice entre le porteur et les codeurs, ainsi qu'entre les *start-uppers* et les codeurs. De plus, le
porteur compense le manque d'autorité naturelle par son mode de coordination assez directif,
n'acceptant que difficilement des propositions de la biologiste et d'autrui. Cependant, au fur et à
mesure, le porteur gagne en confiance, reconnaît la valeur des propositions ce qui rend son mode de
coordination un peu plus souple. On peut observer une proximité entre le porteur et sa compagne, et,
à un niveau intermédiaire, entre la biologiste et les responsables de la *start-up*. En revanche, une
proximité est observable entre les codeurs de la *start-up* et ceux recrutés au Hackathon. Dans cette
constellation relationnelle et malgré ces contraintes, les motivations et l'engagement des participants
permettent de cocréer un projet innovant !

Le projet Jeux, qui dispose d'une salle dédiée, donc une collocation radicale permettant une
familiarité aussi liée au fait que l'équipe soit formée avant l'événement, affiche un mode de
coordination hybride entre le mode du projet Casque et celui du projet Plateforme. Le porteur a
indiqué l'objectif du projet, le besoin de l'enfant et son penchant pour les Pokémons comme cadre. Il
n'intervient quasiment pas, l'autorité de sa fonction est naturelle et reconnue en tant qu'initiateur de
l'idée, le cousin de l'enfant souhaitant lui apporter un soulagement. Il a confiance en l'équipe et ne
cherche pas à valoriser soi-même ou individuellement les membres de l'équipe. Le porteur ne se met
pas en avant, reste généralement observateur ; au mieux, il donne quelques inputs pour clarifier les
besoins de l'enfant. La coordination des codeurs revient au graphiste. L'engagement des membres de
l'équipe est basé sur l'émotion. La confiance et la disponibilité du graphiste : ce mode de coordination
délégatif et agile motive les membres de l'équipe dans leur travail. L'adhésion à ces valeurs les
pousse, lors de conflits, à faire 'front' contre cet élève et se retrouver autour du porteur et de son projet.

Pour les projets Casque et Jeux en particulier, la création sociale de savoir reste longtemps confinée dans chacune des strates de projet jusqu'à la mise en commun des livrables, au moment d'élaborer la présentation finale. Cependant, des différences dans le rôle du porteur de l'équipe et dans sa manière de manager son équipe sont à souligner. Le porteur du projet Casque réalise le processus de développement d'idées à l'aide de sa *Knowledge Broker*, la biologiste, et exploite la familiarité du PET des codeurs. En revanche, la construction sociale et la création de sens se font tardivement et restent limitées, ce qui est cohérent avec le phasage de Tuckman. Dans le projet Jeux, le sens du projet est donné très tôt : à savoir le jeu pour l'enfant handicapé. Par ce sens partagé extrêmement tôt, même les phases de Tuckman sont plus constructives et ce PET fonctionne presque comme un FT (d'ailleurs, nous avons observé ce projet comme hybride). Le projet Plateforme, le seul réel FT, profite du coaching habile des deux porteurs bien que l'équipe consacre la majorité de son temps d'abord à la construction sociale et à l'expression du sens du projet (voire le *Norming*) avant de pouvoir se concentrer rétroactivement sur l'Intention, le *Spark* et finalement sur son *Landing*.

## CONCLUSION

Notre recherche a permis de comprendre l'influence des *Grounds* et des contraintes de co-créativité imposées dans le cadre d'un Hackathon et de quelle manière ces équipes de projet se structurent et se coordonnent, quelles sont leurs dynamiques et effets sur la stimulation de la créativité, et sur le processus de construction de savoir. Cette double analyse a permis de décomposer i) la dynamique d'un Hackathon et de ses acteurs appartenant aux territoires créatifs des *Grounds*, et ii) les dispositifs de coordination du processus de transformation d'une idée créative vers l'innovation.

I) Les trois études de cas nous permettent de confirmer qu'il est possible de différencier des types de participants, par exemple les codeurs et élèves, de l' *Underground*, qui font don de soi et les porteurs de projet, l' *Upperground*, qui ont un objectif de participation autre que ce don de soi à savoir
de trouver une équipe de volontaires pour faire progresser le projet. Certains participants joueront un rôle de *Knowledge Broker*, la biologiste et le graphiste, dans le *Middleground* du projet. La scénarisation du Hackathon répond au processus de co-construction de l'innovation dans les *Grounds*. Les contraintes du processus motivent les participants et l'esprit entrepreneur de l'événement. Le management des contraintes du projet revient principalement au porteur du projet.

II) Pendant le Hackathon, nous avons, pour l'instant, observé trois types de phases créatives : i) le projet peut être peaufiné lors de la discussion avec l'équipe pour le rendre plus clair et plus pertinent (le projet Jeux) ; ii) le projet peut être modifié profondément et remis en question par l'équipe (le projet Plateforme) ; iii) le projet peut être discuté mais reste essentiellement tel que le porteur le prévoit (le projet Casque). En fonction du degré de modification, nous observons également un autre mode de management du porteur, de la coordination dans les dynamiques d'équipe et de leur construction de savoir.

Dans le contexte d'un Hackathon, le degré de créativité de départ peut varier en fonction de l'objectif du porteur et de la liberté accordée à l'équipe dans la proposition de solutions. Le Hackathon peut être effectivement considéré comme une exploitation bienveillante de compétences gratuites dans le cadre du processus de transformation d'une idée créative jusqu'à une innovation achevée et présentée le dimanche soir.

Ceci pourrait expliquer la raison pour laquelle les équipes d'un Hackathon ne poursuivent généralement pas leur collaboration après l'événement : la constitution et l'objectif d'une équipe *ad hoc* et éphémère de personnes qui font don de soi et 'sans lendemain' n'est classiquement pas comparable à celle d'une entreprise. D'ailleurs, bien que nous observions des projets PET et FT, les contextes et les conséquences entre un Hackathon en entreprise et un 'vrai' ne sont pas les mêmes. Ces particularités impactent également la manière de cocréer une solution, du savoir et de son partage. Le processus de transformation de l'idée créative en une innovation est fortement lié aux dispositifs de coordination de l'information (la collocation radicale des membres de l'équipe, la familiarité issue de cette proximité physique) et s'appliquent différemment aux catégories de membres de l'équipe.
Les mécanismes de dévoilement de l'information et le moment de ces échanges (incluant ceux réalisés avec les coachs) semblent indiquer une relative adhésion à la technique dans le cadre du bien commun qu'est l'avènement de la création, son *Landing* du dimanche soir.

Ces travaux pourront ouvrir la voie à des échanges et approfondissements quant à l'appropriation managériale de ces résultats soit par les organisateurs de Hackathons et les coachs, soit pour les entreprises qui souhaiteraient mobiliser ce type de technique de créativité.

Nos recherches complémentaires portent, sous forme d'une étude quantitative, sur la motivation des participants au Hackathon.
BIBLIOGRAPHIE

Amabile, T. M. (1996), « Creativity and Innovation in Organizations », *Harvard Business School*, Background Note 396-239, January.

Amabile, T. M., Hadley, C. H. & Kramer, S. T. (2002), « Creativity under the Gun », Special Issue on The Innovative Enterprise: Turning Ideas into Profits, *Harvard Business Review*, 80(8), August, 52–61.

Angarita, M. A. M. & Nolte, A. (2020), « What does we know about Hackathon outcomes and how to support them? A systematic literature review », *Collaboration Technologies and Social Computing*, August, 50-64.

Angelidis, P., Berman, L., Casa-Perez, M. De la Luz, Cell, L. A., Dafoulas, G. E., Dagan, A., Escobar, B., Lopez, D. M., Noguez, J., Osorio-Valencia, J. S., Otine, C., Paik, K., Rojas-Potosi, L., Symeonidis, A. L. & Winkler, E. (2016), « The Hackathon model spur innovation around global health », *Journal Med Eng Technol.*, 40(7-8), 392-399.

Bokoko, D. M. (2020), « Comment les Hackathons par le levier de la créativité collaborative posent les bases des futures innovations ? », iSTE *OpenScience*, 1-16.

Briscoe, G. & Mulligan, C. (2014), « Digital Innovation: The Hackathon Phenomenon », *CreativeWorks*, London, Working Paper No. 6.

Callon, M. (1999), « Le réseau comme forme émergente et comme modalité de coordination : le cas des interactions stratégiques entre firmes industrielles et laboratoires académiques », *Callon, M. et al.*, *Réseau et Coordination*, Paris : Economica.

Cohendet, P., Grandadam, D. & Simon, L. (2010), « The Anatomy of the Creative City », *Industry and Innovation*, 17(1), 91-111.
Cohendet, P., Parmentier, G. & Simon, L. (2017), « Managing knowledge, creativity and innovation », Bathelt, H., Cohendet, P., Henn, S. & Simon, L. (Eds.), *The Edward Elgar Companion to Innovation and Knowledge Creation*, Edward Elgar Publishing, 2-27.

Csikszentmihalyi, M. (1997), *Creativity: Flow and the psychology of discovery and invention*, HarperCollins Publishers.

Dionne, K.-E. & Carlile, P. (2016), « Le pouvoir transformationnel des hackathons », *Gestion*, 41(2), 62-63.

Eisenhardt, K. (1989), « Building Theories from Case Studies », *The Academy of Management Review*, 14(4), October, 532-550.

Endrissat, N. (2018), « Hackathon: A field of dreams for collaborative innovation? », *Entreprendre & innover*, 3(38), 69-75.

Egolf, D. & Chester, S. (2013), *Forming Storming Norming Performing: Successful Communication in Groups and Teams*, (Third Edition), iUniverse.

Fabbri, J., Toutain, O. & Glaser, A. (2018), « Hackathon & co : entre fascination et rejet », *Entreprendre & innover*, 3(38), 5-8.

Falk, J., Nolte, A., Huppenkothen, D., Weinzierl, M., Gama, K., Spikol, D., Tollerud, E., Hong, N. C., Knäpper, I. & Hayden, L. B. (2022), « The Future of Hackathon, Research and Practice », ArXiv Preprint ArXiv:2211.08963.

Flus, M. & Hurst, A. (2021), « Design at Hackathon: new opportunities for design research », *Design Science*, 7, 1-24.

Gregg, M. (2015), « Hack for good: Speculative labour, app development and the burden of austerity », *The Fibreculture Journal*, 25: Apps and Affect, 183-201.
Gréselle-Zaïbet, O., Kleber, A. & Dejoux, C. (2018), « Le Hackathon en mode design thinking ou quelles modalités pour former à des compétences méthodologiques et comportementales ? », *Management & Avenir*, 6(104), 149-171.

Irani, L. (2015), « Hackathons and the Making of Entrepreneurial Citizenship », *Science, Technology, & Human Values*, 40(5), September, 799-824.

Kienzler, H. & Fontanesi, C. (2016), « Learning through inquiry: A global Health Hackathon », *Teaching in Higher Education*, September, 1-14.

Nandi, A. & Mandernach, M. (2016), « Hackathons as an Informal Learning Platform », *SIGCSE '16: Proceedings of the 47th ACM Technical Symposium on Computing Science Education*, February, 346-351.

Nolte, A., Chounta, I. A. & Herbsleb, J. D. (2020), « What happens with all these Hackathon projects? - Identifying factors to promote Hackathon project continuation », *Human-Computer Interaction*, 4, no. CSCW2, article 145, October, 1-26.

Nolte, A., Pe-Than, E. P. P., Affia, A.-A. O., Chaihirunkarn, C., Filippova, A., Kalyanasundaram, A., Angarita, M. A. M., Trainer, E. & Herbsleb, J. D. (2020), « How to organize a Hackathon - A planning list », arXiv preprint arXiv:2008.08025.

Pe-Than, E. P. P., Nolte, A., Filippova, A., Bird, C., Stallen, S. & Herbsleb, J. D. (2018), « Designing corporate Hackathons with purpose », *IEEE Software*, July, 15-22.

Pe-Than, E. P. P., Nolte, A., Filippova, A., Bird, C., Stallen, S. & Herbsleb, J. D. (2022), « Corporate Hackathon, how and why? A multiple case study of motivation, project proposal and selection, goal setting, coordination, and outcomes », *Human-Computer Interaction*, 37(4), 281-313.

Ronfaut, L. (2014), « Comment le "hackathon" réinvente l'innovation en entreprise », *Le Figaro* : https://www.lefigaro.fr/secteur/high-tech/2014/03/31/32001-20140331ARTFIG00112-hackathons-
les-marathons-de-l-innovation-font-courir-les-geants-de-l-industrie-et-des-services.php (consulté le
12.01.2024).

Russo, B. D. (2011), « Creativity and Constraint: Exploring the Role of Constraint in the Creative Processes of New Product and Technology Development Teams », *Organization Studies*, 35(4), 551-585.

Schulte, C., Nolte, A., Spikol, D. & Chouta, I.-A. (2022), « How do participants collaborate during online hackathons? », *Frontiers in Computer Science*, 1-15.

Sirris, S., Lindheim, T. & Askeland, H. (2022), « Observation and Shadowing: Two Methods to Research Values and Values Work in Organisations and Leadership », Espedal, G., Loaves, B. J., Sirris, S. & Waeraas A. (Eds.), *Researching Value: Methodological Approaches for Understanding Values Work in Organisations and Leadership*, Palgrave Macmillan, Open Access, 133-152.

Söderberg, J. (2021), « The 3 Pillars of Functional Autonomy of Hackathons », *Nanoethics*, 15, 43-56.

Sutton, R.I. & Hargadon, A. (1996), « Brainstorming Groups in Context: Effectiveness in a Product Design Firm », *Administrative Science Quarterly*, 41(4), December, 685-718.

Trainer, E. H., Chaihirunkarn, C., Kalyanasundranam, A. & Herbsleb, J. D. (2014), « Community Code Engagements : Summer of Code & Hackathons for Community Building in Science Software », *Association for Computing Machinery*, Proceedings of the 2014 ACM International Conference on Supporting Group Work.

Trainer, E. H., Kalyanasundranam, A., Chaihirunkarn, C. & Herbsleb, J. D. (2016), « How to Hackathon: Socio-technical Tradeoffs in Brief, Intensive Collocation », *Computer Supported Cooperative Work*, 1116-1128.
Tuckman, B. W. (1965), « Development Sequence in Small Groups », *American Psychological Association : Psychological Bulletin*, 63(6), 384-399.

von Krogh, G. (1998), « Care in Knowledge Creation », *California Management Review*, 40(3), 133-153.

von Krogh, G., Haeflinger, S., Spaeth, S. & Wallin, M. W. (2012), « Carrots and Rainbows: Motivation and Social Practice in Open-Source Development », *MIS Quarterly*, 36(10), 649-676.

Yong, M.S. (2021), « Why not just all do Hackathons online? A comparative study between online and in-person events », *Computer Science Technical Reposts*, MS Thesis.

Zukin, S. & Papadantonakis, M. (2018), « Hackathons as co-optation rituals, socializing workers and institutionalizing innovation in the "new Economy" », *Research in the Sociology of Work*, Chapter, December 2017, Precarious Work, published online 04 Dec 2017, 157-181.