Un projet qui change trois fois de définition de son architecture de contenu en cours de route ne finit jamais dans les délais prévus. C’est le constat posé en reprenant une migration Webflow vers WordPress headless démarrée sans cahier des charges de contenu, où l’équipe précédente avait avancé au fil de l’eau, en découvrant les limites du site Webflow d’origine à mesure qu’elle tentait de les reproduire côté WordPress.
Trois antipatterns récurrents ressortent de cette reprise, chacun ayant coûté un temps disproportionné à corriger une fois le projet bien avancé. Ils ne sont pas propres à Webflow ni à un framework front particulier : ils touchent la préparation d’un projet headless en général, quel que soit le choix technique fait ensuite côté rendu.
Ce qu’on voit : un mappage de contenu improvisé
Le site Webflow d’origine organisait son contenu par collections CMS, chacune avec ses propres champs personnalisés, sans structure de types de contenu clairement définie au départ. L’équipe précédente avait recréé ces collections au fur et à mesure en types de contenu personnalisés WordPress, en ajoutant des champs à mesure que de nouvelles pages du site Webflow révélaient des besoins non anticipés.
Pourquoi c’est un problème : chaque nouvelle découverte de champ manquant obligeait à revenir sur des contenus déjà migrés pour les compléter, ce qui a multiplié les allers-retours et laissé des contenus incohérents entre eux, certains articles ayant des champs que d’autres n’avaient pas.
Quoi faire : avant toute migration, un inventaire complet des collections Webflow et de leurs champs, réalisé en exportant le contenu existant via l’API Webflow, aurait permis de définir une bonne fois pour toutes la structure des types de contenu personnalisés WordPress et de leurs champs personnalisés, avant d’écrire la moindre ligne de code de migration.
Ce qu’on voit : une API REST exposée sans réflexion
L’API REST de WordPress, disponible nativement depuis le cœur du logiciel, avait été utilisée telle quelle, en exposant directement la structure par défaut des points de terminaison /wp-json/wp/v2/, y compris des champs internes inutiles côté front (métadonnées de révision, champs bruts non nettoyés).
Pourquoi c’est un problème : le front consommait une réponse JSON verbeuse et peu structurée, avec des champs de contenu au format HTML brut qu’il fallait ensuite nettoyer côté client, ce qui alourdissait le rendu et rendait le code front plus fragile face à la moindre évolution du contenu.
Quoi faire : le hook register_rest_field() permet d’ajouter des champs personnalisés proprement structurés à la réponse de l’API REST, tandis que le filtre rest_prepare_{post_type} permet de retirer les champs internes inutiles avant l’envoi de la réponse au front. Une réponse d’API pensée pour le front, plutôt que la structure par défaut de WordPress, aurait évité un nettoyage systématique côté client.
add_action( 'rest_api_init', function () {
register_rest_field( 'page', 'resume_structure', array(
'get_callback' => function ( $post ) {
return array(
'titre' => get_the_title( $post['id'] ),
'accroche' => get_post_meta( $post['id'], 'accroche', true ),
'image_mise_en_avant' => get_the_post_thumbnail_url( $post['id'], 'large' ),
);
},
) );
} );
Ce qu’on voit : aucune stratégie de prévisualisation
Le site Webflow d’origine offrait une prévisualisation instantanée de chaque modification dans son propre éditeur visuel. Une fois le contenu migré vers WordPress headless, cette prévisualisation avait tout simplement disparu : les éditeurs de contenu devaient publier un brouillon puis attendre un rebuild du front pour voir le résultat, un cycle bien plus lent que ce à quoi ils étaient habitués.
Pourquoi c’est un problème : cette perte de confort a directement dégradé l’adoption de WordPress par les équipes éditoriales, certaines personnes continuant à demander des captures d’écran avant de valider une publication, faute de prévisualisation fiable.
Quoi faire : une route de prévisualisation dédiée côté front, capable de consommer les brouillons WordPress via l’API REST authentifiée, aurait permis de retrouver un cycle de prévisualisation proche de l’expérience Webflow, un besoin à anticiper dès la conception de l’architecture plutôt qu’à ajouter après coup.
- Inventaire complet du contenu source avant toute migration
- Structure de l’API REST pensée pour le front, pas laissée par défaut
- Prévisualisation des brouillons prévue dès la conception, pas ajoutée en urgence
Un projet headless qui commence sans cahier des charges de contenu n’économise pas de temps de préparation, il le déplace simplement plus loin dans le projet, à un moment où il coûte bien plus cher à rattraper.
En résumé
Aucun de ces trois antipatterns ne relève d’un choix technique erroné en soi : l’API REST de WordPress et une architecture headless restent des choix solides. C’est l’absence de préparation en amont qui a transformé un projet raisonnable en six semaines de retard à rattraper, une fois la reprise engagée. Le choix du framework front n’a, dans ce cas précis, joué aucun rôle dans ces difficultés.
