Hébergement & infrastructure

Un hébergement choisi pour de mauvaises raisons

La plupart des hébergements que j’audite n’ont jamais été choisis : ils ont été hérités. Une agence a pris l’offre la moins chère chez son partenaire habituel, un développeur a lancé le site sur le mutualisé qu’il utilisait déjà pour ses propres projets, ou quelqu’un a coché « recommandé » sur une page de vente sans regarder le trafic réel du site. Ça tourne, jusqu’au jour où ça ne tourne plus : pic de trafic qui fait tomber le site, sauvegarde qu’on découvre corrompue le jour où on en a besoin, migration ratée qui laisse le site inaccessible pendant six heures un lundi matin.

Le problème n’est presque jamais technique au sens noble du terme. C’est un problème de dimensionnement et de suivi : personne ne s’est demandé si l’infrastructure correspondait au trafic réel, et personne ne vérifie qu’elle continue de correspondre six mois plus tard. Un e-commerce qui double son trafic en décembre et reste sur la même configuration qu’en janvier, un site vitrine sur un VPS surdimensionné qui coûte trois fois le prix d’un hébergement mutualisé pour le même résultat, une base de données jamais sauvegardée hors du serveur qui l’héberge : ce sont des choix par défaut, pas des choix réfléchis.

Mon travail sur ce pôle consiste à remplacer ces choix par défaut par une décision argumentée, puis à s’assurer que l’infrastructure reste sous contrôle dans la durée — ce qui suppose du conseil, éventuellement une migration, et de l’exploitation continue.

Conseil, migration, exploitation : les trois briques

Je découpe volontairement la prestation en trois briques indépendantes, détaillées chacune sur sa propre page, parce qu’un client n’a pas toujours besoin des trois. Certains veulent juste un avis sur leur configuration actuelle sans rien changer. D’autres savent déjà où ils veulent aller et ont besoin d’un bras technique pour migrer sans casse. D’autres encore veulent déléguer la surveillance une fois que tout est en place.

Cloudflare et le CDN : sécuriser sans complexifier

Une bonne partie des problèmes de disponibilité et de sécurité que je vois ne se règlent pas en changeant d’hébergeur, mais en ajoutant une couche devant : un CDN qui met le site en cache au plus près du visiteur, et un pare-feu applicatif qui filtre le trafic malveillant avant qu’il n’atteigne le serveur. Cloudflare est l’outil que j’utilise le plus souvent pour ça, parce qu’il couvre à la fois la performance et la sécurité avec une offre gratuite déjà solide pour la majorité des sites vitrines et e-commerce.

Concrètement, ça veut dire des pages statiques servies en quelques millisecondes sans solliciter le serveur d’origine, un filtrage des attaques par déni de service basiques, et des règles de pare-feu qui bloquent les tentatives d’intrusion automatisées avant qu’elles ne touchent le CMS. C’est un chantier séparé, détaillé sur la page Cloudflare & CDN, mais je le mentionne ici parce qu’il fait partie intégrante de toute réflexion sérieuse sur l’hébergement : un serveur bien dimensionné mais exposé directement à internet reste vulnérable.

Supervision et sauvegardes : ce qui se passe après la mise en ligne

Un site qui fonctionne le jour de sa mise en ligne ne dit rien de ce qui se passera six mois plus tard. Les certificats expirent, les extensions accumulent des failles non corrigées, le trafic évolue, et les sauvegardes automatiques qu’on n’a jamais testées se révèlent parfois inutilisables au moment où on en a réellement besoin. C’est la partie la moins visible du travail, et c’est aussi celle que la plupart des hébergeurs ne font pas vraiment, malgré ce qu’annonce leur offre « sauvegarde incluse ».

Sur ce volet, détaillé sur la page supervision & sauvegardes, je mets en place une surveillance de disponibilité qui m’alerte avant que vous ne receviez un appel client mécontent, et des sauvegardes stockées hors du serveur d’origine, avec un test de restauration réel — pas juste une vérification que le fichier existe.

Les cas où je vous le déconseille

Si votre trafic justifie une infrastructure distribuée avec équilibrage de charge sur plusieurs régions, une équipe SRE d’astreinte 24/7 et des runbooks d’incident formalisés, vous avez besoin d’une équipe DevOps interne ou d’une société spécialisée en infrastructure à grande échelle, pas d’un développeur freelance qui intervient en régie. Ce n’est pas mon terrain, et je vous le dirai dès l’audit plutôt que de vous facturer du temps sur un sujet qui dépasse ce que je peux garantir seul.

De la même façon, si vous avez déjà une personne compétente en interne qui gère l’hébergement correctement — sauvegardes testées, supervision en place, veille de sécurité suivie — un audit externe n’apportera pas grand-chose de plus que ce que cette personne sait déjà. Et si votre site fait quelques dizaines de visites par mois sans enjeu commercial derrière, la meilleure décision est souvent de rester sur un mutualisé simple et de ne pas dépenser de budget sur une infrastructure que rien ne justifie.

Là où j’apporte réellement de la valeur, c’est sur la zone intermédiaire : les sites et applications avec un trafic réel et des enjeux business, mais sans équipe technique dédiée pour s’occuper de l’infrastructure au quotidien.

Combien coûte un accompagnement hébergement

Le conseil ponctuel et la migration se facturent en régie ou au forfait selon la complexité — un audit d’une configuration WordPress mutualisée n’a rien à voir avec la migration d’une application Next.js avec base de données et API séparées. L’exploitation continue, elle, fonctionne en abonnement mensuel : supervision, sauvegardes vérifiées et suivi de sécurité, dans le même esprit que la maintenance d’un site.

Un audit initial permet toujours de savoir précisément ce dont votre infrastructure a besoin avant d’engager quoi que ce soit sur la durée. C’est souvent la première étape la plus rentable : elle évite de payer pour une surveillance inutile ou, à l’inverse, de découvrir un trou dans les sauvegardes après coup.

Ce qui change concrètement pour vous

Au quotidien, un hébergement suivi correctement se traduit par peu de choses visibles — c’est justement le but. Pas d’appel client un dimanche parce que le site est tombé. Pas de mauvaise surprise à la facturation parce qu’un VPS surdimensionné a été payé pendant deux ans sans qu’on s’en aperçoive. Pas de panique le jour où un plugin compromis ouvre une brèche, parce qu’un pare-feu applicatif et une sauvegarde restaurable existent déjà.

Je travaille aussi bien sur des sites WordPress ou PrestaShop hébergés en mutualisé ou en VPS que sur des applications plus complexes avec API séparée et base de données dédiée, comme celles que je développe par ailleurs. La logique reste la même : dimensionner selon le trafic réel, documenter les décisions, et vérifier régulièrement que l’infrastructure correspond toujours à l’usage qui en est fait.