Badge builder

Le contexte

Chez Eventmaker, chaque participant d'un salon ou d'un congrès repart avec un badge. Ces badges sont générés par badge-core, un moteur C++ développé en interne qui en a produit des millions. Il est robuste et rapide, mais il ne lit qu'un format : trois fichiers JSON (contenu, vue, style).

Créer un badge revenait donc à écrire du JSON. Les clients ne pouvaient pas être autonomes, les chefs de projet mettaient du temps à se former, et les développeurs étaient régulièrement sollicités.

Un premier design en 2022

En 2022, la designer de l'équipe a conçu sous ma supervision un premier builder, sur le modèle de nos builders d'emails et de sites. Le design était validé, mais il n'avait pas été développé. Les éléments se positionnaient en saisissant des coordonnées X et Y, sans aperçu en temps réel.

Le projet est ensuite resté en attente. Quand il est revenu sur la table début 2024, prototyper dans le code ne demandait plus des semaines grâce à l'IA : pour un objet aussi visuel qu'un badge, je pouvais montrer quelque chose qui fonctionne plutôt qu'une nouvelle maquette.

Un prototype codé

En mars 2024, j'ai développé un prototype avec Fabric.js, une bibliothèque canvas open source qui gère le drag and drop, la sélection multiple et l'aperçu en direct. On pouvait déplacer, redimensionner et aligner les éléments, et le canvas produisait du JSON.

Pour vérifier la compatibilité avec l'existant, j'ai converti les trois fichiers d'un badge réel au format Fabric. J'ai présenté le tout dans un pitch, en posant la question que je ne pouvais pas trancher seul : que faire du moteur de rendu ?

La question du rendu

La réponse du CTO a recentré le problème. La conversion du JSON n'était pas la difficulté principale ; le rendu l'était. badge-core produit un PDF prêt à imprimer, Fabric dessine dans un canvas. Remplacer un moteur éprouvé par une conversion canvas vers PDF présentait des risques : multi-pages, polices, performances.

Nous avons abouti à une architecture plus solide que nos deux propositions initiales : badge-core pour le rendu, sans modification, Fabric.js pour l'édition, et un convertisseur entre les deux. L'éditeur se limite à ce que le moteur sait imprimer : pas de rotation dans un premier temps, par exemple.

Le format de données restait inchangé : les badges existants continuaient de fonctionner, et pouvaient être ouverts dans le nouvel éditeur.

Une semaine plus tard, un développeur avait validé l'approche : un texte placé dans le canvas apparaissait au même endroit dans le PDF.

Du prototype au produit

La même designer a ensuite réalisé les maquettes de l'interface. Nous avons étudié les éditeurs de référence, Canva et Figma en tête, pour reprendre les gestes que les utilisateurs connaissent déjà : alignement, grille magnétique, raccourcis clavier, historique. Pour accélérer le développement, j'ai rassemblé des exemples et des extensions open source de Fabric.js que l'équipe a pu adapter.

L'usage, deux ans après

L'objectif de départ était l'autonomie des clients. Sur cinq semaines de l'automne 2026 :

• 137 utilisateurs clients ont ouvert le builder, sur 165 événements, soit six fois plus que l'équipe interne
• 58 % des événements où un client consulte ses badges passent par le builder

Sur la durée, la tendance est la même. D'après les analytics, le nombre d'utilisateurs clients qui ouvrent le builder chaque mois a presque doublé d'une rentrée à l'autre, et il a rattrapé l'ancien formulaire à modèles en octobre 2026 :

Le JSON n'a pas disparu pour autant : l'équipe interne s'en sert encore pour les badges les plus complexes de grands salons ou de festivals, que le builder ne sait pas encore produire. C'est la limite que nous avions choisie au départ, et la suite logique du projet.

Ce que j'en retiens

Ce projet m'a confirmé qu'un prototype fonctionnel fait avancer une discussion plus vite qu'une maquette : le débat est passé de « est-ce faisable ? » à « comment le rendre fiable ? ». Et c'est en exposant ouvertement ce que je ne savais pas que nous avons trouvé la bonne architecture.

Équipe

• Robin Monjo, CTO : badge-core et la question du rendu
• David Huveau et Elena Verona, développement du builder
• Nadia Tefridj, design du builder, de 2022 à la version livrée