Martin Molcrette a commencé comme développeur front avant de se spécialiser dans le design, puis les design systems. Quand il se retrouve dans une mission sans budget pour les outils de gestion de tokens, il décide de construire le sien. Ce qui devait être un outil local personnel est devenu TokenCraft : une plateforme SaaS avec base de données, authentification, API, plugin Figma, synchronisation bidirectionnelle et workflow agentique entièrement documenté. Tout ça, en solo.
1. Une contrainte qui devient un produit
Martin travaille sur un design system dans lequel les design tokens sont déjà implémentés comme variables Figma. Il veut une solution agnostique, indépendante d'un outil spécifique, pour gérer ces tokens. Des solutions existent (Token Studio, Supernova), mais elles ne sont pas dans le budget de la mission.
Son objectif au départ est simple et local : créer des design tokens sur une interface web et les exporter sur Figma via un JSON et un plugin. Pas de backend, pas de base de données. Une solution uniquement pour lui.
C'est en montrant ce premier POC à des collègues et amis designers qu'il réalise qu'un besoin réel existe autour d'une solution simple pour créer, gérer et exporter des design tokens depuis une interface web.
2. Pourquoi ce choix
Pour son premier POC, Martin choisit V0, l'outil de vibe coding de Vercel. Raisons principales : V0 génère du code Next.js, un framework full stack qu'il connaît déjà. Et son UI est basée sur ShadCN, une librairie open source flexible.
Autre point notable : il ne fait pas de maquette Figma avant de coder. Le but, c'est vraiment de créer grâce au prompt. La maquette se résumait à du texte.
Il sort de V0 dès que son problème initial est résolu : création de tokens sur une interface web et export vers Figma. À ce stade, il ouvre le projet dans Cursor, nettoie le code et commence à planifier la migration du stockage local vers une base de données.
3. Supabase pour la base de données, l'auth et le MCP
Une fois le besoin de collaboration identifié, Martin cherche une solution de base de données. Il choisit Supabase pour trois raisons : base de données, authentification intégrée, et MCP disponible.
Le MCP comme interface entre l'agent et la base
Le MCP permet à une intelligence artificielle, à un agent, à un LLM, de pouvoir dialoguer directement avec Supabase. Par exemple, on peut prompter en disant je voudrais une base de données pour mes design tokens, avec un nom, une valeur, une description. Et derrière, le LLM va s'occuper de se connecter au MCP et de créer les différentes tables.
Le point de vigilance sur les droits
Il note un point de vigilance sur les droits d'écriture donnés à l'agent. Pour éviter qu'ils fassent des actions qui pourraient compromettre des choses, casser des tables, même des données en production. Au début, il n'avait pas mis en place ces garde-fous parce que c'était pour lui seulement. Mais c'est quand même très important.
La synchro bidirectionnelle
La migration vers Supabase débloque de nouveaux usages : les tokens sont désormais accessibles via API, ce qui permet de connecter d'autres outils (Penpot, intégrations CI/CD GitHub) et une synchronisation bidirectionnelle avec Figma. Non plus juste un export JSON, mais une synchro multidirectionnelle entre variables Figma et TokenCraft.
4. Jouer le rôle de PM avec une équipe d'agents
Martin décrit son rôle dans ce workflow comme celui d'un PM qui orchestre des agents jouant des rôles de développeurs, de reviewer de sécurité, d'implémenteurs de tickets.
Linear comme source de vérité
Il gère tout son backlog dans Linear, connecté via MCP. Quand il demande une feature à l'agent, celui-ci va chercher le ticket dans Linear, récupère les détails, et s'occupe de l'implémentation. Sinon, il crée l'issue directement.
Les skills comme instructions
Les skills sont des fichiers d'instruction, des compétences qu'on donne à des agents. Dans son workflow : une skill de front-end design (bonnes pratiques, accessibilité, utilisation de ShadCN), une skill d'architecture du repo, une skill de sécurité Supabase, une skill de génération de changelog.
Le workflow en pratique
Un agent principal interprète la demande, récupère le ticket dans Linear. Un agent ticket implementer exécute en consommant les skills et le MCP Supabase. Plusieurs agents peuvent spawner en parallèle sur des tickets complexes. Un agent de review de sécurité prend ensuite le relais avant de pousser vers un environnement de test. Un humain prend le relais pour tester les fonctionnalités.
Ce workflow, Martin ne l'a pas inventé. C'est un workflow qu'on retrouve dans le monde réel, dans des équipes de produits. Les agents, c'est comme si c'était des personnes dotées de compétences spécifiques. Il l'a juste traduit virtuellement avec les IA.
"Maintenant, le côté développement, ce n'est plus trop un problème. Avec les agents, les skills qu'on a. Si je devais résumer tout ça en un mot, c'est la planification."
5. Quarante euros par mois et une technique de mémoire partagée
Martin a maintenu son budget à environ quarante euros par mois. Vingt euros pour Cursor, vingt euros pour Claude Code. Il n'a jamais eu besoin des plans à deux cents dollars.
Le bon modèle pour la bonne tâche
Pour les grosses features, il utilisait GPT. Pour des petits bugs, des petites fonctionnalités, le mode auto de Cursor sur les plus petits modèles. En termes de tokens, ça ne coûtait rien.
La mémoire partagée
Quand il atteint la limite d'un modèle, il bascule sur un autre. Ce qui rend cela possible : la mémoire partagée. Un fichier Markdown documentant l'architecture du projet, la roadmap et l'état d'avancement, checklisté par les agents à chaque implémentation.
Il met en garde contre la sur-utilisation des gros modèles. Opus, c'est vraiment pour des grosses fonctionnalités. Il ne faut vraiment pas l'utiliser pour des petits trucs parce qu'on crame du token pour rien.
6. Un SaaS en bêta, construit en solo
TokenCraft est une plateforme de gestion de design tokens. Ce qu'elle fait aujourd'hui :
Créer et manager des design tokens organisés en collections avec plusieurs modes (dark mode, etc.). Exporter en JSON, CSS ou SCSS. Importer depuis Figma ou d'autres sources. Synchronisation GitHub pour pousser directement sur un repo. Un assistant de tokens, une interface de chat intégrée pour créer, modifier ou supprimer des tokens via prompt. Un MCP TokenCraft pour connecter la plateforme directement à n'importe quel agent LLM ou codebase.
Martin a commencé en novembre et présente le produit en bêta fermée en avril. Il n'est pas full-time dessus. Pour développer des grosses features, avec tout ce workflow agentique, ça prend vraiment quelques minutes. Sur tout l'aspect documentation du SaaS, ça lui a pris deux soirées, peut-être un week-end.
Ce qui reste à faire : versionning natif dans l'application, gestion de workspaces multi-équipes, fonctionnalités enterprise.
7. Ce qu'il faut poser avant de coder
Si Martin devait refaire le projet, voici ce qu'il ferait dès le départ :
La sécurité en premier
Quand on développe un produit avec l'IA, on arrive à avoir un résultat super vite. Et là, on se confronte à un mur où on se dit, c'est trop cool, mais c'est de plus en plus dur d'ajouter des fonctionnalités. L'IA a de plus en plus de mal parce qu'en amont, elle n'a pas de contexte.
L'architecture et la documentation
Au fur et à mesure qu'on va développer ce produit, c'est de toujours documenter. Ça peut servir de mémoire partagée entre différents agents. Et si demain, quelqu'un voudrait reprendre le projet, c'est de la documentation.
La vision plutôt que la roadmap
Une roadmap, tu te dis je la planifie pour cette année. En fait, tu te rends compte qu'en deux mois, tu as shippé la majorité des fonctionnalités. Sa conclusion : parler de la vision, dire voilà le produit, à terme, je veux qu'il ressemble à ça.
Le piège d'aller trop vite
La capacité de délivrer n'est plus un problème, pour un POC, pour un MVP. Et c'est là le piège. On a tendance à vouloir rajouter beaucoup de fonctionnalités. On peut perdre le sens, la primitive du produit.
L'apprentissage par l'erreur
Sa méthode : commencer très simple. On commence par créer un skill, deux skills, avec un seul agent. Et au fur et à mesure, on essaye d'itérer. Les erreurs font partie du jeu. Mais derrière, c'est vraiment pour voir ce qu'on en tire et comment on améliore son workflow.
"C'est un peu la phrase de Spiderman : un grand pouvoir implique de grandes responsabilités. On a tout le champ des possibles. Et derrière, c'est vraiment ce truc de, OK, je me pose deux minutes. Cette fonctionnalité, c'est quoi la plus-value pour l'utilisateur ?"