Agent IA connecté à votre CRM : gagnez 1 heure par jour sans recruter, guide 2026
Guide 2026 pour brancher un agent IA à votre CRM: actions concrètes, checklist et plan en 7 jours pour gagner jusqu’à 1h/j sans recruter.
Implémenter une architecture RAG multitenant pour un SaaS en Node.js : guide technique pas à pas
20/07/2026
Implémenter une architecture RAG multitenant pour un SaaS en Node.js
Ce guide technique explique comment concevoir et implémenter une architecture RAG (retrieval-augmented generation) dans un SaaS multitenant en Node.js, avec PostgreSQL comme stockage principal des vecteurs. Public : CTO, lead dev, architecte backend. Objectif : obtenir une solution sécurisée, performante et isolée par client pour fournir des réponses enrichies par documents internes.
Pourquoi RAG multitenant ?
RAG permet de combiner recherche de documents et génération de texte pour des réponses contextualisées. Dans un SaaS multitenant il faut en plus garantir l'isolation des données, la latence acceptable et maîtriser les coûts d'appels aux modèles d'embeddings / LLM. Ce guide détaille les composants, le modèle de données, les requêtes de similarité, la sécurité par tenant et les optimisations opérationnelles.
Architecture proposée (haut niveau)
- API Node.js (Express / Fastify) : orchestration des appels recherche + génération
- PostgreSQL + extension vector (pgvector) : table documents avec colonne embedding
- Moteur d'embeddings (API fournisseur) : génération des vecteurs en batch
- Cache (Redis) : résultats RAG fréquents et embeddings temporaires
- RLS (Row Level Security) : isolation tenant au niveau BD
- Pipeline ingestion : normalisation, chunking, embedding, insertion
1. Schéma de données minimal
Exemple de table documents. Dimension d'embedding hypothétique : 1536 (adapter au fournisseur).
-- activer l'extension vector si pas encore faite
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id uuid PRIMARY KEY,
tenant_id uuid NOT NULL,
source text,
content text NOT NULL,
created_at timestamptz DEFAULT now(),
embedding vector(1536) -- dimension exemple
);Bonnes pratiques : stocker le texte original, métadonnées (source, langue, version), et un identifiant tenant explicite.
2. Isolation par tenant : RLS (Row Level Security)
Activer RLS garantit que toutes les requêtes respectent l'isolation même si une requête oublie de filtrer par tenant.
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
-- politique simple : autoriser uniquement les lignes matching app.current_tenant
CREATE POLICY tenant_isolation ON documents
USING (tenant_id = current_setting('app.current_tenant', true)::uuid);Dans chaque session DB, définissez la variable de session (via pooling) avant d'exécuter les requêtes :
-- côté application, après authentification du token utilisateur
await client.query("SET LOCAL app.current_tenant = $1", [tenantId]);Remarques : vérifiez que votre pooler (PgBouncer en transaction mode) conserve le comportement attendu ou utilisez une stratégie d'authentification DB par pool par tenant.
3. Ingestion : chunking, embeddings et insertion
Pipeline d'ingestion recommandé :
- Découper documents longs en chunks (200-1000 tokens selon cas d'usage)
- Nettoyage et métadonnées
- Batch d'appels d'embeddings pour réduire latence et coût
- Insertions en batch dans PostgreSQL
// pseudo Node.js (utilise pg)
const chunks = chunkText(doc.text, 500);
const embeddings = await fetchEmbeddingsBatch(chunks); // appel fournisseur
await client.query('BEGIN');
for (let i=0;i
4. Recherche de similarité (query-time)
Processus :
- Générer embedding de la requête utilisateur
- Interroger PostgreSQL pour top-k similaire en respectant tenant
- Post-traiter : reranking (BM25 + vector), filtrage, construire prompt pour LLM
-- requête de similarité (si pgvector installé, opérateur <-> disponible)
SELECT id, content, embedding <-> $1 AS score
FROM documents
WHERE tenant_id = $2
ORDER BY score
LIMIT 10;
Notes : selon votre configuration vous pouvez créer un index ANN (par ex ivfflat) pour accélérer les recherches sur grands jeux de vecteurs. Référez-vous à la documentation de pgvector pour la syntaxe d'index adaptée.
5. Exemple complet : endpoint Node.js
// pseudo-code express
app.post('/api/qa', authMiddleware, async (req, res) => {
const tenantId = req.user.tenantId;
const qEmbedding = await fetchEmbedding(req.body.question);
await db.query('SET LOCAL app.current_tenant = $1', [tenantId]);
const result = await db.query(
'SELECT content, embedding <-> $1 AS score FROM documents ORDER BY score LIMIT 8',
[qEmbedding]
);
const context = result.rows.map(r => r.content).join('\n---\n');
const prompt = buildPrompt(req.body.question, context);
const answer = await callLLM(prompt); // génération finale
res.json({ answer });
});
6. Optimisations perf et coûts
- Index ANN : indispensable pour millions de vecteurs. Sans index results = scan complet.
- Batch embeddings pour ingestion et pour requêtes user si plusieurs prompts
- Cache Redis des contextes ou des embeddings les plus demandés
- Reranking mixant BM25 (text search) et vecteurs pour meilleures précisions
- Métriques à surveiller : latence P50/P95, recall@k, coût embeddings par 1000 requêtes
7. Sécurité et gouvernance
- RLS obligatoire pour isolation tenant
- Chiffrement au repos et en transit (TLS pour Postgres)
- Limiter qui peut demander embeddings/générations (rate limit, quotas par tenant)
- Masking / suppression lorsque documents contiennent données sensibles
- Audit des prompts et logs ; attention à ne pas logger les embeddings bruts si risque de fuite
8. Erreurs fréquentes et solutions
- Erreur : requêtes de similarité très lentes → vérifier si pgvector est installé et s'il existe un index ANN
- Erreur : isolation manquante → vérifier RLS activé et politique bien définie
- Coût élevé d'embeddings → implémenter batch et caching; limiter fréquence des embeddings de requêtes redondantes
- Problème pooling / variable de session → tester avec votre pooler (PgBouncer) et privilégier set local ou stratégie de connexion par tenant
9. Mesures et KPIs techniques à suivre
Indicateur But Seuil cible P50 / P95 Latence recherche vectorielle UX acceptable <100ms / <300ms (selon SLA) Recall@10 Qualité des documents récupérés >80% pour cas métier critique Coût embeddings / mois Contrôle dépenses Budget par tenant Cache hit ratio Réduction appels externes >60%
Ressources et alternatives
PostgreSQL + pgvector est une solution simple et intégrée. Pour de très grands volumes ou besoins spécifiques, considérer des vectordb spécialisées (Milvus, Pinecone, RedisVector) et une architecture hybride. Pour de l'aide à l'industrialisation, voir nos pages techniques sur Node.js et PostgreSQL, ou notre service d'intelligence artificielle.
Conclusion
Une architecture RAG multitenant bien conçue combine isolation (RLS), indexation vectorielle performante et pipelines d'ingestion robustes. En pratique, priorisez l'isolation par tenant dès la conception, optimisez les coûts d'embeddings par batching et caching, et surveillez latence et qualité via KPIs ciblés.
Besoin d'aide pour prototyper ou industrialiser une solution RAG dans votre SaaS ? Vous pouvez demander un devis ou nous contacter.
