À retenir
- La migration se fait par étapes : inventaire des pages, partage de chaque URL existante avec Fudge pour la reconstruire sur un thème de dev, vérification, publication en ligne (même URL), puis désinstallation de PageFly. Aucun nouveau slug, aucune redirection 301 nécessaire.
- La différence structurelle : Fudge écrit les pages directement dans votre thème en Liquid + CSS + HTML. PageFly affiche les pages via son runtime. Après la migration, les pages subsistent sans l’application.
- Le point de blocage pour 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 pour une reconstruction par prompt avec le contexte de marque chargé. Prévoyez un peu plus de temps pour les mises en page atypiques.
Ce guide s’adresse aux boutiques Shopify qui utilisent actuellement PageFly et qui souhaitent passer à Fudge AI. L’objectif de la migration : du code de thème natif pour chaque page, aucun runtime d’application lors du chargement pour le client, et des pages qui survivent à la désinstallation de l’app.
PageFly est un bon outil, le but de ce guide n’est pas de le dénigrer. Les raisons qui poussent les équipes à migrer sont d’ordre structurel (propriété du code final, vitesse de chargement) 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 haute. L’idéal est de boucler un cycle de migration complet avant de toucher à une page qui reçoit du trafic payant.
Collez l’URL de votre page PageFly en live dans Fudge. Fudge analyse la page existante et la génère à nouveau en Liquid + CSS + HTML natif sur un thème de dev non publié — sur la même URL, mais désormais servie par le code de votre thème au lieu du runtime PageFly.
Itérez grâce aux prompts : “hero plus court”, “remplacer le bloc de témoignages par de l’UGC”, “ajouter un ATC sticky sur mobile”.
N’essayez pas de recréer la page au pixel près (pixel-perfect) par rapport à la version PageFly. Le but de la migration est de sortir une meilleure page sur une base plus saine. Profitez-en pour enlever 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 simplement le moteur de rendu (runtime PageFly → le code de votre thème), pas l'URL. Tant que le contenu reste sensiblement le même, vous n'avez pas à vous soucier d'un éventuel transfert de positionnement.
Par page, 1 à 2 heures de création plus 30 minutes de QA, à condition que le contexte de marque soit chargé dans Fudge. À l'échelle d'un catalogue, comptez 2 à 5 pages par semaine et par personne pour maintenir une bonne qualité de QA. La plupart des boutiques terminent la migration en 4 à 8 semaines.
Oui, pendant la migration. Les deux peuvent cohabiter sur une boutique Shopify. Après la migration, le fait de désinstaller PageFly vous permet d'éliminer son impact sur le temps de chargement.
Il vous suffit de coller l'URL existante dans Fudge et l'outil régénère la page en code de thème natif — vous n'avez pas à copier-coller de code ni à repartir d'une page blanche. L'IA lit la page en ligne et fait le plus gros du travail ; vous la guidez avec des prompts. C'est bien plus rapide que la création initiale sur PageFly.
Toute page PageFly qui n'a pas été migrée redevient généralement une page Shopify par défaut ou renvoie une erreur 404 une fois l'application désinstallée. Les pages migrées ne sont pas impactées : elles sont déjà sous forme de code de thème natif sur la même URL. Veillez à migrer ou archiver chaque page PageFly active avant de désinstaller.
