# Isoler l’extranet adhérents d’une mutuelle régionale d’un WordPress headless

> Comment une mutuelle régionale sépare son extranet adhérents d'un WordPress consommé en lecture seule, avec une authentification distincte des deux mondes.

- Auteur : Clément Hadrot
- Publié le : 2025-05-03
- Mis à jour le : 2025-05-03
- Catégorie : Headless & API
- URL : https://wpmoderne.dev.wordpress-developpement.fr/headless/isoler-extranet-adherents-mutuelle-wordpress-headless/

## L’essentiel

- WordPress reste en lecture seule pour le contenu public
- L'extranet vit sur une authentification totalement séparée
- Aucun jeton d'accès adhérent ne transite par l'API REST publique

« Et si un adhérent tapait son numéro de sécurité sociale dans le mauvais formulaire ? » Cette question, presque provocatrice, a été posée en réunion de cadrage par un responsable informatique d'une mutuelle régionale, avant qu'il ne précise le vrai sujet : son organisation voulait un site vitrine moderne et rapide, construit en headless, mais refusait catégoriquement que l'espace adhérent partage la moindre logique d'authentification avec ce nouveau front public.

Le choix a été de traiter les deux besoins comme deux systèmes distincts qui ne se parlent jamais directement. WordPress fournit le contenu public (garanties, actualités, formulaires de contact) via l'API REST, en lecture seule et sans authentification. L'extranet adhérents, lui, vit sur une plateforme séparée, avec son propre système de connexion, ses propres jetons, et aucune dépendance technique envers WordPress.

## Pourquoi ne pas tout faire tenir dans WordPress

Techniquement, rien n'empêche de gérer des comptes adhérents dans WordPress avec des rôles personnalisés et une authentification par cookies. Mais cette mutuelle traitait des données de santé, soumises à un niveau d'exigence bien supérieur à celui d'un site vitrine classique. Faire cohabiter cette donnée sensible avec un CMS public, dont la surface d'attaque inclut potentiellement des extensions tierces pour le contenu marketing, aurait multiplié les risques sans bénéfice réel.

## Ce que WordPress expose, et ce qu'il ne voit jamais

> L'essentiel à retenir : WordPress reste en lecture seule pour le contenu public ; L'extranet vit sur une authentification totalement séparée ; Aucun jeton d'accès adhérent ne transite par l'API REST publique

Le WordPress de la mutuelle expose uniquement des contenus publics via l'API REST : pages, articles, garanties génériques. Aucune route ne retourne d'information nominative. La configuration désactive explicitement toute route sensible par défaut, notamment celle des utilisateurs, filtrée ainsi :

```
add_filter( 'rest_endpoints', function ( $routes ) {
    unset( $routes['/wp/v2/users'] );
    unset( $routes['/wp/v2/users/(?P<id>[\d]+)'] );
    return $routes;
} );
```

L'extranet adhérents, hébergé sur un domaine distinct, dispose de sa propre base de données et de son propre serveur d'authentification, indépendant du système de comptes WordPress. Un adhérent qui se connecte à son espace personnel n'obtient jamais de jeton exploitable côté WordPress, et réciproquement, un compte WordPress (administrateur, rédacteur) n'a aucun droit d'accès à l'extranet.

## Le seul point de contact autorisé : le contenu, jamais l'identité

Un unique pont existe entre les deux mondes : l'extranet peut afficher, dans son propre habillage, certains contenus éditoriaux publiés dans WordPress (actualités de la mutuelle, documents d'information générale), récupérés via l'API REST publique, sans authentification. Ce contenu reste identique pour tous les adhérents ; aucune donnée personnalisée ne provient de WordPress.

- L'extranet appelle l'API REST publique de WordPress uniquement pour du contenu générique, jamais pour des données liées à un compte.
- Aucun jeton d'authentification adhérent ne transite, même chiffré, vers le domaine WordPress.
- Les deux domaines disposent de politiques CORS strictement séparées, sans autorisation croisée superflue.

## Ce que cette séparation coûte en confort

Cette architecture impose une limite assumée : impossible d'afficher, sur le site public WordPress, un contenu personnalisé selon le statut de l'adhérent connecté, puisque WordPress ignore tout de cette connexion. Pour la mutuelle, ce compromis était acceptable : le site public reste un site de communication, l'extranet reste un espace de gestion de dossier, et cette frontière nette facilite d'ailleurs les audits de sécurité, chaque système pouvant être évalué séparément.

### Ce que cette séparation a simplifié côté audit

Un auditeur externe, mandaté par la mutuelle pour vérifier la conformité de son système d'information, a pu traiter les deux périmètres indépendamment, sans avoir à retracer d'éventuelles interactions entre eux puisqu'il n'en existe aucune techniquement. Ce découpage net a réduit le temps d'audit par rapport à une architecture où contenu public et espace personnalisé auraient partagé la même base de comptes, avec toutes les zones grises que ce partage aurait introduites dans l'analyse des risques.

> La meilleure protection contre une fuite de données sensibles reste souvent de ne jamais leur donner de chemin technique pour circuler entre deux systèmes.

## En résumé

Un WordPress headless ne doit pas forcément héberger tout ce qui touche à un adhérent ou à un client identifié : parfois, la décision la plus sûre consiste à garder deux systèmes d'authentification qui s'ignorent complètement, reliés uniquement par du contenu public et sans donnée nominative en transit.