Loading...
Conception et industrialisation d'applications d'IA générative s'appuyant sur la recherche augmentée par génération (RAG) : cartographie et nettoyage du corpus, indexation vectorielle, orchestration LLM, garde-fous de confidentialité, journalisation, bench de qualité et audits réguliers.
Les modèles de langage génératifs (Claude, GPT, Gemini, Mistral, Llama) sont remarquables sur les connaissances générales, mais limités sur les corpus spécialisés et propriétaires : documentation interne, contrats, fiches produit, base de tickets, jurisprudence. La recherche augmentée par génération (RAG) comble cet écart : on récupère les passages pertinents depuis une base documentaire indexée, on les fournit au modèle dans le prompt, et le modèle génère une réponse sourcée appuyée sur les passages retournés. Ce pattern résout trois problèmes en un : éliminer les hallucinations sur le corpus métier, garder la traçabilité des sources, et permettre des mises à jour rapides sans ré-entraîner le modèle. Les cas d'usage typiques en entreprise sont la recherche dans la documentation interne, l'assistance support client, le traitement documentaire (extraction, qualification, comparaison) et l'exploitation d'un patrimoine éditorial (médias, télécoms, secteur public).
Un POC RAG fonctionne typiquement en deux semaines : indexation vectorielle, prompt template, LLM cloud. Mais le passage en production réelle révèle plusieurs écarts. Premièrement, la qualité : un retrieval qui marche sur dix questions de démo ne tient pas sur mille requêtes utilisateur réelles. Deuxièmement, la sécurité : le POC envoie tout le corpus au modèle, sans filtrage, ce qui n'est pas tenable face aux exigences sectorielles. Troisièmement, l'observabilité : sans journalisation et bench continu, on ne sait pas si la qualité dérive. Enfin, les coûts d'inférence explosent au volume si le pipeline n'est pas optimisé. Notre expertise IA, Data et Automatisation traite spécifiquement cet écart entre POC et production, encadrée par la méthodologie ATLAS.
Le choix du modèle d'inférence dépend du cas d'usage. Pour la majorité des cas RAG en entreprise, Anthropic Claude Sonnet 4.6 ou OpenAI GPT-4o offrent le meilleur rapport qualité/coût avec une fenêtre de contexte large (200 k tokens et plus) qui simplifie le retrieval. Pour des cas régulés ou souverains, des modèles open source (Llama, Mistral, Qwen) déployés en self-hosted sont possibles, au prix d'une infrastructure plus lourde. Pour des cas latence-critiques, des petits modèles spécialisés (Claude Haiku, GPT-4o-mini, Mistral Small) suffisent souvent. Le bon pattern n'est presque jamais un seul modèle : routing dynamique entre modèles selon la complexité de la requête, caching agressif sur les prompts répétés, fallback sur un modèle plus léger en cas de pic de charge.
Base documentaire propriétaire (PDF, Word, intranet, ticketing), besoin métier de recherche augmentée par IA
Choix par défaut. Claude excelle sur le raisonnement et le suivi d'instructions, pgvector évite une dépendance externe, l'orchestration custom (Python ou Node) reste simple à maintenir et à évoluer. Approche recommandée pour les organisations Cloud-agnostic ou multi-cloud.
Organisations engagées dans Microsoft Azure. Stack pleinement managée et gouvernée, intégration native avec Microsoft Purview, conformité Microsoft Compliance Manager, accès facilité aux modèles GPT-4o et o1.
Organisations engagées dans AWS. Bedrock multi-modèles (Claude, Llama, Mistral, Cohere), OpenSearch pour le vecteur, Step Functions pour l'orchestration, gouvernance via AWS IAM et CloudTrail.
Organisations engagées dans Google Cloud. Gemini en accès direct, AlloyDB pour le vecteur, Vertex AI Pipelines pour l'orchestration et l'évaluation continue.
Un projet GenAI RAG en production se structure généralement sur trois à neuf mois selon la complexité du corpus et les exigences de gouvernance. Pour un cas d'usage circonscrit (documentation interne, support client) avec un corpus de quelques milliers de documents, comptez trois à cinq mois avec une cellule de quatre personnes : un architecte IA, un ingénieur RAG senior, un développeur full-stack, un référent métier détaché à 30 %. Pour des programmes ambitieux avec multi-cas d'usage, gouvernance AI Act, monitoring continu, comptez six à neuf mois et une cellule de six à huit personnes incluant un data scientist et un référent juridique ou compliance.
Sous-estimer la qualité du corpus source. Un RAG ne corrige pas les erreurs, contradictions ou doublons du corpus — il les amplifie. Un corpus mal préparé conduit à un système qui hallucine en se prétendant sourcé.
Audit corpus systématique en début de projet : déduplication, détection de versions périmées, identification des contradictions internes, classification par fiabilité. Les documents critiques sont annotés et certifiés par un référent métier. Le pipeline d'ingestion intègre des règles de qualité (longueur minimale, langue détectée, métadonnées obligatoires) et un registre des rejets révisé périodiquement. Voir la méthodologie ATLAS.
Confondre POC RAG et RAG en production. Le POC fonctionne sur dix questions de démo ; en production, on découvre les requêtes ambiguës, les questions multi-tours, les attaques de prompt injection.
Bench de qualité construit en amont, sur des jeux de tests représentatifs (cinquante à deux cents questions issues de logs réels ou d'entretiens utilisateurs). Le bench couvre faithfulness, pertinence du contexte, pertinence de la réponse. Il est exécuté à chaque modification du pipeline et en continu en production sur un échantillon. Aucun déploiement majeur sans amélioration mesurée du bench.
Négliger les garde-fous de confidentialité. Envoyer du corpus métier au modèle sans filtrage expose des données personnelles ou du secret d'affaires, violant Loi 25, RGPD ou contrats clients.
Couche de redaction explicite entre le retrieval et le LLM : détection automatique de PII, masquage paramétrable, allowlist de champs autorisés, audit des fuites par tests adversariaux. Pour les cas ultra-sensibles, déploiement on-premise ou en cloud souverain avec modèle self-hosted (Llama, Mistral). Tous les prompts et réponses sont journalisés avec leur niveau de sensibilité.
Lancer en production sans observabilité. Sans logs, traces et monitoring, on ne voit pas la dérive de qualité, les abus utilisateurs ou les pics de coûts.
Stack observabilité dès J1 : journalisation prompts et réponses (LangSmith, Langfuse, ou solution custom), traces distribuées (OpenTelemetry), tableaux de bord coûts, alertes sur latence et taux d'erreur. Revue hebdomadaire des dérives, alertes automatiques sur dépassement budgétaire ou échecs récurrents.
Ignorer les coûts à grande échelle. Le POC coûte trente euros par jour ; à mille utilisateurs, mille requêtes par jour, cela peut atteindre plusieurs milliers d'euros mensuels si rien n'est optimisé.
Stratégie coûts dès la conception : caching agressif (prompt cache Anthropic, semantic cache custom), routing dynamique entre modèles selon la complexité, batch sur les tâches non-temps-réel, prompts optimisés (réduction de tokens). Estimation mensuelle revue à chaque jalon, alertes sur dépassement, choix de modèle adapté à chaque tâche (Haiku ou GPT-4o-mini pour les tâches simples, Sonnet ou GPT-4o pour le raisonnement complexe).
Plateforme NLP et human-in-the-loop pour la qualification sémantique des contenus éditoriaux d'un opérateur télécom national. Règles tagger, apprentissage continu du lexique, indexation vectorielle (pgvector), modèles Claude pour le raisonnement, journalisation et tableau de bord qualité éditoriale.
Capacité de programme : plateforme d'agents IA pour le traitement documentaire (extraction de clauses, contrôle de conformité, pré-validation). Pipeline RAG, agents spécialisés par typologie, interface humaine de validation. Cadrage type que nous savons mettre en place.
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.
Cela dépend de la taille du corpus, du volume de requêtes et du choix du modèle. Pour un RAG entreprise typique (50 à 500 k documents, 100 à 1 000 requêtes/jour, modèle mid-tier type Claude Sonnet ou Mistral Medium) : coût de build 80 à 200 k€ pour un déploiement production en 6-12 semaines, puis 2 à 8 k€/mois en run (appels API LLM + hébergement base vectorielle + monitoring). Pour un RAG à fort volume (millions de documents, 10 k+ requêtes/jour, modèle premium) : build 200 à 600 k€, run 15 à 50 k€/mois. Self-hosted on-premise (vLLM + Llama ou Mistral + GPU) déplace le coût du run vers l'investissement — 100 à 300 k€ d'infrastructure GPU plus 1-2 ETP dédiés à l'exploitation. Le facteur qui pèse le plus n'est rarement la facture LLM — c'est la qualité du contenu et l'évaluation continue. Voir le parcours GenAI RAG en production.
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.
Nous cadrons la trajectoire, le chiffrage et les livrables en un premier échange de trente minutes. Un POC court peut être proposé avant engagement du programme complet.
Lancer ce parcours →