9 erreurs de hackathon que les organisateurs répètent

La plupart des hackathons décevants échouent pour la même poignée de raisons, et presque aucune ne se joue pendant l'événement. Tout se décide des semaines plus tôt : au moment où l'on rédige le défi, où l'on choisit le jury et où personne n'est désigné pour porter ce qui en sortira. Voici les neuf erreurs qui reviennent sans cesse, et ce qu'il faut faire à la place.

Les neuf erreurs

1. Organiser un hackathon parce que quelqu'un veut un hackathon. L'événement est réservé avant que quiconque ait demandé à quoi il sert. Une date, une salle et un hashtag arrivent ; un objectif, non. Sans objectif, impossible de rédiger un défi, de choisir un jury ou de définir ce qu'est un bon résultat : chaque décision suivante devient un pari. À la place : écrivez une phrase avant toute chose : « À l'issue de cet événement, nous voulons disposer de ___, et ___ s'en saisira. » Si vous ne pouvez pas remplir les deux blancs, il vous faut peut-être un tout autre format. La comparaison hackathon, design jam ou challenge d'innovation vous aide à vérifier.

2. Un thème au lieu d'un défi. « Villes intelligentes », « l'avenir de la banque », « durabilité ». Les thèmes paraissent généreux parce qu'ils laissent de la marge, mais les équipes passent les six premières heures à débattre du sujet, puis construisent ce qu'elles savent déjà construire. À la place : confiez aux équipes un vrai problème, porté par une vraie personne, avec une vraie contrainte. Un bon défi dit qui est concerné, ce qui ne fonctionne pas et ce qui est hors limites. Nous détaillons le savoir-faire dans comment rédiger un énoncé de défi qui donne envie. Un arbre à problèmes construit en amont avec le porteur du défi est le moyen le plus rapide de trouver le bon niveau.

3. Personne pour porter ce qui en sort. C'est l'erreur qui explique pourquoi tant de lauréats ne voient jamais le jour. Une équipe gagne, reçoit un trophée, serre des mains, et le dimanche matin il n'y a ni ligne budgétaire, ni sponsor, ni prochaine réunion. À la place : avant l'événement, désignez la personne qui recevra le travail gagnant et convenez de ce qu'elle est prête à en faire : un pilote, un développement sur 90 jours, un test financé. Inscrivez cet engagement dans le brief pour que les équipes sachent ce qu'elles visent. La suite complète figure dans que faire après le hackathon.

4. Des critères d'évaluation annoncés au moment du pitch. Quand les équipes ne découvrent les critères qu'à la présentation finale, elles optimisent pour ce qu'elles imaginent plaire au jury, en général les slides et la finition. Les jurés divergent ensuite, chacun appliquant discrètement ses propres critères. À la place : publiez les critères avec le défi, expliquez chacun en termes simples et briefez le jury la veille. Pondérez-les selon l'objectif rédigé à l'erreur 1. Notre article sur les critères d'évaluation qui désignent le bon lauréat aborde grilles de notation et calibrage ; une matrice de décision pondérée est la structure la plus simple pour démarrer.

5. Des mentors qui ne viennent que pour la photo. Une liste de noms prestigieux ne fait pas un programme de mentorat. Des seniors qui passent vingt minutes, donnent trois avis contradictoires et repartent font plus de mal que de bien, car les équipes changent de cap pour leur plaire. À la place : recrutez moins de mentors, donnez à chacun un rôle clair (métier, technique, utilisateur, pitch), planifiez leur présence par créneaux et dites-leur que leur rôle est de poser des questions, pas de redessiner l'idée. Plus de détails dans les mentors de hackathon : à quoi ressemble un bon mentorat.

6. Aucun accès aux personnes ou aux données concernées par le défi. On demande aux équipes d'améliorer un service pour des patients, des citoyens ou des clients absents du bâtiment, avec des données d'exemple sans rapport avec la réalité. Elles finissent par résoudre un problème imaginaire. À la place : prévoyez de vrais utilisateurs joignables pendant la première journée, trois ou quatre suffisent, et préparez bien à l'avance un jeu de données réaliste et nettoyé. Si des validations juridiques ou de confidentialité sont nécessaires, lancez-les la semaine où vous fixez la date, pas la semaine de l'événement.

7. Récompenser le meilleur pitch plutôt que le meilleur travail. La dernière heure tient du théâtre. Les équipes dotées d'un orateur assuré et d'un beau deck gagnent, tandis qu'une équipe qui a testé son idée auprès de cinq utilisateurs et changé deux fois de cap perd parce que ses slides étaient sobres. À la place : demandez à chaque équipe des preuves : ce qu'elle a testé, avec qui, ce qui a changé. Donnez au jury du temps avec le prototype de chaque équipe avant les pitchs. Limitez les slides. Vous cherchez l'idée qui mérite le plus d'être poursuivie, pas le meilleur orateur.

8. Trop court pour construire, trop long pour rester vif. Certains organisateurs compressent un hackathon en un après-midi ; d'autres l'étirent sur trois jours épuisants sans structure. Le premier produit des croquis ; le second, des participants fatigués qui ne pensent plus clairement dès la deuxième nuit. À la place : adaptez la durée à ce que vous attendez à la fin. Un concept testé demande environ une journée et demie de travail effectif. Un prototype fonctionnel avec des données réelles demande davantage, et des points d'étape pour que les équipes ne dérivent pas. Construisez l'agenda à rebours depuis la démo finale.

9. Aucune trace de qui a fait quoi. À la fin de l'événement, la seule trace est une photo des gagnants. Les participants qui ont fourni un vrai travail, y compris dans les équipes non primées, repartent sans rien à montrer, et l'organisation ne sait plus qui réinviter ou associer au pilote. À la place : consignez pour chaque équipe le cadrage du problème, ce qu'elle a testé, ce qu'elle a construit et la contribution de chacun. Envoyez-le aux participants et à leurs managers. C'est le moyen le moins coûteux de donner envie de revenir.

À faire et à éviter

À faire

• Rédiger l'objectif et l'engagement post-événement avant de réserver quoi que ce soit.
• Mener un premortem avec l'équipe d'organisation : « Nous sommes trois mois plus tard et le hackathon n'a rien produit. Pourquoi ? »
• Publier ensemble le défi, les critères et les prix.
• Bloquer l'agenda du porteur destinataire pour la semaine qui suit l'événement.
• Utiliser une check-list de déploiement pour la logistique, afin que l'énergie de l'équipe d'organisation aille au défi et non au traiteur.

À éviter

• Laisser le sponsor rédiger seul le défi ; la personne qui vit le problème doit le façonner.
• Inviter des jurés qui n'ont pas lu le défi.
• Promettre une mise en œuvre que vous ne pouvez pas financer.
• Considérer le nombre de participants comme la mesure du succès.

Exemple illustratif

Illustratif. Une autorité régionale de transports publics, dans une ville européenne de taille moyenne, a organisé son premier hackathon sur le thème « une meilleure mobilité ». Quatre-vingts personnes sont venues, douze équipes ont pitché, et l'équipe gagnante a conçu une application de calcul d'itinéraire très proche de trois autres déjà sur le marché. Personne n'a été chargé de la faire avancer.

Pour la deuxième édition, les organisateurs s'y sont pris autrement. Ils ont d'abord écrit l'objectif : trouver un moyen de réduire le nombre de voyageurs bloqués la nuit après avoir manqué la dernière correspondance, ce que le directeur des opérations s'est engagé à piloter sur deux lignes. Ils ont animé une séance d'arbre à problèmes avec des conducteurs et le personnel du poste de commande, puis ont formulé le défi sous forme de question « Comment pourrions-nous » en explicitant les contraintes : pas de nouveaux véhicules, pas de nouvelle application. Les critères ont été publiés avec le brief. Trois conducteurs de nuit étaient joignables pendant la première journée. Le concept gagnant, une règle simple de maintien et d'alerte entre conducteurs et poste de commande, est passé en pilote le mois suivant, avec le directeur des opérations pour porteur.

La deuxième édition était plus petite. C'était aussi la première à avoir changé quelque chose.

Questions fréquentes

Quelle est la cause d'échec la plus fréquente d'un hackathon ? L'absence de porteur pour le résultat. Une idée sans personne prête à la financer ou à la piloter s'arrête dès la fin de l'événement, aussi bonne soit-elle. Réglez ce point avant tout le reste.

De combien de jurés un hackathon a-t-il besoin ? Trois à cinq suffisent en général. Au-delà, la délibération ralentit et la responsabilité se dilue. Le plus important est qu'au moins un juré soit la personne qui portera ensuite l'idée gagnante.

Un hackathon doit-il avoir un seul défi ou plusieurs ? Pour un événement interne, un ou deux défis bien rédigés valent généralement mieux que cinq défis flous. Plusieurs défis ont du sens quand chacun a son propre porteur et ses propres moyens prêts à agir ensuite.

Pour aller plus loin

Commencez par la cartographie complète des formats dans hackathons, jams et challenges : tous les types expliqués, puis la méthode pas à pas dans comment organiser un hackathon qui produit quelque chose de concret. Pour la préparation, les guides arbre à problèmes, questions « Comment pourrions-nous » et premortem couvrent l'essentiel de ce qui dérape, et la matrice de décision pondérée donne à votre jury une structure équitable.