Migrer un site statique de Netlify vers Hostbrid Projects

Avant de quitter Netlify, identifiez les éléments de votre site qui en dépendent. Un site qui génère des fichiers statiques peut être facile à déplacer ; les formulaires, fonctions, redirections et aperçus de changements peuvent nécessiter des remplacements. Changer d’hébergeur ne migre automatiquement ni ces fonctionnalités ni leurs données.

Hostbrid Projects peut convenir si votre dépôt génère des fichiers web que vous souhaitez publier depuis Git. Vérifiez le fonctionnement et l’offre sur Projects et les tarifs. Ce guide ne désigne pas un hébergeur comme le meilleur pour tous : il vous aide à vérifier si votre application peut changer sans perdre de fonctionnalités.

1. Faites l’inventaire avant de déconnecter Netlify

Examinez le dépôt, la configuration du site et le tableau de bord Netlify. Recherchez :

netlify.toml, les scripts package.json, la commande de build, la version de Node et le dossier de publication.
netlify/functions/, les Edge Functions, plugins, variables d’environnement et appels d’API.
Les formulaires avec data-netlify="true" ou netlify, et le service qui reçoit et conserve les envois.
Les règles de redirection et d’en-tête, routes SPA, liens absolus et URL utilisées par les moteurs de recherche.
Les domaines, DNS, certificats, intégrations OAuth, webhooks, bases de données et services de fichiers.
Les Deploy Previews : Netlify peut créer des aperçus pour les changements proposés ; ne supposez pas que la destination offre le même processus.

Netlify documente ses formulaires gérés, ses fonctions et les Deploy Previews. Notez les fonctions que vous utilisez réellement. Un fichier netlify.toml peut contenir une configuration indispensable même si le site semble statique.

Ce qu’exécute votre projet	À vérifier avant de choisir la destination
HTML, CSS, JavaScript ou sortie statique d’un framework	Vérifiez que le build produit toutes les routes et ressources nécessaires dans le dossier publié.
Formulaire Netlify	Configurez et testez un autre destinataire ; l’attribut du formulaire n’enverra pas les demandes au nouvel hébergeur.
Netlify Function ou Edge Function	Déplacez le code vers un runtime compatible ou conservez la fonction externe ; les fichiers statiques ne l’exécutent pas.
Connexion, paiements, API ou base de données	Vérifiez séparément les URL autorisées, callbacks, secrets, webhooks et la persistance.
Aperçus de pull requests	Confirmez le processus proposé par le nouvel hébergeur avant de supprimer l’ancien.

Si vous ne savez pas ce qui se passe après l’envoi d’un formulaire, suivez d’abord ce guide pour vérifier le formulaire, le backend et la livraison.

2. Testez le build depuis le dépôt

Ne migrez pas à partir d’une capture d’écran ou du dossier de développement. Utilisez une copie de travail propre pour reproduire le build :

git clone URL_DU_DEPOT test-migration
cd test-migration
npm ci
npm run build

Ces commandes sont un exemple pour un projet Node avec package-lock.json. Si le projet utilise pnpm, Yarn, une autre version de Node ou une commande différente, respectez les versions et scripts déclarés par le projet. Lisez la configuration et vérifiez le véritable dossier de sortie ; dist, build et out ne sont pas interchangeables.

Ouvrez le résultat en local avec le serveur d’aperçu du framework ou un serveur statique. Vérifiez l’accueil, une URL profonde, son rechargement direct, les CSS, JavaScript, images et erreurs de console. Si l’application nécessite des fonctions serveur, un build réussi ne prouve pas qu’elles fonctionneront sur un hébergement statique.

3. Publiez une copie de test depuis Git

Connectez le dépôt dans Projects, choisissez la bonne branche et configurez les commandes d’installation et de build, ainsi que le dossier de sortie. Vérifiez le journal du build et accédez à l’adresse de test Projects avant de connecter le domaine final. Consultez les conditions actuelles de l’offre : le sous-domaine gratuit, le domaine personnalisé et les services persistants peuvent avoir des conditions différentes.

Testez les mêmes pages et actions que dans votre inventaire. Pour une route SPA, saisissez-la directement dans le navigateur puis rechargez la page ; une navigation qui fonctionne uniquement depuis l’accueil ne suffit pas. Vérifiez également robots.txt, les canonicals, les liens internes, la langue, le statut HTTP et l’absence d’identifiants dans les fichiers téléchargés.

Projects publie depuis Git et accepte des commandes de build et dossiers de sortie configurables, selon sa page produit. Ne supposez pas que cela remplace les formulaires Netlify, ses aperçus, Edge Functions, fonctions serveur, plugins ou en-têtes personnalisés. Si vous avez besoin d’un backend persistant, vérifiez le fonctionnement, les ressources et le tarif du service avant de le commander.

4. Remplacez les dépendances avant de modifier le DNS

Si le site utilise des formulaires, configurez d’abord le nouvel endpoint et testez les envois réussis comme les erreurs. Vérifiez que le message arrive au bon destinataire ; l’écran « envoyé » du navigateur ne prouve pas la livraison.

Pour chaque Function, identifiez la méthode, la route, les variables, les permissions, le stockage et le format de réponse. Décidez si elle doit rester externe, s’exécuter comme backend compatible ou être administrée sur un VPS. Ne mettez jamais de secrets dans Git ni dans des variables intégrées au JavaScript du navigateur.

Recréez les redirections et règles d’en-tête avec une fonction documentée par la destination, puis testez chaque règle. Vérifiez aussi les connexions, paiements, e-mails, webhooks, limites CORS et routes appelées par l’application. Si vous ne pouvez pas remplacer une dépendance, gardez le site actuel disponible pendant que vous cherchez une solution.

5. Changez le domaine en préparant le retour arrière

Conservez autant que possible les mêmes routes publiques. Si vous changez seulement d’hébergeur en gardant le domaine et les URL, testez d’abord le nouveau site, puis modifiez les enregistrements DNS nécessaires. Notez les anciennes valeurs et gardez Netlify disponible jusqu’à la vérification de HTTPS, des URL importantes, des formulaires, des accès, de l’analytique et des e-mails.

Si vous changez aussi de domaine ou de routes, préparez une correspondance une à une et des redirections permanentes directes. Mettez à jour les canonicals et les liens internes du nouveau site ; ne redirigez pas toutes les pages vers l’accueil. Google recommande de tester le nouveau site, de mapper les anciennes URL et d’activer les redirections lors d’un changement d’URL ou de domaine. Une migration technique ne garantit ni le maintien des positions ni un crawl immédiat par Google.

Ne supprimez pas l’ancien déploiement juste après la modification du DNS. Vérifiez d’abord les routes avec et sans www, le certificat, les redirections, les ressources, les pages indexables et les fonctions métier. Pour l’architecture générale, consultez où héberger un site créé avec l’IA ; pour une application React/Vite, vérifiez aussi le build, les routes et le déploiement Git.

Quand rester sur Netlify

Il peut être préférable de garder le site tel quel s’il dépend des Forms, Functions, Edge, plugins ou aperçus requis par votre équipe, sans remplacements vérifiés. La migration peut aussi ne pas être intéressante si le coût, le contrôle du domaine ou les besoins de l’équipe ne s’améliorent pas avec la destination. Comparez les fonctionnalités et tarifs Netlify actuels avec les offres et limites de Projects selon l’usage réel de votre compte.