Migrer son site vers Infomaniak : le guide complet

Ce que tu vas apprendre

Migrer un site vers Infomaniak n’est pas compliqué techniquement, mais l’ordre des opérations compte : inverser deux étapes suffit à faire tomber le site 24 heures ou à perdre son positionnement Google. Ce guide déroule la procédure complète — sauvegarde, création de l’hébergement, import, test sur URL provisoire, bascule DNS progressive, SSL, emails et redirections — pour un site WordPress ou tout CMS classique. Il s’adresse à qui gère déjà un site (agence, développeur, PME technophile) et veut basculer chez Infomaniak sans coupure ni casse SEO.

Prérequis avant de commencer :

• Accès admin au CMS actuel (WordPress, Prestashop, etc.)
• Accès FTP/SSH ou au gestionnaire de fichiers de l’ancien hébergeur
• Accès au panel DNS du nom de domaine (chez le registrar ou l’ancien hébergeur)
• Un compte Infomaniak actif avec un hébergement commandé
• Une fenêtre de calme (soir ou week-end) pour la bascule finale, même si la coupure visée est nulle

1. Sauvegarder fichiers et base de données

Avant toute chose, fais une sauvegarde complète et vérifie qu’elle est exploitable — pas juste “présente”.

Pour un WordPress :

• Fichiers : exporte l’intégralité du dossier racine via FTP/SFTP ou SSH (tar -czvf backup.tar.gz /chemin/vers/wordpress). Si tu es à l’aise en ligne de commande, la connexion SSH accélère largement l’opération par rapport au FTP classique.
• Base de données : exporte un dump SQL complet via phpMyAdmin ou mysqldump. Vérifie la taille du fichier généré — un dump de 2 Ko pour un site avec 500 articles signale un export raté.

Teste l’archive en la décompressant en local. Une sauvegarde qu’on n’a jamais ouverte n’est pas une sauvegarde, c’est un pari. Si ton ancien hébergeur est OVH ou Gandi, les procédures d’accès SSH sont détaillées ici : SSH sur OVH et SSH sur Gandi.

2. Créer l’hébergement et utiliser le transfert gratuit d’Infomaniak

Infomaniak propose un service de transfert de site gratuit, réalisé par leurs équipes techniques, pour la plupart des CMS courants (WordPress, Prestashop, WooCommerce). C’est une vraie économie de temps, mais il couvre un périmètre précis — pas tout.

Ce que le transfert gratuit prend en charge, en général :

• Copie des fichiers du site depuis l’ancien hébergeur
• Import de la base de données
• Configuration de base du CMS sur le nouvel environnement

Ce qu’il ne couvre généralement pas — à vérifier toi-même :

• Les redirections personnalisées (.htaccess custom, règles de réécriture spécifiques)
• Les tâches cron externes (imports automatiques, synchronisations)
• Les comptes email et leur configuration SMTP
• Les certificats SSL personnalisés ou wildcards hors Let’s Encrypt standard
• Les intégrations tierces (API paiement, CRM connecté, webhooks)

Demande le transfert dès la commande de l’hébergement, mais ne considère jamais qu’il “ferme le dossier” : c’est une base de travail, à auditer point par point avant la bascule DNS.

3. Importer et tester sur l’URL provisoire

Chaque hébergement Infomaniak fournit une URL provisoire (type https://xxx.ftp.infomaniak.com ou l’IP directe) qui permet de tester le site avant tout changement DNS. C’est l’étape qu’on saute trop souvent, à tort.

Sur cette URL provisoire, vérifie dans l’ordre :

• Que la page d’accueil s’affiche sans page blanche ni erreur
• Que le menu de navigation fonctionne (un menu qui ne s’affiche pas après migration est un classique lié aux chemins de fichiers)
• Que les images se chargent (chemins absolus vs relatifs, souvent source de images floues ou cassées)
• Que le formulaire de contact envoie bien un email test — la config SMTP ne suit pas toujours automatiquement, voir l’étape 6
• Que l’admin WordPress est accessible et que les plugins ne renvoient pas d’erreur 500

Si tu utilises WordPress, pense à modifier temporairement le fichier wp-config.php ou à ajouter une ligne dans le fichier hosts local pour forcer la résolution vers le nouveau serveur sans toucher au DNS public — cela évite les faux positifs de test.

4. Baisser le TTL DNS avant la bascule

C’est l’étape la plus souvent oubliée, et celle qui cause le plus de coupures visibles. Le TTL (Time To Live) définit combien de temps les résolveurs DNS gardent une réponse en cache avant de la revérifier.

Si ton TTL est à 24h (86400 secondes) et que tu changes l’IP du serveur brutalement, une partie des visiteurs continuera à taper sur l’ancien serveur pendant… jusqu’à 24h. Résultat : erreurs intermittentes, ERR_CONNECTION_REFUSED pour certains, site normal pour d’autres.

La bonne pratique :

• 48h avant la bascule, connecte-toi au panel DNS et abaisse le TTL à 300 secondes (5 minutes) sur les enregistrements A, AAAA et CNAME concernés
• Attends que ce TTL court soit bien propagé (vérifiable avec des outils de lookup DNS public)
• Une fois la bascule faite, tu pourras remonter le TTL à une valeur normale (3600s ou plus) après 24-48h de stabilité

Pour la logique complète de propagation, consulte DNS qui ne propage pas : diagnostic et résolution.

5. Basculer les enregistrements DNS et réémettre le SSL

Une fois le TTL abaissé et le site validé sur l’URL provisoire, modifie les enregistrements DNS pour pointer vers Infomaniak :

• Enregistrement A (et AAAA si IPv6) vers l’IP fournie par Infomaniak
• CNAME www vers le domaine principal ou l’infrastructure Infomaniak selon leur documentation d’hébergement
• Conserve les enregistrements MX intacts si tu ne changes pas ta messagerie en même temps (voir étape suivante)

Dès que la propagation est effective (généralement rapide grâce au TTL bas), Infomaniak génère automatiquement un certificat SSL Let’s Encrypt pour le domaine — à condition que le DNS pointe bien vers eux au moment de la demande. Vérifie le cadenas et absence de contenu mixte HTTPS une fois le certificat actif. Si le certificat tarde ou échoue, le souci vient presque toujours d’une propagation DNS incomplète — reconsulte l’étape 4.

6. Reconfigurer les emails

Si tes emails professionnels tournent sur l’ancien hébergeur (MX pointant ailleurs que le site), ne les touche pas tant que la migration web n’est pas stabilisée : rien n’oblige à migrer le web et le mail le même jour.

Si en revanche tu migres aussi la messagerie chez Infomaniak :

• Crée les comptes email avant de changer les enregistrements MX
• Mets à jour SPF, DKIM et DMARC pour le nouveau serveur d’envoi — une erreur ici fait finir tes emails en spam, voir Email pro qui finit en spam ou n’arrive pas
• Si le site envoie des emails transactionnels (confirmation de commande, formulaire), reconfigure le SMTP dans le CMS — voir Tes emails WordPress n’arrivent pas : configurer l’envoi ou, pour une solution plus fiable via API, configurer Resend

7. Poser les redirections et vérifier le SEO

Dernière étape, souvent négligée : si des URLs changent (structure de permaliens différente, migration de sous-domaine, changement de CMS), pose des redirections 301 propres — jamais de redirections en masse vers la page d’accueil, qui détruit le référencement acquis.

Checklist post-bascule :

• Soumets un test d’exploration dans Google Search Console pour vérifier que Googlebot atteint bien le nouveau serveur
• Vérifie le fichier robots.txt et le sitemap XML pointent vers les bonnes URLs
• Contrôle qu’aucune boucle de redirection n’a été introduite par un plugin de cache mal reconfiguré
• Surveille les 72h suivant la bascule : trafic, taux d’erreur serveur, temps de réponse

Pour la méthodologie complète de préservation du référencement lors d’un changement d’hébergeur, la logique est identique à celle détaillée dans Changer d’hébergeur sans perdre son référencement et dans Migrer WordPress vers un autre hébergeur : le guide.

Tableau récapitulatif : transfert gratuit Infomaniak, ce qui reste à ta charge

Pièges courants

• Basculer le DNS avant d’avoir testé sur l’URL provisoire : le site peut sembler fonctionner en local mais planter en production à cause d’un chemin absolu codé en dur.
• Oublier de remonter le TTL après la bascule : un TTL à 300s en permanence sollicite inutilement les résolveurs DNS et peut légèrement ralentir la résolution.
• Migrer les emails et le site le même jour : cumule les risques inutilement. Sépare les deux opérations dans le temps.
• Ne pas vérifier le certificat SSL avant de forcer HTTPS : si le certificat n’est pas encore émis et que tu forces la redirection HTTPS, le site devient inaccessible — voir ERR_SSL_PROTOCOL_ERROR.
• Considérer le transfert gratuit comme complet : il pose les bases, pas les redirections custom, les intégrations tierces ni la configuration email.

Une migration bien menée vers Infomaniak ne se joue pas sur la vitesse d’exécution, mais sur l’ordre des étapes — TTL abaissé avant la bascule, SSL vérifié avant le forçage HTTPS, redirections posées avant de couper l’ancien hébergement. Respecte cet ordre et le site change de maison sans que personne ne s’en aperçoive.