Les cinq caractéristiques essentielles du cloud computing

Le cloud computing possède cinq caractéristiques essentielles : le libre-service à la demande, l'accès réseau étendu, la mutualisation des ressources, l'élasticité rapide et la mesure de l'utilisation. Elles décrivent la manière dont un service fournit des ressources informatiques, adapte sa capacité et suit leur consommation.

Cette liste provient de la définition du cloud computing publiée par le NIST en septembre 2011. Elle donne aux acheteurs et aux équipes techniques une base commune pour examiner un service. Elle ne démontre pas que celui-ci est sûr, économique ou adapté à une application précise.

Quelles sont les cinq caractéristiques du cloud computing ?

• Libre-service à la demande : demander et gérer les ressources disponibles par une interface, sans négocier chaque opération courante avec le fournisseur.
• Accès réseau étendu : accéder au service par un réseau, avec des mécanismes standards et des clients compatibles.
• Mutualisation des ressources : utiliser une capacité que le fournisseur attribue et réattribue à différents utilisateurs.
• Élasticité rapide : augmenter et réduire la capacité assez rapidement pour répondre aux variations de la demande.
• Mesure de l'utilisation : surveiller, contrôler et présenter la consommation à un niveau adapté au service.

Ces caractéristiques concernent le service examiné. Un fournisseur peut proposer à la fois des services cloud et de l'hébergement classique. Un client peut aussi choisir de ne pas utiliser toutes les fonctions disponibles. Il faut donc évaluer l'offre et sa configuration, sans se fier uniquement au nom du fournisseur.

1. Le libre-service à la demande

Le libre-service à la demande permet à un client autorisé de lancer la mise à disposition d'une ressource sans contacter le fournisseur à chaque demande. Un développeur peut, par exemple, créer une machine de test depuis une console, une API ou un outil en ligne de commande, puis la supprimer une fois les essais terminés.

Le client dispose d'une opération reproductible dont le résultat est documenté. Derrière cette interface, le fournisseur doit valider la demande, attribuer la capacité, appliquer les autorisations et rendre la ressource utilisable. Cela réduit le besoin de faire organiser chaque modification par le service commercial ou l'assistance.

Le libre-service reste encadré

Une organisation peut exiger une validation interne des dépenses avant d'autoriser la création de ressources. Le fournisseur peut également imposer des vérifications de compte, des quotas, des conditions de paiement et des limites de disponibilité par région. Aucun de ces éléments ne suffit, à lui seul, à exclure le libre-service.

Un portail constitue un indice utile, mais ne révèle pas toutes les opérations internes. Le guide d'évaluation du NIST publié en 2018, disponible en anglais, distingue la mise à disposition entièrement automatisée d'une interface de demande automatisée suivie d'un travail manuel chez le fournisseur. Ce second cas doit être évalué selon les besoins du client. Vérifiez les délais réels : un bouton ne prouve pas que le déploiement est immédiat.

Test pratique : créez une ressource temporaire avec un compte client ordinaire, modifiez sa taille si le service le permet, puis supprimez-la. Notez les étapes, les délais, les autorisations et les éventuelles interventions du fournisseur. Vérifiez si l'arrêt libère la ressource et met fin à sa facturation, ou suspend seulement une partie du service.

2. L'accès réseau étendu

L'accès réseau étendu signifie que le service est accessible par un réseau avec des mécanismes standards. Un navigateur peut fournir l'interface d'administration, tandis qu'une application utilise une API documentée ou un autre protocole pris en charge.

Une équipe peut ainsi administrer un service de stockage depuis des ordinateurs portables compatibles, pendant qu'une application récupère des fichiers par son API. Le fournisseur exploite les points d'accès et les interfaces réseau nécessaires. Le client doit disposer d'une connexion adaptée, d'identifiants et des droits requis.

L'accès réseau peut être restreint

Un accès étendu n'exige ni site ouvert sans authentification ni point d'accès sur Internet public. Un cloud privé peut être accessible par le réseau d'une organisation ou par des connexions privées autorisées. La question est de savoir si les clients prévus peuvent y accéder avec les mécanismes proposés depuis les lieux nécessaires.

L'accès dépend aussi de la compatibilité des appareils, des règles réseau, des pannes et des restrictions géographiques. Une interface Web ou une API ne garantit ni faible latence, ni bande passante illimitée, ni fonctionnement hors ligne.

Test pratique : connectez-vous depuis les réseaux et les appareils que l'équipe utilisera. Vérifiez l'authentification, les interfaces documentées, les restrictions et le comportement prévu en cas de coupure. Une démonstration réussie dans les locaux du fournisseur ne prouve pas qu'une équipe distante pourra utiliser le service de façon fiable.

3. La mutualisation des ressources

La mutualisation consiste à regrouper de la capacité, puis à l'attribuer et la réattribuer à différents utilisateurs selon la demande. Elle peut concerner le calcul, la mémoire, le stockage, la bande passante et les ressources qui font fonctionner une application.

Imaginez plusieurs équipes créant des environnements de développement temporaires. Lorsqu'une équipe libère de la capacité, celle-ci redevient disponible pour une autre attribution. Les systèmes d'ordonnancement et de gestion du fournisseur coordonnent ces opérations et doivent maintenir la séparation nécessaire entre les utilisateurs.

La mutualisation ne place pas tous les clients sur un même serveur

Une architecture multilocataire, ou « multitenant », sert plusieurs clients sur une infrastructure commune avec une séparation logique. Cela ne signifie pas que tous utilisent la même machine physique au même moment. Un service peut attribuer des machines dédiées depuis un ensemble de ressources plus large. Dans un cloud privé, les utilisateurs peuvent être les départements d'une seule organisation.

Le client choisit souvent une région ou un emplacement général, sans sélectionner un disque ou un serveur précis. Cette abstraction ne rend pas la localisation des données secondaire. Notre guide sur les emplacements physiques du stockage cloud explique pourquoi les données principales, les copies et les sauvegardes nécessitent des vérifications distinctes.

La mutualisation soulève aussi des questions d'exploitation. Des composants partagés peuvent subir une concurrence pour les ressources, et l'isolation dépend de contrôles précis. Le fournisseur doit pouvoir expliquer les limites de capacité, les règles d'attribution et les composants partagés ou dédiés.

Test pratique : demandez comment la capacité est attribuée et à quels niveaux elle est partagée. Consultez la documentation sur l'isolation des clients, les choix de localisation et les limites de performance. Une partie de ces informations doit venir du fournisseur : un tableau de bord client ne permet pas d'inspecter toute l'infrastructure sous-jacente.

4. L'élasticité rapide

L'élasticité rapide permet d'augmenter et de réduire la capacité selon la demande. Une application qui traite une file de tâches variable peut ajouter des processus de traitement lorsque le travail s'accumule, puis les retirer une fois la file résorbée.

Le fournisseur rend une capacité supplémentaire disponible et permet sa libération. Le client ou le service géré prend les décisions d'ajustement. L'automatisation est courante, mais la définition du NIST indique qu'elle intervient dans certains cas. Elle n'exige pas que chaque ressource cloud adapte sa capacité toute seule.

Élasticité et capacité de mise à l'échelle

La capacité de mise à l'échelle, aussi appelée scalabilité, désigne la possibilité de modifier les ressources pour traiter une quantité de travail différente. L'élasticité concerne leur adaptation aux variations de la demande, y compris leur réduction. Un système qui peut grandir après plusieurs semaines de préparation est extensible, mais ce processus peut être trop lent pour un pic de trafic bref.

La mise à l'échelle verticale modifie les ressources d'une instance existante, par exemple sa mémoire. La mise à l'échelle horizontale ajoute ou retire des instances ou des processus de traitement. L'explication de l'élasticité proposée par Google Cloud, en anglais, présente ces approches. Le choix dépend de l'application et des commandes accessibles dans le service.

L'application et la capacité disponible imposent des limites

Ajouter des machines ne résout pas tous les goulets d'étranglement. L'application doit répartir le travail et gérer correctement son état, ses connexions et ses dépendances. Des traitements sans état peuvent simplifier l'ajout d'instances, mais des systèmes avec état peuvent aussi évoluer si leurs mécanismes de données et de coordination le permettent.

Les quotas, la capacité régionale, les délais de démarrage et la disponibilité des ressources limitent l'expansion. Réduire la capacité peut demander de terminer les requêtes actives ou de préserver des données. Un service élastique peut donner au client l'impression de disposer d'une réserve importante, mais son infrastructure reste limitée.

Test pratique : faites augmenter puis diminuer la demande de manière contrôlée. Mesurez le délai avant que la capacité soit utilisable, vérifiez que le travail se termine correctement et observez la réduction des ressources. Contrôlez l'allocation minimale, le quota maximal et les frais qui continuent après le retrait des ressources supplémentaires.

5. La mesure de l'utilisation

Un service mesuré utilise des mécanismes de comptage pour surveiller, contrôler et présenter la consommation des ressources. Selon le service, les unités pertinentes peuvent être le temps de calcul, les données stockées, les requêtes, les transferts ou les comptes utilisateurs actifs.

Le fournisseur collecte les données d'utilisation à un niveau approprié et met des informations utiles à la disposition du client. Ces relevés peuvent servir à planifier la capacité, appliquer des quotas, répartir des coûts en interne et établir la facturation. Dans un cloud privé, une équipe peut consulter sa part de consommation même si aucun paiement n'intervient entre départements.

La mesure et le prix relèvent de choix distincts

Le paiement à l'usage est une façon de tarifer un service mesuré. Un abonnement fixe peut également inclure des mesures de consommation, des limites ou des rapports. À l'inverse, un tarif horaire ne démontre pas l'existence des quatre autres caractéristiques du cloud.

La mesure doit aider à comprendre la consommation, sans garantir une facture simple. Les montants minimaux, les engagements, les transferts, le stockage conservé et les services supplémentaires peuvent modifier le total. Un tableau de bord doit aussi présenter assez de détails et être actualisé assez souvent pour permettre au client de prendre ses décisions.

Test pratique : exécutez une petite quantité de travail connue, puis retrouvez-la dans le rapport d'utilisation. Vérifiez l'unité, le délai de remontée, la période de regroupement et les consommations qui continuent après la suppression de la ressource principale. Comparez le rapport aux règles tarifaires : chaque indicateur visible n'est pas forcément une unité facturée.

Comment les cinq caractéristiques fonctionnent ensemble

Prenons le cas fictif d'une équipe traitant un lot d'images pour un catalogue de produits. Cet exemple décrit un fonctionnement possible, sans attribuer ces capacités à un fournisseur particulier.

1. Un développeur crée un environnement de traitement autorisé par une API. C'est le libre-service.
2. Le logiciel de l'équipe envoie les tâches et récupère les résultats par des interfaces réseau documentées. C'est l'accès réseau étendu.
3. Le fournisseur attribue du calcul et du stockage depuis des ressources disponibles pour plusieurs utilisateurs. C'est la mutualisation.
4. L'équipe ajoute des processus de traitement quand la file est longue, puis les retire à mesure que le travail se termine. C'est l'élasticité, si ces changements sont assez rapides pour la tâche.
5. Des rapports présentent la consommation de calcul et de stockage pertinente. C'est la mesure de l'utilisation, si le niveau de détail répond aux besoins de l'équipe.

L'équipe doit toujours définir les autorisations, protéger les fichiers sources, gérer les échecs et contrôler les coûts. La libération des ressources de traitement peut laisser des résultats et des sauvegardes stockés. Les cinq caractéristiques expliquent le comportement du service ; les responsabilités restantes déterminent la qualité de son utilisation.

Caractéristiques, avantages et technologies du cloud

Une caractéristique décrit une propriété de fonctionnement. Un avantage est un résultat recherché. L'élasticité peut réduire le besoin de garder une capacité permanente pour des pics occasionnels, mais les économies dépendent des prix, de la demande et de la configuration. Les mesures peuvent aider à maîtriser les coûts, à condition que quelqu'un utilise ces informations.

La sécurité, la fiabilité et la durabilité nécessitent leurs propres preuves. Elles dépendent de l'architecture, de l'exploitation, des décisions du client et de l'application. Elles ne sont pas des éléments supplémentaires de la liste du NIST.

Les machines virtuelles, les conteneurs, les API et les logiciels d'orchestration peuvent contribuer à construire des services cloud. Ce sont des technologies de mise en œuvre. IaaS, PaaS et SaaS décrivent les capacités fournies au client et ce qu'il gère. Public, privé, communautaire et hybride désignent des modèles de déploiement. Aucune de ces catégories n'ajoute une sixième caractéristique essentielle.

Qu'est-ce qui ne suffit pas à définir un service cloud ?

Un serveur hébergé à distance indique un hébergement distant. La virtualisation indique une abstraction des ressources. Un centre de données fournit une infrastructure physique. Une application Web donne un moyen d'accéder à un logiciel. Un abonnement décrit une relation commerciale.

Chacun de ces éléments peut faire partie d'un service cloud, sans établir à lui seul le modèle complet. Un serveur fixe dont le redimensionnement prend plusieurs jours peut convenir à une charge stable tout en offrant peu d'élasticité utile. Une application Web peut fonctionner sur une infrastructure cloud sans fournir à ses clients un service qui possède les cinq caractéristiques.

Évaluez la capacité que le client reçoit réellement. La plateforme cloud sous-jacente d'un fournisseur ne transforme pas automatiquement toutes les offres qui y reposent en services cloud.

Comment évaluer un service cloud

Commencez par une petite charge de travail représentative et définissez ce qui constitue un comportement acceptable pour votre équipe. Un traitement de recherche, une application publique et un service documentaire interne peuvent avoir des besoins différents en matière d'accès et de délai de réponse.

• Mise à disposition : documentez les étapes habituelles, les droits, le délai et la procédure de libération.
• Accès : vérifiez les interfaces et les lieux nécessaires avec les clients prévus.
• Attribution : demandez des informations sur la mutualisation, l'isolation, les options dédiées et la localisation.
• Variations de capacité : testez l'augmentation et la réduction avec une demande réaliste, en tenant compte des limites et des échecs.
• Mesure : rapprochez un exemple de traitement des relevés d'utilisation et des frais applicables.

Évaluez ensuite séparément les contrôles de sécurité, la reprise, l'assistance, la localisation des données, la portabilité et les coûts de sortie. Gardez les informations manquantes sous forme de questions ouvertes. Un service peut correspondre au modèle cloud tout en étant mal adapté à une application précise.

Questions fréquentes

Les caractéristiques du NIST restent-elles pertinentes ?

Elles restent utiles comme vocabulaire commun pour examiner le fonctionnement d'un service. La définition date de 2011 et le guide d'évaluation de 2018. Ils constituent une base, sans décrire toutes les architectures modernes ni certifier un fournisseur particulier.

Un cloud privé doit-il posséder les cinq caractéristiques ?

Oui, dans le modèle du NIST, les cinq caractéristiques s'appliquent aussi au cloud privé. Les ressources peuvent être mutualisées entre plusieurs utilisateurs d'une même organisation. Posséder des serveurs ou réserver l'accès à une entreprise ne suffit pas à créer un cloud privé.

Chaque client doit-il activer l'ajustement automatique de la capacité ?

Non. Les capacités d'un service et la configuration choisie par le client sont deux choses différentes. Un client peut garder une allocation stable ou gérer les changements manuellement. Il faut examiner les possibilités du service et vérifier si la configuration retenue répond aux besoins de l'application.

Le paiement à l'usage est-il une caractéristique essentielle du cloud ?

La mesure de l'utilisation est essentielle. Le paiement à l'usage est une méthode tarifaire qui peut s'appuyer sur ces mesures. Les abonnements et les clouds privés peuvent mesurer la consommation sans facturer chaque unité individuellement.