SaaS
Définition
Software as a Service. Logiciel hébergé dans le cloud, accessible par abonnement via un navigateur. Exemples : Slack, Notion, HubSpot. Vizion Web développe des SaaS sur-mesure pour B2B.
Le modèle
Un SaaS (Software as a Service) est un logiciel hébergé chez l'éditeur, accessible par abonnement via un navigateur ou une API. L'utilisateur paie un loyer mensuel ou annuel, et l'éditeur prend en charge les mises à jour, les serveurs, la sécurité, le support. Ce modèle a remplacé en quinze ans la quasi-totalité des logiciels métier installés sur poste. La promesse pour le client : pas de TMA à gérer, pas de migration majeure tous les cinq ans, des fonctionnalités qui évoluent en continu. La contrepartie : une dépendance forte au fournisseur et des coûts qui s'additionnent dans le temps.
Multi-tenant et isolation
Un SaaS B2B sérieux repose sur une architecture multi-tenant : tous les clients partagent la même infrastructure et la même base, mais chaque enregistrement est rattaché à une organisation et reste invisible aux autres. La RLS (Row Level Security) de PostgreSQL est l'outil le plus efficace pour bâtir cette isolation au niveau de la base, plutôt que dans chaque requête applicative. Pour les grands comptes qui exigent une isolation physique (données dans une base dédiée), on prépare l'architecture pour basculer un client en single-tenant à la demande, sans réécrire le produit.
Les métriques clés
On pilote un SaaS avec un quatuor d'indicateurs : acquisition (combien de nouveaux clients), activation (combien atteignent l'aha moment), rétention (combien restent au-delà de trois mois), et churn (combien partent chaque mois). Le MRR agrège la santé financière en un chiffre, la LTV et le CAC servent à mesurer si le modèle économique tient debout. Un SaaS qui acquiert vite mais churne fort coule, même avec une croissance affichée flatteuse. Ces métriques se construisent dès la première ligne de code : sans event tracking propre, on pilote à vue.
Quand un SaaS sur-mesure se justifie
La majorité des entreprises trouve leur bonheur dans un SaaS existant : HubSpot, Notion, Slack, Pipedrive couvrent 80% des besoins génériques. On bâtit un SaaS sur-mesure quand votre métier sort des sentiers battus, quand l'intégration avec votre back-office serait acrobatique, ou quand vous voulez en faire un produit que vous revendez à votre tour. Côté volume, en dessous de quelques milliers d'utilisateurs, l'investissement reste élevé face à l'abonnement à un outil existant. Au-delà, le sur-mesure devient rapidement plus rentable et offre un vrai actif.
Construire pour la durée
Un SaaS n'est pas un site vitrine livré une fois pour toutes. C'est un produit qui vivra plusieurs années, avec des dizaines de releases, des évolutions réglementaires, des montées en charge. On le construit en conséquence : authentification solide dès le départ, multi-tenant pensé en amont, monitoring et logs sur chaque action critique, CI/CD pour déployer sans douleur, tests automatisés sur les parcours sensibles. Couper ces fondations pour aller plus vite paye au début, et coûte trois fois plus cher à rattraper après douze mois de production.
Les coûts cachés
Le développement initial d'un SaaS représente souvent la moitié du coût total sur trois ans. Les autres postes : hébergement (qui scale avec le trafic), services tiers (Stripe, SendGrid, Twilio, fournisseur LLM), support utilisateur, maintenance évolutive, conformité (RGPD, audits sécurité), marketing produit. On prévoit aussi un budget pour les itérations basées sur les retours utilisateurs : un SaaS qui n'évolue pas perd progressivement face à la concurrence. On chiffre généralement 20 à 30% du coût initial chaque année en run et évolutions, plus pour les SaaS à forte croissance.
Les pièges classiques
Trois écueils reviennent sur les SaaS sur-mesure mal pilotés. Le premier : un périmètre initial trop large, qui retarde la mise en marché et brûle le budget avant la première vente. Le second : ignorer l'instrumentation jusqu'à ce qu'on en ait besoin, ce qui empêche de mesurer quoi que ce soit pendant les six premiers mois. Le troisième : sous-estimer les coûts de support et d'onboarding, qui peuvent dépasser le coût du développement en année 2. On préfère lancer un MVP focalisé sur le parcours critique, instrumenté dès le jour 1, plutôt qu'un produit complet jamais sorti.