Le produit en 30 secondes
Alzée transforme le faire-part en un lien vivant : invitation, informations pratiques, programme, RSVP puis galerie souvenir restent réunis au même endroit.
Le couple choisit une direction artistique, construit un brouillon en cinq étapes et voit immédiatement le résultat dans un aperçu mobile. Il peut avancer même si le lieu, la date limite de réponse ou les textes ne sont pas encore définitifs.
L'invité consulte ensuite un lien public, principalement sur mobile, retrouve les informations à jour et répond sans créer de compte. Mon rôle couvre le cadrage produit, le parcours, le design system multi-thèmes, le front-end et les arbitrages liés à la mise en production.
Cadrage : partir de la situation, pas de l'écran
Le problème n'était pas de mettre un faire-part en ligne. Il fallait réduire la dispersion d'informations sans retirer l'émotion de l'objet.
Avant un mariage, les informations changent : horaire, accès, hébergement, programme ou date limite de réponse. Lorsqu'elles sont réparties entre un faire-part, un formulaire et plusieurs conversations, le couple doit répéter les mises à jour et l'invité ne sait plus quelle version consulter.
J'ai donc cadré Alzée autour de deux besoins complémentaires : donner au couple un espace qu'il peut faire évoluer, et donner à l'invité une source unique, lisible immédiatement sur téléphone.
- Le couple ne possède pas forcément toutes les informations lors de la première visite.
- Le choix esthétique est émotionnel, mais treize options peuvent créer de l'hésitation.
- L'invité ne doit ni s'inscrire ni apprendre une nouvelle interface pour répondre.
- Le contenu doit rester indépendant de l'univers pour autoriser un changement de thème sans perte.
Quel est le vrai objet du produit ?
- Décision
- Un lien unique qui accompagne le mariage avant, pendant et après.
- Pourquoi
- Cette définition réunit invitation, mises à jour, RSVP et souvenirs dans un même modèle mental au lieu d'empiler des fonctions séparées.
- Compromis
- Le périmètre devient plus large qu'un simple faire-part ; il faut donc garder un parcours de création très guidé.
Pour qui concevoir en premier ?
- Décision
- Distinguer le parcours du couple et l'expérience mobile de l'invité.
- Pourquoi
- Le couple configure et administre sur plusieurs sessions ; l'invité doit comprendre et répondre en quelques instants.
- Compromis
- Deux expériences à maintenir, mais une responsabilité beaucoup plus claire pour chaque interface.
Hypothèses et principes de conception
Je n'avais pas encore un volume de recherche utilisateur permettant de présenter ces constats comme des certitudes. Je les ai traités comme des hypothèses à rendre observables dans le produit.
Le principe central est de donner de la confiance avant de demander un engagement. L'utilisateur doit voir une invitation crédible, comprendre ce qu'il pourra modifier et avancer avec les informations qu'il possède déjà.
Le parcours public actuel traduit ces hypothèses en règles concrètes : tout montrer avant le paiement, rendre les champs secondaires facultatifs et repousser la création du compte après les premiers choix utiles.
- Montrer le résultat pendant la saisie plutôt qu'après un long formulaire.
- Permettre « je ne sais pas encore » pour le lieu, la date et la limite RSVP.
- Conserver l'accès aux treize univers même lorsqu'un quiz en recommande un.
- Séparer sauvegarde du brouillon, activation du lien et paiement.
Comment réduire l'hésitation devant treize univers ?
- Décision
- Proposer un quiz de recommandation tout en laissant toute la collection accessible.
- Pourquoi
- La recommandation donne un point de départ sans transformer une suggestion en choix imposé.
- Compromis
- Le quiz ajoute une entrée au parcours, mais évite de réduire artificiellement la diversité de la collection.
Quand demander la création du compte ?
- Décision
- À la cinquième étape, après le thème, les prénoms et les premiers détails.
- Pourquoi
- L'utilisateur a déjà compris la valeur et visualisé son invitation avant de rencontrer la friction d'authentification.
- Compromis
- Le brouillon n'est sauvegardé qu'à la fin ; l'interface doit donc expliquer clairement ce qui va être conservé.
Le configurateur : cinq étapes et un aperçu vivant
Le configurateur transforme une tâche ouverte — « créer mon invitation » — en décisions courtes, réversibles et immédiatement visibles.
Étape 1 : choisir un univers, avec des filtres par style. Étape 2 : saisir les prénoms. Étape 3 : renseigner ou différer le lieu, la date et la limite RSVP. Étape 4 : ajouter les détails facultatifs et une photo. Étape 5 : créer l'espace qui sauvegardera le brouillon.
À droite, un aperçu mobile se met à jour avec les prénoms et l'univers sélectionné. Il sert de preuve et de contrôle : l'utilisateur ne remplit pas des champs abstraits, il construit déjà un objet qu'il reconnaît.
Formulaire complet ou progression guidée ?
- Décision
- Un parcours en cinq étapes avec une seule famille de décisions à la fois.
- Pourquoi
- Le couple peut commencer tôt, sans disposer de tout le programme, et comprend toujours ce qui lui reste à faire.
- Compromis
- Davantage de transitions et d'états à tester qu'un formulaire unique.
Aperçu après validation ou pendant la saisie ?
- Décision
- Un téléphone de prévisualisation persistant et mis à jour en temps réel.
- Pourquoi
- Le feedback immédiat relie chaque donnée à son effet visuel et réduit la peur d'un résultat découvert trop tard.
- Compromis
- La synchronisation entre formulaire, données et treize thèmes devient une contrainte technique structurante.
Treize univers, un seul modèle de données
Les univers ne sont pas de simples arrière-plans. Chacun possède sa typographie, son rythme, ses variantes de couleur et une manière propre de mettre en scène l'invitation. En revanche, les informations du couple, le RSVP et les règles de publication doivent rester les mêmes.
J'ai donc séparé le contenu, les comportements et la direction artistique. Le modèle de données porte les prénoms, les dates, les lieux et les sections ; les composants portent les interactions ; les tokens et variantes portent l'expression visuelle.
- Treize directions artistiques, chacune déclinée en quatre variantes colorées.
- Un contenu conservé lorsque l'utilisateur change d'univers.
- Des primitives partagées pour le compte à rebours, le programme, la galerie et le RSVP.
- Des variations de rythme et de typographie sans dupliquer la logique métier.
Dupliquer les pages pour chaque univers ?
- Décision
- Partager les données et les comportements, puis injecter les choix visuels par configuration.
- Pourquoi
- Un nouveau thème enrichit la collection sans recréer l'authentification, le paiement, le RSVP ou les validations.
- Compromis
- Les invariants doivent être définis avec rigueur ; une liberté visuelle totale fragiliserait la maintenance.
Un produit pour le couple et pour ses invités
Une fois publié, le lien doit fonctionner comme une source de vérité : invitation, programme, informations pratiques et compte à rebours restent modifiables. L'invité accède au RSVP sans compte, peut ajouter un accompagnant et retrouve les changements sur le même lien.
Le produit prolonge ce lien après l'événement avec une galerie et des remerciements. Cette continuité évite de créer un second espace uniquement pour les souvenirs.
Faut-il demander un compte aux invités ?
- Décision
- Non : le RSVP est public depuis le lien reçu.
- Pourquoi
- L'invité accomplit une action ponctuelle ; créer un compte ajouterait une friction sans valeur pour lui.
- Compromis
- Le lien et les protections côté serveur doivent suffire à gérer l'accès et les réponses.
Que devient l'invitation après le mariage ?
- Décision
- Le même lien peut devenir une galerie de souvenirs et de remerciements.
- Pourquoi
- La valeur du produit suit le cycle réel de l'événement au lieu de s'arrêter le jour J.
- Compromis
- Le service doit gérer plusieurs états temporels et une durée d'accès plus longue.
Activation, confiance et delivery
La personnalisation est libre. Le paiement n'intervient qu'au moment d'activer et de partager le lien.
Le plan Mariage est un paiement unique de 150 € pour 12 mois. Le prolongement Souvenir ajoute 50 € et porte l'accès total à 18 mois. Ce modèle évite l'abonnement et rend le moment de monétisation cohérent avec la valeur : le lien devient réellement utile lorsqu'il est partagé.
Alzée est développé avec Next.js, React et TypeScript. La proximité entre design et code m'oblige à considérer chaque variation comme un coût de maintenance, de test et d'accessibilité — pas seulement comme une option visuelle.
Les principes WCAG 2.1 AA servent de cadre : navigation clavier, structure sémantique, libellés, reflow mobile et compréhension des états. Il s'agit d'un objectif de conception, pas d'une certification de conformité.
Quand faire payer ?
- Décision
- Au moment de publier et partager, après personnalisation et aperçu gratuits.
- Pourquoi
- L'utilisateur peut évaluer le résultat complet avant d'engager une dépense ; le prix est rattaché à l'activation d'un service concret.
- Compromis
- Une partie du coût de calcul et de conception est supportée avant conversion.
Abonnement ou paiement unique ?
- Décision
- Un achat de 150 €, puis un prolongement Souvenir optionnel de 50 €.
- Pourquoi
- Le besoin est lié à un événement borné dans le temps ; un abonnement récurrent serait plus difficile à justifier.
- Compromis
- Le revenu n'est pas récurrent et la durée d'hébergement doit être intégrée au prix.
Résultat, limites et apprentissages
Le résultat le plus solide est un produit complet en ligne, pas encore une preuve de croissance à grande échelle.
Alzée propose aujourd'hui treize univers publics, un configurateur en cinq étapes, une invitation mobile complète, un RSVP sans compte invité, un espace mariés et une activation par paiement unique. Treize invitations ont été créées au moment de cette mise à jour.
Je ne transforme pas ce volume en conclusion commerciale. Il montre que le parcours fonctionne de bout en bout, mais il reste insuffisant pour affirmer une adéquation marché, un taux de conversion ou une préférence utilisateur.
- Un aperçu réel réduit davantage l'incertitude qu'une longue explication de la personnalisation.
- Les options « plus tard » sont essentielles pour un produit utilisé pendant une organisation encore mouvante.
- Un système multi-thèmes tient lorsque les invariants de données et de comportement sont plus forts que les variations.
- La prochaine étape de recherche est d'observer des couples dans le configurateur et de mesurer les abandons par étape.
- L'espace authentifié, le paiement réel et les e-mails de service doivent encore faire l'objet d'une QA documentée avec davantage d'utilisateurs.