Discussion :

[Amine Horseman]

Serait-il temps de passer au SaaS ?
Un manager affirme que : « le modèle ASP est un échec »

Quand une entreprise veut investir une partie de son budget dans une solution informatique, elle cherche souvent « la meilleure » solution qui pourrait lui donner une valeur ajoutée et la faire démarquer de ces concurrents. Cependant, le choix n’est pas toujours facile. Avec l’apparition de nouvelles tendances et technologies, il arrive souvent qu’on ne sache plus ce qui marche bien et ce qui commence à être dépassé.

De la même manière si on fait une petite recherche sur le web, on trouve beaucoup d’articles traitant sur la différence entre SaaS (Software as a Service) et ASP (Application Software Provider). Selon un point de vue technique, les deux solutions représentent un modèle d'exploitation commerciale d’outils informatiques dans lequel ceux-ci sont installés sur des serveurs distants plutôt que sur la machine de l'utilisateur. Ceci leur permettrait de ne plus avoir besoin de mettre en place toute l’infrastructure nécessaire, avec les coûts d’installation et de maintenance que cela impliquerait, ainsi que les frais de consommation électrique qui en résulte.

Bien que les deux solutions sont généralement hébergées sur un serveur web ou sur le Cloud et accessible aux clients via le net, la différence, si on regarde les définitions sur le net, est que les solutions SaaS sont des services web accessibles à plusieurs clients en même temps, ces derniers n’ont généralement « pas besoin de payer de licence d’utilisation pour une version du produit, mais plutôt de payer un abonnement mensuel ou annuel ». Alors que pour les solutions ASP : « chaque entreprise cliente dispose de sa version individuelle du produit ».

Le résultat, selon un article de SearcheCIO, est qu’un fournisseur ASP dirige plusieurs applications spécifiques à plusieurs clients, et parfois une version différente pour chaque client, du coup avec ce modèle « il ne pourrait pas fournir beaucoup d'expertise dans chaque application ». Alors que de l’autre côté, un fournisseur SaaS gère une seule version du produit pour tous les clients, et du coup, il pourra bien se spécialiser dans ce service ; de plus, l’amélioration ainsi que la maintenance du produit seront plus fréquentes et moins couteuses pour les clients. De la même manière, le coût relatif à l’hébergement et la sécurité des données se trouve partagé par tous les clients, car « avec SaaS contrairement à ASP : le client n'a pas à acheter le logiciel et ensuite payer le fournisseur pour l’héberger » explique George Zarcilla, directeur du service à la clientèle de Xoom Corp.

« SaaS a démontré un temps de déploiement et un retour sur investissement rapide, une grande fiabilité par rapport à ASP, et un coût inférieur pour les clients » selon Jeffrey Kaplan le manager de ThinkStrategies, « ASP avait un modèle par serveur ou par utilisateur » ajoute le président de Atlantic Decisions, « SaaS peut facturer par cycles CPU ou par octets transférés et ceci facilite la mise à l'échelle d'un système ».

Le manager de Sixteen Ventures confirme tout ça. Selon lui : « le modèle ASP est un échec parce qu'il manque de scalabilité […] SaaS est scalable et permet de profiter d’une véritable économie d'échelle »

Source : Sixteen Ventures, SearchCIO, SearchCIO suite

Et vous ?

Qu’en pensez-vous ? Partagez-vous son point de vue ?

[kolodz]

Passer de ASP (Application Software Provider) à SaaS(Software as a Service) :
Pour le client :
C'est passé de l'achat à la location. C'est moins cher sur le court termes demande moins d'implication sur le longue terme.

Pour le vendeur :
C'est passer d'une rentré d'argent basé sur la licence(non stable) à une rentré d'argent basé sur l'abonnement (stable).

Il est indéniable que la gestion des SaaS s'est industrialisé. Ceux-ci sont plus flexible.

Alors que de l’autre côté, un fournisseur SaaS gère une seule version du produit pour tous les clients, et du coup, il pourra bien se spécialiser dans ce service ; de plus, l’amélioration ainsi que la maintenance du produit seront plus fréquentes et moins couteuses pour les clients.

Pour ce qui est des problématiques des "versions". Il faut bien se rendre compte qu'en général, c'est le client qui ne veux pas changer de version. Car, l'oblique à payer plus ou le force à mettre à jour d'autres logiciels. Pourquoi sortir de l'argent pour une nouvelle version qui n'apporte pas plus de fonctionnalité utile (pour le métier du client) ? Encore plus quand cela est risqué !
Le client perd surtout le droit de décider par lui-même. (Pour le meilleur et pour le pire)

Après vient la question de la gestion des données, le client n'héberge pas ses données... Et cela peut-être problématique pour lui...

« SaaS peut facturer par cycles CPU ou par octets transférés et ceci facilite la mise à l'échelle d'un système ».

Pour la question de la facturation, il faut bien se rendre compte qu'il n'y a aucune facturation où le vendeur ne gagne pas d'argent.
Quand il vous vends X centimes par MonUnitéDeMesure, il se fait Y centimes de marge.

Selon lui : « le modèle ASP est un échec parce qu'il manque de scalabilité […] SaaS est scalable et permet de profiter d’une véritable économie d'échelle »

Le ASP est un échec, car même le meilleurs vendeur à du mal en vendre tout les ans, pendant 20 ans, le même produit et sans évolution. C'est d'ailleurs le constat de Microsoft avec Office. Pour 85% des utilisateurs Office 95 fait le même travail qu'Office 2012...
Donc le ASP n'est pas un échec technique, mais une problématique économique. Celui d'avoir une rentré d'argent stable et suffisante...

Cordialement,
Patrick Kolodziejczyk.

[esperanto]

J'ai l'impression que l'article part du postulat que le fournisseur du service SaaS ou ASP n'est pas l'éditeur du produit : la fourniture de service serait donc un métier en soi - dans le cas contraire autant je comprends qu'un ASP puisse avoir plusieurs versions du même produit, mais pourquoi forcément plusieurs produits?

Je suis en train de développer un logiciel que je proposerai peut-être en SaaS+ASP. Pour moi l'activité SaaS ne sera que le mode de rétribution : le cœur du métier restera toujours la maintenance de l'application, qu'elle soit corrective ou évolutive.
La différence entre les deux:
- en mode SaaS, le client utilisera le serveur par défaut, avec les plugins standard ; seules ses données sont distinctes de celles des autres clients
- en mode ASP, je facturerai en plus la location d'un serveur dédié et l'installation du soft avec les plugins choisis par le client ; le client reçoit une adresse IP qu'il est seul à connaître
La différence ne serait pas donc pour moi entre achat et location, mais entre hébergement mutualisé et dédié.

L'échec du modèle ASP signifierait simplement que le client n'est pas prêt à payer plus cher pour une solution plus personnalisée, même si je lui prouve que c'est meilleur pour la sécurité.
Maintenant c'est sûr qu'en multipliant les intermédiaires, même la mondialisation et la "concurrence libre et non faussée" ne mettront jamais l'ASP (dédié) au prix du SaaS (mutualisé). Si le prix du matériel diminue, les deux baisseront en même temps. Et l'ASP restera cher.

[sinople]

Outre la problématique du stockage des données qui reste toujours importante pour certaines entreprises (même si la tendance globale est d'en avoir "plus rien à foutre".

Je ne suis pas certains que le client gagne quand le fournisseur se spécialise sur son service au lieu du business de son client. Parce que d'expérience chaque client a ses petites spécificités qui font en partie son unicité par rapport a ses concurrents.

Viser la solutions universel (soit disant parfaite) n'est intéressant que pour des processus secondaires ne touchant pas le coeur de l'entreprise.

Après la location versus l'acquisition d'un point de vue économique ainsi que la scabilite (et la fixation) des charges ont tous les deux leurs avantages et inconvénients. C'est trop complexe pour donner une réponse universelle. On imagine juste qu'un fournisseur ne vas pas passer d'un modèle a l'autre pour perdre de l'argent.

[Saverok]

Je ne suis pas certains que le client gagne quand le fournisseur se spécialise sur son service au lieu du business de son client. Parce que d'expérience chaque client a ses petites spécificités qui font en partie son unicité par rapport a ses concurrents.

Ce n'est pas incompatible avec le SaaS
Si l'application est très fortement paramétrable, souvent le cas pour celles proposées en SaaS, toutes ces subtilités peuvent être exprimées via le paramétrage.
Ensuite, pour ce qui est vraiment spécifique, cela s'externalise dans une appli dédiée et qui communiquera avec l'appli SaaS principale

Après, je partage ton avis sur le fournisseur de service qui se doit d'être focalisé sur son client et non sur sa solution
Cela doit rester une constante que l'on soit en SaaS ou non, mais c'est une dérive possible

[_skip]

Franchement, au risque de paraître un peu désagréable, pour moi c'est encore une étude menée par une compagnie de consulting qui veut montrer que son marché c'est le plus mieux, mais pas le plus mieux pour une catégorie de produit ou de service spécifique, le plus mieux en général pour tout type de projet. Et tu ferais bien d'avoir recours à ses services, parce qu'elle sait ce qu'elle dit, hein? Etude à l'appui. Je met ça exactement sur le même plan que ces consultants agiles qui nous expliquent qu'aucun projet ne peut se faire sans la méthodologie X dont ils sont comme par hasard évangélistes ou gold partner certifiés.

Dire "Saas c'est bien, ASP c'est nul on perd des sous" sans aucun contexte précis, merci mais je suis pas convaincu.

[kolodz]

... Je met ça exactement sur le même plan que ces consultants agiles qui nous expliquent qu'aucun projet ne peut se faire sans la méthodologie X dont ils sont comme par hasard évangélistes ou gold partner certifiés.
...

Gros Hors sujet :
Pour connaitre plusieurs consultants agiles personnellement, ce n'est pas leur discours... La plus part des consultants agiles viennent avec leur savoir-faire et une boite à outil "agile". Sachant que l'agilité, c'est pas une méthode, mais un principe.
Si mettre les tâches sur des post-it est plus efficace que faire des points sur l'avancement tout les jours, alors tu passe au post-it...

En citant un consultant agile :

Il n'y a pas de méthodologie magique, il n'y a que des petites astuces qui ont tendance à marcher. Le tout, c'est de savoir lesquels vont fonctionner chez "le" client.
C'est pour ça que je trouve mon job intéressant.(...)

Si t'as un coach agile qui n'a pas ce type de discours, c'est que ce n'en n'est pas un.

Pour moi, il y a deux problèmes :
Prendre trop au sérieux des annonces/publications de technico-commercial.
Faire l’amalgame entre les technico-commercial et ceux qui font actuellement leur job technique ou de conseil.

Cordialement,
Patrick Kolodziejczyk.

[Logan Mauzaize]

Si je comprends bien, la différence entre ASP et SaaS, c'est que l'un fournit un logiciel spécifique et l'autre non ?

Dans ce cas, je comprends pas le problème de la scalabilité ... Tout ce qui est PaaS permet déjà de prendre en charge la scalabilité de manière relativement agnostique à l'environnement (ex: Docker, OpenStack, App Engine, Heroku, etc.).
Quand on fournit un socle de base commun (même si des plug-ins sont activables pour un client particulier) ca reste relativement simple à scaler. Surtout qu'il suffit parfois de fonctionner par micro-services.

[Shamard]

Bonjour à tous,

Je suis dans ce sujet actuellement en tant que Release Manager chez un éditeur et je trouve que ce type d'article est à prendre avec beaucoup de recul !

En effet, comparer de l'ASP à du SaaS revient pour moi à vouloir à tout prix faire un comparatif entre le Sur-mesures et le prêt-à-porter :

• Ni les mêmes prix,
• Ni les mêmes services,
• Ni les mêmes résultats...

En revanche, je pense que pour un Editeur il est important de savoir se positionner et définir une stratégie sur l'une ou l'autre (voire les 2) de ces offres, sachant que pour l'ASP, il y aura forcément un travail dit "d'intégrateur" à envisager !

C'est sans doute là que devrait se situer le vrai débat : un éditeur doit il conserver l'activité d'intégrateur ou le "déléguer" à une société tierce (et la TMA qui va avec) ?