Dans le Schéma traditionnel, on nous explique qu’il y a quatre niveaux d’externalisation :
Expliqué rapidement, ce modèle semble cohérent. Il permet de convaincre un DSI dans un modèle majoritairement OnPremise (local donc), qu’il doit se positionner dans un degré d’externalisation.
Il doit placer le curseur du pas du tout au tout externalisé.
Ce schéma laisse penser qu’il existe une certaine progressivité voire un niveau de maturité en termes d’adoption du Cloud Computing. Nous le verrons plus bas, cette proposition est totalement fausse.
Résumer sa stratégie d’externalisation à quatre niveaux – du rien au tout – est très simpliste voire dangereux.
Tout d’abord, il est évident que l’externalisation de certains blocs n’est pas pertinente : pilotage d’une ligne de production, systèmes d’imagerie ou autres systèmes totalement autonomes ou directement lié à une machine.
A contrario, l’externalisation semble évidente pour d’autres blocs applicatifs. Totalement tournés vers l’extérieur de l’entreprise ou soumis à des pics d’utilisations très variables – il serait absurde de ne pas les externaliser : sites web, applications mobiles, etc.
Pour établir sa stratégie Cloud, il est donc raisonnable de mixer les types d’externalisation en fonction des contraintes physiques, des opportunités technologiques ou des usages.
Nous ne saurions que trop vous recommander de vous appuyer sur un cabinet de Conseil pour établir votre stratégie de “cloudisation”. Cela vous permettra de disposer d’un véritable retour d’expérience et de vous inciter à dépasser les limites de votre imagination.
Nous avons vu plus haut qu’il était possible voire recommandé de mixer les approches “As a Service” entre-elles voire avec l’hébergement local.
Dans ce cadre, on pourrait se demander quel modèle est adapté à quel contexte ?
Pour beaucoup, la dichotomie OnPremise / IaaS se résume à une problématique d’infrastructure interne vs Externe. De mon point de vue, cette vision est totalement fausse.
En effet, l’IaaS se caractérise par une offre standardisée de VM (Machine Virtuelle) idéalement en self-service. En suivant des principes de catalogue de services largement portés par les bonnes pratiques ITIL, il serait totalement possible de reproduire ce modèle totalement hébergé en local.
Techniquement, il s’agirait de disposer d’une infrastructure virtualisée avec un système d’orchestration des VM (voir https://www.openstack.org/ ou https://www.vmware.com/products/vrealize-orchestrator.html). Rien de très compliqué à mettre en oeuvre.
En revanche, le défi organisationnel est de taille. Il s’agit de définir un catalogue de services standardisés en termes d’infrastructures associant : SLA, performance, tarifs, sécurité, etc.
Faisons fi de la vision “niveau d’externalisation” et adoptons une vision organisationnelle.
Dans un monde idéal, un développeur souhaiterais disposer d’environnements prêt-à-l’emploi pour :
Là encore, c’est davantage un enjeu organisationnel que technique qu’il est nécessaire de relever.
Il s’agit en effet de standardiser des usages pour des populations de développeurs. C’est tout.
Lorsqu’on définit le SaaS d’un point de vue SI, on parle en fait d’application 100% standards. Il est par définition impossible de customiser pour l’utilisateur. Le produit vous plait tel qu’il est, sinon vous ne le prenez pas. C’est tout.
Partis sur cette base, nous voyons qu’une fois encore la problématique n’est ni technique, ni de savoir qui opère l’application.
La problématique est uniquement organisationnelle : mes métiers ou utilisateurs peuvent-ils se conformer aux processus informatisés standards de l’outil ? Si non, passez votre chemin.
Finalement, nous avons vu que pour une DSI, la problématique du “As a Service” tourne autour de votre organisation en mode Service. En effet, il serait tout à fait possible – et pourquoi pas recommandé ? – de mettre en place une organisation “As a Service” en interne.
Pourquoi ne pas adopter une organisation “As a Service” y compris pour les briques du SI hébergées en local ?
En effet, en appliquant les bonnes pratiques ITIL de façon puristes, on arriverait à :
En guise de conclusion, voici une proposition de représentation du modèle “as a Service” tel que nous le concevons :