Architecturer un SaaS moderne en 2026 : ce que j'aurais aimé savoir avant Cowri
Retour d'expérience concret sur les décisions techniques qui ont fait — ou failli faire — capoter mon SaaS fintech. Stack, infrastructure, IA, sécurité et pièges qui coûtent cher.
Quand j'ai commencé à coder Cowri, ma plateforme fintech pensée pour les petits commerçants du secteur informel béninois, je croyais que le plus dur serait le code. Je me trompais. Le plus dur, c'est de prendre les bonnes décisions **avant** d'écrire la première ligne. Voici, sans filtre, ce que 18 mois de développement m'ont appris.
1. Choisir sa stack, ce n'est pas choisir un framework
Beaucoup de développeurs débutants passent des semaines à comparer Next.js, Remix, TanStack Start ou SvelteKit. La vérité, c'est que ces choix pèsent 10 % de la réussite d'un SaaS. Les 90 % restants viennent de la façon dont vous structurez vos données, vos flux d'authentification, votre facturation, votre observabilité et votre expérience utilisateur.
Pour Cowri, j'ai choisi React + TanStack Start côté front, Supabase pour la base de données et l'authentification, et Cloudflare Workers pour l'edge runtime. Ce n'est pas la stack la plus tendance — c'est la stack qui me permet de dormir la nuit. Elle est stable, documentée, et me laisse me concentrer sur le produit.
2. Séparer clairement le domaine métier de la couche HTTP
C'est la leçon que j'ai apprise à la dure. Au début, mes fonctions Supabase mélangeaient logique métier et validation d'entrée. Résultat : impossible de tester unitairement quoi que ce soit, et chaque changement de contrat d'API cassait trois autres endroits.
Aujourd'hui, chaque brique métier vit dans un module pur, sans dépendance à HTTP, à la base ou au framework. Les server functions se contentent de valider l'entrée, appeler le domaine, et sérialiser la sortie. Cette discipline paie dès la troisième semaine.
3. Ne pas sur-ingénierier — mais anticiper la casse
Un MVP n'a pas besoin de microservices, de Kubernetes, ni de six queues Redis. Il a besoin de sortir. Mais un MVP qui explose au troisième client parce que vous n'avez pas prévu la moindre observabilité, c'est un MVP mort.
Le juste équilibre pour moi : monolithe simple, mais avec des logs structurés dès le jour 1, des metrics basiques (taux d'erreur, temps de réponse P95), et un système d'alerte email. Sentry en gratuit couvre 90 % des besoins.
4. L'IA n'est pas un produit — c'est une feature
Cowri intègre un assistant vocal pour aider les commerçants analphabètes à comprendre leur santé financière. Pendant deux mois, j'ai construit cet assistant comme le cœur du produit. Erreur. Personne ne payait pour "parler à une IA". Les gens payaient pour **comprendre où passait leur argent**.
J'ai réécrit le positionnement : Cowri est un outil de suivi financier, avec une interface vocale qui rend l'outil accessible. L'IA est devenue invisible, au service de la valeur. Résultat immédiat sur les conversions.
5. La sécurité, dès le premier commit
RLS activée sur toutes les tables, secrets jamais dans le code, HTTPS partout, validation stricte avec Zod sur chaque server function, rate-limiting sur les endpoints publics. Aucune de ces choses n'est optionnelle. Un SaaS qui fuite les données de ses clients ne se relève pas.
En résumé
Un SaaS moderne, ce n'est pas une stack magique. C'est une suite de décisions cohérentes, prises tôt, assumées longtemps. Commencez simple, restez rigoureux, et ne construisez que ce que vos utilisateurs vous demandent — même si votre ego voudrait construire autre chose.