Basculer un site entier vers le headless du jour au lendemain fait courir un risque que peu de clients acceptent sereinement : tout casser d’un coup, sur un site qui génère du chiffre d’affaires tous les jours. Cette méthode propose une alternative plus prudente, testée sur plusieurs projets ces derniers mois : migrer une seule zone de page à la fois, en laissant le thème WordPress classique gérer tout le reste jusqu’à ce que chaque brique ait fait ses preuves.
Ce tutoriel ne traite pas du headless partiel avec des îlots interactifs façon Alpine.js ou React, une approche différente déjà couverte ailleurs sur ce blog pour des besoins d’interactivité plutôt que de migration.
Étape 1 : choisir une zone à faible risque
Le bloc « Articles liés » en pied de page d’article s’est révélé un excellent premier candidat sur ce projet : visible sur chaque article, mais sans impact sur la navigation principale ni sur les fonctionnalités critiques (panier, formulaire de contact). Une erreur sur cette zone reste contenue et rapidement corrigible, sans casser l’expérience globale du site.
Étape 2 : exposer les données nécessaires via l’API REST
La zone concernée nécessite trois articles de la même catégorie que l’article courant, avec titre, image mise en avant et extrait. Un point de terminaison REST personnalisé a été créé pour cet usage précis, plutôt que de faire porter cette logique par le front :
add_action( 'rest_api_init', function () {
register_rest_route( 'exemple/v1', '/articles-lies/(?P<id>\d+)', array(
'methods' => 'GET',
'callback' => 'exemple_get_articles_lies',
'permission_callback' => '__return_true',
) );
} );
function exemple_get_articles_lies( $request ) {
$id = (int) $request['id'];
$categories = wp_get_post_categories( $id );
$articles = get_posts( array(
'category__in' => $categories,
'post__not_in' => array( $id ),
'posts_per_page' => 3,
) );
return array_map( function ( $article ) {
return array(
'id' => $article->ID,
'titre' => get_the_title( $article ),
'extrait' => get_the_excerpt( $article ),
'image' => get_the_post_thumbnail_url( $article, 'medium' ),
'lien' => get_permalink( $article ),
);
}, $articles );
}
Étape 3 : consommer ce point de terminaison depuis un petit widget front
Le thème PHP classique reste responsable de tout le reste de la page. Seule cette zone précise est remplacée par un conteneur vide, complété côté client par un petit script JavaScript autonome, sans framework lourd :
<div id="articles-lies" data-article-id="<?php echo get_the_ID(); ?>"></div>
<script>
(async () => {
const conteneur = document.getElementById('articles-lies')
const id = conteneur.dataset.articleId
const reponse = await fetch(`/wp-json/exemple/v1/articles-lies/${id}`)
const articles = await reponse.json()
conteneur.innerHTML = articles.map(a => `
<a href="${a.lien}">
<img src="${a.image}" alt="">
<span>${a.titre}</span>
</a>
`).join('')
})()
</script>
Étape 4 : mesurer avant d’étendre le périmètre
Deux semaines après la mise en ligne de cette première zone migrée, les journaux du serveur ont été comparés avant et après, pour vérifier qu’aucune charge supplémentaire anormale n’apparaissait sur l’API REST, et que le temps de chargement perçu de la page restait stable. Cette étape de mesure, souvent négligée, est ce qui donne au client la confiance nécessaire pour valider l’étape suivante.
Étape 5 : élargir progressivement, zone par zone
Une fois cette première zone validée en production pendant plusieurs semaines sans incident, le même principe a été appliqué à une deuxième zone (le bloc de newsletter en pied de page), puis une troisième (le fil d’Ariane), chacune avec son propre point de terminaison REST dédié et son propre widget front autonome. Le thème classique continue de porter la structure générale du site jusqu’à ce que suffisamment de zones aient été validées pour envisager une bascule complète vers un front headless unifié.
Ce que cette méthode apporte
- Chaque étape reste réversible : il suffit de retirer le widget et de restaurer le code PHP d’origine en cas de problème.
- Le client voit un résultat concret à chaque étape, plutôt que d’attendre plusieurs mois une bascule complète sans rien voir avancer entretemps.
- L’équipe monte en compétence sur l’API REST progressivement, sans avoir à maîtriser d’un coup toute l’architecture d’un front headless complet.
Une migration qui fait peur au client est une migration mal découpée : plus les étapes sont petites et réversibles, plus il devient facile de dire oui à l’étape suivante.
En résumé
Migrer vers le headless ne demande pas obligatoirement un big bang. En choisissant une zone à faible risque, en l’exposant proprement via un point de terminaison REST dédié, et en mesurant l’impact avant d’étendre le périmètre, un site peut évoluer vers le découplage par petites étapes maîtrisées, sans jamais mettre en danger ce qui fonctionne déjà.
