Nom de domaine, serveur web, espace de stockage, bande passante, support technique : R7 répond aux questions hébergement web que pose un site internet, du choix de l'hébergeur à la protection des données, puis détaille FTP, PHP, SQL, messagerie et CMS.
Site vitrine ou blog : un hébergement web mutualisé, géré par l'hébergeur. Boutique ou application : un serveur dédié, un VPS ou un serveur cloud, aux ressources réservées. Avant de signer : localisation des données, sauvegardes, horaires du support technique et sécurité du serveur web.
Que vérifier chez un hébergeur avant de lui confier son site ?
Un hébergeur se juge sur l'adéquation entre son offre d'hébergement web et les besoins réels du site, bien avant le nombre de gigaoctets affiché. La plupart des déceptions viennent d'un écart entre ce que le site internet demande (trafic, langage, volume de données, messagerie) et ce que le serveur fournit vraiment. Quatre questions méritent une réponse écrite de l'hébergeur avant la souscription : les besoins techniques, les ressources garanties, le lieu de stockage des données et la qualité de l'assistance technique.
Les besoins techniques du projet
Les besoins techniques d'un site web se résument à quelques éléments : le langage utilisé (PHP pour WordPress, Joomla ou Drupal, parfois Node.js ou Python pour une application), le moteur SQL (MySQL ou MariaDB le plus souvent), le nombre d'adresses e-mail à créer sur le domaine et le volume de fichiers à publier. Un site de commerce en ligne, un outil de développement interne et un blog personnel n'ont pas les mêmes besoins : le bon choix d'hébergement web part de cette différence. Un site vitrine de quelques pages web n'a besoin ni d'un accès root ni d'un serveur dédié. Une boutique en ligne qui traite des commandes la nuit, en revanche, exige des tâches planifiées, une version de PHP récente et une mémoire suffisante pour les extensions. Vérifier la liste des versions de PHP proposées évite une mauvaise surprise : au 14 octobre 2026, PHP 8.1 ne reçoit plus de correctifs de sécurité depuis fin 2025, et les branches 8.2 à 8.5 restent suivies selon le calendrier publié sur php.net. Pour un site existant, le test de compatibilité avec PHP 7 et 8 se fait avant la migration, jamais après.
Les ressources réellement garanties
Les ressources d'un hébergement web se mesurent en processeur, en mémoire vive, en espace de stockage et en bande passante. Sur une offre mutualisée, ces ressources se partagent entre un grand nombre de sites installés sur la même machine ; l'hébergeur fixe alors des limites par compte (nombre de processus, mémoire par script PHP, connexions simultanées à MySQL). La mention « illimité » désigne en pratique un usage raisonnable défini dans les conditions générales : lire cette clause dit à partir de quel volume l'hébergeur bride ou suspend un compte. L'espace de stockage compte moins qu'on ne le croit pour un site classique, qui tient souvent en quelques gigaoctets ; les copies de secours, les journaux et les boîtes mail en consomment une grande partie. Certaines offres d'hébergement web vendent des options de ressources à la carte, au mois, ce qui fournit une solution d'appoint face à un pic de trafic saisonnier sans changer de formule.
La localisation des données et le RGPD
La localisation des données d'un site hébergé engage la responsabilité de l'éditeur dès que le site collecte des informations personnelles (formulaire de contact, comptes clients, newsletter). Au sens du RGPD, l'hébergeur agit comme sous-traitant : l'article 28 du règlement impose un contrat qui précise la nature des traitements, les mesures de sécurité et le sort des données en fin de contrat. Un hébergeur sérieux publie ce document, souvent sous le nom d'accord de traitement des données. Un serveur situé dans l'Union européenne simplifie les choses ; un transfert hors de l'Union suppose un cadre juridique adapté. Pour une entreprise ou un professionnel établi en France, un datacenter situé en France ou dans un autre pays de l'Union permet de rendre cette vérification plus simple ; l'hébergeur indique en général dans ses conditions le data center qui accueille chaque serveur web. Les données de santé relèvent d'un régime à part : leur hébergement exige un prestataire certifié HDS (hébergeur de données de santé), prévu par l'article L. 1111-8 du code de la santé publique.
Le support technique et ses horaires
Le support technique d'un hébergeur se juge sur trois critères : les canaux proposés (ticket, téléphone, chat), les horaires réels et la compétence des personnes qui répondent. Un ticket ouvert le samedi soir sur une erreur 500 ne sert à rien si l'assistance ne répond que du lundi au vendredi. Avant de choisir, poser une question technique précise au service client donne une idée plus juste que n'importe quelle page commerciale : le délai de réponse et la qualité de l'explication montrent ce que vaudra l'aide le jour d'une panne. Une documentation publique, tenue à jour et datée, fait aussi partie du service, tout comme la communication de l'équipe technique pendant un incident : une page d'état publique qui annonce les maintenances vaut mieux qu'un silence de plusieurs heures.
Mutualisé, VPS, dédié ou cloud : quel type d'hébergement retenir ?
Le type d'hébergement découle du site à servir et de la part de gestion que l'on accepte de prendre en charge. Les quatre grandes familles se distinguent moins par la puissance brute que par la répartition des responsabilités entre l'hébergeur et l'utilisateur. Le tableau compare ce qui change d'une formule à l'autre ; le détail du passage d'un mutualisé à un serveur virtuel figure dans le comparatif mutualisé ou VPS.
| Formule | Ressources | Gestion du serveur | Pour quel site |
|---|---|---|---|
| Mutualisé | Partagées avec d'autres comptes, limites par compte | Assurée par l'hébergeur | Site vitrine, blog, petite association |
| VPS | Part réservée d'une machine physique | À la charge de l'utilisateur, sauf offre infogérée | Boutique moyenne, plusieurs sites, outils sur mesure |
| Serveur dédié | Machine entière pour un seul client | Administrateur système nécessaire | Fort trafic, contraintes de conformité |
| Serveur cloud | Ajustables à la demande, facturées à l'usage | Variable selon le niveau de service choisi | Trafic irrégulier, application qui doit monter en charge |
Un hébergement mutualisé reste la solution la plus courante pour les sites web de petite taille : l'hébergeur applique les correctifs du système, surveille le serveur web et fournit un panneau d'administration. Le VPS et le serveur dédié donnent un accès complet à la machine, donc la liberté d'installer n'importe quel logiciel, mais aussi la charge des mises à jour et de la sécurité informatique. Une entreprise sans service informatique interne gagne souvent à choisir une offre infogérée, où un spécialiste administre le serveur à sa place.
Un serveur cloud repose sur une technologie de virtualisation répartie entre plusieurs machines physiques. Son avantage tient à la haute disponibilité : la panne d'un équipement ne coupe pas le service, puisque la machine virtuelle redémarre ailleurs. Les offres de cloud public facturent à l'heure ou au mois, un modèle adapté aux sites web dont le trafic varie fortement, moins à un site vitrine dont la charge reste stable toute l'année.
Comment évaluer la qualité d'un hébergement déjà en place ?
La qualité d'un hébergement en service se mesure par des indicateurs objectifs, que n'importe quel éditeur de site peut relever lui-même sans outil payant. Trois mesures suffisent à repérer un hébergeur qui ne tient pas ses engagements : la disponibilité, la vitesse de chargement et le respect des sauvegardes promises.
- La disponibilité : un taux garanti de 99,9 % autorise près de 8 h 45 d'interruption par an, un taux de 99,99 % environ 53 minutes. Un service de surveillance gratuit qui interroge le site toutes les cinq minutes suffit à vérifier le chiffre réel.
- La vitesse de chargement : le temps de réponse du serveur (le délai avant le premier octet) dépend surtout de l'hébergement, alors que le poids des images et des scripts dépend du site. Un temps de réponse qui se dégrade aux heures de pointe signale un serveur mutualisé surchargé.
- Les sauvegardes : restaurer un fichier ou une table depuis une sauvegarde de l'hébergeur, une fois, à titre de test, montre si la promesse tient. Une sauvegarde jamais testée ne garantit rien.
Le taux de disponibilité affiché dans une offre d'hébergement web se traduit en durée d'interruption tolérée ; le calcul porte sur une année de 8 760 heures.
| Taux garanti | Interruption tolérée par an | Par mois, en moyenne |
|---|---|---|
| 99 % | 87 h 36 | 7 h 18 |
| 99,9 % | 8 h 46 | 44 minutes |
| 99,99 % | 53 minutes | 4 minutes 23 |
Grâce à ces mesures, un problème de lenteur ou de coupure se rattache à sa vraie cause, et la discussion avec l'hébergeur s'appuie sur des relevés datés plutôt que sur une impression.
Les moteurs de recherche tiennent compte de l'expérience des internautes, et un site lent ou souvent inaccessible perd des visiteurs avant même de perdre des positions. Quand un CMS ralentit, le diagnostic distingue ce qui relève de l'hébergeur de ce qui relève des extensions : la page sur un WordPress pas assez rapide liste les causes à examiner dans l'ordre.
Les éléments de base d'un site en ligne
Un site internet en ligne repose sur quatre éléments distincts, souvent achetés chez le même prestataire mais qui peuvent vivre séparément : le nom de domaine, la zone DNS, l'hébergement des fichiers et la messagerie. Comprendre ce découpage aide à localiser une panne et à changer de fournisseur sans tout casser. Chaque élément joue un rôle différent dans l'affichage des pages web, et une étape mal faite sur l'un d'eux suffit à couper le site ou les e-mails.
- Le nom de domaine
- L'adresse du site, louée auprès d'un registraire pour une durée renouvelable. Le titulaire du nom doit être l'éditeur du site, jamais l'agence web ou le prestataire qui l'a réservé pour lui ; un transfert de nom de domaine se fait avec un code d'autorisation fourni par le registraire actuel.
- La zone DNS
- Le tableau d'enregistrements qui indique où trouver le site (enregistrements A et AAAA), où livrer les e-mails (MX) et quels serveurs ont le droit d'envoyer au nom du domaine (SPF, DKIM, DMARC).
- L'hébergement des fichiers
- Le serveur web qui stocke les pages, les images et le code, et qui les envoie au navigateur. Les fichiers s'y déposent par FTP, SFTP ou par l'interface d'un CMS.
- La messagerie
- Les boîtes associées au domaine, consultées en IMAP ou en webmail, et le serveur SMTP qui envoie les messages. Elle peut rester chez l'hébergeur ou partir chez un service spécialisé sans toucher au site.
Le certificat SSL complète cet ensemble : il chiffre les échanges entre le navigateur et le serveur, et son absence fait afficher un avertissement à chaque internaute. La plupart des hébergeurs installent aujourd'hui un certificat SSL gratuit en quelques clics, renouvelé automatiquement.
Parcourir les réponses par rubrique
Les réponses de R7 se rangent en cinq rubriques qui suivent la vie d'un site hébergé, de la mise en ligne des fichiers à la sécurité du CMS. Chaque rubrique rassemble des pages courtes, centrées sur un seul réglage ou une seule erreur.
- Hébergement et services internet : FTP et SFTP, noms de domaine, zone DNS, sous-domaines, adresse avec ou sans www, sauvegardes.
- PHP et serveurs : versions maintenues, erreur de mémoire épuisée, fonctions désactivées par l'hébergeur, tâches cron.
- MySQL, MariaDB et requêtes SQL : connexion, export avec mysqldump, choix du moteur InnoDB, triggers, requêtes lentes ; un exemple détaillé montre comment optimiser une jointure LEFT OUTER JOIN.
- Messagerie du domaine : boîte ou redirection, ports IMAP et SMTP, enregistrements SPF, DKIM et DMARC, messages classés en spam.
- WordPress et autres CMS : mises à jour, prérequis techniques, passage en HTTPS, formulaires protégés, gestes après un piratage.
Préparer sa demande pour obtenir une réponse rapide
Une panne d'hébergement se résout plus vite quand quelques informations sont notées avant de chercher de l'aide, auprès du support de l'hébergeur comme sur R7. Le message d'erreur exact compte plus que sa description : « Allowed memory size exhausted » et « Error establishing a database connection » renvoient à deux causes sans rapport, alors que l'utilisateur les décrit souvent tous deux comme « le site ne marche plus ».
- Copier le message d'erreur tel qu'il s'affiche, avec le numéro de ligne s'il y en a un.
- Noter l'heure d'apparition et ce qui a changé juste avant : mise à jour d'une extension, nouveau certificat, modification du fichier .htaccess, changement de version de PHP.
- Ouvrir le journal d'erreurs du serveur, accessible depuis la plupart des panneaux d'administration : il donne souvent la ligne fautive.
- Relever les versions en service (PHP, MySQL ou MariaDB, CMS) et le type d'hébergement.
- Faire une sauvegarde des fichiers et des tables avant toute manipulation.
Cette dernière précaution évite de transformer un incident mineur en perte de données. Les pages du site la rappellent chaque fois qu'une manipulation peut casser un site en ligne, et elles indiquent la commande pour revenir en arrière quand elle existe.
Comment R7 construit ses réponses
Chaque page de R7 part d'une demande concrète, souvent reçue par le formulaire de contact, et y répond dans ses premières lignes avant d'entrer dans le détail. Les commandes, les enregistrements DNS et les paramètres sont donnés tels qu'on les saisit, avec les valeurs à adapter signalées. Les versions de PHP, de MySQL ou de WordPress sont datées sur chaque article, parce qu'une réponse juste en 2022 peut être fausse aujourd'hui.
Les réponses valent quel que soit l'hébergeur, et les noms de menus cités sont ceux que l'on retrouve sur la plupart des panneaux (cPanel, Plesk ou interfaces maison). Quand une manipulation diffère d'un hébergeur à l'autre, la page le dit et décrit le principe plutôt qu'un chemin de clics qui changera au prochain habillage de l'interface. Les points de sécurité (mots de passe, droits sur les fichiers, accès FTP en clair) passent toujours avant le confort.
Les étapes spécifiques à un environnement (serveur Linux, hébergement Windows, conteneur) sont séparées des étapes communes, pour que chaque lecteur retrouve ce qui s'applique à son hébergement web. L'expérience montre que la plupart des pannes de sites web viennent de trois sources : une mise à jour, un enregistrement DNS modifié, une limite de ressources atteinte. Les réponses du site partent donc de ces trois pistes avant d'explorer les cas plus rares.
Changer d'hébergeur sans coupure, sauvegardes, RGPD et support muet
Peut-on changer d'hébergeur sans coupure du site ?
Oui, à condition de préparer la migration dans le bon ordre : copier les fichiers et la base SQL chez le nouvel hébergeur, tester le site sur l'adresse temporaire fournie, abaisser la durée de vie (TTL) des enregistrements DNS quelques jours avant, puis modifier la zone. Les anciens et les nouveaux serveurs doivent rester actifs le temps de la propagation, soit en général 24 à 48 heures.
L'hébergeur fait-il les sauvegardes à ma place ?
La plupart des hébergeurs sauvegardent les comptes, mais la fréquence, la durée de conservation et le coût d'une restauration varient beaucoup. Les conditions de service le précisent. Garder une copie hors de chez l'hébergeur, exportée régulièrement, protège aussi contre la fermeture du compte ou la faillite de l'hébergeur.
Faut-il un hébergement dédié pour respecter le RGPD ?
Non, un hébergement mutualisé peut respecter le RGPD si l'hébergeur fournit un contrat de sous-traitance conforme à l'article 28 et décrit ses mesures de sécurité. Le règlement porte sur les garanties et la localisation des traitements, pas sur le fait de disposer d'une machine à soi.
Que faire quand le support ne répond pas ?
Relancer par un canal écrit qui laisse une trace (ticket ou e-mail), en citant le numéro de la demande initiale et le message d'erreur. En cas d'interruption prolongée, le contrat précise souvent une compensation liée au taux de disponibilité garanti, à réclamer par écrit.
