Comment organiser un hackathon qui produit quelque chose de réel

Pour organiser un hackathon qui produit quelque chose de réel, décidez du sort des lauréats avant tout le reste : qui les porte, sur quel budget ils s'appuient et quand la décision est prise. Préparez ensuite le problème, les données et les personnes, pour que les équipes passent l'événement à construire et non à attendre. L'événement lui-même est la partie facile ; l'essentiel du travail se situe dans les six semaines qui précèdent et les douze semaines qui suivent.

Les étapes ci-dessous supposent un hackathon interne ou d'écosystème d'un à trois jours. Si vous hésitez encore entre plusieurs formats, commencez par tous les types de hackathons et de jams expliqués.

Avant de commencer : l'accord d'une page

Rédigez une seule page et faites-la valider par le sponsor de haut niveau. Elle tient en cinq lignes :

• Le problème, en une phrase, et pourquoi il compte maintenant.
• Le responsable qui reprendra le prototype lauréat, nommément.
• La zone d'atterrissage : la ligne budgétaire, l'équipe ou le programme qui absorbera le lauréat.
• La date de décision : quand, après l'événement, le responsable dira « on y va », « on adapte » ou « on arrête ».
• Ce que « réel » veut dire : un pilote avec 50 utilisateurs, un test d'intégration, une demande d'achat. Soyez précis.

Si vous ne pouvez pas remplir cette page, vous n'êtes pas prêt à organiser un hackathon. Vous êtes peut-être prêt pour un idéathon ou une phase d'exploration.

Pas à pas

1. Cadrer le problème six semaines avant

Interrogez celles et ceux qui vivent avec le problème : équipes de terrain, clients, propriétaires des systèmes. Cinq à huit entretiens avec les parties prenantes suffisent pour éviter de briefer le mauvais problème. Posez les causes et les effets avec un arbre à problèmes, puis rédigez deux à quatre questions « Comment pourrions-nous » qui serviront de parcours de défi. Chaque parcours doit être assez étroit pour qu'une équipe de cinq construise quelque chose de significatif en 48 heures, et assez large pour que deux équipes ne construisent pas la même chose. La rédaction du brief elle-même est traitée dans comment rédiger un énoncé de défi que les gens ont envie de résoudre.

2. Débloquer les accès quatre semaines avant

C'est là que la plupart des hackathons d'entreprise échouent sans bruit. Les équipes arrivent et découvrent qu'elles ne peuvent pas atteindre l'API, que les données ne sont pas autorisées ou que le bac à sable n'existe pas. Quatre semaines avant, listez tout ce qu'une équipe devra toucher, et obtenez l'accord écrit de la DSI, du délégué à la protection des données et de la sécurité. Préparez un bac à sable avec des données de test réalistes. Si les données réelles ne peuvent pas sortir de leur système, créez un jeu synthétique de même structure.

3. Recruter pour des équipes mixtes

Ouvrez les inscriptions trois à quatre semaines avant, et demandez aux gens leur compétence, pas leur fonction. Une bonne équipe de quatre à six personnes compte au moins un bâtisseur, une personne qui connaît le métier et une personne qui ira parler aux usagers. Laissez la possibilité de s'inscrire seul et d'être affecté à une équipe. Évitez que des services entiers s'inscrivent comme une seule équipe : vous perdriez le décloisonnement qui justifie l'événement.

4. Briefer le jury et les mentors deux semaines avant

Le jury doit inclure le responsable désigné dans votre accord d'une page, quelqu'un qui tient le budget et quelqu'un qui représente l'usager. Convenez des critères avec eux avant l'événement et publiez-les auprès des participants. Une grille raisonnable : la solidité des preuves que le problème est réel, l'adéquation avec la zone d'atterrissage, la faisabilité dans les systèmes existants et la qualité du prototype. Pondérez-les dans une matrice de décision pondérée. Plus de détails dans des critères de jury qui désignent le bon lauréat.

Les mentors ne sont pas des jurés. Donnez à chaque mentor un parcours, un calendrier de points d'étape et une consigne : poser des questions, débloquer les accès, ne pas prendre la main. Voir les mentors d'un hackathon.

5. Structurer l'événement autour de trois points d'étape

Un déroulé de 48 heures qui fonctionne :

• Ouverture (deux premières heures). Le sponsor présente en personne le problème et la zone d'atterrissage. Ce sont ensuite les responsables du problème, et non les organisateurs, qui répondent aux questions. Les équipes se forment et choisissent un parcours.
• Premier point d'étape (vers la sixième heure). Chaque équipe énonce son usager, son hypothèse et ce qu'elle va construire. Poussez les équipes à lister leurs croyances les plus risquées avec la cartographie des hypothèses. Supprimez tôt les doublons.
• Deuxième point d'étape (vers la 24e heure). Chaque équipe montre quelque chose qui fonctionne, même sans fioritures, et rend compte d'un test avec un vrai usager ou un vrai système. Un prototype papier compte pour les interfaces pas encore construites.
• Troisième point d'étape (dernière matinée). Gel des fonctionnalités. Le reste du temps sert à tester, corriger et préparer une courte démonstration.

Limitez les présentations à cinq minutes plus les questions, et exigez une démonstration en direct. Des slides sur ce que ferait le produit ne sont pas un prototype.

6. Juger sur l'adoption, pas sur les applaudissements

Organisez le jury comme un panel de mise à l'épreuve : chaque juré note seul, selon les critères publiés, avant toute discussion, puis le panel compare les notes et ne débat que des écarts. Annoncez non seulement le lauréat, mais aussi l'étape suivante : « Le responsable rencontrera cette équipe mardi pour préparer un pilote de quatre semaines. » Si vous annoncez un prix sans étape suivante, chacun comprendra exactement ce qu'était l'événement.

7. Transférer sous dix jours ouvrés

Dans les dix jours ouvrés qui suivent l'événement, le responsable rencontre chaque équipe retenue, convient de qui fait quoi à l'aide d'une matrice RACI, et réserve par écrit, avec leurs managers, le temps dont l'équipe a besoin. Menez les premières étapes du pilote en suivant une check-list de déploiement. À la date de décision, le responsable dit « on y va », « on adapte » ou « on arrête », et le dit publiquement. Pourquoi la plupart des lauréats de hackathon ne voient jamais le jour approfondit cette phase.

Exemple illustratif

Illustratif. Un assureur régional d'Europe du Sud voulait réduire le délai entre la déclaration d'un petit sinistre automobile et le versement de l'indemnisation. Son responsable de l'innovation a d'abord rédigé l'accord d'une page : la directrice des sinistres portait le résultat, le programme digital sinistres l'absorberait, et une décision serait prise six semaines après l'événement.

Quatre semaines avant, la DSI a construit un bac à sable avec des dossiers de sinistres anonymisés et une copie du service de dépôt de documents. Les équipes de cinq mêlaient gestionnaires de sinistres, développeurs et un conseiller du centre d'appels. Au deuxième point d'étape, une équipe avait découvert, en appelant trois assurés ayant récemment déclaré un sinistre, que le retard ne venait pas de l'expertise, mais des clients qui envoyaient les mauvaises photos. Elle a construit un parcours photo guidé et l'a testé avec des conseillers du centre d'appels jouant les clients. Elle a gagné sur les preuves et l'adéquation, pas sur la finition. La directrice des sinistres a rencontré l'équipe le mardi suivant, et un pilote de quatre semaines a été mené dans une agence.

À faire, à éviter

À faire

• Faire signer l'accord d'une page avant d'annoncer la date.
• Faire briefer les équipes par le responsable du problème, pas par l'organisateur.
• Publier les critères du jury dès l'inscription.
• Bien nourrir les participants et les laisser dormir. Une équipe qui a dormi construit mieux le deuxième jour.
• Consigner ce que chaque équipe a appris, y compris celles qui n'ont pas gagné ; leurs constats évitent souvent au lauréat de répéter des erreurs.

À éviter

• Commencer par le lieu, l'identité visuelle ou le prix.
• Laisser les équipes découvrir le matin même qu'elles n'ont pas accès aux systèmes.
• Accepter un jeu de slides à la place d'une démonstration.
• Choisir des jurés qui ne reverront jamais le projet.
• Fêter le succès le vendredi et se taire le dimanche. 9 erreurs que les organisateurs de hackathons répètent sans cesse liste les autres.

Les questions qu'on nous pose

Combien de temps doit durer un hackathon d'entreprise ? Deux jours est le minimum pratique pour obtenir quelque chose qui fonctionne ; 24 heures ne conviennent qu'à des problèmes très étroits. Au-delà de trois jours, vous menez un sprint, ce qui est très bien, mais planifiez-le comme tel.

Combien de personnes faut-il pour organiser un hackathon ? Pour 50 à 80 participants, prévoyez un organisateur principal, un référent technique pour les accès et les environnements, un mentor par parcours, un jury de trois à cinq personnes et quelqu'un dédié à la logistique. Le référent technique est le rôle qui manque le plus souvent.

Les participants à un hackathon doivent-ils être rémunérés ou dégagés de leur temps de travail ? Les hackathons internes doivent se tenir sur le temps de travail ou être compensés, et les managers doivent donner leur accord à l'avance. Si les gens doivent sacrifier un week-end sans contrepartie, vous n'entendrez que ceux qui le peuvent, et vous les perdrez au stade du pilote.

Pour aller plus loin

Les guides qui font l'essentiel du travail ici sont l'arbre à problèmes, la cartographie des hypothèses, la matrice de décision pondérée et la check-list de déploiement. Chacun se mène en moins d'une heure avec une équipe.