Cloud computing : la définition du NIST et ses 5 caractéristiques

Quand on parle de « cloud », on pense souvent à « mettre ses données sur Internet ». C'est réducteur. Le cloud computing a une définition de référence, publiée par le NIST en 2011 (SP 800-145), qui tient en cinq caractéristiques essentielles : le libre-service à la demande, l'accès réseau large, la mutualisation des ressources, l'élasticité rapide et le service mesuré. Ce guide pose ces cinq caractéristiques dans leur formulation d'origine, puis sépare ce qui en découle en pratique, à commencer par le pay-as-you-go, qui est une conséquence du service mesuré et non l'une des cinq.

Ce que vous allez apprendre

La définition du cloud computing telle que le NIST la formule
Les 5 caractéristiques essentielles du NIST SP 800-145, dans leur ordre d'origine
Pourquoi le pay-as-you-go n'en fait pas partie, et d'où il vient
Les conséquences pratiques de ces cinq caractéristiques sur votre travail
Comment distinguer un vrai cloud d'un hébergement classique rebadgé

Aucun prérequis technique, ce guide est conçu pour les débutants. Si vous êtes déjà familier avec ces concepts, vous pouvez passer directement aux modèles XaaS (IaaS, PaaS, SaaS, FaaS, CaaS) ou à l'économie cloud (CAPEX vs OPEX).

1. Définition NIST du cloud computing

Le National Institute of Standards and Technology (NIST), agence de standardisation du département du Commerce des États-Unis, a publié en septembre 2011 la note SP 800-145, sept pages qui font toujours autorité en 2026. Sa définition tient en un paragraphe :

Un modèle permettant un accès réseau à la demande, pratique et ubiquitaire (depuis n'importe où) à un ensemble partagé de ressources informatiques configurables (réseaux, serveurs, stockage, applications, services) qui peuvent être rapidement provisionnées et libérées avec un minimum d'effort de gestion ou d'interaction avec le fournisseur.

Concrètement, le cloud, c'est :

Louer des ressources informatiques plutôt que les acheter.
Y accéder par le réseau, depuis n'importe quel type de terminal.
Scaler ces ressources à la demande, dans les deux sens.
Ne pas gérer l'infrastructure physique sous-jacente.

2. Quelles sont les 5 caractéristiques essentielles du NIST ?

Le NIST retient cinq caractéristiques essentielles, et une infrastructure doit les présenter toutes pour relever de sa définition du cloud. Dans l'ordre du document : le libre-service à la demande, l'accès réseau large, la mutualisation des ressources, l'élasticité rapide et le service mesuré. Elles sont reprises ci-dessous dans cet ordre, chacune avec ce que le texte d'origine dit et ce que cela change concrètement.

Caractéristique 1, le libre-service à la demande (on-demand self-service)

Ce que dit le NIST : le consommateur peut provisionner unilatéralement des capacités de calcul, comme du temps serveur ou du stockage réseau, sans interaction humaine avec chaque fournisseur de service.

Le mot décisif est unilatéralement. Ce n'est pas « rapidement » ni « en libre-service partiel » : c'est sans qu'un humain du fournisseur intervienne. Une offre où la création d'une machine passe par un bon de commande validé par un commercial ne tient pas cette caractéristique, même si le délai est court.

Avant le cloud, l'enfer des tickets

Dans un datacenter traditionnel, pour obtenir un nouveau serveur :

Remplir un bon de commande ou créer un ticket.
Attendre validation du manager et des achats.
Attendre la livraison du matériel (3 semaines à 3 mois).
Attendre qu'un technicien l'installe dans un rack.
Attendre la configuration par l'équipe système.
Recevoir enfin les accès.

Délai typique : 2 semaines à 6 mois. Pendant ce temps, vos concurrents avancent.

Avec le cloud, 30 secondes

Vous vous connectez à la console web (ou utilisez un script Terraform).
Vous choisissez le type de serveur, la taille, la région.
Vous lancez la création.
30 secondes plus tard, votre serveur est prêt et accessible en SSH.

Cette autonomie change radicalement la vitesse d'innovation. Vous testez une idée le matin, vous l'abandonnez l'après-midi si ça ne fonctionne pas, sans avoir engagé 100 000 € de matériel. C'est ce qui rend le cloud structurellement compatible avec les méthodes agiles et le DevOps.

Caractéristique 2, l'accès réseau large (broad network access)

Ce que dit le NIST : les capacités sont disponibles sur le réseau et accessibles par des mécanismes standard qui favorisent l'usage depuis des plateformes clientes hétérogènes, légères ou lourdes, comme des téléphones, des tablettes, des portables et des stations de travail.

C'est la caractéristique la plus souvent oubliée, et elle dit deux choses distinctes. D'abord que l'accès passe par le réseau, ce qui exclut une ressource qu'on ne peut piloter qu'en s'asseyant devant une console physique. Ensuite, et c'est le point réellement discriminant, que les mécanismes sont standard : des protocoles et des formats communs, typiquement HTTPS et des API REST, plutôt qu'un client propriétaire imposé.

Caractéristique 3, la mutualisation des ressources (resource pooling)

Ce que dit le NIST : les ressources du fournisseur sont mises en commun pour servir plusieurs consommateurs selon un modèle multi-tenant, les ressources physiques et virtuelles étant assignées et réassignées dynamiquement selon la demande. Le client n'a généralement ni contrôle ni connaissance de l'emplacement exact des ressources fournies, mais peut souvent le spécifier à un niveau d'abstraction plus élevé, par exemple le pays ou le datacenter.

Cette dernière phrase est celle qui fonde toute la question de la résidence des données : le NIST admet dès 2011 que le client puisse exiger un pays sans choisir une machine. C'est exactement le niveau auquel se joue le débat sur la souveraineté.

Comment ça marche

Imaginez un parking de 1 000 places. Si chaque entreprise du quartier devait construire son propre parking pour ses employés, ce serait un gaspillage énorme, les places sont vides la nuit, le week-end. Un parking partagé optimise l'utilisation : chacun paye uniquement quand il utilise une place.

Le cloud fait pareil :

Les fournisseurs cloud (Outscale, OVHcloud, Scaleway, AWS, Azure, GCP) ont des datacenters de plusieurs milliers à centaines de milliers de serveurs.
Ces serveurs sont répartis entre des milliers de clients.
Quand vous n'utilisez pas une ressource, elle est disponible pour quelqu'un d'autre.
Vous bénéficiez d'une infrastructure de niveau professionnel que vous ne pourriez jamais vous payer seul.

Les avantages de la mutualisation

Le PUE (Power Usage Effectiveness) est le rapport entre l'énergie totale consommée par un datacenter et celle qui alimente réellement les serveurs. Un PUE de 1,5 signifie que la moitié de l'énergie des serveurs est dépensée en plus pour le refroidissement et les pertes. Plus il est proche de 1, plus l'installation est efficace.

Avantage	Explication
Économies d'échelle	Acheter 100 000 serveurs coûte beaucoup moins cher par serveur que d'en acheter 10
Résilience	Un datacenter massif a plus de redondances (alimentation, réseau, refroidissement) qu'une petite salle serveur
Innovation	Les fournisseurs investissent massivement en R&D (IA, GPU, réseau très haut débit)
Sources	Uptime Institute, Global Data Center Survey 2025 et Google Data Centers, efficiency, consultés le 10 septembre 2026
Environnement	Mutualiser réduit le gaspillage énergétique global : Google publie un PUE de 1,09 sur sa flotte en 2025, contre une moyenne mondiale de 1,54 mesurée la même année par l'Uptime Institute

Caractéristique 4, l'élasticité rapide (rapid elasticity)

Ce que dit le NIST : les capacités peuvent être provisionnées et libérées de façon élastique, parfois automatiquement, pour croître et décroître rapidement en phase avec la demande. Du point de vue du consommateur, elles semblent souvent illimitées et mobilisables en toute quantité à tout moment.

Deux nuances comptent ici, et le texte d'origine les porte explicitement. L'automatisme est présenté comme fréquent, pas obligatoire : une élasticité pilotée par API sans autoscaling reste de l'élasticité. Et la ressource semble illimitée au client, ce qui n'est pas la même chose qu'être illimitée : les quotas de compte et les limites de capacité régionale existent.

⬆️ Scaling vertical (scale up)

Augmenter la puissance d'une seule machine : passer de 2 vCPU à 8 vCPU, de 4 Go RAM à 32 Go RAM.

Avantage : simple, pas de changement d'architecture applicative.

Limite : on finit par atteindre la capacité maximale disponible, et c'est cher.

➡️ Scaling horizontal (scale out)

Ajouter plus de machines identiques pour répartir la charge (de 5 serveurs à 50 serveurs).

Avantage : quasi illimité, plus résilient (si un serveur tombe, les autres continuent).

Complexité : nécessite une architecture distribuée (load balancer, sessions externalisées, code stateless).

Exemple concret : site e-commerce saisonnier

Imaginez un site qui vend des jouets, profil typique de charge variable :

Janvier-novembre : 5 serveurs suffisent (trafic normal ~10 000 visiteurs/jour).
Black Friday + Noël : pic à 200 000 visiteurs/jour, le cloud ajoute automatiquement 45 serveurs.
26 décembre : retour à la normale, le cloud retire les serveurs supplémentaires.

Sans cloud, vous auriez acheté 50 serveurs (pour le pic) qui dorment 11 mois sur 12. Avec le cloud, vous payez 5 serveurs 11 mois plus 50 serveurs quelques semaines. C'est mécaniquement beaucoup moins cher pour ce profil de charge.

Caractéristique 5, le service mesuré (measured service)

Ce que dit le NIST : les systèmes cloud contrôlent et optimisent automatiquement l'usage des ressources en s'appuyant sur une capacité de mesure adaptée au type de service, par exemple le stockage, le calcul, la bande passante ou les comptes utilisateurs actifs. L'usage est mesuré, contrôlé et rapporté, ce qui donne de la transparence au fournisseur comme au consommateur.

C'est de cette caractéristique que découle la facturation à l'usage, traitée dans la section suivante. Mais le NIST parle de mesure, pas de facturation : la transparence sur la consommation est la caractéristique, le prix qu'on y accroche est une décision commerciale.

Transparence et traçabilité

Dans un datacenter classique, il est difficile de savoir exactement combien coûte votre application. Avec le cloud, vous voyez en temps réel combien chaque ressource consomme, vous pouvez tagger vos ressources par projet/équipe/environnement, vous recevez des rapports détaillés (Cost Explorer AWS, Cost Management Azure, Billing GCP), vous définissez des budgets avec des alertes automatiques.

Exemples de métriques mesurées

Ce qui est durable dans le tableau ci-dessous, c'est la colonne du milieu : l'unité de facturation de chaque famille de service. Les ordres de grandeur, eux, bougent d'un fournisseur à l'autre et d'un trimestre à l'autre. Ils sont donnés pour fixer l'échelle, pas pour être mémorisés ni cités dans un chiffrage.

Ressource	Unité de facturation (durable)	Ordre de grandeur (septembre 2026)
VM (serveur)	Heures × type d'instance	~0,05 €/h pour 2 vCPU + 4 Go RAM
Stockage objet	Go-mois + nombre de requêtes	~0,02 €/Go/mois + 0,0004 €/1000 requêtes GET
Base managée	Heures × type + stockage + IOPS	~0,10 €/h + 0,10 €/Go + 0,10 €/M IOPS
Bande passante	Go transférés (egress payant, ingress gratuit)	~0,01 €/Go (souverain) à 0,12 €/Go (hyperscaler US)

3. Ce qui découle des cinq caractéristiques

Les cinq caractéristiques du NIST sont une définition, pas un mode d'emploi. Trois conséquences pratiques en découlent presque toujours, et ce sont elles que vous rencontrerez au quotidien. Les traiter séparément évite de les confondre avec la définition elle-même, confusion qui conduit à disqualifier des offres parfaitement conformes parce qu'elles ne facturent pas à la seconde.

Le pay-as-you-go, conséquence commerciale du service mesuré

Le principe : vous payez uniquement ce que vous consommez, à la seconde ou à la minute près. Pas de CAPEX (investissement initial), uniquement de l'OPEX (coûts d'exploitation variables). C'est ce que la plupart des fournisseurs ont construit au-dessus du service mesuré, sans que le NIST l'impose.

Comparaison CAPEX (investissement traditionnel) vs OPEX (cloud pay-as-you-go)

Comment ça fonctionne concrètement

Dans l'infrastructure traditionnelle, vous devez acheter suffisamment de serveurs pour gérer votre pic de charge (Black Friday, lancement de produit, campagne marketing). Le reste du temps, une large part de cette capacité reste inutilisée, mais vous avez déjà payé. L'écart dépend entièrement du profil de charge : un site dont le pic vaut dix fois la charge courante immobilise beaucoup plus de matériel qu'une application au trafic régulier.

Avec le cloud, vous créez 10 serveurs à 9h pour un pic de trafic, vous les utilisez pendant 6 heures, vous les supprimez à 15h. Vous payez seulement 6 heures de 10 serveurs, pas une infrastructure dimensionnée pour le pic 24/7.

💰 Infrastructure traditionnelle

Modèle CAPEX : vous achetez 100 serveurs pour gérer les pics.

Coût initial : 500 000 € (matériel + installation).
Utilisation moyenne : 30 % de la capacité.
Gaspillage : 70 % du budget dort la plupart du temps.
Délai : 2 à 6 mois entre l'achat et la mise en service.

Verdict : coûts fixes élevés avant même de générer du revenu.

☁️ Cloud pay-as-you-go

Modèle OPEX : vous louez ce dont vous avez besoin, quand vous en avez besoin.

Coût initial : 0 € (pas d'achat de matériel).
Utilisation : alignée sur la charge réelle.
Gaspillage : proche de 0 % si gouvernance correcte.
Délai : quelques secondes pour créer une ressource.

Verdict : coûts variables alignés sur l'activité réelle.

Implications du pay-as-you-go

Aspect	Impact
Budget	Bascule CAPEX → OPEX, plus besoin d'investir massivement au départ
Innovation	Tester une idée avec 50 € et scaler si ça fonctionne
Optimisation	Incitation à éteindre ce qui ne sert pas (test, dev, environnements de nuit)
Risque	Sans surveillance, les coûts peuvent exploser (ressources oubliées, sur-dimensionnement)

L'API-first, conséquence technique du libre-service

Un libre-service sans interaction humaine suppose une interface machine. C'est pourquoi tout cloud sérieux expose une API avant d'exposer une console web : la console est un client de l'API, pas l'inverse. Cette conséquence est celle qui rend possibles Terraform, Ansible et les pipelines CI/CD, et elle est détaillée dans le principe API-first.

L'infrastructure as code, conséquence organisationnelle des deux précédentes

Quand une infrastructure se crée par appel API et se facture à la durée d'existence, la décrire dans du code versionné cesse d'être une élégance pour devenir la seule façon de savoir ce qui tourne et pourquoi. C'est le basculement culturel que le NIST ne décrit pas, parce qu'il définit une technologie, pas une pratique.

4. Les 5 caractéristiques se déclinent à tous les niveaux XaaS

Une question revient souvent : « est-ce que ces cinq caractéristiques s'appliquent uniquement à l'IaaS, ou aussi au PaaS, FaaS, SaaS ? » La réponse est qu'elles s'appliquent à tous les modèles XaaS, mais avec des nuances dans la mise en œuvre.

Caractéristique NIST	IaaS	CaaS	PaaS	FaaS	SaaS
Libre-service	API + console	API + manifestes	`git push`	Déploiement fonction	Inscription web
Accès réseau large	API HTTPS + SSH	API Kubernetes	API + Git	API + console	Navigateur + API
Mutualisation	Hyperviseur	Cluster partagé	Plateforme partagée	Containers éphémères	Application multi-tenant
Élasticité rapide	Auto Scaling Group	KEDA / HPA	Auto natif	Native zéro à milliers	Sièges ajustables
Service mesuré	Heures-CPU	Mémoire-secondes	Requêtes / dyno-h	Invocations / Go-s	Sièges actifs
Facturation observée	À l'heure / seconde	À la seconde	À la requête / heure	À la milliseconde	Par utilisateur / mois

Les cinq premières lignes sont les caractéristiques NIST, la dernière est en italique parce qu'elle n'en fait pas partie : c'est la conséquence tarifaire observée sur le marché, qui varie d'un fournisseur à l'autre et d'une année à l'autre. La grille XaaS complète est détaillée dans IaaS, PaaS, SaaS, FaaS, CaaS.

5. Cloud vs infrastructure traditionnelle, le tableau de comparaison

Critère	Infrastructure traditionnelle	Cloud computing
Modèle économique	CAPEX : achat matériel (500 k€ minimum)	OPEX : paiement à l'usage (dès 10 €/mois)
Délai de provisioning	2 semaines à 6 mois	30 secondes à 5 minutes
Scalabilité	Manuelle, lente, limitée	Automatique, rapide, quasi illimitée
Gestion	Vous gérez tout (matériel, OS, réseau, sécurité physique)	Vous gérez l'applicatif, le cloud gère l'infra
Résilience	Vous prévoyez tout (onduleurs, redondance réseau, sauvegardes)	Incluse dans l'offre (multi-AZ, SLA 99,9 %+)
Innovation	Limitée par votre budget matériel	Accès aux dernières technologies (GPU IA, K8s managé, FaaS)

6. Comment vérifier qu'une offre tient les 5 caractéristiques du NIST

Toutes les offres présentées comme « cloud » ne présentent pas les cinq caractéristiques essentielles. Avant d'engager une organisation sur une plateforme, il est utile de vérifier chacune à partir de la documentation et de tests fonctionnels. Les vérifications ci-dessous suivent l'ordre du NIST.

Vérifier le libre-service par API. Si la création d'une ressource (VM, base de données, espace de stockage) passe encore par un bon de commande validé manuellement par un commercial, l'offre n'est pas en libre-service à la demande au sens NIST. Une plateforme cloud doit permettre de créer, modifier et supprimer des ressources via une API ou une console, sans intervention humaine du fournisseur, en quelques minutes.

Vérifier l'accès réseau par mécanismes standard. La plateforme doit être pilotable sur le réseau par des protocoles communs, typiquement HTTPS et une API REST documentée, depuis n'importe quel type de terminal. Un client lourd propriétaire obligatoire, ou une console qui ne fonctionne que sur un navigateur précis, s'écarte de cette caractéristique. Le test tient en une commande : piloter une ressource depuis un terminal, avec curl ou la CLI du fournisseur, sans ouvrir l'interface web.

Vérifier la facturation à l'usage, en gardant en tête que c'est une conséquence et non l'une des cinq. Une facturation forfaitaire mensuelle ne disqualifie pas une offre au sens strict du NIST, mais elle vous prive du levier économique qui motive la plupart des migrations. Un test simple : éteindre une instance plusieurs jours et vérifier que la facture descend.

Vérifier l'élasticité automatique. Si l'ajout d'un serveur lors d'un pic de charge demande l'ouverture d'un ticket ou une configuration manuelle de plusieurs dizaines de minutes, la plateforme n'offre pas l'élasticité automatique attendue. Une plateforme cloud doit pouvoir ajuster automatiquement les ressources en fonction de la charge, via des règles d'autoscaling déclaratives ou un service qui scale nativement.

Vérifier la traçabilité de la consommation. La plateforme doit fournir un suivi détaillé de la consommation par ressource, par tag et par projet, accessible en temps quasi-réel via une console ou une API. Sans cette visibilité, la maîtrise des coûts et l'attribution des dépenses deviennent rapidement difficiles à grande échelle.

Vérifier la mutualisation et l'isolation. La plateforme doit reposer sur une infrastructure mutualisée, troisième caractéristique du NIST, tout en garantissant l'isolation entre tenants. Cette information figure généralement dans la documentation technique (technologies de virtualisation, modèles de partage des ressources, certifications obtenues).

Bonnes pratiques avant signature : vérifier chaque caractéristique sur la documentation officielle, demander un environnement de test pour les valider concrètement, et identifier les points où l'offre est explicitement plus restrictive que le standard NIST. Une offre qui ne présente pas plusieurs de ces caractéristiques peut rester pertinente pour un usage donné, mais doit être positionnée comme telle, pas comme du cloud au sens strict.

À retenir

Le cloud computing est défini par le NIST SP 800-145 (septembre 2011) sur cinq caractéristiques essentielles, toujours la référence en 2026.
Libre-service à la demande : provisionner unilatéralement, sans interaction humaine avec le fournisseur.
Accès réseau large : disponible sur le réseau, par des mécanismes standard, depuis des terminaux hétérogènes. Cela ne veut pas dire « exposé sur Internet ».
Mutualisation des ressources : modèle multi-tenant, avec une localisation choisie au niveau du pays ou du datacenter, pas de la machine.
Élasticité rapide : croître et décroître avec la demande, parfois automatiquement, en paraissant illimité au consommateur.
Service mesuré : usage mesuré, contrôlé et rapporté, ce qui donne la transparence aux deux parties.
Le pay-as-you-go n'est pas l'une des cinq : c'est une conséquence commerciale du service mesuré, et l'erreur la plus fréquente est de le substituer à l'accès réseau large.
Ces cinq caractéristiques se déclinent sur tous les modèles XaaS (IaaS, CaaS, PaaS, FaaS, SaaS) avec des nuances de mise en œuvre.

Prochaines étapes

IaaS, PaaS, SaaS, FaaS, CaaS Les 5 modèles de service cloud et leur grille XaaS unifiée.

CAPEX vs OPEX : économie du cloud La transformation économique fondamentale du cloud, conséquences pratiques sur la gouvernance.

Responsabilité partagée Qui sécurise quoi sur les 5 modèles XaaS, avec un tableau récapitulatif.

Cloud API-first Pourquoi tout est API dans le cloud et comment ça rend l'automatisation native.