Les mentors de hackathon : à quoi ressemble un bon mentorat

Un bon mentor de hackathon aide une équipe à penser plus clairement sa propre idée, par des questions, des retours honnêtes et un coup de main ponctuel pour la débloquer, sans s'approprier l'idée. Un bon mentorat se conçoit : un petit groupe aux rôles clairs, un calendrier de points d'étape calé sur les moments où les équipes coincent, et un court briefing sur ce qu'il faut faire et ne pas faire. Voici comment le mettre en place.

À quoi servent les mentors

Les mentors sont là pour réduire le temps que les équipes passent bloquées. Sur un événement de 36 ou 48 heures, une équipe peut perdre six heures sur une hypothèse erronée, une connexion de données défaillante ou un problème cadré trop largement. Un bon mentor le repère tôt et pose la question qui remet l'équipe en mouvement.

Ce à quoi les mentors ne servent pas : juger, concevoir la solution ou placer leur idée fétiche. Les meilleurs mentors laissent à l'équipe le sentiment que l'idée lui appartient davantage, pas moins. Cela compte pendant l'événement et au-delà : si un pilote suit, l'équipe doit croire en ce qu'elle a construit, et elle ne défendra pas une idée qu'un visiteur senior lui a soufflée.

Il existe quatre rôles de mentor utiles. La plupart des événements ont besoin au minimum des deux premiers :

• Les mentors métier connaissent le problème de l'intérieur : le service, la réglementation, l'historique de ce qui a déjà été tenté.
• Les mentors utilisateurs sont, ou représentent, les personnes concernées. Dans bien des événements, ce sont les personnes les plus précieuses de la salle.
• Les mentors techniques aident sur les données, les outils, l'intégration et ce qui peut réalistement être construit.
• Les mentors méthode et pitch aident les équipes à tester leurs hypothèses, à structurer leur récit et à aller à l'essentiel.

Sept étapes vers un programme de mentorat qui fonctionne

1. Déterminer ce dont les équipes auront besoin, et quand. Parcourez votre agenda et repérez les moments où les équipes peinent habituellement : le cadrage du problème dans les premières heures, le choix d'une idée, le premier test, le mur technique de la nuit, le récit final. Chacun est un moment de mentorat. Choisissez les rôles de mentor en conséquence. Si le défi porte sur un service public, un mentor métier qui connaît les règles vaut plus que deux développeurs supplémentaires. L'énoncé de défi (voir comment rédiger un énoncé de défi que les équipes veulent relever) vous indique quelles connaissances sont rares.

2. Recruter moins de mentors, mais de meilleurs. Un ratio d'environ un mentor pour deux ou trois équipes, par session, suffit généralement si leur temps est planifié. Recrutez pour l'écoute et la patience, pas pour l'ancienneté. Un dirigeant peut faire un bon mentor, mais seulement s'il sait rester vingt minutes avec une équipe et poser plus de questions qu'il ne donne de réponses. Demandez à chaque candidat un engagement de temps précis, au moins deux créneaux, avant de l'accepter. Un nom sur le site web qui apparaît dix minutes fait partie des 9 erreurs de hackathon que les organisateurs répètent.

3. Briefer les mentors avant l'événement. Trente à soixante minutes, idéalement la veille. Couvrez le défi et ses contraintes, les critères d'évaluation (pour que les mentors orientent vers ce qui compte, voir les critères d'évaluation qui désignent le bon lauréat), le planning et les règles de la maison. La règle la plus importante est simple : questionner, pas prescrire. Donnez-leur une courte liste de questions à utiliser, par exemple :

• Pour qui exactement est-ce, et quel moment de leur journée améliorez-vous ?
• Quelle est l'hypothèse la plus risquée que vous faites ? Comment pourriez-vous la vérifier aujourd'hui ?
• Que supprimeriez-vous si vous n'aviez que la moitié du temps ?
• Qu'avez-vous appris ces trois dernières heures qui vous a fait changer d'avis ?

Ces questions mènent tout droit à la cartographie des hypothèses et à un rapide test d'hypothèse ; les mentors doivent connaître les deux suffisamment pour les suggérer.

4. Planifier le temps ; ne pas le laisser au hasard. La formule non structurée « les mentors sont là, il suffit de demander » échoue de deux façons : les équipes sûres d'elles accaparent les mentors et les équipes discrètes ne demandent jamais. Organisez plutôt des tours fixes : par exemple, un point de 15 minutes avec chaque équipe après le bloc de cadrage du problème, un deuxième après le premier test, et un troisième avant le pitch. Entre les tours, les mentors peuvent être sollicités à la demande via une simple file d'attente. Faites tourner les mentors pour que chaque équipe entende plusieurs points de vue, mais gardez un mentor référent nommé comme contact principal de l'équipe, pour que les conseils ne tirent pas dans cinq directions.

5. Donner aux mentors un moyen de partager ce qu'ils observent. Après chaque tour, réunissez les mentors dix minutes. Quelles équipes sont bloquées ? Lesquelles s'apprêtent à construire quelque chose qui enfreint une contrainte ? Lesquelles n'ont parlé à aucun utilisateur ? Cela permet aux organisateurs d'agir tôt, en envoyant par exemple un mentor utilisateur à l'équipe qui en a besoin. Cela évite aussi que les mentors répètent les conseils des autres. Les notes des mentors ne doivent jamais être transmises au jury sous forme de notes ; mentorat et évaluation doivent rester séparés, sinon les équipes cesseront d'être honnêtes avec les mentors.

6. Préserver l'appropriation par l'équipe. Surveillez les dérives classiques : le mentor qui redessine l'idée, celui qui impose sa technologie, celui dont l'ancienneté pousse l'équipe à abandonner une bonne piste pour lui plaire. Dites aux mentors, lors du briefing, que c'est l'équipe qui décide. Dites-le aussi aux équipes : « Les mentors conseillent. Vous décidez de ce que vous retenez. » Si un mentor continue de passer outre, réaffectez-le discrètement à un autre rôle.

7. Boucler la boucle après l'événement. Demandez aux équipes quel mentorat les a aidées et lequel non, à l'aide d'une grille de recueil des retours. Remerciez les mentors avec quelque chose de précis : l'équipe qu'ils ont aidée, ce qui a changé grâce à eux. Si une idée gagnante passe en pilote, le mentor qui connaît le métier est souvent le mieux placé pour rester impliqué les premières semaines. Cette continuité fait partie de ce qui se passe après le hackathon.

À faire et à éviter pour les mentors

À faire

• Commencer chaque échange en demandant ce que l'équipe cherche à faire et où elle bloque.
• Pousser tôt au contact avec de vrais utilisateurs et de vraies données, dès le premier jour si possible.
• Proposer un test rapide (un prototype papier, une conversation de cinq minutes) plutôt qu'un long débat.
• Dire franchement quand quelque chose enfreint une contrainte, et expliquer pourquoi.
• Laisser chaque équipe avec une prochaine étape claire.

À éviter

• Prendre le stylo. Si vous dessinez la solution, c'est vous qui la concevez.
• Arriver avec sa propre idée et chercher une équipe pour la construire.
• Donner des conseils sur tout ; choisissez la seule chose qui compte le plus maintenant.
• Contredire un autre mentor devant l'équipe ; soulevez-le lors du point entre mentors.
• Mentorer une équipe que vous allez aussi évaluer.

Exemple illustratif

Illustratif. Un établissement du service national de santé au Royaume-Uni a organisé un hackathon de deux jours pour réduire les rendez-vous de consultation manqués. Lors de sa première édition, douze cliniciens et managers seniors figuraient comme mentors. La plupart sont passés une fois, brièvement. Trois équipes ont changé de cap après qu'un médecin consultant a suggéré une application de rappel ; au moment du pitch, quatre équipes avaient construit des applications de rappel quasi identiques.

L'édition suivante a été repensée autour des moments où les équipes peinent. Les organisateurs ont recruté sept mentors : deux agents d'accueil des consultations qui géraient les reports au quotidien, deux patients du panel de patients de l'établissement, un analyste de données, un clinicien et un facilitateur pour les tests et le pitch. Tous les sept ont été briefés la veille au soir avec une page de questions et une règle : questionner, pas prescrire. Chaque équipe avait trois points d'étape planifiés et un mentor référent. Au premier point entre mentors, ceux-ci ont signalé que cinq équipes partaient du principe que les patients oubliaient leurs rendez-vous ; les agents d'accueil savaient que beaucoup ne pouvaient tout simplement pas se libérer du travail aux horaires proposés. Les mentors patients l'ont confirmé. Les équipes qui ont testé ce point avec eux se sont orientées vers un échange de créneaux flexible plutôt que vers des rappels. L'idée gagnante est entrée dans un petit pilote porté par la responsable des consultations, et l'un des agents d'accueil est resté en tant que conseiller.

Questions fréquentes

Que fait un mentor de hackathon ? Un mentor aide les équipes à progresser en posant des questions, en donnant des retours honnêtes, en partageant des connaissances métier ou techniques et en levant des blocages. Il ne juge pas et ne conçoit pas la solution à la place de l'équipe.

De combien de mentors un hackathon a-t-il besoin ? Cela dépend du nombre d'équipes et de la durée de l'événement, mais environ un mentor pour deux ou trois équipes par session fonctionne lorsque leur temps est planifié. La diversité des rôles compte davantage que le nombre total.

Un mentor peut-il aussi être juré ? Mieux vaut éviter. Les équipes doivent pouvoir confier leurs doutes aux mentors sans craindre que cela leur coûte des points. Si un cumul est inévitable, veillez à ce que personne n'évalue une équipe qu'il a mentorée.

Pour aller plus loin

Pour la conception complète de l'événement, voir comment organiser un hackathon qui produit quelque chose de concret et la cartographie des formats dans hackathons, jams et challenges : tous les types expliqués. Les guides cartographie des hypothèses, test d'hypothèse et prototype papier sont les trois que tout mentor devrait connaître.