Du mode licence au SaaS : les deux marches à franchir

Un éditeur qui vend des licences et de la maintenance possède une base installée qui paie chaque année sans qu'il ait à la reconquérir. Il possède aussi un problème que le marché lui rappelle à chaque approche d'investisseur : ce revenu-là ne se valorise pas comme un revenu d'abonnement.

D'où la tentation de traiter le sujet comme un projet d'infrastructure. On réhéberge le produit, on le rend multi-locataire, on l'ouvre depuis un navigateur. C'est plus simple à maintenir pour l'éditeur, plus confortable pour le client, et c'est réel.

Mais ce n'est pas une transformation. C'est un déménagement. Et un déménagement ne justifie pas qu'on demande à un client de payer davantage. le client ne paierait que s'il y a de la valeur incrémentale créée.

Ce qui suit est la recette que nous appliquons — et le point central est qu'aucun de ses ingrédients ne suffit seul.

Le contresens de départ

Un client à qui l'on annonce que son logiciel passe dans le CLOUD entend une chose : mon fournisseur va réduire ses coûts d'exploitation, et il veut que je paie plus cher pour ça.

Il n'a pas tort. Un changement de mode d'hébergement, seul, est une amélioration pour l'éditeur. Elle ne devient une valeur pour le client que si elle s'accompagne de tout le reste.

Et le reste n'est pas un supplément d'âme : c'est ce qui rend la conversion acceptable, donc possible, donc rentable. Un programme de bascule qui n'embarque que la technique produit une négociation client par client, épuisante et perdue d'avance.

La vallée de la mort, en deux phrases

Une licence s'encaisse à la signature ; un abonnement s'étale. Le jour où l'on arrête de vendre la première pour vendre le second, on perd un revenu immédiat avant d'avoir constitué le second. Le creux n'est pas un accident d'exécution : il est arithmétique.

Ce qu'il faut modéliser avant de commencer, et que peu modélisent, n'est pas la montée de l'abonnement — c'est l'érosion de la maintenance.

Le gain est écrit ; la perte reste dans une hypothèse que personne n'a formulée. C'est là que les mauvaises surprises se logent — non pas parce que le modèle est faux, mais parce qu'il n'a qu'une moitié.

La recette : cinq ingrédients, et aucun ne suffit seul

① La plateforme mutualisée

Le socle. Une seule version pour tout le monde, des mises à jour continues, une exploitation industrialisée. C'est la condition de tout le reste — et c'est le seul ingrédient dont le bénéfice est d'abord pour l'éditeur. D'où la nécessité des quatre suivants.

② L'expérience utilisateur refaite

Pas ajustée : refaite. C'est l'ingrédient que les programmes techniques sacrifient en premier, et c'est celui que l'utilisateur voit en premier.

Une migration qui ne change rien pour celui qui utilise le produit échoue par construction : elle ne mobilise ni les équipes internes, qui ne comprennent pas l'effort, ni les clients, à qui l'on demande de payer pour une différence qu'ils ne perçoivent pas.

③ De nouvelles fonctionnalités, de nouveaux modules

La bascule est le seul moment où un éditeur peut légitimement rouvrir son offre. Il faut en profiter pour livrer ce que la base réclame depuis des années et que le modèle installé rendait impossible — les fonctions qui supposent une donnée à jour, un service continu, une intégration avec l'extérieur.

④ Un catalogue de services, et non plus seulement un produit

C'est l'ingrédient le plus sous-estimé, et il change la nature de l'offre. À côté du logiciel viennent :

Le client ne compare plus deux prix. Il compare un prix à un prix plus des postes de coût qu'il ne porte plus : l'hébergement, l'investissement transformé en dépense courante, les ressources informatiques rendues à des projets métier, et une part du risque de sécurité transférée.

Un détail de conception qui compte : certains de ces services sont inclus et d'autres en option. La distinction n'est pas comptable — elle dit ce qui définit l'offre et ce qui se vend en plus.

⑤ L'intelligence artificielle, à deux endroits

C'est le cinquième ingrédient, et c'est celui qui distingue une bascule d'une transformation.

Une capacité d'IA incluse en standard. Elle sert trois fins à la fois, et c'est ce qui la rend redoutable : elle justifie l'écart de prix avec l'ancien contrat de maintenance ; elle installe la crédibilité de l'éditeur sur le sujet ; et elle crée l'appétit pour les modules métier qui, eux, se vendent.

Un éditeur de GED métier, à propos de sa propre bascule.

Des modules d'IA métier au catalogue. Ils font deux choses différentes qu'il faut piloter séparément :

• Augmenter le périmètre du produit — automatiser ce qui était saisi, qualifier ce qui était trié, extraire ce qui était recopié. Le bénéfice se mesure en temps rendu et se défend en prix. C'est le prolongement du transfert de charge : on continue de retirer du travail au client.
• Ouvrir des cas d'usage qui n'existaient pas — des services que le produit ne rendait pas, non par manque d'ambition, mais parce qu'ils supposaient une capacité d'interprétation qui n'était pas disponible à grande échelle il y a cinq ans. C'est là que se créent les nouvelles lignes de revenu.

Le premier front défend et valorise la base. Le second l'élargit. Un programme qui ne traite que le premier améliore une marge ; un programme qui traite les deux change une trajectoire.

Le changement que personne n'annonce : on ne fait plus le même métier

Voilà ce qui est écrit dans les plans de bascule sérieux, à la ligne des risques internes, et que les communiqués omettent :

On passe du métier d'éditeur à celui de fournisseur de services.

Ce ne sont ni les mêmes compétences, ni la même organisation, ni la même culture.

C'est la transformation la plus profonde du programme, et la moins visible depuis l'extérieur. Un éditeur qui bascule sans l'assumer se retrouve avec des engagements contractuels qu'il n'a pas les moyens de tenir.

Piloter la bascule

• Fermer l'entrée avant la porte

  L'ancien modèle cesse d'être proposé aux prospects bien avant qu'on ne sollicite la base. Les dérogations restent possibles — écrites, tracées, validées, jamais négociées au cas par cas.

• Migrer à l'échéance, pas à la convenance

  Le moment de bascule d'un client est son renouvellement : le seul instant où la renégociation est naturelle.

• Prévoir un mode intermédiaire

  L'abonnement sans la délégation d'infrastructure, avec une partie du catalogue à la carte. Certains clients veulent garder la main ; les perdre coûte plus cher que les accompagner.

• Revoir la rémunération variable

  Convertir une base installée sans toucher au commissionnement, c'est demander de gagner moins pour travailler plus.

La transition dure plusieurs années ; autant l'organiser. Le plan de bascule et le plan de commissionnement se conçoivent ensemble, ou aucun des deux ne fonctionne.

Trois causes d'échec, et elles se ressemblent

• Une migration au lieu d'une transformation

  L'infrastructure a changé, l'utilisateur n'a rien vu. Personne ne s'est mobilisé, ni dedans ni dehors.

• L'érosion non modélisée

  Le creux de trésorerie arrive quand il n'y a plus de marge pour l'absorber. Il était pourtant arithmétique.

• Personne d'aligné

  Ni les équipes, dont les objectifs n'ont pas bougé ; ni les commerciaux, dont la rémunération punit la conversion ; ni les clients, à qui l'on a expliqué une architecture au lieu d'un bénéfice.

Une transformation échoue rarement sur la technologie. Elle échoue quand personne n'a intérêt à ce qu'elle réussisse.

Le chemin est connu

Il n'y a rien d'expérimental dans ce qui précède. Ces marches ont été franchies à grande échelle, par des éditeurs qui avaient plus de contraintes que la plupart : des produits installés depuis vingt ans, des clients qui n'avaient rien demandé, et un actionnaire qui attendait des résultats trimestriels.

Ce qui distingue ceux qui réussissent n'est ni la technologie ni le budget. C'est d'avoir traité la bascule comme un programme d'entreprise — sa vision écrite, son modèle économique, son plan d'adhésion interne et externe, ses incitations, et un pilotage qui mesure le creux au lieu de l'espérer court.

Et d'avoir compris que les ingrédients ne s'additionnent pas : ils se multiplient. Chacun sans le suivant retombe :

• La plateforme sans l'expérience

  Ne convainc personne — l'utilisateur ne voit rien changer.

• L'expérience sans les services

  Ne justifie pas le prix — c'est plus joli, pas plus utile.

• Les services sans l'IA

  Ne distinguent de personne — tout le monde sait tenir une astreinte.

• L'IA sans la plateforme

  N'est pas déployable — il n'y a ni corpus, ni élasticité, ni chemin vers la base.

C'est une recette. On ne la réussit pas en n'en faisant que la moitié.

L'ingrédient qui manque le plus souvent à la recette. L'IA n'est pas un cinquième pilier qu'on ajoute : elle change ce que le produit fait, donc ce qui se facture. Nous l'avons instruite axe par axe, avec les cas d'usage et un diagnostic de maturité en quatre minutes : Stratégie IA des éditeurs.