Transformer un outil interne en SaaS commercialisable, c’est passer d’une application qui sert une entreprise à une plateforme qui en sert plusieurs, sans développement spécifique pour chacune et contre un abonnement. Le chemin tient en quatre étapes : valider qu’un marché existe hors de vos murs, rendre l’outil multi-clients et paramétrable, sécuriser la propriété du code et le cadre juridique, puis organiser le produit (support, feuille de route, facturation). La difficulté est rarement technique en premier lieu : elle est commerciale et organisationnelle.
Le scénario est fréquent dans les PME et ETI : un outil de planification, de suivi qualité ou de gestion de chantier développé pour vos équipes fonctionne si bien que des partenaires, des fournisseurs ou même des concurrents demandent à l’utiliser. L’idée de le vendre est séduisante. Voici comment l’évaluer sérieusement.
Votre outil a-t-il vraiment un marché ?
Un outil interne réussi résout votre problème, avec vos règles. Un SaaS doit résoudre un problème partagé par de nombreuses entreprises, qui accepteront d’adapter un peu leurs habitudes à votre produit. La première question n’est donc pas « comment le rendre multi-clients ? » mais « qui d’autre paierait pour ça, et pourquoi n’utilise-t-il pas déjà une solution du marché ? ».
Quelques signaux solides :
- des demandes spontanées et répétées, venant d’entreprises sans lien commercial avec vous ;
- un problème propre à un secteur mal couvert par les grands éditeurs, trop généralistes ou trop chers à adapter ;
- une avance métier : votre outil encode un savoir-faire que les solutions existantes n’ont pas ;
- des entreprises prêtes à payer un pilote, pas seulement à « regarder la démo ».
Le test le plus fiable consiste à présenter l’outil à cinq ou dix entreprises cibles, à observer ce qu’elles devraient changer pour l’adopter, puis à proposer un pilote payant à deux ou trois d’entre elles. Si personne ne signe, mieux vaut le savoir avant d’investir. C’est la logique du MVP appliqué aux PME et ETI : apprendre au moindre coût.
Ce qui sépare un outil interne d’un SaaS
Les écarts se situent sur une dizaine de dimensions. Le tableau suivant sert de grille d’audit : chaque ligne où votre outil est dans la colonne de gauche représente un chantier.
| Dimension | Outil interne typique | SaaS commercialisable |
|---|---|---|
| Clients servis | Une seule entreprise | Plusieurs entreprises isolées les unes des autres |
| Règles métier | Codées en dur, à votre image | Paramétrables par client, dans des limites définies |
| Création des comptes | Faite par la DSI | Inscription ou mise en service autonome |
| Authentification | Annuaire de l’entreprise | Comptes par client, invitation, authentification forte, fédération d’identité pour les grands comptes |
| Données | Une seule base, sans notion de client | Identifiant de client partout, export et suppression par client |
| Mises à jour | Quand l’équipe interne le décide | Planifiées, communiquées, sans interruption |
| Support | Un collègue au bout du couloir | Documentation, centre d’aide, niveaux de service |
| Facturation | Aucune | Abonnements, offres, relances |
| Sécurité | Réseau interne de confiance | Exposition publique, tests d’intrusion, questionnaires de sécurité des clients |
| Contrat | Aucun | Conditions générales, accord de sous-traitance des données, engagements de service |
Le guide d’architecture de Microsoft consacré aux solutions multi-tenant rappelle que ces choix (modèle d’isolation, cycle de vie des clients, mesure de la consommation) se décident tôt, car ils sont coûteux à changer une fois le produit en production.
Les cinq chantiers techniques
1. Rendre la plateforme multi-clients
C’est le chantier le plus structurant. Chaque donnée doit appartenir à un client identifié, et l’application doit garantir qu’aucune requête ne puisse renvoyer les données d’un autre. Les modèles possibles (base partagée, base par client, approche hybride) sont détaillés dans notre article sur l’architecture multi-tenant d’un SaaS B2B. Pour un outil existant, la difficulté est d’ajouter cet identifiant partout sans casser l’usage interne en cours.
2. Transformer les règles maison en paramètres
Votre outil reflète vos processus : vos statuts, vos circuits de validation, vos libellés, vos calculs. Un client extérieur aura les siens. Il faut distinguer trois niveaux :
- ce qui est commun à tous les clients et ne se discute pas (le cœur du produit) ;
- ce qui est paramétrable par chaque client dans un écran d’administration (statuts, champs, modèles de documents, seuils) ;
- ce qui est spécifique et que vous refuserez de développer, ou facturerez comme une prestation à part.
La tentation est de tout rendre paramétrable. C’est une erreur : chaque paramètre multiplie les cas à tester et alourdit l’interface. On ne paramètre que ce que plusieurs clients ont réellement demandé.
3. Permettre la mise en service sans intervention
Tant qu’un nouveau client exige qu’un développeur crée sa base ou configure son espace à la main, vous vendez une prestation, pas un SaaS. Création du compte, invitation des collègues, import des données de départ, premiers pas guidés : c’est tout l’enjeu de l’onboarding des utilisateurs d’un SaaS B2B.
4. Facturer et mesurer
Il faut un catalogue d’offres, des abonnements, des relances en cas d’impayé, et les droits d’accès qui en découlent. Le guide de Microsoft sur les modèles de tarification recommande de mesurer la consommation de chaque client, même avec un forfait, pour vérifier que le coût de service reste inférieur au revenu. Il note aussi que la refacturation au coût réel convient bien aux usages internes : c’est peut-être le modèle de votre outil aujourd’hui, mais pas celui d’un produit commercial. Nous détaillons ces mécanismes dans abonnements et facturation récurrente.
5. Exploiter un service pour des clients exigeants
Supervision, sauvegardes restaurables client par client, mises à jour sans interruption, environnement de test, journal des actions : ce que tolère un usage interne ne passe plus avec des clients qui paient. Le cadre SaaS Lens d’AWS est une bonne liste de contrôle pour ces sujets d’exploitation.
Propriété du code et cadre juridique : les vérifications préalables
Avant de vendre, assurez-vous que vous avez le droit de vendre. Trois situations se présentent.
- L’outil a été développé par vos salariés. L’article L113-9 du Code de la propriété intellectuelle prévoit que les droits patrimoniaux sur les programmes et leur documentation créés par des employés dans l’exercice de leurs fonctions sont dévolus à l’employeur, sauf stipulation contraire. La situation est en principe saine, mais les stagiaires, freelances et dirigeants non salariés ne sont pas couverts par cette règle.
- L’outil a été développé par une agence ou un indépendant. Sans cession écrite des droits, couvrant notamment la commercialisation auprès de tiers, vous n’êtes pas propriétaire au sens où vous l’entendez. C’est le sujet de notre article sur la propriété du code source et la réversibilité.
- L’outil intègre des composants tiers. Bibliothèques open source, modèles de documents, données de référence, services d’IA : leurs licences autorisent-elles un usage commercial en SaaS ? Un inventaire s’impose.
Côté données personnelles, votre position change. En hébergeant les données de vos clients, vous devenez leur sous-traitant au sens du RGPD. La CNIL rappelle que le sous-traitant a des obligations propres de sécurité, de confidentialité et de documentation, doit tenir un registre des traitements effectués pour ses clients et les assister, notamment pour les audits et la notification des violations. Il faut donc un accord de sous-traitance annexé à vos conditions générales, et une liste de vos propres sous-traitants (hébergeur, envoi d’e-mails, paiement).
Qui porte le produit dans l’entreprise ?
C’est souvent là que les projets échouent. Un SaaS a besoin d’un responsable produit qui arbitre entre les demandes des clients, d’une équipe de support qui répond dans des délais annoncés, et d’une feuille de route publique ou au moins partagée avec les clients. Si l’outil reste piloté par la direction des opérations qui l’a fait naître, les besoins internes passeront toujours en premier, et les clients externes le sentiront.
| Question d’organisation | Option prudente | Option ambitieuse |
|---|---|---|
| Structure | Activité rattachée à l’entreprise | Société dédiée, éventuellement avec associés |
| Équipe produit | Un responsable produit à temps partiel, agence en appui | Équipe produit et technique dédiée |
| Commercialisation | Partenaires et réseau existant | Équipe commerciale et marketing dédiée |
| Support | Plage horaire limitée, centre d’aide | Support étendu, engagements de service contractuels |
Il n’y a pas de mauvais choix, mais il doit être cohérent avec l’ambition : on ne vise pas des grands comptes avec un support assuré « quand quelqu’un a le temps ».
Faire évoluer l’existant ou repartir d’une base neuve ?
L’outil interne a une valeur immense : il contient des années de règles métier validées sur le terrain. Mais son code a souvent été écrit vite, pour un seul client, et il porte une dette technique qui deviendra pénalisante.
Trois approches se rencontrent :
- Évolution progressive : ajout de l’identifiant client, extraction des paramètres, renforcement de la sécurité, sur l’outil existant. Adaptée quand le code est sain et testé.
- Refonte progressive : construction d’une nouvelle plateforme qui remplace l’ancienne module par module, pendant que l’usage interne continue, selon la méthode décrite dans moderniser une application historique.
- Nouveau produit : l’outil interne sert de spécification vivante, et le SaaS est construit à côté. Adaptée quand l’écart est trop important ou la technologie obsolète.
Le bon choix sort d’un audit du code et de l’architecture, pas d’une préférence de principe.
La feuille de route en sept étapes
- Valider le marché auprès d’entreprises extérieures, jusqu’à obtenir des engagements de pilote.
- Auditer l’outil avec la grille ci-dessus : écarts techniques, dette, sécurité, propriété du code.
- Définir l’offre : périmètre commun, paramètres, ce qui ne sera jamais spécifique, modèle de tarification.
- Sécuriser le juridique : cession de droits, licences, conditions générales, accord de sous-traitance.
- Construire le socle multi-clients : isolation, administration, mise en service, facturation.
- Lancer un pilote avec deux ou trois clients, en mesurant l’usage réel et le temps de support.
- Ouvrir la commercialisation une fois que la mise en service d’un nouveau client ne demande plus d’intervention technique.
Un outil interne qui fonctionne est un excellent point de départ : vous connaissez déjà le métier et vous avez un premier utilisateur exigeant, vous-même. Pour mesurer l’écart entre votre outil et un produit commercialisable, découvrez notre accompagnement SaaS ou échangeons sur votre projet.
