# Une fédération de 300 associations : un WordPress, cent espaces Algolia

> Un seul WordPress headless, cent structures indépendantes, chacune avec sa propre recherche : l'architecture d'un index Algolia partitionné qui tient la route.

- Auteur : WordPress Développement
- Publié le : 2022-01-04
- Mis à jour le : 2022-01-04
- Catégorie : Headless & API
- URL : https://www.wpmoderne.fr/headless/federation-300-associations-wordpress-cent-espaces-algolia/

## L’essentiel

- Un attribut de partitionnement isole chaque structure sans dupliquer l'index
- Les règles de sécurité Algolia empêchent les fuites entre structures
- Un seul index reste plus simple à maintenir que cent index distincts

Une fédération nationale rassemble 300 associations locales indépendantes sous une même bannière, chacune avec son propre espace de contenu — actualités, événements, annuaire de bénévoles — mais toutes hébergées sur une unique instance WordPress headless, pour mutualiser les coûts d'hébergement et de maintenance. Le défi : offrir à chaque structure une recherche qui ne mélange jamais ses résultats avec ceux des 299 autres, sans pour autant démultiplier l'infrastructure de recherche à l'identique.

## La tentation du multi-index

La première approche envisagée consistait à créer un index Algolia distinct par association, soit potentiellement 300 index à synchroniser et maintenir. Cette option a été écartée rapidement : au-delà du coût, la maintenance d'une telle volumétrie d'index — configuration des facettes, des règles de pertinence, des synonymes — aurait dû être répliquée 300 fois à chaque évolution, avec un risque de dérive entre structures au fil du temps.

## L'architecture retenue : un index partitionné

Un seul index Algolia héberge l'ensemble du contenu des 300 associations, chaque document portant un attribut `association_id` utilisé comme critère de partitionnement à chaque requête. La configuration de l'index — facettes, règles de pertinence, synonymes — n'existe qu'en un seul exemplaire, appliqué uniformément à toutes les structures.

```
WordPress (multisite, un site par association)
  └── save_post (type "actualite" ou "evenement")
        └── indexation vers Algolia avec association_id
              { objectID, titre, extrait, association_id, type }

Front (portail unique, url/association-slug/recherche)
  └── requête Algolia filtrée : filters: `association_id:${id}`
```

> L'essentiel à retenir : Un attribut de partitionnement isole chaque structure sans dupliquer l'index ; Les règles de sécurité Algolia empêchent les fuites entre structures ; Un seul index reste plus simple à maintenir que cent index distincts

## Empêcher les fuites entre structures

Filtrer côté front avec un paramètre `filters` classique ne suffit pas : rien n'empêche, techniquement, qu'un appel mal formé ou une clé d'API mal scopée expose le contenu d'une autre association. La sécurisation repose sur les **clés API sécurisées** d'Algolia, générées côté serveur avec un filtre imposé et non contournable côté client :

```
$client = SearchClient::create('APP_ID', 'ADMIN_API_KEY');

$secured_key = $client->generateSecuredApiKey(
    'SEARCH_ONLY_API_KEY',
    [
        'filters'    => "association_id:$association_id",
        'validUntil' => time() + 3600,
    ]
);
```

Cette clé, générée à la demande pour chaque session de recherche selon l'association concernée, applique le filtre au niveau du service Algolia lui-même, avant même que la requête n'atteigne l'index. Aucune manipulation côté navigateur ne permet de l'étendre à une autre association que celle pour laquelle elle a été émise.

## Ce que ce partitionnement change au quotidien

- Une évolution des facettes de recherche (ajout d'un filtre par catégorie d'événement) se déploie une seule fois, pour les 300 structures simultanément.
- Le coût Algolia reste proportionnel au volume total de contenu et de recherches, sans surcoût structurel lié à la multiplication des index.
- La sécurisation par clé API générée à la demande évite toute fuite de contenu entre associations, sans logique de filtrage à réimplémenter côté front.

### Un point de vigilance : la volumétrie combinée

Un index partagé grandit avec l'ensemble des 300 structures cumulées, ce qui peut, à terme, dépasser certains paliers tarifaires d'Algolia liés au nombre total d'enregistrements. Ce comparatif ne traite pas la facturation Algolia elle-même : ce point mérite un suivi indépendant, à mesure que la fédération continue de croître.

> Partitionner un index ne signifie pas le fragmenter : un seul index bien filtré reste souvent plus simple à faire évoluer que cent index synchronisés séparément, à condition que le filtrage soit imposé côté serveur, jamais laissé à la discrétion du front.

## En résumé

Cette architecture ne dit rien de la facturation d'Algolia au-delà d'un certain volume, mais elle répond à une contrainte structurelle propre aux projets multi-tenant : offrir à chaque structure une recherche cloisonnée, sans multiplier la surface de maintenance par le nombre de structures fédérées. Un attribut de partitionnement et une clé API sécurisée suffisent à tenir cette promesse à l'échelle de 300 associations, comme ils tiendraient à l'échelle de mille.