Choisir son hébergement web : les critères qui se vérifient

Le prix n’est pas un critère, c’est une conséquence

Un hébergement mutualisé français coûte entre trois et huit euros par mois, à peu près partout. À ce niveau de prix, ce qui distingue deux offres n’est presque jamais la quantité d’espace disque — vous n’en utiliserez jamais le dixième — mais des réglages invisibles sur la page de vente : la version du langage installée, le protocole servi, la compression, ce que la machine a le droit de faire vers l’extérieur.

La bonne nouvelle, c’est que quatre de ces critères se mesurent depuis l’extérieur, sur n’importe quel site déjà en ligne. Vous pouvez donc auditer votre hébergeur actuel — ou celui d’un concurrent, ou celui du site vitrine d’un hébergeur qui vous démarche — sans rien demander à personne. Les cinq autres ne se voient pas : il faut savoir les demander avant de signer, parce qu’on les découvre sinon en production, un dimanche.

1. La version de PHP : le critère décisif, et le plus négligé

Si vous ne deviez en retenir qu’un, c’est celui-là. PHP publie une nouvelle branche chaque automne. Chacune reçoit deux ans de support actif (corrections de bogues et de sécurité), puis deux ans de correctifs de sécurité seulement. Passé ces quatre ans, plus rien : une faille découverte sur cette branche n’est jamais corrigée, et son existence est publique.

Deux chiffres méritent d’être lus ensemble : PHP 8.1 n’est plus corrigé depuis le 31 décembre 2025, et une part considérable des hébergements mutualisés français la propose encore par défaut. Ce n’est pas de la négligence de leur part : monter la version par défaut casserait les vieux sites de leurs clients. La conséquence est simplement que c’est à vous de le faire, et que presque personne ne le fait, parce que personne ne le dit.

Comment le vérifier de l’extérieur. Beaucoup de serveurs annoncent leur version dans un en-tête HTTP. En ligne de commande :

curl -sI https://exemple.fr/ | grep -i "x-powered-by\|server"

Une réponse du type X-Powered-By: PHP/8.1.34 vous donne la réponse immédiatement. Si l’en-tête est absent, c’est bon signe pour la sécurité — il n’y a aucune raison d’annoncer sa version à qui la demande — mais cela ne vous dispense pas d’aller regarder dans votre panneau d’administration.

Comment le corriger. Sur un hébergement mutualisé sous cPanel ou Plesk, le sélecteur de version PHP est dans le panneau, et le changement prend une minute. Le risque n’est pas dans l’opération mais dans le code : une extension ou un thème ancien peut ne pas supporter la nouvelle branche. La méthode raisonnable est de monter une branche à la fois, de vérifier les pages principales et le formulaire de contact, et de revenir en arrière au moindre écran blanc — le retour est tout aussi immédiat.

Le piège que personne ne mentionne : les extensions ne suivent pas. Sur les hébergements cPanel construits sur CloudLinux — c’est-à-dire la majorité du mutualisé français — chaque version de PHP a sa propre liste d’extensions activées. Basculer de 8.1 à 8.4 sans rien faire d’autre vous donne bien PHP 8.4, mais souvent sans mbstring, sans dom, sans intl, sans gd. Nous l’avons vérifié sur notre propre hébergement : en 8.1, les dix extensions dont nous dépendons sont présentes ; en 8.3 comme en 8.4, il n’en reste que quatre par défaut. Un site qui manipule de l’accentué ou du HTML tombe alors en erreur fatale, et le message ne dit rien de la version de PHP.

D’où la règle : après avoir changé de version, retournez cocher les extensions dans le même écran, et redémarrez de la page d’accueil. C’est aussi la raison pour laquelle ce changement se fait depuis le panneau d’administration et pas en bricolant une ligne AddHandler dans un .htaccess : un nom de gestionnaire inexact n’échoue pas proprement, il fait servir vos fichiers .php en texte brut — code source, identifiants de base de données et clés d’API compris. Nous l’avons obtenu du premier coup, dans un dossier de test isolé.

Nous appliquons la règle à nous-mêmes : au moment où ces lignes sont écrites, aven-web.fr tourne sur PHP 8.1.34, c’est-à-dire sur une branche qui n’est plus corrigée depuis huit mois. C’est le réglage par défaut de l’hébergement, et nous ne l’avions pas vérifié. Les versions 8.3 et 8.4 sont bien disponibles sur cette machine ; la bascule attend seulement que les extensions soient réactivées avec elles, pour la raison expliquée ci-dessus. Un site qui prêche l’hygiène technique se doit de le dire plutôt que de l’effacer.

2. Le protocole : HTTP/1.1, HTTP/2 ou HTTP/3

En HTTP/1.1, le navigateur ouvre une connexion par fichier, et se limite à six connexions simultanées par domaine. Une page ordinaire appelle cinquante ressources : elles passent donc en file d’attente. HTTP/2 fait passer toutes ces ressources dans une seule connexion, en parallèle. HTTP/3 va plus loin en changeant de transport, ce qui aide surtout sur les réseaux mobiles instables.

Ce qui rend ce critère intéressant, c’est qu’il ne dépend pas de votre site. Il n’y a rien à réécrire, rien à optimiser : c’est un réglage de serveur. Un hébergeur qui sert encore en HTTP/1.1 en 2026 vous fait payer une lenteur que vous ne pouvez pas corriger vous-même. Pour la mesurer :

curl -s -o /dev/null -w "%{http_version}\n" https://exemple.fr/

Un détail qui piège : HTTP/2 et HTTP/3 ne se négocient qu’en HTTPS. Un site en clair reste en HTTP/1.1 quoi qu’il arrive — c’est une raison de plus de migrer, en plus de l’avertissement que Chrome affichera en octobre 2026.

3. La compression

Une page HTML est du texte, et le texte se compresse d’un facteur trois à cinq. Les trois algorithmes courants sont gzip, br (Brotli) et zstd. Le serveur annonce celui qu’il a utilisé dans l’en-tête Content-Encoding. Absence d’en-tête sur une page de plusieurs dizaines de kilo-octets : la compression est désactivée, et vous payez trois fois le temps de transfert nécessaire.

Chez la plupart des hébergeurs mutualisés, l’activation tient à quelques lignes dans le fichier .htaccess (module mod_deflate ou mod_brotli). Si le module n’est pas disponible du tout, c’est un signal sur la modernité de la plateforme, pas seulement sur cette fonction.

4. Le temps de réponse, et ce qu’il ne dit pas

Le délai avant le premier octet (TTFB) est la mesure la plus citée et la plus mal interprétée. Elle additionne trois choses : la distance réseau, la charge de la machine, et le temps que met votre code à produire la page. Un TTFB de deux secondes sur un WordPress chargé d’extensions ne dit rien de l’hébergeur.

Pour faire la part des choses, comparez le TTFB d’une page dynamique et celui d’un fichier statique du même site — une image, la feuille de style. Si le fichier statique part immédiatement et que la page met deux secondes, le problème est dans votre code. Si les deux sont lents, il est en dessous.

5 à 9. Ce qui ne se voit pas de l’extérieur

Les cinq points suivants ne se mesurent pas depuis un navigateur. Ce sont ceux qu’il faut poser en question avant de signer, parce qu’ils décident de ce que vous pourrez faire dans deux ans.

La sortie réseau. Votre serveur a-t-il le droit d’appeler une adresse extérieure ? Beaucoup d’hébergements mutualisés filtrent les connexions sortantes, parfois sans le documenter. C’est sans conséquence pour un site vitrine, et bloquant dès que vous voulez appeler une API de paiement, une passerelle d’envoi de courriels, ou simplement vérifier vos propres liens.

Les tâches planifiées. Un accès aux tâches cron transforme un hébergement en petite machine autonome : sauvegardes, envois différés, surveillance. Sans elles, tout ce qui doit se produire en votre absence n’existe pas.

Les fonctions PHP bridées. La directive disable_functions liste ce que l’hébergeur a coupé. Certains y mettent exec et ses cousines, ce qui est défendable ; d’autres y ajoutent des fonctions utilisées par des bibliothèques courantes, et vous ne le découvrez qu’à l’installation. Demandez la liste, ainsi que memory_limit et max_execution_time : un memory_limit à 128 Mo suffit à faire échouer un import de catalogue ou une génération de PDF.

Les sauvegardes. La question n’est pas « faites-vous des sauvegardes » — tout le monde répond oui — mais « puis-je en restaurer une moi-même, sans ouvrir de ticket, et quelle est la plus ancienne disponible ? ». Une sauvegarde de la veille écrasée chaque nuit ne protège pas du cas le plus fréquent : un problème introduit il y a trois semaines et remarqué aujourd’hui.

Le certificat et son renouvellement. Let’s Encrypt inclus et renouvelé automatiquement est devenu la norme ; vérifiez que c’est bien automatique, et non « gratuit, à renouveler manuellement tous les trois mois ». Un renouvellement oublié produit exactement le même effet qu’un certificat expiré : une page d’alerte à la place de votre site.

Le mythe de l’hébergement « conforme RGPD »

Une bonne partie des arguments de vente joue sur une confusion : le RGPD n’impose pas d’héberger les données personnelles en France ni dans l’Union européenne. Son chapitre V autorise les transferts hors UE à condition qu’un niveau de protection adéquat soit assuré — par une décision d’adéquation de la Commission (article 45), par des garanties appropriées comme les clauses contractuelles types (article 46), ou par les dérogations de l’article 49.

Autrement dit : un hébergement français ne vous rend pas conforme, et un hébergement hors UE ne vous rend pas fautif. Ce qui vous rend conforme, c’est de savoir quelles données vous traitez, sur quelle base légale, et de le documenter — ce que produit un registre et une politique de confidentialité honnêtes.

Il existe de vraies obligations sectorielles, et elles sont plus étroites qu’on ne le croit : l’hébergement de données de santé à caractère personnel exige un hébergeur certifié HDS, et certains marchés publics imposent une qualification SecNumCloud. Si vous n’êtes ni dans la santé ni fournisseur de l’État, ces mentions sur une page de vente ne vous concernent pas.

Cela dit, choisir un hébergeur européen a de vrais avantages : un interlocuteur dans votre fuseau horaire, un support dans votre langue, une facture en euros, un droit applicable que vous comprenez, et une analyse d’impact plus simple à écrire. Ce sont de bonnes raisons. Elles n’ont simplement rien à voir avec une obligation légale.

Ce que vous découvrirez en production

Aucun comparatif ne mentionne le comportement d’un hébergement mutualisé sous sollicitation soutenue, parce qu’il ne se mesure pas en une visite. Sur une machine partagée, des requêtes rapprochées finissent par déclencher des protections : réponses vides, erreurs 503 passagères, page intermédiaire de contrôle à la place du contenu attendu.

Nous le mesurons sur notre propre hébergement : environ un échec sur six quand nos outils écrivent plusieurs fichiers d’affilée, et des requêtes POST automatisées régulièrement interceptées par un contrôle de sécurité qu’un navigateur ordinaire franchit sans le voir. Ce n’est pas un défaut : c’est le mutualisé qui fait son travail, protéger les voisins. Mais il faut le savoir avant de bâtir dessus quelque chose qui appelle son propre serveur en rafale.

La leçon générale : le mutualisé convient parfaitement à un site qui sert des pages. Dès que votre projet émet du trafic — synchronisations, appels d’API, traitements en lot — vous êtes en dehors de ce pour quoi l’offre est conçue, quel que soit l’hébergeur.

Si vous devez changer d’hébergeur

La migration n’est pas difficile, elle est simplement pleine de petits pièges. Dans l’ordre :

• Abaissez le TTL de vos enregistrements DNS à 300 secondes au moins 48 heures avant. Sinon, une partie de vos visiteurs continuera d’atteindre l’ancien serveur pendant un jour ou deux, et vos deux bases de données divergeront.
• Montez le site sur le nouvel hébergement avant de basculer, et testez-le en forçant la résolution : curl --resolve exemple.fr:443:<nouvelle IP> https://exemple.fr/.
• Vérifiez le certificat avant la bascule, pas après. Beaucoup d’hébergeurs ne peuvent émettre le certificat qu’une fois le domaine pointé sur eux : prévoyez une courte fenêtre pendant laquelle le site répond en HTTPS avec un certificat qui n’est pas encore le bon.
• Reprenez vos redirections. Elles vivent dans .htaccess ou dans la configuration nginx, et c’est le fichier qu’on oublie le plus souvent de copier. Une redirection perdue, c’est une page qui renvoie 404 alors qu’elle était indexée.
• Passez le site au crible après la bascule : en-têtes de sécurité à remettre, compression à réactiver, version de PHP à choisir explicitement plutôt qu’à subir, contenu mixte éventuellement réintroduit par des URL absolues codées en dur.

La liste à cocher

• Quelle version de PHP, et est-elle encore corrigée ?
• Le serveur répond-il en HTTP/2 ou HTTP/3 ?
• Les réponses sont-elles compressées ?
• Le temps de réponse d’un fichier statique est-il raisonnable ?
• Les connexions sortantes sont-elles autorisées ?
• Y a-t-il des tâches planifiées ?
• Que contient disable_functions, et quels sont memory_limit et max_execution_time ?
• Puis-je restaurer seul une sauvegarde, et de quelle ancienneté ?
• Le certificat est-il renouvelé automatiquement ?

Les quatre premières questions, notre analyseur y répond pour vous : entrez l’adresse d’un site et la section « Hébergement et serveur » du rapport donne la version de PHP annoncée et son état de maintenance, le protocole négocié, la compression et le temps de réponse. Les cinq suivantes se posent à un humain — et la façon dont on vous répond en dit déjà long.