Cloud Services

Cloudy Monday IV : Aujourd'hui dans le nuage, et puis on verra bien!

Dans de nombreux domaines, des mesures ont été prises ces dernières années pour réduire les coûts en raison de la pression croissante sur les prix. Des efforts ont été faits dans divers domaines, souvent aussi ceux qui ont entraîné des coûts supplémentaires à court terme. Que ce soit par un projet ou par l'achat d'une infrastructure ou d'un logiciel. En principe, rien ne s'oppose à cette démarche et des économies ont ainsi été réalisées. Mais où y a-t-il encore du potentiel ? Dans l'informatique en particulier, la migration et la consolidation des moyens informatiques dans le cloud promettent un potentiel d'économies non négligeable.

Par Nicolas Dörig, Product Manager

Mais comment s'assurer que le Journey to the Cloud soit un succès?

Décider d'une telle démarche d'un point de vue financier est une chose, mais convaincre la culture et surtout les différentes personnes de ton entreprise de devenir des supporters ou des promoteurs inconditionnels d'une telle approche est une tâche herculéenne en soi. Enfin, un tel projet suscite des craintes existentielles et une forte résistance qui peut faire échouer l'objectif souhaité de réduction des coûts et d'augmentation de l'efficacité. Une approche intéressante pour les fournisseurs de solutions cloud serait, en plus de la vente de la solution technique, de proposer une offre de services autour du changement de culture.

Les alternatives et les perspectives d'avenir qu'une entreprise peut présenter à ses collaborateurs lors du lancement d'un tel projet constituent donc un facteur de réussite.

Mais ce n'est pas seulement la culture qui doit s'adapter à la nouvelle situation, car on ne change pas de culture comme ça, en passant ! Il est donc essentiel pour la décision d'entreprendre le Journey to the Cloud que les collaborateurs comprennent pourquoi cela doit être fait et où les chances et les avantages en découlent pour eux.

Un autre facteur de réussite est le changement de mentalité dans la planification des ressources et la budgétisation des infrastructures et des logiciels. Au début, on gérait soi-même l'informatique, généralement encore petite, et les coûts étaient secondaires. Avec la prise de conscience croissante des coûts et le fait que le savoir-faire informatique s'appuie sur une base plus large, l'informatique est passée du statut d'acteur principal incontesté à celui de moyen pour atteindre un but et on a donc cherché des solutions qui réduisent les coûts. Des termes comme outsourcing, offshoring, nearshoring faisaient bonne figure dans chaque rapport d'activité et montraient la volonté de minimiser les coûts. Mais la gestion des ressources était toujours étroitement liée au contrôle de gestion et à la comptabilité financière. On analysait, on évaluait et, généralement sur la base des coûts et des avantages, on décidait quelle solution utiliser. Il est clair que les clients ne cherchaient pas vraiment des services avec des SLA définis chez un outsourcer IT, mais voulaient avoir leur mot à dire sur ce qu'il devait faire et comment.

Pourquoi serait-ce différent dans le cloud?

A l'avenir, nous irons donc vers le cloud, et c'est là qu'il faut commencer à penser différemment. Le fournisseur d'une solution cloud utilise des composants techniques qui ne doivent en aucun cas intéresser le client. Ce qui doit intéresser les clients, ce sont les niveaux de service et les paramètres de performance garantis. Les clients achètent un standard et économisent ainsi des coûts, le fournisseur de cloud économise quant à lui des coûts grâce à la masse ou à la similitude de la production du service et aux synergies qui en découlent, également connues sous le terme d'économies d'échelle.

Voici un petit exemple tiré du produit Dynamic Database de Swisscom:

Ce service met à disposition du client une Oracle DB as a Service, c'est-à-dire l'infrastructure, les licences, le support et les options telles que la haute disponibilité, la reprise après sinistre et la sauvegarde, le tout dans un prix journalier ou horaire. Le client ne paie que ce qu'il utilise et n'est pas lié à long terme.

Auparavant, les clients devaient dimensionner leur infrastructure dès l'achat de manière à ce que les coûts de licence soient supportables, mais que la solution ne doive pas être remplacée au bout d'un an en cas de croissance continue. Les erreurs d'évaluation coûtaient cher et il y avait trois scénarios possibles qui pouvaient se produire:

  • A) Surdimensionnement: une infrastructure trop chère a été mise en place, ce qui a nécessité l'achat de plus de licences, mais elle n'a jamais été utilisée.
  • B) Sous-dimensionnement: investissement supplémentaire, car avant même que le premier système ne soit amorti, il a fallu en acheter un nouveau et, pour cela, acheter également les licences.
  • C) Jackpot: L'hypothèse correspondait à l'évolution réelle.

Si l'on demandait aujourd'hui aux entreprises quel est le scénario le plus fréquent, je ne pense pas que beaucoup d'entre elles répondraient honnêtement à cette question en évoquant le scénario C ! Ce qui est également négligé ici, c'est que le scénario B avait une chance valable de se terminer ensuite par un sous-dimensionnement ou même un surdimensionnement.

En plus d'une mauvaise évaluation du dimensionnement d'une solution, un autre point est tout aussi important. Quel que soit le scénario dans lequel l'investissement s'est terminé, il s'agissait d'un pré-investissement qui a immobilisé le capital et qui a entraîné des coûts annuels pour le support de licence et la maintenance en raison des conditions contractuelles.

Dans l'ensemble, il s'agit d'une affaire très coûteuse, qui ne tient même pas compte des coûts de renouvellement du système et des frais de personnel pour les spécialistes des bases de données!

Pour rester dans l'exemple: Dynamic Database rendrait cet investissement caduc après une courte commande de migration (à titre indicatif, 2 jours ouvrables). Mais la condition pour le client est évidente. Il achète un service standardisé qui permet de choisir certaines options et offre également certains niveaux de service comme la disponibilité et le temps de support. La détermination des éléments d'infrastructure tels que le type de serveur, la fréquence du CPU, etc. n'est pas (plus) de la responsabilité du client. En revanche, le client économise de l'argent, parfois même beaucoup d'argent.

Cela me ramène à la question de départ: pourquoi serait-ce différent pour le cloud?

Parce que les règles du jeu ont changé et que la budgétisation de l'informatique devient plus variable, exactement comme une facture de téléphone portable il y a quelques années. Après une période de stabilisation, on pouvait dire ce que l'on devait payer approximativement par mois, car on connaissait son propre comportement d'utilisation. Surtout dans les jeunes années, lorsque l'argent se faisait rare ou que l'on voulait acheter quelque chose de cher, on envoyait éventuellement quelques SMS de moins ou on utilisait la ligne fixe et on optimisait ainsi les coûts. Dans le cloud, cela ne fonctionne pas différemment et qui sait, peut-être que les premiers forfaits seront bientôt disponibles pour le cloud B2B.

Le changement de mentalité est donc un autre facteur de réussite sur le chemin du cloud. Je suis toujours étonné des discussions dans lesquelles je suis impliqué lorsque je présente Dynamic Database à des clients : Combien veulent philosopher avec moi sur le matériel et ses performances et combien veulent discuter du pack de licences inclus. Comment ils m'expliquent qu'ils n'ont pas besoin de certaines options de licence offertes avec le service et qu'il est possible de les exclure pour obtenir un prix plus avantageux. Mais le fait qu'ils aient été surlicenciés pendant des années en raison d'un matériel surdimensionné et que Dynamic Database leur permettrait de se débarrasser immédiatement de leurs investissements élevés ou de leur immobilisation de capital, semble encore hors de question pour beaucoup lors de la première conversation. Probablement parce que beaucoup agissent encore dans leurs vieux schémas de pensée et veulent simplement minimiser le prix et chercher le potentiel en essayant de supprimer les services qui ne sont pas pertinents pour eux. Mais c'est justement à cause de ces individualisations que les fournisseurs IT ont eu du mal dans le passé à maîtriser leurs structures de coûts et à proposer des offres intéressantes aux clients.

En résumé:

Pour réussir le Journey to the Cloud, il faut montrer clairement à ses collaborateurs les objectifs qui y sont liés, faire des collaborateurs des participants, leur montrer des perspectives et jeter les vieux schémas de pensée par-dessus bord. Avant tout, il faut être prêt à acheter un service standardisé, pour lequel on ne peut pas décider dans les moindres détails de la manière dont il est produit, mais on peut bien sûr toujours poser des exigences en termes de niveau de service.

Actuellement, nous sommes dans une phase d'apprentissage où ce changement de mentalité a lieu. Voici une belle déclaration d'un client que j'ai entendue il y a quelques semaines : "Nous voulons utiliser votre service standard, mais nous ne voulons que 15 jours de sauvegarde et non 31 jours et avec l'offre XS, nous n'avons pas besoin de 16 Go de RAM, 8 Go suffisent. Comment cela affecte-t-il les prix?" 🙂

In diesem Sinne, préparons-nous pour le voyage vers le nuage.

Nicolas Dörig

Nicolas Dörig

Product Manager

Plus d’articles getIT

Prêts pour Swisscom

Trouve le Job ou l’univers professionnel qui te convient. Où tu veux co-créer et évoluer.

Ce qui nous définit, c’est toi.

Vers les univers professionnels

Vers les postes vacants cybersécurité