Hébergement d'un site B2B : ce qu'il décide vraiment

Un hébergement décide de deux choses, et de deux seulement : le temps de réponse du serveur et la disponibilité. Tout le reste de la vitesse perçue se joue dans la page, pas sur le serveur.

Cette délimitation vaut d’être posée, parce qu’elle contredit la façon dont l’hébergement est vendu et la façon dont il est accusé. Un site lent à cause de ses images ne guérira pas en changeant d’hébergeur. En revanche, un serveur qui répond en deux secondes plombe tout ce qui vient après, quelle que soit la qualité du site.

Les deux sujets se mesurent, avec des seuils publiés. Ce qui relève de la page est traité séparément dans la vitesse d’un site, ce qui compte.

La seule métrique qui dépend vraiment de l’hébergeur

Cette métrique porte un nom peu engageant, le temps de réponse au premier octet, et elle mesure exactement une chose : le délai entre le moment où le navigateur demande la page et le moment où le serveur commence à répondre.

web.dev, la ressource technique publiée par Google, donne des seuils explicites.

Deux précisions rendent cette métrique utile plutôt qu’anecdotique.

Elle précède tout le reste. La documentation indique que ce temps de réponse « précède les métriques centrées sur l’utilisateur comme le First Contentful Paint et le Largest Contentful Paint ». Autrement dit, chaque milliseconde perdue ici est perdue définitivement : elle s’ajoute à tout ce que fera ensuite le navigateur. Un serveur qui répond en 1,5 seconde vous impose de tenir le reste du chargement en une seconde pour rester dans les clous du LCP, ce qui n’est pas réaliste.

Ce n’est pas un signal Web essentiel en soi

Le temps de réponse ne figure pas parmi les Core Web Vitals et n’est donc pas mesurée comme telle. Elle conditionne simplement ceux qui le sont. C’est pourquoi elle n’apparaît pas dans les discussions habituelles sur la vitesse, alors qu’elle est le seul chiffre que votre hébergeur peut réellement faire bouger.

Ce qu’il faut en faire. Mesurez-le sur vos pages réelles, pas sur la page d’accueil seule, et à plusieurs moments de la journée. Un temps de réponse qui se dégrade aux heures ouvrées signale une mutualisation trop chargée, ce qui est le défaut le plus courant des offres d’entrée de gamme.

Un point de méthode qui évite les fausses conclusions : ce temps dépend aussi de votre site, pas seulement du serveur. Un site qui interroge sa base de données quinze fois avant de produire la première ligne de code sera lent sur n’importe quel hébergement. Avant de changer d’offre, vérifiez que le problème ne vient pas de ce que le serveur doit faire.

La disponibilité, et ce que Google fait quand le site tombe

La disponibilité est le second sujet réellement imputable à l’hébergement, et celui dont les conséquences sont les plus mal connues.

Quand votre site renvoie une erreur serveur, la documentation de Google décrit une réaction en deux temps.

D’abord, le ralentissement. « Les erreurs serveur 5xx et 429 conduisent les robots de Google à ralentir temporairement leur exploration. » Et cette réduction est proportionnelle : « la diminution du taux d’exploration est proportionnelle au nombre d’adresses individuelles qui renvoient une erreur serveur ».

Ensuite, le retrait. La documentation sur la réduction du taux d’exploration est plus précise sur les durées. Elle déconseille de servir ces codes « pendant une longue période, c’est-à-dire au-delà d’un à deux jours », et avertit que « si Googlebot observe ces codes de statut sur la même adresse pendant plusieurs jours, l’adresse peut être retirée de l’index de Google ».

L’ordre de grandeur est donc clair, et il rassure autant qu’il alerte.

Une panne d’une heure n’a pas de conséquence durable sur votre référencement. Elle vous coûte les visiteurs de cette heure, ce qui est déjà un coût, mais l’index n’en garde pas trace.

Une panne de plusieurs jours en a. Et le retour n’est pas immédiat : une adresse retirée doit être réexplorée puis réindexée, ce qui prend le temps que Google décidera d’y consacrer, sur un site dont il vient de réduire le taux d’exploration.

Le serveur influence aussi ce que Google explore

Un troisième effet, moins connu que les deux premiers, relie directement la qualité de votre hébergement à ce que Google voit de votre site.

La documentation sur le budget d’exploration décrit un ajustement automatique fondé sur la santé du serveur : « si le site répond de manière constante et que ses temps de réponse, y compris la latence et le temps de réponse au premier octet, restent stables ou s’améliorent, la limite augmente, ce qui signifie que davantage de connexions peuvent être utilisées pour l’exploration ». Et plus simplement : « si Google peut charger et afficher vos pages plus rapidement, nous pourrons peut-être lire davantage de contenu de votre site ».

Le temps de réponse mesuré plus haut n’affecte donc pas seulement vos visiteurs, il conditionne le débit auquel Google explore votre site.

Une nuance d’honnêteté s’impose immédiatement, et elle est dans la même documentation. Ce sujet ne concerne pas la plupart des PME. Google écrit : « si votre site n’a pas un grand nombre de pages qui changent rapidement, ou si vos pages semblent être explorées le jour même de leur publication, vous n’avez pas besoin de lire ce guide ». Pour un site B2B de quelques dizaines ou centaines de pages, le budget d’exploration n’est pas un problème, et le vendre comme tel relève de l’argument commercial.

Retenez-en donc l’ordre de priorité plutôt que le sujet lui-même : un serveur lent dégrade d’abord l’expérience de vos visiteurs, et accessoirement le débit d’exploration. La première raison suffit à justifier la correction.

Quel code renvoyer pendant une maintenance ?

Le détail paraît technique, il ne l’est pas tant que cela, et il est régulièrement manqué lors des refontes.

Quand vous coupez volontairement le site pour une intervention, la page affichée doit renvoyer un code 503, qui signifie service temporairement indisponible. C’est ce code qui indique aux moteurs que la situation est passagère et qu’il faut repasser plus tard.

Deux erreurs courantes produisent des dégâts disproportionnés.

Afficher une page « site en maintenance » qui renvoie un code 200. Pour Google, cette page devient alors le contenu normal de l’adresse. Si l’opération dure et que plusieurs pages affichent la même chose, vous lui apprenez que votre site s’est transformé en une collection de pages identiques et vides.

Renvoyer un 404. Vous signalez que la page n’existe pas, ce qui est faux et ce qui n’est pas le message à envoyer.

Le 503 reste à réserver aux durées courtes, pour la raison exposée plus haut : au-delà d’un à deux jours, le message cesse d’être compris comme temporaire.

Faut-il un serveur en France pour être bien référencé ?

La question revient systématiquement, et la réponse mérite d’être rendue avec sa nuance plutôt que tranchée dans un sens ou dans l’autre.

La documentation de Google sur les sites multirégionaux écrit : « l’emplacement du serveur est souvent physiquement proche de vos utilisateurs et peut constituer un signal sur l’audience visée par votre site. Certains sites utilisent des réseaux de diffusion de contenu répartis ou sont hébergés dans un pays disposant d’une meilleure infrastructure, ce n’est donc pas un signal définitif ».

Ce qu’il faut en retenir, sans surinterpréter dans un sens ni dans l’autre.

Ce n’est pas un critère décisif de référencement. Les signaux qui pèsent sont le domaine national, la langue, les adresses et numéros locaux affichés sur les pages, et les liens venus de sites locaux.

Cela reste un critère de performance. Un serveur physiquement éloigné de vos visiteurs ajoute du délai réseau à chaque requête, ce qui se retrouve dans le temps de réponse mesuré plus haut. Pour une PME B2B dont les clients sont en France, un hébergement européen se justifie par la latence et par la simplicité juridique, pas par un gain de classement.

La question des données est distincte. L’emplacement des serveurs relève aussi de vos obligations en matière de données personnelles, sujet abordé dans mentions légales, CGV et cookies. Ce n’est pas un sujet de référencement, c’est un sujet de conformité, et il ne se traite pas avec les mêmes arguments.

Mutualisé, VPS ou infogéré : que choisir ?

Les offres se comparent habituellement sur des caractéristiques techniques qui ne prédisent presque rien de votre expérience. Le critère qui décide est ailleurs, et il est humain.

Qui intervient quand le site tombe un dimanche soir.

Cette question tranche mieux que toutes les autres, parce qu’elle rend visible la différence réelle entre les formules.

Le mutualisé. Votre site partage un serveur avec d’autres. L’hébergeur gère la machine, les mises à jour système et la supervision. Vous ne pouvez presque rien régler, mais vous n’avez presque rien à gérer. Le défaut classique est la variabilité : un voisin qui consomme beaucoup dégrade votre temps de réponse, ce que révèle une mesure aux heures ouvrées.

Le serveur dédié ou virtuel non infogéré

Vous disposez de la machine, et vous en êtes responsable, mises à jour de sécurité comprises. C’est un choix pertinent si une personne compétente et disponible existe, chez vous ou chez un prestataire lié par un contrat. C’est un piège si cette personne est un ancien stagiaire ou un ami développeur qui rendait service.

L’infogéré. Quelqu’un est payé pour surveiller et intervenir. C’est la formule qui correspond à la situation de la plupart des PME B2B sans compétence technique interne, et son coût s’apprécie au regard de ce que représente une journée d’indisponibilité.

Le point aveugle, dans les trois cas : l’hébergement n’est pas l’entretien du site. Un hébergeur maintient la machine, pas votre gestionnaire de contenu, ni vos extensions, ni votre code. La distinction est développée dans maintenance d’un site, ce que couvre vraiment un contrat, et c’est l’un des écarts les plus fréquents entre ce qu’une entreprise croit avoir souscrit et ce dont elle dispose réellement.

Les sauvegardes, et la question que personne ne pose

Presque toutes les offres annoncent des sauvegardes. Cette ligne rassure et ne prouve rien, parce que l’existence d’une sauvegarde ne dit rien de votre capacité à revenir en arrière.

Trois questions valent mieux que la mention « sauvegardes incluses ».

Sur combien de jours pouvez-vous remonter ? Une sauvegarde de la veille ne vous protège pas d’un problème apparu il y a une semaine et découvert aujourd’hui, ce qui est le scénario le plus fréquent lorsqu’un contenu a été écrasé.

Qui déclenche la restauration, et en combien de temps ? Une restauration accessible depuis votre espace client en quelques minutes n’a rien à voir avec une restauration obtenue par un ticket traité sous trois jours ouvrés, alors même que les deux figurent sous le mot « sauvegardes ».

Les sauvegardes sont-elles ailleurs que sur le serveur sauvegardé ? Une copie stockée sur la machine qu’elle est censée protéger ne couvre pas les incidents qui touchent la machine.

Et une quatrième, qui les résume : avez-vous déjà restauré une fois, pour voir ? Un test de restauration sur un environnement séparé prend une demi-journée et transforme une promesse contractuelle en fait vérifié. C’est le contrôle le plus négligé de tout le sujet.

Que vaut un taux de disponibilité en heures de panne ?

Les offres annoncent des taux qui se ressemblent tous, et l’écart entre deux chiffres presque identiques est considérable. La conversion en heures de panne annuelles rend la comparaison lisible, et elle ne demande qu’une multiplication.

Un taux de 99 %, qui paraît excellent formulé ainsi, autorise donc plus de trois jours d’indisponibilité par an. Placés au mauvais moment, c’est-à-dire consécutivement, ces trois jours suffisent à faire sortir des adresses de l’index, comme vu plus haut.

Trois précisions changent la lecture de ces chiffres.

Le taux annoncé n’est pas toujours un engagement

Une valeur affichée en argument commercial n’a pas la même portée qu’un engagement contractuel assorti d’une compensation. Lisez ce que dit le contrat, pas la page de vente.

Les exclusions font le vrai taux. Les maintenances planifiées sont presque toujours exclues du calcul. Un hébergeur peut donc afficher 99,99 % et couper le service plusieurs heures par trimestre sans que cela compte.

La compensation n’est pas une réparation. Elle prend généralement la forme d’un avoir proportionnel à la durée de la panne, soit quelques euros. Elle ne couvre pas ce que la panne vous a coûté. Le taux sert à choisir, pas à se rassurer.

Le certificat, et la panne la plus évitable

Un certificat de sécurité a une date d’expiration, et son expiration produit l’un des incidents les plus violents qu’un site puisse connaître : le navigateur n’affiche pas votre site dégradé, il affiche un écran d’avertissement de sécurité que la plupart des visiteurs ne franchissent pas.

C’est une panne totale, et elle est entièrement évitable.

Le renouvellement est automatique dans la plupart des offres modernes, et c’est précisément ce qui la rend traître : personne ne surveille un mécanisme réputé automatique. Le renouvellement échoue pourtant régulièrement, à la faveur d’un changement de configuration, d’une redirection ajoutée, ou d’un domaine dont la vérification ne passe plus.

Les sous-domaines sont le point faible. Un certificat couvre un ensemble de noms précis. Un sous-domaine ajouté après coup, pour un espace client ou une documentation, sort parfois de cette couverture sans que personne ne s’en aperçoive avant qu’un visiteur ne le signale.

Ce qu’il faut faire. Deux choses, et elles prennent cinq minutes. Vérifier la date d’expiration du certificat de votre domaine principal et de chaque sous-domaine actif. Et s’assurer que l’alerte d’échec de renouvellement part vers une adresse que quelqu’un lit, ce qui rejoint exactement le problème des alertes de renouvellement de domaine.

Trois points que la plupart des contrats ne règlent pas

Qui est responsable, exactement. C’est un triangle, et chacun de ses côtés suppose que l’autre s’en occupe. Un contrat d’hébergement mutualisé ne garantit généralement pas le renouvellement comme une obligation de résultat. Une agence ne le couvre que si son contrat de maintenance le nomme, ce qui est rare. Et l’entreprise reste responsable de la sécurité des données qu’elle collecte, quelle que soit la répartition des tâches. Posez la question par écrit avant de signer, et surtout vérifiez à quelle adresse part l’alerte d’échec : le point aveugle classique est la boîte du prestataire précédent, ou un espace client auquel personne chez vous n’a accès.

La durée de vie des certificats se réduit par paliers. L’instance qui réunit les autorités de certification et les éditeurs de navigateurs a acté une trajectoire de réduction : la durée maximale passe de 398 jours à 200 jours, puis à 100, puis à 47 jours à l’horizon 2029. La conséquence est organisationnelle plutôt que technique. Tout renouvellement encore manuel deviendra intenable, et la seule question utile à poser à votre prestataire aujourd’hui est de savoir si votre chaîne est automatisée de bout en bout, alerte comprise.

Le certificat prouve le domaine, et rien d’autre. C’est le malentendu le plus répandu. Un certificat de validation de domaine s’obtient gratuitement, en quelques minutes, sans jamais déclarer qui l’on est : c’est la raison pour laquelle les sites frauduleux en possèdent tous un. Le cadenas atteste que vous êtes bien sur le domaine affiché, il ne dit rien de l’entreprise derrière. Ce qui rassure réellement un visiteur professionnel se trouve ailleurs, dans vos mentions légales et votre identifiabilité, sujet traité dans mentions légales, CGV et cookies.

Les questions à poser avant de signer

Ces questions tiennent en peu de lignes et elles éliminent l’essentiel des mauvaises surprises.

Sur la performance. Quel temps de réponse constaté sur une installation comparable à la mienne, aux heures ouvrées ? Les ressources sont-elles garanties ou partagées ?

Sur la disponibilité. Quel taux d’engagement, et surtout que recouvre-t-il en heures de panne annuelles ? Quelles exclusions, notamment pour les maintenances planifiées ? Quelle compensation, et sous quelle forme ?

Sur l’intervention. Quels horaires de support réels, quel délai de première réponse, en français ou non, par quel canal ?

Sur la réversibilité. Comment récupère-t-on l’intégralité du site et de la base de données pour partir ailleurs ? En combien de temps, et avec quelle assistance ? Un hébergeur dont la sortie est laborieuse est un hébergeur qu’on subit longtemps après avoir décidé de le quitter.

Sur la conformité. Où sont physiquement les serveurs et les sauvegardes ? Qui figure comme hébergeur dans vos mentions légales, information à mettre à jour le jour d’un changement, ce qui est régulièrement oublié.

Par où continuer, selon votre situation

Votre site est lent et vous ne savez pas pourquoi. Mesurez d’abord le temps de réponse du serveur. S’il est bon, le problème est dans la page : la vitesse d’un site, ce qui compte.

Vous voulez savoir ce qui limite votre site en général. L’hébergement n’est qu’une pièce : ce qui décide de la performance d’un site.

Vous confondez hébergement et entretien. C’est fréquent et coûteux : maintenance d’un site, ce que couvre vraiment un contrat.

Vous changez d’hébergeur. Si les adresses ne changent pas, ce n’est pas une migration au sens du référencement, mais les précautions restent utiles : migrer un site sans perdre son référencement.

Vous montez un projet. L’hébergement se choisit après la technologie, elle-même choisie sur qui maintiendra : WordPress, Webflow, Astro ou Framer, et cahier des charges de site web.

Vous gérez aussi votre nom de domaine. Les deux se confondent souvent chez le même prestataire, avec les mêmes angles morts : nom de domaine, choisir, garder et en changer.

En bref

• L’hébergement décide de deux choses : le temps de réponse du serveur et la disponibilité. Le reste de la vitesse se joue dans la page.
• Le temps de réponse a des seuils publiés : bon à 800 millisecondes ou moins, mauvais au-delà de 1 800. Il précède le LCP, donc chaque milliseconde perdue l’est définitivement.
• Une panne d’une heure ne laisse pas de trace dans l’index. Plusieurs jours, si : Google déconseille de servir ces codes au-delà d’un à deux jours et prévient que l’adresse peut être retirée.
• Le crawl ralentit proportionnellement au nombre d’adresses en erreur, ce qui rallonge d’autant le retour à la normale.
• Pour une maintenance planifiée, renvoyez un 503, jamais une page d’erreur en code 200 ni un 404.
• Le serveur en France n’est pas un critère de référencement décisif. Google écrit que l’emplacement du serveur n’est pas un signal définitif. C’est en revanche un critère de latence et de conformité.
• Le vrai critère de choix est humain : qui intervient quand le site tombe un dimanche soir.
• Une sauvegarde ne vaut que par sa restauration. Testez-la une fois, sur un environnement séparé.

Si vous hésitez entre changer d’hébergeur et corriger votre site, la mesure du temps de réponse tranche en dix minutes. Parlons de votre projet, ou découvrez notre approche de la création de site B2B.