Un aquarium tient à l'équilibre de son eau. Le pH, la dureté, les nitrates, le CO2 dérivent lentement, sans prévenir, et le jour où on le remarque, ce sont souvent les poissons ou les crevettes qui l'ont payé. Le problème n'est pas de mesurer : tout le monde teste son eau. Le problème, c'est de repérer la dérive à temps et de savoir si un chiffre est bon ou non. La plupart des aquariophiles notent leurs tests dans un tableur qui ne les alerte de rien, ou dans de vieilles applications austères.

C'est ce problème que j'ai voulu régler. J'en ai fait une application : un suivi d'aquarium au design moderne, pensé pour être simple, qui transforme chaque test en un verdict clair par espèce, alerte quand un paramètre dérive, et conserve l'historique, les photos et l'évolution du bac. Autour de ce cœur, des fonctions qui donnent une raison de revenir : le suivi de reproduction, le budget, le journal de scape. Partir d'un problème qu'on vit soi-même et remonter jusqu'au produit : c'est cela, pour moi, la vision produit.

Je n'en ai pas écrit une seule ligne de code. C'est l'IA qui a tout tapé.

Et c'est pourtant là que j'ai le plus appris sur ce qui sépare une idée d'un produit.

Voir le produit

Un produit commence par un problème, pas par une liste de fonctions. Le mien tenait en une phrase : rendre lisible une eau qui dérive en silence. Tout le reste en découle. Transformer un test en verdict, prévenir avant la casse : ce ne sont pas des choix techniques, mais la traduction directe de ce problème.

L'un de mes concurrents les plus sérieux n'est pas une application : c'est un tableur. N'importe quel aquariophile note ses relevés dans un Google Sheet, gratuitement et sans limite. Inutile de rivaliser sur le nombre de fonctions, une feuille de calcul est infinie. Je ne peux me distinguer que sur ce qu'elle ne fera jamais :

  • lire une tendance d'un coup d'œil ;
  • se remplir en quelques secondes sur un téléphone ;
  • connaître les seuils propres à chaque espèce ;
  • suivre une reproduction.

Là où le tableur enregistre, le produit accompagne. Chaque fois que j'ai voulu ajouter une fonction « parce qu'elle serait bien », c'est cette feuille de calcul qui m'a rappelé à l'ordre : décider ce que l'on fait, et surtout ce que l'on ne fait pas, est une décision de produit.

Penser le modèle

Ce produit, je l'ai d'abord conçu pour moi. J'ai des aquariums, j'avais le problème, et le régler moi-même me plaisait. Il est ensuite devenu un terrain d'expérience : un endroit pour éprouver ma manière de travailler avec l'IA et la façon dont je conçois un produit, à commencer par son volet économique.

Car même un projet fait pour soi mérite qu'on regarde s'il tient debout. J'ai donc regardé les chiffres avant de m'emballer :

  • une application concurrente plafonne autour de huit mille installations, pas des millions ;
  • l'aquariophilie d'eau douce recule depuis une dizaine d'années, même si le nano et la crevette progressent ;
  • la disposition à payer reste modérée.

J'en ai tiré une conclusion sans me raconter d'histoire : ce sera un revenu d'appoint et une pièce de portfolio, pas un produit qui paie un salaire. L'avoir conçu pour moi d'abord rend ce plafond facile à assumer, et surtout utile : il fixe ce que j'y investis, le temps que j'y passe, le point où je m'arrête.

Le budget obéit à la même règle :

  • rien pour l'hébergement tant qu'il n'y a pas un client ;
  • rien pour la publicité tant que l'acquisition naturelle n'a pas prouvé qu'elle convertit ;
  • un prix pensé pour l'audience : un abonnement mensuel accessible pour lever la première barrière, un forfait annuel pour la fidélité, une formule à vie pour une niche qui se méfie des abonnements.

La dépense suit la preuve, jamais l'inverse.

Décider l'architecture

Reste la forme technique. C'est la partie à laquelle je tiens le plus, parce qu'elle touche au métier auquel je me destine : architecte cloud.

Je sais précisément ce que j'utilise, et pourquoi, sans en avoir écrit une ligne. Un front statique et Supabase derrière, pour m'appuyer sur une base Postgres, une authentification et des règles d'accès gérées plutôt que d'administrer un serveur. L'offre gratuite tant que le produit ne rapporte rien, avec un chemin tracé vers l'offre payante le moment venu. Une installation en PWA pour se passer des magasins d'applications au départ. J'ai voulu que les limites du modèle payant soient vérifiées dans la base, et pas seulement dans l'interface, car une barrière qui ne vit que dans le navigateur se contourne. Et j'ai regroupé tous les accès à la base en un seul point, pour qu'en changer un jour tienne en quelques lignes.

Aucun de ces choix ne relève de l'écriture du code : ce sont des décisions. Quels services, pour quelles raisons, avec quels compromis. Savoir ce que l'on assemble et pourquoi, c'est le cœur de ce métier.

Ce qui fait un produit

Une application de suivi d'aquarium ne changera pas le monde, et ce n'était pas le but. Elle m'aura appris l'essentiel : entre une idée et un produit, il y a un problème à comprendre, un modèle à peser, une architecture à décider. Sur ce projet, c'est cette partie du travail qui a été la mienne, et c'est aussi celle qui m'intéresse le plus.

Or ces trois gestes ne valent pas que pour un aquarium. Comprendre un besoin avant de le servir, vérifier qu'un projet tient économiquement, choisir des services et en assumer les compromis : c'est le quotidien d'un architecte, à toute échelle. Un petit produit est un bon terrain pour s'y exercer, sans filet et pour de vrai.

C'est la voie que je poursuis : l'architecture cloud. Un aquarium aujourd'hui, de plus grands systèmes demain, avec la même façon de penser.