Insight · Headless commerce
Dans une refonte headless, le goulot n'est pas le front — c'est le modèle de contenu
On choisit un CMS headless sur sa grille de fonctionnalités, puis on découvre que le vrai travail était ailleurs : décider ce qu'est une page, et comment le marketing publie sans passer par un développeur. Modéliser le contenu est le chantier le plus sous-estimé d'une refonte.
Publié le 20 août 2026 · 8 min de lecture · Sergio Nokam
La conversation sur le choix d’un CMS headless commence presque toujours par une comparaison d’outils. On aligne les grilles de fonctionnalités, on compare les modèles de tarification, on regarde qui propose la meilleure interface d’édition. Cette conversation est légitime, mais elle arrive trop tôt d’environ deux semaines. Car dans la quasi-totalité des refontes que j’observe, le poste qui décide réellement du calendrier n’est ni le choix de l’outil ni la reconstruction du front : c’est le travail, invisible et ingrat, consistant à décider ce qu’est une page.
Ce travail porte un nom sobre — la modélisation de contenu — et il souffre d’un défaut rédhibitoire pour obtenir de l’attention : il ne produit rien qu’on puisse montrer en réunion. Il n’a pas d’interface, pas de capture d’écran, pas de démonstration. Il consiste à écrire une liste de types, de champs et de relations. Et pourtant, c’est de cette liste que découlent la charge de reprise de données, l’autonomie future de l’équipe marketing, et la capacité du site à évoluer sans redéploiement.
Les trois désordres qu’on trouve toujours dans l’existant
Le point de départ est toujours le même : l’information existante n’est pas structurée, elle est rendue. Dans un thème classique, une fiche produit est un mélange de champs natifs de la plateforme, de métachamps ajoutés au fil des années, de blocs de texte enrichi collés dans la description, et parfois de tableaux HTML écrits à la main. Le tout produit un affichage correct, ce qui masque le désordre sous-jacent.
Ouvrir cet existant réserve trois surprises récurrentes.
La première est la représentation multiple de la même notion. Le guide des tailles existe en tableau HTML sur les fiches de 2021, en image sur celles de 2023, et en métachamp structuré sur les plus récentes. Aucune de ces trois formes n’est fausse ; simplement, aucune API ne peut les servir de manière uniforme.
La deuxième est le champ fourre-tout. Il y a presque toujours un métachamp nommé info_supplementaire ou équivalent, dont le contenu s’est diversifié au point de contenir 5 natures d’information différentes selon la fiche. Le décomposer suppose de lire le catalogue, pas de programmer.
La troisième est la page unique. Une, deux, parfois 5 pages ont été construites à la main parce qu’elles ne rentraient dans aucun gabarit — la page de la campagne des Fêtes, la page de partenariat, l’histoire de la marque. Elles ne représentent rien statistiquement et elles consomment un temps disproportionné, parce que chacune pose la question de savoir si l’on modélise un type pour un seul objet.
| Désordre trouvé | Exemple typique | Ce que ça coûte à la reprise |
|---|---|---|
| Représentation multiple | Guide des tailles en tableau HTML, en image, puis en métachamp | Une transformation par variante historique |
| Champ fourre-tout | Un métachamp contenant 5 natures d’information | Lecture manuelle du catalogue avant de programmer |
| Page unique | Page de campagne construite hors gabarit | Modéliser un type pour un seul objet, ou renoncer |
La tension centrale : contraindre la structure, libérer le contenu
La décision structurante d’une modélisation tient dans un arbitrage unique, et les deux erreurs symétriques sont également coûteuses.
Un modèle trop rigide définit des types serrés qui correspondent exactement aux besoins connus au moment de la refonte. Il produit une base de données propre et une équipe marketing dépendante : la moindre page de campagne qui sort du cadre exige une intervention de développement, donc un ticket, donc un délai, donc à terme un contournement. Six mois après la mise en ligne, l’équipe éditoriale publie ses opérations sur une plateforme tierce parce que le site est trop lent à faire évoluer.
Un modèle trop permissif fait l’erreur inverse. Il offre un constructeur de pages à blocs libres, où l’éditeur assemble ce qu’il veut. L’autonomie est totale le premier mois. Au 6e mois, il existe 11 variantes de la même section de mise en avant, la charte visuelle a dérivé, et la performance s’est dégradée parce que personne ne contrôle plus ce qui est chargé sur une page donnée.
Le point d’équilibre que je vise est le suivant : la structure est contrainte, le contenu est libre. Les types de pages sont fermés et peu nombreux. À l’intérieur de chaque type, l’éditeur dispose d’un jeu de blocs autorisés, chacun avec des champs typés et des règles de validation. Il peut tout dire ; il ne peut pas tout construire.
Un bon modèle de contenu ne se juge pas à ce qu’il permet, mais à ce qu’il empêche. Ce qu’il empêche, c’est la dérive silencieuse qui rend un site illisible en 18 mois.
La prévisualisation, dette technique déguisée en confort
Il existe un moment précis, dans chaque refonte headless, où l’équipe éditoriale comprend ce qu’elle a perdu. C’est la première fois qu’elle veut vérifier à quoi ressemblera une page avant de la publier.
Dans un système couplé, cette question ne se pose pas : le CMS et le rendu sont la même chose. En headless, ils sont séparés par construction, et la prévisualisation doit être bâtie explicitement — un mode de rendu qui interroge les brouillons plutôt que le contenu publié, une route protégée, une invalidation de cache adaptée. Ce n’est pas difficile, mais ce n’est pas gratuit, et ça ne se fait pas tout seul.
Une équipe privée de prévisualisation fiable adopte un comportement prévisible : elle publie en production pour voir, corrige, republie. Ce qui annule le bénéfice du flux éditorial et introduit un risque réel sur un site marchand. Je considère donc la prévisualisation comme une exigence de niveau un, à valider pendant le choix de l’outil et à livrer dans le premier lot — pas comme un raffinement de fin de projet.
Le multilingue décide plus de choses qu’il n’y paraît
Pour une marque canadienne, la question linguistique n’est pas une option de configuration. Elle a des conséquences directes sur le modèle.
Il faut trancher, type par type, ce qui est traduit et ce qui est partagé. Une fiche produit a un nom et une description traduits, mais un prix, un stock et un identifiant partagés. Une page éditoriale peut n’exister que dans une langue — et le modèle doit représenter cette absence explicitement, sinon le site produira des liens vers des pages qui n’existent pas. Il faut aussi décider si les identifiants d’URL sont traduits, ce qui affecte le routage, les redirections et le balisage d’alternance linguistique.
Ces décisions sont faciles à prendre au moment de la modélisation et coûteuses à changer ensuite, parce qu’elles touchent simultanément la base de contenu, le routage et le référencement.
Le vrai poste variable : la reprise de données
Reste le chantier dont la charge dépend entièrement de la qualité de l’existant et que le modèle permet enfin d’estimer. Migrer le contenu, ce n’est pas copier des champs. C’est écrire des transformations qui prennent un désordre historique et produisent une structure. Extraire un guide des tailles d’un tableau HTML. Décomposer un champ fourre-tout en trois champs typés. Réconcilier trois conventions de nommage.
Cette charge est le poste le plus variable de tout le projet — j’ai vu des écarts d’un facteur 5 entre deux catalogues de taille comparable. C’est précisément pourquoi l’audit doit précéder le chiffrage : sans lui, ce poste est deviné, et un projet dont le poste le plus variable est deviné n’a pas de date. Il rejoint là les cinq autres postes qui font glisser un calendrier de migration Hydrogen.
Sur la manière dont ce chantier s’articule aux autres causes de dérapage d’une migration, j’ai détaillé le calendrier ailleurs1.
Dans quel ordre mener une refonte headless
Je résume la séquence que je défends, parce qu’elle inverse l’ordre habituel.
D’abord auditer l’existant et écrire le modèle : types, champs, relations, règles de traduction. Ensuite, seulement, choisir l’outil — et le choisir contre ce modèle, en vérifiant qu’il sait représenter ces types précis, gérer ces langues précises, offrir cette prévisualisation précise. Enfin, construire, avec la reprise de données chiffrée sur des observations plutôt que sur une intuition.
Cette séquence a un mérite qui dépasse le confort méthodologique : elle transforme le choix du CMS, qui est habituellement une décision de goût défendue par des arguments de plaquette, en une décision documentée qu’on peut justifier trois ans plus tard. Et elle place le travail difficile au début du projet, là où il coûte des jours, plutôt qu’au milieu, où il coûte des semaines.
Footnotes
-
Sur les autres postes qui font glisser le calendrier d’une refonte — écosystème d’applications, refonte graphique couplée, latence de décision — voir Pourquoi la plupart des migrations Hydrogen prennent six mois au lieu de quatre-vingt-dix jours. ↩
Questions fréquentes
Faut-il choisir le CMS avant ou après avoir modélisé le contenu ?
Après, systématiquement. Modéliser d'abord permet de choisir un outil sur des critères vérifiables — cet outil sait-il représenter mes types réels, gérer mes langues, offrir la prévisualisation dont mes éditeurs ont besoin. Choisir d'abord conduit à plier le modèle aux contraintes de l'outil, ce qui produit des compromis qu'on paiera pendant des années. La modélisation demande quelques jours ; elle transforme un choix d'outil subjectif en décision documentée.
Quel est le signe qu'un modèle de contenu est mal conçu ?
Le meilleur indicateur est le nombre de fois où l'équipe marketing doit demander une modification à un développeur pour une opération purement éditoriale. Si publier une page de campagne exige un déploiement, le modèle est trop rigide. À l'inverse, si les éditeurs peuvent construire n'importe quelle page en assemblant des blocs libres, le modèle est trop permissif et la cohérence visuelle se dégradera en quelques mois. Le bon modèle contraint la structure et libère le contenu.
La prévisualisation est-elle vraiment un sujet critique ?
Oui, et c'est le point sur lequel une refonte headless déçoit le plus souvent des équipes venues d'un thème classique. Dans un CMS couplé, l'éditeur voit la page telle qu'elle sera. En headless, le rendu est produit ailleurs, et la prévisualisation doit être construite explicitement. Une équipe éditoriale privée de prévisualisation fiable perd en autonomie ce que la refonte prétendait lui apporter, et finit par contourner l'outil.
Combien de temps prend la modélisation de contenu d'une boutique existante ?
Sur un catalogue mid-market avec quelques années d'historique, il faut compter 2 à 4 jours pour l'audit et 1 à 2 semaines pour la modélisation validée, en incluant les arbitrages éditoriaux. C'est peu à l'échelle d'un projet de trois mois, mais ce travail doit se faire avant le chiffrage : il détermine la charge de reprise de données, qui est le poste le plus variable de tout le projet.