Le choix de la stack technique est la décision la plus structurante quand on construit un SaaS. Elle conditionne la vitesse de développement, les performances, les coûts d'infrastructure, et la capacité à itérer rapidement. Un mauvais choix au départ, et vous passerez des mois à refactorer au lieu de construire des features.
Après plusieurs années à construire des produits SaaS en production, j'ai convergé vers une stack que j'utilise sur tous mes projets. Ce n'est pas la stack la plus populaire. C'est celle qui me permet de livrer le plus vite avec la meilleure qualité. Voici pourquoi, brique par brique.
Mes critères de choix
Avant de parler d'outils, il faut parler de critères. Chaque technologie que j'adopte doit cocher quatre cases, sans exception.
Performance
Le produit doit être rapide pour les utilisateurs finaux. Pas de compromis sur les temps de chargement, le Time to Interactive, ou la fluidité des interactions. Un SaaS lent, c'est un SaaS que personne n'utilise.
Developer Experience
Je dois pouvoir itérer vite. Hot reload instantané, typage fort, messages d'erreur clairs, documentation solide. Chaque seconde gagnée en DX se traduit en features livrées plus vite au client.
Maintenabilité
Le code doit rester lisible et évolutif dans 6 mois, dans 2 ans. Pas de magie noire, pas de conventions obscures. Un nouveau développeur doit pouvoir comprendre le projet en moins d'une journée.
Coût
Les startups n'ont pas de budget infra illimité. La stack doit tourner pour quelques euros par mois en phase de lancement, et scaler sans exploser la facture quand le trafic augmente.
Frontend — SvelteKit
SvelteKit est le pilier de ma stack. C'est un meta-framework fullstack basé sur Svelte, le framework frontend qui compile les composants en JavaScript vanilla au lieu de les interpréter avec un runtime lourd comme React ou Vue.
Pourquoi pas React/Next.js ? La question revient souvent, et la réponse est simple : la performance et la simplicité. React impose un Virtual DOM, un runtime de 40+ Ko, et un modèle de réactivité basé sur des hooks dont la complexité explose sur les gros projets (useEffect, useMemo, useCallback, les re-renders parasites...). Svelte compile directement en manipulations DOM chirurgicales. Zéro runtime. Zéro overhead.
Avec Svelte 5 et son système de runes ($state, $derived, $effect, $props), la réactivité est native et transparente. Pas besoin de mémoriser 15 patterns de hooks. On déclare un état, Svelte le traque automatiquement. Le résultat en production : des bundles 50 % plus légers et des scores Lighthouse systématiquement au-dessus de 95.
SvelteKit apporte le routing basé sur le filesystem, le SSR, le prerendering statique, les form actions, et un système de load functions qui sépare proprement le data fetching du rendu. Le mode hybride (certaines pages SSR, d'autres prerendered, d'autres SPA) est natif et ne demande aucune configuration complexe.
Résultat concret
Sur mes derniers projets SaaS, le passage de Next.js à SvelteKit a réduit la taille des bundles de 50 % et amélioré les scores Lighthouse de 40 points en moyenne. Le temps de développement a aussi diminué grâce à la syntaxe plus concise de Svelte.
Styling — UnoCSS
UnoCSS est un moteur CSS atomique qui fonctionne au moment de la compilation. Si vous connaissez Tailwind CSS, le concept est identique : des classes utilitaires (flex, p-4, text-red-500) composées directement dans le HTML. Mais UnoCSS va plus loin.
Pourquoi pas Tailwind directement ? Tailwind fonctionne bien, mais son processus de build est plus lourd. UnoCSS utilise un moteur de matching par regex qui est significativement plus rapide. Sur un gros projet, la différence se ressent sur le temps de build et surtout sur le hot reload en développement. UnoCSS génère uniquement les classes utilisées, à la demande, en quelques millisecondes.
Le preset Wind rend UnoCSS 100 % compatible avec la syntaxe Tailwind. Aucun apprentissage supplémentaire si vous venez de Tailwind. En bonus, le système de shortcuts UnoCSS permet de définir des composants de style réutilisables directement dans la configuration (comme btn-brutal ou card-brutal dans ce portfolio).
Runtime — Bun
Bun est un runtime JavaScript tout-en-un qui remplace Node.js, npm, et une partie des outils de build. Écrit en Zig et basé sur JavaScriptCore (le moteur de Safari), il est nativement optimisé pour la vitesse.
Les chiffres parlent d'eux-mêmes : l'installation des dépendances est 3 à 5 fois plus rapide qu'avec npm. Le démarrage des scripts est quasi instantané. Le bundler intégré rivalise avec esbuild. Et surtout, Bun est compatible avec 99 % de l'écosystème npm existant. La migration depuis Node.js se fait en changeant une commande.
En pratique, Bun accélère tout le workflow de développement. Le bun install passe en secondes au lieu de minutes sur les gros projets. Le bun run dev démarre le serveur de développement instantanément. C'est le genre de gain qui semble anecdotique mais qui, cumulé sur des centaines d'exécutions par semaine, fait une vraie différence sur la productivité.
3-5x
Install plus rapide
100%
Compatible npm
All-in-1
Runtime + PM + Bundler
Base de données — PostgreSQL + Drizzle
PostgreSQL n'a plus besoin d'être présenté. C'est la base de données relationnelle open source la plus fiable et la plus complète du marché. Transactions ACID, JSONB pour les données semi-structurées, full-text search natif, extensions comme pgvector pour l'IA : PostgreSQL couvre 99 % des besoins d'un SaaS sans jamais avoir besoin d'ajouter un outil supplémentaire.
Pour l'ORM, j'utilise Drizzle. Contrairement à Prisma qui génère un client lourd avec un query engine en Rust, Drizzle est léger, SQL-first, et offre une type-safety complète grâce à TypeScript. Les requêtes Drizzle se lisent comme du SQL, ce qui facilite le debug et l'optimisation. Le schéma est défini en TypeScript pur, et les migrations sont générées automatiquement.
Côté hosting, deux options selon le projet. Neon pour le serverless : scaling automatique, branchement de bases pour le dev/staging, et un tier gratuit généreux pour commencer. VPS (Hetzner) pour les projets qui ont besoin de performances prévisibles et d'un contrôle total. Un PostgreSQL sur un VPS à 4 €/mois gère confortablement des milliers d'utilisateurs actifs.
Authentification — Lucia / Auth.js
L'authentification est un sujet critique. La tentation est grande de déléguer à un service tiers comme Firebase Auth, Auth0, ou Clerk. Ces solutions fonctionnent, mais elles introduisent une dépendance forte sur un service externe, avec des coûts qui explosent à mesure que le nombre d'utilisateurs grandit.
J'utilise Lucia Auth (ou Auth.js selon les projets). Ce sont des bibliothèques open source, self-hosted, qui gèrent l'authentification directement dans votre base de données PostgreSQL. Sessions, OAuth (Google, GitHub, etc.), magic links, 2FA : tout est géré nativement, sans appel API externe.
Les avantages sont clairs : contrôle total sur les données utilisateur, conformité RGPD facilitée (les données restent chez vous), aucune limite de MAU (Monthly Active Users), et des performances optimales puisque tout reste dans votre infrastructure. Le coût marginal par utilisateur est pratiquement nul.
Comparaison de coûts
Auth0 facture environ 23 $/mois pour 1 000 MAU. A 10 000 MAU, on passe à 228 $/mois. Avec Lucia en self-hosted, le coût est de 0 $ quel que soit le nombre d'utilisateurs. Sur un SaaS en croissance, l'économie se chiffre en milliers d'euros par an.
Déploiement — Docker + VPS
Le déploiement est souvent le parent pauvre des choix techniques. Beaucoup de développeurs poussent vers Vercel ou Netlify par facilité. Ces plateformes sont excellentes pour les sites statiques, mais pour un SaaS avec base de données, workers, et cron jobs, la facture monte vite et le contrôle diminue.
Ma stack de déploiement repose sur trois piliers : Docker pour la conteneurisation, un VPS Hetzner pour l'hébergement, et Traefik comme reverse proxy.
Docker multi-stage builds
Chaque application est packagée dans une image Docker optimisée. Le multi-stage build permet de séparer l'étape de compilation (lourde, avec Bun + dépendances de dev) de l'image finale (légère, avec uniquement Nginx et les fichiers statiques). Résultat : des images de moins de 30 Mo et des déploiements en secondes.
VPS Hetzner
Un serveur dédié à 3-5 €/mois avec 2 vCPU, 4 Go de RAM, et 40 Go SSD. C'est largement suffisant pour faire tourner plusieurs SaaS en parallèle avec PostgreSQL, Redis, et les workers associés. Le rapport prix/performance est imbattable comparé aux services cloud managés.
Traefik + SSL automatique
Traefik gère le routage HTTP, le load balancing, et les certificats SSL Let's Encrypt automatiquement. La configuration se fait par labels Docker : il suffit de déclarer le domaine dans le docker-compose.yml et Traefik provisionne le certificat SSL, configure le redirect HTTP vers HTTPS, et route le trafic vers le bon conteneur. Zéro configuration Nginx manuelle.
CI/CD GitHub Actions
Chaque push sur main déclenche automatiquement le build Docker, les tests, et le déploiement sur le VPS via SSH. Le pipeline complet prend moins de 2 minutes. Pas de déploiement manuel, pas de risque d'oubli. Le code mergé est en production dans la foulée.
Coût total d'infrastructure
Pour un SaaS en production avec base de données, auth, monitoring, et SSL : environ 5-10 €/mois. A comparer aux 50-200 $/mois que coûtent les stacks cloud managées (Vercel Pro + PlanetScale + Auth0 + monitoring SaaS).
Monitoring
Un SaaS sans monitoring, c'est conduire de nuit sans phares. Vous ne savez pas si vos utilisateurs rencontrent des erreurs, si votre serveur approche de ses limites, ou si votre application est même accessible. Voici les trois outils que je déploie systématiquement.
Plausible Analytics
Alternative privacy-first à Google Analytics. Open source, self-hostable, conforme RGPD sans bandeau de cookies. Le script fait moins de 1 Ko (contre 45+ Ko pour GA4). On obtient les métriques essentielles (visiteurs, pages vues, sources de trafic, conversions) sans tracker les utilisateurs individuellement.
Sentry
Error tracking en temps réel. Chaque erreur JavaScript, chaque crash serveur est capturé automatiquement avec le contexte complet : stack trace, session utilisateur, actions précédentes. Sentry permet de diagnostiquer et corriger les bugs avant que les utilisateurs ne s'en plaignent. Le tier gratuit couvre largement les besoins d'un SaaS en lancement.
Uptime Kuma
Monitoring de disponibilité self-hosted. Vérifie toutes les 60 secondes que vos services sont accessibles et vous alerte par email, Discord, ou Slack en cas de downtime. Dashboard simple avec historique de disponibilité et temps de réponse. L'outil tourne dans un conteneur Docker sur le même VPS.
La stack complète en un coup d'oeil
| Couche | Technologie |
|---|---|
| Frontend | SvelteKit 2 + Svelte 5 |
| Styling | UnoCSS (preset Wind) |
| Runtime | Bun |
| Base de données | PostgreSQL + Drizzle ORM |
| Auth | Lucia / Auth.js |
| Déploiement | Docker + Hetzner + Traefik |
| Monitoring | Plausible + Sentry + Uptime Kuma |
Cette stack n'est pas figée dans le marbre. Elle évolue à mesure que l'écosystème progresse. Mais les principes qui la guident restent les mêmes : performance pour l'utilisateur, vélocité pour le développeur, contrôle sur l'infrastructure, et coûts maîtrisés.
Le résultat concret : je livre des SaaS complets en 6 à 12 semaines, avec des scores Lighthouse au-dessus de 95, une infrastructure qui coûte moins de 10 €/mois, et un code que n'importe quel développeur Svelte peut reprendre sans documentation spécifique. C'est la promesse d'une stack bien choisie.
Si vous voulez voir cette stack en action, consultez ma page Stack pour les détails techniques, ou parcourez mes projets pour des exemples concrets de SaaS construits avec ces technologies.