Nous sommes fin juillet. Le Black Friday tombe le 27 novembre 2026, le Cyber Monday le 30. Cela semb…
Qui construit le frontend ? Les rôles dans une équipe composable
Demandez à dix personnes d'une équipe commerce qui possède le frontend et vous obtenez dix réponses différentes. Le marketing dit que c'est l'équipe dev. La dev dit que c'est le design system. Le product owner dit que cela dépend de la roadmap. Dans un stack composable commerce, ce n'est pas une question de responsabilité mineure, c'est le véritable goulot d'étranglement. Le frontend n'a pas de propriétaire unique. Il en a quatre, et la valeur n'apparaît qu'une fois qu'il est clair qui détient quelle partie.
Cet article est le point d'entrée de la vue par rôle : quels quatre rôles touchent au frontend, où la propriété se casse dans un setup classique, et comment une Frontend Management Platform (FMP) sépare la responsabilité proprement au lieu de la pousser dans une file de tickets.
Pourquoi le frontend n'a pas de propriétaire unique
Dans une boutique monolithique, la réponse était simple : le frontend appartenait au backend. Langage de template, couche de thème et logique métier vivaient dans le même système, et celui qui maintenait le système maintenait la storefront. Le composable inverse cela. Le frontend devient sa propre couche, découplée du backend, connectée à plusieurs systèmes via une couche de données. Ce découplage est précisément le gain, car il permet de remplacer le backend sans reconstruire la storefront. Il crée aussi une question ouverte que le monolithe n'a jamais eu à poser : si le frontend n'appartient plus à personne dans le backend, à qui appartient-il ?
La réponse honnête est que quatre rôles se le partagent. Et tant que ce partage n'est pas énoncé, il se remplit de la réponse par défaut de toute équipe technique : tout ce qui touche au frontend devient un ticket développeur. C'est exactement là que les équipes composables ralentissent au lieu d'accélérer.
Les quatre rôles qui touchent au frontend
Une storefront n'est pas construite par une seule personne. Elle est construite par une chaîne de décisions prises par quatre rôles distincts.
Le marketing et l'e-commerce possèdent la sortie : pages de campagne, landing pages, mise en scène des catégories, refontes saisonnières, l'ordre concret des blocs sur une page. Ce rôle est mesuré au chiffre d'affaires et travaille en jours, pas en sprints. Ce dont il a besoin, c'est de pouvoir composer une page et la publier sans attendre une fenêtre de release. La perspective par rôle se trouve sur Laioutr pour les Marketing Managers.
Le product owner possède la priorisation : quels templates existent, quelles fonctionnalités viennent ensuite, où se situe la ligne entre un bloc standard et un cas particulier. Ce rôle traduit entre le souhait métier et la réalité technique, et décide de ce qui appartient au système de composants et de ce qui reste un cas isolé.
Le développement possède les fondations : les composants eux-mêmes, la connexion des données, les garde-fous à l'intérieur desquels tous les autres travaillent. Ce rôle ne construit pas chaque page, il construit le système à partir duquel les pages sont construites. Quand ces fondations sont propres, l'équipe cesse de bloquer les développeurs pour des changements de bannière. La vue de ce rôle se trouve sur Laioutr pour les Developers.
L'architecture possède le contrat : comment la couche de données normalise les backends, comment les thèmes et les design tokens restent cohérents entre marques et marchés, comment le frontend reste rapide et accessible par défaut. Ce rôle est rarement visible dans le travail quotidien sur les pages, mais il décide si tout le modèle tient sur plusieurs storefronts.
Deux rôles adjacents s'ajoutent à ceux-ci, autonomes ou intégrés aux quatre ci-dessus selon la taille de l'équipe. La rédaction maintient le contenu dans le contexte live, voir Laioutr pour les Content Managers, et la partie orientée conversion teste et optimise, voir Laioutr pour les CRO Specialists. Le handoff du design system lui-même appartient aux UX/UI Designers, où tokens et composants doivent passer entre design et code sans perte.
Où la propriété se casse dans un setup classique
La rupture habituelle n'est pas de la mauvaise volonté, c'est une séparation manquante. Dans un frontend custom-build classique, il n'y a pas de ligne nette entre "c'est un bloc que le marketing assemble lui-même" et "c'est du code qui nécessite un ticket de développement". Parce que la ligne manque, tout se déplace du côté sûr : dans le ticket. Un changement de titre, une nouvelle page de campagne, une réorganisation de l'ordre des catégories, tout atterrit dans la même file que le vrai travail de fonctionnalité.
Le résultat est une double perte. Le marketing attend une capacité qu'il ne peut pas contrôler, et le développement passe du temps sur un travail que personne n'appellerait vraiment de l'ingénierie. Nous avons décrit comment ce bouchon se résorbe une fois la séparation en place : du goulot d'étranglement dev au flux frontend dans toute l'équipe. Le point central pour cet article est plus simple : une propriété floue coûte plus cher que n'importe quelle décision technique isolée dans le stack.
Comment une FMP sépare la responsabilité proprement
Une Frontend Management Platform ne résout pas le problème de propriété en faisant d'un rôle le chef de tous les autres. Elle le résout en donnant à chaque rôle sa propre couche, sans chevauchement. Le principe est un contrat entre le développement et les rôles métier.
Le développement définit les composants et les garde-fous une fois : ce qui compte comme bloc autorisé, quels slots il possède, quelles données il tire. Le marketing et la rédaction composent des pages à partir de ceux-ci dans un éditeur live avec aperçu, sans toucher au code et sans bloquer une release. L'architecture possède la couche de données en dessous qui normalise les backends, et la couche de thème qui garde marques et marchés cohérents. Chaque rôle travaille dans sa couche, et aucun n'attend l'autre pour le travail de routine.
C'est exactement l'idée derrière le Frontend as a Service : studio, storefront, couche de connexion et cloud fonctionnent comme un seul système géré où la séparation des responsabilités est intégrée plutôt que renégociée à chaque projet. Si vous voulez situer le terme lui-même, nous avons décrit ce qu'est réellement le Frontend as a Service séparément. Au niveau de la plateforme, la même idée est la Composable Digital Experience Platform : une couche frontend qui se place au-dessus de chaque backend et réunit les quatre rôles en un seul endroit, sans les forcer dans la même file.
La répartition de la propriété en une phrase par rôle
Si vous voulez ancrer le modèle dans une équipe, une phrase par rôle suffit. Le développement possède les composants et les garde-fous. Le product owner possède ce qui appartient au système et dans quel ordre. Le marketing et l'e-commerce possèdent la composition et la mise en ligne des pages. L'architecture possède la couche de données et le contrat de thème entre marques et marchés. Personne n'attend quelqu'un d'autre pour faire son travail central. C'est le test qui indique si la propriété est propre.
FAQ
Qui devrait posséder le frontend dans une équipe composable ? Aucun rôle unique. Le développement possède les composants et les garde-fous, le marketing et l'e-commerce possèdent la composition et la mise en ligne des pages, le product owner possède la priorisation, l'architecture possède la couche de données et le contrat de thème. L'erreur est de tout confier à un seul rôle, généralement l'équipe dev par défaut via la file de tickets.
Qu'est-ce qu'une Frontend Management Platform change à la répartition des rôles ? Elle rend la séparation explicite. Le développement définit composants et règles une fois, et les rôles métier composent des pages à partir de ceux-ci dans un éditeur live. Les changements de routine ne nécessitent plus de ticket de développement, et le développement récupère du temps pour le vrai travail système.
Une petite équipe a-t-elle vraiment besoin de quatre rôles distincts ? Les quatre rôles sont des responsabilités, pas quatre personnes. Dans une petite équipe, une personne peut porter plusieurs rôles. L'important est que les responsabilités soient nommées, afin que tout ne devienne pas par défaut un ticket développeur.
Prochaines étapes
Si la question "qui construit ça au juste" revient à chaque nouvelle page, ce n'est pas un problème d'effectifs, c'est une répartition de propriété manquante. Le moyen le plus rapide de la tester est de regarder le niveau plateforme où les rôles sont déjà séparés. Consultez les tarifs de la plateforme ou parlez-nous de ce à quoi cette répartition ressemblerait dans votre setup précis.