BookNest

Contexte

BookNest est une application de bureau pour cataloguer et suivre une bibliothèque personnelle — livres physiques et numériques mélangés : fiche détaillée par ouvrage, reconnaissance automatique à partir du code-barres ISBN, suivi de lecture, statistiques, liste d’envies avec alertes de sortie. Je l’ai conçue et pilotée seule, de l’idéation à la mise en production, en m’appuyant sur des outils d’IA pour les maquettes et l’implémentation. C’était au départ un outil strictement personnel et mono-utilisateur ; il a évolué depuis vers un produit multi-comptes. La déclinaison mobile, elle, était prévue dès la conception : j’ai choisi de consolider d’abord la version bureau — une fois cette base stable, le portage mobile pouvait démarrer sur des fondations saines.

Problème

Comment aider un lecteur à organiser, suivre et redécouvrir sa bibliothèque personnelle, sans que l’outil se transforme en base de données à remplir à la main ? Les solutions existantes sont soit trop orientées fichiers, soit trop lourdes pour un usage quotidien — et laissent peu de marge pour personnaliser vraiment son propre classement (genres, sous-genres, étiquettes). L’enjeu : une saisie quasi automatique (scan, sources bibliographiques multiples), un modèle de fiche assez riche pour être utile mais pas exhaustif par principe, une taxonomie que chacun façonne à sa manière, et un périmètre que je pouvais réellement tenir seule.

Mon rôle

Product Manager sur un projet solo : j’ai porté toutes les casquettes, de l’idéation à la mise en production. Cadrage à partir d’un brainstorm remis à plat, roadmap séquencée en douze phases avec un périmètre MVP distinct des évolutions V2, spécification du modèle de données (une vingtaine de champs, ajustés selon leur valeur d’usage réelle et non par exhaustivité), conception des écrans, pilotage de l’implémentation, triage des retours de test et documentation vivante des décisions — le raisonnement, pas seulement les specs finales.

Comment j’ai travaillé

En cycles courts : concevoir, implémenter, tester en conditions réelles, ajuster. Même en solo, le produit a été confronté à de vrais utilisateurs : d’abord moi et mon entourage en interne, puis un test externe — un développeur qui a utilisé l’application en conditions réelles, sans accès au code, et a repéré notamment un problème de sécurité. Les retours étaient systématiquement triés avant traitement, et les diagnostics menés par preuve plutôt que par hypothèse : quand un premier correctif ne suffisait pas, rendre visible la vraie valeur mesurée sur l’appareil concerné avant de retoucher quoi que ce soit. Suivi et raisonnement tracés en continu dans Notion et les journaux de projet. Côté outillage : implémentation pilotée de bout en bout avec Claude Code (dépôt GitHub, backend Supabase), visuels — maquettes, mascotte, illustrations — conçus avec Claude Design. Mon rôle restait de cadrer, spécifier, arbitrer et valider à chaque cycle ; l’exécution suivait des consignes que j’affinais au fil du projet.

Décision clé

Sur un produit que je construisais seule, il a fallu apprendre à trancher moi-même, sans personne pour valider — ni pour dire stop. Dès le choix de la stack technique, une recommandation externe complète (langage, outils, roadmap) m’avait été proposée ; plutôt que de l’appliquer telle quelle, je l’ai reprise point par point — accord, nuance ou désaccord argumenté — avant de décider. Ce même réflexe critique s’est retrouvé tout au long du projet, cette fois tourné vers moi-même : résister à l’accumulation de fonctionnalités, en n’ajoutant que ce qui répond à un usage réel et constaté. C’est ce qui m’a conduite à écarter pour l’instant la synchronisation Calibre, l’export PDF et les « Collections » — non par manque de temps, mais faute de valeur ajoutée démontrée face à l’existant (les tags, l’export tableur réexploitable). À chaque fois, la même question avant d’écrire la moindre ligne : est-ce que ça sert un usage réel, ou est-ce que je cède à l’envie d’en faire plus ? Sans bureau ni client pour arbitrer, rester objective sur un produit auquel je suis attachée a été l’exercice le plus exigeant du projet.

Résultat & évolution

Conçu au départ pour mon seul usage, BookNest suscite déjà l’intérêt de plusieurs personnes de mon entourage. Cette demande m’a amenée à introduire la gestion multi-compte et à préparer une version packagée en APK, pour qu’ils puissent l’utiliser à leur tour. En parallèle, j’explore des pistes pour améliorer la pertinence des résultats et la manière dont les données sont stockées. Le MVP desktop, neuf phases de la conception à la mise en production, a été audité écran par écran (chargement, erreur, cas limites) avant d’être déclaré en version 1.0.0. Trois sessions de test en conditions réelles plus tard — triées et traitées par priorité plutôt que dans l’ordre d’arrivée des retours — le produit s’est doté d’une suppression de compte pensée pour une diffusion plus large et d’une première version mobile qui réutilise la même base : 8 chantiers livrés et fusionnés. Le tout couvert aujourd’hui par plus de 900 tests automatisés, desktop et mobile confondus. Mener ce projet de bout en bout m’a fait entrer dans les outils techniques des développeurs — dépôt et CI, base de données et migrations, tests, gestion des environnements — et en mesurer de l’intérieur les contraintes et la complexité réelles. J’en retire une meilleure capacité à estimer ce que coûte vraiment une fonctionnalité, en temps, en argent et en énergie, et à en discuter concrètement avec une équipe de dev. BookNest continue d’évoluer au fil de l’usage réel plutôt que d’un plan figé.