Le périmètre minimal est une décision commerciale
La première version d’un SaaS ne doit pas être « le produit en plus petit ». Elle doit être la plus petite chose qu’un client accepte de payer. Ces deux définitions donnent des périmètres très différents, et la seconde permet de financer la suite.
Concrètement, cela signifie souvent : un seul cas d’usage traité complètement plutôt que cinq traités à moitié, pas de personnalisation, pas d’application mobile, et un tableau de bord d’administration minimal que vous opérez manuellement les premiers mois.
Le cloisonnement des données est le point critique
C’est la décision d’architecture la plus structurante et la plus difficile à modifier après coup. Une fuite de données entre clients est un incident dont un jeune éditeur ne se relève pas commercialement.
Nous appliquons trois règles. Le filtrage par client est appliqué globalement au niveau du modèle, jamais laissé à la charge de chaque requête. Un jeu de tests vérifie explicitement qu’un client ne peut pas atteindre les données d’un autre, y compris via l’API et les exports. Et toute requête écrite manuellement fait l’objet d’une revue spécifique.
Facturation : prévoir les cas laids
L’échec de paiement, le changement de palier en cours de mois, le remboursement partiel, la période d’essai qui expire un dimanche : ces cas représentent 10 % du code de facturation et 80 % des tickets de support quand ils sont mal traités. Nous les couvrons par des tests automatisés avant la mise en production.
