Agence Front et architectures headless
Le front n'est plus une couche de présentation posée sur un CMS. C'est la pièce qui tient la performance, le référencement, l'accessibilité et l'interopérabilité d'un produit. Voici comment nous le concevons, et pourquoi nous choisissons rarement la technologie la plus récente.
Une pratique devenue standard, que nous avons adoptée tôt
Le découplage du front et du back n'a plus rien d'une originalité. De WordPress à Adobe, en passant par la plupart des plateformes e-commerce, presque tous les éditeurs ont ouvert leurs API et permettent aujourd'hui de servir leurs contenus à une interface indépendante. Le headless est devenu une bonne pratique de place, pas un pari technologique.
Ce qui nous distingue, c'est le moment où nous l'avons adoptée. Nous travaillons ainsi depuis l'apparition de ces architectures, parce qu'elles répondaient à une exigence que nous avions déjà : la performance web. Séparer le front du back, c'est reprendre la main sur ce qui est envoyé au navigateur, sur le moment où c'est calculé et sur ce qui est mis en cache. Nous n'avons pas suivi une tendance, nous avons trouvé un outil pour un problème que nous connaissions bien.
Une posture agnostique, et assumée
Nous ne nous précipitons pas sur les nouvelles technologies. Le critère de choix n'est pas la modernité mais la pérennité : taille de la communauté, cycle de support annoncé, capacité à recruter sur cette technologie dans trois ans, coût de sortie.
Un framework choisi pour son élégance puis abandonné deux ans plus tard coûte bien plus cher qu'un socle ennuyeux et documenté. Nous préférons une technologie que d'autres équipes savent reprendre, y compris les vôtres.
Front
Styling
Back
Données
Infrastructure
Services
Ce que headless veut dire concrètement
Trois principes suffisent à décrire l'architecture, et ils ont chacun des conséquences très concrètes sur l'exploitation.
Le contenu vit dans son propre service
Le CMS, le PIM ou l'ERP exposent leurs données par API et ne décident plus de l'affichage. Chaque système reste responsable de ce qu'il sait faire.
Le front décide seul de son rendu
Rendu serveur, génération statique ou régénération incrémentale, choisis page par page selon ce que le moteur de recherche et l'utilisateur doivent voir.
Les deux évoluent séparément
Changer de CMS sans refaire le site devient possible, et refondre le site sans toucher au CMS l'est tout autant.
La contrepartie est réelle : plus de pièces à opérer, un cache à penser, une chaîne de build à maintenir. Le headless n'est pas gratuit, il déplace la complexité.
Dix points sur lesquels nous ne transigeons pas
- 1
Architecture dimensionnée
Le modèle de données, les flux et les volumes sont posés avant la première ligne de code.
- 2
Interopérabilité
L'API est un contrat versionné et documenté, pas un tuyau que l'on branche au dernier moment.
- 3
Performance web
Les Web Vitals sont un critère de conception, pas une optimisation de fin de projet.
- 4
Référencement technique
Le mode de rendu est choisi page par page, selon ce que les moteurs doivent réellement voir.
- 5
Éco-conception
Les Web Sustainability Guidelines s'appliquent au poids des pages et au nombre de requêtes.
- 6
Accessibilité
Elle est tenue dans les composants eux-mêmes, elle n'est pas rattrapée pendant la recette.
- 7
Approche composants
Chaque élément d'interface est écrit une fois, documenté, puis réutilisé partout.
- 8
Design system
La même bibliothèque fait référence côté design et côté code, sans écart toléré.
- 9
DevOps et intégration continue
Chaque livraison est automatisée, testée et rejouable à l'identique.
- 10
Tests
Tests unitaires, tests de bout en bout et recette fonctionnelle, sur chaque livraison.
Quand le headless n'est pas le bon choix
L'architecture se choisit sur le contexte d'exploitation, pas sur la réputation de la technologie.
Terrain favorable
- Catalogue important ou fortement structuré.
- Plusieurs canaux à servir : site, application, marketplace, extranet.
- Système d'information existant à interconnecter.
- Exigences fortes de performance et de référencement.
- Produit destiné à durer plusieurs années.
Terrain défavorable
- Site vitrine de quelques pages, sans aucune intégration.
- Organisation sans capacité d'exploitation technique.
- Besoin de valider une idée avant d'investir, cas où le no-code répond mieux.
- Budget qui ne couvre pas l'exploitation dans la durée.
Questions fréquentes
Vous voulez passer à la mise en œuvre ?
Le déroulé de mission, les livrables et les modalités d'intervention sont détaillés sur notre page prestation.
Voir la prestation développementFront et architectures headless : principes, technologies et arbitrages
Une architecture headless sépare le service qui détient la donnée du front qui l'affiche. Le CMS, le PIM ou l'ERP exposent leurs contenus par API, et l'interface décide seule de la manière dont elle les restitue. Cette séparation n'est pas une mode : elle répond au fait qu'un même catalogue doit aujourd'hui alimenter un site, une application, un extranet et parfois une marketplace.
Notre posture technologique est volontairement agnostique. React, Next.js, Angular, Vue.js et les PWA côté front, Laravel et Symfony côté back, MySQL et PostgreSQL pour les données, Docker, Kubernetes, AWS et Azure pour l'infrastructure, GraphQL, Strapi, WordPress, Algolia ou Firebase pour les services. Le critère n'est jamais la nouveauté : c'est la pérennité, la documentation disponible et la facilité à recruter sur la technologie retenue dans trois ans.
Le mode de rendu est une décision de conception à part entière. Rendu serveur, génération statique ou régénération incrémentale se choisissent page par page, en fonction de la fraîcheur attendue et de ce que les moteurs doivent voir. C'est là que se joue une grande partie du référencement technique, en lien direct avec la performance et l'éco-conception du produit.
Un front headless ne vit jamais isolé. Il consomme des API, s'adosse à un modèle d'échanges avec le système d'information et suppose des contrats stables entre les équipes. De la même manière, la qualité de l'interface repose sur une bibliothèque de composants partagée, ce que nous traitons dans notre approche du design system, et sur une accessibilité tenue dans les composants plutôt que rattrapée en recette.
Enfin, le passage au headless s'inscrit souvent dans un projet plus large de changement de plateforme. Dans ce cas, la question n'est pas seulement technique : reprise des URL, migration des contenus, continuité du référencement et montée en compétence des équipes internes pèsent autant que le choix du framework.
Newsletter Agence Wex
Recevez nos derniers articles, retours d'expérience et bonnes pratiques UX directement dans votre boîte mail.
Désinscription possible à tout moment. Pas de spam, pas de revente de données.
Ce formulaire est protégé par reCAPTCHA : la politique de confidentialité et les conditions d'utilisation de Google s'appliquent.