Quand on parle de « cloud », on pense souvent à « mettre ses données sur Internet ». C'est réducteur. Le cloud computing est un modèle d'infrastructure qui repose sur 5 promesses fondamentales définies par le NIST en 2011 et toujours valables en 2026 : payer uniquement ce qu'on consomme (pay-as-you-go), s'adapter automatiquement à la charge (élasticité), se servir soi-même sans intermédiaire (libre-service), mutualiser les ressources entre clients, et mesurer précisément la consommation. Ce guide pose la définition technique, détaille les 5 promesses, et montre pourquoi un fournisseur qui n'en respecte pas tout n'est pas un vrai cloud.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La définition technique du cloud computing selon le NIST
- Les 5 promesses fondamentales que tient un vrai cloud
- Le modèle économique pay-as-you-go et ses implications
- Les avantages concrets par rapport à une infrastructure traditionnelle
- 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
Section intitulée « 1. Définition NIST du cloud computing »Le National Institute of Standards and Technology (NIST), référence mondiale en informatique, a publié en 2011 (NIST SP 800-145) la définition qui fait toujours autorité en 2026 :
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 via Internet ou un réseau privé.
- Payer uniquement ce qu'on consomme.
- Scaler ces ressources à la demande, dans les deux sens.
- Ne pas gérer l'infrastructure physique sous-jacente.
2. Les 5 promesses fondamentales du cloud
Section intitulée « 2. Les 5 promesses fondamentales du cloud »Pour qu'une infrastructure soit considérée comme du vrai cloud, elle doit tenir 5 promesses essentielles. Ces caractéristiques distinguent le cloud d'un simple hébergement ou d'un datacenter classique. Le NIST les appelle « caractéristiques essentielles », mais en français je préfère parler de promesses parce que beaucoup d'acteurs prétendent faire du cloud sans les tenir.
Promesse 1 — Pay-as-you-go (paiement à l'usage)
Section intitulée « Promesse 1 — Pay-as-you-go (paiement à l'usage) »La promesse : 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).
Comment ça fonctionne concrètement
Section intitulée « 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, 70 à 90 % de cette capacité reste inutilisée — mais vous avez déjà payé.
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
Section intitulée « 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) |
Promesse 2 — Élasticité (scaling automatique)
Section intitulée « Promesse 2 — Élasticité (scaling automatique) »La promesse : vos ressources s'adaptent automatiquement à la charge. Trafic qui monte ? Le cloud ajoute des serveurs. Trafic qui descend ? Il en retire.
Élasticité verticale vs horizontale
Section intitulée « Élasticité verticale vs horizontale »⬆️ 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
Section intitulée « 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.
Promesse 3 — Libre-service à la demande (self-service)
Section intitulée « Promesse 3 — Libre-service à la demande (self-service) »La promesse : vous créez, modifiez et supprimez vos ressources vous-même, sans passer par un technicien ou un service commercial.
Avant le cloud — l'enfer des tickets
Section intitulée « 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
Section intitulée « 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.
Promesse 4 — Mutualisation des ressources (resource pooling)
Section intitulée « Promesse 4 — Mutualisation des ressources (resource pooling) »La promesse : le fournisseur cloud mutualise ses datacenters entre des milliers de clients. Vous profitez d'une infrastructure massive sans avoir à l'acheter.
Comment ça marche
Section intitulée « 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
Section intitulée « Les avantages de la mutualisation »| 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) |
| Environnement | Mutualiser réduit le gaspillage énergétique global, PUE des datacenters cloud à 1,1–1,2 vs 2,0 en entreprise classique |
Promesse 5 — Disponibilité mesurée (measured service)
Section intitulée « Promesse 5 — Disponibilité mesurée (measured service) »La promesse : le cloud mesure précisément ce que vous consommez (CPU, RAM, stockage, requêtes, bande passante) et vous facture en conséquence.
Transparence et traçabilité
Section intitulée « 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
Section intitulée « Exemples de métriques mesurées »| Ressource | Métrique facturée | Ordre de grandeur |
|---|---|---|
| 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. Les 5 promesses se déclinent à tous les niveaux XaaS
Section intitulée « 3. Les 5 promesses se déclinent à tous les niveaux XaaS »Une question revient souvent : « est-ce que ces 5 promesses 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.
| Promesse | IaaS | CaaS | PaaS | FaaS | SaaS |
|---|---|---|---|---|---|
| Pay-as-you-go | À l'heure / seconde | À la seconde / minute | À la requête / heure | À la milliseconde | Par utilisateur / mois |
| Élasticité | Auto Scaling Group | KEDA / HPA | Auto natif | Native zéro à milliers | Souvent illimitée |
| Libre-service | API + console | API + manifestes | git push | Déploiement fonction | Inscription web |
| Mutualisation | Hyperviseur | Cluster partagé | Plateforme partagée | Containers éphémères | Application multi-tenant |
| Disponibilité mesurée | Heures-CPU | Mémoire-secondes | Requêtes / dyno-h | Invocations / Go-s | Sièges actifs |
Cette grille est utile pour comprendre que le modèle de facturation et le mécanisme d'élasticité changent radicalement selon le modèle, mais que les 5 promesses NIST restent la norme de référence que tout vrai cloud doit tenir. La grille XaaS complète est détaillée dans IaaS, PaaS, SaaS, FaaS, CaaS.
4. Cloud vs infrastructure traditionnelle — le tableau de comparaison
Section intitulée « 4. 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) |
5. Comment vérifier qu'une offre tient les 5 promesses NIST
Section intitulée « 5. Comment vérifier qu'une offre tient les 5 promesses NIST »Toutes les offres présentées comme « cloud » ne tiennent pas l'ensemble des 5 promesses NIST. Avant d'engager une organisation sur une plateforme, il est utile de vérifier concrètement chaque promesse à partir de la documentation et des tests fonctionnels.
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 la facturation à l'usage. Si la facturation est forfaitaire mensuelle (montant fixe pour une ressource indépendamment de son utilisation réelle), l'offre n'est pas en pay-as-you-go au sens NIST. Une plateforme cloud facture à la seconde, à la minute ou à l'heure selon le service, et arrête la facturation lorsque la ressource est libérée. Un test simple : éteindre une instance pendant 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 (la promesse n° 4 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 promesse 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 tient pas plusieurs promesses peut rester pertinente pour un usage donné, mais doit être positionnée comme telle, pas comme du cloud au sens strict.
À retenir
Section intitulée « À retenir »- Le cloud computing est défini par le NIST 2011 sur 5 promesses fondamentales toujours valables en 2026.
- Pay-as-you-go : payer uniquement ce qu'on consomme, transformer CAPEX en OPEX.
- Élasticité : s'adapter automatiquement à la charge, scale up/down.
- Libre-service : créer et gérer ses ressources soi-même via API ou console, sans intermédiaire.
- Mutualisation : profiter d'une infrastructure massive partagée entre clients, isolée par virtualisation.
- Disponibilité mesurée : connaître précisément sa consommation et ses coûts.
- Ces 5 promesses se déclinent sur tous les modèles XaaS (IaaS, CaaS, PaaS, FaaS, SaaS) avec des nuances de mise en œuvre.
- Toutes les offres présentées comme cloud ne tiennent pas l'ensemble des 5 promesses NIST : il est utile de les vérifier explicitement avant un engagement.