Combien coûte un SaaS en 2026 ? La grille de prix ne répond pas à la bonne question

Un article technique passé cette semaine propose une grille de prix pour construire un SaaS en 2026, en dollars, pensée pour une équipe qui monte une startup américaine : de 500 à 2 500 dollars pour un prototype, jusqu'à 20 000-50 000 dollars et plus pour une plateforme complexe. L'auteur y détaille ce qui fait vraiment grimper la facture : l'architecture multi-locataires, la gestion fine des rôles et permissions, l'intégration Stripe (bien plus qu'un bouton « payer »), les workflows IA, la préparation à la production. Sa conclusion tient en une phrase : construire moins, mais construire les parties importantes correctement.

C'est un bon article. Le problème, c'est la question qu'il répond.

Une grille pensée pour une startup, pas pour un projet solo

Toute cette grille suppose un contexte précis : une équipe qui construit un produit destiné à plusieurs clients, avec des comptes séparés, une facturation récurrente, des rôles à gérer. C'est un SaaS au sens propre du terme, celui qui sert à plusieurs organisations en même temps.

Une bonne partie de ce que je construis n'a rien à voir avec ça. Un site vitrine, une boutique en ligne pour un artisan, une plateforme éditoriale pour une seule structure : pas de multi-tenant, pas de rôles à arbitrer entre des dizaines de comptes clients, pas de facturation récurrente à gérer moi-même. La grille de prix de l'article ne s'applique tout simplement pas à ce genre de travail, et c'est là que le bât blesse : elle est citée, reprise, brandie dans des devis, alors qu'elle a été pensée pour un produit d'un tout autre genre.

L'auteur, lui, reste clair sur son périmètre. Le problème n'est pas son article : c'est l'usage qu'on en fait ailleurs, quand la même grille sert de référence à un tout autre genre de projet.

Pour donner quand même un repère plutôt que rien, voici les ordres de grandeur constatés sur le marché français en 2026[^1] :

Ce sont des fourchettes de marché, pas un devis : elles disent surtout que l'ordre de grandeur d'un projet solo n'a rien à voir avec celui d'un SaaS multi-comptes, ce qui est précisément le point de cet article.

Ce qui fait vraiment varier le prix, côté solo

Sur un projet solo, ce ne sont pas les catégories d'architecture qui font varier le prix. C'est autre chose, moins visible dans une grille.

Le flou du brief. Un cahier des charges précis coûte moins cher à construire qu'un brief qui se dessine au fil des allers-retours. Le code n'est pas plus compliqué dans un cas que dans l'autre : chaque itération coûte du temps de compréhension mutuelle, au-delà du temps d'écriture pur.

Les intégrations tierces. Un paiement Stripe, un CRM existant, un outil métier déjà en place chez le client : chaque connexion externe est un point où le projet peut caler sur une documentation incomplète, une API qui change, un compte de test qui n'existe pas encore. Le code de l'intégration en lui-même coûte rarement cher. L'incertitude qui l'entoure, si.

Le contenu. Un site avec du contenu prêt (textes validés, images choisies, structure éditoriale pensée) se construit vite. Un site où le contenu se décide en même temps que le design ralentit tout, parce que chaque page attend une décision qui n'est pas technique.

La maintenance qu'on ne facture jamais assez. Un site livré n'est pas un site fini. Il continue d'exister : mises à jour de sécurité, dépendances qui vieillissent, hébergement à surveiller. Ce coût-là est presque toujours sous-estimé dans le prix initial, des deux côtés de la table.

Aucune de ces variables ne figure dans une grille par fonctionnalité. Elles ne se lisent pas dans un cahier des charges, elles se découvrent en travaillant. Deux projets à peu près équivalents sur le papier peuvent avoir un temps de développement du simple au double : celui où le client arrive avec des textes validés et des images choisies avance sans interruption ; celui où chaque page attend encore une décision de contenu s'étale sur plusieurs semaines de plus, pas parce que le code diffère, mais parce que le rythme du projet dépend de décisions qui ne sont pas les miennes à prendre.

Ce qui resserre vraiment une fourchette

La bonne réponse à « combien ça coûte » n'est presque jamais un chiffre unique donné à l'aveugle. C'est une fourchette, assumée comme telle dès le départ, que quelques questions concrètes permettent de resserrer avant même d'écrire une ligne de code :

Plus les réponses sont posées, plus la fourchette se resserre. Plus elles restent ouvertes, plus elle reste large, et c'est très bien ainsi : ça vaut mieux qu'un chiffre rond qui prétend à une précision qu'aucun projet n'a avant d'avoir commencé.

L'article dont je parle a raison sur un point qui dépasse largement le cadre du SaaS : construire moins, mais construire correctement ce qu'on construit. Simplement, pour un projet solo, la vraie difficulté n'est jamais dans la liste des fonctionnalités. Elle est dans tout ce que cette liste ne dit pas.

[^1] : Fourchettes de marché France, ordres de grandeur constatés sur plusieurs sources spécialisées 2026 : iPaoo, prix d'un site vitrine 2026, Adekoite, prix d'un site e-commerce 2026, AdevWeb, fourchettes par type de projet 2026.

The Interstice, développement web freelance. Entre le pixel et l'idée.