Les Page Builders sont-ils morts à l'ère de l'IA ?

Points à retenir

• Les page builders drag-and-drop ont résolu un problème de 2015 - pour les marchands qui ne savent pas coder - avec une architecture de 2015 : des runtimes de widgets, des pages rendues par l’application, et du JavaScript chargé à chaque visite.
• L’IA a changé la contrainte, pas le besoin. Si un simple texte peut produire du code de thème natif, la couche drag-and-drop cesse d’être une interface et devient une charge inutile.
• Shopify réduit lui-même l’écart par le bas. La génération de blocs par l’IA d’Horizon et l’édition de thèmes de Sidekick couvrent désormais des tâches pour lesquelles les marchands installaient autrefois un builder.
• Dire qu’ils sont “morts” reste exagéré. Le contrôle visuel est une vraie interface, la confiance dans les prompts n’est pas universelle, et les écosystèmes matures des builders ne s’évaporent pas en un an.
• La réponse honnête : la catégorie est en train d’être reconstruite, pas enterrée - autour de la génération prompt-to-native-code (du prompt au code natif) avec des ajustements visuels par-dessus.

Tous les quelques mois, quelqu’un déclare qu’une catégorie de logiciels est morte, et la catégorie en question l’ignore généralement. Permettez-moi donc d’être précis sur l’affirmation selon laquelle la génération de pages par l’IA a rendu les builders drag-and-drop obsolètes, car c’est à moitié vrai et à moitié du marketing.

La partie vraie : l’architecture sur laquelle la plupart des page builders drag-and-drop ont été construits - un runtime de widgets générant vos pages via le JavaScript de l’app - vieillit mal, et l’IA en est la cause. La partie fausse : l’idée que les marchands ne voudront plus de contrôle visuel sur leur boutique. Ils en voudront toujours.

Transparence totale avant de commencer : nous créons Fudge, l’opérateur IA pour les boutiques Shopify, avec une note de 4.9 sur le Shopify App Store, et son page builder est en concurrence dans cette catégorie. Gardez en tête que nous avons des intérêts dans cette réponse en lisant la suite. Nous avons essayé de gagner votre confiance en présentant les arguments de l’autre camp de manière juste et solide.

Pourquoi vous pouvez nous faire confiance

Nous avons passé plus de quatre ans dans l’écosystème Shopify, et nous avons installé, testé et benchmarké chaque grand builder drag-and-drop pour notre matrice de comparaison. Les affirmations ici sur leur fonctionnement s’appuient donc sur des tests documentés, pas sur de simples impressions.

Quand il s’agit d’une opinion, c’est présenté comme tel. Quand c’est un fait, il y a une note de bas de page.

À quoi servaient vraiment les page builders

Retour en arrière, vers 2015. Les thèmes Shopify étaient rigides, l’architecture des sections partout (sections-everywhere) n’existait pas encore, et un marchand qui voulait une landing page personnalisée avait deux options : engager un développeur, ou abandonner l’idée.

Les page builders ont résolu cela avec la meilleure interface disponible à l’époque : un canevas visuel avec des blocs déplaçables (drag-and-drop). PageFly, Shogun, GemPages, Replo et les autres ont permis aux marketeurs de composer une page à la main, sans écrire de code (no code), et la catégorie a mérité son succès.

Mais l’interface était livrée avec une architecture. Pour afficher des layouts de blocs arbitraires sur n’importe quel thème, la plupart des builders déploient leur propre runtime : les pages sont assemblées ou hydratées par le JavaScript de l’app, la logique hébergée vit dans la couche de l’app, et la page dépend de l’installation (et du paiement continu) de l’app. C’était un compromis raisonnable en 2015. La question est de savoir si c’est encore un compromis raisonnable aujourd’hui, alors que le code lui-même ne coûte presque rien.

Les arguments pour dire que “les page builders sont morts”

Voici la version la plus solide du scénario pessimiste. Certaines parties sont notre opinion ; les faits majeurs sont sourcés.

1. L’IA produit maintenant ce pour quoi les builders étaient un plan B

Toute la catégorie du drag-and-drop existe parce que les marchands ne savaient pas écrire le code du thème. L’IA a rendu les premiers brouillons en code natif beaucoup moins chers et plus rapides - la contrainte s’est affaiblie, sans disparaître, mais assez pour que la solution de contournement doive prouver à nouveau son utilité.

En 2026, décrire une page en langage courant et obtenir du Liquid natif et fonctionnel en retour n’est plus de la science-fiction - c’est comme ça que les agents de code généralistes marchent, c’est comme ça que notre produit marche, et c’est la direction vers laquelle pointent les propres outils de Shopify. Nous avons détaillé tout le raisonnement dans le nouveau modèle de développement IA de Shopify : quand le langage naturel se compile en code natif, chaque couche d’abstraction qui existait pour éviter de coder doit se re-justifier.

Un canvas en drag-and-drop n’a jamais été le but. C’était la meilleure interface dispo pour un résultat que les marchands ne pouvaient pas produire eux-mêmes. Une fois qu’une phrase suffit à produire le résultat, le canvas n’est plus la seule interface, et le runtime qui le fait tourner n’est plus un coût indispensable.

2. Shopify intègre le remplaçant directement dans sa plateforme

C’est la partie du scénario pessimiste avec des dates précises.

Lors de la Summer ‘25 Edition, Shopify a lancé Horizon, sa nouvelle base de thèmes, aux côtés de la génération de thèmes par IA (“décrivez votre marque et générez un thème personnalisé”) et de la génération de blocs par IA - “dites juste ce que vous voulez et l’IA s’en occupe”, selon les propres mots de Shopify.¹ C’est du prompt-to-theme-block, natif (first-party) et gratuit.

La Winter ‘26 Edition est allée plus loin : Sidekick modifie maintenant les thèmes à partir d’un prompt et peut créer des blocs sur mesure dans n’importe quel thème du Theme Store, pas seulement Horizon.² Les petites tâches qui motivaient pas mal d’installations de builders - une nouvelle section par-ci, un changement de style par-là - deviennent un simple message de chat dans l’admin.

Notre analyse, assumée en tant qu’opinion : Shopify ne tuera pas la catégorie des page builders lui-même, car les outils intégrés s’arrêtent historiquement au niveau “suffisant” et laissent le plus poussé aux apps. Nous avons écrit sur les limites de Sidekick dans l’état de l’IA Shopify en 2026. Mais Shopify compresse impitoyablement le bas du marché - et le bas du marché, c’est là que les builders de widgets ont acquis la plupart de leurs clients.

3. Les coûts liés à l’architecture s’accumulent (contrairement à 2015)

Le compromis lié au runtime des widgets s’est aggravé avec le temps, pour trois raisons documentées.

Le poids de la page a désormais un prix mesurable. Les page builders de la couche applicative génèrent les pages via leur propre JavaScript, ce qui alourdit chaque chargement de page. Google a confirmé que les Core Web Vitals sont utilisés par ses systèmes de classement, avec pour objectifs un LCP inférieur à 2,5 s, un INP inférieur à 200 ms et un CLS inférieur à 0,1³ — un critère de recherche et d’expérience utilisateur parmi d’autres, en plus de l’impact des pages lentes sur la conversion. Quoi qu’il en soit, un runtime que vous payez en millisecondes, à chaque visite, pour toujours, c’est un concept très 2015 à accepter en 2026.

Le lock-in est la norme, pas l’exception. Avec PageFly, Replo, GemPages et Shogun, les pages dépendent de la couche de l’application : désinstallez-la, et elles cessent de s’afficher ou restent figées, devenant impossibles à modifier — un compromis que nous avons documenté outil par outil dans notre comparatif. Dix ans de pages publiées et enchaînées à un abonnement constituent un passif qui ne fait que croître.

Le plafond d’édition n’a jamais bougé. Une bibliothèque de blocs est un menu. Si la mise en page que vous voulez n’est pas au menu, vous en revenez à devoir engager un développeur — exactement le problème que le builder a été installé pour résoudre. La génération par IA n’a pas de bibliothèque de blocs, car elle écrit du code ; le plafond, c’est ce que votre thème est capable d’afficher.

Mettez ces trois éléments bout à bout et le scénario pessimiste s’écrit de lui-même : l’interface est remplaçable, la plateforme absorbe les tâches faciles, et l’architecture est un actif qui se déprécie. Ce n’est pas une catégorie qui a une décennie confortable devant elle.

L’argument contraire : pourquoi le mot “mort” est paresseux

Maintenant, l’autre côté de la médaille, défendu honnêtement - car si vous ne lisez que la section précédente, vous prendriez aussi de mauvaises décisions.

1. Le contrôle visuel est une interface, pas une béquille

Regardez un marketeur peaufiner une section hero - ajuster les espaces, modifier le recadrage, tester trois tailles de titres - et vous ne regardez pas quelqu’un contourner un manque de compétences. Vous regardez de la manipulation directe, qui, pour certaines retouches, est vraiment l’interface la plus rapide que l’humain ait inventée.

Un prompt est un moyen génial de créer une page. C’est une façon très maladroite de décaler un bouton de quatre pixels. Tout récit sur l’avenir de la catégorie qui se termine par “tout le monde tape des phrases pour toujours” ignore la dernière décennie de recherche sur les interfaces. Le canvas a mérité sa place pour le travail de précision, et il la garde.

2. La confiance dans les prompts n’est pas universelle, et les sceptiques n’ont pas tort

Plein de marchands ont vu un outil IA produire un truc faux avec un aplomb incroyable. Leur conclusion - “je veux voir et toucher ce qui va sur ma boutique avant que ce soit publié” - est rationnelle, pas rétrograde.

Le drag-and-drop offre un genre de certitude que la génération IA doit encore prouver : le résultat est exactement ce sur quoi vous avez cliqué. La variance entre deux essais du même prompt est réelle, même si elle diminue. Pour un gérant de boutique dont la vitrine est tout son business, préférer “prévisible mais plus lent” à “rapide mais probabiliste” est un choix défendable en 2026.

3. Les écosystèmes matures ne s’évaporent pas

À lui seul, PageFly affiche une note de 4,9 sur 5 917 avis sur l’App Store (Octobre 2026).⁴ Derrière de tels chiffres se cachent des bibliothèques de templates, des écosystèmes d’intégrations, des agences avec des habitudes bien ancrées, et des milliers de boutiques dont les pages fonctionnent très bien aujourd’hui.

Les catégories avec une telle base installée ne meurent pas sur une simple thèse. Elles s’érodent sur les bords pendant que les acteurs en place s’adaptent - et ils s’adaptent effectivement, greffant la génération par IA à leurs éditeurs (l’image-to-layout de GemPages, les sections IA de Shogun, la génération IA de Replo). Savoir si ajouter de l’IA par-dessus un runtime de widgets est suffisant reste une question ouverte, mais cela prouve que la catégorie a l’intention d’évoluer plutôt que de disparaître.

Qu’est-ce qui va vraiment les remplacer ?

Donc : pas morte. Reconstruite. Voici la forme que prend, selon nous, cette catégorie reconstruite - et oui, c’est la partie où la thèse de notre produit et la thèse de cet article sont exactement les mêmes. Jugez en conséquence.

L’outil qui remportera la prochaine décennie combine trois propriétés :

1. Le prompt-to-page comme couche de création. Décrire une page est plus rapide que d’en assembler une, un point c’est tout. Les premiers brouillons devraient prendre quelques secondes, et la boucle de description-affinage devrait gérer les 80 % de modifications qui sont sémantiques (“réduire l’espace du hero, ajouter une rangée de témoignages”) plutôt que spatiales.

2. Le code natif comme couche de sortie. La page publiée devrait être du Liquid, du CSS et du HTML directement dans votre thème - aucun runtime JavaScript qui assemble la page dans le navigateur, aucune dépendance qui casse à la désinstallation, rien entre votre client et la page. C’est là que l’architecture de 2015 prend sa retraite, et c’est cette propriété qui sépare les page builders IA des simples fonctionnalités d’IA ajoutées dans les builders de widgets.

3. Des ajustements visuels par-dessus. Cliquer sur l’élément, modifier le contenu, voir le résultat - car l’argument de la manipulation directe est parfaitement justifié. Le canevas ne disparaît pas ; il cesse d’être une architecture de rendu pour devenir ce qu’il aurait toujours dû être : une surface d’édition sur du code qui vous appartient.

Cette combinaison conserve ce que le drag-and-drop faisait bien (contrôle visuel, approche no code) et abandonne ce qu’il faisait mal (le runtime, le lock-in, le plafond de verre des bibliothèques de blocs). C’est le positionnement de Fudge, c’est la direction vers laquelle convergent les outils natifs de Shopify, et nous parions que c’est aussi là que finiront les acteurs existants qui survivront - s’ils parviennent à changer leur architecture de rendu sans casser une décennie de pages clients, ce qui est une migration beaucoup plus difficile que de simplement ajouter un champ de prompt.

Il y a une quatrième propriété que nous ajouterions, et c’est la direction que devrait prendre la catégorie par la suite : vous dire comment la page a performé. La plupart des builders s’arrêtent à la publication. Certains affichent des analytics, mais décider de ce qu’il faut changer et de la prochaine page à créer reste à votre charge. Fudge rapporte les visites, le taux de conversion et les achats de chaque page, vous suggère quoi modifier ou créer ensuite à partir de ces chiffres, et gère le SEO, les quiz et les bundles depuis le même outil. Opinion affichée : c’est la limite entre un page builder et un outil qui vous aide à faire croître votre boutique.

Une autre voie de remplacement mérite son propre processus de décision : passer à du sur-mesure complet. Notre guide sur le Shopify headless avec Hydrogen explique quand ce saut est justifié et quand c’est de l’over-engineering.

Ce qu’il faut regarder, peu importe le camp que vous choisissez

Vous n’êtes pas obligé d’adhérer à notre thèse pour faire le bon choix. Que vous optiez pour un outil AI-first ou un builder drag-and-drop mature, ces cinq mêmes questions exposent les compromis :

• Quelle est la sortie publiée ? Du code de thème natif, ou du code rendu via le runtime de l’app ? Cette seule réponse permet de prédire presque toutes les autres.
• Que se passe-t-il lors de la désinstallation ? Demandez-le directement au vendeur, par écrit. “Les pages continuent de fonctionner” et “les pages continuent de fonctionner tant que notre balise script reste dans votre thème” sont des réponses bien différentes.
• Combien ça coûte en millisecondes ? Lancez Lighthouse sur une page construite avec l’outil et comparez-la à votre thème basique. Les Core Web Vitals sont l’un des nombreux facteurs de classement et d’expérience utilisateur,³ c’est donc une question de revenus, pas une question de nerd.
• Où se situe le plafond d’édition ? Pour les outils basés sur une bibliothèque de blocs : que se passe-t-il quand le bloc dont vous avez besoin n’existe pas ? Pour les outils IA : que se passe-t-il quand le prompt ne donne pas le bon résultat - y a-t-il un moyen visuel de le corriger, ou faut-il simplement relancer (re-roll) l’IA ?
• Est-ce que l’outil natif de Shopify le fait déjà ? Depuis Horizon et Sidekick, une vraie part des cas d’usage des builders est devenue une fonctionnalité gratuite de la plateforme.¹² Vérifiez bien avant de payer un abonnement.

Avant d’installer quoi que ce soit, vous pouvez voir ce que le design basé sur des prompts produit réellement sur votre propre boutique : notre outil de refonte de site Shopify gratuit génère trois directions de page d’accueil à partir de vos vrais produits et contenus, sans aucune app requise.

Pour des recommandations classées par cas d’usage, notre guide des meilleurs page builders Shopify applique exactement cette grille d’évaluation à tout le marché, y compris pour les outils qui nous battent sur des dimensions spécifiques.

Notre verdict

Les page builders sont-ils morts ? Non - mais ce qui en faisait une catégorie distincte est en train de mourir.

Le canevas drag-and-drop en tant qu’interface survit, absorbé par ce qui viendra ensuite. Le runtime de widgets en tant qu’architecture non, car ses deux justifications se sont affaiblies en même temps : l’IA a rendu l’accès au code natif drastiquement moins cher pour les marchands, et la propre IA de Shopify a absorbé une grande partie des tâches simples qui justifiaient autrefois l’installation d’une app.

Opinion affichée : d’ici quelques années, “page builder” désignera un outil qui génère et édite du code de thème natif, avec une surface visuelle par-dessus - et les produits qui afficheront encore les boutiques via leur propre JavaScript donneront la même impression que les sites en Flash en 2012. Pas disparus. Juste datés.

Nous sommes biaisés, car nous avons construit notre outil pour ce résultat. Mais nous préférons vous montrer notre raisonnement et nos sources, et vous laisser faire le calcul, plutôt que de prétendre être neutres.

FAQ