SaaS & business model / Billing, quotas & pricing

Construire une plateforme SaaS, techniquement, ce n’est pas le plus dur. La vraie difficulté, c’est de la rendre rentable dans la durée.

La vraie question derrière toute plateforme SaaS

On a accompagné beaucoup de clients dans le développement de plateformes SaaS. Et à chaque fois, la même question revient : “Comment je rentabilise ma plateforme SaaS ?”

Techniquement, technologiquement, il n’y a généralement pas de problème. La vraie difficulté, c’est la commercialisation : comment générer de la valeur autour du produit sans se tirer une balle dans le pied financièrement.

Abonnement, licence : le modèle le plus simple… en apparence

Le modèle le plus courant reste l’abonnement (20 €, 100 € par mois). Sur le papier, c’est simple. Mais les vraies questions sont : est-ce que ce prix couvre réellement les coûts ? Et surtout : est-ce que tous les clients consomment la plateforme de la même manière ? Dans la majorité des SaaS, la réponse est non.

Les frais cachés du SaaS : l’hébergement et la scalabilité

Le nerf de la guerre, ce sont les coûts d’infrastructure. Avec une architecture moderne (micro-services, haute disponibilité), la facture peut vite grimper. Chez Winzana, on s’accorde sur un point : Kubernetes est aujourd’hui incontournable.

La conteneurisation permet une scalabilité montante et descendante et une meilleure maîtrise des ressources. Mais Kubernetes seul ne suffit pas : il faut savoir ce que chaque client te coûte réellement.

Quotas : la clé pour éviter les clients non rentables

Si un client paie 100 € mais consomme énormément d’API et de services coûteux, il vous coûte plus qu’il ne vous rapporte. C’est là qu’intervient la notion de quotas :

quotas d’API
quotas de traitements
quotas de stockage
quotas de services tiers

Sans quotas, vous ne maîtrisez rien.

Observabilité : mesurer pour décider

Pour savoir si votre pricing est bon, il faut mesurer précisément via des solutions d’observabilité (OpenTelemetry, Prometheus, Grafana). La vraie valeur arrive quand ces données sont connectées à votre plateforme pour répondre à deux questions vitales : combien me coûte ce client et quel est mon ROI par client ?

Usage-based pricing : facturer à l’usage réel

Une fois l’observabilité en place, vous pouvez proposer un pricing basé sur l’usage réel : consommation d’API, nombre de traitements ou temps de calcul. C’est particulièrement pertinent pour des modèles B2B2B2C ou des marketplaces. Chaque client paie ce qu’il consomme, et vous protégez votre marge.

Quotas sur services tiers : SMS, IA, APIs externes

Certains coûts sont incompressibles comme les SMS ou l’intelligence artificielle. Les intégrer dans un abonnement “illimité” est souvent une très mauvaise idée. Une approche saine consiste à facturer des packs ou limiter par des quotas clairs pour rendre l’usage transparent et prévisible.

Le piège du SaaS à 20 € par mois

Beaucoup de plateformes se lancent avec des prix très bas. La vraie question est : à partir de combien de clients suis-je rentable ? Et surtout : est-ce que je peux tenir financièrement jusqu’à atteindre ce volume ?

Définir son business model avant de lancer le SaaS

Beaucoup de porteurs de projet oublient de définir comment la plateforme génère de l’argent et comment les coûts évoluent avec l’usage. Un SaaS sans modèle économique clair est un projet à haut risque.

Conclusion

Le billing SaaS n’est pas un détail technique, c’est un sujet stratégique. Quotas, pricing, observabilité et maîtrise des coûts sont liés. Avant de lancer, définissez votre business model et faites-vous accompagner pour éviter les surcoûts cachés. Un bon SaaS est un produit qui sait se financer lui-même.

IA & product design / Figma Maker & Cursor

Nous avons testé Figma Maker couplé à Cursor. La question n’est pas “est-ce que les développeurs vont disparaître ?” mais “qu’est-ce qui change réellement dans notre métier ?”

Pourquoi tout le monde pose la mauvaise question

À chaque nouvelle vague d’outils boostés à l’IA, la même question revient : “Est-ce que le métier de développeur est fini ?” C’est une mauvaise question. Ce n’est pas celle que se posent les équipes qui livrent réellement des produits en production. La vraie question est :

qu’est-ce que ces outils automatisent vraiment ?
qu’est-ce qu’ils déplacent comme responsabilité ?
qu’est-ce qui reste fondamentalement humain ?

Figma Maker : accélérateur de design, pas générateur de produit

Figma Maker permet de générer des écrans et des flows complets à partir d’intentions vagues. C’est réellement utile pour prototyper rapidement et aligner les équipes. Mais il ne comprend pas la logique métier, les contraintes d’architecture, ni la réalité de la production. Il produit des interfaces, pas des systèmes.

Cursor : un copilote de code extrêmement puissant

Cursor est l’un des meilleurs outils actuels pour travailler avec des LLM dans un contexte de développement réel. Il excelle pour naviguer dans une base de code existante, accélérer des refactors ou générer du code répétitif.

Mais Cursor ne “comprend” pas votre produit : il extrapole. S’il est mal guidé, il accélère aussi très bien les mauvaises décisions.

Le fantasme : design → code → produit en un clic

L’idée que Figma Maker + Cursor permettraient de passer automatiquement du design à un produit fini est séduisante. En réalité, ce pipeline casse très vite sur des points cruciaux :

la gestion de l’état et les règles métier complexes
les cas limites
les performances et la sécurité

Construire un système cohérent, maintenable et exploitable reste un travail d’ingénierie.

Ce que ces outils changent vraiment dans le métier de développeur

Ils changent la vitesse, pas la responsabilité. Concrètement, cela signifie moins de temps sur le « boilerplate » et plus de temps sur l’architecture et les choix structurants. Le rôle du développeur senior ou du CTO devient encore plus critique : cadrer, arbitrer, refuser, simplifier.

Ce que ces outils ne feront pas à ta place

Ni Figma Maker, ni Cursor ne prendront en charge les décisions d’architecture, les compromis produit, la gestion de la dette technique ou le « run ». Ils n’assument pas les incidents, les choix, ni leurs conséquences.

Le vrai risque : confondre vitesse et maîtrise

Le danger n’est pas que l’IA remplace les développeurs. Le danger, c’est de livrer plus vite des systèmes que personne ne maîtrise vraiment. Sans cadre, ces outils deviennent des générateurs de dette technique à très grande vitesse.

Conclusion

Figma Maker et Cursor sont d’excellents outils qui augmentent la productivité. Mais ils ne remplacent pas le métier de développeur. Ils déplacent simplement le centre de gravité : moins d’exécution mécanique, plus de responsabilité sur les choix. Le métier ne disparaît pas, il devient plus exigeant.

Architecture logicielle / API-first & intégrations

Les intégrations ne bloquent pas les projets par accident. Elles bloquent quand l’API n’a jamais été pensée comme un produit.

Pourquoi les intégrations sont le premier point de friction

ERP, CRM, paiement, outils tiers, partenaires… Très peu de produits vivent aujourd’hui en vase clos. Pourtant, dans beaucoup de projets, l’API arrive après l’UI, après le modèle de données et après les premières décisions techniques.

Résultat : l’intégration devient un chantier à part, coûteux, fragile, et souvent source de blocages projet.

API-first : ce que ça veut vraiment dire (et ce que ce n’est pas)

API-first ne signifie pas “exposer une API plus tard”. Cela signifie :

concevoir les contrats avant l’implémentation
penser les usages avant les écrans
stabiliser les échanges avant d’optimiser l’interne

L’API devient un produit à part entière, consommé par l’UI, les intégrations et parfois des tiers.

Erreur classique : confondre API et CRUD exposé

Beaucoup d’API se contentent d’exposer la base de données (create, read, update, delete). Le problème ? Les systèmes externes ne pensent pas en tables, ils pensent en processus métier. Une bonne API expose :

des intentions métier
des règles claires
des invariants protégés

Une mauvaise API délègue la complexité aux intégrateurs.

Intégrer un ERP : penser robustesse avant élégance

Les ERP sont rarement temps réel. Ils sont souvent lents, verbeux et imprévisibles. Une API ERP-friendly doit prévoir :

des appels idempotents
des traitements asynchrones
des mécanismes de reprise

Si votre API suppose que “tout répond vite et bien”, l’intégration ERP finira par casser en production.

Intégrer un CRM : gérer l’asymétrie des données

CRM et produit n’ont pas la même vision du client et ne seront jamais parfaitement synchrones. Une bonne approche API-first implique des identifiants stables, des règles claires de source de vérité et des mécanismes de synchronisation explicites. Sans cela, les doublons et les incohérences sont inévitables.

Intégrer le paiement : ne jamais faire confiance par défaut

Le paiement est un cas à part. Tout ce qui peut arriver… arrivera. Une API paiement robuste doit gérer les webhooks en double, les délais réseau, les états intermédiaires et la réconciliation. Si votre modèle suppose un paiement synchrone et fiable, la production vous rappellera vite à l’ordre.

Versionner une API sans bloquer les intégrations

Une API non versionnée finit par bloquer tout le monde. Les bonnes pratiques consistent à versionner les contrats (pas uniquement les URLs), éviter les « breaking changes » silencieux et maintenir plusieurs versions si nécessaire. Une API stable inspire confiance.

Observabilité : voir les intégrations avant qu’elles ne cassent

Les intégrations se dégradent souvent avant d’échouer brutalement. Une API exploitable doit fournir des logs corrélés, des métriques par partenaire et des alertes orientées usage. Sans cela, chaque incident devient une enquête manuelle fastidieuse.

Checklist CTO pour une approche API-first sans blocage

Avant de valider une intégration, voici les points essentiels :

• Des contrats d’API clairs et documentés
• Une gestion explicite des erreurs
• Des appels idempotents
• Une stratégie asynchrone quand nécessaire
• Une politique de versioning et une observabilité réelle

Conclusion

API-first n’est pas un luxe d’architecte, c’est une condition de survie quand le produit s’intègre à un écosystème réel. Une bonne API rend les intégrations prévisibles, maintenables et évolutives. Elles ne sont pas un “plus”, elles font partie intégrante du produit.

Stratégie produit / Build vs Buy

Build vs Buy n’est pas un débat idéologique. C’est un arbitrage entre vitesse, contrôle, risques et capacité à exécuter.

Build vs Buy : une question mal posée dans 80 % des cas

“Est-ce qu’on doit acheter une solution existante ou développer la nôtre ?” Cette question revient dans quasiment tous les projets SaaS ou logiciels métier. Pourtant, elle est souvent abordée sous le mauvais angle : uniquement le coût initial ou la complexité technique.

En réalité, Build vs Buy est un choix stratégique qui engage le produit, l’architecture, la donnée et surtout la capacité à aller vite sur le marché.

Acheter (Buy) : aller vite… sous certaines conditions

Acheter une solution existante est souvent séduisant : time-to-market immédiat, support et documentation. Les avantages sont réels :

démarrage rapide
coût initial maîtrisé
fonctionnalités déjà éprouvées

Mais ces avantages ont un prix invisible au départ : dépendance forte à un éditeur, roadmap subie, coûts récurrents croissants et personnalisation limitée. Acheter, c’est accepter de déléguer une partie du contrôle.

Construire (Build) : plus lent au départ, plus maîtrisé dans le temps

Le sur-mesure fait peur lorsqu’il est mal cadré. Mais bien conçu, il permet :

un alignement parfait avec le métier
un contrôle total sur l’architecture
une maîtrise de la donnée
une évolutivité sans verrou éditeur

Le coût initial est plus élevé, mais le coût marginal d’évolution est souvent bien plus faible qu’avec une solution achetée sur le long terme.

Le vrai sujet : le TCO, pas le prix d’entrée

Comparer Build vs Buy uniquement sur le coût initial est une erreur classique. Le TCO (Total Cost of Ownership) inclut :

• Licences et abonnements
• Coûts d’intégration
• Coûts d’exploitation et de support
• Coûts d’évolution et de sortie (migration)

Beaucoup de solutions “buy” deviennent très chères précisément au moment où le produit commence à bien fonctionner.

La donnée : un critère souvent sous-estimé

Build vs Buy, c’est aussi un choix sur la souveraineté de la donnée. Utiliser une solution tierce implique souvent un hébergement hors Europe et des contraintes juridiques complexes. Le sur-mesure permet ce contrôle total, mais il implique d’assumer l’entièreté de l’exploitation technique.

Les risques : visibles d’un côté, cachés de l’autre

Les risques du Build sont connus : dérive de périmètre, dette technique, délais. Les risques du Buy sont souvent sous-estimés :

verrouillage fournisseur (lock-in)
hausse brutale des coûts
impossibilité de différenciation concurrentielle

Le facteur décisif : le go-to-market

Le critère le plus important est souvent la vitesse à laquelle vous pouvez tester votre marché et délivrer de la valeur. Parfois, acheter permet d’aller vite pour valider une hypothèse. Parfois, le sur-mesure est la seule façon de construire un avantage concurrentiel réel.

Quand le sur-mesure est réellement rentable

Le sur-mesure devient pertinent quand :

le produit est au cœur de la valeur business
la différenciation est clé
la donnée est stratégique
l’architecture doit évoluer sans contraintes externes

Conclusion

Build vs Buy n’est jamais une décision purement technique. C’est un choix de stratégie produit, de gouvernance et de rythme de croissance. Être souverain sur sa solution peut être un avantage énorme, à condition que cela ne bloque pas le go-to-market. Le bon choix est presque toujours contextuel et aligné avec la réalité du marché.

IA & SaaS / RAG en production

Le RAG est une excellente réponse aux hallucinations des LLM. Mais mal implémenté, il en crée de nouvelles.

Avant de parler garde-fous : c’est quoi exactement un RAG ?

RAG signifie Retrieval Augmented Generation. L’idée est simple : au lieu de laisser un LLM répondre uniquement avec ce qu’il “sait”, on lui fournit des données externes pertinentes au moment de la requête.

Concrètement, un RAG repose sur trois briques :

• Une source de vérité : documents, base de données, base de connaissances.
• Un moteur de recherche sémantique : embeddings, vector store.
• Un LLM : qui génère la réponse à partir du contexte fourni.

Le LLM ne “devine” plus : il répond à partir d’un contexte contrôlé. En théorie, cela réduit les hallucinations ; en pratique, seulement si l’architecture est solide.

Pourquoi les hallucinations existent encore avec un RAG

Beaucoup d’équipes découvrent le RAG en production et voient encore des réponses fausses. Les causes sont récurrentes :

contexte incomplet ou bruité
documents mal découpés (chunking)
absence de règles côté génération
confiance aveugle dans la réponse du LLM

Le RAG ne supprime pas les hallucinations par magie : il déplace le problème vers l’architecture et le pipeline de données.

Garde-fou n°1 : une source de vérité strictement contrôlée

Un RAG ne doit jamais indexer n’importe quoi. Les documents doivent être validés fonctionnellement, à jour et traçables (version, origine, date). Si la donnée source est mauvaise, le LLM sera mauvais. Le RAG ne corrige pas une base défaillante.

Garde-fou n°2 : découper les documents intelligemment

Un « chunk » (morceau de texte) trop gros dilue l’information, un trop petit fait perdre le contexte. Les bonnes pratiques incluent un découpage logique (par sections ou paragraphes), un « overlap » (recouvrement) contrôlé et l’usage systématique de métadonnées. Le découpage est un choix d’architecture stratégique.

Garde-fou n°3 : limiter explicitement le champ de réponse du LLM

Par défaut, un LLM essaiera toujours de répondre, même s’il ne sait pas. En production, il faut lui donner des règles strictes :

“Répond uniquement à partir du contexte fourni”
“Si l’information n’est pas présente, dis-le explicitement”

Forcer l’aveu d’ignorance est l’un des meilleurs anti-hallucinations possibles.

Garde-fou n°4 : tracer systématiquement les sources utilisées

Une réponse sans source est un risque. Un RAG doit permettre de savoir quels documents ont été utilisés et quels passages ont influencé la réponse. Sans cette traçabilité, impossible de corriger une erreur ou d’expliquer une réponse à un utilisateur.

Garde-fou n°5 : mesurer la qualité, pas seulement la performance

Beaucoup d’équipes monitorent la latence ou le coût, mais oublient de mesurer le taux de réponses hors contexte ou le taux de “je ne sais pas”. Sans métriques de qualité, les hallucinations passent inaperçues.

Garde-fou n°6 : versionner le pipeline RAG

Un RAG évolue sans cesse (nouveaux documents, prompts, modèles). Sans versioning, les régressions sont invisibles et les comparaisons impossibles. Le pipeline doit être versionné comme n’importe quel composant critique.

Garde-fou n°7 : prévoir un mode dégradé (et l’assumer)

Le RAG ne doit jamais être un point de défaillance unique. Il faut prévoir des réponses par défaut ou des « fallbacks » sans IA. Un RAG qui se tait vaut toujours mieux qu’un RAG qui invente.

Conclusion

Le RAG est un outil puissant, mais ce n’est pas une solution magique. En production, les hallucinations sont rarement un problème de modèle ; elles sont presque toujours un problème d’architecture. Un RAG bien conçu ne promet pas l’omniscience, mais fournit des réponses fiables et traçables.

Architecture SaaS / Mono-tenant vs Multi-tenant

Mono-tenant ou multi-tenant n’est pas un choix technique anodin. C’est une décision structurante qui conditionne ton produit, ton run et ta capacité à scaler.

Un faux débat… jusqu’au jour où il devient critique

Dans beaucoup de projets SaaS, la question mono-tenant vs multi-tenant est repoussée avec une phrase magique : “On verra plus tard, pour l’instant on fait simple.”

Le problème, c’est que “plus tard” arrive toujours plus vite que prévu. Et quand le produit commence à marcher, revenir sur ce choix devient extrêmement coûteux. Ce n’est pas un débat théorique. C’est une décision d’architecture qui impacte la sécurité, la performance, les coûts, l’exploitation et même le business model.

Mono-tenant : simplicité apparente, complexité déplacée

En mono-tenant, chaque client dispose de son environnement : base de données, services, parfois même infrastructure dédiée. Les avantages sont réels :

isolation forte des données
sécurité plus simple à raisonner
personnalisation client facilitée

Mais la contrepartie arrive rapidement sous forme de coûts d’infrastructure élevés, d’opérations complexes à grande échelle et de déploiements démultipliés. En pratique, le mono-tenant déplace la complexité de l’application vers l’exploitation.

Multi-tenant : efficacité maximale, discipline obligatoire

En multi-tenant, plusieurs clients partagent la même application et souvent la même base de données, avec une isolation logique. Les bénéfices sont clairs : mutualisation des coûts, scalabilité naturelle et déploiements centralisés.

Mais ce modèle exige une vraie rigueur architecturale :

gestion stricte des accès aux données
modèle de données pensé pour l’isolation
tests systématiques des frontières de tenant

Le multi-tenant pardonne très peu les approximations.

La vraie question : isolation logique ou isolation physique ?

La vraie question n’est pas mono ou multi, mais comment et où on isole. Quelques options courantes pour la base de données :

• Une base par tenant : isolation physique forte.
• Un schéma par tenant : compromis entre isolation et mutualisation.
• Une table partagée avec tenant_id : isolation logique pure, efficacité maximale.

Chaque approche a des impacts directs sur la sécurité, les performances, les migrations et le run.

Erreur classique : vouloir être multi-tenant “plus tard”

Démarrer en mono-tenant en se disant qu’on migrera ensuite est l’une des erreurs les plus fréquentes. Le multi-tenant impacte profondément le modèle de données, les APIs, la sécurité et les tests. Sans anticipation minimale, la migration devient une refonte déguisée souvent très sous-estimée.

Quand le mono-tenant est le bon choix

C’est un choix adapté dans certains contextes précis :

clients grands comptes avec exigences fortes
contraintes réglementaires élevées
volumétrie très hétérogène ou personnalisations lourdes

Il faut alors assumer un modèle économique plus proche d’un produit industriel que d’une plateforme mutualisée.

Quand le multi-tenant est presque incontournable

Le multi-tenant s’impose lorsque le volume de clients est élevé, le pricing standardisé et que la scalabilité est un objectif clé de croissance. Ne pas y penser dès le départ revient souvent à freiner son propre développement.

Checklist CTO pour choisir sans regret

Avant de trancher, voici les questions à poser clairement :

• Quel niveau d’isolation est réellement requis par mon marché ?
• Quelle est l’hétérogénéité d’usage entre mes clients ?
• Quel est mon modèle de coût d’infrastructure cible ?
• Quel niveau d’automatisation du « run » est prévu ?

Conclusion

Mono-tenant ou multi-tenant n’est pas une question de mode, mais de cohérence. Un bon choix aujourd’hui évite une refonte demain. Si ton SaaS commence à montrer des signes de tension, une revue d’architecture maintenant coûte toujours moins qu’une migration forcée plus tard.

IA & développement / Claude, ChatGPT, LLM en équipe

Utiliser des LLM pour coder en équipe peut accélérer énormément… ou générer une dette technique massive si on ne met aucune règle.

Coder avec des LLM en équipe : le nouveau chaos organisé

Aujourd’hui, Claude, ChatGPT et les autres LLM sont déjà dans les équipes, officiellement ou non. Ils génèrent du code plus vite, des tests plus rapidement et des refactors audacieux.

Mais ils génèrent aussi autre chose : du code que personne ne comprend vraiment, des patterns incohérents et une dette technique silencieuse. Le problème n’est pas l’IA, c’est l’absence de règles collectives.

Un LLM ne code pas “bien” : il code “probable”

Un LLM ne comprend pas votre produit, votre historique ou vos compromis. Il génère ce qui est statistiquement plausible. Cela signifie :

des abstractions parfois inutiles
des patterns copiés hors contexte
du code qui marche… mais qui vieillit mal

Sans garde-fous, l’IA amplifie les défauts existants du projet au lieu de les corriger.

Pourquoi la dette technique explose avec l’IA

Avant, écrire du mauvais code prenait du temps. Aujourd’hui, c’est instantané. En équipe, ces problèmes se multiplient si la code review ne s’adapte pas : duplication de logique, incohérences de nommage et sur-abstraction prématurée deviennent la norme.

Règle n°1 : le code généré par un LLM n’est jamais “hors review”

“C’est l’IA qui l’a écrit” n’est pas une excuse. En code review, le code généré doit être considéré comme du code écrit par un profil junior : rapide, mais naïf, et à challenger systématiquement. Si personne n’est capable d’expliquer le code en review, il ne doit pas passer.

Règle n°2 : interdire les abstractions générées sans usage réel

Les LLM adorent les factories, les helpers génériques et les couches “au cas où”. En review, une question simple doit suffire : “Combien de fois cette abstraction est-elle utilisée aujourd’hui ?” Si la réponse est “une seule fois”, c’est de la complexité anticipée, pas une abstraction.

Règle n°3 : refuser le code que personne n’ose modifier

Le pire code généré par IA est celui que plus personne ne veut toucher par peur de tout casser. En review, posez toujours ces questions :

Est-ce lisible par quelqu’un d’autre ?
Est-ce cohérent avec le reste du projet ?
Est-ce que je saurais le modifier dans 6 mois ?

Si la réponse est non, il faut simplifier, même si “ça marche”.

Règle n°4 : documenter les décisions, pas le code généré

Inutile de documenter chaque ligne produite par l’IA. Il vaut mieux documenter les intentions : pourquoi cette solution a été choisie, quelles alternatives ont été écartées et quels compromis sont assumés. La vraie dette technique vient des décisions non explicitées.

Règle n°5 : aligner les prompts avec les conventions du projet

Laisser chacun prompter “à sa sauce” est une erreur. Les bonnes pratiques incluent des prompts partagés dans le repo, des rappels des conventions de nommage et des patterns d’architecture explicités. Un LLM bien cadré est beaucoup plus utile qu’un LLM “libre”.

Règle n°6 : l’IA accélère, la responsabilité reste humaine

L’usage de l’IA ne transfère aucune responsabilité. Dans une équipe mature : l’IA propose, l’humain décide et l’équipe assume. C’est cette discipline qui permet de bénéficier de la vitesse de l’IA sans en subir les effets secondaires.

Conclusion

Les LLM sont des accélérateurs incroyables, mais ils amplifient ce qui existe déjà. Sans règles de code review adaptées, l’IA ne réduit pas la dette technique : elle la génère plus vite. En tant que CTO, le vrai enjeu est de structurer son usage pour qu’elle serve le produit, et non l’inverse.

MVP SaaS / Scalabilité & architecture

Beaucoup de MVP SaaS fonctionnent. Très peu passent réellement à l’échelle. Et non, ce n’est pas (que) un problème de marché.

Le MVP qui marche… jusqu’au jour où il ne marche plus

En tant que fondateur et CTO, j’ai vu passer énormément de MVP SaaS. Des produits qui trouvent leurs premiers clients, génèrent du revenu, et semblent “bien partis”.

Puis arrive le moment fatidique : plus d’utilisateurs, plus de données, plus de demandes, plus de pression. Et là, le produit commence à montrer ses limites. Pas parce que l’idée est mauvaise, mais parce que l’architecture n’a jamais été pensée pour autre chose qu’un MVP.

Un MVP n’est pas censé être jetable (mais il doit être évolutif)

On confond souvent MVP et prototype jetable. Résultat : on fait des choix “temporaires” qui deviennent permanents. Un MVP doit être simple et rapide à développer, mais capable d’évoluer. Ce qui échoue rarement, c’est le MVP. Ce qui échoue souvent, c’est le passage du MVP à un vrai produit SaaS.

Erreur n°1 : une architecture pensée pour un seul client

Beaucoup de MVP SaaS démarrent comme s’il n’y avait qu’un seul client. Sans séparation claire des tenants, des données et des responsabilités, chaque nouvelle fonctionnalité augmente la complexité globale du système. Le produit se heurte vite à des attentes de sécurité et d’isolation impossibles à satisfaire sans refonte.

Erreur n°2 : un domaine métier noyé dans la technique

Dans beaucoup de MVP, la logique métier est dispersée entre le front, l’API et la base de données. Tant que le produit est petit, ça passe. Quand il grandit, chaque changement devient risqué car le cœur métier n’est pas isolé. Résultat : les tests deviennent difficiles et la dette technique explose.

Erreur n°3 : ignorer la volumétrie jusqu’à ce qu’elle explose

“On verra quand on aura du trafic” est une phrase extrêmement coûteuse. Un MVP SaaS qui réussit va naturellement générer plus de requêtes et d’événements. Sans anticipation minimale (asynchrone, batch, cache), la plateforme devient instable au moment même où elle commence à décoller.

Erreur n°4 : confondre “ça marche” avec “c’est industrialisé”

Un MVP qui marche en environnement contrôlé n’est pas encore un produit SaaS. L’industrialisation implique :

déploiements reproductibles
monitoring et alerting
gestion des incidents
mises à jour sans interruption

Sans run maîtrisé, chaque incident devient une crise qui ralentit la croissance.

Erreur n°5 : empiler les fonctionnalités sans gouvernance

Le succès d’un MVP entraîne souvent une avalanche de demandes. Sans règles claires, le produit devient incohérent et la complexité augmente plus vite que la valeur. L’architecture doit servir de garde-fou contre cette dérive fonctionnelle.

Ce qui permet réellement de passer à l’échelle

Les SaaS qui passent à l’échelle ont presque toujours :

• Un domaine métier clair et isolé
• Une gestion explicite des tenants et des données
• Des flux maîtrisés (sync / async)
• Une vraie stratégie de run
• Des décisions techniques assumées tôt

Conclusion

80 % des MVP SaaS n’échouent pas parce que le marché n’existe pas. Ils échouent parce que la plateforme ne survit pas à son propre succès. Un MVP n’a pas besoin d’être complexe, il a besoin d’être pensé pour évoluer.

Si ton SaaS commence à grandir, c’est précisément à ce moment-là qu’une revue d’architecture fait la différence pour s’assurer que ton produit pourra passer à l’échelle sans tout réécrire.