Un buzzer en une journée, et trois semaines pour le finir

Le 27 janvier, j’ai passé la journée à écrire de la documentation : architecture, spécifications, variables d’environnement, un fichier de consignes pour l’outil. Pas une ligne de code. Le 28, j’ai demandé l’application. Le soir, dix téléphones buzzaient sur un même écran, le premier gagnait, le serveur PartyKit horodatait les appuis pour empêcher la triche. Un commit, quelques corrections, et c’était là.

Je n’avais pas construit quelque chose de mes mains depuis des années. J’ai eu l’impression d’avoir retrouvé un vélo.

Ce que je croyais

Que c’était fini. L’application faisait ce que j’avais décrit : créer une partie, la rejoindre par un code à six lettres ou un QR code, buzzer, valider la réponse, compter les points, afficher un podium. Les tests Playwright passaient. Le 30 janvier, j’ai écrit un CHANGELOG avec un numéro de version, 1.0.0, et une liste de fonctionnalités longue comme le bras.

Version 1.0.0. Le numéro dit tout ce que je pensais.

Ce que c’était

Un prototype qui marchait sur mon réseau, avec mes appareils, quand c’est moi qui appuyais. Les trois semaines qui ont suivi ont été une suite de découvertes, toutes du même genre : ce n’est pas le code qui manquait, c’est le monde réel.

Le 28 au soir déjà, deux corrections « critiques » : la synchronisation des buzzers et l’identification des joueurs. Puis le mode strict de React, incompatible avec les connexions WebSocket, à désactiver. Puis le déploiement : un paramètre manquant dans la connexion au serveur, une page qui ne compilait pas en production. Puis les comptes organisateurs, prévus « pour plus tard », qui ont mis au jour un tas de choses sur les e-mails de confirmation et les variables d’environnement. Puis un téléphone Samsung sur lequel le bouton ne faisait rien. Puis Safari sur iPhone, où il ne faisait rien non plus, pour une autre raison.

Quatre-vingt-onze commits entre le 27 janvier et le 17 février. Une journée pour construire. Vingt pour que ça marche chez les autres.

Ce que j’en retiens

Je le savais. Dix-huit ans à faire des logiciels, on sait que la démo n’est pas le produit. Mais la vitesse du premier jour est trompeuse d’une façon nouvelle : quand l’application existe le soir même, tout ce qui vient après ressemble à du retard, alors que c’est le travail normal. Avant, ce travail était noyé dans les semaines de construction. Maintenant il est à nu, et il prend toute la place.

Le bon réflexe, que j’ai retrouvé vers le 13 février, c’est de considérer la première version comme le début de la liste, pas comme la fin. Et de mettre un vrai téléphone, qui n’est pas le mien, entre les mains de quelqu’un, le plus tôt possible.

La construction a pris une journée. Le reste a pris trois semaines, et le reste, c’est le produit.