B2B
Définition
Business-to-Business. Modèle où l'on vend à des entreprises (et non à des particuliers). La majorité des SaaS et applications métier que Vizion Web développe sont B2B.
Le modèle
B2B désigne la vente à des entreprises, par opposition à B2C qui vise des particuliers. Le cycle de vente s'étire sur des semaines voire des mois, les décisions impliquent plusieurs personnes (utilisateur, manager, achats, IT, juridique), et les contrats sont rédigés au cas par cas avec négociation de prix, de conditions et de SLA. Le revers : un client B2B vaut généralement 100 à 1000 fois plus qu'un client B2C. Les marges sont meilleures, les renouvellements plus prévisibles, et la concurrence moins agressive que sur les marchés grand public.
Ce qui différencie un produit B2B
Un SaaS B2B intègre des fonctionnalités absentes du B2C : multi-tenant avec isolation des données, gestion fine des rôles et permissions, SSO via SAML ou OIDC dès qu'on cible des ETI, audit logs pour la conformité, exports massifs, intégrations API avec les outils existants du client. La facturation sort du modèle carte bancaire : devis, bons de commande, paiement à 30 ou 60 jours, virement, parfois prélèvement SEPA. Le support attendu monte en gamme : email avec SLA, chat dédié, account manager sur les gros comptes. Un produit B2B n'est pas un produit B2C avec un autre prix, c'est une autre conception.
L'acquisition B2B
L'inbound marketing seul ne suffit pas pour un SaaS B2B sérieux. On combine plusieurs canaux : SEO sur les requêtes métier, contenu d'expertise (études, comparatifs, webinars), outbound ciblé (LinkedIn, e-mail à froid sur des comptes qualifiés), événements, partenariats avec des consultants ou intégrateurs. Le cycle de vente impose un CRM rigoureux pour suivre chaque opportunité sur sa durée. Le commercial reste central, même sur les produits self-serve : à partir d'un certain panier moyen, les prospects veulent parler à un humain avant de signer. Compter 6 à 12 mois pour stabiliser un funnel B2B fonctionnel.
Les pièges techniques
Le multi-tenant mal isolé est le risque numéro un : un bug qui expose les données d'un client à un autre tue la confiance et la croissance d'un coup. On utilise la RLS PostgreSQL, on teste les permissions à chaque release, on segmente même les logs et les exports. Deuxième piège, les intégrations sur mesure réclamées par les gros clients : utiles pour signer un deal, dangereuses pour la maintenance si on les laisse diverger. Troisième piège, la dette technique de la première version qui ne supporte pas la montée en charge : 50 clients sur un Supabase démarré au plus simple, ça craque. On anticipe ces seuils au cadrage initial.
Les indicateurs à suivre
MRR, ARR, churn (logo et revenu), CAC, LTV, payback period : le quartet de base. On y ajoute l'expansion (clients qui upgradent), le NRR (revenu net rétention) qui combine churn et expansion, le pipeline value par stade commercial, et le sales cycle moyen. Pour un SaaS B2B sain, on vise un NRR supérieur à 100% (les clients existants génèrent plus chaque année), un payback period sous 18 mois, et un churn logo annuel sous 10% sur les PME, sous 5% sur les ETI. Ces seuils servent à arbitrer entre acquisition pure et rétention/expansion.
Quand viser le B2B
Le B2B est pertinent quand votre produit résout un vrai problème métier qui justifie un budget récurrent : gain de temps mesurable, économie directe, mise en conformité, augmentation du chiffre. Si le produit est consommé en self-serve sans support, sans rôles, sans intégration, vous êtes probablement plutôt sur du B2C ou du PLG (product-led growth) avec des entreprises clientes. Le B2B vrai demande une vraie expertise du métier visé : on ne vend pas un outil RH à des DAF, ni un logiciel BTP à des marketeurs. Le ciblage vertical accélère drastiquement la traction commerciale.
Notre angle Vizion Web
La majorité des SaaS sur-mesure qu'on développe sont B2B. Le marché est moins saturé que le B2C, l'unitaire plus élevé, et l'investissement initial mieux récompensé par la durée de vie des clients. On démarre par un cadrage produit qui décrit le multi-tenant, les rôles, les intégrations attendues, puis on livre une première version en 8 à 12 semaines avec Next.js, Supabase et Stripe. On reste ensuite sur le projet pour faire évoluer le produit selon les retours des premiers clients, qui sont presque toujours différents des hypothèses initiales. C'est une discipline d'itération autant qu'une discipline technique.