Dans la Partie 1, nous avons fait le travail le plus difficile, celui de décider si l’on s’engageait ou non. Si vous êtes ici, c’est que vous avez parcouru le test des quatre murs et qu’au moins un mur est réel. Vous pouvez le nommer, vous pouvez chiffrer ce qu’il vous coûte, et vous pouvez désigner le levier que vous comptez actionner.
Bien. Passons maintenant au chantier. Et c’est le chantier qui fabrique concrètement le plus de regrets. Pas dans la décision elle-même, mais dans la douzaine de choix discrets qui viennent après.
Je vais vous transmettre ceci comme je le ferais avec une équipe produit en qui j’ai confiance. Commencer par la décision, nommer l’arbitrage, dérouler une séquence exécutable. Pas de murs de théorie. Allons-y.
L’architecture, et pourquoi « quel framework » est la mauvaise première question
Tout le monde veut ouvrir avec la question Hydrogen contre Next.js. C’est la deuxième question. La première, celle qui tranche réellement, est la suivante. Quel est votre degré d’engagement à rester sur Shopify, et quel est le poids de votre contenu non-commerce ? Répondez honnêtement à ces deux questions et le framework se choisit en grande partie tout seul.
Pour la plupart des marchands ayant véritablement mérité le chantier, le choix par défaut honnête en 2026 est Hydrogen sur Oxygen. Il est disponible en version générale depuis 2023, il tourne désormais sur React Router v7, qui est l’évolution de Remix, avec Vite comme outil de build, et il est en production chez des marques comme Allbirds et Gymshark. Ce n’est plus une technologie réservée aux early adopters. Elle réduit le calendrier de plusieurs semaines et abaisse la maintenance à long terme, précisément parce qu’elle cesse de lutter contre la plateforme.
Voici le recadrage le plus important, car il inverse l’instinct habituel. Sur Shopify en 2026, le couplage est la fonctionnalité, pas le compromis. Shopify a passé l’année écoulée à rendre l’intégration étroite plus rentable, et non moins. Il existe désormais un outillage conscient du schéma qui connecte directement Cursor, Claude Code et VS Code aux API de Shopify avec validation en direct, ainsi que des périmètres d’authentification anti-bots et une publication au niveau des variantes. Essayer de recréer tout cela sur un backend sur mesure entièrement découplé revient à consacrer des sprints à reconstruire ce qu’Hydrogen vous offre tout servi. Si vous vouliez le contrôle de React à l’intérieur du graphe de Shopify, Hydrogen est la réponse. Si vous vouliez échapper entièrement au graphe de Shopify, retournez relire la Partie 1.
Mon heuristique d’architecte, la même que j’applique à tout système : commencez couplé et pragmatique. Vous pouvez toujours ajouter de la complexité quand vous sentez les coutures craquer. Vous ne pouvez presque jamais la retirer une fois qu’elle est devenue porteuse.
La stack à laquelle vous vous engagez réellement
« Shopify headless » désigne un petit ensemble de briques. Connaissez chacune d’elles avant de cadrer le projet, car chacune est une ligne budgétaire et un point de défaillance potentiel.
La Storefront API, en GraphQL, est votre couche de lecture pour les produits, les collections et le contenu. C’est là que votre vitrine récupère ses données. La Storefront Cart API est l’endroit où vous créez et gérez les paniers, avant d’envoyer le client au checkout via l’URL de checkout du panier. C’est ce qui a remplacé l’ancienne Checkout API, désormais éteinte. La Customer Account API gère la connexion, l’historique des commandes et la gestion de compte pour le client identifié. Checkout Extensibility, associé à Shopify Functions, permet de personnaliser le checkout hébergé, couvrant les upsells, les champs personnalisés, la logique de remise et de livraison, sans toucher à son cœur. Functions est l’endroit où réside désormais votre logique personnalisée de remise, de livraison et de bundle. Et Oxygen est l’hébergement edge de Shopify pour Hydrogen, déployé directement depuis votre dépôt et inclus avec les forfaits payants, si bien qu’il n’y a aucun contrat d’hébergement séparé à négocier.
Intégrez un changement de mentalité, et la moitié des décisions en aval deviennent plus simples. Vous ne construisez pas une boutique. Vous construisez une application frontend qui consomme des services de commerce. Cela change la façon dont vous la staffez, dont vous la testez et dont vous la livrez, ce qui fait l’objet du reste de ce guide.
Le CMS que vous ne pouvez pas éviter
Je vais le dire aussi clairement que possible, car c’est le post-mortem headless le plus courant que je rencontre. Une boutique headless sans CMS signifie que chaque changement de contenu devient un déploiement pour les développeurs.
Imaginez le quotidien. Votre merchandiser veut lancer une collection, changer une bannière hero ou publier une landing page saisonnière. Sur Liquid, il le fait lui-même en quelques minutes. Sur une boutique headless sans couche de contenu, il ouvre un ticket, attend un développeur, attend un déploiement. La vélocité marketing s’effondre, avec des agences rapportant des baisses de 60 à 80 %, et le ressentiment se manifeste dans les réunions d’équipe. Vous aurez dépensé six chiffres pour rendre votre équipe marketing plus lente. J’ai vu ce scénario exact gâcher un lancement qui était, techniquement, une réussite complète.
Le CMS n’est donc pas optionnel. Il fait partie du chantier, et c’est la ligne budgétaire que les propositions adorent oublier discrètement. Les options réelles se résument à quelques-unes.
- Sanity est apprécié des développeurs, flexible et peu coûteux au démarrage, bien qu’il nécessite des développeurs pour modéliser le contenu.
- Contentful est de qualité entreprise, tarifé à l’usage, et monte en charge jusqu’à une complexité sérieuse.
- Storyblok propose une édition visuelle des composants que vos marketeurs peuvent réellement utiliser.
- Les éditeurs visuels natifs d’Hydrogen, comme Weaverse, sont conçus pour que les merchandisers puissent éditer sans développeur, fusionnant le CMS et le page-builder en un seul outil.
Le choix repose sur une seule question. Qui édite le contenu, et à quelle fréquence ? Si le marketing publie quotidiennement, privilégiez un éditeur visuel qu’une personne non technique peut piloter. Si le contenu est rare et structuré, un CMS orienté développeur convient très bien. Vous trompez ici, et l’architecture fonctionne parfaitement pendant que l’entreprise se grippe silencieusement.
La migration SEO, la chose à plus haut risque que vous allez entreprendre
C’est là que les bons chantiers headless meurent réellement. Pas dans l’architecture, mais dans la migration. Vous remplacez chaque URL d’un site auquel Google fait déjà confiance. Faites-le à la légère, et vous n’obtenez pas une boutique plus rapide. Vous obtenez une boutique plus rapide que personne ne peut trouver.
Voici les non-négociables, par ordre de priorité.
Premièrement, la carte de redirection est l’élément à plus haut risque de tout le projet. Chaque URL de l’ancien site a besoin d’une redirection 301 testée vers son équivalent nouveau. Construisez et testez cette carte avant le lancement, pas pendant. C’est le point de défaillance SEO le plus courant dans toute migration, headless ou non.
Deuxièmement, le rendu côté serveur est obligatoire. Hydrogen et Next.js font tous deux du SSR, et les moteurs de recherche doivent recevoir du HTML entièrement rendu. Livrer une vitrine uniquement côté client en 2026 relève de la faute professionnelle, et aucune équipe compétente ne le fait.
Troisièmement, les données structurées sont désormais votre responsabilité. Les thèmes Shopify natifs génèrent automatiquement le JSON-LD des produits et collections. Le headless ne le fait pas, vous devez donc le construire vous-même. C’est simple, et cela ne doit pas être sauté. Dans un monde de découverte agentique, sur lequel nous allons revenir, les données structurées ne relèvent plus de la simple hygiène SEO. C’est ainsi que les machines lisent votre catalogue.
Quatrièmement, les Core Web Vitals sont un facteur de classement. Le plafond de performance que vous avez payé est aussi un levier SEO, mais seulement si vous l’atteignez réellement.
Traitez la migration comme son propre projet, avec son propre responsable, sa propre checklist et sa propre porte de décision go/no-go. Ce n’est pas une tâche de semaine de lancement.
L’horloge de conformité, les échéances qui cassent les boutiques discrètement
C’est la partie qu’on ne met jamais sur la diapositive romantique du headless, et c’est celle qui vous réveille à 3 heures du matin. Shopify est en train de repenser sa couche de checkout, et les échéances sont réelles, séquentielles et dangereusement faciles à confondre. Les confondre est l’erreur de planification la plus coûteuse qu’une boutique Plus puisse commettre en ce moment.
Commençons par checkout.liquid, désormais obsolète. Les pages d’information, de livraison et de paiement devaient migrer vers Checkout Extensibility avant le 13 août 2024. Les pages de remerciement et de statut de commande devaient migrer avant le 28 août 2025 pour les boutiques Plus, les boutiques non-Plus disposant jusqu’au 26 août 2026. Shopify a mis à niveau automatiquement les boutiques qui n’avaient pas migré, ce qui signifie que le code de checkout personnalisé restant et les Additional Scripts cessent simplement de s’afficher. Le symptôme le plus insidieux est que vos pixels post-achat et votre analytique se cassent discrètement, et cela ressemble à des publicités sous-performantes jusqu’à ce que quelqu’un finisse par creuser dans les données.
Vient ensuite la piste séparée du passage de Shopify Scripts vers Shopify Functions. Celle-ci a sa propre échéance. Scripts sera discontinué le 30 juin 2026. Si votre boutique utilise Scripts pour des combinaisons de remises, une livraison échelonnée, une tarification B2B ou une logique de bundle, cette logique cesse de fonctionner le 1er juillet 2026. Le chemin de migration passe par Functions, écrit en JavaScript ou en Rust. Si vous n’avez pas encore commencé, c’est très probablement votre point ouvert le plus urgent au moment où vous lisez ceci.
Derrière tout cela se trouve la norme PCI DSS v4, qui explique en grande partie pourquoi tout cela arrive. L’ancien modèle d’injection de scripts bruts ne pouvait pas répondre aux normes modernes de sécurité des paiements. Le modèle hébergé, basé sur l’extensibilité, est la voie conforme, ce qui est une raison de plus de ne pas vouloir posséder le checkout.
Pour un chantier headless en particulier, votre architecture doit reposer sur le checkout hébergé par Shopify via l’URL de checkout, avec Checkout Extensibility et Functions pour toute personnalisation. Tout plan qui s’appuie discrètement sur une personnalisation du checkout héritée est déjà cassé. Auditez ce point dès le premier jour du cadrage, pas en QA.
L’équipe et le modèle opérationnel, le coût que personne ne chiffre
Une vitrine headless est une application vivante. Elle a besoin d’un responsable qui a un pouls, pas d’un lancement suivi d’une poignée de main.
La vérité brute des post-mortems est qu’une boutique Hydrogen sans un ingénieur React senior à temps plein, ou un contrat d’agence engagé, devient un passif. Les mises à jour s’enlisent, les fonctionnalités qui prenaient des semaines commencent à prendre des trimestres, le backlog grossit, et la boutique que vous avez construite pour sa souplesse devient la chose la plus lente que vous possédiez. Avant de commencer, forcez une vraie réponse à trois questions.
- Qui livre le code ? Nommez la capacité d’ingénierie, qu’il s’agisse de talents React seniors en interne ou d’un studio sous contrat retenu. « On trouvera une solution » n’est pas une réponse.
- Qui fait le merchandising ? C’est la décision du CMS rendue concrète. Quels humains éditent quoi, sans déploiement.
- Qui est responsable de la carte de redirection, des données structurées, des Core Web Vitals et des échéances de conformité ? Ce sont des tâches qui n’appartiennent à personne jusqu’à ce qu’elles deviennent un incident. Assignez-les maintenant, nommément.
C’est aussi là que réside le coût réel. Le chantier est le chiffre visible. La propriété est le coût récurrent. Le headless convertit une part de votre dépense de plateforme en une dépense d’ingénierie permanente. Si cet arbitrage n’a pas de levier de revenu derrière lui, vous n’aviez pas de mur. Vous aviez un souhait. Je continue à vous renvoyer vers la Partie 1 parce que c’est là que vit la discipline.
Construire pour la découverte agentique, la raison propre à 2026 qui a tout changé
J’ai signalé cela comme un mur dans la Partie 1. Voici la réalité de la mise en œuvre, car c’est discrètement la partie la plus stratégique de tout l’exercice.
La frontière de la découverte se déplace. Shopify permet désormais aux vitrines Hydrogen de se connecter au Storefront MCP, ce qui signifie construire des agents d’achat IA directement dans votre boutique, capables de recommander des produits, remplir des paniers et guider les clients à partir de données produit et client en direct. Séparément, Shopify Catalog rend les produits découvrables au sein d’assistants IA comme ChatGPT et Perplexity, ouvrant un canal qui n’existait pas il y a deux ans.
Ce que cela signifie pour le chantier se résume à trois points. Des données structurées et API-first cessent d’être une simple hygiène pour devenir de la distribution. La même discipline de JSON-LD propre et de Storefront API qui aide le SEO est ce qui permet à une machine de lire, recommander et transiger avec votre catalogue, et les architectures headless sont structurellement mieux positionnées pour cela que les boutiques Liquid assemblées à la va-vite. La vitesse devient un facteur de découverte, et pas seulement d’UX, parce que le trafic agentique pénalise les boutiques lentes et désordonnées plus durement que les humains. Un bot n’attend pas poliment. Et vous devriez concevoir dès maintenant votre couche de données pour des lecteurs non humains, en traitant la question de savoir si un agent IA peut comprendre et agir sur votre vitrine comme une exigence de premier plan plutôt qu’un agrément de phase deux.
C’est le seul endroit où je me laisserai aller à sonner comme un futuriste. Les marchands qui construisent aujourd’hui des vitrines headless propres et structurées n’achètent pas seulement un site plus rapide. Ils achètent un site lisible, lisible par les intermédiaires IA qui vont de plus en plus se placer entre vos produits et vos clients. C’est une raison authentique de passer au headless, et elle n’avait tout simplement aucun poids en 2023.
Le plan par phases, comment mener ce chantier sans désastre big-bang
S’il y a une chose tactique à retenir de ce guide, c’est celle-ci. Ne faites pas de migration headless en big-bang. L’approche la plus intelligente est incrémentale. Remplacez d’abord la surface à plus forte valeur, prouvez-la, puis étendez. Gardez le checkout intouché pendant toute la durée.
La Phase 0 consiste à mériter le chantier et à prouver que la correction bon marché est épuisée. Passez le thème Liquid propre au crible de la vitesse. Auditez les applications, les images et les scripts. Confirmez que le mur est réel et que le gain n’est pas qu’une question d’hygiène. Obtenez un alignement écrit entre le marketing, l’ingénierie et la direction sur le mur, son coût et le levier. Le critère de sortie est un enregistrement de décision d’une page, signé par tous.
La Phase 1 consiste à décider et à réduire le risque. Verrouillez trois éléments : l’architecture (avec Hydrogen et Oxygen par défaut), le CMS (choisi selon qui édite quoi) et l’hébergement. Auditez l’horloge de conformité et la migration Scripts vers Functions. Construisez la carte de redirection ainsi que le plan de SSR et de données structurées en tant que livrables, pas en tant qu’intentions. Le critère de sortie est une carte de redirection rédigée et testée en staging, chaque élément de conformité étant assigné à un responsable et à une date.
La Phase 2 consiste à livrer une seule surface. Choisissez la surface où le mur fait le plus mal. C’est souvent les pages produit et collection pour un mur d’expérience, ou une surface d’atterrissage à fort trafic pour un mur de performance. Construisez-la en headless, connectez-la à la Storefront API, gardez tout le reste sur Liquid et gardez le checkout sur Shopify. Le critère de sortie est que la nouvelle surface bat l’ancienne sur la métrique que vous avez nommée, c’est-à-dire la conversion, pas Lighthouse.
La Phase 3 consiste à étendre délibérément. Migrez les surfaces suivantes seulement une fois que chacune a fait ses preuves. Maintenez la carte de redirection et les données structurées en continu. Faites monter les merchandisers sur le CMS et confirmez qu’ils peuvent publier sans vous. Le critère de sortie est que la vélocité marketing est égale ou supérieure à ce qu’elle était avant la migration.
La Phase 4 consiste à construire pour l’avenir. Vous investissez maintenant dans les éléments qui justifiaient l’architecture au départ : le configurateur, la préparation à la découverte agentique, la composabilité multi-surfaces. C’est là que le plafond que vous avez payé se transforme enfin en revenus.
Les pièges, et comment les éviter
J’ai vu les mêmes erreurs se répéter sur suffisamment de chantiers pour les nommer.
Passer au headless pour un problème qu’un passage de vitesse aurait résolu. Six chiffres dépensés pour corriger des pages lentes qui étaient lentes à cause de la surcharge d’applications et d’images non optimisées. La Phase 0 est non négociable : épuisez la correction bon marché et mesurez avant de vous engager.
Oublier le CMS. Chaque changement de contenu devient un déploiement et la vélocité marketing s’effondre. Cadrez le CMS comme faisant partie du chantier, choisi selon qui édite quoi.
Traiter la migration comme une tâche de semaine de lancement. Pas de carte de redirection, classements perdus, trafic qui chute après le lancement. La migration est son propre projet, avec son propre responsable et sa propre porte go/no-go. La carte de redirection d’abord.
Confondre les deux échéances de conformité. L’équipe migre checkout.liquid et suppose que Scripts est également géré, puis la logique de remise se casse le 1er juillet 2026. Suivez Checkout Extensibility et la migration Scripts vers Functions comme deux chantiers séparés avec deux dates séparées.
Lancer sans responsable nommé. La boutique est livrée, l’agence se retire, et il n’y a aucun ingénieur senior pour la maintenir. Confirmez la propriété continue avant de commencer. Pas de responsable, pas de chantier.
Mesurer la mauvaise chose. L’équipe célèbre un score Lighthouse vert pendant que la conversion reste plate. Définissez la métrique de succès en termes d’affaires dès le départ, et tenez le chantier à cette exigence.
Mesurer le succès, à quoi ressemble réellement le succès
Vous ne pouvez pas améliorer ce que vous ne mesurez pas, et « le site semble plus rapide » n’est pas une mesure. Tenez le chantier à des chiffres, sur trois couches : la couche technique, la couche d’expérience et la couche business retardée.
Si les chiffres retardés ne bougent pas, le chantier n’a pas mérité son coût, et vous devez le savoir tôt plutôt qu’à la prochaine revue budgétaire. Suivez les trois dès le lancement.
La décision go/no-go d’une page à remplir avant de dépenser quoi que ce soit
Volez cette idée. C’est l’enregistrement de décision que j’exigerais avant d’approuver un chantier headless, modelé sur un simple Architecture Decision Record, la même discipline que j’applique à tout choix technique conséquent.
La décision : passer au headless sur Hydrogen et Oxygen, Next.js ou autre. Oui ou non.
Le mur : lequel des quatre murs (Expérience, Performance, Composabilité, Découverte) nous bloque ? Nommez-le en une phrase.
Le coût du mur : que nous coûte-t-il aujourd’hui, en argent ou en vélocité ? Si nous ne pouvons pas le chiffrer, nous ne l’avons pas atteint.
Le levier : quel indicateur précis espérons-nous faire bouger, et de combien approximativement ?
La correction bon marché : avons-nous d’abord épuisé le passage de vitesse Liquid et le CRO ? Quelle en est la preuve ?
La propriété : qui livre le code ? Qui fait le merchandising sans déploiement ? Qui est responsable des redirections, des données structurées, des Core Web Vitals et des échéances de conformité ?
Le budget, honnêtement : le chantier, plus l’ingénierie continue, plus Shopify Plus, plus le CMS, plus l’intégration. Le levier compense-t-il ce coût en 24 à 36 mois ?
L’horloge de conformité : sommes-nous à jour vis-à-vis de l’ancien checkout.liquid, et notre migration Scripts vers Functions est-elle terminée avant le 30 juin 2026 ?
Si vous pouvez remplir cette page avec confiance, vous ne devinez plus. Vous décidez. Et cela, bien plus que le choix du framework, est ce qui sépare les marchands qui obtiennent un avantage concurrentiel de ceux qui reçoivent une leçon coûteuse.
Conclusion : le guide entier en trois phrases
Le Shopify headless n’est pas un site web plus rapide. C’est une réarchitecture que vous payez pour un problème que vous pouvez nommer. Le chantier est un ensemble de décisions discrètes, à savoir l’architecture, le CMS, la migration, la conformité et la propriété, et c’est dans chacune d’elles que se fabrique réellement le regret ou l’avantage.
Choisissez couplé et pragmatique, gardez le checkout sur Shopify, livrez de façon incrémentale, et construisez pour un monde où les machines lisent aussi votre boutique. Faites cela, et le headless cesse d’être une promesse dont vous espérez qu’elle rapporte. Il devient un levier que vous actionnez délibérément.
Le marché n’a pas besoin de davantage de marques dotées de superbes vitrines headless qu’elles ne peuvent pas maintenir. Il a besoin de davantage de marchands qui sont passés au headless pour une raison qu’ils pouvaient nommer.
Soyez l’un d’entre eux.