Définition du cloud : comprendre le modèle du NIST

Le cloud désigne des capacités informatiques et des logiciels utilisés par l'intermédiaire d'un réseau, au lieu de tout exécuter sur son propre appareil. Ces ressources peuvent comprendre des serveurs, du stockage, des bases de données, des applications et de la puissance de calcul. Il est ici question du cloud informatique.

La définition formelle va plus loin : le cloud computing fournit des ressources configurables issues d'un ensemble mutualisé, avec des moyens de les demander, de les modifier, de les libérer et d'en mesurer l'utilisation. Un ordinateur distant ne suffit pas à établir ce mode de fonctionnement.

Cette distinction devient utile lorsqu'un fournisseur qualifie son service de « cloud ». Ce guide explique la définition du NIST, les cinq caractéristiques qui la composent et les questions permettant d'évaluer concrètement un service.

Une définition simple du cloud

Pour l'utilisateur, le cloud permet d'obtenir des services informatiques par un réseau. Une application peut conserver des données partagées sur un stockage distant, un développeur peut demander une machine virtuelle ou une équipe peut utiliser un logiciel de comptabilité en ligne. L'appareil local exécute toujours une interface et peut aussi effectuer une part importante des traitements.

Le mot « cloud » désigne souvent les services et l'environnement utilisés. L'expression « cloud computing » insiste davantage sur la manière dont ces ressources sont fournies et gérées. Les usages se recoupent : il n'existe pas de frontière stricte entre les deux expressions.

Le nom vient d'une convention graphique : une forme de nuage peut représenter un réseau sans en montrer tous les équipements. Cloudflare explique cette métaphore des schémas réseau. Cette abstraction facilite la lecture du dessin ; le service réel a toujours besoin de processeurs, de stockage, de connexions, d'électricité et de refroidissement.

La définition formelle du cloud computing

La publication The NIST Definition of Cloud Computing, SP 800-145, décrit un modèle dans lequel les utilisateurs obtiennent à la demande des ressources informatiques configurables par un réseau. Ces ressources proviennent d'un ensemble mutualisé et peuvent être attribuées puis libérées rapidement, avec peu d'intervention manuelle du fournisseur.

Le NIST distingue cinq caractéristiques essentielles, trois modèles de service et quatre modèles de déploiement. Ils fournissent un vocabulaire pour comparer les services. Ils ne certifient ni la sécurité, ni la fiabilité, ni le prix, ni l'adéquation d'un fournisseur à votre travail.

La définition porte sur le fonctionnement. Qui peut demander des capacités ? Comment le système les attribue-t-il ? Peut-on les modifier ? Que mesure-t-il ? Le site web du service, son abonnement ou l'emploi du mot « cloud » ne répondent pas à ces questions.

Les cinq caractéristiques essentielles du cloud computing

1. Le libre-service à la demande

Les utilisateurs peuvent obtenir des capacités informatiques sans qu'un membre du personnel du fournisseur traite chaque demande courante. Par exemple, un développeur autorisé peut créer un serveur de test depuis un tableau de bord ou une API, puis le supprimer à la fin des essais.

Le libre-service peut coexister avec des vérifications de compte, des budgets, des quotas et des validations internes. La distinction utile consiste à savoir si le provisionnement courant passe par un service automatisé ou exige une intervention du fournisseur à chaque demande.

Pour un service logiciel, l'utilisateur peut gérer des comptes et des paramètres applicatifs plutôt que des serveurs individuels. Évaluez le libre-service au niveau de la fonction que le service fournit réellement.

2. Un accès réseau étendu

Les ressources sont accessibles par un réseau au moyen de mécanismes pris en charge. Il peut s'agir de navigateurs, d'applications, d'API et d'outils en ligne de commande utilisés depuis différents types d'appareils.

« Étendu » ne signifie ni anonyme, ni sans restriction, ni compatible avec tous les appareils. L'authentification, les autorisations, les règles réseau, les exigences logicielles et les politiques de l'organisation restent applicables. Un environnement cloud peut utiliser un réseau privé ou une connexion dédiée sans être exposé à l'internet public.

3. La mutualisation des ressources

Le fournisseur regroupe les ressources pour pouvoir attribuer puis réattribuer des capacités lorsque les besoins évoluent. Cet ensemble peut comprendre des ressources physiques et virtuelles : calcul, mémoire, stockage et capacité réseau.

Plusieurs utilisateurs ne correspondent pas nécessairement à des entreprises indépendantes. Un cloud privé peut mutualiser des ressources entre les services d'une même organisation. L'isolation des traitements reste nécessaire, même si leurs ressources sous-jacentes appartiennent à un ensemble commun.

Un client peut choisir une région ou un hébergement dédié sans sélectionner chaque composant physique. Vérifiez les règles réelles d'attribution et d'isolation du service : partager un ensemble de ressources ne signifie pas avoir accès aux fichiers d'un autre client.

4. Une élasticité rapide

La capacité peut augmenter et diminuer avec la demande, parfois automatiquement. Une application peut ajouter des instances de traitement lorsqu'une file de tâches se remplit, puis les libérer une fois les tâches terminées. L'élasticité comprend la réduction des capacités, pas seulement leur augmentation.

La capacité de mise à l'échelle décrit l'aptitude d'un système à traiter un volume de travail différent. L'élasticité concerne l'ajustement des ressources lorsque cette demande change. Aucune de ces propriétés ne supprime les limites de l'application, du compte, du réseau ou des capacités disponibles chez le fournisseur.

Par exemple, Amazon EC2 documente des quotas régionaux qui peuvent empêcher la création d'une instance. Le terme « cloud » ne promet donc pas des ressources illimitées ou immédiatement disponibles.

5. Un service mesuré

Le système mesure l'utilisation des ressources à un niveau adapté au service et rend ces informations disponibles pour le suivi, le contrôle et les rapports. La mesure peut porter sur le stockage, le temps de calcul, les données transférées ou les comptes utilisateurs actifs.

La mesure et la tarification sont deux questions distinctes. Un fournisseur peut mesurer la consommation tout en facturant un abonnement, une offre par paliers ou un engagement minimal. À l'inverse, une facturation à l'heure ne suffit pas à établir les autres caractéristiques du cloud.

Demandez quels événements déclenchent et arrêtent la facturation, quelles ressources subsistent après la fin d'un traitement et quelles mesures vous pouvez consulter. Un graphique d'utilisation n'est utile que si ses unités et son périmètre sont clairs.

Comment fonctionne le cloud computing ?

Prenons un développeur qui demande un environnement applicatif temporaire. La mise en œuvre varie, mais cette séquence relie l'interface du service aux équipements sous-jacents :

1. Le développeur soumet une demande. Un tableau de bord, une API, un outil en ligne de commande ou un déploiement automatisé décrit l'environnement nécessaire.
2. La plateforme vérifie les accès et les limites. L'identité, les autorisations, les règles, les quotas et la disponibilité déterminent si la demande peut aboutir.
3. Le logiciel de gestion attribue les ressources. La plateforme sélectionne les capacités de calcul, de stockage et de réseau adaptées, puis applique la configuration demandée.
4. Les équipements physiques réalisent le travail. Les processeurs exécutent les instructions, la mémoire contient les données de travail, le stockage conserve les informations et les réseaux transportent les échanges.
5. L'application devient accessible. Les utilisateurs passent par le chemin réseau autorisé. Leurs appareils continuent de gérer les logiciels locaux, la saisie et l'affichage.
6. La plateforme mesure et gère l'environnement. Les ressources peuvent être surveillées, modifiées ou libérées. Le stockage conservé et d'autres services peuvent nécessiter une suppression distincte.

Ouvrir une application existante ne crée pas nécessairement un nouveau serveur à chaque fois. Préparer un environnement et utiliser un service déjà en fonctionnement sont deux opérations différentes.

Les couches comprennent généralement l'infrastructure physique, les logiciels d'attribution des ressources, les services de plateforme et les applications. Les outils d'identité, de supervision, de facturation et de gestion interviennent à travers ces couches. Cette description n'impose pas une architecture identique à tous les fournisseurs.

Les modèles de service : que gère le fournisseur ?

L'infrastructure en tant que service (IaaS) fournit des ressources fondamentales comme le calcul, le stockage et le réseau. Le client peut installer et gérer des systèmes d'exploitation et des applications dans les limites du service. Une équipe qui exploite son application sur une machine virtuelle assume davantage de responsabilités opérationnelles qu'une équipe utilisant une application prête à l'emploi.

La plateforme en tant que service (PaaS) fournit un environnement pour déployer des applications avec les outils et les environnements d'exécution pris en charge. Le client gère le code, le comportement applicatif, la configuration et les données, tandis que le fournisseur prend en charge davantage de composants sous-jacents. L'explication du PaaS par Google Cloud décrit cette répartition entre développement applicatif et exploitation de la plateforme.

Le logiciel en tant que service (SaaS) fournit une application exploitée par le fournisseur. Les messageries web, logiciels de comptabilité et services de documents partagés peuvent relever de ce modèle. Les clients gèrent toujours les accès, les paramètres, les données et leurs usages. Une interface dans un navigateur ou un abonnement ne suffit pas à établir qu'une application suit le modèle cloud.

Le serverless est une catégorie apparue dans l'industrie après la définition du NIST, et non son quatrième modèle de service original. Il désigne généralement l'utilisation d'un service sans devoir préparer et gérer en continu des serveurs individuels. Le Function as a Service est une approche : des événements déclenchent du code exécuté dans des environnements gérés par le fournisseur. La documentation AWS Lambda en donne un exemple concret. Les serveurs existent toujours ; les autorisations, le code, les dépendances et les limites du service demandent encore de l'attention.

Les modèles de déploiement : qui peut utiliser l'environnement ?

Le cloud public est proposé à l'usage du public par un fournisseur. Les ressources des clients disposent normalement de contrôles d'accès : « public » ne signifie pas que les documents ou bases de données sont lisibles par tous.

Le cloud privé est réservé à l'usage exclusif d'une organisation. Cette organisation, un tiers ou une combinaison des deux peut le posséder et l'exploiter, dans ses locaux ou ailleurs. L'usage exclusif ne démontre pas une meilleure sécurité et n'exige pas la propriété de chaque bâtiment ou serveur.

Le cloud communautaire sert un groupe défini d'organisations partageant certaines préoccupations, comme une mission ou des exigences de sécurité. Le cloud hybride, dans la classification du NIST, relie au moins deux environnements cloud distincts tout en permettant le déplacement de données ou d'applications entre eux. Posséder des ordinateurs au bureau et un abonnement en ligne ne suffit pas à établir cette intégration.

Le multicloud désigne le recours à plusieurs fournisseurs cloud. C'est un terme courant de l'industrie, pas l'un des quatre modèles de déploiement originaux du NIST. Une installation peut être à la fois hybride et multicloud, mais aucune de ces étiquettes ne démontre que le basculement, la gestion des identités ou la migration fonctionne.

Ces classifications répondent à des questions différentes. Un cloud privé peut fournir de l'infrastructure ou des services applicatifs. Un cloud public peut proposer plusieurs modèles de service. La géographie et la répartition physique des équipements constituent d'autres choix de conception.

Qu'est-ce qui ne constitue pas automatiquement du cloud computing ?

Internet : il s'agit d'un système de réseaux interconnectés. Les services cloud peuvent l'utiliser, mais une connexion réseau ne constitue pas à elle seule un ensemble de ressources informatiques gérées. Une connexion privée peut également transporter le trafic cloud.

Un centre de données : c'est un site qui abrite des équipements informatiques et leurs systèmes de support. Il peut héberger une plateforme cloud, des serveurs dédiés ou des applications classiques. Notre guide sur l'emplacement physique des données dans le cloud distingue les installations, les régions, les serveurs et les copies de données.

Un serveur distant ou un compte d'hébergement : l'accès à distance ne dit pas comment les capacités sont attribuées, mutualisées, ajustées ou mesurées. L'hébergement peut utiliser une infrastructure cloud, mais l'étiquette du fournisseur et une facture mensuelle fixe ne suffisent pas à trancher.

La virtualisation : exécuter des machines virtuelles sur un hôte physique peut faciliter l'attribution des ressources. Cela ne fournit pas, à soi seul, le libre-service, l'élasticité ou la mesure d'une plateforme cloud. Les conteneurs et les ressources bare metal peuvent aussi faire partie de services cloud.

Le stockage cloud : c'est une catégorie de service, plutôt qu'un synonyme de tout le cloud computing. Le calcul, les applications, les bases de données et les traitements gérés en sont d'autres usages. Le stockage n'apporte pas non plus automatiquement une sauvegarde restaurable : la synchronisation et la sauvegarde répondent à des problèmes différents.

Appliquer la définition à trois exemples

Un ordinateur de bureau accessible à distance. Une personne se connecte à une machine fixe par un réseau. Cela établit un accès distant. En l'absence d'éléments sur les autres caractéristiques, ce n'est pas suffisant pour qualifier l'installation de service cloud.

Une plateforme de développement interne. Les équipes demandent des environnements depuis un portail, utilisent des capacités mutualisées, redimensionnent leurs ressources et reçoivent des rapports d'utilisation. Cet exemple illustre un fonctionnement cloud, même si les équipements servent une seule organisation sur un réseau privé.

Une application gérée. Une organisation utilise une application exploitée par un fournisseur, avec des comptes administrés de manière centralisée et des accès configurables. Le fournisseur gère l'attribution des ressources sous-jacentes. Les utilisateurs n'ont pas besoin d'un tableau de bord de machines virtuelles pour que le service soit du SaaS, mais son mode de fourniture reste déterminant.

Les traitements d'IA suivent la même logique. Exécuter un modèle sur une instance GPU louée laisse davantage de responsabilités au client que l'utilisation d'un point de terminaison d'inférence géré. « IA » décrit le travail effectué ; le terme n'établit pas à lui seul un modèle de service ou de déploiement.

Les avantages et les compromis sont distincts de la définition

Les services cloud peuvent raccourcir le délai entre une demande et un environnement utilisable, réduire les achats de matériel local et donner accès à des logiciels gérés. L'intérêt dépend du travail à effectuer et des responsabilités transférées au fournisseur. Notre guide sur les avantages du cloud computing en examine les conditions pratiques.

Coût : comparez l'ensemble de l'installation, y compris le stockage conservé, les transferts de données, le support, les engagements, les licences et le temps de travail nécessaire à son exploitation. Un faible prix d'instance ne démontre pas un faible coût total. Le cloud ne supprime pas non plus tous les achats de matériel ou frais d'infrastructure.

Disponibilité : prenez en compte le service, votre connexion réseau et les dépendances comme l'identité ou la résolution de noms. La réplication et le basculement doivent être conçus et testés. La définition ne garantit aucun taux de disponibilité, et augmenter les capacités ne répare pas automatiquement une panne applicative.

Contrôle et localisation : établissez où les traitements et les données peuvent se trouver, y compris les sauvegardes et les services associés. Une région sélectionnée ne répond pas à toutes les questions sur l'accès, la conservation ou les obligations contractuelles. Consultez la documentation et le contrat du service concerné.

Sortie : vérifiez les formats d'export, les API, le volume de données, le temps de transfert et les dépendances aux fonctions gérées. Utiliser plusieurs fournisseurs ne rend pas automatiquement une application portable. Testez un petit export et une restauration avant qu'une migration devienne urgente.

Comment se répartissent les responsabilités de sécurité ?

Déplacer un traitement modifie l'entité qui exploite chaque couche. Le fournisseur peut gérer les installations, le matériel et une partie de la plateforme ou de l'application. Le client doit toujours administrer les contrôles dont il dispose.

Les recommandations de Microsoft sur la responsabilité partagée illustrent l'évolution de cette répartition entre IaaS, PaaS et SaaS. Les données, les comptes, les autorisations, la configuration et la protection des appareils clients restent des préoccupations importantes pour le client. Un utilisateur d'infrastructure gère aussi davantage de sécurité liée au système d'exploitation et aux applications.

Pour chaque traitement, précisez qui applique les correctifs, surveille, révoque les accès, restaure les données et répond aux incidents. Vérifiez cette répartition pour le service réel. Une classification cloud ne démontre pas que ces tâches sont couvertes ou que le service répond à vos exigences.

Le cloud doit-il être centralisé ?

La définition n'impose pas une seule organisation géographique. Les ressources peuvent se trouver dans de grandes installations régionales, sur les sites d'une organisation ou dans une infrastructure répartie entre plusieurs lieux. Les questions déterminantes portent sur leur fourniture et leur gestion.

Une infrastructure distribuée n'implique pas automatiquement une gouvernance décentralisée, un réseau pair à pair, du multicloud ou de l'edge computing. Ces termes décrivent des propriétés différentes. La distribution peut influer sur la latence, le placement et la gestion des pannes, mais ses avantages dépendent de la conception réelle et des conditions d'exploitation.

La présentation actuelle de l'architecture de Hivenet décrit des approches propres à chaque produit pour le calcul, l'inférence gérée, le stockage et le transfert de fichiers. Compute with Hivenet et un point de terminaison d'inférence géré offrent des niveaux de contrôle différents. La page précise également que les produits Hivenet n'utilisent pas tous un système identique.

La même évaluation s'applique : examinez les accès, l'attribution des ressources, les limites, la mesure, les responsabilités et les possibilités de sortie. La distribution ne garantit à elle seule ni la sécurité, ni la résilience, ni la performance environnementale.

Les questions à poser avant de choisir un service cloud

• Provisionnement : que peut créer ou modifier directement un utilisateur autorisé, et quelles opérations nécessitent le support ou une validation ?
• Capacité : comment fonctionne la mise à l'échelle, quels sont les quotas et que se passe-t-il si la capacité manque ?
• Mutualisation et isolation : quelles ressources sont partagées ou dédiées, et quelles limites protègent les traitements et les données ?
• Mesure et coût : quelles unités sont comptées, comment deviennent-elles des frais et qu'est-ce qui reste facturé après l'arrêt d'un travail ?
• Responsabilités : qui gère chaque couche, notamment les accès, les mises à jour, la supervision, les sauvegardes et les incidents ?
• Localisation et restauration : où les données et les traitements peuvent-ils se trouver, et comment teste-t-on la restauration et les procédures de panne ?
• Sortie : que peut-on exporter, dans quels formats et à quel coût, et quelles parties faudrait-il reconstruire ailleurs ?

Demandez des éléments vérifiables : de la documentation, un exemple de configuration, un rapport d'utilisation ou un petit test. La définition du cloud computing devient alors utile pour une décision réelle.

Questions fréquentes

Le cloud est-il simplement l'ordinateur de quelqu'un d'autre ?

Cette formule rappelle la présence d'équipements physiques, mais omet le mode de fonctionnement. Le cloud computing comprend aussi le libre-service, la mutualisation, l'accès réseau, l'élasticité et la mesure. Une organisation peut exploiter un cloud privé sur une infrastructure qui lui appartient.

Le cloud computing utilise-t-il toujours internet ?

Il nécessite un accès réseau, qui peut inclure des réseaux privés et des connexions dédiées. L'accès par l'internet public est courant, mais l'exposition publique n'est pas une exigence de la définition.

Un service mesuré signifie-t-il que l'on paie uniquement ce que l'on utilise ?

Non. L'utilisation peut être mesurée dans le cadre d'abonnements, de paliers, de réservations ou d'engagements minimaux. Vérifiez les règles de facturation autant que les mesures d'utilisation.

Respecter la définition signifie-t-il qu'un service est bon ?

Non. Cela établit des caractéristiques de son mode de fourniture. Les performances, la restauration, la sécurité, le coût et la possibilité de quitter le service nécessitent des preuves distinctes.