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.