# Architecture d’exposition du contenu WordPress pour le RAG d’un moteur tiers

> Une agence doit alimenter le système de recherche augmentée d'un partenaire. Schéma d'architecture pour exposer proprement le contenu WordPress à un moteur de réponse tiers.

- Auteur : Clément Hadrot
- Publié le : 2024-10-14
- Mis à jour le : 2024-10-14
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/architecture-exposition-contenu-rag/

## L’essentiel

- Une API REST filtrée plutôt qu'un accès direct à la base
- Un format de sortie pensé pour le découpage en passages
- Une couche de contrôle d'accès indépendante du CMS

Une agence partenaire nous a confié un projet inhabituel : un de leurs clients avait signé un partenariat avec un éditeur de moteur de réponse spécialisé dans un secteur professionnel, qui souhaitait alimenter son système de recherche augmentée (RAG) directement à partir du contenu WordPress du client, en dehors de tout crawl public classique.

Ce cas ne relève plus du `llms.txt`, pensé pour guider un crawl public généraliste. Il s'agit ici de construire une architecture d'exposition dédiée, avec un contrat clair entre le CMS et le moteur tiers.

## Le besoin exprimé par le partenaire technique

Le moteur tiers ne voulait pas explorer le site comme un robot classique. Il souhaitait interroger une API dédiée, à intervalle régulier, pour récupérer le contenu sous une forme déjà découpée en passages exploitables, avec des métadonnées de fraîcheur et de provenance précises pour chaque passage.

## Schéma d'architecture retenu

> L'essentiel à retenir : Une API REST filtrée plutôt qu'un accès direct à la base ; Un format de sortie pensé pour le découpage en passages ; Une couche de contrôle d'accès indépendante du CMS

```
WordPress (base de contenu)
   │
   ├── Couche 1 : Endpoint REST dédié
   │     /wp-json/wpmoderne/v1/rag-export
   │     → Filtre les contenus publiés, exclut les brouillons et le contenu sous embargo
   │
   ├── Couche 2 : Transformateur de passages
   │     → Découpe chaque article en blocs de 200 à 400 mots
   │     → Ajoute un identifiant stable par bloc et un horodatage de dernière modification
   │
   └── Couche 3 : Contrôle d'accès
         → Authentification par clé API dédiée au partenaire
         → Journalisation de chaque requête pour audit
```

## Couche 1 : un endpoint REST dédié, pas l'API publique générique

Nous avons délibérément évité d'exposer l'API REST publique standard de WordPress pour cet usage, trop générique et potentiellement bavarde sur des champs non destinés à un tiers externe. Un point de terminaison dédié, enregistré via `register_rest_route()`, permet de contrôler exactement ce qui sort :

```
add_action( 'rest_api_init', function () {
    register_rest_route( 'wpmoderne/v1', '/rag-export', array(
        'methods'             => 'GET',
        'callback'            => 'wpmoderne_rag_export',
        'permission_callback' => 'wpmoderne_check_rag_api_key',
    ) );
} );

function wpmoderne_check_rag_api_key( $request ) {
    $provided = $request->get_header( 'X-Rag-Api-Key' );
    return hash_equals( get_option( 'wpmoderne_rag_partner_key' ), (string) $provided );
}
```

## Couche 2 : transformer le contenu en passages exploitables

Le contenu brut d'un article WordPress, avec ses balises de blocs internes, n'est pas directement exploitable pour un système RAG. La couche de transformation nettoie le HTML, découpe le texte selon les frontières de sections `<h2>` et `<h3>`, et attribue un identifiant stable à chaque passage :

```
{
  "article_id": 4821,
  "passage_id": "4821-p3",
  "titre_section": "Combien de temps une migration de domaine impacte-t-elle le trafic ?",
  "texte": "Une migration de domaine correctement redirigée entraîne...",
  "date_modification": "2024-10-01T09:00:00+02:00",
  "url_source": "https://exemple.fr/migration-domaine/#p3"
}
```

L'ancre `#p3` dans l'URL source permet au moteur tiers de créer un lien de citation qui pointe précisément vers le passage utilisé, plutôt que vers le haut de l'article dans son ensemble — un détail qui facilite la vérification humaine de la citation en cas de doute.

## Couche 3 : un contrôle d'accès distinct des mécanismes WordPress classiques

Contrairement à un accès public via `robots.txt`, cette architecture repose sur une clé API strictement réservée au partenaire, journalisée à chaque requête via un simple enregistrement en base ou en fichier de log dédié. Cela permet de révoquer l'accès à tout moment, de mesurer la fréquence réelle des appels, et de détecter une utilisation anormale sans dépendre de la bonne volonté d'un robot respectant une convention publique.

## Ce que cette architecture évite

- Une dépendance à un crawl public difficile à contrôler dans son rythme et sa couverture.
- L'exposition de contenu sous embargo ou de brouillons via une API trop permissive.
- Une incohérence entre la version indexée par le moteur tiers et la version réellement publiée, grâce à l'horodatage systématique de chaque passage.

> Alimenter un RAG tiers, ce n'est pas laisser un robot explorer un site : c'est signer un contrat de données, avec un format, une fréquence et une traçabilité définis à l'avance.

## En résumé

Une architecture d'exposition dédiée à un partenaire RAG diffère fondamentalement d'une simple ouverture aux robots publics : elle repose sur un endpoint contrôlé, un format de passages structuré et une couche d'authentification propre. Ce niveau d'architecture ne se justifie que pour un partenariat contractuel explicite ; pour une visibilité générale auprès des moteurs génératifs publics, le `llms.txt` et une structure de contenu soignée restent largement suffisants.