Migrer de PageFly vers Fudge AI : Étape par étape

À retenir

• La migration se fait par étapes : faites l’inventaire des pages, partagez chaque URL existante avec Fudge pour la reconstruire sur un thème de dev, vérifiez, publiez en live (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, vos pages survivent sans l’application.
• L’obstacle sur lequel butent la plupart des équipes n’est pas la reconstruction en elle-même - c’est l’étape de l’inventaire. Faites un audit attentif de chaque page PageFly en live et de son objectif 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 plus de temps pour les layouts atypiques.

Ce guide s’adresse aux boutiques Shopify tournant sur PageFly aujourd’hui et qui souhaitent passer à Fudge AI. L’objectif de cette transition : du code de thème natif pour chaque page, aucun runtime d’app lors du chargement côté client, et des pages qui subsistent même après une désinstallation.

PageFly est un bon outil - ce guide n’est pas là pour le critiquer. Les raisons qui poussent les équipes à migrer sont plutôt d’ordre structurel (propriété du code généré, page speed) 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 :

1. 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.
2. 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.
3. 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.

1. Confirmez dans Shopify Admin → Pages qu’aucune page PageFly n’est encore en live.
2. 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.
3. Désinstallez l’app PageFly.
4. 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

Vais-je perdre mon classement SEO en migrant de PageFly à Fudge ?

Non — la page reste sur la même URL. Vous changez simplement de moteur de rendu (runtime PageFly → code de votre thème), pas d’URL. Tant que le contenu reste substantiellement le même, vous n’avez pas à vous soucier d’un impact sur votre ranking SEO.

Combien de temps prend une migration de PageFly vers Fudge ?

Par page, comptez 1 à 2 heures de création plus 30 minutes de QA, lorsque le contexte de la marque est chargé dans Fudge. À l’échelle d’un catalogue entier, prévoyez 2 à 5 pages par semaine et par personne pour maintenir une bonne exigence de QA. La plupart des boutiques bouclent la migration en 4 à 8 semaines.

Puis-je utiliser PageFly et Fudge en même temps ?

Oui, pendant la migration. Les deux peuvent cohabiter sur une boutique Shopify. Après la migration, désinstaller PageFly permet de regagner en performances (page speed).

Dois-je reconstruire chaque page à partir de zéro (from scratch) ?

Vous collez l’URL existante dans Fudge et il régénère la page sous forme de code de thème natif — vous n’avez pas à copier-coller de code ni à démarrer d’une page blanche. L’IA scanne la page en live et s’occupe de l’essentiel du travail ; vous la guidez avec des prompts. C’est beaucoup plus rapide que la construction initiale sur PageFly.

Que se passe-t-il avec mes anciennes pages PageFly quand je désinstalle ?

À la désinstallation, les pages PageFly non migrées redeviennent typiquement des pages Shopify par défaut ou affichent une erreur 404. Les pages migrées ne sont pas affectées — il s’agit déjà du code de votre thème à la même URL. Pensez à migrer ou archiver chaque page PageFly en live avant de désinstaller l’application.