---
title: 'Mise à l''échelle verticale ou horizontale : laquelle?'
description: >-
  La mise à l'échelle verticale, c'est une machine plus grosse. L'horizontale,
  c'est plus de machines. Ce que chacune apporte vraiment, et où se situe le
  plafond.
date: '2026-09-15'
lastUpdated: '2026-09-15'
keywords:
  - mise à l'échelle verticale ou horizontale
  - ai-je besoin de mise à l'échelle horizontale
  - augmenter la taille du serveur
  - quand ajouter un deuxième serveur
  - redimensionner une VM plutôt qu'un répartiteur de charge
  - limites d'un seul serveur
type: article
author: Ross Hill
locale: fr_CA
site_name: MapleDeploy
slogan: Hébergement performant en sol canadien
organization_url: 'https://mapledeploy.ca/'
logo: 'https://mapledeploy.ca//api/logo/lockup'
creator: MapleDeploy
publisher: MapleDeploy
founding_date: '2026-01-13'
email: hello@mapledeploy.ca
geo_region: CA-QC
geo_placename: Montréal
address_country: CA
area_served: Canada
application_category: DeveloperApplication
app_url: 'https://app.mapledeploy.ca'
llms_txt: 'https://mapledeploy.ca/fr/llms.txt'
offers: >-
  Starter $45/mo, Pro $95/mo, Ultra $195/mo, Ultra 32 $395/mo, Ultra 64 $695/mo
  CAD
in_language: fr-CA
canonical_url: 'https://mapledeploy.ca/fr/blog/vertical-vs-horizontal-scaling'
---

La **mise à l'échelle verticale** consiste à faire tourner votre application sur une machine plus grosse : plus de RAM, plus de processeur, plus de disque, toujours une seule machine. La **mise à l'échelle horizontale** consiste à la faire tourner sur plusieurs machines à la fois, avec un répartiteur de charge devant et le trafic réparti entre elles. La plupart des applications n'ont jamais besoin de la seconde.

L'horizontale demande plus de travail qu'il n'y paraît, mais ce n'est pas la raison principale. Une seule machine va plus loin qu'on ne le suppose, et ce qu'on achète en passant à l'horizontale n'est qu'en partie de la capacité.

## Jusqu'où va réellement une seule machine

Le chiffre public le plus clair vient encore de Stack Overflow. Dans son [portrait de l'architecture publié en 2016](https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/), Nick Craver rapporte une seule journée de février 2016 : 209 420 973 requêtes HTTP ont atteint leur répartiteur de charge, dont 66 294 789 chargements de pages. Le tout servi par 9 serveurs web principaux.

C'est de la mise à l'échelle horizontale, donc l'exemple semble plaider pour le camp adverse. La lecture qu'en fait Craver est plus intéressante. Il écrit qu'ils n'avaient plus besoin que d'un seul serveur web, « down to *needing* only 1 web server », et qu'ils l'ont vérifié sans le vouloir à quelques reprises. Puis il pose lui-même la limite du constat : « I'm saying it works. I'm not saying it's a good idea. » Ils en ont tout de même exploité neuf, pour des raisons qu'il résume par « rolling builds, headroom, and redundancy », soit les déploiements progressifs, la marge de manœuvre et la redondance.

Cette réserve est le cœur de l'affaire. Il s'agissait de gros serveurs physiques, pas d'une VM de 4 Go, et des années d'optimisation et une couche de cache importante se trouvaient derrière ces chiffres. Votre application est peut-être plus lourde par requête. Ce qui se transpose n'est pas le nombre de requêtes. C'est qu'une équipe servant 209 millions de requêtes par jour exploitait neuf machines pour des raisons qui, de l'aveu même de Craver, tenaient surtout à autre chose qu'à la capacité.

## Ce que la mise à l'échelle horizontale apporte réellement

Trois choses, et elles n'appellent pas la même réponse.

**De la capacité au-delà du plafond d'une machine.** C'est réel, mais cela mérite d'être vérifié avec vos propres chiffres d'abord. Si votre charge soutenue dépasse vraiment la plus grosse machine que vous pouvez louer, vous n'avez pas le choix.

**La redondance.** Si l'hôte tombe, tout ce qu'il héberge tombe en même temps. Seule une deuxième machine dans un autre domaine de défaillance corrige cela, et aucune quantité de mise à l'échelle verticale ne la remplace. C'est l'argument qui tient vraiment.

**Des déploiements sans interruption de service.** Ce qu'il faut ici, ce sont plusieurs *instances*, pas plusieurs *machines*. Le [tutoriel de Kubernetes sur les mises à jour progressives](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/) l'énonce explicitement : exécuter plusieurs instances « is a requirement for performing updates without affecting application availability », soit une condition pour mettre à jour sans nuire à la disponibilité. Il parle d'instances, pas d'hôtes. Dans une grappe Kubernetes, elles sont normalement réparties sur plusieurs machines, mais la condition elle-même est satisfaite par deux conteneurs sur un seul hôte.

MapleDeploy s'appuie sur [Coolify](/fr/open-source-stack), qui fait cela sur un serveur unique. Au déploiement, il démarre le nouveau conteneur, attend que sa vérification de l'état de santé passe, et arrête seulement ensuite l'ancien. Les nouvelles applications démarrent sans vérification de l'état de santé, donc c'est une option à activer plutôt qu'un acquis, et [la documentation de Coolify](https://coolify.io/docs/knowledge-base/rolling-updates) pose une vérification configurée et réussie comme condition des mises à jour progressives. Les « déploiements sans interruption » sont donc un argument faible pour ajouter une machine. Survivre à la perte de la machine, lui, tient.

## La mise à l'échelle horizontale n'est pas un simple interrupteur

Faire tourner plus d'une instance change ce que votre application a le droit de présumer.

Les [recommandations twelve-factor sur les processus](https://12factor.net/processes) existent pour rendre la mise à l'échelle horizontale possible, et elles énoncent le plus clairement ce qu'elle exige d'entrée de jeu : « Twelve-factor processes are stateless and share-nothing », et « Sticky sessions are a violation of twelve-factor and should never be used or relied upon ». Les processus doivent donc rester sans état et ne rien partager, et les sessions rattachées à un processus précis sont à proscrire. Concrètement, l'état de session migre vers un magasin partagé, les fichiers téléversés vont vers un stockage objet plutôt que sur le disque local, les caches en mémoire cessent d'être fiables, et les tâches planifiées ont besoin d'un moyen de ne pas s'exécuter cinq fois.

Reste la base de données, qui ne se répartit généralement pas de la même façon. Ajouter des serveurs web est relativement simple. Répartir les écritures entre plusieurs nœuds de base de données est un autre projet, et la première réponse habituelle est une machine de base de données plus grosse avec des répliques en lecture plutôt qu'une grappe distribuée.

Rien de tout cela n'est une raison d'éviter la mise à l'échelle horizontale quand vous en avez besoin. C'est une raison de ne pas concevoir pour elle avant d'en avoir besoin.

## Le chemin vertical, concrètement

Voici l'échelle chez MapleDeploy, avec les paliers et les prix réels :

| Forfait | RAM | vCPU | Stockage | Prix (CAD) |
| --- | --- | --- | --- | --- |
| Starter | 4 Go | 2 | 35 Go | 45 $/mois |
| Pro | 8 Go | 4 | 70 Go | 95 $/mois |
| Ultra | 16 Go | 6 | 125 Go | 195 $/mois |
| Ultra 32 | 32 Go | 8 | 250 Go | 395 $/mois |
| Ultra 64 | 64 Go | 8 | 500 Go | 695 $/mois |

Lisez la colonne des vCPU. Les cœurs doublent de Starter à Pro, puis passent à 6, puis à 8, et s'arrêtent là. Le dernier échelon ajoute de la RAM et du disque, pas des cœurs. Si votre charge est limitée par le processeur plutôt que par la mémoire, la marge réelle de la mise à l'échelle verticale est plus étroite que l'écart de prix ne le laisse croire.

Un changement de forfait redimensionne la même VM sur place, sans en provisionner une nouvelle ni vous y migrer. Vos applications et vos données restent où elles sont. Le tableau de bord énonce le compromis avant que vous confirmiez : « Le serveur subira un bref redémarrage pendant la mise à niveau. » Ce n'est ni instantané ni sans interruption. Nous ne publions pas de durée garantie pour ce redémarrage, parce qu'elle varie selon la taille du disque.

La facturation n'est pas au prorata : l'abonnement en cours prend fin et un nouveau démarre immédiatement au nouveau prix. Le chemin ne va par ailleurs que vers le haut. Les rétrogradations ne sont pas prises en charge, donc passer à un forfait inférieur suppose de créer un nouveau serveur et d'y migrer vos données. Augmentez quand les données le justifient, pas par anticipation.

Ces données se trouvent dans le tableau de bord, qui affiche l'usage du processeur, de la mémoire et du disque par serveur, et vous avertit quand une ressource dépasse le seuil d'alerte. Les forfaits Starter et Pro incluent un essai gratuit de 30 jours, ce qui permet de prendre la première décision de dimensionnement avec votre charge réelle. Tous les détails sont dans la [section tarification](/fr/#pricing).

## Où se situe réellement le plafond

64 Go de RAM et 8 vCPU, c'est le sommet de cette échelle. C'est une limite réelle, pas une limite souple.

Si vos besoins la dépassent, un même compte peut exploiter plusieurs serveurs, facturés séparément. Nos serveurs se trouvent tous dans la même installation torontoise, donc un deuxième serveur MapleDeploy apporte de la capacité, pas le domaine de défaillance distinct qu'exige l'argument de redondance plus haut. Écrivez-nous et nous vous dirons honnêtement si nous convenons.

Les signaux d'un vrai besoin d'horizontale sont précis :

- Votre engagement de disponibilité doit survivre à la perte d'un hôte, et une brève interruption pendant un redémarrage ou un redimensionnement n'est pas acceptable pour quelqu'un à qui vous l'avez promis.
- La charge soutenue de processeur ou de mémoire approche le haut de l'échelle, plutôt que des pointes qu'une machine plus grosse absorberait.
- Vous devez servir des utilisateurs depuis plus d'une région géographique.
- Qu'un déploiement raté ou un processus qui s'emballe fasse tout tomber d'un coup est devenu un risque inacceptable plutôt qu'un désagrément.

Sur le premier point, nous publions une [cible de disponibilité mensuelle de 99,9 % assortie de crédits de service](/fr/legal/sla), soit environ 44 minutes par mois. Si votre propre engagement est plus serré, ou s'il doit survivre à la perte pure et simple d'un hôte, une seule VM n'est pas la bonne architecture.

Si rien de tout cela n'est vrai aujourd'hui, la machine que vous occupez n'est pas ce qui limite votre produit. Regrouper vos projets sur un seul serveur et le dimensionner correctement est généralement un meilleur usage d'un après-midi, et [héberger plusieurs projets sur un seul serveur](/fr/blog/run-side-projects-one-server) explique comment dimensionner pour le total.

## La décision que vous pouvez reporter

La mise à l'échelle verticale, c'est un changement de forfait et un redémarrage. L'horizontale, c'est une architecture. La première se décide en un après-midi, quand les graphiques vous le disent. La seconde se décide une fois, puis vous vivez dedans.

Le compromis pratique : gardez l'état de session hors de la mémoire des processus, gardez les téléversements hors du système de fichiers local, traitez le disque local comme un espace temporaire. Cela ne coûte presque rien tant que vous êtes sur un seul serveur, et c'est l'essentiel du travail si un deuxième devient nécessaire.

{% cta-section title="Commencez sur un serveur, agrandissez quand les graphiques le disent" %}
Des VM dédiées à Toronto, de 4 Go à 64 Go. Essai gratuit de 30 jours sur Starter et Pro.
{% /cta-section %}