Les hackathons sont des rencontres où différents profils se réunissent pour produire en un temps réduit une application potentiellement commercialisable. Chez Dernier Cri, il nous arrive souvent de participer (et même parfois de gagner).
Dans cet article, je vais vous proposer une collection de méthodes presque infaillibles pour perdre un Hackathon à coup sûr mais tout de même retirer de l’expérience quelque chose d’intéressant !
Historiquement
Initialement, les hackathons étaient réservé à des hackers qui, dans leurs universités, bidouillaient pour améliorer leurs expériences utilisateurs avec de très grosses machines incompréhensibles pour le commun des mortels.
Bien que les hackathons soient nés dans le contexte de l’informatique appliquée, le succès de ce genre d’événements a suscité un intérêt particulier pour les autres professions qui gravitent autour des métiers du numériques.
Les développeurs en retrait
En général, le jury des hackathons est composé d’une partie des organisateurs ainsi que de personnes relativement influentes dans le monde de la technologie. Comme les technologies admissibles ne sont pas restreintes pour l’événement, il est très dur d’imaginer qu’il soit possible de trouver des profils capables de juger tous les langages/technologies potentiellement utilisables. De plus, il est très complexe de juger de manière pertinente la qualité du code développé étant donnée que la séquence de jugement porte généralement sur une démonstration de l’application, le code source ne rentrant donc pas en ligne de compte.
Il existe plusieurs critères (subjectifs comme objectifs) plus facile à jauger que la qualité d’un programme informatique :
- L’esthétique de son interface ;
- l’ergonomie d’une application ;
- ses leviers commerciaux potentiels.
Même si certains événements font l’effort de récompenser les prouesses techniques, en général, et c’est assez compréhensible, le développeur est souvent en retrait et une équipe composée exclusivement de développeurs aura très peu de chance de victoire.
Je vous propose donc le retour un peu aigri du développeur que je suis sur comment gagner, sans prendre trop de risques, un hackathon.
Comment gagner un Hackathon
Sans aucune provocation, voici une méthode pour maximiser ses chances de victoire. Premièrement, une équipe hétéroclite, mais pas trop :
- Un commercial qui travaillera son pitch durant tout l’événement ;
- un graphiste qui ne fera que des maquettes soignées ;
- un développeur qui ne s’occupera que du front-end.
Peu importe la faisabilité d’une idée, la démonstration est tellement courte qu’il sera impossible pour le jury de déterminer la viabilité technique du produit. Le commercial pensera à un business-model pendant que le graphiste et le développeur intégreront l’application comme un prisme visuel de ce qu’elle devrait être.
Lors de la présentation finale, le commercial deviendra porteur de projet, il parlera de Uberisation et proposera des partenariat futur avec les entreprises des membres du jury ou des partenaires de l’événement, il parlera de french-tech, réveillant notre patriotisme enfoui, en montrant rapidement les quelques écrans implantés pour la démonstration. On pourra entendre parler de viabilité économique, de nouvelles technologies, d’UX design et il pourra même terminer en espérant que son rêve, et celui de toute son équipe qui est de faire du monde un meilleur endroit, se réalise grâce à leur application.
Si la quête d’un développeur est trop complexe, on peut noter que l’équipe pourra s’en passer en laissant le graphiste implanter l’application sous forme de diaporama Powerpoint avec la forme d’une application (c’est du vécu…)
Même si ce guide est un peu caricatural, il est assez courant de voir, durant des hackathons, beaucoup de projets irréalisables recevoir les louanges du jury. Heureusement que ces applications ne sortent jamais de leur cocon !
Hacker un Hackathon : le succès dans la défaite
Historiquement, la motivation première du hackathon est de cultiver un intérêt pour les aspects communautaires des gens intéressés par le monde de la technologie. Bien que l’on puisse regretter un manque de partage indéniable concernant les projets produits, on retrouve en ces lieux des gens motivés par des éléments arpentant les mêmes sphères. Sans participer à la compétition, on peut tout de même rencontrer beaucoup de personnes motivées par les mêmes thématiques, un peu comme lors des MeetUp articulés autours de certains sujets, certaines technologies.
Dans cette optique, il est possible de totalement détourner la compétition pour accroitre son réseau relationnel ou tout simplement de profiter des victuailles (généralement gratuites) pour discuter, le ventre plein, de sujets intéressants.
Au delà du plaisir simple de la conversation, l’ambiance générale, justifiée par la compétition et par les intérêts convergeant des acteurs peut être un environnement idéal pour beaucoup de distractions.
L’expérimentation
Alors que les conseils principaux pour réussir avec succès un hackathon proposent en général aux participants de rester dans un périmètre connu, la durée allouée à un hackathon est suffisamment longue pour avoir le temps de découvrir des technologies et des méthodologies différentes. Par exemple :
- Décider de découvrir un cadriciel OCaml sans aucune connaissances dans l’outil ;
- utiliser des méthodes de développement agile (parce que c’est rigolo) ;
- changer la hiérarchie de gestion de projet.
En général, la productivité en prendra un sacré coup, par contre, sans les pressions des enjeux réels d’une entreprise, il devient facile de remettre en question certains modes de fonctionnement éprouvés. Expérimenter dans un contexte réel est bien plus formateur que la théorie pour la théorie et l’environnement du hackathon est un endroit idéal pour ce genre de perspectives.
Bien qu’une victoire soit un objectif difficile à atteindre quand on découvre et qu’on remet en question ses pratiques récurrentes, il y a fort à parier que certains constats liés à cette remise en question seront sans aucun doute bénéfique. A terme, il est possible que cette transformation standardise une approche, et que lors du hackathon suivant, la recette expérimentée lors de l’édition précédente se révèlera être la clé du succès !
Le bootstrapping de projet
Il arrive très souvent qu’il nous manque une petite impulsion pour lancer un projet personnel. L’environnement du hackathon est aussi idéal pour démarrer un projet viable (ce qui le différenciera de 80% des projets produits dans le cadre réel de la compétition). En effet, en plus de bénéficier d’un open-space et de profiter de l’émulation générale, il devient facile d’obtenir de la revue de la part d’autres participants (pour peu qu’ils en aient le temps) mais aussi, pourquoi pas, tenter d’aller jusqu’à la période des pitch pour bénéficier de l’avis du jury. Même si le projet est hors sujet et que le jury le notifiera, il est fort à parier qu’ils émettront tout de même certaines critiques constructives.
Idéalement, le lancement d’un projet annexe peut être mis en oeuvre lors de la compétition si le sujet/thème ne convainc pas l’équipe.
Cette proposition permet de bénéficier des conditions (généralement bénéfiques) du hackathon, avec tout de même un peu moins de pression que lors de la réalisation d’un projet absolument pertinent vis à vis du thème car ce que l’on attend généralement de ce genre de démarche est simplement l’impulsion nécéssaire au lancement d’un prototype.
L’Oulipo appliqué à la conception de projet
L’Oulipo est “L’ouvroir de littérature potentielle”. Appliqué à de nombreuses disciplines (la bande dessinée, les jeux-vidéos, le cinéma par exemple), l’Ou-X-po s’intéresse à la notion de contrainte.
Cet exemple ressemble relativement à celui de l’expérimentation et il est d’ailleurs possible de très facilement les combiner. Au delà de l’aspect ludique du travail avec contraintes, l’usage de ces dernières permettent des contours élégants (ou affreusement sales) à des problématiques récurrentes dans la conception de projets. Voici quelques exemples de contraintes amusantes :
- N’utiliser que des des outils libres ;
- limiter au maximum les effets de bords dans l’application ;
- intégrer au maximum les contraintes d’accessibilité ;
- écrire tous le projet sans revenir une seule fois en arrière dans l’édition du code ;
- tout programmer par services.
Au delà d’amuser (ou exaspérer, à choisir) les acteurs de ces mises en contraintes, il arrive très souvent que de très beaux motifs de conception ou méthodologie soient extractibles de contraintes. Appliquer ce genre de jeux à un hackathon peut surprendre par les solutions trouvées et, généralement, ça fait son petit effet lors du compte-rendu au jury.
Pour conclure
Il est évident que la compétition est une très bonne chose et que ne participer à des hackathons que pour le plaisir de contourner les règles serait dommage. Cependant, il arrive que le développeur veuille reprendre ses droits et tâche de bénéficier au mieux de l’espace et de l’ambiance qui lui sont alloué pour se former et évoluer.
La conception de projet, dans son ensemble, est une tâche difficile, et parfois frustrante pour le développeur, limité au statut d’exécutant. Pour cela, il peut être ludique et formateur de se recentrer sur l’objectif premier du hackathon, au delà de l’aspect compétitif, qui est la fédération de communautés et le plaisir de la performance.