# Presse locale : garder l’éditeur natif, rendre le site public en headless

> Arborescence commentée d'un headless partiel où la rédaction garde l'éditeur natif de WordPress tandis que le site public consomme l'API REST via un front séparé.

- Auteur : WordPress Développement
- Publié le : 2023-11-19
- Mis à jour le : 2023-11-19
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/presse-locale-editeur-natif-site-public-headless/

## L’essentiel

- La rédaction n'a jamais changé ses habitudes d'écriture dans l'éditeur de blocs
- Seul le rendu public a basculé vers un front Astro consommant l'API
- Les journalistes publient sans savoir que le site public a changé de moteur

Onze journalistes, un rythme de publication de plusieurs articles par jour, et une contrainte non négociable posée dès la première réunion de cadrage : aucune formation supplémentaire pour la rédaction d'un titre de presse locale hebdomadaire qui envisageait de refondre son site public. L'éditeur de blocs WordPress, avec ses habitudes bien ancrées après des années d'usage quotidien, ne devait pas changer d'un pixel.

Cette contrainte a orienté tout le projet vers un headless partiel plutôt qu'une refonte complète : l'administration WordPress reste strictement identique à ce que les journalistes connaissent, tandis que seul le rendu public bascule vers un front séparé, construit avec Astro et consommant l'API REST du site.

## L'arborescence du projet

Le projet se divise en deux dépôts distincts, sans dépendance de code partagée entre eux, uniquement reliés par les endpoints de l'API :

```
presse-locale-wp/               # WordPress, éditeur natif inchangé
├── wp-content/
│   ├── themes/
│   │   └── redaction-admin/    # thème minimal, actif uniquement en admin
│   └── plugins/
│       └── expose-articles-api/
│           ├── cpt-breve.php
│           ├── rest-fields.php
│           └── webhook-publication.php

presse-locale-front/            # Astro, site public consommé par les lecteurs
├── src/
│   ├── pages/
│   │   ├── [categorie]/[slug].astro
│   │   └── index.astro
│   └── lib/
│       └── client-api.ts
└── astro.config.mjs
```

Le thème `redaction-admin` ne sert qu'à afficher un aperçu minimaliste dans le tableau de bord WordPress ; il n'est jamais chargé par un visiteur du site public. Cette séparation nette évite toute tentation, au fil des mois, de faire évoluer le thème classique en parallèle du front Astro, ce qui aurait fini par recréer deux sites à maintenir au lieu d'un.

## Ce que la rédaction ne voit jamais changer

Le type de contenu personnalisé `breve`, ajouté pour les alertes courtes publiées entre deux articles longs, a été déclaré avec les mêmes réglages qu'un article standard côté éditeur, pour que les journalistes n'aient à apprendre aucune nouvelle interface :

> L'essentiel à retenir : La rédaction n'a jamais changé ses habitudes d'écriture dans l'éditeur de blocs ; Seul le rendu public a basculé vers un front Astro consommant l'API ; Les journalistes publient sans savoir que le site public a changé de moteur

```
register_post_type( 'breve', array(
    'label'        => 'Brèves',
    'public'       => true,
    'show_in_rest' => true,
    'rest_base'    => 'breves',
    'supports'     => array( 'title', 'editor', 'author', 'custom-fields' ),
    'menu_icon'    => 'dashicons-megaphone',
) );
```

Le webhook de publication, déclenché sur `publish_post` et `publish_breve`, notifie le front Astro qu'un contenu doit être régénéré. Ce mécanisme reste invisible pour la rédaction, qui continue simplement de cliquer sur le bouton « Publier » comme elle l'a toujours fait, sans savoir qu'en coulisse, un appel HTTP part vers une plateforme de déploiement distincte.

### Les ajustements nécessaires malgré tout

- Les embarquements de tweets et de vidéos, gérés par les blocs natifs d'intégration, ont dû être reproduits fidèlement côté rendu Astro pour éviter une différence d'affichage entre l'aperçu admin et le rendu public
- Les catégories, jusque-là utilisées librement par les journalistes sans grande rigueur, ont nécessité un travail de nettoyage pour que le routage par catégorie du front reste cohérent
- La recherche interne du site public, auparavant gérée nativement par WordPress, a été reconstruite côté front à partir d'un endpoint REST dédié

> Un headless partiel réussi se reconnaît à un signe simple : la rédaction ne sait pas qu'il existe. Le jour où un journaliste s'aperçoit du changement d'architecture, c'est généralement que quelque chose s'est mal passé.

## Ce que ce headless partiel ne couvre pas

La prévisualisation des brouillons directement depuis l'éditeur WordPress vers le rendu du front Astro ne fait pas partie de ce projet. Les journalistes continuent de relire leurs textes dans l'aperçu classique de l'éditeur de blocs, sans lien direct avec le rendu final du site public, une limitation assumée qui pourrait faire l'objet d'un chantier ultérieur si le besoin s'en fait sentir.

## Le bilan après trois mois

Aucune plainte de la rédaction n'a été remontée concernant un changement d'habitude, ce qui confirme que l'objectif initial a été tenu. Le temps de chargement des pages publiques a nettement diminué par rapport à l'ancien thème, un bénéfice secondaire mais bienvenu pour un titre de presse dont les pics de trafic suivent l'actualité locale de façon parfois brutale.

## Pour aller plus loin

Ce projet montre qu'un headless n'oblige pas à renoncer à l'éditeur natif de WordPress : il peut au contraire s'appuyer dessus, à condition de tracer une frontière stricte entre ce que voit la rédaction et ce que consomme le front public. Cette séparation, plus qu'un choix de framework, est ce qui a réellement garanti la réussite du projet.