Pourquoi je construis plusieurs petites applications plutôt qu'une seule grosse
Sur la page d'accueil de ce site, on retrouve QuoiRegarder, QuoiManger, QuoiOffrir, Budget Planner, et bientôt Headache Tracker. Cinq applications séparées, chacune avec une seule fonction précise, plutôt qu'une super-application qui ferait un peu de tout. Ce n'est pas un accident — c'est une décision délibérée, qui vient directement de mon métier d'ingénieur en intégration.
Une fonction, un problème, une décision rapide
QuoiManger répond à une seule question: qu'est-ce qui est en spécial à l'épicerie cette semaine, et qu'est-ce que je pourrais cuisiner avec ça? QuoiRegarder répond à une autre: qu'est-ce qui vaut la peine d'être écouté ce soir? Chaque application a une portée assez petite pour être terminée, testée et corrigée en quelques semaines plutôt qu'en quelques années. Si l'idée ne trouve pas son public, la perte est limitée. Si elle fonctionne, elle continue d'exister sans traîner le poids de fonctionnalités inutilisées empruntées à un projet plus gros.
Ce que ça m'apprend, techniquement
Chaque application est aussi un prétexte pour toucher à une pile technique différente. Les applications web comme QuoiManger, QuoiOffrir et Budget Planner tournent en sous-domaine, avec leur propre déploiement. Headache Tracker, elle, est en React Native / Expo — un terrain complètement différent, plus proche de l'intégration mobile native que je connais déjà côté STB, mais avec ses propres contraintes (cycles de publication sur les stores, gestion des permissions, tests sur appareils réels via Expo Go avant même de songer à publier).
Multiplier les petits projets, plutôt que d'investir des mois dans une seule plateforme dès le départ, me permet de comparer directement ces approches — et de découvrir assez vite laquelle mérite vraiment d'être approfondie.
La discipline de garder les choses séparées
La tentation, une fois qu'on a deux ou trois applications qui fonctionnent, est de vouloir les fusionner « pour que ce soit plus pratique pour l'utilisateur ». Dans mon expérience en intégration de systèmes — où fusionner deux plateformes mal alignées peut prendre des mois et casser des choses qui fonctionnaient très bien séparément — je préfère résister à ce réflexe tant qu'il n'y a pas une vraie raison d'affaires de le faire. Chaque application mobile ou web sur ce site reste un produit autonome, avec son propre cycle de vie. Si un jour deux d'entre elles doivent vraiment être combinées, ce sera parce que les utilisateurs l'auront demandé — pas parce que c'était plus élégant sur papier.