Acheter un serveur, le louer ou choisir le cloud ? Décider application par application

Quatre modèles à distinguer clairement dans les devis

Acheter un serveur signifie d’abord posséder un appareil. Il peut se trouver dans votre local technique ou dans un centre de données facturant son emplacement. Électricité, pièces de rechange et cycle de vie entier restent à organiser. L’achat peut convenir à des charges stables et durables, mais immobilise du capital et exige des hypothèses réalistes sur la capacité et la durée utile.

Avec un serveur dédié loué, le prestataire fournit la machine physique. Le contrat précise le délai de remplacement des pièces défaillantes, l’assistance disponible et la gestion éventuelle du système d’exploitation. Un serveur virtuel partage au contraire une plateforme physique avec d’autres systèmes. Sa performance garantie et ses limites doivent convenir à l’application.

Le cloud peut désigner ces machines virtuelles, mais comprend aussi bases gérées, stockage objet et services applicatifs. La différence dépasse donc le paiement mensuel. Elle porte sur les travaux techniques que vous réalisez et ceux effectivement pris en charge par le service. Un terme commercial comme « géré » ne répond pas à cette question sans description concrète.

Six questions avant la première comparaison de prix

• Quel est le profil de charge ? Usage interne stable, pics saisonniers et projets temporaires nécessitent des réserves différentes.
• Où les gros volumes sont-ils produits ? Si des vidéos sont traitées chaque jour au bureau, l’accès aux ressources de calcul compte autant que leur puissance.
• Que doit-on maintenir lors d’une coupure internet ? Décrivez précisément les processus locaux essentiels.
• Qui exploite le système ? Disponibilité, remplacements et compétences font partie du choix.
• Quelles interruptions et pertes de données sont tolérables ? Cela détermine sauvegarde et restauration.
• Comment ressortir ensuite données et application ? Export, formats, identités et reconstruction doivent fonctionner ensemble.

Documentez les réponses par application. Un service de fichiers, un logiciel de gestion et un portail public ont souvent des exigences différentes. Déplacer les trois pour le même motif risque de négliger une dépendance locale ou de payer une souplesse inutilisée par un service stable.

Une matrice de décision avec de véritables contre-arguments

Ne pondérez les critères qu’après le cahier des charges. Si une machine de production doit continuer lors d’une coupure internet, c’est une contrainte impérative, pas une mauvaise note dans un classement global. Parmi les options restantes, vous pouvez arbitrer effort, coût et adaptabilité. Un classement mathématique ne doit pas masquer une inadéquation.

Trois applications, trois décisions possibles

Premier exemple : un bureau d’études traite de gros fichiers presque entièrement sur un seul site. Le test montre que leur transfert vers des services distants prend le plus de temps. Un service de fichiers local avec sauvegarde hors site restaurable indépendamment pourrait convenir. Il faut un local adapté, une maintenance et un plan de remplacement. Le choix changerait si l’équipe travaillait principalement sur plusieurs sites.

Deuxième exemple : un portail public de réservation connaît des pics irréguliers et dispose d’une petite équipe informatique. Une plateforme applicative gérée avec base de données peut prendre en charge des tâches, si le logiciel est conçu pour elle. Il faut vérifier coût par réservation, export et limites. Un serveur virtuel de taille constante fonctionnant en continu serait aussi du cloud, sans exploiter automatiquement cette possibilité.

Troisième exemple : une application interne tourne régulièrement avec un besoin bien connu. L’entreprise ne veut pas de salle serveur, mais possède un prestataire pour le système et l’application. Un serveur dédié loué ou virtuel avec des garanties adaptées peut limiter l’effort. Il reste à vérifier la restauration réelle, la connexion des salariés et le périmètre contractuel du remplacement matériel.

Qui gère mises à jour, sauvegardes et restauration ?

Pour EC2, AWS attribue notamment au client le système invité et l’application installée. Le fournisseur exploite l’infrastructure sous-jacente. Le partage change avec d’autres services. Appliquez ce principe à chaque offre et demandez de nommer le responsable à chaque couche. AWS : modèle de responsabilité partagée ↗

Une bonne fiche d’exploitation désigne un rôle responsable du matériel, du système, de la base, de l’application, des accès et de la sauvegarde. Elle couvre aussi suppléants, délais de réponse et procédures de changement. Évitez « l’hébergeur s’en charge probablement ». Ce vide apparaît sinon lorsqu’une base doit être restaurée et que chaque partie n’est responsable que d’un morceau.

Le RTO décrit la durée cible de restauration ; le RPO la perte de données tolérable exprimée en temps. Ces objectifs viennent de l’activité. La documentation AWS distingue ainsi la disponibilité des composants de la restauration d’une application complète après une panne majeure. AWS : préparer la reprise après sinistre ↗

La souplesse a une valeur ; les engagements ont des conséquences

Un environnement de test que l’on peut arrêter rapidement ne se calcule pas comme une base fonctionnant pendant des années. AWS décrit divers modèles tarifaires pour charges variables, usages courts et engagements plus longs. Un engagement peut réduire les coûts, seulement si l’utilisation promise se réalise. Une remise ne remplace pas une prévision des besoins. AWS : adapter la tarification à la charge ↗

Pour chaque option, demandez un calcul avec les mêmes volumes, durées d’utilisation, conservations et tâches d’assistance. Calculez aussi un mois de forte demande et la fin du contrat. Les systèmes possédés doivent inclure le remplacement matériel ; les services externes, l’export, les transferts et la reconstruction. Un prix d’entrée faible peut paraître différent sur la durée complète.

Démontrer la portabilité par un petit test d’export

Un bouton de téléchargement ne prouve pas qu’un changement est possible. Exportez un jeu représentatif avec la configuration nécessaire, puis importez-le dans un environnement distinct. Vérifiez relations, autorisations, pièces jointes et horodatages. Pour une application, cela comprend aussi le schéma de la base, les services requis et la correspondance des comptes.

Mesurez également la durée. Un export hypothétique de 2 TB sur une liaison réellement disponible de 100 Mbit/s demande environ 44,4 heures de transfert seul, en unités décimales. Préparation, contrôles et interruptions s’ajoutent. Cela peut convenir au déplacement d’archives, mais pas à une reprise rapide. Exportabilité et restaurabilité exigent donc des tests distincts.

Décider grâce à un pilote limité

Choisissez une application représentative et testez l’option préférée en conditions réalistes. Définissez les critères mesurables avant le pilote : réponses avec un nombre convenu d’utilisateurs, sauvegarde complète, restauration dans l’objectif et rapport mensuel de coûts compréhensible. Définissez également le retour arrière avant de déplacer la production.

Après le test, consignez le modèle choisi, les responsabilités acceptées, les hypothèses de coût, les limites admises et la prochaine revue dans un court document. La meilleure architecture est celle que l’équipe peut exploiter fiablement et faire évoluer. Le modèle peut différer selon l’application, si transitions et responsabilités restent claires.