Hackathon interne : définition, organisation pas à pas et exemple en entreprise

Deux jours, des équipes mêlant des métiers qui ne travaillent jamais ensemble, un défi réel et un prototype à présenter à la fin : le hackathon interne promet d’accélérer l’innovation. Il tient souvent sa promesse le jour même, et la perd le lendemain, quand les projets primés retournent dans les tiroirs faute de suite. Voici ce qu’est un hackathon interne, d’où vient le format, comment le cadrer, le déroulé type sur deux jours, un exemple commenté, la manière de l’animer et ce qui fait qu’un hackathon produit autre chose qu’un bel événement.

Hackathon interne : définition

Un hackathon est un événement intensif, généralement de 24 à 48 heures, au cours duquel des équipes conçoivent et réalisent un prototype en réponse à un défi. Le hackathon interne est réservé aux collaborateurs d’une organisation et se déroule sur le temps de travail. Il se distingue du hackathon ouvert, qui invite des participants extérieurs, étudiants, start-up ou développeurs, et sert souvent aussi la marque employeur ou l’open innovation.

Trois traits le définissent. Le temps est court et fixé d’avance, ce qui oblige à choisir vite. Les équipes sont pluridisciplinaires : un hackathon interne réussi mélange l’informatique, les métiers, le service client, les fonctions support. Et il doit produire quelque chose de tangible : une maquette, un processus testé, un parcours prototypé, pas seulement une idée.

Le mot a gardé une connotation technique, mais le format s’est largement étendu. On organise aujourd’hui des hackathons sur les achats, les ressources humaines, la relation client ou la simplification administrative, avec des prototypes en papier, en tableur ou en outils sans code.

D’où vient le hackathon ?

Le mot apparaît en juin 1999, de deux côtés à la fois. Le 4 juin, une dizaine de développeurs du système d’exploitation OpenBSD se réunissent à Calgary, au Canada, pour travailler ensemble sur du code cryptographique, en partie pour contourner les restrictions américaines à l’exportation de ce type de logiciel. Quelques jours plus tard, du 15 au 19 juin, la conférence JavaOne de Sun Microsystems lance un défi aux participants : écrire en Java un programme pour le nouvel assistant Palm V, utilisant son port infrarouge. Les deux événements sont baptisés hackathon.

Le format entre ensuite dans les entreprises. L’éditeur australien Atlassian lance en 2005 des journées de 24 heures, d’abord appelées FedEx Days, parce qu’il faut « livrer » quelque chose en 24 heures, puis rebaptisées ShipIt. Facebook fait de ses hackathons nocturnes un rituel dont sont issues, selon l’entreprise, des fonctionnalités comme la messagerie instantanée, le journal (Timeline) ou le bouton « J’aime ». Le hackathon interne s’est depuis diffusé bien au-delà des entreprises du numérique, y compris dans le secteur public, qui a publié ses propres guides pratiques.

Ce qu’un hackathon interne apporte, et ce qu’il n’apporte pas

Dans notre étude de l’innovation collaborative, menée depuis dix ans auprès d’une cinquantaine de grandes organisations, le hackathon et sa variante non technique, l’innovathon, figurent parmi les principaux dispositifs utilisés pour mobiliser les équipes en interne. Leurs atouts sont réels : faire travailler ensemble des métiers qui s’ignorent, obtenir en deux jours des prototypes qui auraient demandé des semaines de réunions, révéler des talents, donner un signal fort sur la place faite aux idées des salariés.

Leurs limites sont tout aussi connues. Un hackathon ne remplace pas un processus d’innovation : sans budget, sans temps alloué et sans décideur pour reprendre les projets, il devient un événement de communication, et les participants s’en souviennent la fois suivante. Il fatigue s’il se transforme en nuit blanche obligatoire. Et il exclut s’il est présenté comme une affaire de développeurs.

Le Canevas de cadrage hackathon NextStart

La réussite d’un hackathon interne se décide avant l’annonce. Nous utilisons un canevas de dix questions, à trancher avec le sponsor de l’événement.

Question	Ce qu’il faut décider	Exemple
1. Pourquoi ce hackathon ?	Un objectif principal : résoudre des irritants, explorer un sujet nouveau, décloisonner	Réduire de moitié le délai d’adhésion d’un client
2. Quels défis ?	Deux à six défis réels, formulés en question « Comment pourrions-nous… ? », chacun porté par un métier	Comment pourrions-nous rendre l’adhésion possible en un seul échange ?
3. Qui sponsorise ?	Un dirigeant qui ouvre l’événement, assiste aux présentations et s’engage sur la suite	Le directeur des opérations
4. Qui participe ?	Volontaires, profils mélangés, équipes de quatre à sept personnes	60 participants de 9 directions
5. Quel format ?	Durée, temps de travail, présentiel ou hybride, sans nuit blanche	Deux journées de 9 h à 18 h
6. Quelles ressources ?	Données, outils, experts disponibles, accès aux systèmes	Données anonymisées, outils sans code, deux experts juridiques
7. Qui accompagne ?	Facilitateurs, coachs, experts techniques	Un coach pour deux équipes
8. Quels critères ?	Critères du jury annoncés dès le lancement	Valeur pour le client, faisabilité, effort de mise en œuvre
9. Quelle suite ?	Ce que reçoivent les projets retenus : temps, budget, sponsor	Six semaines à 20 % du temps de deux personnes
10. Comment mesurer ?	Indicateurs à trois et six mois	Projets testés, projets déployés, effet sur l’indicateur visé

Les questions 2, 3 et 9 sont les plus souvent bâclées, et ce sont elles qui décident du résultat. Un défi sans métier porteur produit des idées que personne ne reprend. Un sponsor absent aux présentations envoie le signal inverse de celui recherché. Et une suite décidée après l’événement arrive toujours trop tard.

Organiser un hackathon interne : le déroulé type sur deux jours

• Avant, de quatre à huit semaines. Cadrer avec le canevas, recruter les participants, former les coachs, préparer les données et le matériel, présenter les défis.
• Jour 1, matin : comprendre. Lancement par le sponsor, présentation des défis, constitution des équipes, exploration du problème : entretiens avec des utilisateurs, écoute d’appels, données, visite de terrain.
• Jour 1, après-midi : imaginer et choisir. Production d’idées, puis choix d’une piste par équipe ; premiers croquis.
• Jour 2, matin : prototyper et tester. Construire une maquette, un document, un parcours, et le faire essayer par de vrais utilisateurs ou des collègues du métier.
• Jour 2, après-midi : pitcher et décider. Présentations courtes, délibération du jury sur les critères annoncés, annonce des projets retenus et de leur suite.
• Après, pendant trois mois. Points d’étape avec le sponsor à 30, 60 et 90 jours, pour décider de déployer, de prolonger ou d’arrêter.

Ce déroulé suit la logique du double diamant : comprendre le problème avant de chercher des solutions, et chaque fois ouvrir largement avant de choisir. Pendant la phase d’idées, une technique comme la méthode SCAMPER aide les équipes à dépasser leurs premières pistes ; pour choisir, une matrice impact / effort évite de retenir l’idée la plus spectaculaire plutôt que la plus utile.

Nous recommandons deux journées de travail, sans nuit. Les éditions de 48 heures non-stop ont leur charme, mais elles écartent les personnes qui ont des contraintes familiales et produisent rarement de meilleurs prototypes. Pour un défi unique à traiter en profondeur, le design sprint, sur cinq jours avec une seule équipe, est souvent plus adapté.

Un exemple commenté

Prenons un exemple fictif mais réaliste. Une mutuelle de 1 200 salariés constate que l’adhésion d’un nouveau client demande en moyenne trois échanges et douze jours. La direction des opérations organise un hackathon interne de deux jours, avec quatre défis, soixante volontaires de neuf directions et huit équipes, chacune accompagnée par un coach.

Le premier matin, chaque équipe passe deux heures avec des conseillers et écoute des appels enregistrés. L’une d’elles découvre que la moitié des allers-retours vient d’une seule pièce justificative, demandée sous un format que les clients ne comprennent pas. Le deuxième jour, elle prototype une page d’explication et un message type, et les teste auprès de six conseillers et de trois clients volontaires. Sa présentation ne montre pas une application, mais la modification de trois documents et d’un écran.

Le jury retient deux projets, dont celui-ci. La suite avait été décidée avant l’événement : chaque projet retenu dispose de six semaines, d’un sponsor et de 20 % du temps de deux membres de l’équipe. Trois mois plus tard, le délai d’adhésion est passé de douze à sept jours sur le périmètre testé. Les six autres projets n’ont pas été déployés, mais trois de leurs idées ont rejoint la feuille de route du service client.

Ce que l’exemple montre. Le meilleur projet n’est pas le plus technologique, c’est celui qui a le mieux compris le problème. Et l’effet vient de la suite organisée à l’avance, pas de l’événement lui-même.

Animer un hackathon interne

Un hackathon interne est d’abord un grand atelier collaboratif. Sa réussite dépend moins des outils que de la qualité de l’animation.

• Des coachs formés, un pour une ou deux équipes, qui animent le processus sans prendre la main sur le contenu.
• La production individuelle avant l’échange. À chaque phase d’idées, quelques minutes de réflexion seul avant de partager, pour que les profils les moins à l’aise avec le sujet contribuent autant que les autres.
• Séparer ouvrir et décider. Un temps pour multiplier les pistes, un temps pour en choisir une, avec des critères connus de tous.
• Des facilitateurs neutres sur le résultat : ils ne poussent pas l’idée qui leur plaît.
• Les managers et le sponsor parlent en dernier. Présents au lancement et aux présentations, discrets entre les deux : un directeur qui passe « donner son avis » dans une équipe oriente tout son travail.
• Une équipe d’animation répartie. Au-delà d’une cinquantaine de participants, l’animation se partage entre plusieurs facilitateurs, ce qui suppose de s’être réparti les rôles à l’avance : c’est tout l’enjeu de la co-facilitation.

Nous concevons et animons ce type de format intensif pour des directions qui veulent faire travailler leurs équipes sur un enjeu réel en un ou deux jours : c’est notre démarche Innover en équipe sur un temps court.

Hackathon, design sprint, challenge d’idées, séminaire : quel format choisir ?

Format	Durée	Participants	Ce qu’il produit	Quand le préférer
Hackathon interne	1 à 2 jours	20 à 200, en plusieurs équipes	Plusieurs prototypes sur plusieurs défis	Pour mobiliser largement et décloisonner
Design sprint	4 à 5 jours	Une équipe de 5 à 7 personnes	Un prototype testé sur un défi	Pour traiter en profondeur un défi important
Challenge d’idées en ligne	Quelques semaines	Des centaines à des milliers	Beaucoup d’idées, peu de prototypes	Pour consulter largement avant de choisir
Séminaire collaboratif	1 à 2 jours	Une équipe de direction ou un service	Des décisions et un plan d’action	Pour aligner et décider, plus que pour prototyper
Forum ouvert	Une demi-journée à 2 jours	20 à plusieurs centaines	Des sujets portés par les participants	Quand l’ordre du jour doit venir du groupe

Ces formats se combinent : un challenge d’idées peut alimenter les défis d’un hackathon, et un hackathon peut faire émerger le sujet d’un design sprint. Pour les deux derniers, voir nos articles sur l’organisation d’un séminaire et sur le forum ouvert.

Quand organiser un hackathon interne

• Pour traiter des irritants transverses qu’aucune direction ne peut régler seule.
• Pour explorer un sujet nouveau et repérer les personnes qui ont envie de s’y investir.
• Pour lancer une transformation par le terrain plutôt que par une note de cadrage.
• Pour décloisonner après une fusion ou une réorganisation, en faisant travailler ensemble des équipes qui se connaissent mal.

Mieux vaut s’abstenir quand la décision est déjà prise, quand il n’y a ni temps ni budget pour la suite, quand le sujet demande des mois d’expertise, ou quand le climat social est tendu : un hackathon risque alors d’être perçu comme une opération de façade.

Les limites et les erreurs fréquentes

• Des défis trop vagues. « Innover pour nos clients » ne donne prise à rien ; un défi précis, porté par un métier, produit des projets utilisables.
• Aucune suite prévue. C’est l’erreur la plus fréquente et la plus coûteuse : elle décourage les participants pour les éditions suivantes.
• Un jury qui récompense le meilleur pitch plutôt que le meilleur projet. Des critères annoncés à l’avance limitent ce biais.
• Des équipes homogènes. Une équipe composée d’un seul métier reproduit les solutions qu’il connaît déjà.
• Le culte de la nuit blanche. Il exclut une partie des volontaires et n’améliore pas les résultats.
• Oublier les managers des participants. Deux jours d’absence non anticipés créent du ressentiment ; ils doivent être prévenus et associés.

Questions fréquentes sur le hackathon interne

Pour approfondir. Gerard Briscoe et Catherine Mulligan, Digital Innovation: The Hackathon Phenomenon, Creativeworks London (2014), sur l’origine du mot et les ressorts du format ; Daniel H. Pink, Drive: The Surprising Truth About What Motivates Us, Riverhead (2009), qui a fait connaître les FedEx Days d’Atlassian ; Hackathon, le guide pratique, Bibliothèque des initiatives de la fonction publique (2023). Sur le même blog : le design sprint en 5 jours et le double diamant.