197 milliards de dollars : le marché SaaS en 2023
En 2023, Gartner estime le marché mondial des logiciels SaaS à 197 milliards de dollars, en croissance de 17% par rapport à 2022. Plus significatif encore : Gartner prédit que 85% des applications business seront SaaS d'ici 2025. La transition vers le cloud n'est plus une tendance — c'est le standard. Dans ce contexte, créer un SaaS est devenu l'ambition de nombreux développeurs et entrepreneurs. Mais entre l'idée et le premier euro récurrent, il y a un monde de décisions techniques et commerciales que nous avons traversées avec RecruteX.
Cet article est un retour d'expérience honnête — avec les erreurs, les virages stratégiques et les chiffres réels.
L'idée : un problème réel avant une solution technologique
RecruteX est né d'une observation terrain : les agences de recrutement de taille intermédiaire (3 à 15 consultants) n'ont pas accès aux solutions adaptées. Les grands ATS (Applicant Tracking Systems) comme Workday ou SAP SuccessFactors coûtent entre 15 000 € et 80 000 €/an — hors de portée. Les outils gratuits ou à bas coût (Trello adapté, Google Sheets) créent des silos et ne permettent pas la collaboration multi-clients.
Le gap était clair : un ATS multi-tenant, pensé pour les agences de recrutement, à un tarif PME. Nous avons validé ce positionnement avec 8 entretiens téléphoniques avec des recruteurs avant d'écrire la première ligne de code.
L'architecture multi-tenant : le choix structurant
La décision architecturale la plus importante dans un SaaS B2B : comment isoler les données des clients ? Il existe trois approches :
- Base de données séparée par client : isolation maximale, coût infrastructure élevé, complexité de maintenance importante
- Schéma séparé par client (PostgreSQL) : bon compromis, mais complexe sur MySQL/MariaDB
- Tables partagées avec colonne tenant_id : le choix que nous avons fait
Nous avons opté pour l'option 3 avec une couche de sécurité stricte : chaque requête passe obligatoirement par un TenantManager qui injecte automatiquement le WHERE tenant_id = ?. Une fuite de données inter-tenants est architecturalement impossible si la règle est respectée. Nous avons des tests automatisés qui vérifient cette isolation à chaque déploiement.
Stripe : la bonne décision pour la monétisation
Nous avons intégré Stripe dès le premier sprint, avant même d'avoir notre premier client. Cette décision semble prématurée — elle était en réalité stratégique. Construire la monétisation en retard crée une dette technique difficile à rembourser et pousse à prendre des raccourcis dangereux.
Notre implémentation Stripe repose sur trois colonnes en base : stripe_customer_id, stripe_subscription_id et plan_actif. Nous n'utilisons pas le SDK Stripe officiel — nous avons développé un wrapper cURL minimaliste (StripeManager) qui gère les appels API, les webhooks et les erreurs. Avantage : zéro dépendance externe, contrôle total sur le comportement en cas d'erreur Stripe.
Le pricing : la décision la plus sous-estimée
Nous avons testé trois modèles de pricing en 6 mois :
- Freemium (1 client gratuit, puis payant) : trop peu de conversion, les utilisateurs gratuits n'avaient pas assez d'urgence à passer payant
- Per-seat (par consultant) : confusion sur ce qui comptait comme "siège", friction commerciale
- Per-client géré (le modèle actuel) : clair, proportionnel à la valeur perçue, conversion améliorée de 40%
Le pricing actuel de RecruteX : 49 €/mois jusqu'à 10 clients gérés, 89 €/mois jusqu'à 25 clients, 149 €/mois illimité. Ces tarifs ont été calibrés après analyse des alternatives du marché et entretiens avec des prospects.
De l'idée au premier client payant : la timeline réelle
- Semaine 1-2 : 8 entretiens téléphoniques, validation du problème
- Semaine 3-8 : développement MVP (authentification, gestion candidats, pipeline de suivi, multi-tenant basique)
- Semaine 9-10 : bêta fermée avec 2 agences partenaires
- Semaine 11 : intégration Stripe, page pricing, conditions générales
- Semaine 12 : premier client payant (89 €/mois)
- Mois 4 : 7 clients actifs, MRR à 580 €
- Mois 8 : 18 clients, première fonctionnalité payante supplémentaire (import CV automatique)
Ce qu'on referait différemment
En toute honnêteté : nous aurions investi plus tôt dans les tests automatisés. La base de tests unitaires n'a été construite qu'au mois 5 — ce qui a créé une zone de peur autour des refactorings importants pendant les 4 premiers mois. Avec une couverture de tests dès le début, on déploie plus sereinement et on rembourse moins de dette technique.
Vous avez un projet SaaS en tête ? Ou vous cherchez à digitaliser un processus métier récurrent avec une application sur mesure ? Discutons de votre idée →