Pourquoi la plupart des lauréats de hackathon ne voient jamais le jour, et que faire après le hackathon

La plupart des lauréats de hackathon ne voient jamais le jour parce que l'événement a été conçu pour se terminer, pas pour transmettre. La croyance qui le sous-tend : une idée forte, une fois victorieuse en public, trouvera d'elle-même son sponsor, son budget et son équipe. C'est rarement le cas. Ce qui fonctionne, c'est de décider du responsable, du budget et de la date de décision avant l'événement, puis de dérouler délibérément un parcours de 90 jours du prototype au pilote.

La croyance, exposée honnêtement

Elle se résume ainsi : « Nous organisons le hackathon, la meilleure idée gagne, et la direction, qui l'a vue, la soutiendra naturellement. Les bonnes idées se vendent toutes seules. »

Ce n'est pas une croyance absurde. Les hackathons produisent une vraie énergie et quelques concepts solides. Les dirigeants assistent bel et bien aux présentations finales et y disent souvent des choses encourageantes. Et l'on connaît des histoires célèbres de produits nés lors d'événements de ce type. Les organisateurs en déduisent donc raisonnablement que visibilité plus qualité égale adoption.

Pourquoi elle échoue en pratique

Le lundi, le poste de personne n'a changé. L'équipe lauréate retourne à son travail habituel. Ses managers n'ont pas accepté de la libérer. Le prototype reste sur un ordinateur portable. La visibilité a créé de la bienveillance, mais pas de temps, et sans temps rien n'avance.

Des applaudissements ne sont pas un budget. Un dirigeant qui déclare devant une salle « c'est excellent, allons plus loin » accomplit un geste social, pas une décision de financement. Le budget de l'année à venir a été arrêté il y a des mois, et rien n'y porte le nom du lauréat.

Le prototype a été bâti sur du sable. Pour finir en 48 heures, les équipes simulent : données codées en dur, sécurité ignorée, une étape manuelle derrière un écran. C'est la bonne façon de construire un prototype, mais cela signifie que l'écart entre la démo et la production est bien plus grand que ne le croit la salle. Quand l'équipe IT voit le code, la réponse honnête est « il faudrait tout reconstruire », et l'enthousiasme retombe.

Les jurés n'étaient pas les responsables. Beaucoup de jurys sont composés pour leur rang et leur visibilité. Ensuite, ceux qui devraient faire tourner la solution, dont elle touche les systèmes et dont les équipes l'utiliseraient, la découvrent des semaines plus tard, sans y avoir aucun intérêt.

Gagner était la ligne d'arrivée. On a dit aux équipes que l'objectif était de gagner. Une fois la victoire acquise, l'histoire est terminée. Personne ne leur a dit que gagner était le début d'un test.

Aucun de ces échecs ne tient à l'idée. Ce sont des échecs de conception : l'événement a été construit pour produire une cérémonie, et c'est ce qu'il a fait.

Ce qui fonctionne à la place

Avant l'événement : préparer l'atterrissage

Les décisions qui comptent le plus se prennent des semaines avant que quiconque n'écrive une ligne de code.

1. Nommer le responsable et la zone d'atterrissage. Une personne qui reprendra le lauréat, et la ligne budgétaire ou le programme qui l'absorbera. Comment organiser un hackathon qui produit quelque chose de réel appelle cela l'accord d'une page.
2. Convenir à l'avance du temps libéré. Avant l'événement, les managers des participants probables acceptent que les équipes lauréates disposent d'un temps défini, par exemple une journée par semaine pendant six semaines.
3. Faire siéger les responsables dans le jury. Le jury comprend la personne qui fera tourner la solution et celle dont elle touche les systèmes. Utilisez des critères qui récompensent la capacité à être adopté, pas seulement l'ambition ; voir des critères de jury qui désignent le bon lauréat.
4. Faire un premortem. Demandez à l'équipe d'organisation : « Nous sommes dans six mois et rien de ce hackathon n'a vu le jour. Pourquoi ? » Un premortem fait généralement remonter les problèmes d'accès, de budget et de temps libéré pendant qu'il est encore temps de les régler.

Les 90 jours qui suivent

Traitez la période qui suit l'événement comme un projet à part entière.

• Semaines 1 et 2 : le transfert. Le responsable rencontre chaque équipe retenue. Convenez des rôles avec une matrice RACI, confirmez par écrit le temps libéré, et listez ce qui a été simulé dans le prototype.
• Semaines 2 à 4 : nommer les croyances risquées. Utilisez la cartographie des hypothèses pour trier ce que le prototype suppose sur les usagers, les systèmes et les coûts. Retenez les deux plus dangereuses.
• Semaines 4 à 8 : les tester. Formulez chacune sous forme de test d'hypothèse avec un seuil de réussite fixé à l'avance, et menez-le à petite échelle avec de vrais usagers ou de vraies données.
• Semaines 8 à 12 : décider. Passer au pilote avec une check-list de déploiement, adapter et tester à nouveau, ou arrêter. Les trois sont de bonnes issues si elles sont délibérées.

Tout au long, tenez participants et sponsors informés grâce à un plan de communication avec les parties prenantes simple. Le silence après un hackathon est interprété, à juste titre, comme un abandon, et il détermine si les gens s'inscriront la fois suivante.

Rendre l'arrêt respectable

Certains lauréats ne doivent pas voir le jour. Un test en sixième semaine peut montrer que les usagers n'en veulent pas ou que le coût est trop élevé. C'est un bon résultat, obtenu à peu de frais. Dites-le publiquement, reconnaissez à l'équipe ce qu'elle a appris, et consignez-le. Quand l'arrêt est vécu comme un échec, les responsables évitent la décision et les projets végètent à moitié vivants, ce qui est pire que l'une ou l'autre issue. Comment bien arrêter un projet traite ce sujet.

Exemple illustratif

Illustratif. Un groupe hospitalier universitaire aux Pays-Bas a organisé un hackathon interne pour réduire les rendez-vous de consultation manqués. L'équipe lauréate, deux infirmières, une planificatrice et un développeur, a construit un parcours de rappel permettant aux patients de reprogrammer leur rendez-vous en une seule réponse. Le directeur des opérations l'a saluée depuis la scène. Trois mois plus tard, rien ne s'était passé : le développeur était parti sur un autre projet et personne ne portait le système de messagerie patients.

L'année suivante, le groupe a changé la conception, pas l'événement. Le responsable des consultations externes a été désigné avant l'ouverture des inscriptions. Les managers ont accordé aux lauréats une journée par semaine pendant huit semaines. Le gestionnaire du système de messagerie siégeait au jury. Après l'événement, l'équipe lauréate a mené une rétrospective sur le prototype, cartographié ses hypothèses et testé la plus risquée, à savoir si les patients âgés répondraient à un SMS, dans une consultation. Ils ont répondu, pour la plupart. Le pilote a été étendu à trois consultations en douzième semaine.

Les erreurs courantes

• Annoncer un lauréat sans annoncer d'étape suivante. Dites toujours ce qui se passe, et à quelle date.
• Considérer le prix comme la récompense. Pour la plupart des équipes, la vraie récompense est de voir leur travail utilisé. Une dotation sans suite leur dit que leur travail ne comptait pas.
• Laisser le prototype devenir le produit. Reconstruisez proprement une fois le concept validé ; n'étirez pas du code de hackathon jusqu'en production.
• Oublier les équipes qui n'ont pas gagné. Leurs constats contiennent souvent les meilleures preuves de l'événement. Recueillez-les.
• Organiser le hackathon suivant avant que les lauréats du précédent aient obtenu une décision. Cela se remarque. Lisez 9 erreurs que les organisateurs de hackathons répètent sans cesse pour en savoir plus.

Les questions qu'on nous pose

Que doit-il se passer après un hackathon ? Dans les deux semaines, le responsable désigné doit rencontrer les équipes retenues, convenir des rôles et du temps, et lister ce que le prototype a simulé. Il s'agit ensuite de tester les hypothèses les plus risquées pendant les deux mois suivants et de prendre une décision claire : piloter, adapter ou arrêter.

Pourquoi les projets de hackathon échouent-ils après l'événement ? Le plus souvent parce que personne ne les porte, qu'aucun budget n'y est attaché et que l'équipe n'est pas libérée de son travail habituel. L'idée est rarement le problème ; c'est le transfert manquant qui l'est.

Comment entretenir la dynamique après un hackathon ? Fixez la première réunion de suivi avant la fin de l'événement, informez les participants de l'avancement toutes les quelques semaines, et publiez la décision prise pour chaque lauréat, y compris les arrêts. La dynamique naît de décisions visibles, pas de l'enthousiasme.

Pour aller plus loin

Les guides qui portent un prototype au-delà de l'événement sont le premortem, la cartographie des hypothèses, le test d'hypothèse et la check-list de déploiement. Pour la carte complète des formats, voir tous les types de hackathons et de jams expliqués.