Un outil qui tourne depuis trois ans chez un seul client, sans un bug, finit souvent par provoquer la même phrase : "Vous devriez le vendre à d'autres." L'idée est séduisante, et elle est presque toujours sous-estimée. Ce qui fonctionne pour une équipe de six personnes qui se connaissent n'est pas un produit, c'est un outil fait pour des habitudes précises.
En bref
Transformer un outil interne en SaaS demande de repenser trois choses : l'isolation des données entre clients, la facturation et le support. Le code existant se réutilise en partie, mais la réécriture de la couche multi-clients est rarement évitable. Comptez un cadrage sérieux avant toute ligne de code.
Un outil interne et un SaaS ne sont pas le même chantier
Je mets le verdict tout de suite, parce que c'est ce qu'on lit en dernier chez la plupart des éditeurs : dans la majorité des cas, transformer un outil interne en SaaS revient à construire un second produit, en réutilisant l'idée et quelques écrans du premier. Pas à "ouvrir" l'existant à d'autres entreprises.
La raison tient en une phrase. Un outil interne a un seul propriétaire de données, des utilisateurs qui ont été formés en direct, et un développeur joignable. Un SaaS a des dizaines de propriétaires de données qui ne doivent jamais se croiser, des utilisateurs qui n'appelleront personne avant de se plaindre, et un éditeur qui répond de tout.
L'agence Linkysoft estime dans son comparatif outil interne ou produit SaaS qu'un produit vendable coûte 40 à 60 % de travail de plus qu'un outil interne équivalent, et que le délai passe de 6 à 10 semaines à 5 à 9 mois. Ce sont des estimations d'éditeur, pas une étude indépendante, et je les cite comme des ordres de grandeur. Mais elles recoupent ce que je vois sur mes propres produits : le surcroît ne vient pas des fonctionnalités, il vient de tout ce qui entoure.
Le multi-client, ce que ça change dans le code
C'est le point technique qui décide du reste. Dans un outil interne, la table des commandes contient les commandes de l'entreprise. Dans un SaaS, elle contient celles de tout le monde, et chaque requête doit savoir de quel client elle parle.
Le document de référence d'AWS sur les principes de l'architecture SaaS rappelle une chose que beaucoup d'éditeurs oublient : "Le SaaS est davantage un modèle commercial qu'une stratégie d'architecture." Même avec une pile dédiée par client, on reste en multi-client dès lors que l'intégration, l'identité, la facturation et l'exploitation sont gérées collectivement. Autrement dit, la question n'est pas seulement "où sont stockées les données", mais "comment j'opère cinquante clients sans y passer toutes vos journées".
Il existe trois grandes manières de séparer les clients, et le choix engage votre modèle économique.
| Modèle | Isolation | Coût d'infrastructure | Convient quand |
|---|---|---|---|
| Base partagée, un identifiant client sur chaque ligne | Logique, par le code | Le plus bas | Beaucoup de petits clients similaires |
| Base partagée, un schéma par client | Forte, par la base | Intermédiaire | Quelques dizaines à quelques centaines de clients professionnels |
| Une base par client | Maximale | Le plus élevé | Peu de clients, exigences contractuelles fortes |
Le cabinet Lonestone, dans son guide de l'architecture multi-tenant, indique qu'une approche multi-instance peut multiplier les coûts d'infrastructure par 3 à 5 par rapport à une base mutualisée. C'est la raison pour laquelle le modèle d'isolation se décide avant de parler de tarif, pas après. Et l'agence Edana défend, dans son analyse de la conception d'un SaaS multi-tenant, que la vraie difficulté est l'architecture métier plus que la technologie. Je partage ce point de vue, avec une nuance : l'un ne va pas sans l'autre.
Mon avis, qui n'engage que moi : pour un outil de gestion destiné à des TPE ou des PME, la base partagée avec isolation stricte par client est presque toujours le bon départ. À condition d'accepter la contrepartie, une discipline absolue sur chaque requête et des tests qui vérifient explicitement qu'un client ne peut jamais lire les données d'un autre.
Ce que mes propres produits m'ont appris
Je suis éditrice avant d'être prestataire sur ce sujet : Pictogramaweb édite Simply Spa, Simply Resa, Postwa et Geko, et j'ai développé pour un groupe médical un outil de planification dont les droits ont été cédés. Ce que j'en retiens tient en quelques constats sans flatterie.
Le premier : la facturation ne se bricole pas. Sur Simply Resa, plateforme de réservation pour l'hébergement et le spa, la caisse délègue la production des tickets et factures à un outil certifié plutôt que de réinventer un journal de caisse. Ce choix évite de maintenir soi-même une conformité qui n'est pas mon métier. J'ai aussi repoussé volontairement une refonte du paiement tant que les modules prioritaires n'étaient pas livrés. Ce n'est pas glorieux, mais un SaaS se construit dans l'ordre de ce qui rapporte de la confiance, pas dans l'ordre de ce qui est élégant.
Le deuxième : l'héritage mono-client est un risque réel. Sur l'un de mes outils métier, un reste de code pensé pour un seul client a été identifié comme pouvant, mal traité, exposer des données d'un client à un autre. Il a fallu le lister, le qualifier et le corriger avant toute extension à d'autres structures. Si vous partez d'un outil interne, cherchez ce genre de reste avant de signer le moindre nouveau client.
Le troisième : le support devient un produit. Sur Simply Spa, les réponses aux clients sont écrites, vérifiées dans le compte concerné, jamais improvisées. Cela prend du temps, et c'est exactement ce que personne ne budgète au moment de décider de vendre.
Les cinq chantiers qui n'existent pas dans un outil interne
Voici ce qu'il faut prévoir avant le premier client extérieur, et ce qui explique l'essentiel de l'écart entre les deux projets.
Comment gérer les comptes et les droits de chaque entreprise cliente ?
Il faut distinguer l'entreprise cliente, ses utilisateurs et les rôles qu'ils portent. Un outil interne se contente souvent d'un administrateur et de quelques utilisateurs. Un SaaS doit permettre à chaque client de gérer ses propres équipes, et à vous d'intervenir sur un compte sans voir ce que vous n'avez pas à voir.
Comment facturer par abonnement sans y passer ses soirées ?
Abonnement, période d'essai, changement de formule, échec de paiement, résiliation, remboursement : chaque cas est une règle à écrire et à tester. Un prestataire de paiement gère le débit, mais pas la logique de vos formules. C'est le chantier qui paraît le plus simple et qui déborde le plus.
Que faire des données personnelles de vos clients ?
Dès que vous hébergez les données d'autres entreprises, vous changez de statut. Le guide du sous-traitant de la CNIL précise qu'un éditeur devient sous-traitant lorsqu'il traite des données personnelles pour le compte et sur instruction de son client. Le contrat doit alors définir l'objet et la durée du traitement, sa finalité, les types de données et les catégories de personnes concernées. L'éditeur doit aussi alerter son client si une instruction lui paraît contraire aux règles de protection des données. Cela s'écrit avant la première signature, pas après la première question d'un client. Sur ce point précis, faites relire vos documents par un avocat.
Qui répond quand ça ne marche pas ?
Un outil interne a un interlocuteur. Un SaaS a une file de demandes, des priorités et des engagements de réponse. Linkysoft avance une moyenne de 0,3 à 0,8 message de support par client et par mois dans son comparatif, une observation d'éditeur à prendre avec prudence, mais qui montre l'ordre de grandeur : plus vous avez de clients, plus votre temps de développement se réduit.
Où sont hébergées les données, et à qui appartient le code ?
Ces deux questions se posent à vos clients, et ils vous les poseront. J'y consacre deux articles, l'un sur l'hébergement d'un logiciel métier, l'autre sur la propriété du code d'un logiciel sur mesure. Si vous n'avez pas de réponse claire, vous n'êtes pas prêt à vendre.
Faut-il vraiment vendre son outil interne ?
Voici le tableau de décision que j'utilise quand une entreprise me pose la question.
| Situation | Ce que je recommande |
|---|---|
| Un seul client très satisfait, pas de demande extérieure | Garder l'outil interne, le faire évoluer |
| Trois entreprises du même métier demandent spontanément l'outil | Cadrer un produit, en repartant de la structure de données |
| Le secteur a déjà un logiciel établi qui fait 80 % du besoin | Ne pas vendre, intégrer l'existant |
| L'outil repose sur une particularité propre à votre organisation | Rester en outil interne |
Notez que je ne propose jamais "vendre pour amortir". Si la seule raison de transformer un outil en produit est de rentabiliser un investissement passé, c'est un mauvais départ : le marché ne paie pas vos coûts, il paie un problème résolu. Cette idée est le point où je suis le plus en désaccord avec ce que racontent beaucoup d'agences, qui présentent la revente comme une suite logique plutôt qu'un pari.
Comment procéder sans tout refaire
Si la décision est prise, je procède dans cet ordre. D'abord un cadrage écrit du périmètre : ce que le produit fait pour tous les clients, et ce qui reste du cas particulier. C'est le même exercice que celui d'un cahier des charges d'application métier, avec une question de plus : que se passe-t-il quand un client demande une exception ?
Ensuite, l'isolation des données et les comptes, avant tout nouvel écran. Puis un premier client extérieur, choisi pour sa proximité avec le métier d'origine, avec lequel on valide le parcours complet, de l'inscription à la facture. La logique rejoint celle d'un MVP d'application métier : un périmètre volontairement réduit, livrable en environ 1 mois pour un cadrage bien posé, puis on élargit. Pour la facturation, on ajoute en dernier ce qui n'est pas indispensable à la première vente.
Je détaille ma manière de travailler sur ce type de projet sur la page consacrée au développement de SaaS sur mesure. Les budgets dépendent de facteurs que l'on pose en rendez-vous : le nombre de clients visés, le niveau d'isolation demandé, la part d'existant réutilisable, les exigences contractuelles et le volume de support prévu.
Mon verdict
Transformer un outil interne en SaaS est un bon projet quand le besoin est déjà exprimé par plusieurs entreprises, et un mauvais quand il vient d'un désir d'amortir. Le code est la partie la plus visible et la moins difficile. Le plus dur, c'est de tenir la promesse faite à des clients que vous ne connaissez pas encore, jour après jour. Si vous hésitez, parlons-en : un échange suffit en général pour savoir si votre outil mérite un second cadrage.
Questions fréquentes
Peut-on transformer un outil interne en SaaS sans le réécrire ?
Rarement en totalité. Les écrans et une partie de la logique métier se réutilisent, mais la couche qui sépare les clients, les comptes, la facturation et l'exploitation se construit presque toujours. Un audit de l'existant dit ce qui se garde.
Quelle architecture multi-client choisir pour une TPE ou une PME ?
Pour un produit destiné à beaucoup de petits clients, une base partagée avec isolation stricte par client est souvent le meilleur départ. Si vous visez peu de clients avec des exigences contractuelles fortes, une base par client devient défendable.
Combien de temps faut-il pour sortir un premier produit vendable ?
Un MVP bien cadré se compte en environ 1 mois. Un produit complet, avec facturation, support et conformité, demande nettement plus, et dépend surtout de ce qu'on accepte de laisser pour plus tard.
Devient-on sous-traitant au sens du RGPD en vendant un logiciel ?
Cela dépend de l'accès aux données. D'après la CNIL, un éditeur qui traite des données personnelles pour le compte et sur instruction de son client est sous-traitant et doit un contrat conforme à l'article 28. Faites valider ce point par un avocat.
Photo : Rodeo Project Management Software sur Unsplash
