Serveur dédié ou serverless : le vrai coût, au-delà de la facture

La question mal posée

On me demande régulièrement : « serverless ou serveur dédié ? ». La réponse honnête, c'est que la question suppose un site web, alors qu'il faut d'abord savoir ce que votre site fait. Un site vitrine qui change une fois par mois et un espace client avec des comptes ne donnent pas du tout les mêmes réponses.

Ce qui suit est ce que je constate en pratique, après avoir maintenu des sites sur les deux modèles.

Le serveur classique

Une machine que vous payez, que vous administrez. Vous choisissez la configuration, donc vous choisissez la puissance et le prix. En échange, tout ce qui n'est pas le site relève de vous : le système d'exploitation et ses mises à jour de sécurité, la configuration PHP ou Node, le renouvellement des certificats, la surveillance, les sauvegardes.

C'est une bonne réponse quand vous savez faire, ou quand vous avez quelqu'un sous la main qui sait. La courbe est mauvaise quand personne n'a le temps : la maintenance d'un serveur n'est pas une tâche, c'est une charge récurrente. Et c'est exactement le piège des mutualisés, où l'inattention d'un tiers vous affecte aussi.

Le serverless

L'idée tient en une phrase : au lieu d'entretenir une machine, on utilise des services gérés. Cloudflare Workers exécute votre code au plus près des visiteurs, D1 fournit une base SQLite gérée, R2 stocke les fichiers. Vous ne gérez plus de système d'exploitation, plus de PHP à mettre à jour, plus de bande passante qui s'arrondit.

La facturation suit l'usage, ce qui rend le modèle très lisible pour une petite structure : si le site ne sert pas, il ne coûte presque rien. Brixio a constaté 60 à 70 % de réduction de facture sur des sites comparables après passage à Workers et D1. Ça reste un chiffre lié à leur usage, mais l'ordre de grandeur se retrouve souvent.

→ Vous hésitez entre les deux ? Envoyez-moi ce que fait votre site aujourd'hui, et je vous dirai franchement quel modèle colle — y compris si la réponse est de ne rien changer.

Ce que vous perdez

Il serait malhonnête de ne présenter que les avantages. Le serverless a un coût : la portabilité. Un code écrit pour Workers s'appuie sur les API de la plateforme ; le migrer ailleurs demande du travail. Sur un hébergement mutualisé classique, votre site reste déplaçable.

Vient ensuite les volumes de requêtes : pour un trafic important et régulier, les frais peuvent dépasser ceux d'un serveur bien dimensionné. Il y a aussi les limites d'exécution, à connaître pour les traitements longs comme l'envoi d'e-mails en lots.

Enfin, la courbe d'apprentissage. Un moteur PHP, on le branche et ça marche. Une plateforme edge demande un autre mode de pensée, et une maintenance des compétences. C'est un vrai coût, rarement chiffré.

Ma règle en pratique

Si personne dans l'entreprise ne sait mettre à jour un serveur, le serverless n'est pas un luxe, c'est de l'hygiène. Si vous avez une équipe technique qui gère déjà l'infrastructure, et que votre site est stable, le serveur dédié reste souvent plus économique et vous donne plus de contrôle.

Je ne vends pas une migration parce qu'elle est élégante. Je la vends quand elle répond à un problème constaté : lenteur, attack surface, facture qui grimpe, ou quelqu'un qui passe ses soirées à maintenir une machine.

→ Décrivez-moi votre hébergement actuel et ce que vous Soupçonz comme problème. Je vous donne un avis technical et honnête, même si la réponse est « gardez ce que vous avez ».