Exporter un site Framer : remplacer son formulaire avant l’hébergement statique

Vous pouvez exporter un site Framer et l’héberger ailleurs sans refaire sa mise en page. Mais une copie statique n’emporte pas le traitement serveur des formulaires : avant de basculer le domaine, il faut choisir une nouvelle destination pour chaque envoi et la tester. ExFlow pour Framer est utile pour récupérer les pages, les assets et le comportement côté navigateur ; la responsabilité du formulaire reste un chantier à part entière.

C’est la nuance qui évite le scénario le plus pénible : un beau site en ligne, des animations intactes… et des demandes de contact qui n’arrivent nulle part.

Ce qui voyage avec l’export — et ce qui ne voyage pas

Un site Framer publié est davantage qu’une collection de captures. Il charge des pages, des feuilles de style, des scripts, des polices, des images et parfois des données de collections. La page Framer d’ExFlow indique que son export récupère ces éléments après rendu dans un navigateur, y compris les ressources chargées au moment de l’hydratation, puis réécrit les liens vers des fichiers locaux. C’est précisément ce qu’on veut vérifier pour une landing page animée.

En revanche, un formulaire natif repose sur un service qui traite une requête au moment où un visiteur l’envoie. ExFlow le formule clairement : le visuel et le JavaScript côté client peuvent être exportés, mais les formulaires doivent être dirigés vers votre propre endpoint. Ne vendez donc pas l’export comme une migration applicative complète. Considérez-le comme une excellente base portable, puis remplacez les dépendances qui ont besoin d’un serveur.

Cette séparation est saine : elle donne un dossier de site que vous pouvez archiver, déployer dans Git et transmettre à un développeur, sans prétendre que la messagerie, l’analytics ou les accès privés se recréent tout seuls.

Faites l’inventaire avant de lancer l’export

Avant de saisir l’URL dans ExFlow, notez les éléments qui répondent à une action du visiteur. Une simple page vitrine peut n’en avoir aucun. Une landing page de lancement a souvent au moins un formulaire de contact, une inscription à une liste, un téléchargement contre email ou une prise de rendez-vous.

Voici la fiche de décision que j’utiliserais :

Élément	Ce que l’export conserve	Décision avant publication
Pages et routes	HTML rendu, CSS, JS et assets	Vérifier les URL profondes et la page 404
Animations et composants	Code côté navigateur chargé par le site	Tester sur mobile et après un rechargement direct
Formulaire de contact	Champ et bouton visuels, pas le traitement serveur	Choisir un endpoint, une boîte de réception et un accusé de réception
Inscription newsletter	Interface seulement selon votre intégration	Rebrancher le fournisseur ou remplacer le bloc
Analytics et pixels	Scripts éventuellement présents	Confirmer le consentement et les identifiants après déploiement

Si votre page contient un formulaire, écrivez aussi son contrat minimal : qui reçoit le message, quel champ est obligatoire, quelle réponse voit le visiteur, et où est conservé le consentement ? Cette petite phrase vaut mieux qu’une migration faite à l’instinct.

Le workflow en cinq étapes

1. Exportez la version publiée, pas un brouillon flou

Lancez l’export depuis l’URL publique de votre site Framer. ExFlow propose de récupérer pages, CSS, JavaScript, images et médias, puis de télécharger un ZIP ou de synchroniser vers Git, S3 ou FTP. Gardez ce ZIP daté : il est à la fois votre point de départ et votre plan de retour arrière.

Pour une campagne qui a déjà vécu, cette discipline complète bien une copie statique Framer testable avant une refonte. Le bon moment pour découvrir une ressource manquante n’est pas après le changement de DNS.

2. Ouvrez le site exporté sur une URL de test

Ne testez pas seulement index.html en double-cliquant dessus. Publiez le dossier sur un sous-domaine de préproduction ou un hébergeur statique afin que les chemins, les redirections et les requêtes navigateur se comportent comme en production. Si vous choisissez GitHub Pages, vérifiez qu’un fichier d’entrée se trouve à la racine de la source publiée : GitHub Pages cherche notamment index.html, index.md ou README.md (documentation GitHub).

Passez ensuite trois parcours réels : accueil vers page secondaire, lien direct vers une page profonde, puis retour arrière. C’est un meilleur test qu’une revue de dossier.

3. Rebranchez le formulaire avec une règle simple

Choisissez la destination avant de modifier le code :

• Un formulaire de contact simple peut envoyer vers un endpoint de votre CRM, de votre outil de messagerie ou d’un service de formulaires.
• Une newsletter doit rester reliée au fournisseur qui gère le consentement et les désinscriptions ; ne copiez pas seulement les champs.
• Un téléchargement ou une demande commerciale mérite un test de notification interne et une page de confirmation explicite.

Le critère n’est pas « est-ce que le bouton répond ? », mais « est-ce qu’une personne reçoit et peut traiter la demande ? ». Envoyez un test avec une adresse externe, un prénom accentué et une pièce jointe si votre cas l’exige. Vérifiez aussi la page de merci et le message d’erreur.

Si les animations sont votre inquiétude principale, relisez le contrôle spécifique à une remise Framer sans dépendre de l’hébergement. Ici, le point important est différent : une animation peut survivre alors qu’un prospect est silencieusement perdu.

4. Contrôlez les détails qui se voient mal

Avant la mise en ligne, faites une passe courte mais complète :

• ouvrez chaque page depuis le menu et depuis son URL directe ;
• vérifiez images, polices, vidéo et interactions sur un téléphone ;
• contrôlez les titres, descriptions et image de partage ;
• testez chaque formulaire avec un vrai envoi ;
• notez les redirections qui doivent survivre au changement de domaine.

Pour les sites avec plusieurs pages animées, ajoutez une relecture de la navigation et des états au survol. C’est le prolongement logique d’un export Framer vers un hébergement statique sans casser les animations, mais avec une case supplémentaire : le parcours de conversion complet.

5. Déployez de façon réversible

Une fois la préproduction approuvée, gardez deux choses : le ZIP original et un dépôt Git contenant la version publiée. Vous pourrez ainsi comparer une modification, revenir à une version antérieure ou confier le site sans donner un accès Framer à chaque intervenant. GitHub précise que la publication Pages passe par un workflow de déploiement et peut prendre jusqu’à dix minutes après un envoi : prévoyez cette fenêtre dans votre changement, plutôt que de rafraîchir le domaine avec anxiété.

Pour une opération plus large, cette même logique de répétition est expliquée dans comment archiver un site Webflow avant d’arrêter son hébergement. La plateforme change ; la règle reste : on garde une copie vérifiée et un chemin de retour.

Quand ExFlow est le bon outil

ExFlow est pertinent si vous voulez conserver le rendu publié d’un site Framer, l’archiver ou l’amener vers un hébergement statique sans repartir de zéro. Le dossier peut ensuite aller vers Git, S3, FTP ou un hébergement géré, selon l’équipe qui doit l’exploiter.

Commencez par exporter votre site Framer avec ExFlow, puis ne changez le domaine qu’après un envoi de formulaire réussi sur la version de test. Si votre besoin porte plutôt sur un site Webflow ou Squarespace, ExFlow propose aussi des exporteurs dédiés pour Webflow et Squarespace.

Conclusion

Un export Framer réussi n’est pas seulement un dossier qui s’ouvre : c’est un site dont les routes, les ressources et les demandes entrantes fonctionnent hors de Framer. Faites un export, choisissez la nouvelle destination du formulaire, envoyez un test réel, puis publiez. C’est la manière la plus simple de gagner en portabilité sans créer un angle mort commercial.