# De l'idée innovante à la co-créativité sous contrainte : constitution, dynamique et coordination d'équipes de projets Hackathon

Sabine Cullmann, Inès Guguen-Gicquel

## ► To cite this version:

Sabine Cullmann, Inès Guguen-Gicquel. De l'idée innovante à la co-créativité sous contrainte : constitution, dynamique et coordination d'équipes de projets Hackathon. XXXIII. conférence de l'AIMS 2024, Association francophone d'enseignants et chercheurs en management, stratégie et organisation, Jun 2024, Montréal (Québec), Canada. hal-04631665

HAL Id: hal-04631665

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

Submitted on 2 Jul 2024

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

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

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

Distributed under a Creative Commons Attribution 4.0 International License
De l'idée innovante à la co-créativité sous contrainte :

constitution, dynamique et coordination d'équipes de projets

Hackathon

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 cocréation sous contraintes, ils ont été repris dans de nombreux domaines et leur scénarisation impressionnante contribue à en augmenter considérablement l'attractivité. Cependant, peu de recherches portent sur la manière dont les équipes de projet *ad hoc* se constituent et se structurent, sur leurs dynamiques et leur effet global sur la co-créativité dans un contexte soumis à de très fortes contraintes. Effectivement, un Hackathon se positionne dans le paradoxe des contraintes de la co-créativité par 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 interne des équipes. 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.

Mots-clés : Hackathon, co-créativité, contraintes, équipes de projet, études de cas
# De l'idée innovante à la co-créativité sous contrainte :
# constitution, dynamique et coordination d'équipes de projets
# Hackathon

## INTRODUCTION

Les Hackathons sont l'illustration par excellence de 'comment faire volontairement travailler des équipes composées de personnes qui, a priori, se ne connaissent pas du tout, pendant tout un week-end (même la nuit) en faisant don de leur temps, motivation et compétences, sous des contraintes et tout ceci dans la joie et le plaisir'. Apparu vers la fin des années 1990 (Briscoe et Mulligan, 2014), le 'marathon de hackers' a été imaginé avec l'objectif de 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, tout en 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 plusieurs années (Russo, 2011 ; Briscoe et Mulligan, 2014 ; Angarita et Nolte, 2020) avec une progression de recherches sur des thématiques différentes et variées : l'innovation digitale (Briscoe et Mulligan, 2014), la santé (Angelidis, Berman et al., 2016), le Hackathon comme levier de la créativité (Bokoko, 2020) ou sa capacité transformationnelle (Dionne et Carlile, 2016). Il existe 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) et des revues de littérature et de perspectives de recherche (Falk, Nolte et al., 2022 ; Flus et Hurst, 2021). L'effet du Hackathon a été étudié au niveau du design (Gréselle-Zaïbet, Kleber et Dejoux, 2018), de l'apprentissage (Kienzler et Fontanesi, 2016 ; Nandi et Mandernach,
2016), de l'entrepreneuriat (Irani, 2015), du devenir des projets après le Hackathon (Nolte, Chounta et Herbsleb, 2020) et en entreprise (Pe-Than, Nolte et al., 2022; Ronfaut, 2014). Son organisation du travail (Schulte, Nolte et al., 2022; Yong, 2021; Söderberg, 2021; Zukin et Papadantonakis, 2018; Gregg, 2015) a également fait l'objet de nombreuses publications.

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, puis aux contraintes spécifiques aux Hackathons jusqu'aux dynamiques de développement 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. 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<fnref n="1" />. Nous avons sélectionné au hasard trois projets parmi les vingt-trois projets élus par les quatre cents participants.

<footnote n="1">¹ Un Hackathon démarre le vendredi soir avec les *pitchs* des projets, suivi d'une sorte de marché où les participants choisissent leur projet, et les équipes se constituent. De vendredi soir à dimanche après-midi, elles poursuivent leur travail et préparent la démo finale afin de présenter le résultat au jury et de gagner un prix.</footnote>
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 question 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 rôle des porteurs de projet. Notre objectif est de comprendre à l'aide de ces 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) alors que les entreprises en sont friandes (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<fnref n="2" /> n'est pas étudiée, pas plus que l'étude des dispositifs de management du processus d'innovation qui y émergent.

Afin de compléter ces recherches, nous développerons, sous forme d'un entonnoir, et enrichirons ce cadre en trois volets :

- Le concept des *Grounds* (Cohendet, Grandadam et Simon, 2010) et les processus de co-construction de l'innovation dans les *Grounds* d'un Hackathon : nous supposons que le phénomène des *Grounds* se reproduit dans le Hackathon qui, donc, lui-même se structure selon cette logique

<footnote>Pour plus d'informations, voir aussi https://hackinghealth.camp/hacking-health-camp-edition-2016/ et Dionne et Carlile (2016).</footnote>

<footnote n="2">² Un Hackathon peut être également considéré comme « un tiers-lieu éphémère, pour permettre à des acteurs appartenant à des institutions différentes d'innover collectivement » (Grenier *et al.*, 2020, p. 91) et une étude sous l'angle de l'éphémérité est certainement important et fera l'objet d'une prochaine recherche. Cependant, notre analyse se concentre sur les effets des contraintes qui caractérisent et conditionnent cet événement particulier.</footnote>
de *Grounds*, à savoir : l'Underground avec les participants, le Middleground avec les organisateurs et l'Upperground avec les 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 des contraintes de projets en fonction de leur cahier des charges ; ce paradoxe de contraintes de la co- créativité encadre et stimule la tension entre liberté et contrainte.

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

Notre recherche permet ainsi d'approfondir la compréhension de la dynamique de créativité fortement appréciée au cours des Hackathons en mobilisant la lecture des *Grounds* et la scénarisation des contraintes.

## 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 lecture, 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* représente des entreprises qui apportent 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. Il devient ainsi possible 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é. C'est à l'intérieur de cet écosystème multi strates que va émerger et se développer l'innovation.

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

Cohendet, Parmentier et Simon (2017) identifient quatre grandes phases du processus d'idéation, à 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 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 é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). Ces porteurs de 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'Undergroud 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.

## 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, au cœur du 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 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 karakoky 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 ont pour objectif de tirer bénéfice de ces contraintes en maintenant 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 d'abord données par le porteur du projet avec l'objectif 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. Mais elles peuvent aussi être utiles dans le cas de certaines équipes dispersées, même au risque de ne pas optimiser le résultat.

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, comme 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, 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 champs ambivalent que le porteur de projet doit œuvrer pour stimuler la créativité et la motivation de son équipe, constituée spontanément de membres inconnus, dès le début du Hackathon, afin 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). Surtout 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. Cette partie nous donne l'occasion de nous pencher sur la diversité des dynamiques organisationnelles au niveau micro-social que constitue chaque équipe en observant en particulier les micro-pratiques d'organisation ou de désorganisation (boucle rétroactive) dans la progression globale de l'avancement du projet et du déploiement du potentiel de créativité, exponentiel, dans ce contexte.

### 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.

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. Au moment du marché, ces équipes peuvent être complétées par des volontaires. Le *Sparkboard* permet aux participants de s'informer des projets avant le Hackathon et de communiquer aux porteurs leur intérêt. 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. Constitution et coordination du projet sont donc assez sensibles au mode de recrutement mais nécessite également, au préalable au démarrage dans tous les cas, l'adhésion au sens partagé du projet, à son objectif final.

### 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 micro 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).

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. 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. 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. 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.

Ces étapes de constitution des équipes d'un Hackathon sont aisément observables, même si chaque équipe les franchit à son rythme.

### 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 de 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, et cette homologie peut permettre de se mettre d'accord plus rapidement. Les FT, en revanche, ne disposent pas de cette condition préalable et choisissent le projet selon d'autres 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 éphémères ;

ii) Le champ ambivalent de la co-créativité sous contrainte dans lequel le porteur œuvre pour stimuler la créativité et la motivation de son é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 de l'équipe.

Notre recherche vise alors à répondre aux questions principales : 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.

Sous l'influence des *Grounds* et des contraintes de co-créativité imposées dans le cadre d'un Hackathon, nous observons comment les équipes projet se structurent et se coordonnent de manière à répondre rapidement et efficacement à al demande du porteur de projet. Leurs dynamiques et effets
sur la simulation de la créativité ainsi que le rôle des porteurs de projet peuvent également avoir un
impact sur cette dynamique, et nous les avons intégrés à notre analyse. Notre objectif est de
comprendre à l'aide de tris études de cas le rôle de la constitution, des dynamiques et de la
coordination d'équipes de projet de Hackathon dans le processus de transformation d'une idée
innovante vers une co-créativité sous contrainte.

## 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.
Nous avons mené des entretiens ponctuels avec des membres des trois équipes, disposons également de vidéos retraçant l'avancement des trois projets sélectionnés durant ce Hackathon, de photos, et de trois interviews. Nous avons visionné, décrypté, décrit et confronté nos résultats et interprétations au sein de notre équipe de recherche et vérifié nos analyses à travers d'interviews.

Le tableau 1 retrace notre approche méthodologique nous permettant, en partant des éléments d'observation, des grilles théoriques et des catégories conceptuelles appliquées, de formaliser le codage de nos trois projets observés.

<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>
<table><caption>Tableau 1. Récapitulatif méthodologique</caption><thead><tr><td>Éléments d'observation</td><td>Grille théorique</td><td>Catégories conceptuelles</td><td>Codage</td></tr></thead><tbody><tr><td>Typologie des membres de l'équipe</td><td>Appartenance Ground</td><td>Grounds pour comprendre spécificités</td><td>Parmi les trois catégories non exclusives</td></tr><tr><td>Types d'interactions privilégiées en interne dans l'équipe</td><td>Organisation leadership</td><td>Management participatif, délégatif, directif</td><td>Formel, informel, niveau de partage, de manipulation</td></tr><tr><td>Types d'interactions privilégiées avec l'équipe organisatrice</td><td>Organisation leadership</td><td>Contraintes et supports</td><td>Pitch, coaching, phasage, logistique</td></tr><tr><td>Appropriation des contraintes de temps</td><td>Motivation vs. Indifférence</td><td>Cadencement, scénarisation, outils</td><td>Management temporel, présentation finale</td></tr><tr><td>Appropriation des contraintes d'espace</td><td>Logistique</td><td>Radical collocalisation &amp; team coordination</td><td>Espace attribué et exploité</td></tr><tr><td>Perception de l'intérêt collectif, personnel, autocentré ou non du résultat du projet</td><td>Valeur et sens</td><td>PET &amp; FT</td><td>Familiarité vs. Esprit de communauté</td></tr><tr><td>Phasage de déroulement du projet</td><td>Management de projet</td><td>Agilité</td><td>Constitution de l'équipe, processus de collaboration</td></tr><tr><td>Scénarisation spontanée du projet (clashs, types d'interaction, de dialogues, etc.)</td><td>Microsociologie</td><td>Forming, Storming, Norming &amp; Performing</td><td>Structuration, collaboration, conflits</td></tr><tr><td>Langage verbal (vocabulaire, technicité) et non verbal</td><td>Familiarité</td><td>Proximité vs. Distance</td><td>Interaction directe, par intermédiaire</td></tr></tbody></table>

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, karaoké et fête
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, karakoky 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. Nous structurant volontairement la présentation de nos cas en ces deux étapes, essentielles pour la compréhension de nos cas et leur analyse à l'aide des concepts retenus.
## 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 relacent 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, « vingt 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.
Le tableau 2 synthétise les conclusions comparatives des trois projets de Hackathon observés.

<table><caption>Tableau 2. Récapitulatif de l'analyse des trois projets observés</caption><thead><tr><th></th><th>Projet 1 : Plateforme de mise en relation d'acteurs de la santé</th><th>Projet 2 : Des Jeux vidéo pour un enfant handicapé</th><th>Projet 3 : Un Casque pour des patients atteints d'un AVC</th></tr></thead><tbody><tr><td>Constitution de l'équipe</td><td>12</td><td>8</td><td>11</td></tr><tr><td>Cible du projet</td><td>Professionnels de santé (autocentré)</td><td>Patient unique</td><td>Patients multiples</td></tr><tr><td>Spécificités du projet</td><td>Application de mise en relation, exclusivement du codage et détection des besoins des acteurs</td><td>Adaptation aux spécificités d'un enfant en particulier, avec aller-retour et codage</td><td>Adaptation à une grande variété de situations liés aux patients très différents les uns des autres, coordination pour synthétiser ces informations puis codage</td></tr><tr><td>Phasage de la collaboration</td><td>2 phases</td><td>3 phases</td><td>2 phases</td></tr><tr><td>Inspiration du projet</td><td>Underground</td><td>Underground &amp; Upperground</td><td>Upperground</td></tr><tr><td>Type de collaboration</td><td>Collective</td><td>Classique hiérarchique</td><td>Classique hiérarchique</td></tr><tr><td>Focus contrainte</td><td>Fonctionnement et consensus collectif</td><td>Attentes famille / enfant et école</td><td>Fonctionnement et consensus chez les leaders du projet</td></tr></tbody></table>

Le rôle des Grounds et leur lien avec le fonctionnement en équipe des projets paraît construire le mode de fonctionnement. Mais l'origine de la constitution de l'équipe, du partage de l'objectif commun et de sociabilisation paraissent être également des préalables à l'émergence des dynamiques de créativité. La contrainte temporelle ne paraît pas limiter en revanche la capacité créative mais, plutôt intériorisée par les acteurs, elle semble les galvaniser autour de l'atteinte de ce fameux objectif, même presqu'irréaliste au départ.
# 3. RESULTATS ET DISCUSSION

L'objectif de notre recherche est de mieux comprendre les effets des *Grounds*, 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, les dynamiques et la coordination des équipes ainsi que leur effet sur la créativité et l'innovation.

## 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 50 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
ressesemble 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, quant à lui, 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 elle a 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, les dynamiques et la coordination des équipes

#### 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). 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. 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.

### 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 dont 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 de *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 *Undergrounds*), 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

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.

## 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 quel est le rôle des porteurs de projet. 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 et des dynamiques de l'équipe.

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.

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 (pp. 2-27), Bathelt, H., Cohendet, P., Henn, S. & Simon, L. (Eds.), The Edward Elgar Companion to Innovation and Knowledge Creation, Edward Elgar Publishing.

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.
Grenier, C., Ibrahim, R. & Duprat, L. (2020), Comment organiser un tiers-lieu pour favoriser l'émergence d'innovations ? Le cas d'un pôle d'opérateurs de services à domicile, *Innovations*, 61, 89-115.

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.

Hacking Health Camp 2016 : https://hackinghealth.camp/hacking-health-camp-edition-2016/ (consulté le 26.04.2024).

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. (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.

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.

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 (pp. 133-152), 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.

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.