Rares sont les entreprises qui ne font pas appel aujourd’hui, pour leurs applications métiers ou bureautiques, à l’externalisation. Cependant, l’expérience utilisateur est souvent décevante.  Par Jérôme Dilouya, Directeur Associé InterCloud.

Rares sont les entreprises qui ne font pas appel aujourd’hui, pour leurs applications métiers ou bureautiques, à l’externalisation. Cependant, l’expérience utilisateur est souvent décevante – interfaces peu réactives, temps de chargement trop longs, performances irrégulières – avec autant de conséquences désastreuses : des forces de ventes démotivées quand le CRM n’est pas à la hauteur, des plateformes d’appels surchargées quand les fiches clients n’apparaissent pas à temps, une équipe back-office qui refuse d’adopter un nouvel outil de facturation aux performances jugées peu fiables, des livraisons annulées par l’indisponibilité du logiciel de supply chain, des heures perdues à ressaisir des notes de frais pour cause de déconnexions intempestives.

La réussite d’un projet d’externalisation informatique passant par une adoption franche et massive des utilisateurs, la qualité perçue par ces derniers est déterminante et doit atteindre un niveau comparable à celui des meilleurs systèmes de l’entreprise.

Les solutions sont souvent à chercher du côté du réseau …

Le retour du réseau

Aujourd’hui quiconque s’intéresse quelque peu à l’environnement du Cloud Computing a assimilé les concepts d’Infrastructure, de Platform et de Software as a Service.

Toutefois, les acteurs de l’écosystème du Cloud Computing ne sont pas tous à classer dans chacune de ces catégories : le NIST (National Institute of Standards and Technology) a récemment publié une mise à jour de sa vision de cet écosystème.

Modèle détaillé de l’écosystème Cloud Computing - NIST

Bien que le réseau ait été longtemps négligé dans les sujets Cloud Computing (en banalisant la couche transport notamment), il est important de noter que les experts du NIST l’ont réintégré comme socle de l’ensemble, en créant la notion de « Cloud Carriers ».

D’autres acteurs parlent aussi de NaaS (Network as a Service) pour mettre en avant la nécessité, pour les services réseau liés au Cloud Computing, de présenter les mêmes propriétés que ce dernier (flexibilité, paiement à l’usage, adaptabilité rapide…).

On trouve aussi la notion de Cloud Area Network, vue comme une extension du LAN intégrant les applications ou infrastructures Cloud utilisées au sein de l’entreprise considérée.

Il n’y a rien d’étonnant à ce que le réseau revienne au cœur des enjeux de l’écosystème.

En effet, passée la phase d’adoption du principe du Cloud Computing et de ses applications, les préoccupations majeures des utilisateurs de Cloud Computing sont la sécurité et l’intégrité des données, ainsi que la disponibilité et la performance d’accès aux données : or ces principaux thèmes induisent tous des implications majeures au niveau réseau.

Cloud Computing et Qualité de Service

L’histoire d’amour passionnée entre le Réseau et la Qualité de Service, qui donne lieu à des épisodes plus ou moins dramatiques, dure depuis des lustres.

Le Cloud Computing vient lui redonner un certain piment car à l’accoutumée, Réseau et Qualité de Service « lavent leur linge sale » en famille, c’est-à-dire en environnement plus ou moins fermé (réseau d’entreprise, réseau privé ou réseau d’opérateur).

En quoi est-ce un nouveau défi que de gérer la qualité de service « perçue » par un utilisateur d’application hébergée, alors que depuis des années nous manipulons des dizaines, voire des centaines de mécanismes plus élaborés les uns que les autres pour gérer cela dans nos réseaux ?

C’est précisément parce que nous n’évoluons pas ici dans nos propres réseaux, mais sur Internet.

Pour accéder à un Cloud « public » (ce qui est le cas pour la majorité des applications en mode SaaS par exemple) il faut, à un moment ou un autre, traverser le réseau des réseaux … Il en va de même pour les Clouds « hybrides » ou « communautaires » qui empruntent aussi dans la plupart des cas des liaisons banalisées qui passent par Internet.

Et Internet n’a jamais fait bon ménage avec la Qualité de Service.

Ainsi, pour schématiser, l’utilisateur final doit traverser, pour atteindre son service Cloud, deux « espaces réseau » de nature bien distinctes.

Le premier, son réseau (étendu) d’entreprise, au sein duquel la gestion de la Qualité de Service est une opération de routine, maîtrisée à la fois par les opérateurs télécoms, les intégrateurs, les acteurs spécialisés, voire l’entreprise elle-même.

Le second, le réseau qui sépare ce premier réseau du lieu d’hébergement du service Cloud en question, c’est-à-dire Internet dans la plupart des accès à un Cloud « public ». Sur cet « espace réseau », la mise en place de mécanismes de gestion de la Qualité de Service est nettement plus délicate.

Des solutions existent cependant. Certaines nécessitent le déploiement d’équipement aux extrémités … Il faut donc discuter avec son fournisseur de Cloud, et si ce dernier considère que son service est « irréprochable », il y a fort à parier que la discussion sera infructueuse. D’autres, plus récentes, se basent sur une interconnexion plus ou moins directe entre l’infrastructure du fournisseur de Cloud et celle de l’utilisateur final.

Mais parmi toutes ces offres, comment faire son choix ? Toutes promettent une « Qualité de Service » retrouvée, voire même « de bout en bout » – encore faut-il savoir de quel « bout » on parle … Les indicateurs diffèrent, les engagements aussi.

De la nécessité de la mesure

Afin de concilier Cloud Computing et Qualité de Service, il apparaît nécessaire de disposer d’un système de mesure fiable et impartiale.

-L’approche « réseau »

Une première approche – issue du monde réseau et qui ne dépaysera personne dans un environnement « télécoms » – consiste à mettre en place des méthodologies de test au niveau protocolaire.

Au niveau IP, la famille RFC 2330 pour l'IETF et la famille Y.1540 pour l'ITU-T sont deux familles qui ont donné naissance à la Qualité de Service pour les réseaux IP.

Au niveau Ethernet, la norme RFC 2544, conçue pour mesurer les performances d'un équipement particulier, et non d'un service de bout en bout (pas de notion de gigue – variation du délai de transmission, et donc de la latence – par exemple) semblait perfectible. Elle a été corrigée pour donner naissance à l'ITU-T Y.1564, qui introduit des services (des flots de test, définis par leur profil de trame et de débit), trois débits de test (CIR, EIR et Overshoot), deux types de test (configuration et performance) et quatre métriques (débit, latence, gigue et perte).

Hélas, cette approche reste, malgré sa finesse, aveugle aux problématiques des « couches hautes », souvent à l’origine des éternels débats entre DSI et utilisateurs : « Tout est au vert. Le réseau et les serveurs, tout fonctionne. Rien à signaler » Et à l’autre bout du combiné … « Ah oui ? Venez pour essayer l’ERP un peu pour voir … parce qu’ici, ça ne marche pas. Ca rame mon cher monsieur. ».

L’approche « applicative »

Pour dépasser ces débats, il faut une vision plus « applicative », liée à « l’expérience utilisateur », qui se rapproche au mieux du ressenti de l’utilisateur derrière son poste de travail (certains diront qu’on parle alors de « QoE – Quality of Experience »).

Ici, des « robots » vont se comporter comme des utilisateurs finaux et analyser l’intégralité de la « pile applicative », en continu, aussi longtemps que nécessaire. Les problèmes réseaux seront décelés, mais aussi ceux des couches hautes, invisibles par les approches précédentes.

L’entreprise peut alors construire des indicateurs pertinents pour ses applications Cloud, lisibles de tous, et par conséquent contractualiser sur la base d’engagements de services qui font sens.

Plus important encore, elle devient capable de déterminer quel « espace réseau » est fautif dans la dégradation de la qualité perçue par les utilisateurs, et quelles sont les raisons de cette dégradation.

La voie de la guérison

Armée de mécanismes de gestion de la Qualité de Service plus ou moins éprouvés sur chacun des deux « espaces réseau » – ainsi que d’un système de mesure adéquat – l’entreprise peut désormais tenter de réconcilier le Cloud, le Réseau et la Qualité de Service.

Il lui faudra pourtant surmonter un dernier obstacle.

Les deux « espaces réseaux » dont nous avons parlé, ainsi que l’environnement Cloud sur lequel l’application cible est opérée n’utilisent pas, à ce jour, les mêmes référentiels de Qualité de Service.

En effet, les différents prestataires de la chaîne de service ne sont pas en mesure de partager entre eux leurs indicateurs. Ces derniers sont de plus présentés sous des formes distinctes par chaque acteur – empêchant une lecture homogène des tableaux de bord et des engagements contractuels.

Ainsi, même si l’entreprise peut aspirer à disposer d’une vision unifiée de la Qualité de Service des applications Cloud, le chemin est encore long avant que cette visibilité soit délivrée de façon homogène, impartiale et exploitable directement par les fournisseurs.

Jérôme Dilouya, Directeur Associé InterCloud