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

À retenir

• Les page builders en drag-and-drop ont résolu un problème de 2015 - les marchands qui ne savent pas coder - avec une architecture de 2015 : des runtimes de widgets, des pages générées par l’app et du JavaScript chargé à chaque visite.
• L’IA a changé la contrainte, pas le besoin. Si du langage courant peut produire du code de thème natif, la couche de drag-and-drop arrête d’être l’interface et devient juste une surcharge.
• Shopify lui-même réduit l’écart par le bas. La génération de blocs par IA d’Horizon et l’édition de thèmes de Sidekick couvrent désormais les tâches pour lesquelles les marchands installaient auparavant un builder.
• Parler de “mort” est encore exagéré. Le contrôle visuel est une vraie interface, la confiance dans les prompts n’est pas absolue, et les écosystèmes matures de 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 avec du peaufinage visuel 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 royalement la plupart du temps. Laissez-moi donc être précis quant à l’affirmation selon laquelle la génération de pages par IA a rendu les builders drag-and-drop obsolètes, car c’est à moitié vrai et à moitié du marketing.

La moitié vraie : l’architecture sur laquelle la plupart des page builders drag-and-drop ont été construits - un runtime de widget générant vos pages via le JavaScript de l’app - vieillit mal, et l’IA en est la cause. La moitié fausse : les marchands cesseront de vouloir un contrôle visuel sur leurs boutiques. C’est faux.

Transparence totale avant de donner le moindre argument : nous développons Fudge, un AI page builder pour Shopify, et nous sommes concurrents dans cette catégorie. Vous devriez lire tout ce qui suit en sachant que nous avons un intérêt direct dans la réponse. Nous avons essayé de mériter votre confiance en présentant les arguments du camp adverse de manière honnête.

Pourquoi vous pouvez nous faire confiance

Nous développons Fudge, un page builder Shopify IA noté 4.9 sur le Shopify App Store, ce qui signifie que nous sommes en concurrence directe avec les outils dont parle cet article - et c’est exactement pour ça que nous montrons les deux côtés de la médaille plutôt que de crier victoire. Nous avons aussi installé, testé et benchmarké chaque grand builder drag-and-drop pour notre matrice de comparaison publique, donc ce qu’on affirme ici sur leur fonctionnement vient de tests documentés, pas de vagues impressions.

Quand une affirmation est une opinion, elle est présentée comme telle. Quand c’est un fait, il est sourcé en bas de page.

À quoi servaient vraiment les page builders

Retour en 2015 (environ). Les thèmes Shopify étaient rigides, les sections-everywhere n’existaient pas encore, et un marchand qui voulait une landing page sur mesure avait deux options : embaucher un développeur ou abandonner l’idée.

Les page builders ont résolu ça avec la meilleure interface dispo à l’époque : un canvas visuel avec des blocs déplaçables. PageFly, Shogun, GemPages, Replo et les autres ont permis à un marketeur de composer une page à la main, sans coder, et la catégorie a mérité son succès honnêtement.

Mais l’interface venait avec une architecture. Pour afficher des layouts de blocs arbitraires sur n’importe quel thème, la plupart des builders embarquent 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 du fait que l’app reste installée et payée. C’était un compromis raisonnable en 2015. La question est de savoir si c’est toujours un compromis raisonnable quand le code lui-même est devenu bon marché.

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 du runtime de widgets a mal vieilli, pour trois raisons documentées.

Le poids des pages a désormais un prix mesurable. Les builders côté app 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 des objectifs de LCP sous 2.5s, d’INP sous 200ms, et de CLS sous 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. Dans tous les cas, un runtime que vous payez en millisecondes, à chaque visite, et pour toujours, est un truc très 2015 à accepter en 2026.

Le lock-in est la règle, pas l’exception. Avec PageFly, Replo, GemPages et Shogun, les pages sont rendues par la couche de l’app et s’arrêtent de s’afficher quand vous la désinstallez - un compromis qu’on a documenté outil par outil dans notre comparatif. Dix ans de pages publiées liées à un abonnement, c’est un passif qui ne fait que grandir.

Le plafond d’édition n’a jamais bougé. Une bibliothèque de blocs est un menu. Si le layout que vous voulez n’est pas sur le menu, vous devez de nouveau embaucher un développeur - exactement le problème pour lequel le builder a été installé. La génération par IA n’a pas de bibliothèque de blocs, puisqu’elle écrit du code ; le plafond est ce que votre thème est capable d’afficher.

Mettez ces trois éléments ensemble et le scénario pessimiste s’écrit tout seul : l’interface est remplaçable, la plateforme absorbe les tâches faciles, et l’architecture est un actif qui se déprécie. Pas de quoi présager une décennie tranquille pour la catégorie.

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

PageFly détient à lui seul une note de 4.9 sur des milliers d’avis sur l’App Store.⁴ Derrière de tels chiffres, il y a 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 tournent très bien aujourd’hui.

Les catégories avec une telle base installée ne meurent pas à cause d’une théorie. Elles s’érodent sur les bords pendant que les leaders s’adaptent - et les leaders s’adaptent, en greffant de la génération IA sur leurs éditeurs (le ‘image-to-layout’ de GemPages, les sections IA de Shogun, la génération IA de Replo). Savoir si de l’IA par-dessus un runtime de widgets est suffisant reste une question ouverte, mais ça prouve que la catégorie a l’intention d’évoluer plutôt que d’expirer.

Qu’est-ce qui va vraiment les remplacer ?

Donc : pas morts. Reconstruits. Voici la forme que prendra la catégorie reconstruite selon nous - et oui, c’est la partie où la thèse de notre produit et celle de cet article sont identiques. Jugez en conséquence.

L’outil qui gagnera 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 de l’assembler, point barre. Les premiers brouillons devraient prendre des secondes, et la boucle description-amélioration devrait gérer les 80% de modifications qui sont sémantiques (“raccourcir le 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 dans votre thème - pas de JavaScript de runtime qui l’assemble dans le navigateur, pas de dépendance qui casse tout à la désinstallation, rien entre votre client et la page. C’est là que l’architecture de 2015 prend sa retraite, et c’est ce qui sépare les AI page builders des simples fonctionnalités IA à l’intérieur des builders de widgets.

3. Le peaufinage visuel par-dessus. Cliquez sur l’élément, changez le truc, voyez le résultat - car l’argument de la manipulation directe est correct. Le canvas ne disparaît pas ; il arrête juste d’être l’architecture de rendu pour devenir ce qu’il a toujours dû être : une surface d’édition sur du code qui vous appartient.

Cette combinaison garde ce que le drag-and-drop faisait de bien (contrôle visuel, pas besoin de coder) et vire ce qu’il faisait mal (le runtime, le lock-in, le plafond de la bibliothèque de blocs). C’est là que se place Fudge, c’est vers là que convergent par le bas les propres outils natifs de Shopify, et c’est là que nous parions que les leaders survivants finiront par aller aussi - s’ils arrivent à changer leur architecture de rendu sans casser une décennie de pages clients, ce qui est une migration beaucoup plus dure que de juste ajouter une barre de prompt.

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

Avant d’installer quoi que ce soit, vous pouvez voir ce que le prompt-driven design donne concrètement sur votre propre boutique : notre outil gratuit de refonte de site Shopify génère trois pistes pour votre page d’accueil à partir de vos vrais produits et contenus, sans aucune app requise.

Vous n’êtes pas obligé d’adhérer à notre vision pour faire le bon choix. Que vous optiez pour un outil AI-first ou pour un éditeur drag-and-drop mature, les cinq mêmes questions mettent en évidence les compromis :

• Quel est le résultat publié ? Du code de thème natif, ou du code rendu via le runtime de l’application ? Cette seule réponse détermine la plupart des autres.
• Que se passe-t-il lors de la désinstallation ? Demandez directement à l’éditeur, par écrit. “Les pages continuent de fonctionner” et “les pages continuent de fonctionner tant que notre balise script reste dans votre thème” sont deux réponses très différentes.
• Quel est le coût en millisecondes ? Lancez Lighthouse sur une page créée avec l’outil et comparez-la à votre thème de base. Les Core Web Vitals sont un critère de classement et d’expérience utilisateur parmi d’autres,³ c’est donc une question de revenus, pas une question de geek.
• Quelle est la limite 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 si le prompt tombe à côté — y a-t-il un moyen visuel de corriger ça, ou faut-il juste faire un re-roll ?
• Shopify le fait-il déjà en natif ? Post-Horizon et post-Sidekick, une bonne partie des cas d’usage des builders sont devenus des fonctionnalités gratuites de la plateforme.¹² Vérifiez bien avant de payer un abonnement pour l’un d’eux.

Pour des recommandations classées par cas d’usage, notre guide des meilleurs page builders Shopify applique exactement cette grille d’évaluation à l’ensemble du marché, y compris pour les outils qui nous surpassent sur des critères précis.

Notre verdict

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

Le canvas en drag-and-drop en tant qu’interface survit, absorbé dans ce qui va suivre. Le runtime de widget en tant qu’architecture ne survit pas, car ses deux raisons d’être se sont affaiblies d’un coup : l’IA a rendu le code natif beaucoup moins cher à obtenir pour les marchands, et l’IA de Shopify a absorbé de nombreuses petites tâches qui justifiaient autrefois l’installation d’une app.

Opinion, clairement assumée : d’ici quelques années, “page builder” désignera un outil qui génère et édite le code natif d’un thème, avec une interface visuelle par-dessus - et les produits qui génèrent encore des boutiques via leur propre JavaScript sembleront aussi datés que les sites Flash en 2012. Pas disparus. Mais d’un autre temps.

Nous sommes biaisés, car c’est pour ce résultat qu’on a créé notre produit. Mais on préfère vous montrer notre raisonnement et nos sources, et vous laisser faire le calcul, plutôt que de faire semblant d’être neutres.

FAQ