Architecture RAG Drupal : que construire et que confier à un service géré

Une architecture RAG pour Drupal ne se résume pas à un chatbot. Une solution native nécessite normalement l’extraction du contenu, son découpage, des embeddings, une recherche vectorielle, la configuration de Search API, un LLM, des citations, des contrôles d’accès, des tâches de rafraîchissement, une interface et l’exploitation. Un service géré pour site public déplace plusieurs couches hors de Drupal ; la bonne frontière dépend de l’accès aux données et de l’entité responsable des défaillances.

Michael Shamanoff Founder, Achla AI Pour qui : propriétaires, architectes et intégrateurs Drupal qui évaluent la recherche sémantique ou les réponses avec citations. Méthode : pages officielles des projets Drupal et fichiers produit actuels d’Achla examinés le 3 août 2026, complétés par une matrice de responsabilité et une grille d’évaluation originales. L’IA a aidé à la rédaction ; les affirmations factuelles importantes sont reliées aux sources dans le registre joint. Pourquoi : les guides d’installation nomment les composants, mais les décideurs doivent aussi savoir qui exploite chaque couche, comment elle peut tomber en panne et quelles exigences excluent une approche gérée fondée sur l’exploration publique.

L’architecture RAG Drupal, couche par couche

RAG comprend deux flux. L’indexation transforme le contenu en enregistrements interrogeables. La requête transforme une question en recherche, contexte, génération et preuves vérifiables.

Flux d’indexation : du contenu aux fragments interrogeables

1. Sélectionnez les entités, champs et modes d’affichage Drupal qui contiennent les sources utiles.
2. Extrayez le texte en conservant identité, langue, URL, métadonnées d’accès et signaux de mise à jour ou suppression.
3. Découpez les contenus longs en fragments qui gardent assez de contexte pour rester compréhensibles.
4. Générez les embeddings et stockez-les dans un backend compatible avec les vecteurs.
5. Mettez à jour, remplacez ou supprimez les enregistrements lorsque le contenu Drupal change.

Le projet officiel AI Search intègre les embeddings vectoriels à Search API et documente un backend vectoriel, le découpage, les seuils de score, les contrôles d’accès aux entités après requête, la recherche hybride et l’intégration RAG. Ce sont des briques, pas un modèle d’exploitation complet.

Flux de requête : de la question à la réponse citée

1. Convertissez ou acheminez la question vers la méthode de recherche retenue.
2. Récupérez les fragments candidats et appliquez seuils, filtres ou logique de recherche hybride.
3. Assemblez le contexte du LLM sans perdre l’identité des sources ni les contraintes d’accès.
4. Générez une réponse, ou un résultat vide honnête.
5. Affichez les citations et journalisez assez de preuves pour diagnostiquer la recherche séparément de la génération.

Conservez les sources récupérées, le texte généré et les citations visibles par le visiteur comme trois preuves distinctes : une recherche pertinente peut être mal résumée, tandis qu’un texte fluide peut s’appuyer sur la mauvaise source.

Ce que fait Search API — et ce qu’il ne fait pas seul

Search API est le cadre de recherche extensible de Drupal. Il définit les index et fonctionne avec des backends, champs, processeurs, Views, filtres et facettes. À lui seul, il ne choisit pas de modèle d’embedding, n’exploite pas tous les backends, n’assemble pas le prompt d’un LLM, ne génère pas de réponse, ne conçoit pas l’interface de chat et n’évalue pas l’ancrage dans les sources.

Sa page officielle indique également une limite de sécurité importante : Search API ne peut pas fournir de restrictions d’accès génériques pour chaque cas. Les propriétaires du site doivent s’assurer que seuls les éléments accessibles sont indexés ou affichés, même si l’écosystème propose l’altération node-access et d’autres contrôles.

Une page de résultats sémantiques ne doit pas nécessairement devenir un chat. Déterminez si les visiteurs ont besoin de résultats classés, d’une réponse citée, d’une conversation ou de plusieurs surfaces.

L’état actuel des projets Drupal doit guider la décision de risque

Les versions et la couverture de sécurité évoluent. Actualisez ce tableau avant validation humaine, puis avant toute décision d’implémentation. Les informations suivantes ont été observées sur les pages officielles Drupal.org le 3 août 2026.

Un numéro 1.0.x ne remplace pas une couverture de sécurité. Évaluez séparément maturité, maintenance, versions de Drupal, dépendances aux fournisseurs et statut de la politique de sécurité.

Approche interne : les composants dont votre équipe doit être responsable

Une solution native conserve davantage de contrôle près de Drupal, mais multiplie les responsables opérationnels. Le projet RAG Search illustre un index vectoriel Search API alimentant l’assemblage du prompt et un LLM, avec caches exact et sémantique facultatifs, limitation de débit et nouveaux contrôles d’accès avant de servir des fragments en cache. Son exclusion de la politique de sécurité reste un avertissement important.

Drupal as RAG présente une autre voie avec Drupal 11, PostgreSQL et pgvector, ainsi qu’Ollama sur un hôte local ou réseau. Sa version observée était alpha et hors couverture : c’est un exemple d’architecture, pas une recommandation.

Le compromis plus large est traité dans recherche IA d’entreprise ou DIY.

Approche gérée : quelles couches sortent de Drupal

Pour un site public, l’approche gérée confie au fournisseur l’exploration, l’indexation, la recherche, les appels au modèle, la livraison des réponses et une partie du suivi. Drupal fournit les pages publiques et un script ou connecteur. La pile dans Drupal diminue, mais le service perd la connaissance native des champs, révisions, rôles et décisions d’accès, sauf mise en œuvre et vérification explicites.

Les fichiers produit Achla inspectés décrivent un connecteur Drupal 10/11 distribué avec Composer, une matrice de validation PHP 8.3 et des mises à jour automatiques indiquées comme disponibles lors de la dernière vérification du 16 juillet 2026. Le service explore et indexe le site public, puis affiche des réponses liées aux sources dans un widget disponible en modes bubble, inline et attach.

Achla n’est pas un backend Search API. Il s’agit d’une voie distincte d’exploration publique et de widget gérés. Elle ne doit pas être présentée comme solution pour le contenu Drupal privé ou authentifié, la recherche tenant compte des rôles, les permissions au niveau des lignes ou les actions transactionnelles. Consultez la configuration gérée sans développeur pour cette limite opérationnelle.

Construire ou gérer ? Décidez selon les exigences, pas la mode

Incluez infrastructure, mises à jour, revue de sécurité, clés fournisseurs, observabilité, opérations de contenu, réponse aux incidents et preuve du bon fonctionnement des restrictions d’accès — pas seulement le prix de la licence.

Protéger l’accès, les citations et le rafraîchissement

Le contenu privé constitue une bifurcation architecturale stricte. Search API ne résout pas automatiquement toutes les restrictions. AI Search documente les contrôles d’accès après requête ; RAG Search documente les clés de cache par rôle et les nouveaux contrôles d’accès aux sources. Ces mécanismes propres aux modules doivent encore être testés avec de vrais rôles, du contenu non publié, des permissions modifiées et des réponses en cache.

Le projet AI RAG Search Chat montre que la surface de production dépasse la recherche : pages de recherche et chat, sessions, permissions, limitation de débit, fournisseurs et sources liées. Sa version 1.0.7 observée était hors couverture des avis Drupal.

Pour toute architecture, conservez URL et identifiants pendant le découpage, vérifiez que chaque citation soutient la réponse, définissez un échec honnête et testez la propagation des mises à jour et suppressions. Une réponse liée aux sources est plus vérifiable, mais recherche et citations n’éliminent pas l’erreur du modèle. Utilisez ce guide pour évaluer la fiabilité d’une recherche IA.

Utiliser une grille de pilote reproductible

Construisez le jeu d’évaluation à partir de tâches réelles. Vingt à trente questions représentatives constituent une méthode de planification, pas un benchmark ni un seuil promis.

1. Notez la question, la page source attendue, la classe de contenu/accès et l’issue « introuvable » acceptable.
2. Incluez termes exacts, paraphrases, pages contradictoires, contenu ancien ou supprimé et une question sans réponse.
3. Pour un test natif sur contenu privé, employez des comptes de rôles différents et échouez dès qu’une source inaccessible est exposée.
4. Enregistrez les sources récupérées séparément du texte généré et des citations visibles.
5. Testez le rafraîchissement après modification et suppression, puis recommencez lorsque les caches pertinents peuvent intervenir.
6. Ajoutez les tests clavier, mobile, panne, résultat vide et solution de repli de l’interface.
7. Classez chaque échec dans ingestion, recherche, génération, citation/interface, accès ou exploitation, puis nommez son responsable dans chaque architecture.

Échouez le pilote en cas d’exposition de contenu restreint, de sources inventées, de liens de citation cassés, d’absence de reconnaissance d’une réponse introuvable ou de contenu supprimé restant au-delà du délai documenté. N’inventez pas de score universel. La fiche de preuves RAG sépare affirmation, source, comportement attendu et résultat observé.

Erreurs d’architecture courantes

• Traiter un LLM comme la recherche au lieu de mesurer les preuves récupérées.
• Indexer des champs ou contenus privés sans préserver et tester les règles d’accès.
• Perdre URL, langue, révision ou identité de l’entité pendant le découpage.
• Tester les ajouts, mais pas modifications, suppressions, invalidation du cache et échecs honnêtes.
• Qualifier une version de « sûre » parce qu’elle n’a pas de suffixe alpha, sans vérifier la couverture.
• Appeler un crawler public « backend Search API » ou « intégration de contenu privé ».
• Comparer le prix des licences en omettant infrastructure et responsabilité des incidents.

Une prochaine étape pratique pour un site Drupal public

Prototypez en interne si les champs et permissions Drupal, le contrôle des fournisseurs et une exploitation Search API existante sont essentiels. Évaluez une recherche gérée si la source est délibérément publique et si l’équipe souhaite déléguer les couches du service RAG.

Si vous voulez des réponses citées sur les pages et documents Drupal publics sans exploiter la pile RAG dans Drupal, évaluez la configuration Drupal d’Achla. Achla n’est pas un backend Search API ni la voie de contenu privé décrite ci-dessus.

Questions posées par les équipes Drupal

Ai-je besoin de Search API ?

Oui pour une approche native bâtie autour de ses modules. Un service géré d’exploration publique peut utiliser son propre index. Ce sont deux architectures différentes ; un connecteur ou widget ne transforme pas l’index géré en backend Search API.

Ai-je toujours besoin d’une base vectorielle ?

Pas pour toute recherche. La recherche par mots-clés ou facettes peut utiliser d’autres backends. AI Search emploie des backends vectoriels pour la recherche sémantique ; un service géré peut masquer son infrastructure derrière sa frontière.

La recherche sémantique peut-elle fonctionner sans chat ?

Oui. Elle peut renvoyer des résultats classés. Ajoutez la génération seulement si une réponse rédigée sert la tâche, si les sources sont conservées, les absences gérées honnêtement et la formulation testée séparément de la recherche.

Qu’en est-il du contenu privé ?

Intégrez les exigences d’accès dès le début. Une conception native peut préserver les permissions Drupal si l’ensemble de l’indexation, de la recherche, du cache et de l’affichage est testé. La voie Achla décrite ici se limite au contenu public explorable.

Comment comparer les pilotes ?

Utilisez le même jeu de questions, les mêmes sources attendues, cas d’accès, tests de rafraîchissement, contrôles des citations, conditions d’interface et catégories d’échec. Comparez preuves et responsabilités, pas une démonstration choisie par le fournisseur ni un score universel non étayé.

Illustration partagée

Un choix d’architecture RAG répartit l’extraction, la recherche, la génération, les citations et l’exploitation entre différents responsables.

*Un choix d’architecture RAG répartit l’extraction, la recherche, la génération, les citations et l’exploitation entre différents responsables.*