Making of : “La nuit des Losers”

C'est en ligne ! Vous pouvez dès maintenant découvrir le site de notre événement : "La nuit des Losers".

Pour celles et ceux qui ne sont pas encore au courant : cet événement est dédié aux projets déchus (concours et appel d'offres), qui ont atterri dans les archives. Plutôt que de les pleurer et de s'apitoyer sur leur sort , cet événement est l'occasion de les mettre sur le devant de la scène !

Cet article de blog raconte comment nous avons construit ce site rapidement en utilisant l'IA, notre processus et ce que nous en avons retenu.

La mission du site est la suivante : expliquer le concept de l'événement, partager les infos pratiques, et donner envie à nos confrères et consoeurs de venir avec leurs propres projets enterrés.

Cet événement sera un espace sûr, avec une bonne dose d'humour et d'autodérision et le site doit le refléter. Les gens doivent s'y sentir assez à l'aise pour remarquer et apprécier les petits détails de design.

Tout a commencé par le processus habituel : les wireframes. Cette fois, c'est Alberto qui s'y est collé, et il s'avère qu'il a un talent caché pour le design. Plus sérieusement, il avait une idée précise de ce dont il avait besoin pour le site et la manière la plus simple de le transmettre est de faire des croquis !

Pour cette étape, on est revenu au papier et au crayon, les seuls outils qui ne se déconnectent jamais et qui ne rament pas.

Comme vous pouvez le voir, il s'agit d'une seule page, avec en introduction, un grand hero typographique. Vient ensuite la présentation du concept, les bonnes raisons d'y assister, une citation et le programme avec l'horaire. Plus bas, une liste des intervenants et intervenantes avec leur portrait, une section sponsors et agences partenaires, et un mot de clôture.

Une structure simple qui aide l'utilisateur à comprendre d'abord le but de l'événement, pourquoi y assister, le programme et les participants.

On m'a confié un visuel clé pour comprendre la direction artistique de l'événement et la pousser plus loin. Ce visuel reprend le geste de la main « Loser » avec des contours noirs épais sur fond blanc. Pas d'ombrage, pas de texture. Plat, propre, avec un côté cartoon, le genre de chose qu'on trouverait dans un pack d'emojis.

Il nous manquait tout de même une police. Pour ça, j'ai choisi Proxima Soft. Elle a les bonnes caractéristiques et les bons détails typographiques pour s'accorder avec l'illustration de la main, et grâce à Adobe Fonts, j'ai pu l'installer immédiatement.

Ça s'est aussi révélé utile plus tard : il m'a suffi de donner à Claude les liens de la police, et il les a utilisés directement dans le projet sans que j'aie besoin d'installer quoi que ce soit ni d'autoriser un accès de son côté.

J'ai ensuite itéré rapidement sur des écrans mobiles pour sortir des idées et écarter celles qui ne fonctionnaient pas.

J'ai choisi de travailler sur la version mobile car on s'attend à ce que beaucoup d'utilisateurs et utilisatrices arrivent depuis les réseaux sociaux. De plus, ça me permet de comparer côte à côte les différents écrans créés.

Une fois que j'ai obtenu un produit solide sur mobile, j'ai vérifié que la mise en page fonctionnait aussi sur un écran d'ordinateur. En y travaillant, quelques idées m'ont pas mal emballé.

Par exemple, je me suis dit que ce serait amusant que la main suive la souris, et que certaines sections pourraient être relevées par des animations au scroll.

L'idée la plus folle se trouvait près du footer : un flipper. Toutes de bonnes idées pour rendre le site engageant.

Mais étaient-elles vraiment réalisables sur le web ?

Donc une fois satisfait d'un premier jet, il était temps de mettre ces idées en pratique. Pour ça, j'ai utilisé Claude Code pour prototyper rapidement mes idées, avec le MCP Figma qui aide Claude à "lire" le design et générer la mise en page pour le viewport desktop.

Côté technique, j'ai volontairement gardé une stack simple : Vite et TypeScript, rien de plus. Pas de framework, pas de backend, pas de gymnastique de build. Pour un site d'une page, tout le reste aurait ajouté de la complexité inutilement.

Le hot reload de Vite est important car chaque modification faite par Claude apparait instantanément dans le navigateur, ce qui me permettait de juger une animation ou un ajustement d'espacement à l'instant même où il était appliqué, plutôt que de tout reconstruire et de deviner.

J'ai donc écrit mon prompt et appuyé sur enter.

Une fois que j'ai eu terminé avec Claude, j'ai été honnêtement surpris de voir à quel point c'était proche de ce que j'avais designé. J'ai dû apporter quelques corrections mineures : typographie, espacement, et couper quelques éléments superflus. Après ça, je suis passé à la partie amusante : les animations et les interactions.

J'ai testé plusieurs comportements pour la façon dont la main devait suivre la souris. Il a fallu plusieurs allers-retours pour bien faire. J'ai dû vraiment guider Claude sur la manière dont la main devait se tordre avec le curseur et pas seulement le suivre.

Puis, j'ai eu une idée que je pouvais tester sur-le-champ : cliquer sur "Nuit" et le site bascule en "mode nuit". J'ai aimé pouvoir la tester immédiatement plutôt que de la noter pour plus tard et de passer du temps dans Figma à choisir des couleurs pour une maquette de thème "sombre".

La bannière en haut de page a commencé comme un élément simple. Puis je me suis demandé si elle pourrait fonctionner comme un bandeau défilant, et Claude a géré la progression du défilement sans problème. Ce qui m'a surpris, c'est qu'elle arrêtait l'animation du défilement dès que la souris passait dessus. Quelque chose que j'aurais peut-être ajouté plus tard, mais c'est agréable de le voir déjà implémenté par défaut.

Ce genre de détails donne au site l'impression que quelqu'un a vraiment pensé aux utilisateurs et utilisatrices.

La carte expliquant l'événement principal paraissait plate une fois construite. J'ai demandé à Claude d'ajouter un petit tableau de bord de réactions, où les visiteurs et visiteuses pouvent réagir et voir les compteurs se mettre à jour en direct.

Ce n'est pas connecté à une base de données. Ça aurait ajouté une vraie complexité pour peu de bénéfice, donc les compteurs sont juste aléatoires et se réinitialisent.

Claude aurait probablement pu gérer la vraie version aussi, mais pour un site événementiel d'une page, faire semblant était le bon choix.

Pour la section "pourquoi y assister", je voulais quelque chose de plus que des cartes statiques, alors j'ai demandé une interaction de type clic pour déplier et afficher plus de détails.

Ça a bien fonctionné du premier coup, sauf que l'animation paraissait rigide. Mettre des mots sur ce que "rigide" voulait vraiment dire, ça a été la partie difficile. Mon collègue Benoît m'a aidé sur ce point. Une fois qu'on a pu bien le décrire, Claude a corrigé ça rapidement.

C'est aussi à ce moment que j'ai remarqué que ma consommation de crédits grimpait. J'ai brûlé des crédits en un seul après-midi d'essais-erreurs avant de changer ma façon de travailler.

Utiliser le mode plan, où l'on voit ce que Claude prévoit de faire avant qu'il ne touche à quoi que ce soit, a évité beaucoup d'allers-retours. Et beaucoup de crédits.

Il fallait rendre ces cartes intéressantes. Au survol avec la souris, nous avons fait pleurer les intervenants et intervenantes (bah oui, pourquoi se priver ;)).

La partie difficile fût de positionner les gouttes de larmes exactement là où on le voulait. J'ai donc demandé à Claude de nous construire un petit outil : une page nue avec le portrait, où je pouvais glisser la larme au bon endroit, cliquer sur "copier la position", et coller les coordonnées dans le chat.

Claude a ensuite placé chaque goutte avec précision. Une fois toutes en place, je lui ai demandé de retirer l'outil. Phrase étrange à écrire, mais c'est le workflow maintenant : construire un outil, s'en servir dix minutes, le jeter.

La section sponsors et agences partenaires a été la partie la plus difficile de tout le projet.

Première tentative : un flipper. Ça voulait dire réfléchir à chaque cas limite pour les murs, les réinitialisations, la façon dont plusieurs balles interagissent, et les contrôles au clavier pour les leviers par rapport aux clics. Et puis, bien sûr, les bugs.

Mon bug préféré, c'était quand la balle traversait occasionnellement un mur à grande vitesse et disparaissait complètement du plateau. Après avoir corrigé tous les bugs, ça fonctionnait bien sur desktop.

Le mobile, c'est une autre histoire. J'ai déployé des previews sur Vercel et j'ai découvert qu'un double-tap sur l'écran zoomait toute la page et cassait le jeu. Claude avait aussi du mal à verrouiller correctement les limites du canvas.

Après un moment, j'ai réalisé qu'on s'enfonçait dans un puits sans fond avec une échéance qui approchait, alors on a coupé nos pertes et opté pour quelque chose de plus simple : un jeu de type bowling-briques où la balle rebondit sur un plateau et marque des points en touchant les logos des sponsors.

Moins ambitieux que le flipper, mais ça fonctionne proprement sur ordinateur comme sur mobile, sans aucune bataille.

À l'origine, on prévoyait de vendre des billets, mais on a décidé que l'événement devait rester le plus accessible possible, donc on a totalement abandonné cette idée.

Le bouton "billet" a été transformé en bouton "ajouter au calendrier". Cliquez dessus, et un fichier calendrier apparaît, prêt à être enregistré.

Claude a même suggéré d'ajouter des détails qu'on n'avait pas pensé à demander : le moment de la notification, une courte description, le lieu. Un bon exemple de Claude qui comble les manques au lieu de simplement suivre les instructions à la lettre. Il avait assez de contexte pour savoir ce qu'on voulait vraiment.

J'ai appris à la dure comment bien gérer git : structurer les releases, créer une branche avant de tester quoi que ce soit d'important. J'ai cassé le site plus d'une fois en mélangeant des fonctionnalités dans une seule branche. Un processus plus lent, mais une vraie leçon.

Travailler ainsi a aussi permis aux trois personnes qui d'habitude, restent chacune de leur côté sur un projet (client, développeur, designer) de regarder la même preview Vercel en direct et de se mettre d'accord sur ce que "terminé" voulait réellement dire, au lieu que chacun imagine une version différente dans sa tête. Les gens pouvaient réagir au site pendant qu'il était encore brut, et on pouvait intégrer les retours rapidement plutôt que d'attendre une grande révélation.

Notre équipe de développement a aussi repéré de vrais problèmes : accessibilité, SEO, performance. Leurs retours comptaient. Et ça allait dans les deux sens : plus ils décrivaient précisément ce qu'ils voulaient, mieux Claude exécutait, parce qu'ils comprenaient vraiment le code sous-jacent.

Mon avis honnête : ce processus est excellent pour de petits sites d'une page comme celui-ci. Dès qu'on ajoute des bases de données, des formulaires, ou quoi que ce soit avec une vraie logique backend, on veut un vrai développeur aux commandes de cette partie. Et au-delà de la construction elle-même, Claude a fini par faire office de CMS léger, en corrigeant les textes, les dates, les numéros de téléphone, les fautes de frappe, sans qu'on ait besoin d'en construire un juste pour ça. Une nouvelle façon, plutôt amusante, de construire un site web.

Si ce n'est pas encore fait, allez y jeter un œil sur lanuitdeslosers.ch et trouvez tous les easter eggs.

À bientôt, on se voit à l'événement ! 😉