19 heures, 16 équipes et un agent nommé Aviad

Auteur : Asaf Goldstoff

À 4 heures du matin, après 19 heures de travail ininterrompu, le dernier groupe était toujours au bureau. Nous avions commencé le matin précédent, et lorsque la lumière a de nouveau inondé les fenêtres du bâtiment, 16 équipes avaient déjà finalisé leurs projets. Plus de 60 employés ont participé à l'événement, et les équipes comprenaient non seulement des ingénieurs, mais aussi du personnel des ressources humaines et de la finance qui ont proposé des solutions de bout en bout fonctionnelles.

Ce n'est pas le premier hackathon auquel j'assiste, mais cette fois, il y avait quelque chose de différent. J'attribue cette différence — et, en fait, l'énorme amélioration de l'impact — à la planification préliminaire. Il est facile d'organiser un hackathon d'une journée pour qu'il ait l'air impressionnant, mais il est beaucoup plus difficile de l'organiser pour que ses produits survivent au lendemain.

Alors, comment transformer un hackathon d'une journée d'activité en un lieu où naissent de vraies solutions qui continueront à nous servir longtemps après ?

1. Préparer les équipes (bien avant de s'asseoir pour écrire du code)

Personne n'est venu au hackathon sans préparation. Dans les semaines précédant l'événement, nous avons organisé des ateliers de base sur les outils d'IA et avons appris à partir de cas d'utilisation réels (Use cases), afin que même ceux qui n'avaient jamais écrit de prompt sachent par où commencer. Parallèlement, nous avons demandé à chaque équipe d'arriver avec une liste de processus manuels et fastidieux de leur quotidien — pas une idée abstraite, mais un problème concret qu'ils souhaitent résoudre.

Dans notre cas, la plupart des participants n'étaient pas des développeurs, nous nous sommes donc concentrés sur la formation à Claude et aux outils de Vibe Coding. Tout au long des ateliers, nous avons présenté les meilleures pratiques (Best Practices) pour travailler avec les outils, et nous avons construit ensemble des produits, des compétences et des agents initiaux — afin que chaque participant et participante fasse l'expérience du succès avant même le hackathon.

Deux semaines avant l'événement, chaque équipe a soumis son idée pour approbation. L'objectif était de s'assurer de sa faisabilité et de sa valeur réelle, afin de ne pas passer 24 heures à construire quelque chose qui ne serait pas utilisé en pratique. Avant même le jour de l'événement, chaque équipe savait déjà exactement ce qu'elle venait résoudre.

Voici les trois paramètres principaux qui justifiaient chaque feu vert que nous donnions à une idée :

Faisabilité réelle pour le passage de la solution en production.
Potentiel prouvé d'économie d'au moins une journée de travail par mois — en temps ou en coûts.
Méthode de mise en œuvre correcte de la solution (pour s'assurer que les équipes ne créent pas de bonnes solutions de manière inefficace).

2. Construire une infrastructure qui centralise les projets et les préserve

Le lendemain des hackathons, la plupart des projets ont tendance à rester dans un dossier sur l'ordinateur de quelqu'un et à y être négligés. Pour éviter une telle situation, notre équipe DevOps a préparé à l'avance une architecture dédiée dans GitLab. Les nouveaux projets ont reçu un environnement de travail partagé et prédéfini, et les projets basés sur des systèmes existants ont été étiquetés selon une convention de nommage uniforme. Tous les produits ont été concentrés en un seul endroit, au lieu d'être dispersés sur des ordinateurs personnels.

Nous avons préparé à l'avance des modèles qui ont permis même aux équipes non techniques de mettre en place leurs solutions de manière simple et uniforme. De plus, une personne technique a été associée à chaque équipe en tant que mentor ou membre actif de l'équipe tout au long du hackathon. De notre point de vue, c'était l'occasion d'exposer les personnes non techniques aux défis et aux façons de penser aux problèmes techniques — et d'obtenir une vue plus large de la situation dans son ensemble.

De plus, nous avons fixé une règle simple à l'avance : pour qu'un projet soit considéré comme réussi, il doit être suffisamment mature pour passer en production. Cela a changé la nature du travail pendant la journée elle-même. Les équipes n'ont pas construit une démo qui ne fonctionne que sur scène, mais ont construit quelque chose qui doit continuer à fonctionner la semaine suivante. Qu'est-ce qui rend un projet suffisamment mature ? Dans le cadre du processus d'approbation des idées, nous avons accompagné et guidé les équipes pour qu'elles amènent leurs solutions à une production complète en 24 heures. Cela inclut :

La préparation de la solution pour une utilisation par le reste des utilisateurs de l'organisation.
La sécurité de l'information et la gestion des autorisations.
La possibilité d'étendre la solution ultérieurement de manière évolutive.

3. La question qui doit être posée dès l'inscription

Déjà au stade de l'inscription à l'événement, nous avons demandé à chaque équipe d'expliquer non seulement comment elle allait construire l'outil, mais aussi comment elle prévoyait d'amener son département à l'adopter dans la vie quotidienne. Une telle question à un stade aussi précoce oblige les gens à réfléchir à l'utilisation réelle bien avant d'écrire une seule ligne de code.

Avant le hackathon, dans le cadre du processus d'approbation des idées, nous avons effectué une planification initiale pour la mise en œuvre de la solution dans le département. Un processus de mise en œuvre peut inclure des ateliers, une passation organisée et la définition d'un responsable départemental qui dirigera l'adoption de la solution. Un bon exemple est l'équipe d'Onboarding, qui a construit une application permettant aux nouveaux clients de saisir leurs données de manière autonome et de voir les mises à jour dans le système en temps réel. Cela économise à l'équipe beaucoup de travail manuel, donc l'adoption de la solution a été presque immédiate. Pour la mise en œuvre, nous avons ouvert un tableau de tâches dédié et avons divisé le travail entre les membres de l'équipe d'Onboarding. Ainsi, chaque membre de l'équipe est partenaire de la mise en œuvre de la solution et de son adoption, et pas seulement un utilisateur.

4. Le twist : un juge non humain

Aux côtés des fondateurs et des managers qui siégeaient au jury, nous avons ajouté Aviad — un agent que nous avons créé spécialement pour l'événement. Après toutes les présentations des participants au hackathon, il a passé en revue leur transcription complète et a classé les équipes selon les mêmes critères que ceux utilisés par les juges humains. Son souci du détail nous a surpris, car il a identifié des angles d'analyse qui n'apparaissaient pas toujours dans la discussion des juges eux-mêmes.

Dans la première étape, nous avons présenté à Aviad toutes les idées soumises, y compris le problème que chaque idée était censée résoudre, la solution offerte par l'outil et la manière dont il peut être mis en œuvre. Ensuite, nous lui avons fourni les cinq paramètres principaux selon lesquels les juges prévoyaient de classer les équipes. Dans l'étape suivante, nous avons effectué divers tests sur lui, lui avons présenté une explication détaillée de chaque solution, y compris une démonstration à partir de la démo, et avons vérifié s'il parvenait à l'évaluer de manière cohérente. En cours de route, nous avons également corrigé divers cas limites.

À la fin des présentations, nous avons recueilli la transcription de chaque démo et l'avons transmise à Aviad, tout en nous assurant qu'il savait à quelle équipe et à quelle démo il faisait référence. Aviad a été invité à classer chaque démo selon les cinq paramètres, avec une note de 1 à 5 pour chaque paramètre, exactement comme les juges ont été invités à le faire.

Nous avons décidé de classer les groupes en calculant la moyenne des notes de tous les juges, y compris Aviad, donc la note d'Aviad a reçu un poids identique à celui de chacun des autres juges. Avant d'annoncer les gagnants, nous avons vérifié que les notes données par Aviad étaient en corrélation raisonnable avec les notes des autres juges, et nous avons effectivement vu qu'il évalue les démos de manière similaire à la plupart d'entre eux. Après cela, nous avons discuté avec lui pour comprendre les considérations derrière ses évaluations, et il semblait bien comprendre la complexité et la valeur que les solutions des groupes génèrent.

Dans l'une des présentations, Aviad a donné une note nettement plus élevée que la plupart des juges, principalement sur le paramètre qui examinait l'étendue des utilisateurs pouvant tirer profit de la solution. Lorsque nous lui avons demandé d'expliquer la décision, il nous a montré comment la solution pouvait servir deux départements supplémentaires, et pas seulement le département présenté par l'équipe, et a même décrit plusieurs cas d'utilisation pertinents pour eux. C'était intéressant — à la fois pratiquement et parce qu'aucun des juges humains n'avait saisi cette possibilité.

5. Le lendemain

L'un des objectifs du processus que nous avons construit était d'empêcher l'effacement de l'enthousiasme autour des projets. Et cela a fonctionné : des semaines après le hackathon, nous continuons à accompagner les chefs de groupe lors de réunions bimensuelles, pour nous assurer que les outils qu'ils ont construits ne resteront pas au stade d'expérience — mais atteindront une utilisation complète sur le terrain. La plupart des organisations sautent cette étape, mais à mon avis, c'est ce qui détermine si le hackathon a été un véritable investissement ou une journée de plaisir avec des pizzas.

L'objectif des réunions bimensuelles est de passer en revue les statuts, de documenter les tâches ouvertes qui doivent être résolues pour mettre en œuvre les idées, et de s'assurer que tout progresse comme prévu. Nous avons divisé les projets entre plusieurs personnes responsables qui sont chargées de pousser les solutions auxquelles elles ont été affectées. Lors des réunions avec elles, des lacunes techniques apparaissent parfois, nécessitant le soutien de la R&D et du DevOps, et pour cela, nous avons le CTO qui nous accompagne et s'occupe de fournir les ressources pertinentes. Les problèmes opérationnels liés à la connexion à d'autres produits dans l'organisation nécessitent le soutien du département RevOps, et pour les lacunes dans l'utilisation correcte des capacités d'IA, les groupes sont assistés par mon équipe, AI Operations.

Aujourd'hui, quelques semaines après le hackathon, deux solutions ont déjà été entièrement mises en œuvre dans leurs départements. Nous pourrons mesurer la valeur qu'elles génèrent dans environ trois mois.

Bien que relativement peu de temps se soit écoulé, les projets que les équipes ont réussi à construire en une nuit m'ont fait repenser la façon dont nous planifions l'avenir et divisons la responsabilité autour de l'IA dans l'organisation. Les cycles technologiques sont si courts aujourd'hui, et la capacité à créer des solutions est distribuée entre tous les départements — pas seulement parmi les ingénieurs. Cela nécessite une réflexion différente sur la planification à long terme.

Si vous vous demandez comment commencer, si vous souhaitez organiser un événement similaire chez vous, ou si vous êtes simplement curieux au sujet d'Aviad, vous êtes invités à m'écrire dans les commentaires et je serai heureux de partager nos expériences, nos erreurs et nos succès.

L'auteur est directeur des opérations d'IA (Director of AI Operations) chez Agora.