Pourquoi les éditeurs basculent
Le modèle de la licence installée a bien fonctionné pendant vingt ans. Ce qui l'a rendu difficile à tenir, ce n'est pas la mode du cloud, c'est l'arithmétique : chaque client ajouté alourdit le support au lieu de l'amortir, et chaque version déployée sur le terrain se paie en interventions.
Un revenu qui se répète
La licence vendue une fois oblige à reconquérir le marché chaque année. L'abonnement transforme un chiffre d'affaires en socle.
Un support qui cesse de vous ruiner
Maintenir douze versions installées chez douze clients coûte plus cher que d'en maintenir une seule que vous hébergez.
Des mises à jour qui arrivent enfin
Un correctif déployé une fois profite à tout le monde le jour même, au lieu d'attendre la prochaine intervention chez chaque client.
Une valorisation qui change de nature
Un éditeur qui vend des licences se valorise sur son résultat. Un éditeur avec du revenu récurrent se valorise sur un multiple de ce revenu.
Le dernier point est celui qui décide le plus souvent. Un éditeur qui vend des licences se valorise sur son résultat, avec un multiple modeste. Le même éditeur avec un revenu récurrent installé change de catégorie aux yeux d'un acquéreur ou d'un investisseur.
Les trois chemins
Aucun n'est meilleur dans l'absolu. Le bon dépend de l'état de votre code, de la patience de votre trésorerie et de ce que vos clients accepteront.
Héberger tel quel
Vous prenez le logiciel existant et vous l'installez sur vos serveurs, une instance par client. Rien à réécrire, la bascule commerciale peut démarrer en quelques semaines.
Quand le choisir
Valider l'appétence de vos clients pour l'abonnement sans engager de développement lourd.
Ce que ça coûte
Vos coûts d'hébergement grimpent proportionnellement au nombre de clients, et vous maintenez toujours autant de versions. Ce n'est pas un SaaS, c'est un hébergement infogéré.
Mutualiser par étapes
Vous gardez le coeur applicatif et vous refondez d'abord ce qui bloque la mutualisation : la gestion des comptes, l'isolation des données, la facturation. Le reste suit par lots.
Quand le choisir
Le meilleur rapport risque sur résultat dans la majorité des cas. Vous restez commercialisable pendant toute la transition.
Ce que ça coûte
Une période où vous faites tourner deux modèles en parallèle, avec la complexité que ça implique pour vos équipes.
Reconstruire le socle
Vous repartez sur une architecture pensée multi-tenant dès le départ, en reprenant les règles métier accumulées dans l'ancien produit.
Quand le choisir
Justifié quand le logiciel existant est trop ancien pour évoluer, ou quand l'ambition commerciale dépasse largement le produit actuel.
Ce que ça coûte
Le plus long et le plus cher. Le risque classique consiste à sous-estimer le savoir métier enfoui dans un code de quinze ans.
Dans la majorité des dossiers qu'on voit, le deuxième chemin l'emporte. Le premier sert de rampe de lancement commerciale, le troisième se réserve aux produits dont la technologie d'origine ne suit plus. Le choix se tranche sur un audit de quelques jours, pas sur une intuition.
Ce qui coince en pratique
Les difficultés d'une bascule vers le SaaS sont rarement là où on les attend. Le code se traite. Ce qui suit se traite moins bien s'il n'a pas été anticipé.
Le client qui refuse le cloud
Une partie de votre base a des raisons réelles de vouloir garder ses données chez elle, parfois contractuelles. Prévoyez de faire cohabiter les deux modèles pendant des années, pas des mois.
La tarification qu'il faut refaire entièrement
Passer d'une licence à un abonnement mensuel ne se fait pas en divisant par douze. Vous changez de promesse, donc de grille. C'est un chantier commercial autant que technique.
Le creux de revenu de la transition
Vous arrêtez de vendre des licences avant que les abonnements aient atteint le même niveau. Ce creux dure entre douze et vingt-quatre mois et se prépare en trésorerie.
Le support qui explose au lancement
Héberger vos clients vous rend responsable de leur disponibilité. Les incidents qui étaient les leurs deviennent les vôtres, avec des attentes de réponse plus fortes.
Le socle technique à construire
Quel que soit le chemin retenu, trois briques changent de nature. L'isolation des données, pour que cent clients cohabitent sans jamais se voir. La gestion des comptes et des droits, puisque vos clients administreront eux-mêmes leurs utilisateurs. La facturation récurrente, avec ses plans, ses changements de formule et ses impayés.
La première est la plus structurante et la plus mal comprise. Elle mérite une page à elle seule : les trois modèles d'architecture multi-tenant et comment choisir entre eux. Pour le reste du socle, voir la création de plateforme SaaS.
Budget
Les ordres de grandeur suivent les trois chemins. Industrialiser l'hébergement du produit existant demande 15 000 à 25 000 euros. Mutualiser par étapes se situe entre 50 000 et 100 000 euros. Reconstruire le socle dépasse généralement 100 000 euros.
Ces fourchettes ne veulent pas dire grand-chose tant que l'état réel du code n'est pas connu. C'est pour ça qu'on commence toujours par un audit, dont le coût reste sans commune mesure avec la décision qu'il éclaire.
Pour situer les ordres de grandeur :
FAQ
Combien coûte la transformation d'un logiciel en SaaS ?
Le simple hébergement du produit existant, une instance par client, démarre autour de 15 000 à 25 000 euros de travaux d'industrialisation. Une mutualisation par étapes se situe généralement entre 50 000 et 100 000 euros selon l'état du code. Une reconstruction complète du socle dépasse souvent 100 000 euros. L'audit préalable, qui conditionne le choix, reste modeste au regard de ces montants.
Combien de temps prend le passage au SaaS ?
Quelques semaines pour un hébergement en l'état, six à douze mois pour une mutualisation par étapes, douze à dix-huit mois pour une reconstruction. Ces durées concernent la partie technique. La transition commerciale de votre base installée s'étale souvent sur deux à trois ans en parallèle.
Faut-il tout réécrire pour devenir multi-tenant ?
Rarement en totalité. Ce qui doit changer, c'est la couche qui gère les comptes, l'isolation des données et la facturation. Les règles métier, qui représentent l'essentiel de la valeur accumulée, se conservent le plus souvent. Une réécriture complète se justifie surtout quand la technologie d'origine n'est plus maintenue.
Comment gérer les clients qui veulent rester en installation locale ?
En assumant les deux modèles pendant la durée nécessaire, et en le chiffrant honnêtement. Maintenir une version installable a un coût réel qui doit se retrouver dans le prix de cette offre. Beaucoup d'éditeurs facturent la version locale nettement plus cher, ce qui règle la question progressivement.
Peut-on passer au SaaS sans changer de technologie ?
Souvent oui, si la technologie d'origine est encore maintenue et sait tourner en environnement serveur. Le sujet n'est pas le langage mais l'architecture : la manière dont les données sont séparées, dont les comptes sont gérés, dont les mises à jour se déploient. Un audit tranche ce point en quelques jours.
Quelle différence avec une reprise de SaaS classique ?
Une reprise concerne un produit déjà en ligne dont le code pose problème. Ici, le produit fonctionne mais son modèle de distribution change : il passe d'une installation chez chaque client à une plateforme unique que vous hébergez et facturez par abonnement. C'est d'abord une transformation de modèle économique.
Un logiciel à faire passer en SaaS ?
30 minutes pour comprendre votre produit, votre base installée et vous dire lequel des trois chemins vous correspond.
Réserver un appel