Un site headless sépare strictement deux choses : le « head » (l'interface visible — pages HTML, app mobile, écran en magasin) et le back-end qui sert le contenu via une API (REST ou GraphQL). Là où WordPress ou Shopify mélangent stockage et rendu, une archi headless utilise un CMS headless (Sanity, Strapi, Contentful) côté contenu, et un framework moderne comme Next.js côté front. Le contenu devient une donnée structurée que vous pouvez consommer où vous voulez.
L'intérêt principal est triple. Performance : le front est généré en SSG ou ISR et servi depuis un CDN edge — résultat, des Core Web Vitals au vert sans optimisation héroïque. Multi-canal : le même contenu nourrit votre site, votre app mobile, votre newsletter, votre kiosque magasin. Évolutivité : vous pouvez changer de front sans toucher au contenu, ou inversement. C'est l'approche Jamstack appliquée au contenu éditorial.
Le coût d'entrée est plus élevé qu'un WordPress vanilla — il faut un dev front compétent, et un CMS qui peut tourner sur 50€/mois (Sanity) ou en self-hosted (Strapi). En contrepartie : zéro maintenance plugin, sécurité bien meilleure (pas de surface d'attaque PHP/admin exposée), et un workflow éditorial moderne. On le recommande à partir de 30-50 pages, ou dès qu'il y a un besoin multi-canal. Pour voir si c'est pertinent chez vous, regardez nos sites sur-mesure ou demandez un audit gratuit.
Quand choisir une archi headless
- Vous avez plusieurs canaux (web, app, in-store, partenaires) qui consomment le même contenu.
- Vous voulez des performances maximales : SSG + CDN edge, LCP sous 1,5 s, scores Lighthouse 95+.
- Votre équipe contenu veut un back-office moderne sans toucher au front (preview en temps réel, schémas typés, versioning).
- Vous prévoyez de changer de front dans 2-3 ans (rebrand, migration mobile) sans tout reconstruire.
