1. Partir de l’usage, jamais de la fiche technique
La question n’est pas « combien de cœurs puis-je m’offrir » mais « qu’est-ce qui va tourner là-dessus, et combien de personnes vont s’en servir en même temps ». Un bot Discord et une boutique en ligne à 500 visiteurs par jour ne se dimensionnent pas du tout pareil, même si les deux « hébergent un service ».
Prenez cinq minutes pour lister trois choses :
- Les logiciels qui devront tourner en permanence (serveur web, base de données, cache, file d’attente, service applicatif…).
- La charge attendue : visiteurs simultanés, joueurs connectés, tâches planifiées, imports nocturnes.
- La tolérance à l’indisponibilité : quelques minutes d’arrêt sont-elles acceptables, ou l’activité s’arrête-t-elle avec le serveur ?
Cette troisième réponse détermine plus votre budget que les deux premières : c’est elle qui décide de la sauvegarde, de la supervision et de l’astreinte.
2. Processeur : fréquence élevée ou nombre de cœurs ?
Les deux ne servent pas à la même chose. Un cœur rapide traite vite une tâche unique ; beaucoup de cœurs traitent en parallèle beaucoup de tâches distinctes.
- Fréquence élevée : serveurs de jeu (Minecraft en particulier), applications monothread, traitements séquentiels. Un serveur à 5 GHz sur 2 cœurs battra un 3 GHz sur 8 cœurs.
- Beaucoup de cœurs : hébergement de plusieurs sites, conteneurs, compilation, traitement d’images, bases de données sollicitées par de nombreuses requêtes simultanées.
Pour un site vitrine ou une petite application, 2 vCPU suffisent largement. Au-delà de 4 vCPU, vérifiez d’abord que votre application sait réellement les exploiter : beaucoup de logiciels saturent un seul cœur pendant que les autres restent inactifs.
3. Mémoire vive : la ressource qui fait tomber les serveurs
C’est le manque de RAM, pas le manque de CPU, qui provoque l’essentiel des pannes que nous dépannons. Quand la mémoire est saturée, le système tue des processus au hasard : votre base de données s’arrête et le site affiche une erreur 500, sans que rien n’explique clairement pourquoi.
Quelques ordres de grandeur que nous constatons en production :
| Usage | RAM confortable | Remarque |
|---|---|---|
| Bot, VPN, petit script | 2 Go | Le minimum viable |
| Site vitrine, blog | 4 Go | Avec cache activé |
| Boutique en ligne | 8 Go | Base + cache objet |
| Plusieurs applications | 16 Go | Conteneurs, préproduction |
Prévoyez toujours une marge de 25 à 30 % : un serveur qui tourne en permanence à 95 % de sa mémoire ne supportera pas la première sauvegarde ou le premier pic de trafic.
4. Stockage : la taille compte moins que la vitesse
Le NVMe est aujourd’hui la norme, et l’écart avec un disque mécanique est considérable sur les bases de données : requêtes plus rapides, sauvegardes plus courtes, redémarrages plus nets. Si un hébergeur propose encore du disque mécanique pour un serveur applicatif, passez votre chemin.
Pour la taille, comptez le système (10 à 15 Go), vos données, puis doublez pour laisser la place aux sauvegardes locales, aux journaux et aux mises à jour. Un espace disque plein est une panne, pas un avertissement.
5. Réseau, adresses IP et protection
Trois points à vérifier avant de commander :
- La bande passante : « illimité » signifie souvent « non compté mais bridé au-delà d’un certain volume ». Demandez le débit garanti, pas le débit maximal.
- La protection anti-DDoS : elle doit être incluse et permanente. Une protection qu’il faut activer pendant l’attaque arrive toujours trop tard.
- Les adresses IP : une IPv4 dédiée reste nécessaire pour un serveur de messagerie ou un certificat particulier ; vérifiez aussi la réputation de l’adresse fournie si vous comptez envoyer des e-mails.
6. Infogéré ou non infogéré ?
Un VPS non infogéré vous donne les clés et s’arrête là : mises à jour, sécurité, sauvegardes et surveillance sont à votre charge. C’est parfait pour apprendre ou pour une équipe qui a déjà les compétences.
L’infogérance a du sens dès que le serveur porte une activité qui rapporte de l’argent, ou quand personne dans l’équipe n’a le temps d’appliquer les correctifs de sécurité un vendredi soir. Le calcul est simple : comparez le coût mensuel de l’infogérance à celui d’une journée d’arrêt.
Un serveur non infogéré laissé sans mise à jour pendant six mois est, statistiquement, un serveur compromis. Si vous ne pouvez pas vous en occuper, prévoyez le budget correspondant dès le départ.
7. Les cinq erreurs que nous voyons le plus
- Surdimensionner le CPU et sous-dimensionner la RAM. C’est le contraire qu’il faut faire dans la majorité des cas.
- Oublier la sauvegarde. Un snapshot pris par l’hébergeur sur la même infrastructure n’est pas une sauvegarde externalisée.
- Ne pas surveiller. Sans supervision, vous apprenez la panne par un client.
- Choisir la localisation au hasard. Vos visiteurs sont en France : un serveur à l’autre bout du monde ajoute de la latence pour rien.
- Prendre un engagement de trois ans pour économiser 15 %. Les besoins changent, et une migration forcée coûte plus cher que l’économie réalisée.
8. Récapitulatif
Un dimensionnement raisonnable, dans l’ordre : la RAM d’abord, le stockage NVMe ensuite, le CPU en dernier — sauf pour un serveur de jeu, où la fréquence passe en tête. Ajoutez la sauvegarde dans tous les cas, et la supervision dès que le service compte pour quelqu’un d’autre que vous.
Si vous hésitez encore, notre configurateur applique exactement ce raisonnement à partir de vos besoins, et vous indique l’offre correspondante avec son prix.