Hébergement cloud ou hébergement web : comment faire son choix ?

La plupart des entreprises qui comparent l'hébergement cloud à l'hébergement web traditionnel sont déjà hébergées quelque part et se demandent si le changement vaut le coup, malgré les perturbations que ça peut entraîner. Ce guide compare les deux solutions en termes de gestion du trafic, de disponibilité, de responsabilité en matière de sécurité et de coût sur trois ans ; il explique en détail ce qu'implique concrètement une migration et te donne des arguments pour rester où tu es quand c'est la meilleure solution.

En bref : avec l'hébergement traditionnel, ton site est hébergé sur une seule machine. L'hébergement cloud le répartit sur un cluster. Le cluster gère mieux les pics de trafic et les pannes matérielles. La machine unique est plus simple, moins chère dans les formules d'entrée de gamme, et tout à fait suffisante pour un grand nombre de sites. Le choix qui te convient dépend du coût que représente pour toi une heure d'indisponibilité et de l'irrégularité de ton trafic.

L'hébergement cloud, c'est différent de l'hébergement web ?

On te présentera souvent ces deux concepts comme des opposés. Mais ce n'est pas le cas. L'hébergement dans le cloud est un type d'hébergement web, tout comme un VPS est un type d'hébergement web. Personne ne se demande s'il veut une berline ou une voiture.

En fait, la comparaison dont les gens parlent, c'est celle entre l'hébergement sur une seule machine et l'hébergement sur un cluster de machines. C'est une vraie différence qui a des conséquences concrètes ; c'est pourquoi, dans la suite de ce guide, on utilise le terme « hébergement traditionnel » pour les modèles à machine unique et « hébergement cloud » pour ceux en cluster.

Si tu veux qu'on t'explique l'architecture sous-jacente en soi, y compris la différence entre le cloud public et le cloud privé, commence par découvrir ce qu'est l'hébergement cloud et comment ça marche. Ce guide part de ces bases et se concentre sur la prise de décision.

Qu'est-ce qu'un hébergement web classique ?

Cette rubrique regroupe trois modèles. Ils se distinguent par le niveau de puissance de la machine proposée, et non par la présence ou non de la virtualisation, puisque deux des trois modèles en bénéficient.

L'hébergement mutualisé héberge plusieurs sites web sur un seul serveur physique, en puisant dans un pool commun de ressources (processeur, mémoire et disque). Ces ressources ne te sont pas réservées, c'est pourquoi un site voisin soumis à une forte charge peut ralentir le tien. Pour un site statique de présentation, un portfolio ou un blog peu fréquenté, ce compromis est généralement acceptable et le prix en tient compte.

Hébergement VPS divise un serveur physique en instances virtuelles isolées grâce à un hyperviseur, chacune disposant de sa propre part réservée de processeur, de mémoire et de stockage, ainsi que d'un accès root. Les performances sont plus prévisibles qu'avec l'hébergement mutualisé, car les ressources qui te sont allouées t'appartiennent. La limite, c'est la machine physique sous-jacente : tu peux aller jusqu'aux limites de ce serveur, mais pas au-delà.

Le VPS offre un choix de gestion qui a plus d'importance que la plupart des acheteurs ne le pensent. Un VPS géré comprend un panneau de contrôle, et c'est le fournisseur qui s'occupe des mises à jour du système d'exploitation et de la sécurité. Un VPS non géré te confie l'ensemble de la pile. Même infrastructure, répartition des tâches différente. Notre guide comparatif entre l'hébergement VPS géré et non géré explique où tracer la ligne de démarcation pour différentes équipes.

Les serveurs dédiés te donnent accès à une machine physique complète : processeurs professionnels, mémoire ECC, stockage RAID, et contrôle total jusqu’aux paramètres du BIOS et du noyau. Rien n’est partagé et rien n’est abstrait. Ça garantit des performances constantes, mais ça te rend aussi responsable d’une machine qui ne dispose d’aucune sauvegarde automatique en cas de panne matérielle.

En quoi l'hébergement cloud est-il différent ?

L'hébergement cloud fait tourner tes machines virtuelles sur un ensemble de serveurs physiques plutôt que sur un seul. Les différences concrètes découlent de ce simple changement d'architecture.

Lorsqu'un nœud tombe en panne, la plateforme peut déplacer ton instance ou en lancer une nouvelle ailleurs dans le cluster, au lieu de te laisser hors ligne en attendant l'intervention d'un technicien. Quand tu as besoin de plus de mémoire, la capacité est déjà disponible dans le pool ; il suffit donc d'une simple action depuis la console pour l'ajouter, sans avoir à commander de matériel. Lorsque le trafic arrive de manière irrégulière, la charge est répartie entre les nœuds au lieu de se concentrer sur un seul.

Mieux vaut vérifier plutôt que de partir d'une hypothèse : toutes les offres vendues sous l'appellation « hébergement cloud » n'incluent pas forcément une fonctionnalité de basculement en cluster. Les serveurs virtuels à nœud unique sont souvent commercialisés sous cette même appellation. Demande explicitement ce qu'il advient de ta charge de travail en cas de panne de l'hôte physique sur lequel elle s'exécute.

Quelles sont les différences entre l'hébergement cloud et l'hébergement traditionnel ?

	Hébergement classique	Hébergement en nuage
Architecture	Une machine physique	Pool de machines en cluster
Augmenter la capacité	Changement de matériel ou migration	Action sur console, en minutes
Panne matérielle	Indisponibilité jusqu'à la réparation ou la remise en service	La charge de travail est déplacée ou redémarrée ailleurs
Pics de trafic	Limité par le plafond de cette machine	Réparti dans tout l'amas
Modèle de coûts	Forfait mensuel	Tarification au volume ou forfait dans le cadre des formules gérées
Couverture géographique	Un seul centre de données	Plusieurs régions disponibles
Le plus adapté	Des charges de travail stables et prévisibles	Des charges de travail irrégulières ou en augmentation

Lequel gère le mieux les pics de trafic ?

L'hébergement cloud, et c'est justement au moment où ça coûte le plus cher que l'écart est le plus grand.

Sur une seule machine, ta limite est fixée dès le jour de l'achat. Une campagne qui marche mieux que prévu, le lancement d'un produit, une publication qui fait le buzz : tout ça se heurte à un mur que tu ne peux pas surmonter pendant que le trafic afflue. En général, ça ne se termine pas par un crash. Ça se traduit plutôt par des temps de réponse qui passent de 200 millisecondes à quatre secondes, une hausse des abandons de panier, et personne ne se rend compte de ce qui s'est passé avant de consulter les statistiques le lendemain matin.

Une infrastructure en cluster gère ça différemment. La capacité est déjà disponible dans le pool avant même que tu en aies besoin, la charge est répartie entre les nœuds, et l'ajout de ressources pendant un événement est une réalité, pas juste une théorie.

L'argument en faveur de l'hébergement traditionnel est clair : si ton trafic est quasi stable, cet avantage ne te sert pas à grand-chose. L'élasticité, c'est une assurance, et une assurance dont tu ne te sers jamais, c'est juste un coût.

Qu'est-ce qui reste en ligne quand le matériel tombe en panne ?

Les disques durs tombent en panne. Les blocs d'alimentation tombent en panne. C'est monnaie courante, pas une exception, et la différence entre les deux modèles, c'est ce qui se passe ensuite.

L'hébergement traditionnel assure la fiabilité grâce à la redondance au sein d'une même machine : des matrices RAID qui protègent le stockage, ainsi que des alimentations électriques et des liaisons réseau redondantes au sein du centre de données. Ça permet de faire face à la défaillance d'un composant. En revanche, ça ne couvre pas la panne de la machine elle-même, et c'est à toi de configurer et de gérer le basculement vers un deuxième serveur, si tant est que tu le configures.

Les plateformes cloud intègrent la bascule de secours dans leur architecture. Lorsqu'un nœud tombe en panne, le plan de contrôle réorganise la charge de travail sans que personne ait besoin de créer un ticket.

Une petite précision sur une idée reçue : la haute disponibilité, ce n'est pas une sauvegarde. Le basculement te permet de rester en ligne en cas de panne matérielle. Ça ne va pas réparer un déploiement raté, une table de base de données supprimée ou un fichier compromis. Pour ça, il faut de vraies sauvegardes, avec leur propre politique de conservation et leur propre espace de stockage, bien à part de l'infrastructure qu'elles protègent. Les équipes qui considèrent le clustering comme un substitut aux sauvegardes découvrent la différence au pire moment possible.

Qui est responsable de la sécurité sur chacun d'entre eux ?

C'est là que ces deux modèles sont le plus souvent mal expliqués, même par les prestataires.

Avec l'hébergement classique, les responsabilités sont réparties en fonction de la formule choisie. En hébergement mutualisé, le fournisseur s'occupe de presque tout, et c'est en partie pour ça que tu paies. Sur un VPS non géré ou un serveur dédié que tu gères toi-même, c'est à toi de t'occuper des mises à jour du système d'exploitation, des règles de pare-feu, du contrôle d'accès et de la gestion des intrusions.

L'hébergement cloud fonctionne selon un modèle de responsabilité partagée, et cette répartition est souvent mal comprise. Le fournisseur assure la sécurité de l'infrastructure, du matériel et de l'hyperviseur. C'est à toi de t'occuper de la sécurité du système d'exploitation, des applications, des données et des accès. L'infrastructure cloud n'applique pas les correctifs à ton système d'exploitation à ta place. L'application automatisée des correctifs est un service géré, vendu séparément ou inclus dans une offre de gestion, et ne fait pas partie intégrante de l'architecture cloud.

C'est justement cette distinction qui explique en grande partie pourquoi les équipes en pleine croissance finissent par opter pour une infrastructure gérée. Les tâches liées à la sécurité ne disparaissent pas quand tu passes au cloud. Elles sont simplement transférées à celui ou celle que tu choisis pour s'en charger.

Comment se comparent les coûts sur trois ans ?

Avec l'hébergement traditionnel, on te facture un forfait mensuel fixe. Tu connais le montant, et tu le paies que tu utilises ou non la capacité prévue. On a souvent tendance à surdimensionner les ressources, car les équipes prévoient une charge de pointe qui n'arrive que deux fois par an.

L'hébergement cloud est généralement facturé à l'utilisation : la puissance de calcul, le stockage et le transfert de données sont facturés séparément et évoluent indépendamment les uns des autres. Le coût d'entrée est plus bas, c'est pourquoi c'est l'option par défaut pour les nouveaux projets. Le transfert de données est l'élément qui surprend le plus souvent les gens, car c'est le plus difficile à estimer avant que le trafic de production ne soit effectif.

Il y a un troisième modèle à connaître : la tarification forfaitaire pour l'infrastructure cloud. Les formules de cloud privé géré regroupent l'infrastructure, un volume de transfert défini et l'assistance en un seul montant mensuel, ce qui te permet de payer moins pendant les mois calmes, tout en ayant une facture prévisible.

Pour une analyse complète des coûts, avec notamment des données d'enquête sur les dépenses imprévues liées au cloud et le seuil d'utilisation à partir duquel la tarification forfaitaire devient plus avantageuse, consulte notre comparatif entre les serveurs cloud, les serveurs dédiés et le cloud privé géré.

Quelle place occupe le cloud privé géré entre les deux ?

Les deux modèles ci-dessus t'obligent à faire un choix que beaucoup d'entreprises ne veulent pas faire. L'hébergement traditionnel te fournit du matériel que personne d'autre ne touche et te demande de le gérer toi-même. L'hébergement cloud t'offre de la flexibilité et te place sur une infrastructure partagée avec une facture qui varie.

Le cloud privé géré existe justement parce qu’on peut éviter ce compromis. Il utilise les mécanismes du cloud, comme la virtualisation, la mise en commun des ressources et l’approvisionnement à la demande, sur du matériel réservé à un seul client et géré par l’équipe technique du fournisseur.

Ce que ça change concrètement :

• Ta charge de travail s'exécute sur du matériel qu'aucun autre client ne partage, donc les conflits d'accès provenant de l'extérieur de ton organisation ne sont pas un problème.
• La taille des machines virtuelles s'adapte sans qu'il soit nécessaire de commander du matériel ; l'augmentation de la capacité est donc un changement planifié plutôt qu'un projet de migration.
• Les correctifs, la surveillance, les sauvegardes et la gestion des incidents relèvent de la responsabilité du fournisseur ; par conséquent, les responsabilités en matière de sécurité décrites ci-dessus ne reviennent pas automatiquement à ton équipe.
• Le tarif est un montant mensuel fixe qui couvre l'infrastructure, le volume de transfert et l'assistance.

InMotion Cloud utilise ce modèle sur du matériel qu'InMotion possède et gère, avec un ingénieur expérimenté qui s'occupe directement de ta demande dès le premier contact, plutôt qu'une file d'attente de tickets de première ligne.

Que se passe-t-il concrètement quand tu passes à l'hébergement cloud ?

C'est la partie que la plupart des articles comparatifs négligent, et c'est souvent ce qui fait pencher la balance.

Une migration se déroule en quatre phases, et le risque se concentre sur l'une d'entre elles.

Préparation. Fais l'inventaire de tout ce qui tourne sur le serveur actuel : le site, les tâches cron, les webhooks, la messagerie, les certificats SSL et toutes les intégrations qui pointent vers ton adresse IP. Une tâche cron oubliée, c'est la surprise classique après une migration.

La mise en place du DNS. C'est là que tout se joue en matière de temps d'indisponibilité. Les résolveurs DNS mettent tes enregistrements en cache pendant toute la durée indiquée par le TTL ; ainsi, un TTL de 24 heures signifie que certains visiteurs continueront à se connecter à l'ancien serveur pendant une journée entière après que tu aies effectué la modification. La solution, c’est de réduire le TTL à l’avance, et il faut le faire suffisamment tôt pour que les anciennes valeurs mises en cache expirent en premier. La documentation DNSCloudflare recommande de réduire les TTL au moins 24 à 48 heures à l’avance, en choisissant idéalement la valeur la plus longue que tu as actuellement. Notre guide de migration DNS propose un calendrier par étapes qui réduit progressivement les TTL au cours de la semaine précédant la bascule.

Basculement. Copie les données en deux étapes : un transfert en masse à l'avance, puis une synchronisation delta au moment du basculement. Laisse l'ancien serveur allumé et ne touche à rien. Modifie l'enregistrement A. Surveille le trafic.

Vérification et retour en arrière. Teste tout ce qui pourrait poser problème en coulisses : le panier, la connexion, les téléchargements de fichiers, l'envoi d'e-mails, les tâches planifiées. Comme l'ancien serveur est toujours en ligne et que le TTL est encore faible, le retour en arrière se fait par une simple modification du DNS, sans avoir à lancer d'opération de récupération.

Deux remarques sur la portée de l'opération. Ne déplace pas les serveurs de noms et l'hébergement en même temps ; ils ont des comportements de mise en cache différents, et dépanner l'un pendant que l'autre est en cours de migration, c'est se compliquer la vie inutilement. Et si la messagerie se trouve sur le même serveur, fais-le séparément, car les systèmes de messagerie gèrent la mise en cache et les tentatives de reconnexion d'une manière moins tolérante que le trafic web.

InMotion inclut l'assistance à la migration dans ses offres, au lieu de la proposer comme un service professionnel facturé en supplément, et les forfaits InMotion Cloud comprennent une aide à la migration pour les équipes venant d'AWS, d'Azure, de Google Cloud, de VMware ou d'environnements sur site.

Quand vaut-il mieux s'en tenir à l'hébergement classique ?

Parfois, la bonne réponse, c'est que tu as déjà l'hébergement qu'il te faut.

• Ton trafic stagne vraiment. L'élasticité que tu n'utilises jamais, c'est une fonctionnalité pour laquelle tu paies sans en profiter.
• Ce site est purement informatif. Un site de présentation, un portfolio ou le site d'une entreprise locale avec un formulaire de contact n'a pas besoin d'une infrastructure en cluster.
• Les temps d'arrêt ne te coûtent pas grand-chose. Multiplie une heure d'arrêt par son coût réel. Si ce chiffre est faible, l'intérêt de la redondance est proportionnellement faible.
• Un seul serveur dédié suffit déjà à gérer la charge de travail. Les applications stables et à fort taux d'utilisation fonctionnent souvent plus efficacement et à moindre coût sur du matériel dédié que sur une configuration cloud équivalente.
• Pour l'instant, tu n'es pas en mesure de faire cette migration. Une migration mal menée coûte plus cher que le problème qu'elle était censée résoudre. Attendre le bon moment, c'est une décision tout à fait légitime.

Quel type d'hébergement convient le mieux à ton entreprise ?

L'hébergement traditionnel convient aux petites entreprises dont les besoins sont prévisibles, aux sites statiques et d'information, ainsi qu'aux charges de travail stables et à forte utilisation qui tiennent facilement sur une seule machine.

L'hébergement cloud est idéal pour les boutiques en ligne où la disponibilité se traduit directement par du chiffre d'affaires, les applications soumises à des pics de trafic irréguliers ou saisonniers, les équipes qui ont besoin de créer et de supprimer des environnements à la volée, ainsi que les audiences réparties dans différentes régions où la proximité des serveurs influe sur le temps de réponse. InMotion exploite des centres de données en Virginie, en Californie et à Amsterdam.

Le cloud privé géré, c'est la solution idéale pour les entreprises en pleine croissance qui veulent du matériel dédié et une facture prévisible sans avoir à embaucher d'administrateurs de serveurs, pour les équipes qui ont dépassé les capacités d'un serveur dédié et qui recherchent de la flexibilité sans perdre en isolation, et pour les organisations qui quittent un hyperscaler parce que la facture n'est plus prévisible.

Prendre la décision

Deux questions permettent de trancher plus vite qu'un comparatif des fonctionnalités.

Combien te coûte une heure d'indisponibilité ? Ce chiffre détermine le niveau de redondance qu'il vaut la peine d'acheter. À quel point ton trafic est-il irrégulier ? Ça détermine le niveau d'élasticité qu'il vaut la peine d'acheter. Si les deux réponses sont faibles, l'hébergement traditionnel fait son boulot et changer de prestataire serait une dépense sans retour sur investissement.

Si ces deux réponses sont pertinentes, la question suivante est de savoir qui gère l'infrastructure. L'hébergement cloud transfère le problème du matériel à ton fournisseur, mais te laisse en charge du système d'exploitation, de la sécurité et de la surveillance.

Si tu veux du matériel dédié, la flexibilité du cloud et un forfait mensuel fixe sans que personne ait à se charger de l'administration des serveurs, c'est exactement pour ça qu'InMotion Cloud a été conçu, en s'appuyant sur le matériel et le réseau qu'InMotion possède et exploite depuis 25 ans.

Tu ne sais pas trop où tu en es ? Parle-en à notre équipe et on fera le point sur ta configuration actuelle par rapport à ce dont tu as réellement besoin.

Questions fréquemment posées