Ce que le format mesure
Un hackathon mesure la capacité d'une équipe à produire quelque chose qui fonctionne sous contrainte de temps, et c'est une compétence réelle. Il ne mesure pas la capacité à tenir ce qui a été produit.
J'ai animé un hackathon dans le cadre d'un summer camp, avec des équipes d'étudiants sur des outils de génération d'interface. Toutes ont livré quelque chose qui tournait à la fin des deux jours. C'est nouveau : il y a trois ans, la moitié n'y arrivait pas.
Cette réussite généralisée est le résultat le plus intéressant du format, et c'est aussi ce qui le rend trompeur pour qui en tire des conclusions sur le niveau.
L'écart qui apparaît dès qu'on gratte
Ce qui tourne au bout de deux jours ne comporte ni gestion d'erreur, ni tests, ni accessibilité, ni journalisation, et personne ne l'a remarqué pendant la présentation. Ce sont exactement les quatre chantiers qui font la différence entre un écran et un logiciel.
Le constat n'est pas un reproche adressé aux équipes : le format ne demande pas ces choses et ne laisse pas le temps de les faire.
Il devient un problème quand un jury, ou une direction, conclut de la démonstration que le produit est presque prêt. L'écart entre les deux états est bien plus grand qu'il n'y paraît, et il ne se voit pas sur scène.
Les quatre chantiers restants sont détaillés dans générer une interface, et ce qui reste à faire.
Ce que je regarde vraiment pendant les restitutions
- Si l'équipe sait dire ce qui ne marche pas. Une équipe qui liste ses limites a compris son sujet ; une équipe qui n'en voit aucune ne l'a pas testé.
- Si le résultat se vérifie. Sait-on dire, à la fin, si la sortie est juste ? Voir juger un projet d'IA en cinq minutes.
- Ce qui a été abandonné en cours de route, et pourquoi. C'est l'indicateur d'arbitrage le plus fiable en deux jours.
- Qui a fait quoi, ce qui révèle si l'équipe a travaillé ou si une personne a tout porté.
Ce que la génération assistée a changé au format
Elle a supprimé la barrière technique et déplacé la difficulté vers le cadrage, ce qui rend le format plus discriminant, pas moins. C'est le changement le plus net des deux dernières années.
Avant, une partie du temps passait à faire fonctionner les choses, et les équipes se départageaient sur l'exécution. Cette part a fondu.
Ce qui reste est le choix du problème, la définition de ce qui compte comme succès, et la capacité à renoncer à une fonctionnalité pour en finir une autre. Ce sont des compétences plus difficiles à acquérir que la maîtrise d'un outil, et elles se voient beaucoup mieux maintenant qu'elles ne sont plus masquées par les difficultés techniques.
Un hackathon est donc devenu un meilleur révélateur de maturité qu'il ne l'était, à condition de savoir ce qu'on regarde.
Ce que ça dit du recrutement
Les compétences que le format révèle maintenant sont exactement celles qu'on cherche en entretien, et elles ne figurent dans aucun classement d'exercice technique. C'est un usage sous-exploité.
Une équipe qui a arbitré, renoncé, et qui sait expliquer ses limites démontre en deux jours ce qu'un entretien met des heures à approcher.
À l'inverse, un candidat qui produit vite et ne voit aucune limite à son propre travail est un signal, et pas un bon.
Les deux questions que je pose en entretien viennent d'ailleurs de là : quel projet avez-vous arrêté et pourquoi, et comment sauriez-vous que ce système fonctionne. Elles sont développées dans recruter un profil IA : ce qu'il faut chercher.
La question qui départage les équipes en trente secondes
« Qu'est-ce qui ne marche pas dans ce que vous venez de montrer ? » Une équipe qui répond précisément a testé son travail. Une équipe qui ne voit rien a présenté sans vérifier.
Ce que j'en retire pour la formation
Le format apprend l'arbitrage sous contrainte, ce qu'aucun cours ne transmet, et il n'apprend pas à tenir un système. Il faut donc le compléter, pas le remplacer.
Le complément qui manque le plus est court : reprendre, deux semaines plus tard, un des projets produits, et le faire tenir. Ajouter la gestion d'erreur, un jeu de tests, une journalisation.
Cet exercice est ingrat et il enseigne exactement ce que le hackathon ne peut pas enseigner : le travail qui rend un système exploitable est plus long que celui qui le fait fonctionner.
C'est le même déplacement pédagogique que celui décrit dans former à tenir un système, pas à utiliser un outil, appliqué à un public étudiant.
Questions fréquentes
Que mesure réellement un hackathon ?
La capacité à produire quelque chose qui fonctionne sous contrainte de temps, et désormais surtout la capacité à cadrer et à renoncer. Il ne mesure pas la capacité à tenir ce qui a été produit.
Qu'est-ce qui manque à ce qui est produit en deux jours ?
La gestion d'erreur, les tests, l'accessibilité et la journalisation. Ce sont les quatre chantiers qui séparent un écran d'un logiciel, et aucun ne se voit sur scène.
La génération assistée a-t-elle rendu le format inutile ?
L'inverse. Elle a supprimé la barrière technique, ce qui rend visibles les compétences de cadrage et d'arbitrage, plus difficiles à acquérir et plus discriminantes.
Quelle question poser en restitution ?
« Qu'est-ce qui ne marche pas dans ce que vous venez de montrer ? » Une réponse précise indique que l'équipe a testé ; l'absence de réponse indique qu'elle a présenté sans vérifier.