Headless Experience Conf’ 2026 : 5 enseignements clés sur les architectures front-end

Le 19 mars dernier, Kaliop organisait la 3ᵉ édition de la Headless Experience Conf’, consacrée aux enjeux du front-end dans les architectures headless et composables.

À travers plusieurs prises de parole et différents types de formats (table ronde, retours d’expérience, analyses d’architecture et éclairages techniques), cette matinée a permis de mettre en perspective les choix structurants auxquels sont confrontés les CTO, architectes et équipes produit.

Nous en avons dressé les principaux enseignements dans cet article.

1. Le front-end est devenu un sujet d’architecture à part entière

Dans les architectures headless, le front-end n’est plus une simple couche de restitution.

Il devient :

• un point de convergence des flux (API, microservices, CMS),
• un lieu de gestion de la complexité fonctionnelle,
• un levier direct sur la performance et le SEO.

Qu’il s’agisse du choix de framework, du mode de rendu ou encore de la gestion des flux de données, ces décisions ont des impacts directs sur :

• la performance,
• la maintenabilité,
• la capacité d’évolution des plateformes.

Le front-end devient une pièce centrale du système, et non plus un simple paramètre. Il doit être pensé comme une brique à part entière de l’architecture, avec les mêmes exigences que le back. De plus, les retours d’expérience présentés lors de la conférence confirment un point : les choix front-end engagent sur le long terme.

2. Le composable permet de transformer à l’échelle… mais introduit de la complexité

Le cas Interflora illustre une transformation à grande échelle : en cinq ans, un écosystème fragmenté, composé d’un ensemble de plateformes par Business units, a été rationalisé autour d’une plateforme e-commerce unifiée, capable de servir ces différentes Business Units tout en intégrant des spécificités locales.

Cette trajectoire repose sur une architecture composable et headless, un modèle qui repose sur :

• un core model commun,
• l’intégration de systèmes hétérogènes grâce à une architecture orientée microservices,
• un déploiement progressif à l’international, tout en intégrant des spécificités locales (SI ou métier).

Mais ce modèle implique aussi une complexité accrue et des choix techniques structurants dès le départ. Le composable est un accélérateur, mais nécessite une discipline d’architecture forte. Bien maîtrisée, la migration opérée par le groupe Interflora a permis d’accélérer le déploiement de nouveaux pays et de mutualiser les développements.

3. Les choix de rendu ne sont pas neutres

Plusieurs interventions ont mis en lumière un point clé : le mode de rendu (client-side vs server-side) conditionne fortement la trajectoire technique.

Dans le cas d’Interflora, le choix initial d’un rendu côté client, pertinent dans un contexte donné, est aujourd’hui réinterrogé au regard :

• des contraintes SEO,
• de la performance,
• de la complexité fonctionnelle.

Avec le recul, une approche intégrant davantage de server-side rendering apparaît plus adaptée pour absorber les exigences du web. Mais cela dépend des contextes techniques, métier et business de chaque projet. Le CSR peut être pertinent dans certains contextes, mais dans le cadre d’une complexité métier croissante, il peut être un facteur de fragilité.

Les choix d’architecture front-end doivent être pensés en fonction des contraintes réelles du produit, pas uniquement des opportunités technologiques.

4. Moderniser implique de remettre en question son existant

Le cas Kinougarde présenté dans cette matinée de conférences illustre une situation fréquente dans les organisations : un socle WordPress, historiquement pertinent, perd en pertinence et devient un outil décalé par rapport aux besoins.

L’enjeu n’était pas tant la technologie elle-même que la manière dont elle était utilisée. Le modèle monolithique, combinant front et back, s’est avéré de moins en moins adapté à un contexte où l’expérience utilisateur, la capacité d’évolution et le multi-site devenaient structurants. Dans les faits, la richesse de l’écosystème WordPress — notamment ses plugins — était peu exploitée côté front, car les interfaces étaient largement sur mesure. Le CMS servait principalement de back-office, sans réelle valeur ajoutée côté rendu.

C’est ce décalage qui a motivé la transition vers une approche headless et Back for Front. En séparant clairement le front et le CMS, Kinougarde a pu reprendre le contrôle de l’expérience utilisateur et s’affranchir des contraintes liées au modèle initial. Le choix d’une stack Strapi + Next.js a permis de structurer un environnement plus modulaire, plus lisible et plus adapté à une logique multi-marques.

Au-delà du changement technologique, cette évolution a surtout permis de rétablir une cohérence entre les outils utilisés et les objectifs poursuivis.

5. Le choix du framework est un arbitrage contextualisé, pas une standardisation

Le cas Kinougarde met en évidence un arbitrage fréquent : faut-il capitaliser sur les compétences existantes ou choisir le framework le plus adapté à l’usage ?

L’organisation disposait déjà d’une base Angular solide, utilisée pour ses applications métier. Dans une logique d’optimisation des ressources et de mutualisation des compétences, il aurait été naturel de prolonger ce choix sur les projets web. Pourtant, cette option a été remise en question.

L’analyse menée a fait apparaître une distinction importante : si Angular répond efficacement aux besoins des applications métier, il se révèle moins adapté à des problématiques propres au web, notamment en termes d’expérience utilisateur, de flexibilité et d’écosystème. À l’inverse, React, et en particulier son framework Next.js, offrait un cadre plus pertinent pour adresser ces enjeux.

Ce choix n’a pas été neutre. Il impliquait d’introduire un nouvel écosystème technique, sans compétence interne initiale, et donc de s’appuyer sur un partenaire capable d’accompagner cette montée en maturité.

Mais c’est précisément ce point qui en fait un enseignement intéressant : le bon choix technique n’est pas toujours celui qui s’inscrit dans la continuité de l’existant.

Ce type de décision souligne un point essentiel :

• un framework adapté à des applications métier ne l’est pas nécessairement pour un front web,
• la cohérence technique ne doit pas primer sur la pertinence d’usage.

Il s’agit donc avant tout de choisir une technologie adaptée à l’usage, quitte à accepter un effort initial plus important pour construire une base plus solide et plus durable.

Cette 3ᵉ édition de la Headless Experience Conf confirme une évolution de fond : les architectures front-end sont désormais au cœur des décisions stratégiques des organisations.

Les retours d’expérience partagés montrent que la modernisation est une trajectoire, pas un projet ponctuel, que les choix d’architecture doivent être régulièrement réévalués, il n’en existe pas parfaits, et surtout ils doivent être alignés avec les usages réels et les enjeux business du produit.

Moderniser son architecture, ce n’est pas suivre une tendance. C’est construire une trajectoire cohérente, capable d’évoluer.