Transformer votre outil interne en SaaS : devenir éditeur

Transformer un outil interne en SaaS, c'est passer d'un logiciel qui sert une entreprise à un produit vendu par abonnement à beaucoup d'autres. Le cœur métier se garde souvent ; ce qui change, c'est tout le reste : séparer les données de chaque client, facturer, assurer le support, signer des contrats et prouver que vous détenez les droits sur le code. Autrement dit, vous devenez éditeur de logiciel.

Le scénario est fréquent. Une entreprise a fait développer, ou a développé elle-même, un outil qui règle un problème de son métier. Un fournisseur, un confrère ou un concurrent le voit en démonstration et demande s'il est à vendre. La question devient alors : est-ce une bonne idée, et qu'est-ce que cela implique vraiment ? Cet article répond sans enjoliver, en partant de ce qui distingue un outil maison d'un produit.

Outil interne ou produit : ce qui change

Un outil interne a un seul client, qui est aussi son propriétaire. Il peut tolérer des réglages en dur, une procédure de sauvegarde manuelle, un bouton que seul le comptable comprend. Un produit vendu à d'autres ne le peut pas.

La dernière ligne est celle qu'on sous-estime le plus. Tant que l'outil est interne, chaque demande de l'équipe peut être satisfaite. Dès qu'il est vendu, une demande d'un client doit servir aux autres, sinon le produit se transforme en collection de versions sur mesure impossibles à maintenir.

Les cinq chantiers pour devenir éditeur

1. Rendre l'outil multi-clients

C'est le chantier technique principal. Chaque entreprise cliente doit voir ses données et seulement les siennes, avec ses propres utilisateurs, ses propres rôles et ses propres réglages. Un outil pensé pour une seule entreprise mélange souvent tout dans les mêmes tables : il faut alors introduire la notion de client à tous les niveaux, de la base de données aux exports.

Le cas ressemble à celui d'un réseau d'agences, où chaque site ne doit voir que son périmètre : notre article sur le back-office multi-sites détaille cette logique de droits. Pour un SaaS, la séparation va plus loin, puisque les clients sont des entreprises distinctes. Les options d'architecture sont comparées dans notre article sur le SaaS multi-tenant.

S'y ajoutent l'inscription en libre-service ou accompagnée, la gestion des invitations, la réinitialisation des mots de passe et la suppression d'un compte avec ses données : autant de fonctions qu'un outil interne n'a jamais eues.

2. Fixer un prix et facturer

Un outil interne ne coûte rien à l'utilisateur. Un produit doit trouver un modèle de prix compréhensible : par utilisateur, par établissement, par volume, ou par paliers de fonctions. Le bon modèle suit ce qui crée de la valeur pour le client, pas ce qui coûte à l'éditeur. Les approches sont détaillées dans notre article sur le prix d'un SaaS.

Côté technique, la facturation récurrente implique des abonnements, des périodes d'essai, des changements de formule en cours de mois, des paiements refusés et des factures conformes. Un prestataire de paiement spécialisé en prend une bonne partie en charge, mais le raccordement reste à construire.

3. Organiser le support et l'exploitation

Un client qui paie un abonnement attend un service qui fonctionne, des réponses à ses questions et des corrections rapides. Il faut donc une documentation, un canal de support identifié, une supervision qui alerte avant que les clients ne le fassent, des sauvegardes testées, des mises à jour de sécurité régulières et une procédure en cas d'incident.

C'est souvent ce qui décide de la viabilité du projet. Une entreprise dont le métier n'est pas le logiciel doit choisir : recruter, ou confier l'exploitation à une équipe externe qui s'en charge dans la durée.

4. Encadrer la relation par des contrats

Dès que vous hébergez des données personnelles pour le compte de vos clients, vous devenez en principe leur sous-traitant au sens du RGPD. L'article 28 du règlement impose un contrat qui décrit le traitement, et il encadre le recours à vos propres prestataires, comme votre hébergeur : il faut l'autorisation écrite de vos clients, et ces prestataires doivent respecter les mêmes obligations que vous. La CNIL a publié un guide du sous-traitant avec un exemple de clauses.

Viennent ensuite les conditions générales d'utilisation et de vente, l'engagement de disponibilité et de délai de réponse, et la réversibilité : la façon dont un client récupère ses données s'il part. Ces documents engagent l'entreprise : ils se font relire par un avocat spécialisé avant la première vente.

5. Vérifier que vous détenez les droits

On ne peut vendre que ce qui vous appartient. Si l'outil a été écrit par vos salariés dans l'exercice de leurs fonctions, l'article L113-9 du Code de la propriété intellectuelle attribue en principe les droits patrimoniaux à l'employeur, sauf stipulation contraire. Si l'outil a été développé par un prestataire, tout dépend de son contrat : une licence d'utilisation interne ne suffit pas pour revendre le logiciel à des tiers. Les droits sont définis au cas par cas dans le contrat, et c'est le premier document à relire.

Même vigilance pour les composants : bibliothèques open source dont la licence impose des conditions de redistribution, modules payants achetés pour un usage interne, ou services tiers dont les conditions interdisent la revente.

Vérifier la demande avant d'industrialiser

L'intérêt d'un confrère pendant une démonstration est un signal, pas une preuve. Avant d'engager le chantier, quelques questions évitent de construire un produit sans acheteurs :

• Le problème est-il commun au secteur, ou propre à votre façon de travailler ? Un outil qui épouse une organisation unique se vend mal.
• Qui paierait, et sur quel budget ? Le dirigeant, le responsable d'exploitation, la DSI d'un groupe : le circuit de décision change le cycle de vente.
• Combien d'entreprises cibles existent, et comment les atteindre ? Un salon professionnel, une fédération, un réseau de distributeurs ?
• Qu'utilisent-elles aujourd'hui ? Si c'est un tableur, le scénario décrit dans notre article sur le remplacement d'Excel est votre meilleur argument. Si c'est un logiciel concurrent, il faut une vraie différence.

La méthode la plus sûre reste de montrer avant de construire : une version de démonstration, ou un prototype de la version multi-clients, présentée à des entreprises qui ne vous doivent rien, avec une demande d'engagement concret à la clé.

Ce que l'on garde, ce que l'on reprend

Un outil interne qui tourne depuis des années a une valeur que l'on oublie souvent de compter : il contient des règles métier éprouvées et des écrans validés par de vrais utilisateurs. Cette connaissance se garde, même quand le code doit évoluer.

Ce qui se reprend le plus souvent :

• le modèle de données, pour y introduire la séparation par client ;
• l'authentification et les droits, pensés pour une seule entreprise ;
• les réglages écrits en dur, à transformer en paramètres ;
• l'hébergement, qui doit tenir la charge de plusieurs clients et respecter leurs exigences, notamment sur la localisation des données ;
• la dette technique accumulée, tolérable en interne, coûteuse dès que des clients externes en subissent les effets.

Un audit du code existant permet de trancher entre faire évoluer et reconstruire, et de chiffrer chaque option. Les postes de coût d'un SaaS sont détaillés dans notre article sur le coût de développement d'un SaaS.

Ce qu'implique un SaaS en production : un exemple

Izi-Devis, le logiciel de devis et de factures pour artisans que LPR Studio conçoit, développe et exploite lui-même, n'est pas né comme un outil interne : il a été pensé comme un produit dès le départ. Il illustre en revanche ce que demande un SaaS une fois en ligne :

• une offre d'entrée et un abonnement, avec une offre gratuite limitée et un abonnement dont le tarif est publié ;
• un produit vivant, avec de nouvelles versions chaque semaine depuis le premier jour, nourries par les retours des utilisateurs ;
• une exploitation continue : hébergement en Europe, supervision, sauvegardes et mises à jour ;
• des ponts vers l'existant, comme l'export comptable ou l'import depuis un autre logiciel, parce qu'aucun client ne part de zéro.

Aucune de ces fonctions n'aurait été nécessaire pour un outil réservé à une seule entreprise. C'est l'écart à anticiper.

La feuille de route, étape par étape

1. Vérifiez les droits sur le code et les composants, contrat du prestataire en main.
2. Testez la demande auprès d'entreprises extérieures, avec une démonstration et une demande d'engagement.
3. Faites auditer l'existant pour décider entre évolution et refonte.
4. Montrez la version multi-clients sous forme de prototype avant de la développer : inscription, espace client, réglages, facturation.
5. Préparez les contrats : conditions générales, contrat de traitement RGPD, engagement de service, réversibilité.
6. Organisez l'exploitation et le support avant le premier client payant, pas après.
7. Ouvrez progressivement, avec quelques clients pilotes, puis élargissez.

Chez LPR Studio, le prototype de la version multi-clients est gratuit et présenté en visio sous 5 jours ouvrés. Il sert à voir le produit avant de l'industrialiser, et à le montrer à vos futurs clients. Trois formules permettent ensuite de le construire : forfait à prix fixe, abonnement sans payer le développement, ou édition SaaS.