Cloud hybride et multicloud : distinction, arbitrages et coûts cachés

Le cloud hybride relie un environnement privé ou local à un cloud public, avec une continuité assumée entre les deux. Le multicloud répartit des charges entre plusieurs fournisseurs publics, sans qu’ils communiquent nécessairement. Les deux termes sont employés indifféremment dans les argumentaires commerciaux, alors qu’ils répondent à des problèmes distincts et n’ont pas le même coût. Cette page pose la distinction, les raisons réelles d’y arriver et les postes que les projections omettent, dans le prolongement de notre couverture cloud et infrastructure.

Deux modèles, deux problèmes

Définition. Le cloud hybride désigne une architecture reliant un environnement privé ou local à un ou plusieurs clouds publics, avec des flux et une continuité opérationnelle organisés entre les deux. Le multicloud désigne l’usage de plusieurs fournisseurs de cloud public, que leurs environnements communiquent ou non.

Une organisation peut être les deux à la fois, et beaucoup le sont sans l’avoir décidé.

Le multicloud est plus souvent subi que choisi

C’est le constat que les présentations d’éditeurs escamotent. Rares sont les directions informatiques qui décident un beau matin de répartir leurs charges entre trois fournisseurs. Elles y arrivent par quatre chemins :

• Une acquisition qui apporte un système d’information construit ailleurs.
• Une décision métier prise sans passer par la DSI, un service souscrit directement par une direction.
• Une spécialisation réelle, quand un fournisseur porte un service que les autres n’égalent pas.
• Une contrainte réglementaire qui impose de placer certaines charges chez un acteur qualifié, traitée dans notre section cloud souverain.

Seuls les deux derniers chemins relèvent d’un arbitrage. Les deux premiers produisent un multicloud non gouverné, qui cumule les coûts sans produire les bénéfices attendus.

Les coûts que les projections oublient

La multiplication des modèles de sécurité. Chaque fournisseur a son modèle d’identités, de politiques et de journalisation. Maintenir une posture homogène sur deux environnements demande un effort qui ne double pas, il croît plus vite que le nombre de fournisseurs.

Les compétences. Une équipe compétente sur un fournisseur ne l’est pas mécaniquement sur un autre. Le coût de la double compétence, ou de la double équipe, est le poste le plus systématiquement sous-évalué.

Les frais de transfert sortant. Ils frappent précisément les architectures qui font dialoguer deux clouds. Une conception qui répartit une même chaîne applicative entre deux fournisseurs paie ce dialogue au volume, en permanence.

La liaison réseau, sur l’hybride. Une interconnexion dédiée entre le site et le fournisseur a un coût récurrent et devient un point de défaillance unique s’il n’est pas doublé.

La cohérence des données. C’est la difficulté technique dominante sur l’hybride. Répliquer, synchroniser ou partitionner des données entre deux environnements suppose des choix de conception que l’on ne défait pas facilement.

Ce que la portabilité suppose réellement

L’argument le plus fréquent en faveur du multicloud est la réduction de la dépendance et le levier de négociation. Il n’est valable que sous une condition : que les applications aient été conçues pour être portables.

Or la portabilité suppose de renoncer aux services managés qui justifiaient le choix du fournisseur. Une application qui exploite une base de données propriétaire et un service d’authentification spécifique ne se déplace pas, quel que soit le nombre de fournisseurs contractualisés. Le levier de négociation n’existe que si la menace de partir est crédible.

La conteneurisation est la réponse la plus solide à ce problème, développée dans notre section Kubernetes et orchestration. Elle a son propre coût, mais elle rend la portabilité mesurable plutôt que théorique.

Instruire la décision

1. Cartographier l’existant. Quels fournisseurs sont réellement en usage, y compris les services souscrits hors DSI. L’inventaire révèle presque toujours plus d’acteurs que prévu.

2. Qualifier chaque présence : décision d’architecture, contrainte réglementaire, héritage d’acquisition, ou dérive. Les deux dernières catégories appellent une décision de rationalisation.

3. Chiffrer la double exploitation avant d’ajouter un fournisseur, compétences comprises. Voir notre section pilotage de la dépense cloud.

4. Décider du niveau d’homogénéité visé. Une gouvernance unifiée de la sécurité et des identités sur plusieurs fournisseurs est atteignable, mais c’est un chantier à part entière, pas une conséquence automatique.

Explorer le cluster

Cette page fait partie de notre couverture des architectures cloud et infrastructures d’entreprise : hyperscalers, souveraineté, coûts, migration et datacenters.

iTPro+ : recevez chaque semaine les analyses d’architecture et les arbitrages de coût qui concernent les directions informatiques.