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}`
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.
