Cet article remplace assumément le classement par la méthode : vous n’y trouverez ni nom d’hébergeur, ni prix, ni palmarès. La raison est simple et vaut d’être dite d’emblée : un classement est périmé le jour de sa publication. Les offres changent, les tarifs promotionnels expirent, les capacités évoluent, et une comparaison recopiée d’un comparateur est invérifiable pour qui l’écrit comme pour qui la lit. Affirmer aujourd’hui ce que vaut une offre commerciale précise serait malhonnête de notre part — nous ne pouvons pas le vérifier au moment où vous lisez ces lignes.
Ce qui ne se périme pas, en revanche, c’est la méthode : huit critères, chacun avec la commande qui permet de le contrôler soi-même en quelques minutes, sur n’importe quelle offre, y compris celle que vous avez déjà. L’article s’appuie sur trois relevés qui montrent ce que ces vérifications évitent : un plafond de dépôt de fichier qui fait échouer un envoi de 40 Mo après 3,87 Mo transmis ; les durées réelles d’envoi d’un fichier de 250 Mo selon le débit montant ; et une chaîne de redirections qui fait passer une réponse de 128 ms à 1 087 ms.
Pourquoi un classement ne vaut rien
Trois raisons, cumulatives. La première est la volatilité : une offre d’entrée de gamme change de capacités, de version de langage et de tarif plusieurs fois par an, et la version que vous souscrivez n’est pas celle qui a été testée. La deuxième est le modèle économique des comparateurs, largement financé par l’apport d’affaires, ce qui ne rend pas leurs classements faux mais rend leur ordre non vérifiable — vous ne pouvez pas distinguer le mérite de la rémunération. La troisième est la plus décisive : un classement compare des offres sur des critères généraux alors que la bonne question est particulière. Le meilleur hébergeur pour une boutique avec des traitements longs n’est pas le meilleur pour un site vitrine, ni pour une application qui envoie des fichiers volumineux.
Il reste une chose qu’un article peut fournir honnêtement : la liste des vérifications, avec la commande associée. Vous appliquez les huit critères ci-dessous aux deux ou trois offres que vous envisagez, vous relevez les réponses dans le tableau fourni en fin d’article, et vous décidez sur vos propres mesures. C’est plus long qu’un palmarès. C’est aussi la seule méthode qui reste valable dans deux ans.
Les quatre critères qui portent sur la machine
Les quatre premiers critères décrivent ce que le serveur est et ce qu’il vous laisse faire. Chacun se relève en une commande, et le relevé prend moins de dix minutes pour l’ensemble.
Critère 1 — localisation et exploitant réel
Savoir où sont physiquement vos données et qui les exploite conditionne les questions juridiques, les délais de réseau et les recours en cas de litige. Deux commandes suffisent pour commencer, avant même de poser la question au commercial :
dig +short A votre-domaine.fr
whois 203.0.113.10 | grep -iE "country|netname|org"La première donne l’adresse du serveur, la seconde l’organisation qui détient le bloc d’adresses et son pays déclaré. Attention à deux pièges : un service de distribution de contenu en frontal masque l’origine réelle, et l’adresse d’un bloc n’est pas nécessairement l’emplacement du centre de données. C’est pourquoi ces commandes servent à préparer la question, pas à la remplacer : demandez par écrit le nom de l’exploitant et la localité du centre de données, ainsi que l’identité de la société qui répond en cas d’incident. Nous détaillons les implications de ce choix dans notre article consacré à héberger son site en France ; retenez ici qu’une réponse écrite vaut mieux qu’une mention marketing sur une page d’offre.
Critère 2 — versions des langages et rythme de mise à disposition
Un hébergement qui ne propose pas les versions maintenues du langage vous condamne à faire tourner un socle qui ne reçoit plus de correctifs de sécurité — et c’est l’une des causes directes des problèmes recensés dans notre inventaire des dix vulnérabilités les plus fréquentes. La vérification se fait en deux temps : ce qui est disponible, et à quelle vitesse les nouvelles versions arrivent.
php -v
php -i | grep -E "^(memory_limit|max_execution_time|upload_max_filesize|post_max_size)"Les valeurs retournées par la seconde commande sont plus importantes que la version elle-même : ce sont elles qui décident si vos traitements aboutissent. Demandez au support deux choses vérifiables : le délai habituel entre la sortie d’une version majeure du langage et sa mise à disposition, et la possibilité de choisir la version par site plutôt que pour tout le serveur. Un hébergeur qui ne sait pas répondre à la première question ne suit pas le calendrier de son socle.
Critère 3 — limites d’envoi de fichiers
C’est le critère le plus souvent découvert en production, et le relevé qui suit explique pourquoi il est particulièrement pénible. Sur un serveur plafonnant le dépôt à 1 Mo, l’envoi d’un fichier de 40 Mo est rejeté par une erreur 413 — mais seulement après que le client a déjà transmis 3,87 Mo. Autrement dit, le refus n’arrive pas au début : le navigateur téléverse, l’utilisateur attend, puis tout échoue. Sur une connexion lente, l’attente peut durer des minutes avant l’échec.
| Débit montant | Durée d’envoi |
|---|---|
| 1 Mb/s | 33 min |
| 8 Mb/s | 4 min 10 |
| 100 Mb/s | 20 s |
Deux conclusions. D’abord, relevez vos plafonds avant de promettre une fonction d’envoi de documents à vos utilisateurs : upload_max_filesize, post_max_size, et la limite éventuelle du serveur web en frontal, qui est souvent la plus basse et la plus oubliée. Ensuite, dimensionnez selon le débit montant de vos utilisateurs, pas selon le vôtre : une connexion domestique ou un partage de connexion mobile change complètement l’expérience, et une fonction acceptable au bureau devient inutilisable en clientèle. Le test à faire est simple : envoyez un fichier représentatif depuis une connexion représentative, chronomètre en main.
Critère 4 — sauvegardes, et surtout leur restauration
Tous les hébergeurs sauvegardent. Peu de clients ont déjà restauré. La question à poser n’est donc pas « faites-vous des sauvegardes » — la réponse est toujours oui — mais quatre questions dont les réponses se vérifient : à quelle fréquence, sur quelle profondeur d’historique, où sont stockées les copies, et surtout qui peut lancer une restauration et en combien de temps.
La seule vérification qui vaille est de restaurer réellement, sur une base jetable, en dehors de toute urgence :
mysqldump --single-transaction nom_base | gzip > test.sql.gz
mysql -e "CREATE DATABASE restauration_test"
gunzip -c test.sql.gz | mysql restauration_testPuis comparez les comptages des tables principales entre l’original et la copie. Le chronomètre pendant l’opération vous donne la seule donnée qui intéresse la direction : la durée d’indisponibilité en cas de sinistre. Une sauvegarde jamais restaurée n’est pas une protection, c’est une hypothèse — et c’est le moment de vérifier aussi si la restauration est incluse dans votre offre ou facturée en intervention, ce que la plupart des souscripteurs ignorent.
Les quatre critères qui portent sur l’exploitation
Les quatre suivants ne décrivent pas la machine mais la manière dont elle est tenue dans la durée — c’est là que se joue la différence entre deux offres au même prix affiché.
Critère 5 — certificat et renouvellement automatique
Le certificat n’est pas un critère de choix — tout le monde en fournit — mais son renouvellement en est un, parce que c’est une panne à date fixe. Vérifiez la date d’expiration et la chaîne de certification :
echo | openssl s_client -connect votre-domaine.fr:443 -servername votre-domaine.fr 2>/dev/null | openssl x509 -noout -dates -issuerTrois questions complètent le relevé : le renouvellement est-il automatique, une alerte est-elle envoyée en cas d’échec, et que se passe-t-il si le renouvellement échoue un samedi ? La troisième est la plus révélatrice : un hébergeur qui a une réponse précise a déjà connu le cas, ce qui est plutôt rassurant. Ajoutez de votre côté une surveillance indépendante avec alerte à quinze jours : elle ne coûte rien et vous rend autonome de la qualité des alertes de votre fournisseur.
Critère 6 — en-têtes de sécurité et configuration par défaut
Ce que le serveur renvoie par défaut en dit long sur le soin apporté à sa configuration :
curl -sI https://votre-domaine.fr | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer-policy|server"Aucun de ces en-têtes n’est de la responsabilité exclusive de l’hébergeur — la plupart se règlent au niveau de l’application. Ce que la commande révèle, c’est la marge de manœuvre : pouvez-vous les définir vous-même ? Un hébergement qui ne permet pas de poser vos propres en-têtes vous interdit une bonne partie des protections modernes. Regardez aussi l’en-tête Server : lorsqu’il affiche un numéro de version précis, c’est une information offerte gratuitement à quiconque cherche des cibles, et le signe d’une configuration laissée par défaut.
Critère 7 — temps de réponse, et le piège des redirections
Mesurez la réponse du serveur plutôt que de lire une promesse de disponibilité :
curl -o /dev/null -s -w "dns:%{time_namelookup} connexion:%{time_connect} tls:%{time_appconnect} premier_octet:%{time_starttransfer} total:%{time_total} redirections:%{num_redirects}\n" -L https://votre-domaine.frLe champ le plus parlant est le temps jusqu’au premier octet, qui isole le travail du serveur. Mais le dernier champ réserve les plus mauvaises surprises, et voici pourquoi. Sur un même banc, une réponse servie sans aucune redirection prend 128 ms ; la même réponse au bout d’une chaîne de huit sauts successifs prend 1 087 ms — soit 8,5 fois plus, pour un contenu identique.
| Chaîne de redirections | Temps de réponse |
|---|---|
| Aucun saut | 128 ms |
| Huit sauts successifs | 1 087 ms |
Ces chaînes se constituent toutes seules : une redirection du domaine sans préfixe vers le domaine avec préfixe, une du protocole non chiffré vers le chiffré, une d’une ancienne URL vers la nouvelle, une de la nouvelle vers une troisième après une refonte, et ainsi de suite. Chacune paraît anodine, et leur addition est visible par tous les visiteurs, sur chaque première visite. Le remède est banal : rendre chaque redirection directe vers la destination finale, plutôt qu’en cascade. Encore faut-il avoir mesuré — c’est exactement ce que fait le champ num_redirects de la commande ci-dessus.
Critère 8 — conditions de sortie
Le dernier critère est contractuel et ne se mesure pas avec une commande : que se passe-t-il le jour où vous partez ? Quatre points doivent figurer par écrit avant la souscription — la possibilité de récupérer l’intégralité des données dans un format ouvert, la durée du préavis, le traitement du reliquat d’abonnement, et la procédure de transfert du nom de domaine avec son code d’autorisation. Vérifiez également qui est titulaire du domaine dans les registres publics : si votre prestataire l’a déposé à son propre nom, votre sortie dépend de sa bonne volonté, quelle que soit la qualité de la relation aujourd’hui.
Testez enfin le support avant de signer, avec trois questions dont vous connaissez déjà les réponses grâce aux critères précédents : la version du langage disponible et le délai de mise à disposition des nouvelles, la procédure exacte de restauration d’une sauvegarde, et le comportement en cas d’échec de renouvellement du certificat. Ce que vous évaluez n’est pas seulement l’exactitude des réponses, mais le délai : une réponse précise en quelques heures avant la vente indique une organisation ; une réponse vague en trois jours avant la vente annonce ce qui vous attend après.
Mutualisé, serveur dédié virtuel, infogéré : le critère qui tranche
| Niveau | Vous maîtrisez | Vous portez | Pour qui |
|---|---|---|---|
| Mutualisé | Presque rien au-delà de l’application | Rien sur le système ; en contrepartie, les limites ne se négocient pas | Sites de présentation, petits volumes, pas de traitement long |
| Serveur dédié virtuel non infogéré | Tout : versions, limites, services, en-têtes | Mises à jour système, sécurité, sauvegardes, supervision, astreinte | Équipes disposant d’une compétence système disponible |
| Serveur infogéré | L’application et la plupart des réglages | Le contrat porte l’exploitation ; vous portez la vérification qu’il est tenu | Applications critiques sans équipe système interne |
Le critère qui tranche n’est ni le prix ni le trafic : c’est la question « qui applique les correctifs de sécurité du système, et qui se lève la nuit ? ». Sur du mutualisé, l’hébergeur. Sur un serveur non infogéré, vous — et si personne chez vous n’a ce rôle par écrit, le serveur ne sera pas mis à jour, c’est une constante. Sur de l’infogéré, le prestataire, à condition que le contrat nomme les engagements. C’est précisément ce que nous mettons par écrit dans nos prestations d’hébergement web, parce qu’un engagement qui n’est pas écrit n’existe pas au moment de l’incident.
Ce que le coût réel recouvre, selon le niveau
Nous avons dit que nous ne donnerions aucun prix, et nous nous y tenons : les grilles bougent trop vite. En revanche, la structure du coût, elle, ne bouge pas, et c’est elle qu’il faut comparer entre deux offres — sans quoi vous comparez un abonnement mensuel avec un autre abonnement mensuel qui ne couvre pas les mêmes choses.
| Poste | Mutualisé | Serveur virtuel non infogéré | Infogéré |
|---|---|---|---|
| Machine et bande passante | Dans l’abonnement | Dans l’abonnement | Dans l’abonnement |
| Mises à jour système | Dans l’abonnement | À votre charge, en temps d’équipe | Dans le contrat, à vérifier ligne par ligne |
| Sauvegardes et restauration | Souvent en option, restauration parfois facturée | À construire et à tester vous-même | Dans le contrat, avec un délai à exiger par écrit |
| Supervision et alertes | Rarement incluse | À construire | Dans le contrat |
| Intervention hors horaires | Sans objet | À votre charge, si quelqu’un est disponible | Selon l’engagement souscrit |
La bonne comparaison consiste donc à convertir les cases « à votre charge » en heures et à les valoriser à votre coût interne. Une équipe qui n’a personne pour tenir un serveur ne fait pas une économie en prenant un serveur nu : elle transfère le coût vers un poste qui n’existe pas encore, et le résultat le plus courant est un serveur non mis à jour pendant deux ans. Comptez les heures avant de comparer les abonnements.
Ce que « souveraineté » veut dire — et ne veut pas dire
Le mot est employé à tort et à travers, et il vaut mieux savoir ce qu’il recouvre. Des serveurs situés en France ne suffisent pas à garantir qu’aucune législation étrangère ne s’applique : ce qui compte est aussi la nationalité de la société exploitante et de ses maisons mères, ainsi que la localisation des sous-traitants qui ont un accès technique — supervision, sauvegardes, support de nuit. À l’inverse, une entreprise européenne peut parfaitement héberger vos données sur une infrastructure d’un tiers non européen sans le mettre en avant.
Les questions utiles sont donc au nombre de trois, et elles se posent par écrit : quelle société exploite le service et quel est son actionnariat, où se trouvent les données et les sauvegardes, et quels sous-traitants disposent d’un accès technique. Un prestataire sérieux répond ; un prestataire qui renvoie à une page commerciale n’a pas répondu. Ajoutez un critère pratique, indépendant de la souveraineté : dans quelle langue et sur quel fuseau horaire le support répond-il un dimanche matin ?
Le tableau de relevé à remplir
| Critère | Ce qu’on note | Moyen |
|---|---|---|
| Localisation et exploitant | Pays, exploitant, sous-traitants avec accès | dig, whois, puis réponse écrite du fournisseur |
| Versions et limites | Version du langage, mémoire, durée d’exécution, délai de mise à disposition | php -v et php -i |
| Envoi de fichiers | Plafonds applicatif et serveur web, durée mesurée depuis une connexion réelle | Test d’envoi chronométré |
| Sauvegardes | Fréquence, profondeur, lieu, durée de restauration mesurée, coût | Restauration réelle sur une base jetable |
| Certificat | Date d’expiration, automatisation, alerte en cas d’échec | openssl s_client + surveillance indépendante |
| En-têtes | En-têtes présents, possibilité de les définir, exposition de la version du serveur | curl -sI |
| Temps de réponse | Premier octet, nombre de redirections | curl -w |
| Sortie | Export des données, préavis, reliquat, titulaire du domaine | Conditions contractuelles + registre public |
Ce qu’il faut retenir
Un palmarès d’hébergeurs vieillit en quelques mois et ne se vérifie pas ; huit critères contrôlables à la commande restent valables pour n’importe quelle offre, y compris la vôtre aujourd’hui. Ils portent sur la localisation et l’exploitant réel, les versions et limites du langage, les plafonds d’envoi de fichiers, la restauration effective des sauvegardes, le renouvellement du certificat, les en-têtes de sécurité, le temps de réponse, et les conditions de sortie. Une heure de relevé vaut mieux qu’un comparatif recopié.
Trois mesures donnent le ton. Un plafond de dépôt à 1 Mo fait échouer un fichier de 40 Mo en erreur 413 — mais seulement après 3,87 Mo transmis, donc après une attente inutile pour l’utilisateur. Un fichier de 250 Mo demande 33 minutes à 1 Mb/s, 4 min 10 à 8 Mb/s et 20 s à 100 Mb/s : dimensionnez sur le débit montant de vos utilisateurs, pas sur le vôtre. Et une chaîne de huit redirections fait passer une réponse de 128 ms à 1 087 ms pour un contenu identique — un défaut invisible pour qui ne mesure pas le nombre de sauts.
Le critère qui tranche entre mutualisé, serveur virtuel et infogéré n’est ni le prix ni le trafic : c’est de savoir qui applique les correctifs système et qui se lève la nuit. Si la réponse n’est écrite nulle part, personne ne le fera. Testez enfin le support avant de signer avec trois questions dont vous connaissez déjà la réponse : ce que vous mesurez alors, c’est le délai et la précision — les deux seules choses que vous achetez vraiment au-delà de la machine.
