Qu'est-ce que le cloud public ? Fonctionnement et compromis

La technologie du cloud public permet aux particuliers et aux organisations d'utiliser les services informatiques d'un fournisseur qui les propose à un large marché. Vous pouvez louer de la puissance de calcul, stocker des données applicatives, déployer du code ou utiliser une application sans exploiter vous-même l'infrastructure physique sous-jacente.

Le mot « public » désigne les clients auxquels le service est proposé. Il ne signifie pas que tout le monde peut lire vos fichiers, accéder à votre compte ou se connecter à vos serveurs. Ces possibilités dépendent du produit, de ses contrôles d'accès et de votre configuration.

Cette distinction aide à comparer cloud public, cloud privé et cloud hybride. Elle sépare aussi trois questions : qui peut souscrire au service, où fonctionne son infrastructure et quelles tâches le fournisseur prend en charge.

Qu'est-ce que le cloud public ?

Le cloud public est un modèle de déploiement dans lequel une infrastructure cloud est proposée au grand public. Ses clients peuvent être des particuliers, des entreprises, des universités ou des organismes publics. Le fournisseur définit les conditions du service, les critères d'accès, les emplacements disponibles et la capacité proposée.

La définition du cloud public du NIST prévoit qu'il puisse appartenir à des acteurs commerciaux, universitaires ou publics, ou à une combinaison de ces acteurs. Le terme ne désigne donc pas uniquement les offres d'entreprises technologiques privées.

Le cloud a aussi des caractéristiques plus précises que le simple hébergement d'un serveur à distance. La définition du cloud computing du NIST décrit le provisionnement en libre-service, l'accès par le réseau, la mutualisation des ressources, l'élasticité et la mesure de l'utilisation. Ces fonctions permettent de demander et de libérer des ressources sans organiser chaque changement matériel.

L'élasticité connaît des limites concrètes. Les quotas du compte, le matériel disponible, la capacité régionale, les restrictions du produit et la conception de l'application déterminent la croissance possible d'une charge de travail. Un service cloud peut faciliter cette croissance sans garantir des ressources illimitées.

Ce que signifie le mot « public »

L'accès commence généralement par un compte ou un contrat. Les droits d'administration dépendent ensuite des identités, des autorisations et de l'authentification. Un client peut choisir de rendre une application accessible sur Internet tout en conservant une base de données et des interfaces de gestion privées.

Par exemple, Amazon S3 indique que les nouveaux compartiments et objets ne sont pas publics par défaut. Des autorisations peuvent ouvrir l'accès, tandis que des contrôles distincts peuvent le bloquer. Le modèle de déploiement ne suffit donc pas à déterminer si des données sont exposées.

La mutualisation signifie souvent que plusieurs clients utilisent une même infrastructure, avec une isolation entre leurs charges de travail. Elle n'impose pas le partage de chaque serveur physique. Les hôtes dédiés Amazon EC2 fournissent, par exemple, des serveurs physiques réservés à un client au sein de l'offre de cloud public d'AWS.

Cloud public ne signifie pas non plus accès gratuit, connexion exclusivement par Internet ou facturation limitée au temps de calcul actif. Un fournisseur peut proposer des connexions privées, des abonnements, des engagements minimaux, de la capacité réservée et des frais à l'usage. Vérifiez les conditions et les unités de facturation du service.

Comment fonctionne la technologie du cloud public ?

Un cloud public relie des ressources physiques à une plateforme logicielle qui les attribue et les présente sous forme de services. Trois couches permettent de comprendre ce qui se passe derrière une console ou une API.

L'infrastructure physique

Les processeurs, GPU, mémoires, supports de stockage et équipements réseau exécutent le travail. Ils dépendent de locaux, d'électricité, de refroidissement, de sécurité physique et de maintenance. L'infrastructure reste matérielle même lorsque le client ne voit jamais les machines.

Les équipements peuvent être regroupés dans de grands centres de données ou répartis entre plusieurs installations. Les régions et le matériel proposés varient selon le fournisseur et le produit. Notre guide sur les lieux de stockage du cloud explique pourquoi l'emplacement compte pour les performances et le traitement des données.

La plateforme de gestion des ressources

La virtualisation, les systèmes de conteneurs, l'ordonnancement et l'orchestration contribuent à attribuer la capacité physique. Les logiciels réseau et de stockage relient les charges de travail et gèrent les données. Les services d'identité, les API, les compteurs d'utilisation et la facturation rendent ces ressources accessibles aux clients.

Chaque produit n'utilise pas nécessairement toutes ces technologies. Une machine virtuelle, un serveur physique dédié et une base de données managée peuvent avoir des modèles d'isolation et d'exploitation différents dans le catalogue d'un même fournisseur.

Les services utilisés par les clients

Les clients utilisent des produits tels que des machines virtuelles, du stockage objet, des bases de données, des plateformes applicatives, des points de terminaison d'IA ou des logiciels hébergés. Chaque produit délimite différemment les tâches du fournisseur et celles du client.

Un développeur qui demande une machine virtuelle obtient un environnement à configurer. Une personne qui ouvre un éditeur de documents hébergé obtient une application à utiliser. Les deux peuvent reposer sur une infrastructure de cloud public, mais les compétences nécessaires et les contrôles disponibles diffèrent.

De la demande à la libération des ressources

Le cycle commence généralement par la création d'un compte ou l'accès à une organisation. Le client demande un service depuis une console ou une API. La plateforme vérifie les autorisations, les limites du compte et la capacité avant d'attribuer les ressources.

Le client déploie ensuite ses logiciels, charge des données ou configure l'application. La supervision et les relevés d'utilisation permettent de suivre le fonctionnement et la consommation. Selon le produit, l'ajustement de capacité peut être manuel, piloté par des règles ou intégré au service managé.

À la fin du travail, il faut comprendre ce que fait réellement l'arrêt d'une ressource. Arrêter le calcul peut laisser du stockage ou d'autres ressources facturables en place. L'export des données utiles et la suppression des ressources sont des étapes distinctes. Les règles de conservation peuvent aussi déterminer quand les copies stockées disparaissent.

Les modèles de service du cloud public

Le cloud public est un modèle de déploiement. L'infrastructure à la demande, la plateforme à la demande et le logiciel à la demande décrivent la part de la pile logicielle exploitée par le fournisseur.

• Infrastructure as a service (IaaS) : vous utilisez des ressources de calcul, de stockage ou de réseau et gérez les logiciels que vous y installez. Avec une machine virtuelle, le système d'exploitation invité et les applications restent généralement à la charge de votre équipe.
• Platform as a service (PaaS) : le fournisseur exploite une plateforme applicative, tandis que vous déployez et configurez votre code dans l'environnement pris en charge.
• Software as a service (SaaS) : vous utilisez une application prête à l'emploi. Votre travail porte sur les utilisateurs, la configuration, les données et l'intégration de l'application dans l'organisation.

Les services serverless peuvent retirer le provisionnement des serveurs du travail du client. Le terme ne décrit toutefois pas tous les services managés. Un point de terminaison d'IA managé peut notamment utiliser une capacité dédiée provisionnée. Vérifiez son comportement de mise à l'échelle et sa facturation : « managé » ne signifie pas automatiquement ajustement de capacité ou paiement à la requête.

Sécurité du cloud public et responsabilité partagée

Confier une charge de travail à un fournisseur modifie la répartition des tâches sans supprimer les responsabilités du client. Le guide de Microsoft sur la responsabilité partagée montre comment le périmètre du fournisseur s'élargit de l'IaaS au SaaS. Le client conserve des responsabilités concernant ses données, ses identités, les accès et la configuration qui lui revient.

Pour une machine virtuelle, cela peut inclure les mises à jour du système et la sécurité applicative. Avec une application prête à l'emploi, le client choisit encore les utilisateurs autorisés et les informations stockées. Vérifiez cette répartition produit par produit.

Prenons une petite équipe de recherche qui partage un environnement d'analyse. Une personne doit pouvoir modifier l'infrastructure ; une autre doit seulement exécuter un traitement. Leur donner à toutes deux les droits d'administration est une décision de l'équipe, pas une caractéristique inévitable du cloud public. L'équipe doit aussi décider où conserver les identifiants, comment retirer les accès après un départ et qui répond aux alertes.

Les contrôles du fournisseur comptent également. L'isolation, la maintenance, la gestion des incidents, la disponibilité et les engagements contractuels influencent le résultat. Les étiquettes « public » et « privé » ne prouvent ni la sécurité d'une charge de travail ni son adéquation à une exigence précise.

La reprise exige un plan. Déterminez ce qui est sauvegardé, qui peut le restaurer, le temps nécessaire et la manière de tester la procédure. Une seconde copie synchronisée n'est pas automatiquement une sauvegarde indépendante. Notre article sur la synchronisation et la sauvegarde cloud explique cette distinction.

Cloud public, privé, hybride et distribué

Cloud privé : l'usage exclusif d'une organisation

Un cloud privé sert une seule organisation, qui peut regrouper plusieurs équipes ou entités. Il peut être exploité en interne, par un tiers ou conjointement, dans les locaux de l'organisation ou ailleurs.

Du matériel dédié ne suffit pas à faire de l'ensemble du service un cloud privé. Un hôte dédié acheté dans un catalogue de cloud public peut rester intégré au service public du fournisseur. Examinez les conditions d'accès et d'exploitation de l'ensemble, au-delà du seul partage d'un processeur.

Le cloud privé peut proposer des contrôles adaptés à certains besoins, mais il exige aussi des personnes, une planification de capacité et des procédures d'exploitation. Son coût ne prend pas toujours la forme d'un achat initial de matériel : un cloud privé hébergé peut avoir une facturation récurrente.

Cloud hybride : des environnements cloud reliés

Dans la définition du NIST, le cloud hybride relie des infrastructures cloud distinctes qui conservent leur identité, grâce à des technologies permettant la portabilité des données ou des applications. Les organisations emploient aussi l'expression plus large « informatique hybride » pour des combinaisons comprenant des systèmes classiques sur site.

Acheter des services dans deux environnements ne les intègre pas automatiquement. Déplacer une application entre clouds public et privé peut exiger des changements de réseau, d'identité, de format de données, de dépendances et de déploiement. Le cloud bursting, qui utilise un autre environnement pour apporter de la capacité supplémentaire, doit être conçu et testé.

Cloud distribué : la répartition des ressources et du travail

Le mot « public » concerne les clients auxquels le service est proposé. Le mot « distribué » concerne la répartition et la coordination des ressources ou du travail entre plusieurs lieux ou machines. Un cloud public peut utiliser une infrastructure distribuée, tout comme un cloud privé.

Cette répartition ne garantit à elle seule ni résilience, ni souveraineté, ni faible latence, ni baisse des émissions, ni décentralisation du contrôle. Ces résultats dépendent de l'architecture et des choix d'exploitation. Pour comprendre la coordination entre machines, consultez notre article sur le fonctionnement du calcul distribué.

Avantages et compromis du cloud public

Le cloud public peut réduire le délai entre l'identification d'un besoin et l'obtention des ressources. Une équipe peut essayer un service ou exécuter un travail temporaire sans installer d'abord le matériel. Les services managés peuvent aussi réduire certaines tâches de maintenance, et le catalogue d'un fournisseur peut donner accès à des processeurs ou à des fonctions que l'équipe ne possède pas.

Ces avantages dépendent de la disponibilité, des démarches d'accès et de la charge de travail. Une instance GPU n'est utile que si la configuration nécessaire est disponible et si le traitement peut l'exploiter. Le choix entre plusieurs régions n'a d'intérêt que si le produit retenu est proposé aux endroits requis.

Les coûts demandent la même attention. Comparez le temps de calcul, le stockage, les transferts, les requêtes, l'assistance, les licences et le temps de travail de l'équipe. Un tarif horaire bas peut être compensé par une exécution lente, de la capacité inutilisée ou le déplacement de gros volumes de données. Une utilisation prévisible peut justifier un engagement, mais celui-ci reste à payer si la demande baisse.

Le cloud public crée aussi des dépendances envers le fournisseur, le réseau, l'accès au compte et les interfaces du service. Des fonctions propriétaires peuvent réduire le travail de développement tout en compliquant une migration future. Intégrez à la comparaison les formats d'export, la durée des transferts et la reconstruction des intégrations.

Quand envisager le cloud public ?

Le cloud public mérite souvent d'être évalué pour des projets temporaires, une demande variable, de nouvelles applications ou l'accès à du matériel spécialisé. Il peut aussi convenir à une équipe qui souhaite un produit managé parce que l'exploitation d'un service équivalent détournerait du temps de son activité principale.

Prenons une analyse qui dure deux semaines. Louer une capacité adaptée peut éviter l'achat de matériel pour une mission courte. La comparaison utile porte sur le coût et le délai nécessaires pour obtenir le résultat, y compris la préparation des données et la récupération des sorties. Pour un système constamment utilisé sur du matériel déjà possédé, le calcul peut être différent.

D'autres contraintes peuvent écarter un service : une connexion peu fiable, un fonctionnement hors ligne, des emplacements non proposés, une capacité indisponible ou un besoin de contrôle physique auquel le produit ne répond pas. Une demande stable ne rend pas automatiquement l'infrastructure privée moins chère, pas plus qu'une demande variable ne rend tout produit de cloud public adapté.

Pour l'apprentissage automatique, distinguez l'accès à un GPU d'un service de modèles managé. Entraîner un modèle sur votre propre instance laisse à votre équipe la gestion de l'environnement logiciel et de la chaîne de traitement des données. Un service managé modifie cette répartition, mais exige encore des décisions sur la sécurité des données, les accès et les résultats acceptables.

Les questions à poser avant de choisir

• Quel travail le service doit-il accomplir ? Définissez la charge, le délai cible, le volume de données et les dépendances logicielles avant de comparer les produits.
• Quelles tâches restent à notre charge ? Identifiez les responsables des systèmes d'exploitation, des accès, des secrets, des mises à jour, de la supervision et de la reprise.
• Où le travail peut-il s'exécuter ? Vérifiez le matériel, les emplacements, le traitement des données et les conditions contractuelles du produit précis.
• Comment l'isolation fonctionne-t-elle ? Examinez la séparation entre clients, les options dédiées, les contrôles d'identité et l'exposition réseau.
• Combien coûtera l'ensemble du travail ? Comptez le stockage conservé, les transferts, les engagements, les licences, l'assistance et le temps d'exploitation.
• Quelles sont les limites ? Vérifiez les quotas, la mise à l'échelle, la capacité disponible et le comportement du service lorsqu'une limite est atteinte.
• Comment reprendre après un incident ? Précisez la supervision, les contacts, les sauvegardes, les tests de restauration et l'interruption acceptable.
• Comment quitter le service ? Testez l'export des données utiles, la reconstruction des dépendances et la suppression des ressources et comptes selon les règles de conservation.

Un essai représentatif à petite échelle apporte des réponses concrètes. Notez la configuration, la durée du travail, les ressources encore facturées après sa fin et la capacité d'un autre membre de l'équipe à répéter la procédure.

Quelle place pour Hivenet ?

Hivenet présente sa plateforme comme un cloud distribué, avec des architectures propres à chaque produit. Cette description de l'infrastructure doit être distinguée du modèle d'accès de chaque produit et des tâches qu'il laisse au client.

Compute with Hivenet propose du calcul CPU et GPU à travers des machines virtuelles et des conteneurs. Le choix de l'environnement modifie les contrôles disponibles et les logiciels à gérer. L'Inference API de Hivenet fournit des points de terminaison de modèles managés. Son utilisation répartit donc les tâches autrement que l'exécution d'un modèle sur votre propre instance.

Le stockage objet S3 répond aux besoins des applications, tandis que Store et Send sont des applications prêtes à l'emploi pour stocker et partager des fichiers. Private AI fait l'objet d'un cadrage de déploiement distinct. Évaluez le produit nécessaire sans supposer que tous les services Hivenet partagent une architecture, un modèle d'isolation ou les mêmes responsabilités.

Questions fréquentes

Peut-on stocker des données sensibles dans un cloud public ?

C'est possible dans certains cas, mais le modèle de déploiement ne suffit pas à le décider. Évaluez les données, les accès, les emplacements, les fonctions du produit, le contrat et les exigences de votre organisation. Vérifiez aussi que votre équipe peut exploiter le service de façon adaptée.

Le cloud public est-il toujours moins cher que le cloud privé ?

Non. Le taux d'utilisation, les engagements, les transferts, le matériel existant, l'assistance et le temps de travail peuvent changer le résultat. Comparez le coût d'exécution et d'exploitation de la charge sur une période réaliste.

Le cloud public impose-t-il le partage des serveurs physiques ?

Non. De nombreux services mutualisent le matériel entre clients, mais un fournisseur de cloud public peut aussi proposer une capacité physique dédiée. L'accès au service et l'attribution du matériel sont deux questions distinctes.

Le cloud public est-il la même chose que le SaaS ?

Non. Le cloud public décrit un modèle de déploiement ; le SaaS décrit l'utilisation d'une application exploitée par un fournisseur. Un cloud public peut aussi proposer de l'infrastructure ou des plateformes applicatives.