Media Kit
Un SaaS né d’un générateur de visuels personnalisés, devenu un produit d’activation événementielle aujourd’hui relu de fond en comble avant une V2.
Le point de départ
Media Kit a commencé beaucoup plus petit : générer des visuels personnalisés faciles à partager. Le besoin a progressivement dépassé le générateur pour devenir un produit vendu, utilisé pour préparer et distribuer du contenu à des participants d’événements.
La V1 a donc accumulé de vraies contraintes de produit : plusieurs audiences, différents types de contenus, des états de publication, des intégrations, des accès participants, des règles de plan et de la mesure d’usage.
Ce que la V1 a prouvé
Le produit ne se résume plus aux visuels. Il organise une chaîne plus large : configurer ce qui sera proposé, activer les bons participants, puis mesurer ce qui s’est réellement passé.
Cette évolution est la preuve la plus importante du projet : une idée très ciblée a trouvé assez d’usage pour devenir un SaaS plus riche. Elle a aussi créé une dette classique des produits qui grandissent par itérations : certaines règles sont intentionnelles, d’autres sont seulement devenues vraies parce que l’implémentation les a figées.
La contrainte de la V2
Réécrire le code sans distinguer ces deux catégories reproduirait simplement la dette dans une stack plus récente. La V2 est donc développée dans un repo séparé et commence par une phase de discovery, avant d’implémenter les fonctionnalités Media Kit.
Le principe est parité comportementale quand elle est nécessaire, pas parité d’implémentation. La V1 est relue à partir du code, des tests, des schémas, des migrations et de l’historique afin de classer chaque comportement : à conserver, redessiner, supprimer ou différer.
Les choix qui ont compté
La cible produit est maintenant décrite autour de trois verbes — Setup → Activate → Measure — plutôt qu’autour de la structure historique des écrans. La V2 doit également garder une frontière claire entre le domaine Media Kit et ses intégrations : une plateforme partenaire importante ne doit pas devenir le modèle de données du produit.
Les décisions de migration sont prises au fur et à mesure de l’audit. Par exemple, la V2 distingue explicitement publication, preview interne et preview partageable au lieu de reproduire un simple bypass de la V1.
Où le projet en est
La V1 reste la référence de production. La V2 est encore en discovery : plusieurs domaines fonctionnels ont déjà été audités et documentés, mais aucune feature Media Kit V2 n’est considérée comme implémentée simplement parce que le boilerplate existe.
C’est volontaire : le résultat attendu de cette phase n’est pas un écran neuf, mais une compréhension suffisamment précise pour que la reconstruction améliore réellement le produit.
Ce que j’en retiens
Une replatform n’est pas d’abord un chantier de stack. C’est un exercice de séparation entre le comportement que les utilisateurs attendent et les accidents de l’ancienne architecture.
L’autre leçon est de ne pas prendre la mémoire du créateur comme source de vérité unique. Quand un produit a vécu, les preuves sont réparties dans son code, ses données, ses tests et son historique ; les confronter avant de réécrire évite beaucoup de fausses certitudes.