Software as a Service : quelle(s) évolution(s) (2/2)

L’hébergement des applications et leur prise en charge par des maîtrises d’œuvre externes spécialisées permet d’éviter à disposer soi-même de ces compétences. C’est un peu comme faire appel à une société de services en informatique, sauf que là, la frontière entre le métier d’éditeur de logiciel et celui de prestataire de service devient floue. Rien n’interdit à une SSII de proposer ses propres solutions en SaaS, rien n’interdit non plus à un éditeur de considérer que ses équipes sont les mieux placées pour définir les spécificités fonctionnelles d’une application ou son architecture. Après tout, qui connaît mieux l’application, les forces et les limites de son modèle fonctionnel, ou la façon dont elle est mutualisée entre plusieurs clients ?

Dernièrement, j’ai trouvé que cette tendance se développait franchement. Nombre de mes clients ont fait appel en direct aux équipes des éditeurs après avoir choisi une solution… et nombre d’entre eux s’en sont d'ailleurs mordu les doigts : absence de méthode, ingénierie défaillante, incapacité à s’engager au forfait, ont allègrement conduit des projets stratégiques vers d'insondables abysses. La criticité stratégique des sujets avait laissé penser que seules les équipes des éditeurs proposeraient le niveau de maîtrise suffisant pour garantir le succès des projets. C’est l’inverse qui s’est produit.

Mais, comme vous l’avez peut-être déjà très justement remarqué, ces projets n’ont pas été opérés en mode SaaS. En mode SaaS, on fournit d’abord un socle fonctionnel et technique déjà existant. Les équipes ne se déplacent pas pour réaliser un logiciel : celui-ci existe déjà et il est éventuellement personnalisé pour les besoins d’une entreprise. Et c’est là que l’on peut se demander qui a besoin d’applications en mode SaaS.

En effet, à l’heure où nos clients nous demandent de tenir compte de façon de plus en plus précise des spécificités de leurs modèles métier, de contextualiser encore davantage nos études et nos réalisations, le modèle SaaS fournit davantage du prêt-à-porter que de la haute couture. Alors, à qui s’adresse le SaaS ? A de grandes entreprises qui voient là une manière efficace de sous-traiter des processus non stratégiques (du Business Process Outsourcing) ? A des PME qui n’ont qu’un intérêt limité pour le custom et trouvent plus commode de disposer d’applications clés en main ?

Tout dépend de ce que l’on nomme réellement SaaS. La volonté du SaaS, c’est précisément de s’affranchir de l’ASP, et de la notion d'application (comme, d'ailleurs, la SOA), ce dont il n’a pas encore les moyens économiques et technologiques (on se cherche encore beaucoup dans le SaaS, et Google est un peu l’arbre qui cache le désert). On différencierait alors l’ASP du SaaS en n’hébergeant pas des applications, mais des processus ou des services, graphiques ou non, prêts à être assemblés pour former des interfaces personnalisées, des processus modulaires. Le SaaS serait davantage un ensemble de ressources éventuellement "annuairisées" (que fait Google, finalement). On reparlerait sérieusement du mashup dans le monde de l'entreprise. Celle-ci trouverait là la voie du custom et de différenciation. Les modèles économiques se développeraient en conséquence, avec une facturation à la ressource consommée, la ressource pouvant avoir une signification sémantique métier pour l’entreprise (un client, une commande, une vérification Sarbanes-Oxley…).

Délire enfiévré ou boule de cristal, je n’ai pas la capacité à prédire l’avenir, et mes tristes scores à l'Euromillions me le rappellent régulièrement. Mais il n’est qu’à regarder les grandes manœuvres de SAP, IBM et Microsoft pour comprendre que si tout reste encore à faire, la vision est là.

Reste alors à régler la question de la relation entre éditeur de logiciels, société de service et cabinets de conseil. Si je prêchais pour ma paroisse, je dirais que la SaaS ouvre la porte à un modèle vertueux entre éditeur de logiciels et société de service, au service du client et de la création de valeur, pour définir des business cases, les modalités d’applications du custom, aider les entreprises à définir si le modèle SaaS est adapté pour elles et choisir la meilleure solution à leurs besoins.

Alors je me rendrais compte que tout compte fait, sur ce point-là en tout cas, le SaaS ne change pas grand-chose à nos métiers respectifs.

Software as a Service : quelle(s) évolution(s) ? (1/2)

Cette semaine, un think tank d’Unilog Management a regroupé quelques consultants pour débattre de domaines en voie de développement. Celui auquel j’ai participé portait sur le SaaS. SaaS (Software as a Service) évoque l’externalisation par les entreprises de processus métier auprès de partenaires chargés d’héberger la solution IT qui orchestre ces processus et d’assurer la prestation de services qui l’accompagne. Contrairement aux rumeurs, SaaS n’est donc pas la version flamande d’un populaire mâle espion engendré par Gérard de Villiers (pas plus d’ailleurs que l’acronyme OSS en son temps n’évoquait les prouesses à venir de Jean Dujardin).

SaaS se présente comme un nouveau modèle de facturation des logiciels : ce sont d’ailleurs principalement les éditeurs qui font du SaaS : les plus visibles sont SAP, Microsoft, IBM ou encore Oracle, mais de nombreux pure-players opèrent également, tels que salesforce.com. Par ailleurs, la concentration a déjà commencé, avec l’acquisition récente de Nsite par Business Objects pour proposer un modèle SaaS dans le champ du décisionnel. Au lieu d’investir dans une licence plus ou moins perpétuelle, les entreprises dépensent en « pay as you go » et « pay as you grow » : un montant forfaitaire, ou dégressif, par utilisateur ou par nombre d’objets manipulés. Ainsi, Salesforce.com facture les entreprises au nombre de clients stockés dans sa base de CRM (Customer Relationship Management).

En comparaison de l’acquisition d’une licence, les analystes estiment que le modèle SaaS est moins onéreux les trois premières années. Au-delà de trois ans d’utilisation d’une même version d’un logiciel, il vaut mieux investir dans une licence. Mais les avantages sont ailleurs. Evolutions et nouvelles fonctionnalités peuvent être régulièrement mises en ligne, sans forcément d’importants coûts de migration (même si les évolutions majeures deviennent du coup plus difficiles à appliquer). Et puis, il n’est plus nécessaire d’investir dans l’infrastructure ou dans les compétences : elles sont chez le partenaire. Par conséquent, une des réels points d'impact du modèle SaaS pourrait être son impact sur l’organisation des DSI.

En déléguant une partie des compétences et des socles techniques, les DSI vont pouvoir mieux se concentrer sur ce qu’elles cherchent à faire aujourd’hui : accroître l’efficacité de la relation entre maîtrises d’ouvrage et maîtrises d'oeuvre pour ajuster les relations avec le métier et accélérer l’alignement. Mécaniquement, c’est ce que doit provoquer l’externalisation d’une partie de la maîtrise d’œuvre. Avec une relation nécessairement contractuelle, il est probable que l'efficacité s'accroisse et que le temps de delivery de nouvelles fonctionnalités soit en moyenne considérablement réduit à l'avenir.

Mais on peut s’interroger sur la portée de ce modèle : s’agit-il d’un revival de l’ASP (Application Service Provider) ou d’un réel nouveau modèle ?