Architecte CMS headless
1Modélisation contenu, choix CMS cible (Strapi, Drupal headless, Directus, WP+WPGraphQL), conception API, design system
Loading...
Loading...
Migration d'un CMS classique (WordPress, Drupal, Joomla) vers une architecture headless : back CMS (Strapi, Drupal headless, Directus) + front SPA (Next.js, Astro), SEO et performances préservés.
Chaque phase regroupe une ou plusieurs des dix étapes ATLAS. Aucune phase ne démarre tant que la précédente n'a pas livré son artefact validé. La méthodologie ATLAS rend la migration AS/400 prévisible et auditable.
Inventaire complet des URLs sources, des contenus, des intégrations tierces (CRM, ESP, paiement). Cartographie hreflang multi-langues. Audit Core Web Vitals baseline. Définition du périmètre prioritaire et choix CMS cible (Strapi, Drupal headless, Directus, WP+WPGraphQL). Table de redirections 301 source/cible validée par le SEO.
Atelier de modélisation contenu : distinction entités métier (Article, Auteur, Catégorie) vs composants présentation (Hero, Bloc CTA), normalisation des relations. Capture des workflows éditoriaux existants, identification des plugins WordPress / modules Drupal à remplacer ou intégrer.
Conception de l'API content optimisée : une page = un seul appel, pas en cascade. Design system frontend (composants, design tokens). Budget performance fixé (LCP < 2,5 s, CLS < 0,1, INP < 200 ms). Préparation des tests de non-régression sur les workflows critiques.
Build front SPA (Next.js ou Astro), configuration CMS headless cible, migration des contenus depuis le monolithe, intégration CRM/ESP/paiement, previews live activés, tests de parité visuelle sur jeux de pages représentatifs.
Cutover production avec table 301 activée sur .htaccess ou middleware. Formation éditeurs sur 2 sessions (avant + 2 semaines après). Monitoring Search Console quotidien sur 90 jours, alerte sur baisse d'impressions ou de positions. Mesure temps de publication post-cutover (cible : ≤ baseline).
Les outils de conversion automatique de code legacy produisent du code qui compile, mais qui reste illisible et non maintenable : les patterns d'origine sont recopiés tels quels, sans idiomatisation, avec des dépendances à une runtime propriétaire. Mis en production sans re-caractérisation complète, ce code n'est ni fiable ni évolutif. La traduction automatique de bout en bout n'est pas une méthode de modernisation — c'est un transfert de dette.
Notre méthode est inverse. ATLAS repose sur plusieurs lectures du code legacy, menées selon plusieurs angles : flux de données, règles métier, dépendances, cas limites. L'IA intervient ici comme accélérateur de compréhension — pour déchiffrer des décennies de logique métier accumulée, rétro-documenter des branches non commentées, expliciter l'intention derrière le code. Elle ne décide pas et ne traduit pas : elle éclaire le travail de l'architecte, qui conçoit ensuite l'architecture cible (cloud, base de données, services) et pilote la migration pattern par pattern, sous audit de parité.
Cette compréhension exige encore des humains qui connaissent les langages legacy. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite des développeurs mainframe et legacy, la Tunisie conserve un vivier de développeurs expérimentés (COBOL, Delphi, PowerBuilder, RPG…). Couplés à des architectes et développeurs modernes formés à la méthode ATLAS, ils assurent la continuité entre l'intention métier d'origine et le système cible.
Médias et portails d'actualité dont la dette front-end pèse sur le temps de publication. Marques multi-sites et multi-marchés qui empilent les instances WordPress ou Drupal pour gérer plusieurs pays. Acteurs publics et institutionnels qui maintiennent des sites bilingues complexes (français/arabe, français/anglais) où la performance et l'accessibilité sont auditées. Dans tous ces cas, le couplage fort front/back devient un frein : chaque évolution de présentation impose un cycle complet de release CMS, et la stack legacy bloque la modernisation des fronts mobile et applicatif.
Trois forces poussent : (1) la pression Core Web Vitals depuis 2021 — un site monolithique peine à passer le seuil LCP < 2,5 s sans refonte profonde du rendu ; (2) le multi-canal — site web, app mobile, écrans en magasin, voice — partagent le même contenu, ce qu'un CMS monolithique ne sait pas exposer proprement ; (3) la fin de vie de plugins critiques (WordPress notamment) qui force une décision : refonte WordPress ou bascule headless. Le headless permet de découpler le rythme front (rapide, design system) du rythme back (gouvernance contenu, sécurité).
Pour un site vitrine simple sans multi-canal et sans équipe technique dédiée, un WordPress optimisé reste plus économique. Pour une équipe éditoriale sans appui dev, le headless complique l'autonomie (pas de WYSIWYG natif sur le front). Pour un e-commerce avec workflow merchandising lourd, certaines plateformes monolithiques (Shopify, Magento) gardent l'avantage. Le headless n'est pas une réponse universelle : il s'impose quand le multi-canal, les performances ou la liberté front justifient l'investissement.
Le site access-international.dev est passé de WordPress à une architecture headless (Next.js 16 + static export) le 23 avril 2026. Repères factuels : 135 pages bilingues (66 FR + 66 EN + pages utilitaires), sitemap de 124 URLs avec hreflang complet FR/EN, 51 redirections 301 WordPress→Next.js intégrées au `.htaccess` Plesk pour préserver chaque ancien chemin. Audit SEO post-migration 91/100, sécurité 92/100 (HSTS preload, headers durcis). 31 OG images générées via Playwright à partir d'un template HTML paramétrable. Les crawlers IA (GPTBot, ClaudeBot, PerplexityBot) sont explicitement autorisés dans le `robots.txt`. Cette migration est notre propre démonstration : nous appliquons sur notre site la méthodologie ATLAS que nous proposons aux clients. Pas de claim théorique — le résultat est mesurable et accessible à l'audit.
CMS headless + front SPA (Next.js, Astro)
Quand l'équipe a une culture JS et veut un back CMS léger, extensible, déployable sur Cloudflare/Vercel/AWS. Pas de dépendance PHP.
Quand on capitalise sur une expertise Drupal existante (modules, permissions, workflows éditoriaux) et qu'on veut garder le back tout en modernisant le front.
Quand le contenu est structuré comme une vraie base de données et que l'équipe veut une API REST/GraphQL générée automatiquement, sans abstraction CMS lourde.
Quand WordPress est déjà en place et qu'on veut une transition douce — on garde le back WP, on bascule le front sur Next/Astro, on ajoute une couche GraphQL.
8 à 16 semaines selon le volume de contenus à migrer (de 100 à 5 000 pages), le nombre d'intégrations tierces (CRM, ESP, paiement) et la maturité du design system. Équipe type : 1 chef de projet, 2 développeurs front (Next.js ou Astro), 1 développeur API/CMS, 1 référent SEO sur la phase de migration.
Préservation SEO mal cadrée — la migration change la structure d'URL, casse des redirections, ou modifie le rendu serveur de manière subtile. Résultat fréquent dans la littérature : pertes de rankings de 20 à 40 % sur les six mois suivant le cutover, parfois jamais récupérées.
Cartographie complète des URLs sources et cibles avant tout développement, table de redirections 301 exhaustive intégrée au .htaccess ou au middleware, audit Core Web Vitals comparatif avant/après, monitoring Search Console quotidien sur les 90 jours post-cutover. Sur le projet Access International, 51 redirections WordPress→Next ont été préservées sans perte de positions.
Modèle de contenu calqué sur le monolithe — les équipes recopient les types de contenus WordPress dans Strapi sans repenser l'API. Résultat : API rigide, données dupliquées, le front est obligé de faire 5 appels pour rendre une page d'accueil.
Atelier de modélisation de contenu en amont, distinction claire entre entités métier (Article, Auteur, Catégorie) et composants de présentation (Hero, Bloc CTA), normalisation des relations. L'API doit livrer une page complète en un seul appel optimisé, pas en cascade.
Workflow éditorial cassé sans préparation — les éditeurs perdent leur WYSIWYG familier, ne voient plus le rendu visuel pendant la rédaction, doivent comprendre la notion de "draft API" vs publié. Résistance forte, retard de mise en production des contenus.
Mise en place de previews live côté front (Next.js draft mode, Astro view transitions), formation hands-on des éditeurs sur 2 sessions courtes, documentation visuelle des nouveaux flux. Le succès se mesure au temps de publication d'un article : il doit être inférieur ou égal à l'ancien.
Performance front mal mesurée — l'équipe pense que "headless = forcément rapide" et néglige les optimisations front. Résultat : LCP dégradé par des images non optimisées, CLS cassé par des polices custom, JavaScript bundle gonflé.
Budget performance fixé dès le cadrage (LCP < 2,5 s, CLS < 0,1, INP < 200 ms), mesure CrUX field data en continu, optimisation systématique : images WebP/AVIF responsive, fonts subset + font-display swap, code splitting agressif, ISR ou SSG par défaut. Le headless ne garantit la perf que si elle est explicitement gouvernée.
Plusieurs profils distincts, mobilisés sur la durée du programme. Reproduire cette cellule en interne est rarement réaliste — la pénurie des compétences legacy et la profondeur d'expertise ATLAS rendent l'externalisation structurellement plus rapide et moins risquée.
Modélisation contenu, choix CMS cible (Strapi, Drupal headless, Directus, WP+WPGraphQL), conception API, design system
Next.js ou Astro, SSG/ISR, optimisation Core Web Vitals, images responsive WebP/AVIF, code splitting, draft mode pour previews
Configuration CMS headless, API REST/GraphQL, modélisation entités, workflows éditoriaux, permissions
Cartographie URLs source/cible, table 301 exhaustive, hreflang, robots/sitemaps, monitoring GSC 90 jours post-cutover
Conception previews live, formation hands-on éditeurs (2 sessions), documentation visuelle, mesure temps de publication
Pilotage cadrage → cutover, coordination équipes métier / IT / SEO, recette utilisateurs
Access maîtrise les CMS monolithiques côté backend sur des projets livrés : Drupal sur la plateforme bilingue (arabe + anglais) du Ministère de la Culture KSA pour la valorisation patrimoniale Vision 2030 ; WordPress sur les portails Azur City (3 centres commerciaux) et Gnet News (portail d'actualité). Cette expertise back est directement transférable à une transition headless (Drupal headless via JSON:API, WordPress headless via WPGraphQL).
Sur le front statique moderne : le site access-international.dev est lui-même Next.js 16 + static export hébergé Plesk, avec 135 pages bilingues, SEO baseline 91/100, hreflang complet et 51 redirections legacy préservées. Le site vivantro.org tourne sur Astro avec Cloudflare Pages. Le site terrageo.pages.dev combine Vite + React + PWA. Capacité front SPA opérationnelle, combinable avec n'importe quel back CMS headless.
Le coût dépend du volume de contenu, du nombre d'intégrations et de la maturité du design system. À titre de repère : un site éditorial de 500 pages avec 3 intégrations tierces (CRM, ESP, paiement) se situe entre 40 000 et 80 000 EUR en mode forfait nearshore Tunisie. Un portail multi-sites avec 5 000 pages et workflows éditoriaux complexes peut dépasser 150 000 EUR. Le cadrage Intake permet de fixer une fourchette assumée. Voir les modèles de delivery.
Trois garde-fous : (1) cartographie URL complète avant tout dev, table de redirections 301 exhaustive validée par le SEO référent ; (2) audit Core Web Vitals comparatif avant/après pour s'assurer que le passage au headless améliore les performances et n'introduit pas de régressions de CLS ou LCP ; (3) monitoring Search Console quotidien sur les 90 jours post-cutover, alerte automatique sur toute baisse d'impressions ou de positions. Sur notre propre site nous avons préservé 51 redirections WordPress sans perte de rankings.
8 à 16 semaines selon le volume. Pour un site vitrine de 100 pages sans intégration complexe, 8 semaines suffisent (cadrage 2, dev 4, recette + cutover 2). Pour un portail multi-sites de 5 000 pages avec CRM, ESP, paiement et multi-langue, comptez 14 à 16 semaines. Le pilote sur un sous-périmètre (une rubrique, une langue) en 4 semaines permet de valider la mécanique avant d'engager la suite.
Le risque principal d'une migration headless est la résistance éditoriale : perte du WYSIWYG familier, nouveaux workflows, draft API. Notre approche : previews live côté front dès le début (Next.js draft mode ou Astro view transitions), 2 sessions de formation hands-on des éditeurs (avant cutover et 2 semaines après), documentation visuelle des flux. Le succès se mesure au temps de publication d'un article : il doit être inférieur ou égal à l'ancien dans les 30 jours suivant le cutover.
Trois manières de démarrer — du diagnostic SEO au programme complet. Notre approche démontrée sur access-international.dev même (51 redirections préservées, score SEO 91/100).