Cloud public et cloud privé

Qui possède le matériel que vous utilisez

Un réseau hospitalier veut faire tourner son portail patient sur une infrastructure qu'il peut renforcer pendant la saison de la grippe et réduire une fois l'été venu. Son responsable conformité exige aussi que les dossiers patients ne quittent jamais du matériel que l'hôpital contrôle lui-même : pas de serveurs partagés, pas de charge de travail d'un voisin inconnu tournant juste à côté. À 3 rues de là, une startup de 3 personnes veut l'inverse : pas de centre de données, pas de personnel IT, et un produit prêt à lancer dans 6 semaines.

Les deux équipes veulent les mêmes caractéristiques du cloud, le libre-service à la demande, l'élasticité, mais elles ne peuvent pas les obtenir de la même infrastructure. Cette différence, qui possède le matériel et qui d'autre est autorisé à le partager, est ce que décrit un modèle de déploiement cloud. Cette leçon couvre les 3 modèles que le NIST définit autour de l'exclusivité : public, privé et communautaire. La prochaine leçon couvre ce qui se passe quand on les combine.

Cloud public : un fournisseur, de nombreux locataires

Dans un cloud public, un fournisseur externe comme AWS, Microsoft Azure ou Google Cloud possède et exploite le matériel, puis en vend l'accès comme service à quiconque est prêt à payer. La définition du NIST est directe sur le public visé : l'infrastructure est provisionnée pour un usage ouvert par le grand public. Vous ne possédez aucun serveur. Vous louez de la capacité, une machine virtuelle, un espace de stockage, une base de données gérée, depuis un réservoir partagé où puisent aussi des milliers d'autres clients, et le logiciel du fournisseur garde les données et charges de travail de chaque client isolées des autres.

Ce réservoir partagé est exactement ce qui rend le cloud public économique. Le fournisseur répartit le coût de ses centres de données entre tous ses clients, ce qui donne l'échelle, la variété de services et la tarification à l'usage qui ont rendu possible le lancement en 6 semaines de la startup. AWS résume ce compromis sans détour dans sa propre documentation : pour presque tous les usages, le cloud public l'emporte sur le coût, l'étendue des services et la rapidité de démarrage, précisément parce que vous ne payez ni pour construire ni pour exploiter la moindre infrastructure vous-même.

Cloud privé : une organisation, du matériel dédié

Un cloud privé inverse la propriété. Le NIST le définit comme une infrastructure provisionnée pour l'usage exclusif d'une seule organisation comprenant plusieurs consommateurs, par exemple plusieurs unités commerciales. Cette organisation, et non un fournisseur public, contrôle qui touche au matériel, où il se trouve physiquement, et comment il est sécurisé. C'est exactement ce que demandait le responsable conformité de l'hôpital.

Voici la frontière qui piège le plus souvent : posséder des serveurs virtualisés sur site ne fait pas automatiquement de vous un cloud privé. Un vrai cloud doit encore franchir les 5 caractéristiques du NIST vues dans le sujet précédent, et le libre-service à la demande en fait partie. Un centre de données où les développeurs ouvrent un ticket et attendent 2 jours pour obtenir une nouvelle machine virtuelle n'est pas un cloud privé. C'est de l'IT traditionnelle avec un hypervisor en plus. Une configuration ne mérite le nom "cloud privé" que si elle laisse aussi ses propres utilisateurs provisionner eux-mêmes des ressources à la demande, la même expérience instantanée et sans approbation qu'offre un cloud public, simplement réservée à une seule organisation plutôt qu'au grand public.

Même une fois cette barre franchie, la comparaison d'AWS reste franche sur ce qu'un cloud privé sacrifie : une seule organisation égale rarement l'étendue des services, le rythme des nouvelles fonctionnalités, ou les économies d'échelle qu'un fournisseur public répartit sur des millions de clients. Construire votre propre version d'un service comme Amazon S3 vous donne une facture à la forme de S3, pas S3 lui-même. AWS va jusqu'à dire qu'il est pratiquement impossible de reproduire l'infrastructure du cloud public en privé, et que la plupart des organisations qui ont essayé n'ont pas réellement obtenu des avantages comparables. C'est pourquoi AWS réserve le cloud privé à un cas étroit : les très grandes organisations qui exploitent déjà leurs propres centres de données et disposent du personnel d'infrastructure pour les faire tourner, pas le choix par défaut de la plupart des équipes.

Cloud communautaire : partagé entre, pas vendu à

Le NIST nomme un troisième modèle exclusif qui reçoit beaucoup moins d'attention : le cloud communautaire, une infrastructure provisionnée pour l'usage exclusif d'une communauté spécifique de consommateurs issus d'organisations qui partagent des préoccupations communes, comme une mission, une exigence de sécurité ou une obligation de conformité. Contrairement à un cloud public, un inconnu ne peut pas simplement s'inscrire. Contrairement à un cloud privé, plusieurs organisations le partagent, tant que chacune appartient à la même communauté vérifiée.

Vous rencontrez rarement, dans la vraie vie, un cloud communautaire qui colle exactement à la définition du manuel, mais les régions cloud gouvernementales s'en approchent le plus en pratique : des environnements isolés construits spécifiquement pour des agences gouvernementales et leurs prestataires vérifiés, qui partagent la même barre de conformité et de sécurité plutôt que d'être ouverts au grand public. C'est un point d'ancrage utile pour la définition, même si le cas le plus scolaire, des consortiums de recherche ou des groupes industriels partageant une exigence de conformité commune, reste marginal.

Comparer les 3 modèles

Choisir entre les 3 modèles

Revenons à l'hôpital et à la startup. La startup n'a aucun blocage de conformité et rien de sensible à protéger, donc le cloud public s'impose : aucun coût initial, et une capacité élastique dès le premier jour. La contrainte de l'hôpital n'est ni le coût ni la vitesse, c'est que les dossiers patients ne peuvent pas se trouver sur du matériel qu'il ne contrôle pas. Un cloud privé, coûteux à construire et à faire tourner, est le seul modèle qui satisfait cette exigence non négociable.

Repérez le même signal dans n'importe quel scénario que vous lisez. Des expressions comme "dédié", "matériel que nous contrôlons", ou une règle de conformité qui interdit l'infrastructure partagée pointent vers le cloud privé. Des expressions comme "payer seulement ce que vous utilisez", "aucun investissement initial", ou "lancer rapidement sans infrastructure à gérer" pointent vers le cloud public. "Partagé entre plusieurs organisations avec la même exigence de conformité" est le signal du cloud communautaire, et il apparaît assez rarement pour que, quand c'est le cas, ce soit presque toujours la bonne réponse plutôt qu'un piège.

Ce que vous emportez avec vous

La question qui distingue ces 3 modèles reste toujours la même : qui possède le matériel, et qui d'autre est autorisé à le partager. Le cloud public répond "un fournisseur, et quiconque paie". Le cloud privé répond "une seule organisation, personne d'autre, et seulement si le libre-service fait vraiment partie du contrat". Le cloud communautaire répond "un groupe vérifié, et seulement ce groupe". Les déploiements réels s'arrêtent rarement à un seul choix. La prochaine leçon couvre ce qui se passe quand une organisation les combine, en connectant une infrastructure privée au cloud public, ou en répartissant ses charges de travail entre plusieurs fournisseurs publics, et pourquoi ces 2 combinaisons ne sont pas la même chose.