À retenir
- La migration se fait par étapes : faites l’inventaire des pages, partagez chaque URL existante avec Fudge pour la reconstruire sur un dev theme (thème de développement), vérifiez, mettez 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 génère les pages via son runtime. Après la migration, les pages continuent de fonctionner sans l’application.
- Ce qui bloque la plupart des équipes n’est pas la reconstruction, c’est l’étape de l’inventaire. Faites un audit minutieux de chaque page PageFly en ligne et de son objectif avant de toucher à quoi que ce soit.
- Comptez 1 à 2 heures par page si vous reconstruisez via des prompts avec le contexte de votre marque intégré. Prévoyez 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 cette transition : avoir du code de thème natif pour chaque page, pas de runtime d’application lors du chargement de la page pour le client, et des pages qui survivent à la désinstallation.
PageFly est un bon outil - ce guide n’a pas pour but de le critiquer. La raison pour laquelle les équipes migrent est structurelle (propriété du code de sortie, vitesse de la page) plutôt que fonctionnelle.
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 remplacez simplement le moteur de rendu (runtime PageFly → code de votre thème), pas l'URL. Tant que le contenu reste globalement similaire, il n'y a pas de perte de classement SEO à craindre.
Comptez 1 à 2 heures de construction plus 30 minutes de QA (contrôle qualité) par page, une fois le contexte de votre marque intégré à Fudge. Sur l'ensemble d'un catalogue, prévoyez 2 à 5 pages par semaine et par personne pour maintenir une bonne QA. La plupart des boutiques terminent leur migration en 4 à 8 semaines.
Oui, pendant la migration. Les deux peuvent coexister sur une boutique Shopify. Après la migration, désinstaller PageFly vous permet de récupérer de la vitesse de chargement sur vos pages.
Vous collez l'URL existante dans Fudge et il regénère la page en code de thème natif — vous n'avez pas besoin de copier-coller du code ou de repartir d'une page 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 sur PageFly.
Toute page PageFly qui n'a pas été migrée redevient généralement une page par défaut Shopify ou une erreur 404 une fois l'application désinstallée. Les pages migrées ne sont pas affectées — elles sont déjà en code de thème sur la même URL. Pensez à migrer ou archiver chaque page PageFly en ligne avant de désinstaller.
