Le problème et son origine
L'idée de Spooki n'est pas née devant un tableau blanc mais au lycée, pendant des soirées entre amis. À chaque fois, le même temps mort revenait : on cherchait quoi regarder, on ouvrait trois catalogues, on lisait des synopsis, et l'envie retombait avant même le générique. Surtout, la question que l'on se posait vraiment n'était jamais celle à laquelle répondaient les plateformes. Nous ne voulions pas seulement savoir quel film d'horreur regarder, mais lequel fait vraiment peur, et quel type de peur il provoque. Cette nuance change tout. Une note sur dix ne dit pas si un film fait peur, ni comment. C'est ce que Spooki devait arriver à dire.
L'intuition s'est précisée dans le métro, puis s'est transformée en un cahier des charges mental bien avant la première ligne de code. À cette époque, mon bagage technique était mince : du JavaScript acquis sur des bots Discord et des scripts d'automatisation, et du HTML. Une application mobile complète, avec un backend, une base de données et une distribution sur les stores, paraissait clairement hors de portée. Je m'y suis attaqué précisément parce que c'était difficile. Ce n'était ni un projet scolaire ni une commande, mais un terrain que je choisissais pour sa capacité à me faire progresser.
Il n'y a pas eu de méthode. J'ai appris la technique au fur et à mesure, quand j'en avais besoin. L'interface a toujours compté autant pour moi que la fluidité du défilement ou la qualité du rendu.
Le pari et la communauté
La vision initiale dépassait la seule application. J'imaginais un couple entre un outil de découverte et un Ciné-Club, une communauté de fans d'horreur qui se recommandent des films entre eux. L'angle communautaire n'était pas un ajout tardif, il structurait le projet dès l'origine : la valeur ne venait pas seulement d'un algorithme, mais aussi de personnes qui partagent le même goût et se font confiance pour signaler ce qui fait réellement peur.
Pour financer à la fois le développement et le Ciné-Club, j'ai lancé une campagne Ulule, clôturée le 11 décembre 2023. Le résultat : 474 euros collectés sur un objectif de 3 000 euros, pour 23 contributions. La campagne n'a donc pas été financée et aucun fonds n'a été perçu. Les écrans présentés aux contributeurs correspondaient au MVP React Native de l'époque, ce qui rendait la promesse concrète, sans suffire à convaincre à l'échelle visée.
Ma réponse à cet échec a défini la suite du projet : construire et livrer Spooki quand même, seul et en autofinancement, jusqu'à la publication sur les deux stores. Cette contrainte de moyens a imposé des choix sobres et peu de dépendances payantes, une discipline qui a durablement orienté l'architecture. L'angle communautaire, lui, n'a pas disparu : il a survécu dans le produit sous la forme de la recommandation par un score de frayeur alimenté par la communauté.
Le pivot React Native vers Flutter
J'ai commencé en React Native, logique pour un profil JavaScript, et j'ai vite eu un premier MVP qui marchait. Il a servi à valider le concept : le parcours de découverte tenait, et le problème méritait une vraie application.
Je suis perfectionniste, et je veux une application aussi fluide qu'une application native. Je repère les micro-saccades, les transitions qui accrochent, les listes qui ne défilent pas parfaitement, et ce sont ces détails qui font qu'on garde une application ou qu'on la supprime. Sur Android, en usage réel, le défilement et les animations n'étaient pas au niveau. Entre iOS et Android, c'était le jour et la nuit. Je manquais sans doute d'expérience pour bien optimiser, mais obtenir un rendu fluide sur Android avec React Native restait très difficile.
J'ai donc pris une décision coûteuse à court terme et rentable à long terme : réécrire l'intégralité du frontend en Flutter, dont le moteur dessine lui-même l'interface, ce qui offre un contrôle au pixel et une homogénéité entre iOS et Android. L'arbitrage était explicite : accepter une courbe d'apprentissage réelle et la perte du MVP existant, contre un plafond de qualité bien plus haut et une base de code unique, maintenable par une seule personne. À la même période, j'ai adopté TypeScript côté backend, pour porter la même exigence de rigueur du client jusqu'au serveur.
L'architecture full-stack
Toute la chaîne est tenue par une seule personne, du client mobile jusqu'à l'infrastructure. Le frontend est écrit en Flutter et Dart. Le backend repose sur Node.js, TypeScript et Express, avec Prisma comme ORM au-dessus d'une base MySQL.
Côté infrastructure, le service tourne sous Docker pour garantir la reproductibilité entre les environnements, Nginx assure le rôle de reverse proxy, et Cloudflare se place en frontal. L'application intègre par ailleurs de nombreuses APIs externes, ce qui a demandé un soin particulier sur la résilience des appels et la cohérence des données agrégées. L'ensemble reste volontairement classique et maîtrisable par une seule personne, ce qui est ici un objectif d'ingénierie et non un aveu de simplicité.
Industrialisation et livraison continue
La livraison est automatisée, ce qui est rarement le cas sur un projet personnel et constitue pourtant un multiplicateur de vitesse. GitHub Actions publie automatiquement les bêtas internes sur TestFlight pour iOS et sur le Play Store pour Android. Concrètement, un changement validé déclenche une distribution vers les testeurs sans intervention manuelle, ce qui supprime une source classique d'erreurs et de lenteur, et permet de tester un correctif sur appareil réel dans la foulée.
Au delà de la mécanique de déploiement, j'ai tenu une organisation Git professionnelle, même en travaillant seul. J'utilise des issues GitHub pour tracer le travail et des pull requests pour intégrer les changements, alors qu'un simple push sur la branche principale aurait suffi. Ce choix est délibératoire : il impose une traçabilité, force à formuler l'intention de chaque changement et crée un historique lisible que je peux relire, ce qui est précieux quand on reprend un projet après une pause.
Cette discipline reproduit volontairement les conditions d'une équipe, pour que le passage à un contexte collaboratif ne demande aucun changement d'habitude. C'est une preuve concrète de la manière dont je travaille, davantage que du produit lui-même.
Instrumentation et mesure du produit
J'ai instrumenté Spooki de bout en bout et je me suis construit un tableau de bord analytics maison, baptisé SPOOKI Analytics V4, sur Grafana. Il est alimenté par mes propres métriques backend, exposées depuis Node.js et MySQL, avec une observabilité assurée par Prometheus et Loki. L'objectif n'était pas de collectionner des courbes, mais de pouvoir répondre à des questions précises sur le produit : qui l'utilise, comment, et est-ce que la fonctionnalité cœur répond bien au besoin d'origine. Je mesure ainsi l'acquisition (inscriptions par jour et cumulées), l'engagement, la rétention, la répartition par plateforme, par langue et par version d'application, et surtout les préférences d'intensité de peur.
En septembre 2026, le dashboard compte 1 397 utilisateurs, 107 075 swipes, 4 639 films regardés, 3 026 notes et 19 898 films actifs au catalogue. Les inscriptions accélèrent : une trentaine par mois fin 2025, 123 en juillet 2026 et 130 en août. L'audience est francophone et internationale, majoritairement en France, mais aussi en Côte d'Ivoire, au Cameroun, au Canada, au Gabon, au Congo, aux États-Unis et au Royaume-Uni.
Le point le plus intéressant referme la boucle ouverte au lycée : la distribution des préférences montre qu'environ 57% des utilisateurs recherchent l'intensité de peur la plus élevée. La donnée valide donc le besoin qui a fondé le projet. Je tiens à être honnête sur la portée de tout cela : la valeur que je revendique n'est pas la taille de l'audience, encore modeste, mais la capacité à mesurer et la culture data-driven qui en découle. Le produit est jeune et mené en solo, je ne survends pas la traction et je ne mets pas en avant de métriques fragiles.
Les défis d'ingénierie
Le premier défi a été d'apprendre Flutter. Il m'a fallu plusieurs mois pour être à l'aise : la façon de construire une interface n'a rien à voir avec ce que je connaissais en JavaScript.
L'authentification a constitué un autre morceau important. Je n'en avais jamais implémenté, et c'était un vrai apprentissage backend, avec ses questions de sécurité, de gestion des sessions et des cas limites. Dans le même registre, concevoir un schéma de base de données solide et évolutif a demandé de penser au delà du besoin immédiat, pour ne pas me retrouver bloqué par mes propres choix quelques mois plus tard. La robustesse et la stabilité ont été un fil conducteur permanent : gérer les cas d'erreur partout, et penser en même temps aux utilisateurs, aux administrateurs, à l'évolutivité future et aux différents états du frontend.
Ce qui rend l'exercice tenable, c'est que je prends autant de plaisir au backend qu'au frontend. Ce qui me motive n'est pas une couche en particulier mais le résultat : chercher, comprendre, puis accomplir. Cette motivation est ce qui permet de tenir la distance quand il faut, seul, penser à tout à la fois.
Résultat et preuves
Spooki a été conçu et livré en solo, du prototype jusqu'à la publication sur les deux stores. C'est le point que je retiens en premier, parce qu'il résume la nature du projet : aller au bout, seul, d'une chaîne complète qui va de l'idée au client mobile installé. L'application affiche une note de 5,0 sur l'App Store, sur 10 avis, et je précise volontairement le volume pour ne pas laisser croire à une représentativité qu'il n'a pas.
En septembre 2026, le backend compte 1 397 utilisateurs, un chiffre lu dans mon propre dashboard. La marque est déposée à l'INPI et l'activité est portée par une micro-entreprise. Spooki a aussi été vu dans Télématin, sur France 2, en 2024.
Ce que ce projet montre, plus que ses chiffres, c'est que je peux concevoir, livrer et maintenir seul une application en production, même sans financement.