Avis d'expert : Services cloud, les trois étapes clés de leur histoire

Les services cloud d'aujourd'hui sont le fruit d'un progrès constant tout au long de ces dix dernières années, mais se pose à présent la question de leur avenir. Pour identifier comment les futures offres cloud vont évoluer, un retour sur le passé est nécessaire.

Les prémices

Les débuts des services cloud ont été marqués par les services de collaboration et de messagerie hébergée tels que Business Productivity Online Suite (BPOS) de Microsoft. La version orientée fournisseurs de services de BPOS appelée Hosted Messaging & Collaboration de Microsoft, a notamment connu un vif succès auprès des tous premiers acteurs de ce marché. Néanmoins, cette solution n'était pas la seule offre disponible. Beaucoup d'autres entreprises de moins grande envergure, proposaient ce même type de services : elles passaient par l'hébergement Exchange ou utilisaient leurs propres plates-formes créées en interne.

Les services cloud ont connu un tournant décisif lorsque nombre de sociétés qui cherchaient à revendre des services de collaboration et de messagerie ont adopté la stratégie suivante : appliquer leur propre marque à des services dits « génériques » comme les services de messagerie, de calendrier et Sharepoint. La différence était très mince. Pour les partenaires, la valeur ajoutée que cette démarche apportait par rapport au faible investissement requis était tout à fait acceptable. Ce sont les débuts des services cloud : une solution répondant à un besoin spécifique pouvant facilement s'intégrer dans une offre plus large d'un revendeur.

Nous pouvons même y voir ici les premiers pas du « brokerage », autrement dit, l'hébergement d'une série de services syndiqués derrière une seule marque avec un processus de facturation unique pour le client. L'agrégation voit également le jour.

L'intégration

WordPress illustre parfaitement l'intégration, deuxième étape dans l'histoire des services cloud. WordPress est une solution très facile à personnaliser et si cette simplicité est son plus gros avantage, elle s'avère être également son plus gros inconvénient. En effet, l'écosystème de WordPress compte environ 23 000 applications. Prenons l'exemple d'un ISV : si ce dernier voulait le proposer à sa base d'abonnés, il lui fallait mettre à disposition absolument toutes les applications. Ce processus impliquait donc un travail fastidieux d'intégration et de codage en dur.

À cela venait s'ajouter un autre problème, celui de la gestion permanente des packs. Le pré-packaging était certes possible mais l'investissement requis beaucoup trop lourd. Résultat : la situation devenait de plus en plus sérieuse pour nombre d'entreprises qui essayaient d'intégrer WordPress afin de créer leurs propres services. En résumé, si le « brokerage » était possible, il était particulièrement complexe et sa maintenance exigeait un travail technique colossal.

Les App Stores ou Boutiques d'applications sont un cas très similaire. Nombreuses, elles sont proposées par toutes sortes d'entreprises, de très grandes comme Apple et de petites tels que les opérateurs mobiles individuels. Les boutiques d'applications individuelles sont taillées sur mesure, rendant ainsi impossible l'intégration les unes aux autres. Dès qu'un certain nombre d'applications doivent fonctionner ensemble, le modèle de la boutique d'applications commence à s'effondrer.

La personnalisation

Regardons à présent la situation actuelle et penchons-nous de plus près sur l'Application Packaging Standard 2.0 (APS 2.0). Grâce à l'APS, les fournisseurs de logiciels peuvent intégrer la gestion et le provisioning contrôlé dans des applications en ligne au sein même d'un environnement d'hébergement mutualisé. Cette démarche contourne tout à fait le problème que nous venons de décrire avec WordPress. Les ISV, FAI et revendeurs n'ont en aucun cas besoin de se demander comment intégrer les add-ons dans leurs services et applications. Le codage en dur n'est pas du tout requis. Quant aux mises à jour des packs individuels, elles n'exigent pas le moindre travail laborieux sur la base du code. Prenons l'exemple de WordPress qui est packagé au format APS 2.0. Tout fournisseur de logiciels qui package son produit au format APS 2.0 se repose sur une base de code déjà installée.

Pour les FAI et revendeurs, leur objectif a toujours été de proposer des services personnalisés qui non seulement se démarquent de la concurrence mais sont également adaptés aux besoins de leurs clients. L'APS 2.0 présente de nombreuses commandes très différentes qui permettent aux FAI et VAR d'exécuter beaucoup de personnalisations dynamiques, y compris des solutions personnalisées dans un environnement multi-locataires. En d'autres termes, si votre cible de vente est très spécifique, tel que le marché de la santé, vous pouvez créer un service cloud personnalisé et l'adapter à votre convenance en fonction de votre client. Par exemple, une clinique n'aura pas besoin des mêmes services qu'un hôpital universitaire. De plus, le coût d'une application, de l'ISV au revendeur, est beaucoup moins élevé. Tous les problèmes survenus lors de cette période d'intégration, dont le codage en dur, ont disparu. Certes, ces problèmes auraient pu autrefois être évités mais il aurait fallu investir beaucoup de temps et d'argent.

Quelles conséquences ?

Avec l'ère de la personnalisation, les revendeurs redeviennent des VAR ou revendeurs à valeur ajoutée. Au lieu d'utiliser un service générique, d'y apposer sa marque et de le revendre pour finir par obtenir des marges de plus en plus réduites, les revendeurs peuvent ajouter de la valeur aux services qu'ils vendent. Ainsi, ils peuvent récupérer un service standard et le personnaliser pour l'adapter aux besoins bien précis de leurs clients.

Pour les clients PME-PMI, il s'agit là d'un véritable tournant : ils ont désormais accès à des outils qui étaient autrefois réservés aux grandes entreprises. De fait, les PME-PMI sont loin de méconnaître les services cloud. Ces entreprises se sont déjà familiarisées avec les services de collaboration et de messagerie hébergée et peuvent déjà utiliser le SaaS avec les produits comme Salesforce.com. Désormais, ces services sont tout à fait abordables pour ces entreprises ainsi que pour leurs fournisseurs. Ils peuvent créer des suites personnalisées d'outils qui ne se limitent pas à la messagerie hébergée.

Les développeurs, quant à eux, y gagnent tout autant. Ils peuvent les combiner très efficacement à des services plus larges. Résultat : ils peuvent créer des packs qui viennent compléter ou personnaliser une autre solution et offrir davantage de personnalisation aux marchés verticaux spécifiques.

Voir aussi

Silicon.fr étend son site dédié à l'emploi IT
Silicon.fr en direct sur les smartphones et tablettes

, - .