Hackathon OpenData 76, les coulisses du jury

[ Articles -> HackHours -> Hackathon OpenData 76 : retour d'expérience d'un juré ]

Le week-end dernier (les 11 et 12 avril 2014) se déroulait le 3ème hackathon Normand à l'Hôtel du Département de la Seine-Maritime, organisé conjointement par l'association HackHours et le Conseil Général. Un événement très médiatisé, pour lequel le département a mobilisé de grands moyens et n'a pas lésiné sur les détails.

Logo OpenData 76

Qu'est-ce qu'un hackathon ?

Un hackathon, c'est une sorte de concours de développement informatique intensif (24h non-stop), au cours duquel les équipes d'informaticiens et d'infographistes (4 personnes en général) sont invitées, sur la base d'un thème spécifique (dans ce cas ci, l'Open Data), à imaginer, concevoir, développer et présenter un prototype fonctionnel d'application informatique (mais aussi parfois d'objet électronique physique).

Ce que c'est que d'être membre du jury

J'avais déjà eu l'occasion de faire partie d'une équipe sur ce type d'événement, mais cette fois-ci mon statut était tout autre puisque j'avais l'honneur d'être l'un des 5 membres du jury (Gaël Musquet, Marc-Aurèle Carucci, Vincent Lalire, Baptiste Dumouchel et moi-même), dont la lourde tâche consistait à retenir 3 excellents projets parmi les 25 présentés lors de la phase finale. Un tel choix est d'autant plus délicat et lourd de conséquences sur un événement de cette ampleur, quand on considère les différents prix en jeu (MacBook Air, iPad...) et l'impact médiatique du hackathon.

Logo HackHours

Je ne me voyais pas juger les projets sur la seule base d'une présentation de 5 mn en fin de session, et c'est pourquoi, comme certains de mes homologues, j'ai fait le choix d'être présent pendant le hackathon afin de rencontrer les équipes, les conseiller, observer leurs méthodes de conception, de développement et d'organisation ainsi que leur état d'esprit.

Je me suis donc appliqué à passer entre les tables pour rencontrer les développeurs, designers et chefs de projets et pour discuter avec eux. On distingue assez vite les équipes organisées des développeurs du dimanche, les idées innovantes et originales des projets avec un air de déjà vu, mais à cette étape, toutes les équipes ont encore leurs chances, et d'ailleurs aucun des jurés n'avait de vainqueur en tête avant la délibération. Ce qui est certain, c'est que tous sont motivés pour s'amuser et tenter de remporter la victoire.

De ces observations, bon nombre d'éléments ont également attiré mon attention :

Savoir survivre aux imprévus : un art difficile

Au cours de ce troisième Hackhours, malgré le cadre idyllique de l'événement, les équipes ont été confrontées à pas mal d'imprévus qui sont la hantise des informaticiens : les coupures d'accès Internet et d'électricité. Malgré tout le dispositif mis en place pour l'occasion, ce genre de chose peut toujours arriver, et il est intéressant de savoir pourquoi :

Coupure Internet

Concernant les coupures et ralentissements du réseau et de la connexion Internet, je dois, en tant qu'architecte réseaux, m'avouer stupéfait face à l'incompétence de l'opérateur chargé de la mission (j'ai passé plusieurs heures à tenter d'aider les techniciens, mais l'architecture a été très mal pensée) et par l'acceptation naïve d'un tel contrat pour la somme astronomique et indécente de 25000€ ! Notez bien que, pour pas un centime, le réseau Wi-Fi déjà en place du Conseil Général fonctionnait bien mieux ! La prochaine fois, il serait plus judicieux de faire confiance à un petit opérateur local (associatif ?), habitué à ce genre d'événement et de trafic, et capable de gérer un tel réseau (je prêche pour ma paroisse, et j'assume !).

Cependant, ces imprévus sont intéressants et ont du bon, car ils permettent de distinguer clairement les équipes organisées, qui savent garder leur sang froid et développer hors-ligne (serveurs locaux, copies, connaissance approfondie des langages permettant de moins dépendre des documentations en ligne...) des équipes totalement perdues. Finalement, c'est un nouveau challenge qui s'installe, et un stress supplémentaire.

La phase de présentation des projets, et la délibération tant redoutée du jury

Après 24h de développement, les équipes sont fatiguées, et moi aussi. Mais j'ai fait le plein d'idées intéressantes, et il est désormais temps de passer aux présentations des projets, et de délibérer sur les 3 équipes gagnantes avec le reste du jury. Et c'est ainsi que les présentations commencent et s'enchaînent pendant près de 2h30, sous l'œil attentif des jurés qui prennent des notes, évaluent les projets selon plusieurs critères et redoutent de devoir faire un choix.

Puis vient l'heure de la délibération. À l'écart de la foule dans une salle de réunion, 20 minutes de discussions commencent. Les notes prises au cours des présentations sont d'une grande utilité, et les bons projets se distinguent déjà clairement aux yeux des jurés. On élimine d'office les projets portés par des équipes n'ayant pas respecté les règles (thème non respecté, projet commencé avant le début du hackathon, aide d'un développeur extérieur...), puis on discute de la première place, puis de la deuxième et de la troisième, en argumentant sur la base des critères importants sur un hackathon. Chaque membre du jury ayant sa spécialité (technique, économie, communication), les choix se veulent nécessairement multicritères, et riches de sens.

Si la décision est unanime et presque immédiate sur la première place, le consensus prend plus de temps à naître pour les places suivantes. Un quatrième projet, ne pouvant être classé en raison du non respect d'un des critères, est nommé coup de cœur du jury.

Et c'est ainsi que cette année, nos gagnants sont :

Hackhours 2014 : Les vainqueurs - CheckTaRoute

Les critères d'évaluation et les bonnes pratiques pour gagner un hackathon

Beaucoup d'équipes imaginent que seul un projet très complet, implémentant tout un tas de fonctionnalités et développé proprement (en utilisant tel ou tel framework super à la mode) a de sérieuses chances de gagner. Il n'en est rien. Il faut absolument garder à l'esprit que lors d'un hackathon, on développe un prototype, avec tout ce que ça implique.

Voici donc, à mes yeux, les caractéristiques essentielles d'un bon projet de hackathon :

En clair, il faut avoir une bonne idée, savoir gérer son temps, et se dépasser pour être plus qu'un développeur. Pour ceux que ça intéresse, je vous invite à consulter l'article de mon collègue Antoine Augusti.

En résumé

Les hackathons, c'est bien ! Quoi qu'il arrive, tout le monde s'amuse bien, l'ambiance est excellente, et ce genre d'événement est aussi une superbe opportunité pour rencontrer tout un tas de personnes intéressantes (des développeurs, mais aussi des infographistes, des businessmans, des chefs d'entreprises, des hommes et femmes politiques, des étudiants...).

Je ne peux que recommander ces week-end de folie, et vous conseiller d'y venir, car vous avez tout à y gagner !

Quelques liens :


comments powered by Disqus