Changer d'hébergeur pour un site WordPress inquiète pour une raison simple : le dirigeant imagine une journée blanche. Le site affiche une erreur, les mails cessent d'arriver, le certificat expire au mauvais moment, et personne ne sait dire combien de temps la situation va durer. Cette crainte est légitime, parce qu'une migration mal préparée produit exactement ce résultat. Elle n'est pourtant pas une fatalité : une bascule d'hébergement se planifie, s'annonce et se vérifie, et le temps d'indisponibilité réel se réduit alors à quelques minutes, souvent à rien du tout.
Nous sommes partenaire Infomaniak, et il faut préciser tout de suite ce que cela signifie et ce que cela ne signifie pas. Le compte d'hébergement reste ouvert à votre nom, vous en détenez les identifiants, et vous pouvez nous en retirer l'accès du jour au lendemain sans que votre site s'arrête. Nous ne revendons pas d'hébergement en marque blanche et nous ne citons pas les tarifs de l'hébergeur, parce que ce ne sont pas les nôtres : vous souscrivez directement, avec votre propre moyen de paiement. Ce partenariat nous donne une connaissance précise d'une plateforme que nous administrons souvent, rien de plus. Nous maintenons également des sites chez OVH, chez Hostpoint et ailleurs, et cette diversité est assumée.
La question de la localisation des données, elle, se traite séparément. Nous la développons dans notre article sur le choix d'héberger en Suisse ou en France. Le présent article répond à une question différente : pourquoi cette plateforme revient-elle si souvent dans nos mises en ligne, et qu'est-ce qui se passe concrètement quand nous y transférons un site existant.
Les caractéristiques qui font revenir cet hébergeur dans nos projets
Le support s'exprime en français et comprend les configurations franco-suisses. Ce détail paraît secondaire jusqu'au jour où une zone DNS doit être corrigée dans l'heure. Un interlocuteur qui saisit immédiatement qu'un domaine .fr pointe vers une infrastructure genevoise et qu'une boîte professionnelle est rattachée au même compte fait gagner un temps considérable.
Le panneau d'administration reste lisible pour une personne qui n'est pas administratrice système. Nous y attachons de l'importance parce que nous refusons de créer une dépendance artificielle. Un dirigeant doit pouvoir consulter seul l'état de son certificat, retrouver une adresse de messagerie ou vérifier la date de renouvellement de son domaine, sans nous ouvrir un ticket.
Les versions de PHP proposées sont maintenues et se changent en quelques clics. Cela compte davantage qu'il n'y paraît, car un site qui tourne encore sur une version abandonnée du langage reste en ligne tout en accumulant des vulnérabilités non corrigées. Nous détaillons ce mécanisme dans l'article sur les risques d'un PHP obsolète sous WordPress.
Les sauvegardes automatiques de la plateforme fonctionnent bien et nous les activons systématiquement. Elles ne remplacent cependant pas une copie déposée hors de l'infrastructure de l'hébergeur, pour la raison évidente qu'un incident affectant le compte affecte aussi ce qu'il contient. Nous posons donc toujours une seconde sauvegarde ailleurs, comme nous l'expliquons dans notre article sur la sauvegarde WordPress hors serveur.
Enfin, la messagerie et le site cohabitent fréquemment sur le même compte. C'est pratique au quotidien et c'est un point de vigilance majeur le jour d'une migration, parce qu'une modification DNS mal cadrée coupe simultanément le site et les mails. Nous traitons ce sujet à part dans notre article sur la messagerie Infomaniak, car les besoins d'une TPE de cinq personnes et ceux d'une PME de trente salariés ne se ressemblent pas.
Choisir entre un hébergement mutualisé et un serveur dédié
Pour un site vitrine créé à partir de 900 HT, un hébergement mutualisé correctement configuré suffit largement. Une dizaine de pages, un formulaire de contact, des images converties au bon format et un cache actif ne justifient pas une machine dédiée. Payer un serveur virtuel pour ce type de site revient à louer un camion pour transporter deux cartons.
Le serveur dédié ou virtuel devient pertinent dans des cas identifiables. Une boutique en ligne avec un catalogue important et des paniers simultanés consomme des ressources que le mutualisé partage mal. Une application métier interne exige des droits que le mutualisé n'accorde pas. Un besoin de tâches planifiées précises, d'une extension système particulière ou d'un accès complet en ligne de commande pousse dans la même direction. Nous posons la question dans ce sens, en partant de l'usage, jamais en partant du produit.
Il faut aussi dire clairement ce que cette plateforme n'est pas. Elle n'est pas magiquement plus professionnelle qu'une autre, et le nom de l'hébergeur ne compense jamais un thème acheté sans support ou quarante extensions installées au fil des années. Elle constitue un interlocuteur que nos clients du Bassin Genevois identifient facilement, avec une résidence des données en Suisse quand le cahier des charges l'exige.
Le déroulé d'une migration de site sans journée blanche
Nous commençons par un audit court de l'installation existante. Il détermine si le site est sain, s'il est infecté, si le thème est encore mis à jour par son auteur, et si la base de données a grossi de façon anormale. Cet audit fait partie de la maintenance WordPress à 500 HT / an et il conditionne la suite. Migrer un site compromis vers une plateforme neuve ne fait que déplacer le problème, et nous préférons le dire avant qu'après.
La bascule elle-même suit une séquence que nous ne modifions pas.
- Nous inventorions par écrit ce qui doit se déplacer et ce qui doit rester en place : fichiers, base de données, domaine, certificat, boîtes aux lettres, redirections existantes, éventuels sous-domaines de test.
- Nous abaissons la durée de vie des enregistrements DNS quelques jours avant l'opération, afin que le changement se propage rapidement au lieu de traîner pendant deux jours.
- Nous installons le site sur la nouvelle plateforme, en accès restreint, et nous le testons réellement : navigation, formulaires, panier s'il y en a un, envoi des notifications.
- Nous basculons le domaine à un créneau convenu avec vous, puis nous vérifions le certificat et la délivrabilité des messages sortants. Un formulaire qui ne renvoie plus rien après une migration est un incident classique, et nous détaillons ses causes dans l'article sur le formulaire qui dit merci sans envoyer de mail.
- Nous laissons l'ancien hébergement actif pendant plusieurs jours, sans le résilier, pour disposer d'un retour arrière immédiat en cas d'imprévu.
- Nous contrôlons enfin la reprise de l'indexation dans les outils de suivi, afin de repérer une page passée en erreur.
Cette rigueur est la même que celle d'une bascule cloud sans coupure, simplement à une échelle réduite. La mise en ligne d'un site représente 120 HT, et elle vous est offerte lorsque nous en assurons ensuite la maintenance annuelle.
Ce que nous refusons de faire au nom d'un partenariat
Nous ne migrons pas un site parce que nous détenons une carte de partenaire. Si votre installation actuelle est propre, si elle tourne sur une version de PHP maintenue et si vous êtes titulaire du compte, nous la maintenons là où elle est. Le déplacement se justifie quand l'hébergement actuel bloque quelque chose de concret : une version de langage abandonnée, un compte détenu par un tiers qui ne répond plus, une absence totale de sauvegarde, un support inaccessible, ou une contrainte de résidence des données nouvellement imposée par un client.
Si l'on vous pousse à changer d'hébergeur sans vous préciser noir sur blanc si vos adresses de messagerie suivent le mouvement, demandez le plan de bascule. Nous écrivons ce qui bouge, ce qui reste, la fenêtre d'indisponibilité attendue et la procédure de retour arrière. Un dirigeant doit pouvoir lire ce document sans être informaticien, et le conserver après notre intervention.