Cloud ou serveur dédié : comment nous choisissons

Le cloud est devenu la réponse par défaut, au point qu’on ne pose plus la question. C’est dommage, parce que pour une application métier ordinaire, il coûte souvent trois à cinq fois plus cher qu’une alternative parfaitement adaptée.

Voici comment nous tranchons, avec les critères qui décident réellement.

Ce que le cloud apporte vraiment

Trois choses, et il faut les avoir en tête pour savoir si on en a besoin.

L’élasticité. Payer pour ce qu’on consomme, absorber un pic sans rien préparer. C’est l’argument fondateur, et il n’a de valeur que si la charge varie fortement — une billetterie d’événement, un service saisonnier, une application grand public.

Une application métier utilisée par deux cents personnes du lundi au vendredi n’a pas de pic. Sa charge est la plus prévisible qui soit. L’élasticité, ici, ne sert à rien et se paie quand même.

Les services managés. Base de données sauvegardée, supervisée et mise à jour sans qu’on s’en occupe. C’est un gain réel, surtout sans équipe d’exploitation. C’est aussi ce qui représente l’essentiel du surcoût.

La redondance géographique. Continuer de fonctionner malgré la panne d’un centre de données. Nécessaire quand l’indisponibilité coûte immédiatement de l’argent ; superflu quand une interruption de deux heures est acceptable — ce qui est le cas de beaucoup d’applications internes.

Ce que le serveur dédié apporte

Un coût prévisible et bas. Une machine capable de faire tourner confortablement une application métier et sa base coûte quelques dizaines d’euros par mois. L’équivalent en services managés se compte en centaines.

Une facture sans surprise. Le cloud facture le trafic sortant, les requêtes, le stockage, les sauvegardes. Une erreur de configuration ou un pic inattendu produit une facture qu’on découvre après coup. Un serveur dédié coûte le même prix chaque mois, quoi qu’il arrive.

La simplicité. Une machine, un pare-feu, une procédure de déploiement. Un développeur peut tenir tout le modèle mental en tête, ce qui n’est pas vrai d’une architecture cloud composée de douze services interconnectés.

Ce que le serveur dédié coûte

Il faut être honnête sur le revers, parce qu’il est réel.

Quelqu’un doit s’en occuper. Mises à jour de sécurité, surveillance, sauvegardes vérifiées, certificats. Comptez quelques heures par mois — nulles si personne ne les fait, et l’on découvre alors le problème lors du premier incident.

La panne matérielle existe. Un disque lâche, une machine ne redémarre pas. Sans plan de reprise testé, l’interruption se compte en heures. Ce risque se traite — sauvegardes externes, procédure de reconstruction, éventuellement une machine de secours — mais il faut le traiter explicitement.

La montée en charge demande une action. Doubler les ressources suppose une intervention et parfois une interruption. Sur une charge prévisible, ce n’est pas un problème ; sur une croissance rapide, c’est une contrainte.

Notre grille

Critère	Serveur dédié	Cloud
Charge prévisible	Oui	Indifférent
Charge très variable	Non	Oui
Budget serré	Oui	Non
Aucune équipe d’exploitation	Non	Oui
Interruption de 2 h acceptable	Oui	Indifférent
Redondance géographique requise	Non	Oui
Contrainte de localisation des données	Selon l’hébergeur	Selon la région

Deux lignes décident presque toujours : qui exploite, et combien coûte une heure d’indisponibilité. Le reste est secondaire.

Photo : domaine public (CC0).

La solution intermédiaire, souvent la bonne

Ce que nous recommandons le plus souvent n’est ni l’un ni l’autre en pur.

Un serveur dédié ou un VPS pour l’application, chez un hébergeur européen, avec un hébergement managé : l’hébergeur assure la disponibilité matérielle et les sauvegardes de base, nous assurons l’application et sa supervision.

On garde le coût maîtrisé et la simplicité, on transfère le risque matériel, et on évite la dépendance à des services propriétaires qui rendent toute migration ultérieure coûteuse.

Photo : domaine public (CC0).

La question de la sortie

C’est le point que je pousse le plus dans les arbitrages, et celui qu’on regarde le moins au moment de décider.

Le sujet n’est pas idéologique : il s’agit de savoir combien coûterait un changement d’hébergement si le besoin s’en présentait — hausse tarifaire, exigence contractuelle d’un client, évolution réglementaire.

La réponse dépend beaucoup moins du fournisseur que de ce qu’on utilise chez lui.

Des machines, du stockage, une base de données standard : la sortie est un projet de quelques semaines. Ces briques existent partout, sous la même forme.

Des services propriétaires enchaînés — file de messages, fonctions événementielles, authentification, base non standard : la sortie devient une réécriture. Ce n’est pas une raison de s’en priver, c’est une raison de le savoir avant plutôt qu’après.

La règle que j’applique : accepter volontiers un service propriétaire pour ce qui n’est pas critique, et rester sur des briques standard pour ce qui porte les données. C’est ce qui permet de bénéficier du confort sans se retrouver captif de son propre système.

Ce qu’il faut vérifier avant de signer, quelle que soit l’option

Quatre points, valables aussi bien pour un hébergeur classique que pour un grand fournisseur.

Où sont physiquement les données, et sous quelle juridiction. Cette question est contractuelle, pas technique, et elle devient bloquante sur les marchés publics et le secteur de la santé.

Ce que couvre exactement l’engagement de disponibilité. Souvent, l’infrastructure seulement, sans votre application. Et la compensation prévue est presque toujours symbolique par rapport au coût réel d’une interruption.

Qui restaure, et en combien de temps. Une sauvegarde dont personne n’a jamais testé la restauration n’est pas une sauvegarde. Cette vérification doit être faite au moins une fois par an, en conditions réelles.

Comment on récupère ses données si l’on part, dans quel format et à quel coût. Les frais de sortie de données existent chez plusieurs fournisseurs, et ils surprennent au mauvais moment.

Le coût humain, rarement chiffré

Les comparaisons s’arrêtent presque toujours au tarif mensuel, alors que l’écart réel se joue ailleurs.

Un serveur dédié suppose que quelqu’un applique les mises à jour système, surveille l’espace disque, renouvelle les certificats, teste les restaurations et intervienne en cas de panne matérielle. Ce sont quelques heures par mois en régime normal, et une astreinte le reste du temps.

Sur une infrastructure managée, une partie de ce travail est incluse dans le prix. Ce n’est pas gratuit — c’est facturé dans l’abonnement, simplement de façon prévisible.

La question à se poser n’est donc pas « lequel coûte le moins cher », mais « avons-nous quelqu’un, et son remplaçant, pour tenir ce serveur ? ». Sur une petite structure, la réponse est souvent non, et elle tranche l’arbitrage à elle seule.

Le point qu’on oublie de regarder

Le coût de sortie.

Une application qui utilise dix services managés spécifiques d’un fournisseur ne se déplace plus. Le coût de sortie devient un argument de négociation à chaque renouvellement, et il est à sens unique.

Ma règle : les composants qui portent la valeur — code, données, logique — doivent rester portables. Base de données standard, stockage de fichiers accessible par un protocole courant, conteneurs. On peut utiliser un fournisseur cloud sans s’y enfermer, mais cela se décide au départ, pas au moment où l’on veut partir.