C’est LE sujet du moment. Oui mais voilà, qu’est ce que le cloud ?

 

Beaucoup trop de marketing et de légendes à ce sujet. Et si nous commencions par redéfinir le concept de Cloud ?

Pour moi, le “Cloud” pourrait trouver cette définition : ensemble de solutions technologiques et financières qui permettent :

• Une mise à disposition extrêmement rapide (quelques minutes à quelques heures) de ressources IT à des utilisateurs internes ou des clients externes
• Un modèle de facturation à l’usage évitant des investissements initiaux (et un amortissement) trop difficiles à justifier quand il est impossible de calculer “a priori” un retour sur cet investissement.

Ce n’est donc pas, comme certains voudraient nous le vendre, une marque comme AWS, Google Cloud ou Azure… Et encore moins une solution ou le seul cloud public serait la solution à tous nos maux.

 

Pendant des années, le fonctionnement “par projet” qui était imposé aux DSI ont obligé celles-ci à demander des délais incompressibles, parfois impossibles à supporter pour les demandeurs : le travail préalable d’évaluation, avec les éditeurs logiciels ou les développeurs permettant de déterminer les ressources nécessaires et les achats à effectuer, les procédures d’appels d’offres, de dépouillement, de contractualisation et de passage de commande avec les fournisseurs sélectionnés, la réception, l’installation et la nécessaire formation des équipes… Amenait une DSI à prévoir un délai compris en moyenne entre 6 mois et 1 an pour supporter les demandes relatives à la mise en place d’une nouvelle application. Pour beaucoup de directions fonctionnelles, ce délai devenait trop long dans ce monde ou l’agilité des entreprises et leur capacité à se transformer (digitalement) rapidement peut vite constituer un avantage concurrentiel décisif.

 

Pour tenir les engagements de “Time to Market” toujours plus ambitieux et  imposés par les directions générales soucieuses de protéger l’avenir de l’entreprise ; les directions fonctionnelles ont alors commencé à se détourner de leur DSI, commençant à se provisionner des ressources IT un peu partout, en utilisant souvent la carte bancaire du service et la note de frais comme modèle de facturation (et en tapant parfois sur la tête du DSI en expliquant que la solution externe coûte beaucoup moins cher que la solution proposée par la DSI de l’entreprise).

 

Ainsi naquit le “Shadow IT”. Phénomène qui dans certaines entreprises a touché presque 40 % des applications utilisées.

 

Oui mais voilà, toutes ces applications qui tournent en dehors du contrôle de la DSI (et plus encore de la visibilité des RSSI), n’ont pas forcément le bon niveau de sécurité, de sauvegardes, de disponibilité… Par rapport à la criticité des données et à la disponibilité nécessaire. Les fournisseurs de Cloud public nous rassurent en nous expliquant que leurs datacenters sont les plus sûrs au monde (oui mais dans quels datacenters sont hébergées mes applications et mes données ?  Mystère et boule de gomme…). Que leurs équipes sont les plus capables, les mieux formées.

 

La vérité est à relativiser :

Mardi 8/06/2021 : Erreur d’un sous-traitant AWS. Beaucoup de sites Web dont ceux d’Amazon, de la maison blanche et de nombreux média sont indisponibles pendant plusieurs heures.

Mercredi 10/03/2021 : Incendie d’un datacenter OVH Cloud à Strasbourg (à priori lié à un feu de batterie d’un onduleur) => Tous les systèmes de sécurité anti-incendie n’ont pu empêcher le feu de se propager.

Résultat : 12 000 à 16 000 clients impactés. Et un constat amer pour certains : quand on choisit le plan de base à 15€ par mois pour un site marchand qui rapporte des dizaines de milliers d’euros par mois on fait le choix d’assurer une voiture de luxe neuve au tiers en se disant que les mécanismes de sécurité active et passive suffiront à éviter tous les accidents… Quel décideur, bien informé, ferait ça ?

Mercredi 25 novembre 2020 : Deuxième panne d’importance des services AWS (après celle catastrophique du 28 février 2017) => Résultat : Des dizaines de milliers d’entreprises à l’arrêt et plus cocasse encore. Le métro de New York City HS !

 

Quel est le point commun entre tous ces incidents ? Le dédouanement de responsabilité des fournisseurs de cloud public.

 

Le dédommagement proposé : 1 mois de gratuité du plan cloud souscrit ! (En plus c’est clairement écrit dans les conditions générales de vente et de service) Et en cas de vol de données : C’est la responsabilité pénale du souscripteur qui sera jugée (en vertu du RGPD ou toute autre obligation de protection des données personnelles). Le fournisseur de cloud public ne sera pas inquiété. Même si c’est lui le responsable de la brèche.

 

Il est temps pour les entreprises d’analyser leurs besoins par application :

 

– RTO (Recovery Time Objective) : Temps d’indisponibilité de l’application que l’entreprise peut se permettre

– RPO (Recovery Point Objective) : Quantité de données, exprimée en temps, que l’entreprise peut se permettre de perdre

– Sensibilité des données et risque financiers associés (vol par la compétition de données confidentielles, piratage et revente de données personnelles des clients ou des employés…)

– Besoin de performances

– Evolution prévisible des performances ou des volumétries associées à ces applications

– Sensibilité de l’accès à la donnée en cas de perte de liaison (par ex: coup de pelle dans la fibre optique privant un site de liaison au WAN ou à Internet)

– Budget disponible tout de suite ou lorsque l’application aura fait les preuves d’un ROI significatif

 

Et c’est fort de ces analyses, et pas avant, que nous pourrons déterminer le meilleur compromis pour fournir les ressources nécessaires à cette application :

– Cloud Public

– Cloud Privé (internalisé ou hébergé)

– Socle technique complètement dédié (internalisé ou hébergé)