Je ne suis pas ingénieure backend de formation. Je suis venue au développement par la pratique, parce que je n'avais pas le choix et parce que ça m'intéressait vraiment. Quand j'ai lancé Sunna Planner, j'ai pris des décisions d'architecture sans filet. Certaines étaient bonnes. D'autres m'ont coûté du temps, de l'argent, ou les deux. Voici ce que j'aurais aimé savoir avant.
1. Firebase est un accélérateur, pas une solution magique
Firebase m'a permis de lancer vite. Auth, Firestore, Storage, push notifications, tout est intégré et la courbe d'apprentissage est raisonnable quand on part de Flutter. Mais Firebase ne pardonne pas les mauvaises structures de données. Si tu modélises mal ta base Firestore dès le départ, tu paies deux fois le prix : en lectures inutiles et en refactoring douloureux plus tard. J'ai appris ça à mes dépens en v1 où mes requêtes étaient trop larges, trop fréquentes, et pas du tout indexées correctement.
2. Les règles de sécurité Firestore, on ne les improvise pas
Les security rules Firestore, c'est la partie que les tutos expliquent en deux lignes. En production, c'est une autre histoire. Une règle mal écrite peut exposer des données d'un utilisateur à un autre, ou bloquer des lectures légitimes sans aucun message d'erreur clair côté client. J'ai passé beaucoup de temps à comprendre les règles de sécurité et comment bien les rédiger. Et ce n'est pas optionnel, c'est la première ligne de défense de toute l'architecture.
3. Les coûts cloud arrivent toujours plus tôt qu'on ne le pense
GCP et Firebase ont une logique de facturation fine. Au début, tout semble gratuit ou presque. Puis un pic d'utilisation, une mauvaise requête en boucle, une Cloud Function mal optimisée, et la facture change de dimension. J'ai mis en place des alertes budget dès la création de ma base de donnée, ce qui évite les mauvaises surprises. Mais la vraie leçon c'est qu'on ne peut pas surveiller les coûts a posteriori. Il faut les anticiper dans l'architecture elle-même.
Exemple concret : Une Cloud Function déclenchée chaque minute pour lire les docs Firestore. En théorie c'est propre mais en pratique c'est très coûteux dès que le nombre d'utilisateurs augmente. Solution toute bête, cette Cloud Function n'est utile que pour les Premium Users, j'ai filtré pour ne remonter que les utilisateurs premium. Résultat: coût divisé par trois.
4. Versionner son schéma de données, c'est non négociable
Quand on est seule sur le produit, on a tendance à faire confiance à sa mémoire. Mauvaise idée. Un schéma Firestore évolue vite, surtout entre deux versions majeures. Si tu n'as pas de documentation à jour de la structure de tes collections, tu passes un temps fou à reconstruire le contexte avant chaque modification. Et quand tu intègres de l'IA ou des automatisations, un schéma flou devient un vrai problème opérationnel.
5. Le backend, ça se teste avant que ça casse
Les tests sur une app solo, c'est souvent la première chose sacrifiée sur l'autel de la vitesse. Je l'ai fait. Et j'ai payé. Pas forcément avec des bugs catastrophiques, mais avec du temps perdu à déboguer des régressions qui auraient été détectées en cinq minutes avec un test bien écrit. Sur Firebase, les emulators locaux changent vraiment la donne : tu testes Auth, Firestore et Functions sans toucher à la prod. C'est le minimum viable pour ne pas casser ce qui marche à chaque déploiement.
Pour aller plus loin sur les décisions techniques qui structurent un produit solo, j'en parle aussi dans ce que le digital m'a vraiment appris.
Conclusion
Le backend, quand on est solo, c'est une dette silencieuse si on ne le prend pas au sérieux dès le départ. Pas besoin d'être expert. Il faut juste modéliser lentement, idéalement avoir une vision sur le moyen/long-terme, documenter au fil de l'eau, et tester avant de déployer. Le reste s'apprend en faisant.