Architecture SaaS avec Symfony : multi-tenant et abonnements
Comment structurer une application SaaS avec Symfony : isolation des données entre clients (multi-tenancy), abonnements, scalabilité et sécurité. Les choix d'architecture qui conditionnent la suite du produit. Pour faire construire votre produit, voir ma prestation de développement SaaS Symfony.
Piliers d'une architecture SaaS
- ✓ Multi-tenancy : isolation données par client
- ✓ Abonnements : Stripe, essais gratuits, plans
- ✓ Scalabilité : architecture horizontale, cache
- ✓ Sécurité : gestion des rôles, 2FA, audit logs
- ✓ API : REST pour intégrations tierces
- ✓ Analytics : tableaux de bord, metrics
Stack technique SaaS
Multi-tenant avec Symfony : isoler les données de chaque client
Dans un SaaS, tous vos clients utilisent la même application. La règle absolue : un client ne doit jamais voir les données d'un autre. Il existe plusieurs façons d'organiser cette isolation avec Symfony et Doctrine, et le bon choix dépend de votre marché, de vos contraintes réglementaires et de votre budget d'exploitation.
Base partagée + tenant_id
Toutes les tables portent une colonne tenant_id, filtrée automatiquement par un filtre Doctrine global. La solution la plus simple et la moins coûteuse à exploiter, adaptée à la majorité des SaaS B2B qui démarrent.
Une base par client
Chaque client dispose de sa propre base MySQL, sélectionnée à la connexion. Isolation maximale : sauvegarde, restauration et suppression par client, utile pour les exigences contractuelles ou réglementaires (santé, finance). En contrepartie, chaque migration doit être appliquée à toutes les bases.
Modèle hybride
La majorité des clients partage une base commune, et les grands comptes qui l'exigent obtiennent une base dédiée. Le code reste le même : seule la connexion change selon le client. Une façon de démarrer simplement sans fermer la porte aux exigences futures.
Ce que je mets en place, quelle que soit la stratégie
- ✓ Résolution du client courant (sous-domaine, en-tête ou utilisateur connecté) dans un listener Symfony, avant tout accès aux données
- ✓ Filtre Doctrine activé automatiquement, pour qu'une requête oubliée ne puisse pas remonter les données d'un autre client
- ✓ Voters Symfony qui vérifient l'appartenance de chaque ressource au client, en complément du filtre
- ✓ Identifiant du client transmis aux tâches asynchrones (Symfony Messenger) et clés de cache préfixées par client
- ✓ Tests automatisés qui vérifient qu'un utilisateur du client A ne peut ni lire ni modifier une donnée du client B
- ✓ Un client Stripe par tenant, et des webhooks qui ouvrent ou ferment les fonctionnalités selon le plan souscrit
Vous partez d'une application mono-client à transformer en SaaS ? C'est une migration fréquente : on commence généralement par la base partagée avec tenant_id, puis on fait évoluer l'architecture si le besoin d'isolation grandit. Voir aussi mon accompagnement SaaS.
Projets SaaS réalisés
Les Annonces CHR
Reprise d'une plateforme d'annonces PHP 7 abandonnée par deux développeurs : stabilisée, puis plus de 35 000 annonces publiées.
Voir le projetPlateforme d'échange experts
Réseau social privé et intranet métier pour plus de 400 experts automobiles rattachés à un grand assureur : messagerie, documents, cotisations.
Voir le projetSaaS d'analyse de soft skills
SaaS de recrutement qui révèle les soft skills des candidats par un parcours ludique, sans CV. Livré et mis en service en 3 mois.
Voir le projetQuestions fréquentes
Base partagée ou base par client pour un SaaS multi-tenant ?
La base partagée avec une colonne tenant_id filtrée par Doctrine convient à la majorité des SaaS B2B : simple et peu coûteuse à exploiter. La base par client se justifie quand l'isolation est une exigence contractuelle ou réglementaire, au prix d'une exploitation plus lourde.
SaaS ou application métier classique : quelle différence ?
Un SaaS est multi-tenant (plusieurs clients dans la même application) et facturé par abonnement. Une application métier classique est déployée pour un seul client. L'architecture, notamment l'isolation des données, est différente.
Quel est le budget pour un MVP SaaS ?
Entre 8 000 € et 15 000 € selon la complexité. Un MVP fonctionnel (authentification, abonnements Stripe, tableau de bord, API) peut être livré en 6 à 8 semaines.
Combien de temps pour développer un SaaS de zéro ?
MVP fonctionnel en 6 à 8 semaines. Version complète avec fonctionnalités avancées : 3 à 6 mois. Je fournis un planning détaillé avant de démarrer.
Comment Stripe gère-t-il les abonnements dans un SaaS ?
Stripe Billing gère les plans tarifaires, les essais gratuits, les changements de plan, les relances en cas d'échec de paiement et la facturation. Intégré via webhooks pour synchroniser l'état de l'abonnement côté Symfony.
Besoin de développement SaaS pour votre projet ? → Prestation SaaS Symfony : de l'idée au produit, livrables et tarifs
Pour aller plus loin
Lancer votre SaaS ?
Discutons de votre idée et de l'architecture la plus adaptée.
Prendre rendez-vous