Hébergement, e-mail professionnel et délivrabilité : bien héberger son site

Qu’est-ce qu’un hébergement web, et de quoi avez-vous besoin ?

L’hébergement, c’est la location d’une place sur un serveur, un ordinateur allumé en permanence dans un centre de données, qui stocke les fichiers et la base de données de votre site et les envoie à chaque visiteur. Une offre d’hébergement comprend en général l’espace disque, une ou plusieurs bases de données, un certificat HTTPS, souvent des boîtes e-mail, et un panneau de contrôle pour gérer le tout.

L’hébergement ne remplace pas le nom de domaine : le domaine est l’adresse, l’hébergement est le terrain. Les deux peuvent être achetés chez le même fournisseur ou séparément, et le DNS relie l’un à l’autre. Tout ce qui concerne le choix et la propriété du domaine est dans le chapitre sur le nom de domaine .be.

Pour un site vitrine, les besoins sont en général modestes : quelques centaines de mégaoctets, une base de données, un trafic de quelques centaines à quelques milliers de visites par mois. Ce qui fait la différence n’est pas la puissance, mais la fiabilité, les sauvegardes et le support.

Mutualisé, VPS, cloud ou tout compris : quel type d’hébergement choisir ?

Commencez par un hébergement mutualisé, sauf raison précise d’aller plus loin. Les autres formules servent des besoins réels, mais elles demandent plus de budget ou de compétences.

Sur un mutualisé, votre site partage un serveur avec d’autres clients ; l’hébergeur s’occupe du système et de sa sécurité. Un VPS (serveur privé virtuel) vous donne une portion de serveur réservée, en général plus puissante mais à administrer vous-même, sauf formule infogérée. Le cloud facture à la consommation et convient surtout aux applications qui encaissent des pics de trafic.

Avec une plateforme tout compris, l’hébergement est inclus dans l’abonnement et vous ne gérez rien. C’est à mon avis un bon choix pour un tout petit budget ou une boutique simple sur Shopify ; en contrepartie, quitter la plateforme revient souvent à refaire le site. Le chapitre qui compare Wix, WordPress et le sur mesure détaille ces options.

Quels critères vérifier avant de choisir un hébergeur ?

Des serveurs dans l’Union européenne

Votre site traite des données personnelles : formulaire de contact, statistiques, commandes. L’hébergeur agit alors en principe comme sous-traitant au sens du RGPD, et l’article 28 impose un contrat de sous-traitance ou un autre acte juridique (souvent appelé DPA, parfois intégré aux conditions générales). Si les données sont stockées hors de l’Union (plus exactement hors de l’Espace économique européen) ou consultées depuis un pays tiers, par exemple par un support situé ailleurs, s’ajoutent les règles sur les transferts internationaux (articles 44 et suivants du RGPD) : pour les États-Unis, l’Autorité de protection des données rappelle que la décision d’adéquation ne couvre que les organisations inscrites sur la liste du Data Privacy Framework.

Le plus simple est donc de choisir un hébergeur qui garantit des serveurs dans l’Union et de le mentionner dans votre politique de confidentialité (voir les obligations légales d’un site). On trouve des hébergeurs établis en Belgique et ailleurs dans l’Union : le pays des serveurs se vérifie dans chaque offre, dans les conditions générales ou le contrat de sous-traitance.

Les autres points à contrôler

• Sauvegardes : quotidiennes, conservées au moins deux semaines, stockées hors du serveur, et restaurables par vous-même depuis le panneau de contrôle. Demandez combien coûte une restauration faite par le support.
• HTTPS gratuit et automatique : les certificats Let’s Encrypt sont gratuits et valent 90 jours par défaut ; leur durée maximale descendra à 45 jours d’ici février 2028. Leur renouvellement doit donc être automatique, sans action de votre part.
• Versions de PHP : au 30 septembre 2026, PHP 8.2 à 8.5 sont maintenus, mais PHP 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026 ; PHP 8.1 n’en reçoit plus depuis fin 2025. L’hébergeur doit proposer les versions récentes et vous laisser choisir.
• Support en français, et en néerlandais si votre équipe ou vos clients le parlent : par téléphone ou par chat, avec des horaires compatibles avec les vôtres.
• Ressources réelles : mémoire allouée à PHP, nombre de bases de données et de boîtes e-mail, limite d’e-mails envoyés par heure. Une offre « illimitée » comporte en général des limites d’usage, précisées dans les conditions d’utilisation : lisez-les.
• Prix de renouvellement : c’est lui qui compte, pas le prix d’appel.

Hébergement, domaine et maintenance forment les frais annuels d’un site, récapitulés dans le chapitre sur le prix d’un site internet. Chez moi, l’hébergement et le nom de domaine d’un site vitrine coûtent 120 € HTVA par an, en supplément de la création, et ceux d’une boutique en ligne sont compris la première année (voir mes tarifs) : posez-moi, comme à tout prestataire, les questions de cette liste avant de vous engager.

Quelle solution pour une adresse e-mail professionnelle à votre nom ?

Une adresse à votre nom de domaine (info@votre-entreprise.be) inspire en général plus confiance qu’une adresse gratuite ou liée à votre fournisseur d’accès, et elle vous suit si vous changez d’hébergeur ou de messagerie. Trois solutions coexistent :

À mon avis, dès que vous êtes plusieurs ou que l’e-mail est votre outil de travail principal, séparez la messagerie de l’hébergement du site. Vous pourrez changer d’hébergeur sans toucher à vos boîtes, et inversement.

SPF, DKIM, DMARC : comment limiter le risque que vos e-mails arrivent en indésirables ?

Les grandes messageries vérifient désormais que chaque e-mail vient bien d’un serveur autorisé par le domaine de l’expéditeur. Cette preuve repose sur trois enregistrements DNS, publiés dans la zone de votre domaine. Sans eux, vos e-mails peuvent être classés en indésirables, voire refusés, et il est plus facile d’envoyer de faux e-mails en votre nom.

Ce que Gmail, Yahoo et Outlook exigent

Depuis février 2024, Google et Yahoo imposent à tous les expéditeurs une authentification SPF ou DKIM, des enregistrements DNS direct et inverse valides pour les serveurs d’envoi et un taux de plaintes pour spam inférieur à 0,3 %. Google exige aussi une connexion chiffrée (TLS). Les gros expéditeurs, à partir d’environ 5 000 e-mails par jour vers des comptes Gmail personnels, doivent en plus publier SPF et DKIM, une politique DMARC (au moins p=none) alignée sur l’adresse d’expédition et une désinscription en un clic pour les e-mails commerciaux. Depuis novembre 2025, Gmail durcit l’application : les messages non conformes peuvent être refusés temporairement ou définitivement. Microsoft applique des règles comparables depuis mai 2025 aux domaines qui envoient plus de 5 000 e-mails par jour vers Outlook.com, Hotmail et Live.

Une PME n’atteint en général pas ces volumes avec ses e-mails courants, mais une lettre d’information peut les dépasser, et les règles de base s’appliquent à tous les expéditeurs. DNS Belgium et le Centre pour la Cybersécurité Belgique (CCB) ont d’ailleurs publié en décembre 2025 des lignes directrices de cybersécurité qui recommandent notamment ces trois protocoles.

1. Publiez SPF avec tous vos services d’envoi (messagerie, site, outil de lettre d’information) dans une seule ligne, sans dépasser 10 recherches DNS (chaque include en compte au moins une) : au-delà, la vérification SPF échoue (RFC 7208).
2. Activez DKIM dans chaque service d’envoi et publiez les clés qu’il vous donne.
3. Publiez DMARC en p=none et lisez les rapports quelques semaines pour repérer les envois oubliés.
4. Durcissez ensuite en p=quarantine, puis en p=reject quand tout est conforme.

Pour vérifier votre domaine avec un e-mail de test et corriger un contrôle en échec, voyez le chapitre pourquoi vos e-mails arrivent en spam.

Pourquoi les e-mails du formulaire de contact finissent-ils en spam ?

Une cause fréquente est la façon dont le site les envoie. Sur beaucoup de sites, le formulaire utilise la fonction mail() de PHP : le message est en général remis au logiciel d’envoi du serveur, sans authentification SMTP ; la signature DKIM dépend alors de la configuration de l’hébergeur. Trois erreurs se cumulent souvent :

• L’expéditeur est l’adresse du visiteur : le message prétend venir d’une adresse @yahoo.com mais part de votre hébergement. Le domaine du visiteur ne l’autorise pas, et sa politique DMARC peut demander le rejet. Au 30 septembre 2026, yahoo.com publie une politique de rejet, skynet.be et proximus.be une politique de quarantaine.
• Le serveur du site n’est pas dans votre SPF, même quand l’expéditeur est votre propre adresse.
• Le serveur est partagé : sa réputation dépend aussi des autres sites qu’il héberge.

La solution habituelle est un envoi SMTP authentifié : le site se connecte à une vraie boîte d’envoi (celle de votre hébergeur, de Microsoft 365, de Google Workspace ou d’un service d’e-mails transactionnels) avec des identifiants réservés à cet usage (selon le service : boîte d’envoi dédiée, mot de passe d’application, clé d’API ou connexion OAuth). Si SPF et DKIM sont configurés pour ce service, le message part alors signé DKIM, depuis un serveur autorisé par votre SPF.

• Expéditeur : une adresse de votre domaine, par exemple formulaire@votre-domaine.be.
• Adresse de réponse (« Reply-To ») : celle du visiteur, pour lui répondre d’un clic.
• Sur WordPress, une extension SMTP remplace l’envoi par défaut ; sur un site codé sur mesure, une bibliothèque comme PHPMailer ou Symfony Mailer fait de même.
• Pas d’accusé de réception qui recopie le message du visiteur : des robots peuvent s’en servir pour envoyer du spam par votre formulaire.
• Testez en envoyant le formulaire vers une adresse Gmail et une adresse Outlook, puis lisez les en-têtes : SPF, DKIM et DMARC doivent afficher « pass ».

Protégez aussi le formulaire contre les robots (champ piège, limitation du nombre d’envois) : c’est traité dans le chapitre maintenance et sécurité du site.

Comment changer d’hébergeur en limitant les coupures ?

En faisant fonctionner les deux hébergements en parallèle et en ne basculant le DNS qu’une fois le nouveau site testé. Comptez en général une à deux semaines entre la commande et la résiliation de l’ancien contrat.

1. Commandez le nouvel hébergement sans résilier l’ancien, et vérifiez la date d’échéance du contrat actuel.
2. Réduisez la durée de cache du DNS (le TTL, par exemple à 300 secondes) un ou deux jours avant la bascule, pour qu’elle soit prise en compte plus rapidement.
3. Copiez les fichiers et la base de données, puis testez le site sur l’adresse temporaire fournie par le nouvel hébergeur.
4. Recréez les boîtes e-mail et copiez les anciens messages si la messagerie déménage aussi ; prévoyez de transmettre les nouveaux mots de passe aux utilisateurs par un moyen sûr.
5. Basculez le DNS : enregistrements A et AAAA pour le site ; MX seulement si la messagerie déménage ; SPF et DKIM mis à jour si le serveur d’envoi change. Si la zone DNS est gérée chez l’ancien hébergeur, recopiez-la entièrement chez le nouveau (y compris les enregistrements TXT, DKIM et DMARC) avant de changer les serveurs de noms.
6. Vérifiez le HTTPS, les formulaires et la réception des e-mails dans les heures qui suivent.
7. Résiliez l’ancien hébergement après une à deux semaines sans problème, en gardant une dernière sauvegarde complète.