Développement SaaS : du MVP à la plateforme en production

Que comprend le développement SaaS, au-delà des fonctionnalités ?

Un produit SaaS a deux parties : les fonctionnalités pour lesquelles les clients paient, et la plateforme qui permet à de nombreux clients de les utiliser en même temps, en toute sécurité. La plateforme couvre l’isolation des clients, l’inscription et la gestion des équipes, les abonnements et la facturation, une API publique, les outils d’administration, la supervision et un processus de mise en production. La première année, elle représente souvent autant de travail que les fonctionnalités, et c’est la partie la plus coûteuse à ajouter après coup. Nous concevons les deux dès le départ et ne construisons que la part de plateforme dont l’étape actuelle a besoin.

Du MVP à la production : les étapes

Étape	Objectif	Ce qui existe à la fin
Découverte	Trouver l’hypothèse la plus risquée et le plus petit produit qui la teste	Périmètre, note d’architecture, modèle de multi-tenancy et de tarification
MVP	De vrais utilisateurs sur de vraies données	Inscription, workflow principal, facturation, suivi des erreurs, sauvegardes
Production	Des clients payants qui en dépendent	Rôles, journal d’audit, API publique, console d’administration, supervision, revue de sécurité
Montée en charge	Grandir sans jouer les pompiers	Files de tâches, cache, limites par client, budgets de performance, procédures pour le service de piquet

Un MVP est réduit en périmètre, pas en qualité. L’authentification, l’isolation des clients et la journalisation en font partie dès la première version, car les ajouter plus tard oblige à toucher chaque requête et chaque écran.

Les décisions d’architecture que nous prenons tôt

Modèle de multi-tenancy. Base partagée avec une colonne client, un schéma par client ou une base par client. Nous commençons en général par une base PostgreSQL partagée et appliquons l’isolation avec la sécurité au niveau des lignes : un filtre oublié dans le code de l’application ne peut pas exposer les données d’un autre client. La conception permet de déplacer plus tard un grand client vers une base dédiée si un contrat l’exige.

Identité et accès. Des sessions pour l’application web, des clés API à portée limitée pour les intégrations et des jetons signés de courte durée (RS256) lorsque le produit est intégré dans une autre plateforme. Les droits sont vérifiés dans le backend à chaque requête.

Facturation. Le prestataire de facturation fait foi pour les paiements ; votre produit fait foi pour ce que chaque formule autorise. Des webhooks à signature vérifiée synchronisent les deux, et aucun accès n’est jamais accordé sur la seule base d’une redirection du navigateur.

L’API d’abord. Une API REST versionnée avec un document OpenAPI, une pagination par curseur et des clés d’idempotence sur les requêtes d’écriture. Pour les produits que des agents IA doivent pouvoir utiliser, un serveur MCP en lecture seule complète l’API.

Des fonctions d’IA avec des limites. Lorsque le produit appelle des LLM, nous ajoutons des plafonds de coût par client, une validation des réponses du modèle, un fournisseur de secours et, pour chaque appel, un enregistrement du modèle, de la version du prompt, des tokens et du coût.

Ce qui dérape entre le MVP et la production

• Des données visibles d’un client à l’autre. Évité par une isolation au niveau de la base et des tests automatisés qui tentent des lectures croisées.
• Une facturation désynchronisée. Un webhook manqué laisse l’accès à un client résilié, ou le retire à un client qui paie. Des traitements idempotents et un rapprochement quotidien comblent l’écart.
• Des voisins encombrants. L’import massif d’un client ralentit tous les autres. Des files de tâches de fond et des limites de débit par client le contiennent.
• Un support à l’aveugle. Sans console d’administration ni identifiants de requête dans les journaux, chaque ticket devient un jeu de devinettes.
• Des webhooks qui échouent sans bruit. Nous signons chaque envoi sortant, relançons avec un délai progressif et désactivons les destinataires qui échouent en continu, en expliquant la raison au client.

Sécurité et conformité

Nous utilisons l’OWASP Application Security Verification Standard (ASVS) comme checklist de mise en production et suivons les pratiques du NIST Secure Software Development Framework (SP 800-218) : revue de code, analyse statique et détection de secrets dans la CI, et un processus de mise en production documenté. La LPD révisée s’applique aux données personnelles traitées en Suisse. Le RGPD s’applique dès que vous proposez le produit à des personnes dans l’UE, et le règlement européen sur l’IA peut viser les fonctions d’IA dont les résultats y sont utilisés. Nous concevons les flux de données, la liste des sous-traitants et l’hébergement (en Suisse ou dans une région de l’UE) pour que vos réponses aux questionnaires de sécurité de vos clients soient exactes.

Qu’est-ce qui détermine le coût et les délais ?

Facteur	Effet sur l’effort
Multi-tenancy et isolation	Des bases dédiées ou un hébergement régional par client ajoutent du travail de développement et d’exploitation.
Modèle de facturation	Licences par utilisateur, facturation à l’usage, périodes d’essai et taxes ajoutent chacune des règles et des cas particuliers.
Intégrations	Chaque système tiers apporte sa propre authentification, ses limites et ses modes de défaillance.
Fonctions d’IA	Conception des prompts, évaluation et contrôle des coûts s’ajoutent à la fonction elle-même.
Exigences des grands comptes	Authentification unique, exports d’audit et revues de sécurité arrivent avec les clients plus importants.
MVP existant	Remplacer un prototype ou une base no-code demande une migration des données et une exploitation en parallèle.

Après la phase de découverte, nous chiffrons le MVP comme un projet à périmètre fixe, puis planifions les étapes suivantes selon ce qu’il vous apprend. Les étapes et une checklist de mise en production sont détaillées dans notre article du MVP à la production.

Comment il s’intègre au reste de l’entreprise

Un produit SaaS a besoin d’un système commercial autour de lui. Les essais et les inscriptions alimentent l’automatisation du CRM et des ventes. Les e-mails de prise en main, de facturation et d’usage passent par l’automatisation des e-mails. Les données du produit s’échangent avec les outils de vos clients grâce aux intégrations API.

Pourquoi Sensaria

Nous développons des plateformes de ce type. L’annuaire d’API de communication que nous avons développé publie une API REST publique avec un document OpenAPI, ainsi qu’un serveur MCP en lecture seule ; les requêtes en texte libre passent par un analyseur déterministe plutôt que par un LLM, si bien qu’une même question obtient toujours la même réponse. Pour un client, nous avons développé un produit multi-tenant avec la sécurité au niveau des lignes de PostgreSQL, des webhooks sortants signés avec relances et désactivation automatique, et un widget intégrable authentifié par des jetons de courte durée. Sensaria AG est basée à Lugano, en Suisse, et travaille en français, en allemand, en italien et en anglais.