Comment concevoir un pipeline RAG sécurisé pour un ERP/CRM multitenant

Pipeline RAG sécurisé pour ERP/CRM multitenant — architecture recommandée

Résumé : cet article technique explique pas à pas comment concevoir un pipeline RAG (retrieval‑augmented generation) sécurisé et adapté à un ERP/CRM multitenant. Public : CTO, lead dev et ingénieurs backend qui doivent garantir isolation, confidentialité et auditabilité tout en gardant des performances acceptables.

Pourquoi la sécurité spécifique au RAG est critique dans un ERP/CRM multitenant

Un pipeline RAG combine ingestion de documents, embeddings, stockage vectoriel et appels vers un LLM. Dans un contexte ERP/CRM les données sont souvent sensibles (contrats, factures, informations clients). Sans isolation stricte, une requête d’un tenant peut remonter des chunks appartenant à un autre tenant — un risque inacceptable pour la conformité et la confiance client. Les bonnes pratiques d’architecture recommandent de centraliser l’orchestration et d’appliquer des contrôles d’accès stricts côté service avant toute récupération. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html?utm_source=openai))

Étapes concrètes pour concevoir le pipeline

1. Choisir le pattern de tenancy — trois options courantes :
   • Isolation physique (index/instance par tenant) : ++ sécurité, -- coût et complexité d’orchestration.
   • Isolation logique (namespace/tenant_id dans le même index) : compromis coût/maintenance, nécessite checks stricts au runtime.
   • Hybrid (groupes de tenants par namespace) : bon quand vous avez des centaines de petits tenants.
2. Mettre en place une couche d’orchestration (API gateway / RAG orchestrator) — toute requête passe par ce point unique qui :
   • valide l’identité et le scope (RBAC/claims),
   • applique les filtres tenant_id avant le retrieval,
   • enrichit la requête (redaction, suppression PII) et logge l’opération.
   Cette couche réduit la surface d’attaque et centralise l’audit. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/secure-multitenant-rag?utm_source=openai))
3. Isolation au niveau du vector store — recommandations pratiques :
   • Si votre vector DB le supporte, utilisez des namespaces/collections par tenant.
   • Sinon, stockez tenant_id en métadonnées et appliquez un filtre strict côté orchestrator ; considérez Row Level Security (RLS) pour une base relationnelle avec pgvector.
   • Effectuez des tests d’injection adversarial pour vérifier qu’une requête similaire ne remonte pas des chunks non autorisés.
4. Chiffrement et gestion des clés — principes :
   • Chiffrez au repos les documents sensibles et les embeddings si nécessaire (chiffrement côté serveur).
   • Privilégiez l’envelope encryption : une clé de données (DEK) pour chaque tenant chiffrée par une clé maître (KEK) détenue par un KMS.
   • Externalisez la gestion des clés à un service KMS (cloud KMS ou HSM) et appliquez rotation et séparation des privilèges. ([csrc.nist.gov](https://csrc.nist.gov/projects/key-management/key-management-guidelines?utm_source=openai))
5. Logging, observabilité et audit — ce qu’il faut tracer :
   • Qui a demandé quoi (user id / client id), quelle requête, quels documents ont été récupérés, horodatage et décision d’accès.
   • Conservez les logs d’accès et d’erreur dans un stockage immuable/horodaté pour audit.
6. Validation de la sortie et post‑filtrage — étape souvent oubliée :
   • Avant d’envoyer le prompt au LLM, appliquez des règles de redaction et vérification : suppression de PII, vérification que les citations proviennent bien du tenant.
   • Après génération, appliquez un module de sécurité qui détecte les hallucinations sensibles et empêche la fuite de secrets.

Snippets et patterns techniques

1) Middleware Node.js pour forcer tenant_id avant la recherche

// express middleware example
function requireTenant(req, res, next) {
  const tenantId = req.header('x-tenant-id') || req.user?.tenantId;
  if (!tenantId) return res.status(400).send('tenant id required');
  req.tenantId = tenantId;
  next();
}

// usage in search route
app.post('/api/rag/search', requireAuth, requireTenant, async (req, res) => {
  const { q } = req.body;
  const results = await vectorSearch(q, { tenantId: req.tenantId }); // voir pattern ci-dessous
  res.json(results);
});

2) Requête de recherche avec filtrage tenant_id (pseudo‑code pour pgvector ou vector DB)

-- pseudo SQL (pgvector + RLS)
SET LOCAL role = 'app_role';
SELECT id, score, payload
FROM vectors
WHERE tenant_id = $1
ORDER BY embedding <#> $2 -- similarity operator
LIMIT 10;

Activez Row Level Security (RLS) pour forcer la contrainte côté base si possible : c’est une défense en profondeur.

3) Exemple d'envelope encryption (Node.js, crypto) pour chiffrer un document avant stockage

const crypto = require('crypto');

// generate DEK (data encryption key)
const dek = crypto.randomBytes(32); // AES-256
// encrypt payload with AES-GCM
function encryptPayload(plain) {
  const iv = crypto.randomBytes(12);
  const cipher = crypto.createCipheriv('aes-256-gcm', dek, iv);
  const ciphertext = Buffer.concat([cipher.update(plain, 'utf8'), cipher.final()]);
  const tag = cipher.getAuthTag();
  return { iv: iv.toString('base64'), ciphertext: ciphertext.toString('base64'), tag: tag.toString('base64') };
}
// ENVELOPE: dek est chiffré par le KEK via KMS (ex: AWS KMS, Google KMS)

Ne stockez jamais la DEK en clair ; stockez uniquement la DEK chiffrée par le KEK. Pour la gestion des clés, suivez les recommandations NIST/OWASP. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html?utm_source=openai))

Performances, coûts et métriques à suivre

• Latence cible pour la recherche RAG : définissez un SLO (ex. p95 ≤ 300 ms pour retrieval seul).
• Coût par requête : surveillez nombre d'embeddings retrouvés et appels LLM par session. Batcher les embeddings lors de l’ingestion réduit coûts API.
• Taille des namespaces : au-delà de X millions de vecteurs (selon votre DB) envisagez sharding ou isolation physique.

Erreurs fréquentes et pièges à éviter

• Compter uniquement sur le scoring sémantique pour l’autorisation : la pertinence peut surfacer des documents non autorisés. Toujours filter par tenant_id avant le ranking.
• Ne pas chiffrer les embeddings ou considérer qu’ils ne sont pas sensibles : embeddings peuvent être reconstruitables dans certains cas.
• Logs contenant des extraits sensibles sans masquage — respectez la minimisation et protégez les logs.

Ressources et bonnes pratiques officielles

Pour la cryptographie et la gestion des clés, suivez les guides officiels NIST sur la gestion de clés ainsi que les cheat sheets OWASP (cryptographic storage, key management et RAG Security) qui donnent des contrôles pratiques et tests d’attaque à réaliser. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt2r1.pdf?utm_source=openai))

Checklist rapide avant mise en production

• Pattern de tenancy choisi et testé (namespace vs logical vs physical)
• Orchestrator centralisé avec validation d’identité et filtrage
• Chiffrement en repos + envelope encryption + KMS
• RLS ou filtres applicatifs testés avec tests adversariaux
• Audit logging immuable et plan de rétention
• Tests de charge et SLOs définis (p50/p95 latence, QPS)

Conclusion

Un pipeline RAG pour un ERP/CRM multitenant exige des choix d’architecture et des contrôles de sécurité dès la conception : isolation des données, gestion robuste des clés, orchestration centralisée et validation des sorties. En appliquant les patterns présentés (isolation, envelope encryption, RLS/filters, audits) vous réduisez fortement le risque de fuite inter‑tenant tout en gardant de bonnes performances.

Pour un accompagnement sur la mise en œuvre (audit d’architecture, prototype sécurisé ou intégration LLM dans votre ERP/CRM), nos experts peuvent vous aider à définir l’architecture et le plan d’action. Voir nos prestations : services IA et services ERP/CRM. Pour un audit rapide, demandez une séance de consulting offerte : séance de consulting.