Développer un SaaS : architecture, abonnements et exploitation

Le logiciel en tant que service, ou SaaS, est défini par le NIST américain comme un logiciel fourni par un prestataire et utilisé par ses clients au travers d'internet, sans qu'ils gèrent l'infrastructure qui le fait tourner. Pour celui qui le construit, cette définition cache trois exigences : servir plusieurs clients avec un seul logiciel sans jamais mélanger leurs données, facturer de façon récurrente, et exploiter le service en continu.

Ce guide s'adresse aux porteurs de projet, éditeurs de logiciels et entreprises qui veulent transformer un savoir-faire en produit. Il ne parle pas de prix : les repères de marché sont dans la page combien coûte un SaaS. Il parle des décisions qui déterminent ce budget et la solidité du produit.

Valider avant de développer

Le risque principal d'un SaaS n'est pas technique. C'est de construire avec soin un produit que personne ne paiera. Avant la première ligne de code, trois choses doivent être établies :

• Un problème que des clients paient déjà pour résoudre, avec un tableur, un prestataire ou un logiciel qu'ils trouvent inadapté.
• Des premiers clients identifiés, idéalement prêts à tester une première version, voire à la précommander.
• Un périmètre de première version limité au parcours qui crée la valeur, et une liste écrite de tout ce qui attendra.

Notre guide du MVP d'une application détaille cette délimitation. Le point important pour un SaaS : la première version doit être réduite en fonctionnalités, jamais en solidité. Le cloisonnement des données, la facturation et les sauvegardes ne sont pas des options de deuxième version.

Le cœur d'un SaaS : servir plusieurs clients sans mélanger leurs données

Un SaaS est dit « multi-clients » (en anglais, multi-tenant) : chaque entreprise cliente a son espace, ses utilisateurs et ses données, mais tous partagent le même logiciel. Il existe trois grandes façons d'isoler les données.

Pour la plupart des projets, nous retenons la base commune avec un cloisonnement imposé au niveau de la base de données : avec PostgreSQL et Supabase, les règles de sécurité au niveau des lignes (row level security) garantissent qu'une requête ne peut renvoyer que les lignes du client connecté, même si le code applicatif contient une erreur. C'est une protection de dernier recours qui change tout le jour où un développeur oublie un filtre.

Comptes, rôles et invitations

Un client de SaaS n'est pas une personne : c'est une organisation, avec plusieurs utilisateurs aux droits différents. Il faut prévoir dès la conception :

• Les organisations et l'invitation de collègues par l'administrateur du compte client ;
• Les rôles (administrateur, utilisateur, lecture seule, comptable) et ce que chacun peut voir et faire ;
• La connexion unique (SSO) avec l'annuaire de l'entreprise, que les clients plus importants demandent vite ;
• Le journal des actions : qui a modifié quoi et quand, indispensable en cas de litige ou d'erreur.

La plateforme Klass., projet dont le fondateur de YMHB Web est cofondateur, illustre cette complexité : trois portails (école, opérations, intervenant), douze rôles et un cloisonnement strict entre établissements, vérifiés par un programme de contrôles automatiques rejoué à chaque mise à jour.

Abonnements et facturation

La facturation récurrente est le deuxième pilier d'un SaaS. Les questions à trancher :

• Le modèle de prix : par utilisateur, par volume, par formule, ou une combinaison.
• Le cycle de vie de l'abonnement : période d'essai, changement de formule en cours de mois, résiliation, réactivation.
• Les échecs de paiement : relances, période de grâce, suspension de l'accès, et ce que voit le client pendant ce temps.
• Les factures : numérotation, mentions obligatoires, envoi automatique.

Nous utilisons en général Stripe pour ces mécanismes, en suivant les événements qu'il envoie à l'application (paiement réussi, échec, résiliation) pour mettre à jour les droits du client. Pour Garage Connect, place de marché de la reprogrammation moteur, le modèle repose sur un abonnement mensuel des garages, sans commission sur les prestations : abonnements Stripe, factures PDF générées automatiquement et e-mails transactionnels. Pour Cospo Line, les abonnements existent des deux côtés, client et prestataire. Notre article sur les paiements de plateforme avec Stripe détaille ces montages.

Un point d'actualité pour les SaaS qui facturent des entreprises françaises : depuis le 1er septembre 2026, toutes les entreprises assujetties à la TVA établies en France doivent pouvoir recevoir des factures électroniques, et les PME devront les émettre au plus tard le 1er septembre 2027, selon l'administration fiscale. Le circuit de facturation du SaaS doit en tenir compte. Le guide de la facture électronique fait le point.

Les traitements longs et l'exploitation

Beaucoup de SaaS font plus qu'afficher des données : ils calculent, analysent, génèrent des documents ou interrogent d'autres services. Ces traitements ne doivent pas bloquer l'interface. Ils passent par des files d'attente et des processus qui travaillent en arrière-plan, puis préviennent l'utilisateur quand le résultat est prêt.

VISIA, produit interne de YMHB Web qui mesure la présence d'une entreprise dans les réponses des assistants IA, fonctionne ainsi : chaque analyse passe 123 contrôles techniques et éditoriaux et interroge plusieurs assistants IA ; ces travaux sont répartis sur six processus en parallèle, derrière l'application.

L'exploitation, elle, ne s'arrête jamais. Un SaaS a besoin dès sa première version :

• d'une supervision qui alerte avant que les clients ne s'en aperçoivent ;
• de sauvegardes testées, c'est-à-dire restaurées au moins une fois pour vérifier qu'elles fonctionnent ;
• d'un environnement de test séparé de la production, avec des données fictives ;
• d'une procédure de mise à jour qui ne coupe pas le service.

Sécurité, données personnelles et réversibilité

Un SaaS concentre les données de nombreux clients : c'est une cible. La base de travail est le Top 10 de l'OWASP, référence des risques de sécurité des applications web (dernière édition : 2025), complété par l'authentification multifacteur pour les comptes administrateurs.

Côté droit, deux textes européens s'appliquent directement à l'éditeur :

• Le RGPD, article 28 : quand le SaaS traite des données personnelles pour le compte de ses clients, l'éditeur est sous-traitant et un contrat doit encadrer ce traitement. À la fin de la prestation, il supprime ou restitue les données, au choix du client.
• Le règlement européen sur les données (Data Act), applicable depuis le 12 septembre 2025 : il encadre le changement de fournisseur de services de traitement de données, SaaS compris (préavis, période de transition, export des données), et interdit les frais de changement de fournisseur à partir du 12 janvier 2027, avec des exceptions pour les services conçus sur mesure.

En pratique, cela veut dire prévoir dès la conception un export complet et documenté des données de chaque client. C'est aussi un argument commercial : un client qui sait pouvoir partir s'engage plus facilement.

La technique : des choix sobres

Nous construisons en général les SaaS avec Next.js et React pour l'interface, Node.js pour les traitements, PostgreSQL (souvent via Supabase) pour les données et Stripe pour les paiements. Ces choix ne relèvent pas de la mode : ce sont des technologies répandues, documentées et maintenues, qu'une autre équipe pourra reprendre. Notre comparatif Supabase ou Firebase détaille un des arbitrages fréquents.

Le critère le plus important n'est pas la technologie, c'est la propriété. Chez YMHB Web, le code et les données appartiennent au client au paiement intégral : un éditeur de SaaS doit pouvoir changer de prestataire sans repartir de zéro. Le guide propriété du code source et réversibilité explique ce qu'il faut exiger dans le contrat.

Ce qui fait le budget d'un SaaS

Les postes qui pèsent sont toujours les mêmes : le cloisonnement et les rôles, la facturation récurrente, les traitements en arrière-plan, les intégrations avec d'autres logiciels, l'espace d'administration de l'éditeur, puis l'hébergement et l'exploitation. Le nombre d'écrans compte peu en comparaison. Nous fixons le budget en forfait global ferme après un cadrage qui tranche ces points, et le fondateur suit le projet du premier rendez-vous à la mise en service.

Pour en savoir plus sur l'offre : application web et plateforme SaaS sur mesure, MVP pour startups et PME et plateformes web métier.

Pour aller plus loin

• Combien coûte le développement d'un SaaS ?
• Logiciel sur mesure ou SaaS : comment trancher
• SaaS : définition et exemples
• Sécurité d'une application métier
• RGPD et logiciel métier
• Combien coûte l'hébergement d'une application ?

Sources

• NIST, Special Publication 800-145, The NIST Definition of Cloud Computing (septembre 2011) : nvlpubs.nist.gov (nouvel onglet)
• Supabase, Row Level Security, consulté le 8 octobre 2026 : supabase.com (nouvel onglet)
• Stripe, Documentation : recevoir des événements Stripe dans votre endpoint de webhook, consulté le 8 octobre 2026 : docs.stripe.com (nouvel onglet)
• impots.gouv.fr, Je découvre la facturation électronique (page modifiée le 26 mai 2026) : impots.gouv.fr (nouvel onglet)
• OWASP Foundation, OWASP Top 10:2025 : top10.owasp.org (nouvel onglet)
• CNIL, texte du RGPD, chapitre IV (article 28, sous-traitant) : cnil.fr (nouvel onglet)
• EUR-Lex, règlement (UE) 2023/2854 sur les données (Data Act) : eur-lex.europa.eu (nouvel onglet)
• YMHB Web, études de cas Klass., Garage Connect, Cospo Line et VISIA, publiées sur ymhb-web.com (2026).