Élasticité et scalabilité sont confondues neuf fois sur dix dans les conversations techniques. Les deux concepts sont distincts mais liés : la scalabilité est la capacité à grossir, l’élasticité est la capacité à grossir et rétrécir automatiquement selon la charge réelle. Une application peut être scalable sans être élastique (on-premise dimensionné pour le pic), une application réellement élastique exige des prérequis architecturaux précis (stateless, sessions externalisées, observabilité). Cette page pose les définitions, distingue scaling vertical et horizontal, et défend une opinion : viser l’élasticité par défaut sur tout nouveau projet en 2026 est une décision de design, pas un détail d’optimisation.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La différence précise entre scalabilité et élasticité
- Le scaling vertical (scale-up) vs horizontal (scale-out) et leurs limites
- Les prérequis architecturaux de l’élasticité (stateless, sessions, observabilité)
- Quand viser l’élasticité automatique et quand l’éviter
- Les pièges classiques de l’autoscaling mal réglé
Prérequis : avoir compris les 5 promesses du cloud. Si besoin, démarrez par Définition et promesses du cloud.
1. Les deux définitions précises
Section intitulée « 1. Les deux définitions précises »Avant tout, fixons le vocabulaire. La confusion vient du fait que dans le langage courant, on utilise « scalable » pour désigner toute application qui peut grossir, sans distinguer les modes.
Scalabilité
Section intitulée « Scalabilité »Définition : capacité d’un système à gérer une charge croissante en ajoutant des ressources (verticalement ou horizontalement). Le système peut être scalé manuellement, à la commande, à fréquence donnée — ce n’est pas implicitement automatique.
Une application scalable peut grossir, mais elle ne grossit pas automatiquement. Un cluster on-premise de 10 serveurs peut être scalé à 20 serveurs, mais cela demande de commander, racker, configurer — quelques semaines à plusieurs mois.
Élasticité
Section intitulée « Élasticité »Définition : capacité d’un système à s’adapter automatiquement à la charge en temps réel, en ajoutant ET retirant des ressources sans intervention humaine. L’élasticité est une propriété supplémentaire par rapport à la scalabilité.
Une application élastique est forcément scalable, mais une application scalable n’est pas forcément élastique. C’est la différence cruciale.
| Propriété | Scalable | Élastique |
|---|---|---|
| Peut grossir | ✅ | ✅ |
| Peut rétrécir | ⚠️ (manuel) | ✅ (auto) |
| Adaptation automatique | ❌ | ✅ |
| Granularité d’ajustement | Mois (on-prem) à minutes (cloud) | Secondes |
| Coût hors charge | Fixe (capacité réservée) | Quasi nul (scale to zero) |
L’analogie du restaurant
Section intitulée « L’analogie du restaurant »Scalable mais pas élastique : un restaurant qui peut louer une salle voisine pour un événement exceptionnel. Il faut prévenir 48 heures à l’avance, on paye la salle entière, on remet les meubles ensuite.
Élastique : un restaurant qui agrandit ou rétrécit sa salle automatiquement selon le nombre de clients qui rentrent, à la seconde, sans intervention humaine. C’est techniquement infaisable dans un restaurant — c’est ce que rend possible le cloud.
2. Les deux axes du scaling
Section intitulée « 2. Les deux axes du scaling »Quand on parle de scaling, deux directions sont possibles. Elles ne sont pas équivalentes et chacune a ses limites propres.
Scaling vertical (scale-up / scale-down)
Section intitulée « Scaling vertical (scale-up / scale-down) »Le scaling vertical consiste à augmenter la puissance d’une seule machine : passer de 2 vCPU à 8 vCPU, de 4 Go RAM à 32 Go RAM, de gp3 à io2 pour le disque.
Avantages :
- Simple à mettre en œuvre, pas de changement d’architecture applicative.
- Compatible avec les applications monolithiques non distribuées.
- Pas de problématique de cohérence distribuée (locks, transactions).
Limites :
- Plafond physique : on finit par atteindre la capacité maximale (par exemple 192 vCPU et 4 To RAM sur les plus grosses VMs cloud).
- Coût exponentiel : passer de m5.xlarge (4 vCPU) à m5.24xlarge (96 vCPU) coûte ~24 fois plus, mais l’application n’est rarement 24 fois plus rapide.
- Single Point of Failure : une seule grosse machine reste un SPOF.
- Indisponibilité au resize : redémarrage de la VM nécessaire dans la plupart des cas.
Scaling horizontal (scale-out / scale-in)
Section intitulée « Scaling horizontal (scale-out / scale-in) »Le scaling horizontal consiste à ajouter plus de machines identiques pour répartir la charge : de 5 serveurs à 50 serveurs derrière un load balancer.
Avantages :
- Quasi illimité : ajouter une 1001ᵉ instance se fait comme la 100ᵉ.
- Plus résilient : si un serveur tombe, les autres continuent.
- Coût linéaire : 10 serveurs coûtent 10× le prix d’un serveur, pas plus.
- Compatible avec l’élasticité automatique.
Complexité :
- Nécessite une architecture distribuée : load balancer, sessions partagées, code stateless.
- Nécessite une observabilité suffisante pour détecter quand scaler.
- Cohérence distribuée à gérer (locks externalisés, transactions saga, eventual consistency).
Tableau de décision
Section intitulée « Tableau de décision »| Critère | Scaling vertical | Scaling horizontal |
|---|---|---|
| Complexité applicative | Faible | Élevée |
| Plafond | Capacité d’une VM | Quasi illimité |
| Compatible élasticité | ❌ | ✅ |
| Compatible monolithe | ✅ | ⚠️ (selon design) |
| Coût relatif | Exponentiel au-delà du milieu de gamme | Linéaire |
| Tolérance aux pannes | SPOF | Tolérante |
3. Les prérequis architecturaux de l’élasticité
Section intitulée « 3. Les prérequis architecturaux de l’élasticité »L’élasticité automatique n’est pas qu’une question de service cloud — elle exige des propriétés applicatives précises. Sans ces prérequis, vous pouvez configurer un autoscaler mais il ne fonctionnera pas correctement.
Prérequis 1 — Stateless
Section intitulée « Prérequis 1 — Stateless »Vos serveurs applicatifs ne doivent pas conserver d’état local critique. Les sessions utilisateurs, les caches applicatifs, les fichiers temporaires importants doivent vivre ailleurs — Redis pour les sessions, Memcached pour les caches, S3 pour les uploads.
Sans stateless, le scale-in tue les utilisateurs connectés (leur session disparaît avec l’instance), et le scale-out ne marche pas correctement (le nouvel utilisateur arrive sur une instance qui n’a pas son contexte).
Prérequis 2 — Idempotence des opérations
Section intitulée « Prérequis 2 — Idempotence des opérations »Quand le load balancer redirige une requête sur une autre instance suite à un timeout, l’application doit pouvoir retraiter la requête sans effet de bord. Une commande passée deux fois ne doit pas créer deux commandes — c’est l’idempotence, sujet de Idempotence cloud.
Prérequis 3 — Health checks réalistes
Section intitulée « Prérequis 3 — Health checks réalistes »Le load balancer doit savoir rapidement quand une instance est défaillante. Les health checks classiques (/health qui retourne 200) sont insuffisants — il faut des health checks profonds qui valident la connectivité base de données, les services dépendants, l’état applicatif réel.
Prérequis 4 — Métriques actionnables
Section intitulée « Prérequis 4 — Métriques actionnables »L’autoscaler scale sur des métriques. Si vos seules métriques sont CPU et RAM, vous scalerez mal. Les métriques pertinentes pour scaler sont applicatives : latence p95, profondeur de queue, requêtes par seconde par instance. Sujet du futur guide monitoring-observability-concepts du sous-thème E.
Prérequis 5 — Démarrage rapide
Section intitulée « Prérequis 5 — Démarrage rapide »Si une instance met 5 minutes à devenir disponible (boot OS + install runtime + chargement du code), votre autoscaler réagit toujours 5 minutes après le pic. Pour gagner en réactivité : images pré-construites (Packer), containers (CaaS), ou serverless (FaaS).
4. Quand viser l’élasticité automatique
Section intitulée « 4. Quand viser l’élasticité automatique »L’élasticité a un coût de mise en place non négligeable (architecture distribuée, observabilité, tests de résilience). Elle ne se justifie pas sur tous les profils de charge.
Profils où l’élasticité est rentable
Section intitulée « Profils où l’élasticité est rentable »- Charge variable saisonnière : e-commerce avec pic Black Friday, sites événementiels, billetterie.
- Charge variable journalière : applications grand public avec pic 18h–22h, plateformes B2C.
- Charge bursty imprévisible : APIs publiques, fonctions event-driven.
- Workloads de calcul ponctuels : ML training, encodage vidéo, batch nuit.
Sur ces profils, le ratio pic / baseline est typiquement supérieur à 3, et l’élasticité économise 50 à 80 % de la facture compute.
Profils où l’élasticité est superflue
Section intitulée « Profils où l’élasticité est superflue »- Charge stable 24/7 avec peu de variation (< 30 %) : applications B2B internes, ERP, bases de données transactionnelles.
- Workloads avec contraintes strictes de latence : les cold starts d’autoscaling peuvent dégrader le p99.
- Applications stateful complexes où le coût de stateless dépasse le bénéfice d’élasticité.
Sur ces profils, un dimensionnement fixe avec Reserved Instances est plus simple et souvent moins cher au TCO.
5. Les pièges classiques de l’autoscaling
Section intitulée « 5. Les pièges classiques de l’autoscaling »Cinq pièges récurrents que je rencontre lors d’audits de production cloud.
🐌 Scaling trop lent
Le piège : les seuils sont à 80 % CPU sur 5 minutes, l’instance met 3 minutes à démarrer. Total : 8 minutes de dégradation utilisateur avant que le scale-out ne soulage.
Mitigation : seuils plus bas (60 %), démarrage plus rapide (containers), pre-warming d’instances en pool.
📉 Scale-in trop agressif
Le piège : la charge baisse à 14h, l’autoscaler tue 80 % des instances. À 14h05 le nouveau pic arrive et il faut tout redémarrer.
Mitigation : cooldown de scale-in long (15–30 min), garde-fou minimum d’instances, prévision de charge basée sur l’historique.
📊 Métriques non pertinentes
Le piège : scaling sur CPU alors que la latence applicative monte à cause d’une lenteur en base de données. Le CPU reste à 30 %, l’autoscaler ne scale pas, les utilisateurs subissent.
Mitigation : métriques applicatives (latence p95, queue depth), extension pour les triggers custom (KEDA dans l’écosystème Kubernetes).
💸 Coût qui explose
Le piège : pas de plafond max d’instances. Une attaque DDoS ou un bug fait scaler à 500 instances, facture multipliée par 100.
Mitigation : max_size dans l’Auto Scaling Group, alarmes coût, WAF / rate limiting en amont du LB.
🔄 Flapping
Le piège : la charge oscille autour du seuil, le scaler ajoute et retire des instances en boucle. Stress technique et facturation absurde.
Mitigation : seuils différents pour scale-out (60 %) et scale-in (40 %), cooldown long, métrique lissée sur 5 min.
6. Quand vise-t-on l’élasticité dès la conception ?
Section intitulée « 6. Quand vise-t-on l’élasticité dès la conception ? »L’élasticité n’est pas obligatoire pour toute application : elle apporte un bénéfice mesurable sur certains profils de charge, et reste une complexité injustifiée sur d’autres. Comprendre ces critères évite à la fois la sur-ingénierie et la dette technique liée à un démarrage stateful difficile à corriger ensuite.
Profils où l’élasticité apporte un bénéfice clair. Les applications dont la charge varie fortement dans la journée ou la semaine (avec un ratio pic/baseline supérieur à 3), les applications soumises à des pics imprévus (effet réseaux sociaux, communication mass-market, événements ponctuels), et les systèmes destinés à grossir rapidement bénéficient directement de l’élasticité, à la fois en coût et en résilience.
Profils où l’élasticité apporte peu. Une application à charge stable 24/7, peu sensible aux pics, et bien dimensionnée par rapport à sa cible utilisateur ne tirera pas grand bénéfice d’un autoscaler. Elle peut tout à fait fonctionner avec un nombre fixe d’instances, en optant pour des engagements (instances réservées, savings plans) qui réduisent la facture sans complexité opérationnelle supplémentaire.
Le coût d’une bascule rétroactive. Une application stateful avec sessions locales, fichiers stockés sur le disque local et caches in-memory peut rester ainsi pendant des années. Quand le besoin d’élasticité finit par arriver, la transition demande de retravailler les sessions, les caches, les uploads, les tâches périodiques. Cette bascule rétroactive coûte plus cher qu’un design initial qui anticipe l’élasticité, même si l’application n’en a pas immédiatement besoin.
Le bénéfice opérationnel, pas seulement financier. Au-delà du coût, un système élastique offre une marge de manœuvre face aux pics imprévus, réduit le risque de dégradation à 3 h du matin, et simplifie le travail de l’astreinte. Ces bénéfices opérationnels comptent autant que la facture, mais ne se mesurent qu’après plusieurs mois d’exploitation.
À retenir
Section intitulée « À retenir »- Scalabilité = capacité à grossir (manuelle ou auto). Élasticité = capacité à grossir ET rétrécir automatiquement.
- Scale-up (vertical) augmente la puissance d’une machine, plafonné. Scale-out (horizontal) ajoute des machines, quasi-illimité.
- L’élasticité exige 5 prérequis : stateless, idempotence, health checks profonds, métriques actionnables, démarrage rapide.
- Profils variables (ratio pic/baseline > 3) rentabilisent l’élasticité ; profils stables 24/7 préfèrent Reserved Instances.
- Cinq pièges classiques d’autoscaling : scaling lent, scale-in agressif, métriques non pertinentes, coût qui explose, flapping.
- L’élasticité apporte un bénéfice clair sur charges variables et pics imprévus ; sur charges stables 24/7, des instances fixes avec engagements restent souvent plus simples.