Wishlist : Quand la tech résout un problème de famille

Chaque année, même scénario. Dès que les fêtes approchent, le groupe WhatsApp familial explose : "Qu'est-ce que tu veux pour Noël ?", "Attends, moi j'avais prévu de lui offrir ça…", "Mais tu voulais pas un pull ? Ah non, c'était l'année dernière."

Les solutions du marché existent. Listes Amazon, apps dédiées. Mais à chaque fois, avec son lot de compromis : créer un compte sur une plateforme tierce, se manger des pubs, dépendre d'un service qui ferme ou change ses conditions. Et surtout, le vrai problème : comment réserver un cadeau discrètement sans que le destinataire ne voie que c'est pris ?

Besoin simple. Récurrent. Concret. J'avais les compétences. J'ai construit.

Wishlist, conçue et déployée de A à Z. Le concept est volontairement limpide : chaque membre de la famille consulte les listes des autres et réserve un cadeau, sans que le destinataire puisse voir qui a pris quoi.

Le moteur de l'expérience, c'est la gestion des rôles : • Le visiteur parcourt les listes et réserve ce qu'il veut offrir • L'administrateur gère sa propre liste. Il ajoute ses idées, met des photos, précise prix et liens • Le super-administrateur crée et gère les comptes de toute la famille

J'ai aussi glissé un thème de Noël activable en un paramètre. Flocons de neige, couleurs chaudes. Parce que les petits détails qui font sourire, ça compte autant que le reste.

Deux briques distinctes qui communiquent via une API.

L'interface : Next.js et React. Cartes animées, navigation fluide, validation en temps réel sur les formulaires, confirmations sur les actions sensibles, design responsive. L'objectif : que ma mère s'y retrouve au premier clic.

Le serveur : une API Python construite avec FastAPI. Authentification sécurisée, gestion des droits par rôle, stockage des données, et un export CSV pour les administrateurs qui veulent récupérer leur contenu.

Le déploiement : tout vit dans des conteneurs Docker, orchestrés via Docker Compose, derrière un reverse proxy (Traefik + CrowdSec) qui gère le HTTPS et la protection contre les attaques. Auto-hébergé, autonome, solide.

Déployer une app pour sa famille, c'est s'offrir un groupe de beta-testeurs qu'aucune startup ne peut recruter : zéro complaisance, zéro bagage technique, et une franchise que les formulaires de feedback ne captureront jamais.

Trois semaines d'usage ont suffi. Trois retours. Trois itérations.

« Je n'arrive plus à me connecter, ton truc me dit mot de passe incorrect. » Deux jours après le lancement, la personne était bloquée à l'écran de login sans aucun recours. J'avais naïvement supposé que dans un cercle fermé, tout le monde retiendrait ses identifiants. Erreur. J'ai traité ça comme un bug d'expérience, pas comme un oubli utilisateur. Résultat : un flux complet de réinitialisation de mot de passe. Un produit "simple" ne dispense pas de couvrir les parcours d'échec.

« Mais on clique où pour voir ta liste ? » Mon premier design de navigation me semblait évident. Il ne l'était pas. Ce retour, formulé cash, par quelqu'un qui ne cherche pas midi à quatorze heures, m'a poussé à repenser entièrement le parcours de sélection des listes. Moins d'abstraction, plus de clarté. L'évidence du concepteur est rarement celle de l'utilisateur.

« C'est possible de préparer ma liste sans que les autres la voient tout de suite ? » Un cas d'usage que je n'avais pas anticipé. Pourtant parfaitement logique : certains voulaient remplir leur liste tranquillement avant de la rendre visible. J'ai ajouté une option de visibilité par liste. Simple à coder, décisif pour l'adoption.

Trois retours bruts, non sollicités, parfois en message vocal. Et chacun a produit une décision produit claire, priorisée et livrée. C'est ça, être user-centric.