La technologie évolue constamment. De nouveaux frameworks apparaissent chaque année, des outils deviennent obsolètes, et les tendances vont et viennent. Mais après avoir travaillé sur de vrais systèmes en production pour des startups, des plateformes e-commerce, des outils internes et des services basés sur l'IA, j'ai appris que ce qui compte vraiment n'est pas la nouveauté, mais la fiabilité.
Ma stack actuelle est le résultat d'années d'itération, d'erreurs, de refactorisations et de systèmes fonctionnant sous de vraies contraintes métier. Elle n'est pas conçue pour impressionner sur une landing page. Elle est conçue pour survivre à la croissance, aux exigences changeantes, aux nouveaux développeurs qui rejoignent le projet, et à la complexité inévitable qui accompagne tout produit SaaS sérieux.
Cet article explique comment et pourquoi je structure ma stack technique de cette façon aujourd'hui.
Choisir délibérément des technologies ennuyeuses
Quand on construit des produits SaaS assez longtemps, on commence à valoriser la prévisibilité plutôt que l'excitation.
Au début de ma carrière, j'ai beaucoup expérimenté : différents frameworks, bases de données exotiques, nouveaux paradigmes, outils non éprouvés. Certains ont fonctionné. Beaucoup ont créé des frictions inutiles par la suite : mises à jour difficiles, manque de documentation, vivier de recrutement limité, ou bugs subtils en production difficiles à diagnostiquer.
Aujourd'hui, je choisis délibérément des technologies qui sont :
- bien comprises
- largement adoptées
- ennuyeuses en production
- faciles à débugger
- faciles pour recruter
- supportées pendant des années
Cela ne ralentit pas les projets. Cela les accélère sur le long terme.
Backend : la stabilité d'abord, la flexibilité ensuite
Côté backend, la plupart de mes projets SaaS reposent sur Node.js avec TypeScript.
Pas parce que c'est à la mode, mais parce que cela offre un excellent équilibre entre vitesse de développement, maturité de l'écosystème et maintenabilité à long terme.
TypeScript seul a changé ma façon de construire des systèmes. Il transforme les grandes bases de code en quelque chose qu'on peut raisonner. Il rend le refactoring plus sûr. Il impose de la clarté dans les modèles de données et les contrats d'API. Et quand plusieurs développeurs collaborent sur le même backend, il devient une forme de documentation vivante.
Pour les APIs, je construis généralement des services REST classiques avec Express ou Fastify. Je préfère des endpoints explicites et des contrats clairs plutôt que des architectures trop abstraites. Quand les systèmes grandissent, la simplicité devient une forme de scalabilité.
Pour l'accès aux données, je m'appuie fortement sur Prisma. Il fournit un typage fort, des schémas lisibles, des migrations sûres, et un bon équilibre entre abstraction et contrôle. La base de données sous-jacente est le plus souvent PostgreSQL, parfois MySQL selon l'historique du projet ou les contraintes d'hébergement.
Redis est fréquemment ajouté quand le produit grandit : pour le caching, les jobs en arrière-plan, les files d'attente, le rate limiting, ou l'état partagé de type session. C'est simple, rapide et extrêmement fiable quand c'est utilisé correctement.
Cette stack backend me permet de concevoir des systèmes faciles à étendre, faciles à débugger et faciles à opérer.
Frontend : la clarté plutôt que l'astuce
Côté frontend, je travaille principalement avec React et TypeScript.
Ici encore, le choix est pragmatique. React n'est pas parfait, mais son écosystème est massif, stable et bien compris. Quand un client veut recruter des développeurs supplémentaires plus tard, trouver des ingénieurs React est trivial. Cela seul compte beaucoup pour les projets à long terme.
TypeScript côté frontend apporte les mêmes bénéfices que côté backend : moins d'erreurs à l'exécution, des refactorisations plus sûres et des interfaces de composants plus claires.
Pour le styling et la structure UI, je m'appuie généralement sur Tailwind et shadcn/ui. Ils me permettent de construire des interfaces cohérentes rapidement sans introduire de design systems lourds ou d'architectures CSS complexes qui deviennent difficiles à maintenir.
Dans les dashboards SaaS, les outils internes et les panneaux d'administration, la simplicité visuelle bat la complexité. Ce qui compte, c'est que l'UI reste prévisible, rapide et compréhensible même quand les fonctionnalités s'accumulent.
Je porte une attention particulière à :
- des composants pilotés par l'API
- une séparation claire entre UI et logique métier
- des flux d'état prévisibles
- le lazy loading et le code splitting quand c'est pertinent
- des patterns de design cohérents
Ces détails apparaissent rarement dans les captures d'écran marketing, mais ils déterminent si le frontend reste gérable deux ans plus tard.
Infrastructure : la reproductibilité plutôt que l'héroïsme
L'infrastructure est là où beaucoup de projets SaaS échouent silencieusement.
Pas parce que les serveurs sont lents, mais parce que les déploiements deviennent stressants, les environnements divergent, et personne n'est vraiment sûr de comment le système fonctionne réellement.
Pour cette raison, tout ce que je construis tourne dans Docker.
Développement, staging, production : les mêmes containers, la même structure de configuration, le même processus de démarrage. Cela réduit drastiquement le problème "ça marche sur ma machine" et rend l'onboarding des nouveaux développeurs beaucoup plus facile.
Pour les déploiements, je m'appuie sur des pipelines CI/CD qui buildent, testent et déploient automatiquement. Que ce soit GitHub Actions, Coolify ou des pipelines personnalisés, le principe reste le même : l'intervention humaine doit être minimale.
Selon le projet, j'utilise des fournisseurs cloud classiques ou de l'infrastructure auto-hébergée. Dans certains produits SaaS, la simplicité du cloud est parfaite. Dans d'autres, le contrôle des coûts, la confidentialité des données ou l'utilisation de GPU rend l'auto-hébergement plus sensé.
L'important n'est pas où les serveurs tournent, mais que :
- les déploiements soient reproductibles
- les rollbacks soient possibles
- les environnements soient isolés
- la configuration soit externalisée
- les secrets soient gérés correctement
Si déployer fait peur, quelque chose ne va pas.
Pourquoi cette stack fonctionne bien pour le SaaS
Cette stack n'est pas optimisée pour des projets de démo ou des expériences éphémères. Elle est optimisée pour des produits qui doivent survivre à une vraie utilisation.
Elle scale bien techniquement, mais plus important encore, elle scale organisationnellement :
- les nouveaux développeurs peuvent comprendre la codebase rapidement
- les bugs peuvent être diagnostiqués sans conjecture
- les fonctionnalités peuvent être ajoutées sans peur
- l'infrastructure peut croître graduellement
J'ai utilisé des variations de cette stack pour :
- des plateformes e-commerce multi-boutiques
- des systèmes d'automatisation logistique et d'entrepôt
- des outils d'administration Shopify
- des services SaaS alimentés par l'IA
- des dashboards internes d'entreprise
- des plateformes financières et analytiques
Dans tous ces cas, les choix techniques sont passés en arrière-plan, ce qui est exactement ce qu'on veut. Le produit devient le focus, pas la technologie.
S'adapter aux écosystèmes existants
Bien sûr, tous les projets ne partent pas de zéro.
Beaucoup de clients ont déjà une codebase existante, des bases de données différentes ou des contraintes d'infrastructure spécifiques. Dans ces cas, je m'adapte.
Je suis à l'aise pour travailler avec d'autres frameworks, ORMs, fournisseurs cloud ou modèles de déploiement. Ce qui compte pour moi n'est pas d'imposer mes outils favoris, mais de maintenir les mêmes principes : clarté, sécurité, reproductibilité et maintenabilité à long terme.
Une stack façonnée par la production, pas par les tendances
Chaque décision technique majeure dans cette stack vient de vrais problèmes que j'ai rencontrés en production :
- des systèmes impossibles à débugger
- des bases de données devenues des goulots d'étranglement
- des frontends que plus personne n'osait toucher
- des déploiements qui cassaient aléatoirement
- des produits bloqués par des raccourcis précoces
Chaque échec a affiné ma façon de travailler aujourd'hui.
Mon objectif est simple : construire des systèmes qui deviennent ennuyeux à opérer.
Quand personne n'a peur de déployer un vendredi après-midi, quand ajouter une fonctionnalité ne nécessite pas de toucher dix modules non liés, quand les logs expliquent clairement ce qui s'est mal passé, alors la stack fait son travail.
Travailler avec cette stack
Si vous construisez un produit SaaS, une plateforme interne ou une startup technique et que vous vous souciez autant de la stabilité à long terme que de la vitesse à court terme, c'est le type d'environnement avec lequel je travaille habituellement.
Je collabore avec des clients en France et à l'international en tant que développeur full-stack freelance, agissant souvent à la fois comme ingénieur senior et lead technique, aidant à concevoir des systèmes faits pour durer plutôt que des prototypes faits pour être jetés.
Si cet état d'esprit résonne avec votre projet, cette stack lui conviendra probablement aussi.