Scaler un SaaS du MVP au vrai chiffre d'affaires : ce qui casse vraiment

Résumé : Après le MVP, le scaling casse par vagues—support, puis performance, puis organisation—avant même de « nécessiter des microservices ».

La plupart du contenu « comment construire un SaaS » s'arrête au premier client payant. La partie intéressante (et douloureuse) commence juste après : les centaines de décisions entre le MVP et un produit dont 1 000 clients dépendent chaque jour. Voici ce qui casse vraiment, à peu près dans l'ordre où ça casse.

Étape 1 : 10 → 50 clients — le déluge de support

Vers 30 clients, le fondateur ne peut plus onboarder tout le monde personnellement. Les bugs ignorés pendant le MVP commencent à remonter quotidiennement. Le support email devient un job à temps plein.

Ce qu'il faut construire maintenant

• Une vraie page de statut, même basique. Les clients qui demandent « c'est down ? » sont une taxe sur votre temps.
• Des empty states in-app avec des exemples. La moitié des tickets « l'app est cassée » sont en fait « je ne sais pas par où commencer ».
• De l'analytics basique sur chaque action critique (signup, premier projet créé, première facture envoyée). Vous ne pouvez pas améliorer ce que vous ne mesurez pas.

Étape 2 : 50 → 200 clients — la taxe de scale

Les pages qui chargeaient en 200ms mettent maintenant 2 secondes. La base est OK, mais une requête spécifique (vous savez laquelle) fait un sequential scan sur un million de lignes. Un seul client bruyant avec de mauvaises données ralentit tout le tenant.

Ce qui casse en premier

• Les listings sans pagination. La page « tout afficher » devient une attente de 30 secondes.
• Les requêtes N+1 dans l'API. Chaque item de liste déclenche 5 allers-retours base. Ajoutez un trace ORM pour les trouver.
• Les jobs de fond exécutés en synchrone. « Envoyer email facture » bloque la requête. Mettez-le dans une queue.
• Une seule instance Postgres pour tout. Les read replicas aident. Un connection pooler (PgBouncer) aussi.

Étape 3 : 200 → 1 000 clients — la taxe organisationnelle

Maintenant les problèmes cessent d'être techniques. Ils deviennent organisationnels. Le fondateur ne peut plus relire chaque PR. Le customer success a besoin d'outils admin que l'engineering n'avait pas prévu de construire. Les sales veulent des prix custom. Les edge cases de facturation se multiplient.

Sur quoi investir

• Un panel admin interne. « Impersonate user », « prolonger l'essai », « émettre un remboursement », « corriger des données » — sans ça, chaque problème revient sur l'engineering.
• Du vrai RBAC. Owner / admin / member ne suffit plus. Les clients sont maintenant des équipes d'équipes.
• SSO et SCIM. Les clients enterprise les demandent dès le deuxième call commercial. Vous pouvez construire la version flexible une fois.
• Un deuxième ingénieur capable de livrer sans vous. Le plus gros bottleneck de scaling, c'est généralement la queue de PR du fondateur.

Le piège du rewrite

Quelque part entre 100 et 500 clients, quelqu'un dans l'équipe va dire « il faut tout réécrire ». Il a généralement tort. Le code du MVP est moche, mais il marche et il paie les factures. Ce dont vous avez vraiment besoin, c'est de refactoriser des parties spécifiques : la partie avec les pires bugs, la partie qui scale le moins bien, la partie que personne ne veut toucher.

Les rewrites tuent les SaaS. Les refactos ciblées non.

La conclusion ennuyeuse

Scaler un SaaS jusqu'à du vrai CA n'est pas une histoire de technologie. C'est l'histoire de retirer le fondateur du chemin critique de chaque décision, chaque bug, et chaque conversation client — sans perdre la qualité qui vous y a amené. La stack qui vous a amené à 50 clients est, avec une fréquence surprenante, la même qui vous emmène à 5 000.