pipeline RAG pour ERP/CRM : déploiement, mise à l’échelle et sécurité
Ce guide s'adresse aux CTO et lead dev qui doivent intégrer une solution Retrieval-Augmented Generation (RAG) dans un ERP ou un CRM. Il décrit, pas à pas, un pipeline technique prêt à la production : ingestion et nettoyage des données, création d'embeddings, stockage dans une vector database, stratégie de récupération, déploiement et bonnes pratiques sécurité/observabilité. À la fin vous aurez un design réutilisable et des snippets pour démarrer une preuve de concept robuste.
Pourquoi un pipeline RAG spécifique à un ERP/CRM ?
Les données d’un ERP/CRM sont hétérogènes (factures, fiches clients, tickets, notes commerciales). Une implémentation RAG standard peut fonctionner, mais pour la production vous devez répondre à trois contraintes fortes : séparation multi-tenant, cohérence des métadonnées métier, et maîtrise des coûts de consommation de tokens. Le pipeline présenté ici vise ces contraintes.
Architecture haute niveau
- Ingestion : ETL/CDC depuis bases opérationnelles (Postgres, SQL Server, file storage).
- Normalisation et chunking : découper documents, ajouter métadonnées (tenant_id, document_type, timestamp).
- Embeddings : service centralisé (API externe) ou local (model on-premise).
- Vector store : pgvector / Milvus / Pinecone / Weaviate selon besoins.
- Retrieval & ranking : récupération par similarité + reranking sémantique ou lexical.
- Serve : API d’assistant qui combine retrieval + génération (Llama, OpenAI, etc.).
- Monitoring et sécurité : métriques latence, coût, qualité; chiffrement, audits et contrôle d’accès.
Étape 1 — ingestion et chunking (code)
Principes : conserver les métadonnées métier, éviter les chunks trop courts, et stocker original_id pour traçabilité.
def chunk_text(text, max_tokens=500):
# simple découpage par paragraphe puis par taille
paragraphs = text.split("\n\n")
chunks = []
current = ""
for p in paragraphs:
if len(current) + len(p) > max_tokens:
if current:
chunks.append(current)
current = p
else:
current += "\n\n" + p if current else p
if current:
chunks.append(current)
return chunks
Exemple d’insert vers une table Postgres avec pgvector (schéma simplifié).
-- SQL (schema)
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
tenant_id TEXT NOT NULL,
original_id TEXT NOT NULL,
document_type TEXT,
content TEXT,
metadata JSONB,
embedding vector
);
Insertion via Python après calcul d'embedding :
import psycopg2
def upsert_embedding(conn, tenant_id, original_id, chunk, embedding, metadata):
with conn.cursor() as cur:
cur.execute("""
INSERT INTO documents (tenant_id, original_id, document_type, content, metadata, embedding)
VALUES (%s, %s, %s, %s, %s, %s)
""", (tenant_id, original_id, metadata.get("type"), chunk, json.dumps(metadata), embedding))
Étape 2 — création des embeddings
Choix critique : API hébergée (OpenAI, Cohere) ou modèle local (sentence-transformers, LLM open-source). Avantages et inconvénients :
- API externe : rapide à implémenter, scalabilité automatique, coût variable.
- Modèle local : contrôle des données, coût fixe infra, latence variable selon infra.
Exemple générique d'appel à un service d'embeddings (pseudo-code) :
def compute_embedding(text, model="embedding-v1"):
# wrapper pour appeler votre fournisseur d'embeddings
response = embedding_client.create(input=text, model=model)
return response.embedding # vecteur float[]
Astuce : batcher les textes pour réduire les appels réseau et respecter les quotas. Gérer les retry en cas de rate limit.
Étape 3 — modèle de stockage et stratégies multi-tenant
Deux approches courantes :
- Collections par tenant : isoler physiquement chaque tenant dans sa collection/namespace. + sécurité, - complexité d’opération si beaucoup de tenants.
- Table unique avec filtrage tenant_id : plus simple à gérer, nécessite indexation appropriée et quotas logiques. Bon si le nombre de tenants est élevé mais chaque tenant a peu de données.
Trade-off dépend du nombre de tenants et de la sensibilité des données. Pour un ERP/CRM, privilégiez l’isolation logique (tenant_id) au début, passez à l’isolation physique si contrainte de conformité ou performance.
Étape 4 — récupération et reranking
Processus typique :
- Compute embedding de la requête.
- Recherche vectorielle proche en filtrant par tenant_id et éventuellement document_type.
- Reranker les top-k (par score cosinus + signaux métier, ex. date, confiance).
- Assembler contexte pour le modèle génératif avec prompt engineering.
-- Exemple SQL pgvector
SELECT id, content, metadata
FROM documents
WHERE tenant_id = 'tenant_123'
ORDER BY embedding <-> query_embedding
LIMIT 10;
Note : l'opérateur <-> est l'opérateur de distance de pgvector. Adaptez selon votre vector store.
Étape 5 — déploiement et mise à l’échelle
Recommandations pratiques :
- Déployer le service d’embeddings séparément pour scaler indépendamment du service de génération.
- Utiliser des jobs batch pour l’ingestion initiale et la réingestion incrémentale via CDC.
- Mettre en place un cache pour les embeddings de requêtes fréquentes et les réponses longues.
- Dimensionner la vector DB en fonction du throughput de recherche et du SLA. Surveiller latence p99.
Exemple docker-compose minimal pour une vector DB locale (illustratif) :
version: '3.8'
services:
postgres:
image: postgres:14
environment:
POSTGRES_PASSWORD: example
volumes:
- pgdata:/var/lib/postgresql/data
volumes:
pgdata:
Pour une production vraie, privilégiez des clusters managés ou K8s avec monitoring et autoscaling.
Sécurité, conformité et gouvernance
- Ne jamais envoyer au modèle externe des informations sensibles sans anonymisation. Définir des règles de masquage PII lors de l’ingestion.
- Chiffrement des embeddings et des documents au repos. Gérer les clés via KMS.
- Audit des requêtes : qui a demandé quoi, quelles sources ont été utilisées pour une réponse.
- Politique de rétention : versioning et suppression pour respecter la réglementation.
Si vous utilisez un fournisseur externe, documentez le partage de données et mettez en place un proxy pour filtrer et logguer les inputs.
Observabilité et mesures clés
Métriques à suivre dès le POC :
- Latence totale (retrieval + génération) p50/p95/p99.
- Taux de hit du cache et nombre de requêtes vector DB par minute.
- Qualité retrieval : taux de réponses pertinentes via tests manuels échantillonnés.
- Coût par requête (embeddings + génération).
Exportez traces et logs vers un APM pour corréler erreurs applicatives et performances de la vector DB.
Erreurs fréquentes et dépannage
- Embedding dimension mismatch : vérifier que le modèle d’embeddings et la colonne vector ont la même dimension.
- Baisse de pertinence : vérifier le chunking, la perte de métadonnées et le scoring final.
- Dégradations de latence : surveiller la mémoire du vector store et le IO disque, activer répliques si nécessaire.
- Fuites de données : auditer les prompts envoyés à des APIs externes.
Exemple de check rapide
- Tester la similarité locale : calculer la distance entre deux embeddings connus.
- Vérifier les logs d’erreurs du service d’embeddings pour rate limits.
- Comparer résultats retrieval avec une recherche textuelle basique pour détecter régressions.
Bonnes pratiques résumé
- Conserver métadonnées métier détaillées pour le reranking et l’audit.
- Batcher et paralléliser l’ingestion avec retries et backoff.
- Séparer les composants pour scaler indépendamment : ingestion, embeddings, vector DB, génération.
- Choisir isolation logique vs physique selon le niveau de conformité et le nombre de tenants.
- Mettre en place des tests qualité retrieval automatisés dans votre pipeline CI/CD.
Ressources et suites possibles
Pour aller plus loin : intégrer ce pipeline dans votre architecture SaaS, ajouter observabilité dédiée et workflows de gouvernance. Si vous utilisez Python et Postgres, la combinaison Python + PostgreSQL avec pgvector est un point de départ pragmatique. Pour un projet ERP/CRM plus large, pensez à articuler ce pipeline avec votre backoffice métier via vos services ERP/CRM et votre stratégie IA globale intelligence artificielle.
Conclusion rapide : un pipeline RAG pour ERP/CRM demande des choix techniques clairs sur l’isolation tenant, la stratégie d’embeddings et la vector DB. Commencez par un POC limité à 1 ou 2 cas d’usage métier, mesurez pertinence et coût, puis industrialisez par itérations.
Besoin d’un accompagnement pour monter un POC ou dimensionner une solution RAG pour votre ERP/CRM ? Obtenez un audit ou un devis rapide via notre page de devis.
