Hébergement web : que vérifier avant de renouveler ou de migrer ?

Avant de renouveler ou de changer d’hébergement, réunissez trois éléments : la facture réelle de la prochaine période, la liste des dépendances du site et une méthode de restauration testée. Ils éclairent mieux votre décision qu’un tarif mensuel de lancement ou une affirmation non vérifiée selon laquelle un prestataire serait plus rapide.

Le renouvellement est un bon moment pour réexaminer votre contrat. Ce n’est pas automatiquement une raison de migrer. Une comparaison pertinente inclut le travail et les risques du changement de prestataire autant que le coût du maintien de l’hébergement actuel.

Chiffrer la période que vous allez réellement acheter

Obtenez le montant du renouvellement pour l’offre et la durée de facturation exactes. Distinguez l’équivalent mensuel annoncé de la somme totale facturée à l’avance. Notez la devise, les taxes applicables, la date de renouvellement, l’échéance de résiliation et l’éventuel réglage de renouvellement automatique.

Listez les dépendances facturées séparément : domaines, messagerie, sauvegardes, stockage, aide à la migration, services de sécurité et licences logicielles payantes. Demandez quels avantages de lancement expirent et combien coûte une restauration de sauvegarde. Une fonctionnalité figurant dans le nom d’une offre peut néanmoins être limitée ou assortie de frais facultatifs.

Comparez la même charge de travail et la même durée chez chaque prestataire. Évitez d’opposer un prix promotionnel sur trois ans à un renouvellement sur un an sans rendre la différence visible. Si les conditions manquent de clarté, obtenez une réponse écrite avant de vous appuyer sur le montant.

Votre propre temps de migration est aussi un coût. Le chevauchement des comptes, l’aide d’un spécialiste et la reconfiguration de la messagerie ou des outils de publication en sont d’autres. Une économie modeste peut rester intéressante, mais elle doit résister à ce calcul plus complet.

Cette liste ne classe pas les hébergeurs et ne présente aucun test de vitesse. Les offres publiées changent ; le prix utile est celui qui s’applique à votre formule, à votre localisation et à votre situation de renouvellement au moment de décider.

Relier les limites aux tâches de votre site

Identifiez ce qui consomme des ressources : pages d’articles, diffusion des images, recherche, tâches planifiées, sauvegardes, imports, newsletters et administration. Une publication surtout statique n’a pas les mêmes besoins qu’un CMS qui construit des pages et interroge une base de données à chaque visite.

Demandez comment le prestataire définit et applique ses limites de stockage, de trafic, de processeur, de mémoire, de processus simultanés et de nombre de fichiers. Vérifiez ce qui se passe à la limite : avertissement, frais, ralentissement ou arrêt du service. Une capacité généreuse de transfert ne supprime pas nécessairement les autres contraintes.

Contrôlez les versions logicielles nécessaires au site et la façon dont le prestataire gère les versions prises en charge et les mises à jour. Si une agence ou un développeur gère l’application, demandez-lui de confirmer sa compatibilité plutôt que de vous fier à la catégorie commerciale de l’hébergeur.

Définissez le périmètre de l’assistance. Qui analyse un déploiement raté, restaure une base de données, résout un conflit d’extensions ou intervient hors des heures ouvrées ? Renseignez-vous sur les engagements de réponse et sur la différence entre répondre à un ticket et résoudre la panne.

Si vous disposez d’un problème réel dans votre historique d’exploitation, utilisez-le. Décrivez la défaillance et demandez ce que l’offre couvrirait. N’inventez pas d’incident de test et n’annoncez pas un délai de réponse que vous n’avez pas mesuré.

Prouver que vous pouvez restaurer le site et garder le contrôle

Une sauvegarde n’est utile que si elle contient les éléments nécessaires au site et si quelqu’un sait la restaurer. Pour WordPress, la documentation officielle sur les sauvegardes distingue la base de données des fichiers ; une restauration complète nécessite généralement les deux.

Quelle que soit la plateforme, listez les éléments de récupération : contenus, médias, fichiers applicatifs ou de compilation, configuration, redirections et éventuelles bases de données séparées. Identifiez les secrets dont la récupération doit être sécurisée sans les placer dans une archive publiquement téléchargeable.

Restaurez une sauvegarde récente dans un environnement de test privé. Vérifiez un article récent, un ancien article avec images et les actions essentielles au site. Notez la date de la sauvegarde, ce qui a été restauré et ce qui manque. Un simple message confirmant la réussite d’une tâche de sauvegarde ne répond pas à ces questions.

Vérifiez aussi la propriété des comptes. La bonne personne doit contrôler l’enregistrement du domaine, le DNS, la facturation de l’hébergement et les moyens de récupération. L’organisation ou le propriétaire doit conserver l’accès lorsqu’un prestataire part. Utilisez des comptes distincts et des autorisations adaptées lorsque les services le permettent.

La routine de maintenance transforme ces contrôles en travail régulier, afin que le prochain renouvellement ne soit pas la première occasion de demander où se trouvent les sauvegardes.

Préparer la migration avant de modifier le DNS

Inventoriez tous les services associés au domaine. L’hébergement du site et la messagerie peuvent être fournis ensemble ou séparément : identifiez les enregistrements concernés avant tout remplacement. Conservez une copie de la configuration DNS actuelle et convenez de la personne qui effectuera et vérifiera les changements.

Déplacez d’abord une copie et testez-la en privé. Comparez les URL, les redirections, les images, les formulaires, la connexion, les tâches planifiées et le processus de publication. Avec un CMS, tenez compte des écritures postérieures à la copie initiale : un nouvel article ou un message de formulaire pourrait sinon être oublié.

Le manuel de migration WordPress explique que la bonne procédure dépend des éléments déplacés, notamment d’un éventuel changement d’URL. Un changement de serveur et un changement de domaine sont deux opérations différentes. N’ajoutez pas une nouvelle structure d’URL à une migration d’hébergement sans raison ni plan distincts.

Définissez le créneau d’intervention, la synchronisation finale, les vérifications et le critère de retour en arrière. Désignez une personne qui décidera si le nouvel environnement est acceptable. Ne comptez pas simplement sur l’idée que quelqu’un remarquera un problème.

Résilier après avoir pris en compte toutes les dépendances

Après le basculement, vérifiez le site en ligne à travers les parcours habituels des lecteurs et des rédacteurs. Contrôlez la destination attendue, la connexion sécurisée, la messagerie si elle est concernée et les services externes qui dépendent de l’ancien environnement. Examinez les journaux et la surveillance pour repérer des défaillances qu’une visite de l’accueil ne montrerait pas.

Maintenez l’ancien service pendant la période convenue de chevauchement et de récupération. La bonne durée dépend de la configuration et des besoins de l’activité ; il n’existe pas de jour universel de résiliation. Confirmez l’export des données nécessaires et l’accès à des sauvegardes indépendantes avant la fermeture du compte.

Si le trafic baisse après le déplacement, suivez un diagnostic structuré de baisse de trafic, en commençant par l’accès, le suivi et les changements d’URL. N’attribuez pas immédiatement la baisse aux performances de recherche du nouvel hébergeur.

Terminez par une courte transmission : qui possède chaque compte, où sont conservés les éléments de récupération, ce qui a changé et la date du prochain renouvellement. La décision d’hébergement est complète lorsque les personnes responsables peuvent exploiter et restaurer le site.