Hackathons, jams et défis : tous les formats expliqués

Il existe une douzaine de types d'événements d'innovation en temps limité, et ils diffèrent sur trois points : qui participe, ce qu'on attend d'eux en sortie, et ce qui se passe ensuite. Un hackathon construit un logiciel ou un matériel qui fonctionne ; une jam conçoit et prototype un service ou une expérience autour d'un thème ; un défi d'innovation sollicite des solutions à un problème donné sur plusieurs semaines ou plusieurs mois. Choisissez le format selon ce dont vous aurez besoin le lundi matin, pas selon le nom qui sonne le mieux.

Ce guide passe en revue tous les formats courants, dit ce que chacun fait bien et moins bien, et renvoie vers les articles approfondis de ce hub.

Les trois questions qui permettent de classer tous les formats

Avant les noms, la logique. Chaque événement de cette famille répond différemment à trois questions.

1. Qui est dans la salle ? Vos propres collaborateurs (interne), des partenaires invités (écosystème), ou toute personne qui s'inscrit (ouvert).
2. Qu'est-ce qui compte comme terminé ? Du code qui tourne, un objet physique, un prototype de service testé, une analyse de données ou un concept solidement argumenté.
3. Quelle est la durée ? Une seule journée, les 48 heures classiques, ou un défi qui se déroule sur plusieurs semaines, par étapes.

Si vous savez répondre à ces trois questions pour votre situation, le format s'impose presque de lui-même. Les organisateurs qui les sautent finissent par organiser un « hackathon » dont le véritable objectif était l'engagement des collaborateurs, puis s'étonnent que rien n'aboutisse. Pour une comparaison point par point, voir hackathon, design jam ou défi d'innovation.

Les hackathons : construire vite

Le mot date de juin 1999, quand les développeurs d'OpenBSD et, de leur côté, Sun Microsystems lors de sa conférence JavaOne l'ont tous deux employé pour désigner des sessions de programmation intensives. L'idée de base n'a pas changé : de petites équipes, une échéance courte, et quelque chose qui tourne à la fin.

Hackathon d'entreprise (interne). Les collaborateurs d'une même organisation forment des équipes mixtes pour construire des prototypes répondant à des problèmes métier. Idéal pour révéler des talents internes, décloisonner et tester des idées qui ne survivraient jamais à un comité budgétaire sous forme de note. Faible quand la direction n'a ni plan, ni responsable, ni budget pour ce qui gagne. Lisez pourquoi la plupart des lauréats de hackathon ne voient jamais le jour avant de réserver le lieu.

Hackathon citoyen et public. Un organisme public ouvre ses problèmes, et souvent ses données, aux développeurs, designers et citoyens. L'International Space Apps Challenge de la NASA, organisé chaque année depuis 2012, en est l'exemple mondial le plus connu. Ces événements créent de la confiance et font entrer des compétences extérieures dans l'administration, mais ils ont besoin d'une voie claire pour qu'un prototype atteigne un vrai service, sinon ils deviennent des opérations de bonne volonté. Les hackathons d'intérêt général couvre les versions portées par une cause.

Hackathon ouvert (public). Tout le monde peut s'inscrire. Vous gagnez en diversité, en énergie, et en personnes qui découvrent votre problème pour la première fois. Vous perdez la maîtrise de la propriété intellectuelle, de la confidentialité et du suivi, car la plupart des participants retournent ensuite à d'autres emplois. L'arbitrage est détaillé dans hackathon interne ou ouvert au public.

Hackathon d'écosystème. Plusieurs entités partagent un même défi qu'aucune ne peut résoudre seule : un régulateur, deux banques et une communauté fintech ; un ministère, une université et des hôpitaux. Les équipes sont délibérément composées de personnes de différentes organisations. Le plus difficile n'est pas le week-end, mais de s'accorder en amont sur qui porte le problème et qui finance le lauréat. Voir le hackathon d'écosystème.

Les jams : concevoir des services et des expériences

Une jam reprend la contrainte de temps du hackathon mais change ce qui compte comme terminé. Le livrable est un prototype de service, d'expérience ou de jeu, testé avec de vraies personnes quand c'est possible, plutôt que du code de production.

Service jam. La Global Service Jam a été lancée en 2011 par Adam Lawrence et Markus Hormess de WorkPlayExperience. Des équipes dans de nombreuses villes travaillent pendant 48 heures sur le même thème secret, révélé au départ, puis publient leurs prototypes en ligne sous licence ouverte. La méthode, c'est le service design avec un parti pris pour « faire plutôt que parler » : sortir, parler aux gens, construire une version grossière, la tester, la modifier. C'est le meilleur format pour faire ressentir à une organisation ce qu'est réellement le service design.

GovJam. Le même modèle, destiné au secteur public. La GovJam a été co-initiée en 2012 par le gouvernement australien avec WorkPlayExperience et Protopartners, et la Global GovJam se tient dans des villes du monde entier depuis 2013. Agents publics, designers et citoyens travaillent côte à côte pendant 48 heures sur un thème secret commun. Un événement frère, la Global Sustainability Jam, applique la même approche au développement durable.

Design jam. La version générique, organisée localement : une ou deux journées sur un problème de design, souvent d'expérience utilisateur ou de service précis, avec un facilitateur qui guide la recherche, l'idéation et le prototypage. Plus légère à organiser qu'un hackathon puisque personne n'a besoin d'environnement de développement, et ouverte aux personnes qui ne codent pas.

Game jam. Les équipes créent un jeu jouable autour d'un thème. La Global Game Jam, fondée par Susan Gold, Ian Schreiber, Gorm Lai et Foaad Khosmood et inspirée de la Nordic Game Jam, s'est tenue pour la première fois en janvier 2009 sur 53 sites. Elle dure 48 heures, généralement fin janvier, avec un thème donné au départ. Les organisations utilisent moins les game jams pour les jeux que pour ce qu'elles entraînent : cadrer sévèrement, livrer quelque chose de complet et jouable en deux jours.

Comment organiser vous-même l'un de ces événements, thème compris, est traité dans organiser une jam.

Les variantes en « -thon » : même horloge, autre livrable

Idéathon. Les équipes développent des concepts, pas des réalisations. Le livrable est une formulation du problème, un concept de solution, un storyboard sommaire et un pitch. Utile en amont, quand on ne sait pas encore quel problème compte, ou quand les participants n'ont pas de compétences techniques. Le risque : prendre un pitch soigné pour une preuve. Exigez au moins une conversation avec un vrai usager par équipe.

Datathon. Un hackathon centré sur l'analyse et le croisement de jeux de données plutôt que sur la construction de logiciels. Le livrable est un insight, un modèle ou une visualisation qui répond à une question. Cela ne fonctionne que si les données sont prêtes, nettoyées et autorisées avant le jour J ; la plupart des datathons ratés meurent dans les trois premières heures, sur des problèmes d'autorisation.

Makeathon. Du prototypage physique : matériel, électronique, maquettes de produit, souvent dans un fab lab ou un makerspace. Il faut des outils, des matériaux, des consignes de sécurité et des techniciens, et la durée tend à être plus longue, car fabriquer et casser des objets prend du temps.

Les défis d'innovation : le format long

Un défi d'innovation (parfois appelé appel à solutions ou concours à prix) publie un problème et sollicite des solutions sur plusieurs semaines ou plusieurs mois, généralement par étapes : candidature, présélection, développement accompagné, sélection finale. Il convient aux problèmes qui ne se résolvent pas en 48 heures, aux porteurs de solutions qui travaillent déjà sur le sujet (startups, équipes de recherche, fournisseurs), et aux organisations qui veulent un flux de pilotes plutôt qu'un week-end d'énergie.

Un défi vit ou meurt par son énoncé. Trop large, et vous recevez une pile d'applications génériques ; trop étroit, et vous avez rédigé un appel d'offres. Comment rédiger un énoncé de défi que les gens ont envie de résoudre traite le sujet en profondeur, et des critères de jury qui désignent le bon lauréat couvre les étapes de sélection.

Tous les formats en un coup d'œil

Comment choisir, en cinq étapes

1. Écrivez la phrase du lundi matin. « Après cet événement, nous aurons ___ et ___ en sera responsable. » Si le blanc est « un prototype fonctionnel que notre DSI reprendra », il vous faut un hackathon. Si c'est « trois concepts de service testés que l'équipe expérience client pilotera », une jam. Si c'est « deux startups sous contrat pour un pilote », un défi.
2. Vérifiez que le problème est mûr. Structurez-le avec un arbre à problèmes et transformez le cœur du sujet en quelques questions « Comment pourrions-nous ». Si vous n'y arrivez pas, organisez d'abord un idéathon ou une phase d'exploration.
3. Alignez les compétences sur le livrable. Du code qui tourne exige des développeurs dans la plupart des équipes. Des prototypes de service exigent des personnes prêtes à parler à des inconnus. Les événements data exigent des données propres et autorisées.
4. Décidez de l'« après » avant le « pendant ». Nommez le responsable, la ligne budgétaire et la date de décision pour les lauréats. Comment organiser un hackathon qui produit quelque chose de réel l'intègre au plan.
5. Choisissez jurés et mentors pour le livrable, pas pour la photo. Des jurés qui porteront le résultat ; des mentors qui connaissent le problème. Voir les mentors d'un hackathon.

Exemple illustratif

Illustratif. Une autorité organisatrice des transports d'une ville moyenne d'Europe du Nord voulait réduire les correspondances manquées par les voyageurs âgés. Son premier réflexe a été un hackathon ouvert avec un prix pour la meilleure application. En préparant l'événement, l'équipe a écrit sa phrase du lundi matin et s'est aperçue qu'elle ne voulait pas d'application du tout : elle voulait savoir quelle partie du trajet échouait et quels changements de service le personnel pouvait faire avec le budget actuel.

Elle a organisé à la place une service jam de deux jours, avec des conducteurs, des agents de gare, quelques voyageurs âgés et deux designers. Les équipes ont passé la première matinée à parcourir les lignes et à interroger des voyageurs, ont construit des storyboards et des prototypes papier d'annonces, de signalétique et d'un rôle de « binôme de correspondance », puis les ont testés dans un vrai pôle d'échanges. Un panel de mise à l'épreuve composé du directeur des opérations et de deux chefs de gare a retenu deux concepts à piloter. Un hackathon a suivi six mois plus tard, avec un cahier des charges resserré : construire l'alerte de correspondance en temps réel dont la jam avait montré que les voyageurs voulaient vraiment.

À faire, à éviter

À faire

• Choisir le format selon le livrable attendu et la personne qui le portera.
• Publier le problème, les critères du jury et ce que reçoivent les lauréats avant l'ouverture des inscriptions.
• Composer les équipes à dessein : experts métier avec bâtisseurs, juniors avec seniors, internes avec externes.
• Planifier les 90 jours qui suivent l'événement aussi soigneusement que ses 48 heures. Une check-list de déploiement y aide.
• Pour les événements d'écosystème, dessiner une carte d'écosystème et s'accorder sur qui porte quoi avant d'inviter qui que ce soit.

À éviter

• Appeler hackathon un événement d'engagement, puis promettre une mise en œuvre.
• Lancer un datathon avant que les données ne soient autorisées, ou un hackathon sans accès aux systèmes que le prototype doit toucher.
• Laisser le pitch tout décider. Notez les preuves et la faisabilité avec une matrice de décision pondérée, pas à l'applaudimètre.
• Copier le principe du thème secret d'une jam mondiale pour un événement interne dont vous connaissez déjà le problème. Les thèmes secrets conviennent aux événements d'apprentissage, pas à la résolution ciblée de problèmes.
• Répéter les erreurs classiques recensées dans 9 erreurs que les organisateurs de hackathons répètent sans cesse.

Les questions qu'on nous pose

Quelle est la différence entre un hackathon et une jam ? Un hackathon est jugé sur ce qui fonctionne : code, matériel, prototype qui tourne. Une jam est jugée sur un service ou une expérience conçus et testés, et ne demande généralement pas de coder. Les deux durent souvent 48 heures, mais une jam passe bien plus de ce temps avec de vrais usagers.

Quelle est la différence entre un hackathon et un idéathon ? Un idéathon se termine par des concepts et des pitchs ; un hackathon, par quelque chose de construit. Optez pour un idéathon quand le problème est encore flou ou que les participants ne sont pas techniques, et pour un hackathon quand le problème est clair et que vous avez des bâtisseurs.

Un défi d'innovation, est-ce la même chose qu'un hackathon ? Non. Un défi se déroule sur des semaines ou des mois, par étapes, et attire des porteurs de solutions qui ont déjà des capacités, comme des startups et des équipes de recherche. Un hackathon condense tout en quelques jours et la plupart des équipes partent de zéro.

Pour aller plus loin

Commencez par les guides qui structurent le problème avant tout événement : l'arbre à problèmes et les questions « Comment pourrions-nous ». Pour la phase de construction et de test, utilisez le prototype papier et le storyboard, et pour la sélection, un panel de mise à l'épreuve. Tous les guides méthodologiques sont réunis dans l'index des guides.