À retenir
- La migration se fait par étapes : inventoriez vos pages, partagez chaque URL existante avec Fudge pour la reconstruire sur un thème de dev, vérifiez, publiez en ligne (sur la même URL), puis désinstallez PageFly. Pas de nouveaux slugs, aucune redirection 301 n’est requise.
- La différence structurelle : Fudge écrit les pages directement dans votre thème en Liquid + CSS + HTML. PageFly fait le rendu des pages via son runtime. Après la migration, les pages survivent sans l’application.
- L’obstacle que rencontrent la plupart des équipes n’est pas la reconstruction, mais l’étape de l’inventaire. Faites un audit minutieux de chaque page PageFly en ligne et de son utilité avant de toucher à quoi que ce soit.
- Comptez 1 à 2 heures par page si vous reconstruisez via prompt avec le contexte de la marque chargé. Prévoyez plus pour les mises en page atypiques.
Ce guide s’adresse aux boutiques Shopify utilisant actuellement PageFly et qui souhaitent passer à Fudge AI. L’objectif de ce changement : du code natif dans le thème pour chaque page, aucun runtime d’application lors du chargement de la page par le client, et des pages qui survivent à la désinstallation.
PageFly est un bon outil — ce guide n’est pas là pour le dénigrer. La raison pour laquelle les équipes migrent est d’ordre structurel (propriété du code généré, vitesse de page) plutôt que fonctionnel.
Pourquoi vous pouvez nous faire confiance
Nous avons conçu Fudge et accompagné des dizaines d’équipes dans cette migration. Nous avons aussi travaillé pendant des années sur des boutiques construites avec PageFly et savons ce qu’il faut faire pour les démêler. Les étapes ci-dessous sont éprouvées sur le terrain. Comparez cela avec notre comparatif PageFly vs Fudge plus global pour avoir la vision stratégique globale.
Avant de commencer
Trois prérequis :
- Vous êtes sûr de votre choix. La migration est assez définitive pour qu’on s’y engage à fond. Après ça, vos pages vivront directement au sein même de votre thème.
- Vous disposez d’un dev theme sur lequel bosser. Il faut toujours reconstruire et tester ces pages sur un thème en développement avant de pulibier en live. Shopify permet de garder des thèmes non publiés exactement pour ça.
- Vous avez installé Fudge et l’avez connecté à votre boutique, même si vous n’avez encore rien construit.
Étape 1 : Inventorier chaque page PageFly actuellement en live
C’est l’étape qui coûte le plus de temps si vous faites l’impasse dessus. Ouvrez l’app PageFly et listez toutes les pages qui sont en live sur votre boutique.
Pour chaque page, notez :
- L’URL de la page sur la boutique en live
- L’objectif de la page (LP pour quelle campagne, variante de PDP, homepage, etc.)
- Le trafic mensuel approximatif
- Si elle reçoit actuellement du trafic payant (paid traffic)
- La dernière modification significative
Sauvegardez cette liste dans un tableur partagé. Elle deviendra votre backlog de migration.
Regroupez par ordre de priorité :
- Haute : les pages recevant du trafic payant en ce moment. À migrer en premier.
- Moyenne : les pages avec un trafic organique significatif, mais sans dépenses publicitaires actives.
- Basse : les pages archivées ou à faible trafic. Demandez-vous si elles valent vraiment la peine d’être migrées.
Étape 2 : Choisir la première page et la reconstruire dans Fudge
Commencez par une page de priorité moyenne, et non de haute priorité. Il est préférable de faire un cycle de migration complet avant de toucher à une page générant du trafic payant.
Collez l’URL de la page PageFly en ligne dans Fudge. Fudge lit la page existante et la regénère en Liquid + CSS + HTML natif sur un dev theme non publié — exactement à la même URL qu’actuellement, sauf qu’elle est désormais servie par le code de votre thème au lieu du runtime PageFly.
Itérez avec des prompts : “raccourcir le hero”, “remplacer le bloc de témoignages par du UGC”, “ajouter un ATC sticky sur mobile”.
N’essayez pas de recréer la page au pixel près par rapport à PageFly. Le but de la migration est de mettre en ligne une meilleure page sur des fondations plus solides. Profitez-en pour faire du ménage et retirer le superflu.
Étape 3 : Tester la nouvelle page
Depuis votre dev theme non publié :
- Regardez la page sur mobile (sur un vrai appareil, pas juste Chrome DevTools)
- Lancez Lighthouse Mobile. Confirmez que LCP < 2.5s, INP < 200ms, et CLS < 0.1
- Cliquez sur le bouton Add to Cart de la nouvelle page. Vérifiez que le panier, le checkout et les événements post-achat (le tracking) se déclenchent bien.
- Simulez une 4G lente (fonction throttle dans DevTools) : permet de tester le temps de chargement pour un client lambda.
Si quoi que ce soit foire, corrigez dans Fudge avant de publier.
Étape 4 : Publier en live
Lorsque la page est prête, publiez le thème de dev (ou poussez la section en live). L’URL ne change pas — le même slug /pages/... est maintenant distribué par le code de votre thème au lieu de PageFly. La version de Fudge prend automatiquement le dessus sur le slug ; nul besoin de dépublier dans PageFly au préalable, pas de redirections 301, aucune créa publicitaire à mettre à jour.
Attendez 24 à 48 heures. Surveillez la page dans vos outils d’analytics et de reporting publicitaire. Si tout semble correct, vous pouvez supprimer la page PageFly originale dans l’application PageFly quand vous le voulez — à ce stade, elle est inactive.
Étape 5 : Répéter le processus pour le reste de votre backlog
Remontez la file en suivant la priorité dictée. Ne cherchez surtout pas à tout migrer d’un coup - la quantité de choses à vérifier en QA sur plusieurs pages rend les erreurs beaucoup plus fréquentes.
Un bon rythme de croisière : 2 à 5 pages par semaine, de par leur complexité. Une toute petite floppée de LPs peut être migrée en deux semaines max. Un très gros catalogue prendra un trimestre en comparaison.
Étape 6 : Désinstaller PageFly
Agissez seulement après avoir migré (ou délibérément archivé) toutes les pages PageFly, et après qu’au moins deux semaines d’analytics en live ont confirmé l’absence de régression.
- Confirmez dans Shopify Admin → Pages qu’aucune page PageFly n’est encore en live.
- Vérifiez dans votre thème que PageFly n’a pas laissé de balises script ni d’imports CSS. Cherchez le domaine ou les noms d’assets de PageFly dans
theme.liquid. - Désinstallez l’app PageFly.
- Relancez Lighthouse sur quelques pages clés pour confirmer que le runtime a bien disparu.
C’est terminé.
Que faire si une page ne se migre pas proprement ?
Trois alternatives :
- La reconstruire autrement. La page PageFly s’arcboutait sans doute sur des barrières dont Fudge n’hérite pas. Jouez le jeu et cherchez la simplification au moment de reconstruire.
- Faites marcher les deux le temps qu’il faut sur cette page particulière. Une situation non viable sur la longueur mais qui dépannera la page visée pendant que vous continuez de gratter sa bonne modélisation côté Fudge et chercherez les ajustements nécessaires.
- Demandez-en un custom theme template. Devant une mise en page bien trop complexe, votre dev se chargera lui-même d’insérer son Liquid section en direct dessus. Fudge n’aura alors qu’à “scaffolder” dessus.
Pour quelle raison il est de mise de migrer ?
Les arguments structurels, en bref :
- Propriété du code généré. Les pages Fudge sont du code de thème. Elles restent si vous désinstallez. Contrairement aux pages PageFly.
- Page speed. PageFly ajoute un runtime JavaScript à chaque visite sur une page générée par l’app. Fudge n’ajoute aucun runtime supplémentaire.
- Workflow. Décrire une page dans un prompt est plus rapide que de faire du glisser-déposer de blocs (drag-and-drop) pour une page que vous n’avez jamais construite auparavant. Les deux ont une courbe d’apprentissage ; celle des prompts est plus rapide pour la plupart des marketeurs.
Pour aller plus loin, vous pouvez consulter les meilleurs page builders Shopify, IA vs drag-and-drop, et les meilleurs page builders IA pour Shopify.
FAQ
Non — la page reste sur la même URL. Vous changez le moteur de rendu (runtime PageFly → le code de votre thème), pas l'URL. Tant que le contenu reste substantiellement similaire, il n'y a pas de transfert de classement dont il faut s'inquiéter.
Par page, 1 à 2 heures de construction plus 30 minutes de QA, lorsque le contexte de la marque est chargé dans Fudge. Sur l'ensemble d'un catalogue, prévoyez 2 à 5 pages par semaine et par personne pour maintenir la qualité de la QA. La plupart des boutiques terminent la migration en 4 à 8 semaines.
Oui, pendant la migration. Les deux peuvent coexister sur une boutique Shopify. Après la migration, désinstaller PageFly supprime l'impact sur la vitesse de chargement.
Vous collez l'URL existante dans Fudge et il régénère la page en tant que code natif du thème — vous ne copiez-collez pas de code ou ne reconstruisez pas à partir d'une feuille blanche. L'IA lit la page en ligne et fait la majeure partie du travail ; vous la guidez avec des prompts. C'est beaucoup plus rapide que la construction initiale avec PageFly.
Toute page PageFly qui n'a pas été migrée revient généralement à une page Shopify par défaut ou à une erreur 404 une fois l'application désinstallée. Les pages migrées ne sont pas affectées — elles sont déjà du code de thème sur la même URL. Migrez ou archivez chaque page PageFly en ligne avant de désinstaller.
Vous ne savez pas encore vers quoi vous tourner ? Comparez les six meilleures alternatives à PageFly avant de migrer.
