Déployer une application d'IA générative en production avec un pipeline RAG gouverné.

Cela dépend de la maturité du corpus, des exigences de gouvernance et de la volumétrie. Pour un cas d'usage circonscrit (documentation interne, support client, FAQ enrichie), comptez trois à cinq mois avec une cellule de quatre personnes pour aller du POC à la production. Pour un programme ambitieux avec multi-cas d'usage, gouvernance AI Act et monitoring continu, comptez six à neuf mois avec une équipe de six à huit personnes. La durée dépend essentiellement de la qualité du corpus en amont : un corpus déjà nettoyé et catalogué accélère le projet d'au moins deux mois.

Le choix dépend du cas d'usage et des contraintes de gouvernance. Pour la majorité des cas RAG en entreprise, Claude Sonnet 4.6 ou GPT-4o offrent le meilleur rapport qualité/coût grâce à leur grande fenêtre de contexte. Gemini est pertinent dans l'écosystème Google Cloud. Pour des cas régulés ou souverains, les modèles open source (Llama 4, Mistral, Qwen) déployés en self-hosted sont possibles mais demandent une infrastructure plus lourde. En pratique, un système RAG mature combine plusieurs modèles : un grand modèle pour le raisonnement complexe, un petit modèle pour les tâches simples (classification, extraction), avec routing dynamique.

Trois piliers. Premièrement, un bench de qualité construit en amont avec cinquante à deux cents questions de référence, exécuté à chaque modification du pipeline et en continu en production sur un échantillon. Les métriques standards sont la faithfulness (la réponse est-elle fidèle aux passages retournés ?), la pertinence du contexte et la pertinence de la réponse. Deuxièmement, une boucle humain-dans-la-boucle (HITL) sur les cas critiques pour valider les sorties sensibles. Troisièmement, une observabilité production complète qui détecte les dérives en temps réel : nouvelles classes de questions, taux d'hallucination, latence, coûts.

Deux approches complémentaires. La première est la redaction côté pipeline : avant d'envoyer le contexte récupéré au modèle, on applique un filtrage automatique des informations personnelles, des secrets et des champs sensibles, avec une allowlist explicite des champs autorisés. La seconde est le choix d'un déploiement adapté : pour les cas ultra-sensibles, un modèle self-hosted en cloud souverain ou on-premise (Llama, Mistral) garantit qu'aucune donnée ne sort du périmètre. Anthropic et OpenAI offrent par ailleurs des engagements contractuels sur la non-utilisation des données pour l'entraînement, qui sont nécessaires mais pas toujours suffisants selon le secteur.

Dans la majorité des cas d'usage entreprise, le RAG est préférable au fine-tuning. Il est plus simple, moins coûteux, plus facile à mettre à jour (ajouter une nouvelle source = enrichir l'index, pas réentraîner) et plus traçable (les sources citées sont visibles). Le fine-tuning a sa place pour ajuster le style ou le ton d'un modèle, ou pour des cas où le retrieval ne suffit pas (par exemple, internaliser une logique spécifique très répétitive). En pratique, beaucoup de projets ambitieux combinent les deux : un fine-tune léger sur le style, un RAG pour la connaissance factuelle.

L'AI Act classifie les systèmes IA par niveau de risque. Un assistant RAG d'aide à la rédaction documentaire est typiquement à risque limité, ce qui impose la transparence vis-à-vis des utilisateurs (indiquer qu'ils interagissent avec un système IA) et la documentation des sources et des limites. Un système RAG utilisé dans des décisions à fort impact (recrutement, crédit, santé) bascule en risque élevé, ce qui impose une évaluation de conformité, une supervision humaine, des journaux et des contrôles de robustesse. La méthodologie ATLAS intègre cette classification dès la phase de cadrage et conditionne le niveau de gouvernance déployé en conséquence.

Le coût d'un RAG en production se décompose en construction et en exploitation, et les deux répondent à des variables différentes. Pour la construction : la taille et l'hétérogénéité du corpus, et surtout la qualité du travail d'extraction et de découpage documentaire, qui domine largement l'effort. Pour l'exploitation : le volume de requêtes quotidiennes et le choix du modèle, auxquels s'ajoute l'hébergement de la base vectorielle. Une variante auto-hébergée déplace le coût du run vers l'investissement matériel et vers les équipes d'exploitation. Cadrage initial gratuit, de 30 minutes à 2 heures.

Cinq pratiques que nous appliquons sur tout RAG en production : (1) retrieval hybride (sémantique via embeddings + mot-clé via BM25, puis re-ranking) — le pur sémantique loupe systématiquement les requêtes en termes exacts. (2) Chunking adaptatif par type de document — contrats juridiques et fiches produit demandent des tailles de chunks différentes. (3) Citation des sources dans chaque réponse — indispensable pour la confiance et l'auditabilité. (4) Évaluation continue avec ragas ou un bench custom, exécuté à chaque évolution de modèle ou de prompt — la qualité d'un RAG dérive silencieusement sinon. (5) Filtrage des données personnelles avant LLM — pseudonymisation avant envoi au modèle. Au-delà : hébergement régional pour conformité (Loi 25, RGPD), checkpoints human-in-the-loop sur les décisions sensibles, et monitoring FinOps de la facture token. Voir le parcours GenAI RAG en production.