Développer un SaaS ou une plateforme métier : le budget réaliste pour une PME

Un devis d'ESN ne mesure pas la complexité de votre logiciel. Il reflète le coût de la structure qui le produit. Avant la première ligne de code, plusieurs personnes ont déjà été rémunérées pour cadrer, chiffrer et vendre le projet, et chaque intervenant est facturé à un taux journalier qui inclut sa marge et celle de l'entreprise.

Ce que vous payez dans un gros devis

• —Une phase d'avant-vente : réunions, cahier des charges, réponse à appel d'offres, souvent facturée en interne.
• —Une chaîne hiérarchique : chef de projet, lead technique, architecte, parfois un directeur de compte, en plus des développeurs.
• —Une marge d'agence sur chaque taux journalier, puis une seconde marge quand une partie est sous-traitée.
• —Une provision de risque : le devis gonfle pour absorber les imprévus d'une organisation lourde.
• —Des coûts fixes répercutés : locaux, commerciaux, direction, qui n'ont aucun rapport avec votre produit.

Résultat : le montant décrit l'organisation, pas la fonctionnalité. La même plateforme peut coûter 40 000 € ou 200 000 € selon qui la vend. Pour une PME qui lance son premier outil, la question utile n'est pas « combien coûte un SaaS » mais « quel périmètre minimal règle mon problème, et qui peut le livrer sans cette superstructure ».

Trois postes déterminent l'essentiel du budget. Ils sont rarement visibles sur une maquette, ce qui explique pourquoi deux devis pour « le même » projet peuvent varier du simple au décuple.

Le périmètre visible

Ce sont les écrans que l'utilisateur voit : formulaires, tableaux, tableau de bord, parcours d'inscription. C'est la partie que tout le monde chiffre, et paradoxalement la moins coûteuse. Chaque écran supplémentaire ajoute du temps, mais reste prévisible. Le piège n'est pas le nombre d'écrans, c'est le nombre de cas particuliers derrière chacun.

Le back-office invisible

C'est là que part le budget. Gestion des comptes et des rôles, séparation des données entre clients, historique, droits d'accès, administration. Une application qui sert plusieurs entreprises en même temps (multi-tenant) doit garantir qu'aucun client ne voit les données d'un autre, ce qui structure toute l'architecture dès le départ.

Alieva illustre ce poids : ce SaaS d'audit de sites que nous avons développé de bout en bout est multi-tenant, avec une couche de comptes et d'isolation des données qui représente une part majeure du travail réel, invisible sur une capture d'écran.

Les intégrations tierces

Facturation, authentification, services externes : chaque intégration ajoute un système à faire fonctionner de façon fiable, y compris quand il tombe en panne. Sur Alieva, la facturation par abonnement passe par Stripe Billing et la connexion par OAuth Google : deux briques standard, mais qui demandent une gestion sérieuse des cas limites (paiement refusé, abonnement suspendu, jeton expiré).

Le Lab NRV, un SaaS de prédictions, montre l'autre versant : un monorepo Next.js et FastAPI, plus de 30 endpoints d'API. Plus la logique métier est riche, plus la surface technique grandit, et c'est cette surface — pas le nombre de pages — qui fixe le budget.

• —Périmètre visible : prévisible, généralement le poste le plus faible.
• —Back-office et rôles : le vrai centre de gravité du budget.
• —Intégrations (paiement, auth, API) : chacune est un système à fiabiliser, pas une case à cocher.

La cause numéro un d'un budget qui explose n'est pas le prix du jour, c'est le périmètre qui gonfle en cours de route. La parade tient en une règle : livrer d'abord la version la plus petite qui règle vraiment le problème, la mettre en production, puis décider de la suite avec des utilisateurs réels.

Définir le chemin critique

Listez ce qui, si vous le retiriez, viderait le produit de son intérêt. Tout le reste attend. Pour chaque fonctionnalité demandée, une seule question : est-ce qu'un premier client peut travailler sans elle pendant trois mois ? Si oui, elle sort du premier lot.

• —Un seul parcours utilisateur complet, du début à la fin, plutôt que dix parcours à moitié faits.
• —Les rôles strictement nécessaires (souvent : un administrateur et un utilisateur), pas une matrice de permissions complète.
• —Une intégration de paiement si vous vendez dès le lancement ; sinon, elle attend.
• —Un back-office minimal pour que vous puissiez gérer les comptes à la main au début.

Ce qui attend la version 2

• —Les automatisations de confort (relances, exports avancés, notifications fines).
• —Les tableaux de bord analytiques détaillés, tant que vous n'avez pas de données à analyser.
• —Les intégrations « au cas où » avec des outils que personne n'a encore demandés.
• —La personnalisation poussée de l'interface par client.

Un MVP cadré n'est pas un produit au rabais. C'est un produit en production, utilisé, qui vous apprend ce qui mérite les investissements suivants. Payer 8 000 € pour valider une intuition vaut mieux que 90 000 € pour découvrir que trois écrans sur dix servent réellement.

À périmètre égal, l'écart de prix entre un studio indépendant senior et une agence ne se joue pas sur la qualité du code, mais sur ce qui s'ajoute autour. Comprendre où part l'argent vous aide à choisir en connaissance de cause.

• —Agence : plusieurs intermédiaires entre vous et la personne qui code ; vous financez la coordination interne autant que le développement.
• —Studio indépendant senior : la personne qui cadre est celle qui développe et qui déploie ; l'information ne se perd pas en route.
• —Agence : taux journalier chargé de la structure, avec une partie du travail parfois confiée à des profils juniors ou sous-traités.
• —Studio senior : un interlocuteur unique, responsable du résultat en production, pas seulement de la livraison d'un lot.

L'indépendant senior a ses limites : capacité réduite pour un très gros programme, nécessité de choisir quelqu'un qui livre réellement en production et pas seulement des maquettes. Pour un premier SaaS ou une plateforme métier de PME, c'est précisément le bon calibre : assez d'expertise pour tenir l'architecture, assez léger pour tenir le budget.

Pour une première application métier — un SaaS, une plateforme interne, un outil sur-mesure — la fourchette réaliste se situe entre 5 000 et 12 000 € HT. Ce n'est pas un prix d'appel : c'est le coût d'une version en production, pensée pour évoluer, sans la superstructure qui triple la facture.

Ce que couvre cette fourchette

• —Le cadrage du chemin critique et l'architecture, tenus par la personne qui développe.
• —Un périmètre fonctionnel complet sur un parcours utilisateur, jusqu'à la mise en production.
• —Le back-office nécessaire : comptes, rôles de base, isolation des données quand le produit sert plusieurs clients.
• —Une intégration structurante quand elle est requise, par exemple la facturation par abonnement (comme Stripe Billing sur Alieva) ou la connexion via OAuth.
• —Le déploiement sur une infrastructure maîtrisée et un produit réellement utilisable, pas une démo.

Ce qui fait sortir de la fourchette

• —Une logique métier très riche : plus la surface d'API grandit (le Lab NRV dépasse 30 endpoints), plus le budget monte.
• —Plusieurs parcours utilisateurs distincts à livrer d'emblée plutôt qu'un seul.
• —Des intégrations multiples ou des connexions à des systèmes existants complexes.
• —Des exigences fortes de conformité, de volumétrie ou de personnalisation par client dès le départ.

La bonne démarche : partir du problème, isoler le chemin critique, livrer entre 5 000 et 12 000 €, puis réinvestir sur ce que les utilisateurs réclament vraiment. C'est ainsi qu'Alieva et le Lab NRV existent en production — des produits complets, construits par lots, sans devis à six chiffres pour démarrer.