MOLM

Le Contexte et le Problème

Le bien-être peine à se commercialiser simplement. Offrir une séance chez un masseur, un réflexologue ou un studio de pilates à un proche suppose de connaître le praticien, le tarif, et d'effectuer un paiement en dehors de tout circuit unifié. Molm répond à ce problème avec un concept minimaliste : une carte cadeau universelle, acceptée chez tous les praticiens bien-être partenaires du réseau.

L'enjeu du projet n'était pas seulement technique — c'était de construire un produit qui convainc à la fois les acheteurs (simplicité, confiance) et les praticiens (valeur du réseau, onboarding fluide). Les deux faces de la plateforme devaient fonctionner de concert.

Architecture et Choix Techniques

Le projet repose sur Next.js 16 App Router avec une gestion multilingue maison via des segments [lang] dans le système de fichiers — trois langues (FR, EN, DE) couvertes par des dictionnaires TypeScript typés, sans aucune librairie externe.

Supabase assure le stockage des données et l'authentification du dashboard d'administration. Les sessions côté serveur sont gérées avec @supabase/ssr et un middleware Next.js, garantissant que les routes d'administration sont protégées à la couche réseau avant même d'atteindre les composants React.

La validation des formulaires repose entièrement sur Zod, partagé entre client et server actions — un schéma unique qui valide les données en entrée et génère automatiquement les types TypeScript correspondants.

Défis Techniques et Solutions

Le premier défi a été le multilingue sans overhead. J'ai opté pour une approche dictionnaire maison plutôt que d'embarquer une librairie dédiée : chaque route [lang] reçoit le dictionnaire correspondant en props, éliminant tout contexte global et gardant les bundles légers.

• —Typage complet des dictionnaires pour détecter les clés manquantes à la compilation
• —Génération statique des pages par langue via generateStaticParams
• —Middleware de redirection automatique selon la langue du navigateur

Le formulaire d'onboarding partenaire présentait un second défi : multi-étapes, validation progressive et protection anti-spam. L'intégration de reCAPTCHA v3 dans un environnement App Router demande une attention particulière — le token doit être généré côté client juste avant la soumission, puis vérifié côté serveur dans une Server Action, sans jamais exposer la clé secrète.

Les emails transactionnels (confirmation d'achat, validation du compte partenaire) sont délégués à Resend avec des templates HTML statiques, sans dépendance à des moteurs de templates lourds.

Conclusion et Apprentissages

Molm m'a confronté à la réalité d'un produit bi-face : les décisions UX pour les acheteurs et pour les praticiens sont souvent opposées. Là où un acheteur veut de la friction minimale, un praticien a besoin de confiance et d'informations détaillées avant de s'inscrire.

Ce projet a consolidé ma maîtrise du multilingue sans librairie dans l'App Router et de la gestion des sessions Supabase en mode SSR — deux sujets où la documentation officielle laisse encore des zones d'ombre que l'on découvre en production.