Checklist de référence : rendre un export Framer livrable et auto-hébergeable

Un export Framer devient réellement livrable lorsqu’il est testé comme un petit site indépendant : les routes, les médias, les animations, les métadonnées et les points de contact doivent fonctionner hors de Framer. La bonne méthode n’est donc pas de télécharger un dossier puis de le transmettre : c’est de constituer un paquet contrôlé, avec ses limites documentées.

Cette distinction compte lors d’une remise client, d’un changement d’hébergement ou d’une sauvegarde avant refonte. Un site visuellement parfait peut encore perdre une police, une route CMS ou un formulaire dès que l’on coupe le lien avec sa plateforme d’origine.

Ce qu’un export Framer doit réellement contenir

Un site Framer publié est une application côté navigateur. Pour qu’une copie statique soit utile, elle doit emporter les pages rendues, les feuilles CSS, les scripts, les polices, les images et les données chargées au démarrage. C’est précisément le périmètre annoncé par l’exporteur Framer d’ExFlow : l’outil rend le site publié, capture ses ressources et réécrit les chemins pour produire des fichiers statiques.

Cela ne signifie pas que tout comportement serveur est exportable. Les formulaires natifs, l’éditeur Framer, une zone protégée gérée dynamiquement ou une mesure d’audience liée au service doivent être inventoriés et remplacés ou assumés comme hors périmètre. C’est une contrainte, pas un défaut de la copie : elle évite de promettre au client un site autonome alors qu’un bouton important dépend encore d’un service externe.

La fiche de remise en cinq rubriques

Avant le premier export, créez une fiche sur une page. Elle sert autant au test qu’à la remise.

Rubrique	Question à inscrire	Preuve attendue
Périmètre	Quelles pages et quelles routes doivent survivre ?	Liste des URL et des modèles CMS
Ressources	Quelles polices, images, vidéos et scripts sont critiques ?	Pages rendues sans erreur réseau
Interactions	Quels menus, transitions et composants doivent rester actifs ?	Contrôle clavier, mobile et bureau
Services	Quels formulaires, analytics ou contenus sont servis à la demande ?	Remplacement, désactivation ou réserve écrite
Livraison	Où vit la version approuvée ?	ZIP daté, dépôt Git ou destination d’hébergement

Cette fiche améliore une remise même quand l’objectif n’est qu’une archive. Elle reprend l’idée d’une remise client après l’export Framer tout en ajoutant une règle pratique : chaque élément critique doit avoir une preuve de fonctionnement hors plateforme.

Procédure de contrôle après export

1. Ouvrir la copie depuis un vrai serveur statique. Un aperçu local peut masquer des chemins ou des requêtes qui échoueront en production. Déployez d’abord dans un espace de préproduction ou servez le dossier avec un serveur local.
2. Parcourir les routes prévues. Testez navigation, liens de pied de page, ancres, pages 404 et, si le site en a, quelques pages de collection. La page d’accueil ne suffit pas.
3. Contrôler le mouvement et le responsive. Vérifiez les transitions, survols, menus et sections interactives à deux largeurs d’écran. Un mouvement décoratif peut être accepté différemment d’un menu inaccessible.
4. Lire la console et l’onglet réseau. Une erreur de police ou une image manquante est souvent plus simple à corriger avant la remise qu’après le changement de DNS.
5. Décider le sort des formulaires. Orientez chaque formulaire vers un endpoint choisi, un service tiers validé, ou retirez-le temporairement. Ne laissez jamais une action utilisateur sans propriétaire.

Choisir une destination en fonction de la remise

Le meilleur hébergement n’est pas universel. Un ZIP daté convient à une archive ponctuelle. Un dépôt Git est plus adapté quand une équipe doit relire les changements et déclencher un déploiement. Un compartiment compatible S3 ou un hébergement statique convient à un site stable et peu dynamique. ExFlow propose le téléchargement du ZIP ainsi que des synchronisations vers Git, S3 et FTP ; choisissez la destination après avoir défini qui maintiendra la version suivante.

La règle de décision est courte : si une personne doit relire chaque version, utilisez Git ; si personne ne modifie le site mais qu’il doit rester consultable, privilégiez un hébergement statique ; si l’on prépare seulement une migration, commencez par l’archive et la fiche de contrôle. Pour un autre contexte de migration, notre dossier Squarespace avant migration propose une organisation complémentaire.

Les erreurs qui rendent une copie inutilisable

Trois oublis reviennent souvent : transmettre des fichiers sans la liste des URL testées ; confondre une animation visible avec une interaction réellement utilisable ; et oublier le propriétaire des formulaires, statistiques ou redirections. Ajoutez aussi une vérification de titre, de description et d’image de partage. Ce sont des éléments faciles à perdre pendant un changement de domaine, comme le montre notre méthode pour fiabiliser une synchronisation Notion-Webflow.

ExFlow peut aussi exporter Webflow et Squarespace, mais la checklist doit rester spécifique à Framer : elle doit couvrir les scripts et les interactions qui font la valeur de cette publication.

La prochaine action

Lancez un export de préproduction, puis remplissez la fiche de remise avant de déplacer le domaine. Si chaque ligne possède une preuve — route ouverte, média chargé, interaction testée ou limite explicitement acceptée — votre export n’est plus seulement une copie : c’est un livrable que l’on peut maintenir.