Choisir sa stack technique SaaS en 2026

Les fondateurs passent des semaines sur le choix de leur stack, et généralement sur les mauvaises décisions. Le débat sur les frameworks est bruyant, distrayant et presque sans importance. Les décisions qui déterminent vraiment si le produit sera agréable ou pénible à faire évoluer dans deux ans se prennent en une après-midi, souvent par défaut.

La bonne façon de trier : laquelle de ces décisions puis-je changer plus tard sans réécrire le produit ?

Les trois qu'on ne peut pas revenir en arrière

1. Votre modèle de données

Pas « quelle base de données », mais la forme de vos données. Quelles sont les entités centrales, comment elles se relient, ce qui est obligatoire.

C'est celle qui fait mal. Chaque ligne de code applicatif, chaque requête, chaque intégration et chaque migration suppose la forme que vous avez choisie. En changer plus tard revient à toutes les changer en même temps, sur des données de production que vous ne pouvez pas perdre.

Consacrez-y du temps réel. Esquissez les entités avant d'écrire du code, et demandez-vous précisément ce qui se passe quand un client veut deux exemplaires de ce que vous aviez supposé unique — deux établissements, deux marques, deux devises. Cette question prédit la plupart des migrations coûteuses.

2. Votre modèle de multi-tenant

Comment vous séparez les données d'un client de celles d'un autre : tables partagées avec une colonne de tenant, un schéma par client, une base par client.

Cela touche chaque requête que vous écrirez. Rétro-installer l'isolation dans un système conçu pour un seul client relève quasiment de la réécriture, et c'est ainsi qu'une application qui fonctionnait bien se met à laisser fuiter des données entre comptes.

Pour la plupart des SaaS B2B, une base partagée avec une colonne de tenant et un filtrage strictement appliqué est le bon choix, et tient bien plus longtemps qu'on ne le croit. Optez pour une isolation plus lourde quand la conformité l'exige — délibérément, pas par accident.

3. L'identité et les permissions

Qui est un utilisateur, ce qu'est un compte, comment les deux se relient, et ce qu'un rôle a le droit de faire.

Le piège consiste à modéliser un utilisateur par compte parce que c'est le cas simple. Puis votre premier vrai client demande à inviter son équipe, et la notion d'organisation doit être insérée sous tout ce que vous avez déjà construit. Modélisez utilisateurs, organisations et adhésions comme trois choses distinctes dès le premier jour — même si l'interface n'affiche qu'un seul utilisateur pendant des mois.

Tout le reste coûte moins cher que le débat à son sujet

Framework, styles, hébergement, CI, bibliothèque de composants, gestion d'état, monorepo ou non. Chacun de ces choix est remplaçable en quelques jours ou semaines par une équipe compétente. Ils génèrent le plus de débats et en méritent le moins.

Choisissez avec deux critères :

1. Que peut maintenir votre équipe ? La même logique que pour React Native ou Flutter : une stack que personne ne veut assumer est la plus coûteuse, quels que soient ses benchmarks.
2. Qu'est-ce qui est ennuyeux ? Préférez une technologie avec dix ans de questions déjà résolues à une nouveauté de six mois dotée d'une belle page d'accueil. Votre budget de nouveauté doit aller au produit, pas à la plomberie.

Ce que nous utilisons par défaut, et pourquoi ce n'est pas une prescription

Par transparence, pas par prescription : TypeScript de bout en bout, Next.js, PostgreSQL, une plateforme managée pour l'hébergement et les tâches de fond, et des solutions achetées pour l'authentification, les paiements et l'e-mail.

Le raisonnement n'est pas que ce sont les meilleurs outils dans l'absolu. C'est qu'un seul langage sur toute la stack supprime une catégorie de bugs et de changements de contexte, que Postgres est ennuyeux exactement comme on veut qu'une base le soit, et que les briques managées évitent que quelqu'un passe son temps à maintenir de l'infrastructure au lieu de construire le produit.

Si la force de votre équipe est Django, Rails ou .NET — construisez avec ça. Une stack que votre équipe connaît en profondeur bat une stack à la mode qu'elle apprend à vos frais, à chaque fois.

À acheter, pas à construire

Authentification, paiements et facturation par abonnement, e-mails transactionnels, analytics, suivi d'erreurs, stockage de fichiers. Chacun est un problème résolu avec des options matures, et chacun demande étonnamment de travail à faire correctement — la facturation surtout, une fois pris en compte le prorata, les échecs de paiement et les relances.

Les redévelopper n'est pas un exploit technique : ce sont des semaines passées à arriver là où vous auriez pu commencer. Elles se prennent directement sur votre délai de développement.

En résumé

Débattez du modèle de données, du modèle multi-tenant et du modèle d'identité jusqu'à être sûr de vous. Puis choisissez des outils ennuyeux, bien supportés et déjà connus de votre équipe pour tout le reste, et mettez-vous au travail.

Si une décision de stack demanderait deux semaines à un bon ingénieur pour être annulée, elle ne mérite pas deux semaines de débat.

Si vous voulez un second avis sur les trois qui comptent avant de vous engager, c'est la conversation que nous préférons. Découvrez notre approche du développement SaaS, ou contactez-nous.