La question centrale : qui calcule, qui filtre, qui trie ?
Dans une architecture découplée, trois couches interviennent dans une requête de recherche : Drupal (source de vérité des contenus et des droits), le moteur d'index (Solr, Elasticsearch, Meilisearch…), et le front-end. Chaque architecture déplace la responsabilité différemment entre ces trois couches.
Architecture 1 — Tout API : Drupal comme proxy de recherche
Le front-end n'interroge jamais le moteur d'index directement. Il appelle une route Drupal, qui vérifie la session, construit la requête vers Solr ou Elasticsearch, filtre les résultats selon les permissions, et retourne des données déjà contrôlées — facettes incluses.
Avantage : droits appliqués en amont, cohérence forte, aucune surface d'exposition de l'index.
Coût : Drupal devient un goulot d'étranglement. La mise en cache est complexe dès qu'il y a des utilisateurs authentifiés aux droits différents. Convient aux portails métier à faible concurrence et aux accès sensibles.
Architecture 2 — Mixte : index exposé, permissions par filtre
Le front interroge directement le moteur d'index pour la performance. Les permissions sont injectées comme filtres obligatoires dans chaque requête, selon les droits récupérés auprès de Drupal au chargement de la page.
Avantage : charge de Drupal drastiquement réduite, facettes et tris calculés par le moteur conçu pour ça.
Coût : la cohérence des droits repose sur la synchronisation de l'index. Un document dont le statut d'accès change dans Drupal reste visible dans l'index jusqu'à la prochaine resync. Risque de fuite si le filtre est oublié côté front.
Architecture 3 — Front-optimisé : permissions précalculées dans l'index
Les permissions sont dénormalisées à l'indexation. Pour chaque document, Drupal calcule la liste des utilisateurs ou groupes autorisés et l'écrit dans l'index comme champ de filtre. Le front filtre directement, sans rappeler Drupal.
Avantage : latence minimale, scalabilité maximale. Le seul modèle viable sur des catalogues à très grande échelle.
Coût : taille de l'index importante si les droits sont granulaires. Mise à jour des permissions = reindex partiel. Désynchronisation silencieuse possible.
La synchronisation d'index — le point de friction invisible
L'index n'est jamais synchrone à 100 % avec Drupal. Les stratégies : push temps réel via hooks Drupal, queue asynchrone (RabbitMQ, Redis), reindex planifié par cron, ou invalidation sélective des seuls documents modifiés. La tolérance au décalage est une décision métier, pas technique.
Droits par document — où ne pas transiger
- Tester les permissions comme des fonctionnalités : chaque niveau de droits a des tests d'intégration qui vérifient les résultats côté front, pas seulement dans Drupal.
- Ne jamais faire confiance à l'index sans couche de filtrage des permissions (réseau, authentification ou filtre obligatoire).
- Prévoir la révocation rapide pour les contenus confidentiels publiés par erreur.
Fallback quand l'index est à la traîne
Surveiller l'écart entre le last_modified Drupal et le indexed_at de l'index. Mettre en place un fallback vers Drupal pour les requêtes critiques quand le retard dépasse un seuil. Alerter avant que les utilisateurs ne remontent des incohérences.
Ce qu'il faut cadrer avant de coder
Trois questions à trancher avec le métier avant d'implémenter : quel délai maximum entre une modification de droits et son effectivité dans les résultats ? Que se passe-t-il si un document confidentiel apparaît trente secondes dans les résultats d'un utilisateur non autorisé ? Quel est le volume de requêtes aux heures de pointe ?
Ces décisions valent un diagnostic préalable, pas une hypothèse dans le README.