Hackathon AI Labs - mode d'emploi pour survivre jusqu'au bout des 50h

Introduction

Dans notre article précédent, nous avons présenté l’idée avec laquelle Quantmetry s’est présenté au Hackathon AI Labs : un projet de reconnaissance d’oeuvres d’art en temps réel et de recommandations personnalisée. Nous avons également expliqué comment nous avons enrichi notre équipe en convaincant d’autres participants de rejoindre notre projet. Dans cette deuxième partie de la série, plus de détails sur les 50h de feu du Hackathon, et quelques suggestions pour tenir jusqu’au bout dans un cadre d’enthousiasme bien sûr, mais aussi de fatigue et de possibles tensions …

Lancer le hackhathon

1. Faire connaissance

Nous voilà donc huit réunis dans une war-room, notre espace de vie pour les 48 prochaines heures. Comme toute expérience en commun il est important de faire connaissance au plus tôt avec ses compagnons d’aventure pour comprendre au mieux, pour chacun :

• Ses objectifs personnels (sans censure) par exemple: “vivre une expérience humaine” ; “gagner le hackathon” ; “monter en compétence technologique / méthodologique” ; “vivre la gloire et devenir célèbre” ..

• Son profil, ou comment il se sentirait à l’aise dans l’équipe

L’idée est d’éviter impérativement tout risque de frustration et de quiproquo, les heures sont comptées, le stress va monter, il n’est pas rare qu’une équipe explose en plein vol pour de “simples” problèmes de communications.

Réserver ainsi la première soirée pour “juste” faire connaissance avec les membres de l’équipes n’est pas un luxe et pour ça il faut parfois parler pour parler… Une des techniques simple et efficace proposée par l’équipe encadrante du Hackathon était la suivante : chacun au moment de se décrire doit entre autre expliquer quel animal il aimerait être et pourquoi. On a ainsi eu dans l’équipe : 1 bonobo, 1 girafe, 1 cheval, 1 vache et 4 chats… pourquoi pas…

2. Fédérer autour d’une vision commune

S’il ne fallait retenir qu’une seule leçon de ce hackathon, ce serait celle-là : Il faut impérativement prendre le temps de :

– Définir clairement et précisément les objectifs : quelles sont les features de l’application ? Les user-stories ? …

– Fédérer autour de ces objectifs et prendre le temps de vérifier que l’ensemble de l’équipe a bien compris et partage cette vision commune.

Cela est moins anodin qu’il n’y paraît. Après avoir fait connaissance, notre première session de travail a été de formaliser les objectifs de l’application afin de les décliner en features, pour organiser la répartition des tâches au cours du week-end. Nous pensions que ce travail serait une formalité, car chacun de nous pensait avoir une idée très claire de l’application, et que cette idée était partagée par tout le monde…

Que nenni ! En cherchant à formaliser les objectifs, nous nous sommes rendus compte que chacun avait des idées assez différentes sur les objectifs de l’application (l’utilisateur doit-il pouvoir noter les tableaux qu’il voit ? si oui comment ? sur quelle base doit être construit le moteur de recommandation ? …). En réalité, chacun s’était fait son application rêvée dans sa tête…

Cela nous a finalement pris beaucoup plus de temps et d’énergie que prévu, mais nous avons réussi (à force de discussion et de compromis), à faire émerger une vision précise et clarifiée de l’application cible, et surtout, partagée par tous. Le temps consacré à cette première étape n’a en aucun cas été perdu, car il nous a permis d’être beaucoup plus efficaces sur les phases de développement qui ont suivi !

3. Organiser l’équipe

Une des clés du succès réside également dans une organisation efficace et un partage intelligent des tâches. Chacun doit savoir précisément ce qu’il a à faire. L’ensemble des features doivent être développées, et il faut s’assurer qu’aucun travail n’est fait en double : le hackathon ne dure que deux jours. Impossible de ne pas être optimaux sur la gestion des ressources.

Une organisation efficace, surtout si l’équipe est de taille relativement importante (ce qui était notre cas puisque nous étions huit), est de bien séparer le travail en chantiers distincts. Par chance, notre équipe était composée de profils très complémentaires :

– Des développeurs plutôt back-end

– Des développeurs plutôt front-end

– Des profils business developers / UX

Notre équipe s’est donc constituée de manière homogène autour de ces trois pôles. Il a été clairement défini ce qui était attendu de chacun de ces pôles, par exemple :

– Les UX ont expliqué au pôle front-end ce qui était attendu visuellement pour l’application

– Les développeurs front-end ont détaillé quelles données ils attendaient que le back-end fournisse et sous quel format.

Cela a permis à chacun de ces chantiers de s’organiser de son côté et d’avancer de manière beaucoup plus agile et efficace.

4. Coder, designer, tester, coder

Les objectifs sont clairement établis. Les tâches à réaliser clairement identifiées. Les équipes formées. “Y’a plus qu’à”, comme on dit ! Des dizaines d’heures et quelques milliers de lignes de code en perspective.

Ici pas de secret : il faut faire chauffer ses neurones, prendre une bonne dose de caféine et mettre le pied à l’étrier.

Pas de secret, mais quelques petits conseils qui permettent d’avancer efficacement :

● Prenez le temps de bien organiser votre environnement de travail :

   ○ Repository Git avec les bons droits d’accès pour tout le monde ;

   ○ Architecture de code propre et partagée par l’ensemble de l’équipe (idéalement, il faut initier le repo git du projet avec cette architecture commune) ;

   ○ Outils de communication pour partager des infos et des ressources : nous avons pour notre part mis en place un channel slack.

● Faites des tests réguliers : 2j c’est court, et on a envie d’en faire le maximum, mais prenez le temps de tester régulièrement le code que vous produisez. Certaines features sont prioritaires, et il faut assurer qu’elles soient opérationnelles au terme des deux jours : mieux vaut moins de features proprement réalisées qu’une pléthore de petites features accompagnées de sa pléthore de bugs …

● Faites des points rapides, mais réguliers avec toute l’équipe: toutes les 3-4h, par exemple, faites un point où les différents pôles de l’équipe précisent où ils en sont. Cela permet de vérifier que tout est en phase, et de faire des réajustements si besoin.

● Gardez un peu de temps à la fin pour “recoller tous les morceaux entre eux”. Dans notre cas nous avions réservé quelques heures pour faire la connexion entre le back et le front, et vérifier que tout arrivait bien à fonctionner ensemble.

5. Convaincre le jury : le boss final 

Ça y est, nous y sommes. Dimanche, 16h. À deux heures de la présentation devant le jury. A l’issue de ces deux jours de travail, nous avons quasiment réussi à développer un prototype d’application fonctionnelle : nous avons développé une petite application web qui reconnaît les tableaux pris en photo et propose des recommandations basées sur le contenu de ces tableaux.

Nous avons même installé des photos de tableaux dans notre salle, pour faire une démonstration…

Et ça fonctionne ! Lorsqu’on prend en photo le tableau suivant :

Marty reconnait bien le célèbre “Printemps” de Giuseppe Arcimboldo, et propose des recommandations de tableaux contenant … des fleurs :

Maintenant il ne reste plus qu’à convaincre le jury. Ca n’est pas une étape facile : en 5 minutes seulement, il faut arriver à :

– Faire comprendre clairement le principe de l’application et le besoin auquelle elle répond;

– Expliquer l’originalité de l’approche et la plus value de l’IA ;

– Démontrer le potentiel de l’application en présentant un business plan qui tient la route;

– Et surtout, faire rêver le jury, lui donner envie d’utiliser et de croire en votre

application.

Ici non plus, pas de secret : la présentation se prépare à l’avance et se répète. Pour notre part, nous avions dédié un pôle spécialement pour la partie “business”, qui était en charge de la définition du business plan et la préparation de la soutenance finale devant le jury. Il ne faut rien laisser au hasard :

– Se renseigner sur les marchés ciblés par l’application, quitte à aller sonder de vrais visiteurs du musée beaubourg juste à côté ;

– Anticiper les questions techniques ou business que pourrait poser le jury ;

– Chronométrer et répéter plusieurs fois la présentation.

Nous avons bien pris le temps de préparer et de répéter la restitution finale, et celle-ci s’est assez logiquement bien déroulée. Comme nous nous y attendions, nous avons été principalement challengés sur le business plan, mais le fait d’avoir anticipé les questions avec l’aide des mentors nous a permis d’éviter de tomber dans de gros pièges !

Conclusion

Au final, une troisième place (sur vingt…), et surtout un week-end hyper sympa entre team building et grosse geekerie !

Participer à un hackathon est une expérience extrêmement enrichissante. On se laisse très rapidement prendre par le challenge, la “frénésie créative” et l’envie de créer quelque chose de concret grâce à l’effort d’une dizaine de personnes bien motivées.

De plus, c’est l’occasion de découvrir de nouvelles technologies, et de s’enrichir des nombreuses idées des différents participants.

A ce stade l’application Marty est déjà fonctionnelle mais pas encore rendue publique : nous la déploierons sur AWS dès que possible. Entre temps un troisième article va bientôt paraître sur ce blog pour rentrer un plus dans les détails techniques de l’application, en expliquant comment nous nous y sommes pris pour faire de la recherche d’image et de la recommandation basé son contenu.

PS: Un grand merci à l’équipe du boncoin.fr ; à Rita pour ses méthodologies de gestion de projet et son charisme de pitcheuse et à Matthieu pour avoir réussi à développer toute la partie fronte (qui s’est interfacée en cinq minutes avec le back comme par magie). Merci aussi Wandrille à Aymeric pour tout leur apport pendant ce hackathon.