Les cinq caractéristiques essentielles du cloud
Identifier les cinq caractéristiques du cloud computing selon la définition normative du NIST.
À retenir
- Le NIST SP 800-145 définit le cloud par cinq caractéristiques essentielles.
- Self-service, accès réseau, mutualisation, élasticité et mesure du service doivent coexister.
- L'élasticité implique la capacité à réduire la capacité, pas seulement à l'augmenter.
- Un contrat « cloud » doit être vérifié à l'aune de ces cinq critères, pas du seul discours commercial.
Une définition normative, pas marketing
Le terme « cloud » est souvent utilisé pour désigner n'importe quel service hébergé à distance. Pour éviter cette confusion, le NIST (National Institute of Standards and Technology) a publié en 2011 la Special Publication 800-145, qui définit le cloud computing par cinq caractéristiques essentielles, trois modèles de service et quatre modèles de déploiement. Cette définition fait aujourd'hui référence dans les contrats, les audits et les certifications.
Les cinq caractéristiques du NIST
- Self-service à la demande (on-demand self-service) : un utilisateur peut provisionner des ressources de calcul (VM, stockage, base de données) sans intervention humaine côté fournisseur, via une console ou une API.
- Accès réseau étendu (broad network access) : les services sont accessibles via le réseau, depuis des clients hétérogènes (postes, mobiles, API).
- Mutualisation des ressources (resource pooling) : les ressources physiques du fournisseur sont mutualisées entre plusieurs clients grâce à un modèle multi-tenant, avec allocation dynamique selon la demande.
- Élasticité rapide (rapid elasticity) : la capacité peut être augmentée ou réduite rapidement, parfois automatiquement, et paraît illimitée du point de vue du client.
- Service mesuré (measured service) : l'usage est mesuré et facturé (ou reporté) de façon transparente, typiquement au forfait ou à la consommation (pay-as-you-go).
Point clé
si un service ne présente pas ces cinq caractéristiques simultanément, ce n'est pas du cloud au sens NIST — c'est de l'hébergement traditionnel ou de l'infogérance, même si le marketing utilise le mot « cloud ».
Pourquoi cette définition compte en exploitation
Un ingénieur infrastructure doit pouvoir vérifier concrètement ces critères avant de signer un contrat cloud. Par exemple :
| Caractéristique | Question à poser au fournisseur |
|---|---|
| Self-service | Puis-je créer une VM sans ticket ni délai de traitement humain ? |
| Accès réseau | Quels protocoles et quelles zones géographiques sont couverts par le SLA réseau ? |
| Mutualisation | Quel isolement logique (VPC, tenant) protège mes données des autres clients ? |
| Élasticité | Le scaling automatique a-t-il une limite contractuelle ou technique ? |
| Service mesuré | La facturation est-elle horaire, à la seconde, ou par palier ? |
Attention
certains fournisseurs proposent un « cloud privé » qui n'est en réalité qu'une infrastructure virtualisée dédiée, sans self-service réel ni élasticité automatique. Vérifiez toujours l'existence d'une API de provisioning avant d'accepter l'appellation « cloud » dans un contrat.
Élasticité vs scalabilité : une nuance importante
L'élasticité n'est pas seulement la capacité à monter en charge (scalabilité) : c'est la capacité à monter et descendre rapidement, avec une facturation qui suit. Un système scalable mais non élastique peut ajouter des serveurs, mais continue de facturer même à l'arrêt de la charge.
# Exemple : ajustement d'élasticité côté Kubernetes (HPA)
kubectl autoscale deployment api --cpu-percent=60 --min=2 --max=10
kubectl get hpa
Cet exemple illustre l'élasticité au niveau applicatif : le nombre de pods varie automatiquement selon la charge CPU observée, dans les bornes définies.
Sur le terrain
lors d'un audit fournisseur pour un client d'Afrique francophone migrant vers le cloud, la question la plus révélatrice est souvent : « combien de temps entre ma demande de VM et sa disponibilité effective ? ». Un délai supérieur à quelques minutes trahit généralement un processus encore manuel derrière le portail self-service.
Astuce
gardez toujours la référence exacte NIST SP 800-145 sous la main lors des négociations contractuelles ; elle sert de base neutre pour départager un fournisseur qui survend son offre comme « cloud natif ».