Hydrogen devient agnostique au runtime : ce que cela règle
Shopify et Vercel reconstruisent Hydrogen comme une base ouverte et agnostique au runtime. Hydrogen se déploie désormais directement sur Vercel, le projet est open source et fonctionne au-delà des frontières de frameworks : Svelte, Nuxt, Next.js ou ta propre configuration. C'est une vraie amélioration, et elle répond exactement à la critique qui accompagne Hydrogen depuis son lancement. Ce qu'elle ne règle pas se situe un niveau plus haut : la couche frontend que tu reconstruis pour chaque storefront.
Ce qui a réellement été annoncé
Les points clés du briefing Vercel sur cette reconstruction :
- Hydrogen est agnostique au runtime. Oxygen n'est plus le seul chemin vers la production. Le déploiement sur Vercel devient une option de premier rang.
- Hydrogen est ouvert aux frameworks. React n'est plus une hypothèse intégrée. C'est une base commerce sur laquelle différents frameworks peuvent s'appuyer.
- L'open source comme fondation. Les développeuses, développeurs et agents disposent d'une base commune au lieu de réécrire la couche commerce pour chaque storefront.
- Les agents font partie du design. La reconstruction prend explicitement en compte le fait que les humains ne sont plus les seuls à construire des storefronts.
Pour les équipes Shopify qui devaient choisir entre un thème Liquid et un développement sur mesure sans retour possible, voilà une troisième option sérieuse. Qui a déjà regardé le côté coûts de ce choix le verra vite : nous avons fait le calcul dans Shopify Frontend Cost: Theme vs. Headless, et cette reconstruction déplace exactement une ligne de ce calcul, l'engagement runtime.
Pourquoi c'est un vrai progrès
Depuis deux ans, nous entendons la même phrase en discovery : « Avec Hydrogen, nous sommes collés à Shopify. Si nous voulons changer, nous repartons de zéro. » La reconstruction enlève la moitié de la charge de cette phrase. Le runtime ne fait plus partie du marché. Une équipe qui démarre sur Hydrogen aujourd'hui n'est pas automatiquement enfermée demain sur une seule couche d'hébergement.
Que Shopify le fasse ouvertement et en open source, plutôt que de garder le runtime comme instrument de rétention, est la bonne décision. Nous le disons sans ironie : c'est le mouvement dont le marché avait besoin, et il vient du leader du marché.
Ce que la reconstruction ne règle pas
Agnostique au runtime n'est pas la même chose qu'agnostique au backend. Et ni l'un ni l'autre n'est encore du frontend management.
1. Le backend reste fixé. Hydrogen, c'est la logique commerce de Shopify. Si ton activité B2B tourne sur un système proche de l'ERP, ta marque DACH sur Shopware et ta marketplace sur encore autre chose, un frontend Shopify libéré du runtime t'aide sur exactement un de ces cas. La question d'un frontend unique pour plusieurs backends reste ouverte.
2. La couche frontend se construit toujours par storefront. Une fondation open source te retire la couche commerce, pas la storefront au-dessus. Navigation, pages de campagne, workflow éditorial, gestion des locales, discipline des design tokens sur plusieurs marques : tout cela est reconstruit dans chaque projet. Dans nos projets, c'est cette partie qui consomme les semaines, pas l'appel à la Storefront API.
3. L'éditorial et le marketing ne sont pas adressés. Cette reconstruction est une histoire de développeurs et d'agents. Elle ne dit rien sur la façon dont une content manager met en ligne une page de campagne un jeudi soir sans ouvrir de ticket. Traite la couche frontend comme un artefact de code et ce travail reste durablement dans le backlog engineering.
4. Plus de choix signifie plus de décisions. Svelte, Nuxt, Next.js, ton propre framework, Vercel ou ailleurs : chacun de ces axes devient ta décision et ta maintenance. Pour une équipe avec de la capacité plateforme, c'est un gain. Pour une équipe de trois personnes, c'est du travail que personne n'a inscrit au plan.
Là où Laioutr intervient
Laioutr est une Frontend Management Platform (FMP) : une couche de pilotage du frontend commerce qui se place au-dessus du backend au lieu d'en faire partie. Concrètement, face aux quatre points ci-dessus :
L'agnosticisme backend comme architecture, pas comme promesse. Notre couche d'orchestration parle à plus de 50 backends, Shopify inclus. Tu gardes Shopify comme moteur commerce et tu obtiens la même couche storefront que celle qui tourne sur Shopware ou commercetools. La forme technique est décrite sur Composability et Orchestration.
La couche frontend comme produit, pas comme projet. Sections, blocks, bibliothèque de composants et déploiement arrivent comme une plateforme, pas comme un modèle de dépôt. La deuxième storefront ne repart pas de zéro. Pour les configurations multi-marques et multi-marchés, c'est la différence entre des semaines et des trimestres : Multi-Brand et Multi-Market.
L'éditorial sans ticket développeur. Pages de campagne, landing pages et modifications de contenu se font dans Studio, avec preview et validation. L'engineering relit et étend, sans être le goulot d'étranglement : Content Management.
Cohérence et performance comme propriétés de la plateforme. Les design tokens et les thèmes s'appliquent à toutes les storefronts au lieu de dériver dépôt par dépôt (Brand Consistency), et les Core Web Vitals sont une part mesurée de la plateforme plutôt que le résultat d'une passe d'optimisation en fin de projet (Performance et Core Web Vitals).
Si tu veux peser « Hydrogen ou couche frontend » concrètement pour ton équipe, nous l'avons écrit avant cette reconstruction dans Hydrogen vs. Laioutr: Which Frontend for Which Team?. La ligne runtime y est désormais dépassée par l'annonce. Les lignes équipe et exploitation ne le sont pas.
Ce que tu y gagnes
- Runtime. Hydrogen après la reconstruction: au choix, Vercel en premier rang. Avec Laioutr comme couche frontend: au choix, hébergement UE inclus.
- Backend. Hydrogen après la reconstruction: Shopify. Avec Laioutr comme couche frontend: plus de 50 backends, Shopify inclus, remplaçable.
- Deuxième storefront. Hydrogen après la reconstruction: un nouveau projet sur une base commune. Avec Laioutr comme couche frontend: une configuration sur une plateforme existante.
- Page de campagne. Hydrogen après la reconstruction: pull request. Avec Laioutr comme couche frontend: Studio, avec preview et validation.
- Modèle d'exploitation. Hydrogen après la reconstruction: ton équipe exploite la couche. Avec Laioutr comme couche frontend: une plateforme, avec mises à jour et support.
FAQ
Laioutr est-il une alternative à Hydrogen ou un complément ? Une alternative au niveau de la couche frontend. Tu continues d'utiliser la Shopify Storefront API comme source de données, mais tu ne construis pas la storefront comme un projet Hydrogen séparé. Détails sur Headless Frontend pour Shopify.
Nous avons déjà une storefront Hydrogen. C'était pour rien ? Non. Modèle de données, accès à la Storefront API et structure de contenu restent utilisables. Le changement porte sur la couche de présentation et de pilotage, pas sur l'intégration commerce.
Combien cela coûte-t-il ? Tarifs et paliers sur la page tarifs de Laioutr. Pour une comparaison face à un développement sur mesure, le détail des coûts dans l'article thème-vs-headless lié plus haut est une meilleure base qu'un prix catalogue.
Combien de temps prend la mise en œuvre ? Médiane sous 14 jours pour une première storefront avec accompagnement des fondateurs. Avec plusieurs marques ou marchés, cela dépend de tes données, pas du frontend.
Shopify reste-t-il notre backend ? Oui, aussi longtemps que tu le souhaites. C'est précisément le point : la décision reste réversible sans reconstruire le frontend.
Prochaines étapes
Si ton équipe se demande si cette reconstruction d'Hydrogen est le déclencheur de la vôtre, réserve une démo de 30 minutes sur Headless Frontend pour Shopify. Nous parcourons ton stack avec toi, et nous te dirons aussi quand Hydrogen est le bon choix pour ton cas.
Autres sujets de la plateforme Laioutr
À propos de l'auteur : Marcel Thiesies est Co-Founder de Laioutr. Il travaille chaque jour avec des équipes DACH sur la question de savoir quelle partie du stack commerce doit vraiment être remplacée et quelle partie a simplement besoin d'un meilleur pilotage.