Quelle base technique pour développer son SaaS ?

« On développe avec quoi ? » est souvent la première question technique d’un porteur de projet SaaS. C’est une bonne question, mais posée trop tôt elle produit de mauvaises réponses : on choisit une technologie parce qu’elle brille, pas parce qu’elle résout le problème. Remettons les choses dans l’ordre : d’abord les approches possibles, ensuite les critères, et seulement à la fin les noms de technologies.

Quelles sont les trois façons de construire un SaaS ?

Partir de zéro (from scratch). Chaque brique est développée pour votre produit. Liberté totale, mais tout est à construire : authentification, gestion des comptes, droits, facturation, administration, monitoring. Comptez plusieurs semaines de développement avant la première fonctionnalité qui vous différencie : sur un MVP à budget serré, c’est du temps pris sur ce qui compte.

S’appuyer sur un socle applicatif. Un socle applicatif est une fondation logicielle éprouvée qui fournit d’emblée les briques génériques de tout SaaS (comptes, droits, API, administration), sur laquelle le développement se concentre exclusivement sur votre métier. C’est notre approche : nos projets reposent sur FastEdgy, notre socle open source, ce qui explique qu’un MVP sorte en 6 à 12 semaines sans sacrifier l’architecture.

Assembler du no-code. Rapide pour valider une hypothèse de marché, limité pour durer : volumes plafonnés, expérience utilisateur générique, logique prisonnière de la plateforme. Un vrai outil de test, rarement une fondation de produit commercialisé. Nous avons détaillé quand le no-code suffit et quand il sature dans un article dédié.

Les quatre critères qui doivent décider

Un critère est volontairement absent de ce tableau : la popularité de la technologie. Les frameworks à la mode changent tous les deux ans ; votre SaaS, lui, devra être maintenu, recruté et faire évoluer pendant cinq à dix ans. La question utile n’est pas « qu’est-ce qui est moderne ? » mais « qu’est-ce qui sera encore maintenu, documenté et recrutable dans cinq ans ? ».

Notre réponse, et pourquoi elle est vérifiable

Chez Krafter, la stack est la même pour nos produits et pour ceux de nos clients : Vue.js pour les interfaces web, Flutter pour le mobile (une seule base de code pour iOS et Android), Python côté serveur, PostgreSQL pour les données, le tout sur notre socle open source FastEdgy.

Ce choix n’a rien d’idéologique, il est empirique : cette stack fait tourner Melimelo, Trottr, Kascade et Smashr, avec 25 000 utilisateurs quotidiens. Montées de version, pics de charge, années de maintenance, intégrations tierces : les problèmes que votre SaaS rencontrera, nos produits les ont déjà rencontrés, et les solutions sont déjà dans le socle.

La propriété suit la même logique. La surcouche métier développée pour votre produit vous appartient intégralement : code source à votre nom, propriété intellectuelle transférée. Le socle étant open source, aucune clause ne vous retient : vous pouvez reprendre le code, changer de prestataire, internaliser. Contrairement au no-code, où votre logique appartient de fait à la plateforme, ici la dépendance est nulle par construction.

Comment décider pour votre projet ?

Trois situations types, trois réponses :

1. Vous testez un marché, budget minimal, aucune certitude. Commencez par du no-code ou un MVP au périmètre serré : l’important est la vitesse d’apprentissage, pas la perfection technique. Documentez ce que vous apprenez, c’est votre future spécification.
2. Vous lancez un produit destiné à être commercialisé. Socle applicatif éprouvé, architecture pensée pour durer dès la V1, périmètre discipliné. C’est le cœur de notre offre de développement SaaS : 12 000 à 30 000 € HT pour un MVP en production.
3. Vous avez déjà un produit qui plafonne (no-code saturé, prototype devenu ingérable, V1 d’un autre prestataire). La question n’est plus la stack mais la reprise : audit de l’existant, plan de transition, et souvent une réécriture du cœur sur fondations saines. Ça se cadre au cas par cas, honnêtement.

Dans les trois cas, le choix technique découle du stade et du produit, jamais l’inverse. C’est une conversation de 30 minutes avec quelqu’un qui a déjà fait ces choix et vécu leurs conséquences en production : on vous la propose, sans engagement, et vous repartez avec une recommandation argumentée même si elle ne passe pas par nous.