Guide migration · Framer

Exporter un site Framer en HTML sans perdre ses animations.

Une migration réussie ne consiste pas à prendre une capture d’écran du site. Il faut reconstruire chaque déclencheur, chaque durée et chaque état dans un projet qui fonctionne sans le runtime du builder.

8 min de lectureMis à jour le 25 juillet 2026Par XportFrame

Framer facilite la création de mouvements complexes, mais une partie de ces comportements peut être attachée à sa structure interne. Le risque, lors d’un départ précipité, est de conserver l’apparence d’une page tout en perdant ce qui lui donne sa personnalité : la révélation des blocs, les transitions entre états, les variantes de composants, les effets de parallaxe ou les menus qui réagissent au scroll.

La bonne méthode consiste à traiter le site comme un système. On commence par documenter ce qui existe, puis on reconstruit les comportements dans des technologies portables : CSS pour les transitions simples, JavaScript natif pour les interactions, et des fichiers locaux pour les médias et les polices. Framer précise dans sa documentation sur l’auto-hébergement qu’il ne fournit pas d’export HTML autonome de ses sites publiés.

1. Avant de toucher au site, figez une référence

Avant l’export, créez une référence visuelle incontestable. Parcourez toutes les pages sur desktop et mobile, puis enregistrez les interactions importantes. Une vidéo courte par parcours est souvent plus utile que vingt captures : elle montre l’ordre des animations, leur vitesse, les retards et le comportement au retour.

  • Filmez la page d’accueil du chargement jusqu’au footer, sans accélérer le scroll.
  • Ouvrez chaque menu, accordéon, modal, carrousel et formulaire.
  • Testez les hovers au clavier et à la souris, pas seulement au tactile.
  • Notez les différences entre desktop, tablette et mobile.
  • Conservez une copie des titres, métadonnées et URL actuelles.
Le bon réflexe

Ne validez jamais une migration uniquement avec une capture pixel-perfect. Deux pages peuvent être identiques au repos et totalement différentes dès que l’utilisateur interagit.

2. Inventoriez les pages, composants et assets

Une landing seule est simple. Un vrai site contient souvent des routes imbriquées, des pages CMS, des variantes locales et des composants réutilisés. Construisez d’abord une carte de routes : page d’accueil, pages produit, articles, pages légales, formulaires, pages 404 et redirections historiques.

Pour chaque route, listez les ressources nécessaires : images originales, formats mobiles, vidéos, icônes, fichiers SVG, polices et scripts tiers. Le résultat attendu n’est pas une page qui charge ses médias depuis Framer, mais un dossier autonome dont tous les chemins restent valides après changement de domaine.

01

Carte des routes

Associez chaque URL actuelle à un fichier ou à une route de destination. Incluez les pages dynamiques et les anciennes URLs encore indexées.

02

Bibliothèque de composants

Repérez les headers, boutons, cards, témoignages et footers répétés. Ils doivent garder les mêmes règles partout.

03

Dossier de médias

Téléchargez les sources avec des noms lisibles, puis vérifiez qu’aucune URL distante indispensable ne reste dans le HTML ou le CSS.

3. Cartographiez chaque animation en quatre informations

Une animation n’est pas seulement un effet. Pour pouvoir la reproduire proprement, notez son déclencheur, ses propriétés, son timing et son état final. Par exemple : “quand la carte entre à 15 % dans le viewport, elle passe de 24 px plus bas et 0 d’opacité à sa position normale en 620 ms, avec un léger délai selon son index”.

Cette description permet de choisir la technique la plus légère. Les hovers, changements d’opacité, déplacements et rotations simples appartiennent généralement au CSS. Les animations déclenchées au scroll peuvent reposer sur IntersectionObserver. Les séquences synchronisées demandent parfois une petite timeline JavaScript, mais elles ne justifient pas forcément une dépendance entière.

reveal.js
const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (!entry.isIntersecting) return;
    entry.target.classList.add("is-visible");
    observer.unobserve(entry.target);
  });
}, { threshold: 0.15 });

document.querySelectorAll("[data-reveal]")
  .forEach((element) => observer.observe(element));

4. Reconstruisez du plus simple au plus fragile

Commencez par les transitions de base, puis remontez vers les comportements complexes. Cette progression évite de déboguer simultanément le layout, les médias et l’animation. Stabilisez d’abord les dimensions et les points de rupture, ensuite les hovers, puis les apparitions au scroll, et enfin les séquences.

  • CSS d’abord : transitions, hovers, états ouverts/fermés, micro-déplacements et gradients animés.
  • JavaScript natif ensuite : scroll, accordéons, menus, carrousels légers et synchronisation d’états.
  • Bibliothèque ciblée en dernier recours : uniquement lorsque l’effet exige une timeline ou une interpolation que le navigateur ne gère pas simplement.

Conservez les courbes d’accélération. Une animation de 500 ms avec une courbe linéaire n’a pas le même ressenti qu’une animation de 500 ms en cubic-bezier(.2,.8,.2,1). Le “pixel-perfect” du mouvement se joue souvent davantage dans l’easing que dans la durée.

5. Testez le mouvement sur chaque format

Un effet élégant sur grand écran peut devenir gênant sur mobile. Les éléments flottants peuvent couvrir le texte, un parallaxe peut provoquer un débordement horizontal et une animation liée au hover n’existe pas sur écran tactile. Pour chaque interaction, prévoyez un comportement de repli.

  • Aucune animation ne doit déplacer le contenu au point de créer un saut de mise en page.
  • Les éléments interactifs restent utilisables au clavier avec un focus visible.
  • Le menu et les modales se ferment avec Échap et rendent le focus correctement.
  • La règle prefers-reduced-motion réduit ou désactive les mouvements non essentiels.
  • Le site reste lisible si JavaScript est lent ou indisponible.

6. Préservez les URLs, le SEO et les formulaires

Une migration visuelle parfaite peut tout de même perdre du trafic si les URLs changent. Réutilisez les mêmes slugs lorsque c’est possible. Quand une route doit changer, ajoutez une redirection permanente vers sa nouvelle destination. Reportez aussi les titres de pages, descriptions, balises sociales, données structurées et textes alternatifs.

Les formulaires méritent un test séparé : validation, message d’erreur, confirmation, anti-spam et destination des données. L’interface peut rester identique, mais l’envoi doit être raccordé à un service ou à votre propre backend après la sortie de Framer.

7. Checklist de sortie

  • Toutes les pages publiques répondent et aucune route importante ne renvoie 404.
  • Les images, vidéos, SVG et polices sont servis depuis votre projet ou un domaine que vous contrôlez.
  • Les hovers, apparitions, menus et transitions ont été comparés à la vidéo de référence.
  • Les tests ont été réalisés sur un vrai mobile, pas uniquement dans l’émulateur du navigateur.
  • Les redirections et le domaine ont été préparés avant de couper l’ancien hébergement.
  • Une version précédente reste disponible pour revenir en arrière rapidement.

Le moment idéal pour résilier l’ancien plan n’est pas le jour où le nouveau site “semble terminé”. Attendez que le domaine serve la nouvelle version, que les formulaires aient reçu un test réel et que les outils d’analyse ne montrent aucune rupture de parcours.

Votre animation ne doit pas être votre prison.

XportFrame cartographie les pages, récupère les assets et prépare une version autonome que vous pouvez vérifier dans le dashboard avant de télécharger le ZIP.

Tester avec une URL →

Continuer à reprendre le contrôle.