Retour d’expérience d’un Hackathon
TLDR : Cet article raconte le déroulement d’un hackathon au sein de SensCritique, c’est un article “tech” qui à pour objectif de vous montrer les coulisses de SensCritique.
Après une année riche en rebondissements, nous nous devions de finir l’année en vous remerciant pour vos différentes implications au sein de la communauté SensCritique.
2022 n’a pas été facile pour l’équipe technique, la sortie du nouveau site nous a énormément sollicités mais grâce à vos retours et vos encouragements nous avons pu centrer nos efforts. Encore une fois … MERCI !
Pour terminer cette année nous avons décidé de nous réserver une semaine pour effectuer un Hackathon.
Un Hackathon, c’est un événement durant lequel une équipe de développement se charge de travailler sur une fonctionnalité sur un délai assez court. En fonction de la taille des équipes, il peut y avoir plusieurs sujets en parallèle mais l’idée est la même : focus sur une tâche précise dans un temps imparti.
Les principales raisons pour faire un hackathon sont :
- Sortir des tâches du quotidien tout en développant une fonctionnalité avec une valeur ajoutée pour nos utilisateurs.
- Augmenter la cohésion dans l’équipe, on travaille ensemble ! que ce soit pour la prise de décision ou le développement.
- Réaliser un projet que l’on n’aurait pas intégré à la roadmap.
Pourquoi maintenant ? : L’activité est réduite en fin d’année et nous voulions avoir quelque chose à vous “offrir” avant la fin de l’année…
Après quelques discussions en interne, nous avons choisi d’orienter notre Hackathon vers la création d’un “Spotify Wrapped”, autrement-dit une page de statistiques de consommation annuelle.
Nous sommes nombreux à apprécier les bilans de consommation annuels; Spotify s’est démarqué sur ce sujet, là où d’autres acteurs essaient encore d’innover avec plus ou moins de succès, c’est le cas de Deezer, Twitch, Strava et bien d’autres.
Cette fonctionnalité a déjà été développée par le passé mais elle rencontrait quelques faiblesses.
Commençons par revenir dans le passé, voici à quoi ressemblait LeRécap’ SensCritique :
Première faiblesse: C’est une vidéo.
Les plus aguerris des techs auront vite compris la complexité, pour chaque utilisateur nous devions récupérer ses données en base de données, les formater dans un format intelligible (JSON) puis les fournir à l’équipe vidéo qui ensuite se chargeait de générer la vidéo.
Le gros avantage d’avoir une vidéo c’est de pouvoir partager l’intégralité de son Récap’ à n’importe qui (en plus d’avoir un rendu très animé), l’inconvénient principal c’est que c’est très coûteux en temps de calcul et de montage. On aurait pu automatiser une partie mais quand bien même nous n’aurions jamais pu réaliser les vidéos de tous nos utilisateurs…
Et c’est là qu’entre en jeu la deuxième faiblesse : L’accessibilité.
Ces vidéos n’ont été envoyées qu’à un nombre restreint d’utilisateurs et nous ne voulions pas continuer avec ce modèle. A partir du moment où nous disposons d’assez de données pour créer un récap pour un utilisateur, nous devons être en mesure de lui en proposer un.
Avant de lancer le Hackathon, nous nous sommes réservé du temps pour réfléchir aux contraintes que l’on pouvait rencontrer. L’idée principale étant de limiter le risque de blocage technique sur des problématiques évidentes, mais de ne surtout pas faire le hackathon avant le hackathon.
“Comment préparer un hackathon sans solliciter l’équipe ?”
On écrit ! Écrire ses craintes et ses idées (même les plus farfelues) ça nous permet de mieux comprendre les enjeux et ça donne un support à l’équipe lors du hackathon.
J’ai donc rédigé un document notion avec toutes mes idées, les possibilités qui s’offraient à nous comme le fait de pouvoir générer une vidéo “à la volée” sans nécessiter une intervention humaine ou faire une simple page de “statistiques”.
J’ai même fini par faire une maquette Figma de ce que j’avais en tête … Imaginez la tête d’Antoine, notre designer, quand il a vu la maquette le jour-J…
Quelques jours avant le hackathon j’ai présenté mes idées à Matthieu, notre lead-developer pour avoir son avis. Encore une fois, l’idée n’est pas de faire le hackathon à deux mais d’avoir un regard différent.
D-Day
C’est le grand jour, une partie de l’équipe est tendue à l’idée de faire ce Hackathon, c’est nouveau pour beaucoup et ils ne connaissent que le sujet du hackathon, pas son déroulement.
On commence la journée en douceur par un petit-déjeuner, c’est le moment de tous se retrouver en présentiel car une partie de l’équipe est en télétravail à plein/mi-temps le restant de l’année.
Après quelques chocolatines et croissantines (wink wink les sudistes), nous avons commencé le hackathon par une présentation du sujet et du déroulement du hackathon.
J’avais réservé la matinée pour qu’on puisse réfléchir tous ensemble à la fonctionnalité mais en 1h30 c’était plié.
“Est-ce que l’idée vous semble réalisable ? dans les temps ? des SPOF (Single Point of Failure) en vu ?”
La réflexion d’équipe a été efficace, tout le monde s’est rapidement impliqué et a pu faire ses recommandations. La plus grosse crainte mise en avant par l’équipe était le découpage des tâches, comment allons-nous avancer alors qu’il n’y a aucun design, aucune réflexion globale ?
Dans un cycle de développement “standard”, le designer est souvent le premier à opérer. Il nous propose des maquettes, les modifie puis les met à disposition quand tout est prêt. C’est à ce moment que les développeurs et développeuses prennent le relai.
Afin de permettre à tout le monde de travailler en même temps (et donc gagner du temps) nous avons décidé de faire plusieurs binômes qui pourraient travailler en pair-programming.
En plus des binômes, nous nous sommes mis d’accord sur le “rendu final” : On souhaite avoir un format “insta-like” avec un système de “stories” et une musique de fond. En se basant sur la maquette que j’ai réalisée, on garde un écran 9:16eme central et un fond derrière cet écran.
Ce format va nous permettre de rendre la fonctionnalité disponible sur mobile et desktop sans avoir à réaliser différents rendus.
L’autre intérêt est de prévoir une réutilisation de ce format dans notre application mobile, car oui c’est un de nos futurs gros chantiers..
Grâce à cet accord sur le rendu final de notre fonctionnalité. Nous avons pu effectuer la répartition des tâches assez rapidement :
- Audrey et Matthieu ont travaillé sur la création du squelette de la page, toute la mécanique pour passer d’un écran à un autre, avoir les petites bulles d’avancement etc
- Viviane et Emilien se sont mis sur la création du MCD (Modèle Conceptuel de Données) et de la création de la migration SQL qui nous permettra de stocker les statistiques finales.
- Guillaume, data scientist, s’est orienté vers la création et l’optimisation des requêtes SQL afin de simplifier le travail des dévs quand ils devront implémenter la logique back-end.
- Antoine a quant à lui commencer à réfléchir à la charte graphique de la page, on part de zéro il nous faut donc des couleurs, des SVG, des composants etc. pour pouvoir démarrer la réalisation des différentes pages.
- Pour ma part, pendant les deux premiers jours j’ai accompagné Guillaume (data scientist) et Antoine (designer) afin qu’ils ne soient pas tout seul. Puis j’ai rejoins les dévs sur le reste de la semaine.
A la fin de la première journée nous avions déjà un premier squelette “light”, la base de données était pratiquement prête, les requêtes SQL étaient en bonne voie et nous avions déjà une proposition de charte graphique.
Les complications
La plus grosse contrainte en Hackathon c’est le temps. Vous devez tout faire mais avec peu de temps, il faut donc choisir ses combats.
On s’en est rapidement rendu compte quand on voyait le temps défiler et nos idées s’envoler avec lui.
On a régulièrement dû trancher sur ce qu’on gardait ou non dans le Récap’, comme par exemple un écran “Les pépites à découvrir”, qui permettait d’afficher des films ou séries à ne pas rater. Ou encore le bouton “Partager” qui auraient permis de partager chaque écran sur les réseaux sociaux..
La principale raison de ces choix a été le temps, encore et toujours. Faire des animations différentes à chaque écran c’est cool mais c’est très long à réaliser, que ce soit pour le designer ou pour les développeurs et développeuses qui doivent les implémenter (en plus de développer l’interface, le back-end, régler les bugs et effets de bords etc)
Malgré ces arbitrages qui peuvent parfois être frustrants, l’équipe s’est donnée à 200% pendant une semaine avec pour objectif commun de terminer ce hackathon, ce qu’ils ont fait avec brio.
Fin du hackathon et ressenti
C’est avec plaisir et fierté que l’on a terminé cette semaine de Hackathon.
Tout n’est pas parfait (rien ne l’est) mais une chose est sûre, on en refera un l’année prochaine et LeRécap’ sera enrichi avec le temps parce que oui, bien qu’on soit satisfait du résultat, il y a encore quelques axes d’améliorations :
- Ajouter d’autres données plus pertinentes et plus “fun”
- Intégrer les autres univers (musique, jeux vidéo, livre, bd..)
- Ajouter un bouton “Partager”
- Et encore plein d’autres idées..
Si vous travaillez dans la tech’ et que vous désirez vous lancer dans l’organisation d’un hackathon en interne, voici quelques recommandations:
- Bien répartir les compétences
Mélangez les compétences des uns et des autres pour que tout le monde y gagne - Ne laisser pas quelqu’un seul
- Bien répartir les tâches
C’est à la fois la clé de la réussite d’un hackathon mais aussi sont plus gros challenge. - Trouvez un sujet qui motive votre équipe
- Préparez le “cadre” du hackathon à l’avance
Certains hackathon partent aussi de zéro, c’est une question de préférence mais en fonction de vos besoins il sera peut être plus judicieux d’arriver avec un cadre (organisation, risque, crainte, étude de faisabilité etc). - Proposez et choisissez des sujets à l’avance
C’est toujours du temps de gagné et ça n’apporte pas énormément de valeur lors du hackathon - N’ajoutez pas de pression supplémentaire
C’est un moment particulier qui peut être stressant pour certaines personnes, gardez à l’esprit que ça doit rester un moment convivial et agréable pour tout le monde. Comme dirait Jérôme Niel “ON APPREND EN S’AMUSANT”
Visiteurs, contributeurs, admins, équipe SC, merci à tous d’avoir suivi nos aventures cette année et d’être à nos côtés pour continuer cette belle histoire qu’est SensCritique !
Thibaut — CTO
