Hackathon en entreprise : guide pour l’organiser et l’animer

Un mardi matin, la DRH annonce un hackathon interne pour faire émerger des idées. Quarante personnes, une journée, un jury, des pizzas. Le soir, l’énergie est là et les pitchs sont applaudis. Trois mois plus tard, aucun projet n’a avancé d’un pas, et les participants ne se réinscriront pas au prochain.

Ce scénario est inventé, mais il résume le risque principal du format. Un hackathon se gagne rarement le jour J. Il se joue avant, dans la formulation du défi, et après, dans ce que la direction fait des prototypes.

Ce guide s’adresse à ceux qui commandent un hackathon comme à ceux qui l’animent. Vous y trouverez une définition, les cas où le format est pertinent, ses quatre conditions de réussite et un déroulé en cinq temps. Suivent trois formats, les erreurs fréquentes et ce qui se joue le jour d’après.

Le mot vient du monde du logiciel. Selon le dictionnaire Merriam-Webster, il associe hack au suffixe -athon, tiré de marathon, et sa première attestation remonte à 1990. Il désigne un événement où des programmeurs collaborent intensivement, sur une courte période, pour créer un logiciel.

Le format a depuis quitté le seul monde du code. En 2016, Elizabeth Spaulding et Greg Caimi, de Bain & Company, montraient dans la Harvard Business Review que des entreprises hors tech l’employaient. Les sujets traités allaient de la culture d’entreprise à la chaîne logistique.

En entreprise, un hackathon est donc un temps court où des équipes mixtes transforment un problème réel en prototypes. Le prototype s’entend au sens large : une maquette, un parcours client dessiné, une procédure testée, un plan d’action d’une page. Ce qui le distingue d’un atelier, c’est le livrable tangible et la décision qui suit.

Avant de fixer une date, posez une question au commanditaire : que ferez-vous, concrètement, du projet gagnant ? Si la réponse reste floue, le hackathon produira de l’enthousiasme, puis de la déception. C’est le premier test à faire passer à tout projet de hackathon.

La taille du groupe compte aussi. Nous déconseillons le format en dessous d’une quinzaine de participants, car il n’y a alors pas assez d’équipes pour confronter des pistes différentes. Pour un petit groupe, un atelier d’idéation bien construit suffit souvent.

Enfin, un hackathon ne soigne pas un collectif abîmé. Quand le vrai sujet est un conflit ou une réorganisation, l’énergie demandée par le format se retourne contre l’équipe. Ces situations demandent un cadre différent, posé par un facilitateur expérimenté.

Le défi est la pièce la plus sous-estimée. Une formulation comme « innover dans la relation client » ne guide personne. Une question comme « comment un nouveau client pourrait-il obtenir une réponse dès son premier appel ? » donne une direction sans imposer de réponse. Pour travailler cette formulation, notre liste de 100 questions puissantes offre de bons points de départ.

Côté équipes, la Direction interministérielle de la transformation publique recommande des tables de 5 à 7 personnes. Ce repère rejoint l’analyse de J. Richard Hackman, chercheur à Harvard, qui conseillait de garder les équipes sous la barre des dix membres. Mélangez les profils : le commercial, le technicien et la personne de l’accueil ne voient pas le même problème.

Le livrable et l’engagement de suite se décident avant le jour J, avec le commanditaire. Ils figurent ensuite dans le discours d’ouverture. Les participants savent ainsi pourquoi ils travaillent et ce qu’il adviendra de leur production.

Le jury mérite le même soin. Trois ou quatre personnes suffisent souvent, dont le sponsor et au moins un représentant du terrain concerné. Leurs critères sont annoncés à l’ouverture : l’impact attendu, la faisabilité avec les moyens disponibles, la clarté du prototype. Un jury qui invente ses critères après coup abîme la confiance des participants, même quand son choix final est bon.

Le cadrage commence deux à quatre semaines avant pour un hackathon interne. Pour un événement ouvert au public, la Direction interministérielle de la transformation publique compte au moins deux mois de préparation. C’est le moment où l’on écrit le défi, choisit le jury et fixe ce qui sera fait des projets.

L’ouverture donne le ton. Le commanditaire explique l’enjeu en quelques minutes, puis le facilitateur pose les règles et forme les équipes. L’exploration vient ensuite : les équipes interrogent des utilisateurs, des collègues de terrain ou des experts avant de chercher la moindre idée. Spaulding et Caimi recommandent d’ailleurs des entretiens directs avec les clients et le personnel de terrain.

Pour l’idéation, la méthode 635 de brainwriting fait produire beaucoup d’idées par écrit, chacun enrichissant la feuille de son voisin. Pour trier, le dot voting permet de choisir en quelques minutes. Pour rendre une idée tangible, la product box aide l’équipe à matérialiser les bénéfices de son idée.

Côté logistique, prévoyez :

• un espace par équipe, avec paperboard et matériel de prototypage ;
• une connexion internet, une sonorisation et un projecteur pour les pitchs ;
• des repas et des pauses sur place, pour ne pas casser le rythme ;
• un minuteur visible de tous pendant les pitchs.

Le hackathon fait partie de nos fiches méthodes pour facilitateurs, où vous trouverez d’autres formats à combiner.

Le format court n’est pas une version au rabais. Pour un comité de direction qui veut tester une piste sur un irritant précis, une demi-journée bien cadrée suffit souvent. La journée complète reste le format que nous recommandons pour un premier hackathon interne, avec plusieurs équipes mixtes.

Le format long a ses références. L’article de Spaulding et Caimi cite le 50e hackathon de Facebook, organisé sur 24 heures avec environ deux cents ingénieurs. Il cite aussi une banque qui a réuni 18 participants en cinq équipes pendant trois jours.

Un hackathon peut aussi se tenir à distance, avec un tableau blanc partagé et des salles de travail virtuelles. Le format y perd en énergie ce qu’il gagne en accessibilité. Prévoyez alors des séquences plus courtes, des pauses plus fréquentes et un facilitateur par groupe de deux ou trois équipes.

Un point de vigilance sur les formats de nuit. Ils excluent de fait ceux qui ont des contraintes familiales, et ils font coïncider le moment de choisir avec celui de la plus grande fatigue. Pour un hackathon interne, deux journées consécutives valent souvent mieux qu’une nuit blanche.

Ces erreurs ont un point commun : elles ne se voient pas pendant l’événement. La journée peut sembler réussie, avec de l’énergie et de beaux pitchs. Le coût apparaît plus tard, quand les participants constatent que rien ne bouge.

La quatrième erreur mérite une attention particulière. Un hackathon met des équipes en compétition, mais son but reste collectif. Quand un manager presse son équipe de gagner, les participants risquent de cesser d’explorer pour défendre la piste la plus sûre. Le facilitateur doit rappeler que l’objectif est de bien poser un problème, pas seulement de remporter un prix.

La cinquième erreur est la plus coûteuse. Un hackathon sans suite apprend aux salariés que leurs idées servent de décor. La fois suivante, les plus engagés risquent de ne pas revenir.

Ces chiffres portent sur des hackathons logiciels recensés sur Devpost, pas sur des hackathons internes d’entreprise. Ils donnent pourtant un ordre de grandeur utile : sans organisation délibérée, l’élan du jour J retombe très vite. L’étude identifie aussi ce qui favorise la continuité, en particulier la diversité des compétences dans l’équipe et l’intention d’étendre le projet au-delà de l’événement.

Les recommandations convergent. La Direction interministérielle de la transformation publique conseille de définir à l’avance le devenir des projets : mode de sélection et accompagnement prévu. Spaulding et Caimi recommandent d’investir dans les meilleures idées et de poursuivre les tests après l’événement.

Mesurez enfin ce que le hackathon a produit, au-delà des prototypes. Combien de projets ont été testés à trente jours ? Combien de participants ont travaillé avec un service qu’ils connaissaient mal ? Combien de décisions ont été prises à quatre-vingt-dix jours ? Ces trois indicateurs disent plus que le nombre d’idées produites le jour J.

Un hackathon isolé ne crée pas non plus une culture d’innovation. Il peut en être une étape s’il s’inscrit dans une démarche plus large. Nous la décrivons dans notre article sur la culture d’innovation interne.

Vous êtes dirigeant ou DRH et envisagez un hackathon ? Notre séminaire d’innovation sur mesure mobilise ce format parmi d’autres méthodes, après un entretien de cadrage.

Vous êtes facilitateur, manager ou formateur et voulez animer vous-même ce type de dispositif ? Insuffle Académie, la branche organisme de formation d’Insuffle, propose une formation facilitation et intelligence collective de trois jours. Elle est portée par un organisme certifié Qualiopi et peut être financée par votre OPCO.

Un hackathon utile tient en trois moments. Avant, un défi clair et un engagement de suite écrit. Pendant, des équipes mixtes qui comprennent avant de résoudre. Après, des décisions annoncées à dates fixes. Le jour J n’est que la partie visible.

Si vous ne retenez qu’une chose, retenez la question à poser au commanditaire : que ferez-vous du projet gagnant ? Sa réponse vous dira si le format est le bon.