De l’ASP au SaaS
L’ASP (Application Service Provider) tend à devenir du SaaS (Software as a Service). Pour bien comprendre ce basculement il faut rappeler les principes techniques qui sont à l’oeuvre :
- Les solutions ASP sont historiquement des solutions de type client / serveur dans lesquelles le prestataire héberge le serveur.
- La solution SaaS s’appuie, elle, sur les standards web pour proposer des applications accessibles par des clients légers.
On retiendra donc que l’ASP et le SaaS sont identiques dans leurs intentions (vendre un service plutôt qu’un logiciel qui s’installe), mais différentes dans leur réalisation technique : seul le SaaS reproduit des architectures web (SOAP, XML, etc.).
Si l’on voulait aller plus loin, il faudrait faire la distinction entre les SaaS qui utilisent une architecture REST et celles qui utilisent SOAP ou RPC. Voir à ce propos la très belle note sur Biologeek sur l’architecture REST.
LES PRINCIPAUX FACTEURS DU DEVELOPPEMENT DES SOLUTIONS SaaS :
Une logique de coût et une économie d’échelle.
Tout comme le développement spécifique a été bousculé par l’arrivée des « solutions sur étagère » que sont les progiciels d’entreprise, ces mêmes progiciels sont à leur tour bousculés par les solutions Web (le nom le plus simple des SaaS) qui ont les avantages suivants :
- logique de leasing et non d’achat (ce qui réduit les besoins de trésorerie)
- pas d’installation (pas de hardware à maintenir, pas de frais d’intégration, de maintenance, etc.)
- diminution des ressources humaines affectées à l’informatique de l’entreprise
- moins de dépendance à un éditeur dans l’évolution de son système d’information
- meilleur réactivité et souplesse des services applicatifs
Pour les prestataires offrant des SaaS cela implique :
- de construire des data center et des centres de calculs importants
- d’avoir la capacité financière pour faire face aux besoins de trésorerie
C’est donc une pure logique d’économie d’échelle qui anime le business model de ces acteurs. Logique rendue possible par l’utilisation des techniques et des standards Web, designée et socialisée dans la vague Web 2.0.
LES PRINCIPALES RÉTICENCES POUR LA BASCULE VERS UNE LOGIQUE SaaS.
Ces sont les suivantes :
- la confidentialité des données
- les besoins d’accès Offline
- couplage nécessaire avec les applications existantes installées dans le système d’information de l’entreprise
- les résistances au changement (mutation et disparition de certains métiers dans l’entreprise)
Parmi ces éléments de réticence, la confidentialité des données est le plus sérieux.
IMPACT DE LA CONFIDENTIALITÉ DES DONNÉES SUR L’AVENIR DES SaaS
En bon consultant je dirai que 80% des informations ne sont pas sensibles et peuvent donc être adressées via des solutions SaaS. Mais cela implique de construire une autre solution pour les 20% restantes et d’asssurer un service sans-couture entre les deux types d’informations ; du coup le coût global augmente sensiblement la facture initiale, réduisant par là même un des principal avantages de l’approche SaaS.
A noter que, lorsqu’on parle de confidentialité des données, on voit souvent apparaître les questions de sécurité. C’est un faux problème, car les Data Centers des prestataires de SaaS sont souvent de bien meilleures places fortes que les systèmes d’information des entreprises.
L’OPPOSITION ENTRE LE LEGACY ET LE SaaS
Louis Naugès, qui est un acteur Français très intéressant de la bascule vers le SaaS oppose souvent le Saas au « legacy » (désignant par là les applications historiques et patrimoniales des entreprises). Mais entre le Leagcy et le SaaS il existe, pour les grandes organisations, une troisième voie qui consiste à construire des data center sur lesquels des SaaS d’entreprises pourront se construire, sans aller sur Internet donc. Une autre voie et celle que tentent d’adopter les grands nom de l’ERP, ainsi SAP a commencé à proposer des logiciels en mode SaaS, mais sous forme timide d’option pour l’instant (ne pas s’attendre à des architectures REST et au respect des standards de la part de ces acteurs).
Il existe donc différentes déclinaisons dans le monde du SaaS :
– Les Saas Internet (Google Aps, SalesForces)
– Les Saas Intranet (une partie sur mesure)
– Les ERP « SaaSisés » (SAP, ORACLE)
Beaucoup de personnes vont voir leur métier changer et évoluer dans les prochaines années.
[…] D’une manière générale, tout le monde veut profiter de l’intérêt et de l’engouement pour le Software as a Service. Aussi, ceux qui faisait de l’ASP (Application Service Provider) disent aujourd’hui avec une grande facilité qu’ils font du SaaS depuis longtemps. Il y a un an, j’avais déjà évoqué des éléments de distinction entre les solutions ASP et les solutions SaaS. Voici donc quelques critères qui permettent de caractériser une solution en mode SaaS : Full Web : Le SaaS est totalement intégré dans l’environnement du web, dans son architecture et dans le respect des standards. En conséquence on accède aux services en mode SaaS par HTTP et via une URL, et bien sûr on offre toutes les APIs qui vont bien. Économies d’échelle et outil de production : Un acteur SaaS est de facto dans une logique industrielle d’économie d’échelle. Il doit bénéficier d’infrastructures importantes pour la production de ses services, soit les siennes s’il veut être un acteur de rang 1, soit celles d’un partenaire (par exemple Amazon) s’il est un acteur de rang 2. Sans installation : Aucune installation dans le système d’information et aucun accès à l’environnement desktop sur le poste de travail n’est nécessaire. Tout passe par le navigateur. Multi-tenants : Une seule instance du logiciel pour x clients. Ce qui signifie que l’environnement de production est mutualisé et virtualisé. Aucun hébergement dédié pour un client n’est possible. Et ce, contrairement aux solutions ASP qui disposent d’un environnement dédié pour chaque client et qui donc ne peuvent bénéficier des vertus de la mutualisation (nouveaux clients = nouvelles bases de données). Web Analytics : Une solution SaaS n’est viable que si elle dispose de puissants outils d’analyse et de reporting pour détecter les tendances d’utilisation et de comportement des clients. Grâce à çà, les évolutions seront plus en phase avec les pratiques des utilisateurs. Le vrai métier d’un acteur SaaS c’est de “tâter le pouls” de ses utilisateurs en quasi temps réel. Agilité : La conséquence de plusieurs des points précédents est qu’une solution SaaS doit faire preuve d’agilité dans l’évolution de la solution. Les développements sont incrémentaux, c’est le règne du Beta, de l’essai et de l’expérimentation permanents pour coller au plus prêts du marché et générer le plus d’innovation possible. Au final, parmi ceux qui se revendiquent de la démarche SaaS, combien arrivent à satisfaire l’ensemble des points précédents ? […]
[…] D’une manière générale, tout le monde veut profiter de l’intérêt et de l’engouement pour le Software as a Service. Aussi, ceux qui faisait de l’ASP (Application Service Provider) disent aujourd’hui avec une grande facilité qu’ils font du SaaS depuis longtemps. Il y a un an, j’avais déjà évoqué des éléments de distinction entre les solutions ASP et les solutions SaaS. Voici donc quelques critères qui permettent de caractériser une solution en mode SaaS : Full Web : Le SaaS est totalement intégré dans l’environnement du web, dans son architecture et dans le respect des standards. En conséquence on accède aux services en mode SaaS par HTTP et via une URL, et bien sûr on offre toutes les APIs qui vont bien. Économies d’échelle et outil de production : Un acteur SaaS est de facto dans une logique industrielle d’économie d’échelle. Il doit bénéficier d’infrastructures importantes pour la production de ses services, soit les siennes s’il veut être un acteur de rang 1, soit celles d’un partenaire (par exemple Amazon) s’il est un acteur de rang 2. Sans installation : Aucune installation dans le système d’information et aucun accès à l’environnement desktop sur le poste de travail n’est nécessaire. Tout passe par le navigateur. Multi-tenants : Une seule instance du logiciel pour x clients. Ce qui signifie que l’environnement de production est mutualisé et virtualisé. Aucun hébergement dédié pour un client n’est possible. Et ce, contrairement aux solutions ASP qui disposent d’un environnement dédié pour chaque client et qui donc ne peuvent bénéficier des vertus de la mutualisation (nouveaux clients = nouvelles bases de données). Web Analytics : Une solution SaaS n’est viable que si elle dispose de puissants outils d’analyse et de reporting pour détecter les tendances d’utilisation et de comportement des clients. Grâce à çà, les évolutions seront plus en phase avec les pratiques des utilisateurs. Le vrai métier d’un acteur SaaS c’est de “tâter le pouls” de ses utilisateurs en quasi temps réel. Agilité : La conséquence de plusieurs des points précédents est qu’une solution SaaS doit faire preuve d’agilité dans l’évolution de la solution. Les développements sont incrémentaux, c’est le règne du Beta, de l’essai et de l’expérimentation permanents pour coller au plus prêts du marché et générer le plus d’innovation possible. Au final, parmi ceux qui se revendiquent de la démarche SaaS, combien arrivent à satisfaire l’ensemble des points précédents ? […]
[…] avec le « Nuage » (Cloud). Encore une supercherie marketing redéfinissant les services « SAAS » ou « ASP ». Ceci étant dit, même si mal compris par l’utilisateur final, le terme Cloud est […]
A propos du problème d’accès offline, les acteurs du Web 2.0 sont bien conscients de cette limite dans leurs applications et c’est pourquoi ils réfléchissent de plus en plus au problème tout comme/avec certains développeurs de navigateur (Mozilla en particulier). De ce point de vue, je te conseille de regarder la solution Zimbra : http://www.lexpansion.com/art/32.0.156163.0.html et http://www.zimbra.com/ qui m’a bluffé voire même réconcilié définitivement avec l’AJAX et autre interface riche en javascript, il faut aussi avoir en tête les travaux du WHATWG : http://developer.mozilla.org/presentations/sxsw2007/the_open_web/
[Reply]