Pourquoi la plupart des migrations Hydrogen prennent 6 mois au lieu de 90 jours

Le chiffre revient dans presque toutes les conversations de cadrage que j’ai avec des marques qui envisagent de quitter un thème Liquid : la migration devait durer un trimestre, elle en a duré deux, parfois trois. La conclusion qu’on en tire est généralement fausse. On accuse Hydrogen d’être immature, React d’être verbeux, l’agence d’avoir sous-estimé. Dans les faits, le développement de la vitrine est la partie la plus prévisible de l’opération, et c’est rarement elle qui glisse. Ce qui fait exploser le calendrier se joue ailleurs, dans des zones que le chiffrage initial n’a pas regardées parce qu’elles n’avaient pas l’air techniques.

Je pose d’emblée la thèse, parce qu’elle conditionne tout le reste : 90 jours sont tenables si, et seulement si, le projet est un portage. Reconstruire en Hydrogen une boutique dont la charte, l’arborescence et le modèle de données restent inchangés est un travail borné, estimable, et que j’ai vu tenir. Le même délai devient une fiction dès qu’on y ajoute un seul des trois chantiers que les organisations ont l’habitude de coupler à une migration. Le reste de cet essai décrit les six endroits où le temps disparaît, par ordre décroissant de dégât.

L’écosystème d’applications est le premier gouffre

Une boutique Shopify Plus mature tourne rarement avec moins de 20 applications installées. Avis clients, abonnements, fidélité, upsell au panier, recherche, bandeaux promotionnels, popups de collecte d’adresses, suivi de livraison, gestion des retours. Chacune a été ajoutée à un moment où elle résolvait un problème réel, et l’accumulation n’a jamais été auditée.

Le point que presque personne n’anticipe est le suivant : une part importante de ces applications fonctionne en injectant du script dans le thème Liquid. Elles s’installent en modifiant le rendu que Shopify produit. Or, en Hydrogen, Shopify ne rend plus la vitrine. Le mécanisme d’injection n’existe tout simplement plus. Chaque application concernée entre alors dans l’une de trois catégories : elle expose une API propre et peut être réintégrée proprement ; elle n’en expose pas et doit être réimplémentée à la main ; ou elle est abandonnée, ce qui suppose une décision métier que le développeur n’a pas autorité pour prendre.

Sur une boutique à 25 applications, il n’est pas rare que 8 survivent telles quelles, 10 demandent un travail d’intégration significatif, et 7 posent une question qu’il faut remonter au marketing. Ces 7 questions sont le vrai chemin critique. Elles ne se résolvent pas en écrivant du code ; elles se résolvent en obtenant un arbitrage d’une personne occupée.

L’inventaire de cet écosystème demande 3 jours. Le produire avant de chiffrer change le chiffre. Le découvrir en semaine six coûte un mois.

La refonte graphique greffée en chemin

Le deuxième gouffre est organisationnel, et il est presque toujours consenti de bonne foi. La direction raisonne ainsi : puisqu’on reconstruit la vitrine de toute façon, autant en profiter pour moderniser le design. L’argument paraît imparable. Il double pourtant la durée du projet, pour une raison qui tient moins à la quantité de travail qu’à la nature de l’incertitude.

Un portage est un projet à cible connue. On sait à quoi le résultat doit ressembler : à ce qui existe. La validation est binaire et rapide — la page de collection se comporte-t-elle comme avant, oui ou non. Une refonte est un projet à cible négociée. Chaque écran devient un objet de discussion, les allers-retours se multiplient, et le calendrier ne dépend plus de la vélocité de l’équipe technique mais du rythme des validations internes.

Coupler les deux, c’est faire dépendre une date d’engagement technique d’un processus de décision esthétique. Je recommande systématiquement de les séquencer : porter d’abord à iso-design, mesurer, puis refondre sur une base saine. La marque qui accepte cette séquence livre en 3 mois puis itère ; celle qui les couple livre en 7.

Une migration headless n’est pas un projet de développement. C’est un projet de désaccouplage d’un écosystème que personne n’a cartographié depuis cinq ans. Le code est la partie facile.

Le modèle de contenu, découvert trop tard

Le troisième poste est le plus insidieux, parce qu’il ne se voit pas depuis l’extérieur. Dans un thème Liquid, une quantité considérable d’information vit dans des endroits qui ne sont pas structurés : des blocs de texte enrichi collés dans une description produit, des sections de page d’accueil configurées dans l’éditeur de thème, des métachamps créés au fil de l’eau sans convention de nommage, parfois des tableaux HTML écrits à la main par une personne partie depuis.

Reconstruire la vitrine impose de rendre cette information adressable par une API. C’est-à-dire de la modéliser. Et modéliser du contenu existant, c’est découvrir que la même notion est représentée de quatre façons différentes selon l’époque à laquelle la fiche a été créée. Le travail n’est pas difficile ; il est long, il exige des arbitrages produit, et il ne peut pas être parallélisé au-delà d’un certain point.

Un audit de modèle de contenu avant chiffrage coûte 2 à 3 jours et déplace ce risque du milieu du projet vers son début. C’est, avec l’inventaire d’applications, le meilleur investissement de la phase de cadrage.

Les intégrations tierces qui n’apparaissent sur aucun schéma

Vient ensuite la couche des systèmes qui parlent à Shopify sans que personne n’y pense : l’ERP qui synchronise les stocks, le PIM qui pousse les fiches, l’outil d’expédition qui lit les commandes, le service de gestion des retours, le connecteur comptable. La plupart de ces flux passent par des webhooks ou par l’API Admin, et à ce titre ils survivent à une migration de vitrine — c’est une bonne nouvelle qu’il faut dire clairement.

Le problème naît des exceptions. Il existe presque toujours un ou deux flux qui, pour des raisons historiques, dépendent du rendu du thème : un script qui lit une valeur dans le DOM, un pixel personnalisé placé dans une page de confirmation, un connecteur qui scrute une URL au format précis. Ces cas sont rares mais leur détection est difficile et leur correction imprévisible. Ils justifient à eux seuls de conserver une marge dans le calendrier.

La parité SEO traitée comme une phase deux

Le cinquième poste est celui dont le coût est différé, donc systématiquement sous-estimé. Une migration change les gabarits, souvent les URL, parfois la structure de l’arborescence. Sans un plan de redirection exhaustif, sans une transposition fidèle des données structurées, sans une vérification des balises canoniques et du rendu côté serveur, le trafic organique se dégrade — et il se dégrade avec un délai qui empêche de faire le lien immédiatement.

Le traiter comme un chantier de fin de projet est un choix qui se retourne. Je le considère comme une contrainte de conception, au même titre que la performance : on ne migre pas une page tant que sa redirection et son balisage ne sont pas définis. J’ai détaillé ailleurs la mécanique de cette parité¹ ; le point à retenir ici est calendaire. Intégrée dès le début, elle coûte quelques jours répartis. Reportée à la fin, elle produit une phase de rattrapage de 3 à 6 semaines, sous la pression désagréable d’une courbe de trafic qui baisse. Le détail de cette parité — plan de redirection, transposition des données structurées, ordre de bascule — fait l’objet d’un essai dédié sur le replatforming sans perte de trafic organique.

La latence de décision, qu’aucun devis ne chiffre

Reste le facteur dont on ne parle jamais parce qu’il est gênant : le temps que met l’organisation cliente à trancher. Les sept questions issues de l’audit d’applications, les arbitrages de modèle de contenu, la validation des redirections, le choix de conserver ou non telle fonctionnalité marginale — chacune de ces décisions est rapide à prendre et lente à obtenir.

Sur un projet de 90 jours, j’observe régulièrement que 15 à 20 jours ouvrés sont consommés en attente de décisions, pas en production de travail. Ce n’est pas une critique du client ; c’est une propriété des organisations. Mais c’est un poste qui doit apparaître dans le calendrier, avec un interlocuteur unique nommé et un rythme d’arbitrage convenu à l’avance. Un projet qui n’a pas désigné cette personne a déjà commencé à glisser.

Le coût de chaque poste, selon le moment où on le découvre

Poste	Coût si audité au cadrage	Coût si découvert en cours de projet
Écosystème d’applications	3 jours d’inventaire	3 à 5 semaines
Refonte graphique couplée	0 jour — décision de séquencement	+3 à 4 mois
Modèle de contenu	2 à 3 jours d’audit	2 à 4 semaines
Intégrations tierces	1 jour de cartographie	1 à 2 semaines
Parité SEO	coût réparti, contrainte de conception	3 à 6 semaines de rattrapage
Latence de décision	1 interlocuteur nommé, délai convenu	15 à 20 jours ouvrés perdus

Ces ordres de grandeur sont ceux que j’observe sur des catalogues mid-market ; ils varient, mais le rapport entre les deux colonnes, lui, est stable. Aucun de ces postes n’est difficile. Tous deviennent coûteux au même moment : quand on les découvre après avoir annoncé une date.

Ce qui tient réellement en 90 jours

Si l’on soustrait la refonte graphique, si l’on a inventorié les applications et le modèle de contenu avant de chiffrer, si la parité SEO est une contrainte de conception plutôt qu’une phase finale, et si une personne est mandatée pour trancher sous 48 heures, alors ce qui reste — reconstruire les gabarits, brancher la Storefront API, câbler le panier, tenir un budget de performance — est un travail borné qui tient dans un trimestre.

La question à poser avant de s’engager sur une date n’est donc jamais « combien de temps pour migrer ». C’est : combien de décisions non tranchées reste-t-il dans ce périmètre. Le nombre de jours en découle. Et c’est aussi pourquoi je refuse de chiffrer une migration sans avoir produit d’abord l’inventaire : sans lui, le chiffre est une hypothèse déguisée en engagement, et l’écart entre les deux finit toujours par se payer d’un côté ou de l’autre de la table.

---

Footnotes

1. Sur le détail de la parité technique lors d’un changement de plateforme — plan de redirection, transposition des données structurées, ordre de bascule — voir l’essai Replatforming : ne pas perdre son trafic organique. ↩