Shopify Hydrogen ou Next.js : quelle stack headless choisir en 2026 ?

Si vous lisez cet article, vous avez déjà décidé que le headless est sur la table. La vraie question : sur quelle stack vous engager. Shopify pousse Hydrogen comme la voie officielle. L'écosystème React tire les équipes vers Next.js. Les deux livreront une boutique rapide. Elles ne sont pas interchangeables pour autant.

Cet article est la version longue d'une conversation que nous avons chaque mois avec des fondateurs et des CTO : où chaque framework gagne réellement, où il pose problème six mois plus tard, et comment nous tranchons sur une mission Sentinu.

La réponse courte

Si votre boutique se résume à "catalogue Shopify, pages marketing, checkout", sans autre backend commerce dans l'équation, Hydrogen est le choix par défaut en 2026. L'intégration à la Storefront API, les primitives de cache et le runtime Oxygen sont taillés exactement pour ce profil de projet.

Si votre backend est hétérogène (PIM séparé, couche marketplace, inventaire multi-régions tiré d'un ERP, site marketing largement plus important que la boutique, ou base de code Next.js existante), Next.js est le bon choix par défaut, avec Shopify positionné comme une source de données parmi d'autres.

Tout ce qui suit, c'est le raisonnement derrière ces deux phrases.

Ce qu'est réellement Hydrogen en 2026

Hydrogen est le framework React de Shopify, actuellement construit sur Remix (et donc sur les data APIs de React Router v7). Il embarque :

• Un client storefront typé branché sur la Storefront API
• Un SSR en streaming avec des loaders par route
• Une couche de cache (CacheLong, CacheShort, CacheNone, stratégies personnalisées) intégrée au runtime
• Un déploiement first-party sur Oxygen, la plateforme edge à isolats V8 de Shopify
• Des helpers panier et checkout qui gèrent les parties stateful pénibles du commerce
• Une intégration optionnelle à la Customer Account API pour l'authentification headless

L'élément clé à comprendre : Hydrogen n'est pas "Next.js avec un SDK Shopify pré-installé". C'est un framework opinionated sur la façon de parler à la Storefront API, sur le cache des réponses GraphQL, et sur le déploiement. Ces opinions sont majoritairement correctes pour un projet Shopify-first, et elles vous coûtent en flexibilité dès que le projet ne l'est pas.

// Loader Hydrogen : typé, mis en cache, natif edge runtime
export async function loader({ context, params }) {
  const { product } = await context.storefront.query(PRODUCT_QUERY, {
    variables: { handle: params.handle },
    cache: context.storefront.CacheLong(),
  });

  if (!product) throw new Response(null, { status: 404 });
  return { product };
}

La ligne cache: CacheLong() est tout l'intérêt. Vous n'écrivez pas votre propre logique ISR, votre propre SWR, votre propre couche Redis. Vous utilisez un runtime qui comprend "ceci est une page produit, voici comment Shopify veut qu'elle soit mise en cache".

Ce que Next.js offre que Hydrogen n'a pas

Next.js (App Router, 15+) est agnostique de la plateforme. Shopify n'est qu'une des N sources de données possibles. Cette neutralité est à la fois la feature et le bug.

Ce que vous gagnez :

• N'importe quelle source de données, n'importe quel provider d'auth, n'importe quel CMS, n'importe quel CDN
• Un écosystème massif de patterns, de middleware et d'options d'hébergement (Vercel, Cloudflare, AWS, Node auto-hébergé)
• Server Components, Server Actions, Partial Prerendering, et la R&D la plus active du monde React sur les stratégies de rendu
• Un vivier de recrutement plus large (chaque développeur React connaît Next, moins connaissent Hydrogen)

Ce que vous abandonnez :

• Vous écrivez la couche d'intégration Shopify vous-même. Invalidation du cache sur update produit, revalidation pilotée par webhook, gestion du rate-limit Storefront API, contenu draft vs published : rien n'est gratuit. Nous avons vu des équipes passer deux sprints à reconstruire ce que CacheLong() offre en Hydrogen.
• État du panier et du checkout. Hydrogen a des helpers. En Next.js vous gérez vous-même le cookie d'ID panier, les mutations Storefront API et la chorégraphie de redirection vers le checkout Shopify.
• L'intégration Customer Account API. Faisable en Next.js, considérablement plus de travail.

Face à face sur ce qui compte vraiment

Rendu et performance

Les deux frameworks peuvent livrer des boutiques avec un LCP sous la seconde. La question est de savoir combien de travail il faut pour y arriver.

En pratique, les deux peuvent atteindre un profil Core Web Vitals vert. La différence apparaît dans la maintenance, six mois plus tard, quand quelqu'un doit invalider le hero de la home après une modif marketing. En Hydrogen, c'est un webhook plus un cache tag. En Next.js, c'est la même idée mais vous câblez vous-même.

SEO et indexabilité

C'est l'objection la plus fréquente des fondateurs qui hésitent sur le headless : "Google ne va-t-il pas avoir du mal avec une boutique React ?" Non, si c'est fait correctement. Les deux frameworks rendent côté serveur par défaut. Les deux produisent du HTML que Googlebot crawle dès le premier passage sans exécuter JavaScript.

Là où le risque SEO se loge réellement :

• Hreflang et routage international. Hydrogen propose un pattern clair avec des routes imbriquées par locale. Next.js vous donne du routage par locale via middleware. Les deux fonctionnent, les deux peuvent être mal configurés.
• Gestion des canonicals pendant une migration. C'est là que les boutiques perdent réellement du trafic. Aucun framework ne vous sauve d'une mauvaise table de redirections.
• Données structurées. Même effort dans les deux cas, vous écrivez le JSON-LD vous-même.
• Génération du sitemap. Hydrogen a une convention de route. Next.js a app/sitemap.ts. Les deux conviennent.

Si vous migrez depuis un thème Liquid, le risque SEO est dans la stratégie de redirections et la structure d'URL, pas dans le framework de rendu. Nous traitons ce sujet dans notre guide de migration Shopify.

Hébergement et déploiement

C'est la partie la plus sous-estimée de la décision.

Hydrogen tourne au mieux sur Oxygen. Oxygen est intégré à l'admin Shopify, fait des previews de déploiement par branche, et le runtime à base d'isolats V8 n'a pas de cold start. Vous pouvez techniquement déployer Hydrogen ailleurs, mais vous perdez la plomberie cache et vous sortez du chemin supporté. Pour un projet Shopify-first, ce verrouillage est acceptable parce que la plateforme qui vous verrouille est la même que celle qui fait tourner votre checkout.

Next.js tourne partout. Vercel est le chemin de moindre résistance et celui contre lequel Next est conçu. Cloudflare Workers devient de plus en plus viable. Du Node auto-hébergé derrière un load balancer marche mais vous perdez beaucoup des features edge-aware du framework. AWS via OpenNext fonctionne mais vous maintenez maintenant du code d'infrastructure.

La vraie question : voulez-vous un seul vendor (Shopify, via Oxygen et la Storefront API) ou deux (Shopify pour le commerce, Vercel/Cloudflare pour le front) ? Deux vendors, c'est plus de levier et plus de surface à maintenir.

Expérience développeur et recrutement

Avis honnête, six mois à faire tourner les deux stacks en production :

• Onboarding Hydrogen : un développeur React expérimenté en Shopify est productif en une semaine. Un développeur React pur sans contexte Shopify met deux à trois semaines pour comprendre le modèle de cache et la Storefront API.
• Onboarding Next.js : n'importe quel développeur React moderne est immédiatement productif sur le framework. Le code d'intégration Shopify est ce qu'il doit apprendre, et ce code est de la responsabilité de votre équipe.
• Marché du recrutement : Next.js gagne en volume brut d'ingénieurs disponibles. Hydrogen gagne en qualité d'adéquation pour un projet Shopify.

Quand Hydrogen montre ses limites

C'est un framework honnête, pas un framework parfait. Les cas où nous avons sorti un projet d'Hydrogen ou déconseillé d'y entrer :

• La boutique n'est qu'un consommateur parmi d'autres pour un backend commerce qui n'est pas que Shopify
• Le contenu pèse beaucoup plus que le commerce (une marque média avec une petite boutique annexe)
• L'équipe n'a aucun contexte Shopify et un deadline strict qui n'autorise pas la montée en compétence
• Vous avez besoin de fonctionnalités de rendu que Hydrogen n'expose pas encore proprement (patterns PPR très spécifiques, exigences de streaming exotiques)
• Vous devez déployer sur une infrastructure que votre équipe sécurité contrôle, sans option Oxygen

Quand Next.js montre ses limites

Tout aussi honnête. Cas où Next.js est le mauvais choix pour une boutique Shopify :

• Vous êtes en train de reconstruire à la main les primitives Hydrogen parce que personne ne veut maintenir une couche de cache custom
• L'équipe est petite et vous passez plus de temps sur la plomberie que sur le produit
• Vous voulez des coûts par requête prévisibles et la tarification d'Oxygen est matériellement meilleure pour votre profil de trafic
• Vous voulez que le support Shopify puisse réellement vous aider quand quelque chose casse au niveau du runtime

Une grille de décision que nous utilisons réellement

Pour cadrer un projet headless chez Sentinu, nous notons quatre axes de 0 à 3 et laissons le total trancher :

1. Centralité de Shopify : Shopify est-il le seul backend commerce (3), l'un des deux (1), ou l'un parmi beaucoup (0) ?
2. Fluence Shopify de l'équipe : profonde (3), familière (1), nulle (0) ?
3. Équilibre contenu vs commerce : surtout commerce (3), équilibré (1), surtout contenu (0) ?
4. Contraintes d'infrastructure : Oxygen acceptable (3), neutre (1), interdit (0) ?

Score 8 ou plus : Hydrogen. Score 5 ou moins : Next.js. La bande du milieu (6 à 7) est l'endroit où la vraie conversation a lieu, et où la réponse dépend généralement des plans de recrutement et de l'intégration custom déjà en place ailleurs dans l'entreprise.

Ce que nous livrons chez Sentinu

Les deux, avec un défaut marqué vers Hydrogen pour les projets Shopify-first. Engagements récents :

• Une marque D2C de mode sur Hydrogen + Oxygen, LCP sous 800ms sur toutes les PDP, hreflang sur trois locales
• Un catalogue B2B de pièces industrielles sur Next.js + Shopify Plus, parce que le PIM était la source de vérité et Shopify en aval
• Une migration d'un thème Liquid vers Hydrogen pour une marque dont l'équipe technique comptait deux ingénieurs expérimentés en Shopify et un deadline Core Web Vitals strict

Nous n'avons pas de préférence religieuse. Nous avons une checklist, et la checklist tranche habituellement avant que le fondateur ait fini de décrire le projet.

FAQ

Hydrogen est-il prêt pour la production en 2026 ?

Oui. La version basée sur Remix est stable, déployée sur des milliers de boutiques Shopify Plus, et les APIs de cache et Customer Account ont nettement mûri. L'ancien "v1" d'Hydrogen basé uniquement sur Vite est déprécié, ne démarrez pas un nouveau projet dessus.

Puis-je faire tourner Hydrogen sur Vercel au lieu d'Oxygen ?

Techniquement oui, en pratique vous sortez du chemin supporté et vous perdez le cache intégré d'Oxygen. Pour un projet sérieux nous nous engageons sur Oxygen ou nous utilisons Next.js. Le chemin du milieu est le pire des deux mondes.

Next.js donne-t-il un meilleur SEO qu'Hydrogen ?

Non. La performance SEO vient de la stratégie de rendu et de la rigueur, pas du choix de framework. Les deux livrent du HTML rendu côté serveur par défaut. Les deux peuvent être mal configurés.

Que penser de Shopify Hydrogen v2 face à v1 ?

Hydrogen v2 (basé sur Remix, désormais à l'ère React Router v7) est la seule version sur laquelle nous recommandons de démarrer aujourd'hui. v1 est en fin de vie. Si vous êtes sur v1, planifiez une migration sur le prochain cycle trimestriel.

Shopify va-t-il continuer à investir dans Hydrogen ?

Hydrogen est le framework React officiel, Oxygen est un produit Shopify first-party, et les annonces axées storefront aux événements Shopify Edition pointent toutes vers la même stack. Le risque que Shopify abandonne est faible. Le risque que le framework évolue et impose du travail de migration est réel, comme pour tout framework activement développé.

Combien de temps prend un build Hydrogen face à un build Next.js sur le même périmètre ?

Selon notre expérience, un projet Hydrogen pour une boutique Shopify-first se livre 15 à 25 pour cent plus vite que l'équivalent Next.js, principalement parce que vous n'écrivez pas la couche d'intégration Shopify. Cet écart se referme si l'équipe a une grosse expérience Next.js et zéro expérience Shopify.

Pour aller plus loin

Si vous évaluez un rebuild headless, les deux pages à lire après celle-ci sont notre présentation des services Shopify Headless pour l'approche d'ingénierie, et notre page optimisation de la vitesse Shopify pour mesurer les gains après mise en ligne.

Si vous préférez sauter la lecture et avoir une conversation d'architecture de trente minutes, c'est pour cela que nous sommes là.