Après une année consacrée aux expérimentations IA, nous constatons chez Smartpoint que la mise en production suscite de nouvelles préoccupations. De plus en plus de DSI (voire le Comex) se posent la question de la souveraineté des données. L’IA, ce n’est pas qu’une question de performance … mais aussi de territoire, de dépendance et de responsabilité.

Risques d’exposition des données, forte dépendance vis-à-vis des acteurs américains (vendor lock-in) et contexte géopolitique instable, tous les facteurs sont réunis. Le temps est venu de se poser la question de comment concevoir une plateforme IA souveraine capable d’opérer un RAG en production.

Mettre en production l’IA générative sans audit possible et avec des coûts non maîtrisés n’est pas une option viable.

« La souveraineté IA est liée au contrat d’exploitation : qui possède vos clés, où sont hébergés vos modèles et sous quelle juridiction tombent vos données » souligne Luc Doladille, Directeur conseil data & IA,

Pourquoi un RAG souverain ?

Le passage à l’IA agentique et le déploiement d’un copilote IA privé en entreprise soulèvent des vulnérabilités critiques que les solutions SaaS « boîte noire » ne peuvent pas couvrir. Pour une direction DSI, l’enjeu n’est pas d’accéder à un modèle performant mais de garantir la maîtrise du cycle de vie des données.

Le système doit être exploitable, auditable et gouvernable.

La souveraineté est le socle de confiance indispensable pour soutenir l’innovation. Opérer une architecture RAG souveraine permet de relier la puissance des LLM au patrimoine documentaire de l’entreprise, tout en garantissant un cadre d’hébergement et d’exploitation maîtrisé (cloud de confiance, exigences sécurité, conditions contractuelles). C’est cette maîtrise qui permet de construire une IA générative compatible avec les exigences RGPD et prépare celles de traçabilité, de documentation et de tenue de logs lorsque les cas d’usage relèvent des obligations de l’AI Act.

Enfin, une approche souveraine remet la DSI en capacité de piloter le TCO d’un RAG (coûts d’inférence, de réindexation, d’observabilité, d’exploitation) et d’offrir aux métiers un copilote privé fiable, mesuré, et sous contrôle.

Plateforme IA souveraine : de quoi parle-t-on ?

Pour nos experts Data IA, la souveraineté se traduit par un contrat d’exploitation vérifiable.

Une plateforme IA souveraine repose sur quatre piliers indissociables :

1. Souveraineté des données : localisation, classification, chiffrement, politiques de rétention, conditions d’accès et de transfert.
2. Souveraineté du modèle : liberté de choix, portabilité, réversibilité, capacité multi-modèles, gouvernance des versions.
3. Souveraineté opérationnelle : logs et traces, IAM, SLO, runbooks, supervision et capacité de rollback.
4. Souveraineté juridique & conformité : exigences RGPD, cadre contractuel de sous-traitance et capacité à démontrer la conformité y compris sur les dimensions de documentation et de record-keeping attendues par l’AI Act lorsque applicable.

En France, la qualification SecNumCloud sert souvent de repère “cloud de confiance” pour les environnements sensibles.

-> A lire sur ce sujet : Règlement (UE) 2024/1689 du Parlement européen et du Conseil du 13 juin 2024 établissant des règles harmonisées concernant l’intelligence artificielle. https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202401689 et Posture générale et actions de l’ANSSI sur le cloud, SecNumCloud.

Architecture cible, les 7 briques d’un RAG souverain industrialisable

Nos architectes Data & IA recommandent une architecture structurée autour de 7 briques intégrées dans un cadre d’hébergement et d’exploitation de confiance :

1. Compute & Hosting : Hébergement dans un environnement maîtrisé (cloud qualifié SecNumCloud, on-premise ou hybride) afin de réduire la surface d’exposition et de garantir la résidence des données.
2. Model Layer : Accès à des LLM privés ou opérés dans un cadre souverain, avec capacité multi-modèles pour arbitrer performance, coût, latence et contraintes de conformité.
3. Knowledge Layer : Maîtrise de l’index et du vector store (hybrid search, rerank), avec gouvernance de la fraîcheur (réindexation / re-embedding) et des sources.
4. Orchestration : Pipelines RAG incluant guardrails, routage intelligent et quality gates (évaluations) pour valider groundedness, conformité et actions autorisées avant restitution.
5. Security & IAM : Politiques RBAC/ABAC, gestion des secrets, segmentation réseau et policy-as-code pour tracer et contrôler les accès comme les usages.
6. Observabilité & LLMOps : Monitoring continu (traces, latence, erreurs, groundedness, dérive), journalisation maîtrisée des prompts (masquage PII, rétention), et mécanismes de rollback pour prévenir drift et régressions. (Pour approfondir : Industrialisation RAG, piloter l’IA en production )
7. FinOps IA & TCO : Pilotage du coût global (tokens, rerank, réindexation, stockage, observabilité, run) pour éviter les surprises budgétaires et tenir un TCO RAG réaliste. (À lire : Combien coûte un agent IA ? Architecture, stack technique et TCO réel pour les DSI.)

La finalité est de rendre la plateforme IA auditable (logs), réversible (modèle & stack) et opérable (SLO + runbooks).

“La souveraineté n’impose pas un mono-fournisseur local : elle requiert la capacité d’arbitrer, d’auditer et de sortir.” Luc Doladille, Directeur Conseil Data & IA, Smartpoint

Grille de critères pour évaluer une plateforme IA / RAG en termes de souveraineté

Une plateforme IA souveraine, c’est la capacité vérifiable à maîtriser vos données, vos modèles, vos accès, vos coûts… et votre sortie.

Mode d’emploi
Note chaque critère : 0 = absent, 1 = partiel, 2 = maîtrisé.
Score max : 30 points.

Vous avez un RAG qui fonctionne en POC, et vous voulez vérifier qu’il est gouvernable, auditable et maîtrisé en coûts avant la mise en production ? Contactez-nous.

Toutes vos questions plateforme IA, RAG et souveraineté

Chez Smartpoint, ESN spécialisée en Data et Intelligence Artificielle, nous observons un basculement dans les priorités IA des directions IT.
Il ne s’agit plus de tester des modèles ou de de multiplier POC, mais de déployer des agents IA capables d’agir concrètement sur les processus métiers, à commencer par ceux de la DSI elle-même.

D’un côté, nous constatons que les investissements en IA sont bien là et que l’adoption progresse rapidement. De l’autre, le passage à l’échelle reste un obstacle majeur. De nombreux projets ne dépassent jamais le stade du POC ou se « crashent en vol » dès les premiers mois de mise en production.

D’ailleurs, de nombreuses sourcent documentent ce phénomène, les investissements IA se déplacent progressivement du calcul pur (heavy compute) vers l’intégration directe de l’IA dans les workflows opérationnels. Autrement dit, la valeur ne se situe plus dans le modèle, mais dans sa capacité à s’intégrer, s’exécuter et être piloté dans le système d’information.

Dans la réalité de projets IA, les DSI sont confrontés à de nouveaux enjeux : dépendance technologique, intégration SI incomplète, explosion des coûts cachés et exigences réglementaires accrues. Et une question revient : combien coûte réellement un agent IA en production ?

·

Ces chiffres masquent toutefois une réalité moins visible. L’adoption de l’IA ne veut pas dire maîtrise des coûts, ni pérennité en production ! Et c’est précisément là que les agents IA posent de nouveaux défis aux directions IT.

1. Les 5 risques de l’IA Agentique pour les DSI

Le déploiement d’agents IA en production expose le SI à des vulnérabilités d’un genre nouveau. Dès qu’un agent IA est intégré au système d’information, il accède aux données métiers et il interagit avec des processus existants et cela génère de nouveaux risques qui expliquent pourquoi une grande part des projets d’IA générative ne dépasse jamais le stade du POC ou l’épreuve du passage à l’échelle.

1. La dépendance technologique (Vendor Lock-in)

Avec près de 70 % des entreprises françaises qui s’équipent aujourd’hui via des solutions « sur étagère », les directions IT s’exposent à une forte dépendance vis-à-vis des systèmes propriétaires. Ces plateformes promettent une mise en œuvre rapide mais enferment souvent la DSI dans des choix technologiques dont il est difficile de s’extraire par la suite. Lorsque l’éditeur modifie sa politique tarifaire, fait évoluer ses modèles ou impose ses propres outils d’orchestration, l’entreprise se retrouve captive et cela a un impact direct sur les coûts, la performance et l’évolutivité du SI.

Alors que les architectures seront de plus en plus agentiques et pilotées par le langage naturel dans le futur, cette dépendance est clairement à prendre en considération dès aujourd’hui. Elle freine en effet la capacité à intégrer l’agent IA dans une architecture SI composable et API-first (Sur ce sujet, lire notre article « Architecture SI AI-Ready ? Construire un SI conversationnel et agentique piloté par le langage naturel » ). Chez Smartpoint, nos experts Data IA recommandent fortement d’adopter une stratégie open stack, pour que la DSI gardent la maîtrise des LLM, des outils d’orchestration et des couches d’intégration.

2. La dérive sémantique et l’obsolescence des connaissances

Contrairement au code traditionnel, un agent IA n’est pas figé, il est vivant. Il évolue au rythme des modèles sous-jacents, des données métiers et des référentiels documentaires auxquels il accède. Sans un dispositif de supervision avancé, la nature dynamique des agents IT conduit progressivement mais inexorablement à une dérive sémantique. L’agent commence à halluciner, il donne des réponses approximatives, s’appuie sur des informations obsolètes ou génère des contenus qui ne sont plus alignés avec la réalité opérationnelle.

A lire sur ce sujet IA générative : comment atténuer les hallucinations MAG IT

Chez Smartpoint, nous mettons en place un monitoring rigoureux de la groundedness, afin de vérifier la véracité des réponses par rapport aux sources utilisées. Les hallucinations, même si elles sont à la marge, érodent la confiance des utilisateurs et freinent l’adoption métiers … sans compter l’impact en terme de crédibilité pour la DSI.

Dans les projets d’agents IA en production, ce risque est pour nous le risque N°1 !

3. L’explosion du TCO et le « Shadow AI »

Le coût total de possession d’un agent IA est souvent sous-estimé… Sans approche FinOps, la consommation de tokens, l’usage intensif des modèles et l’absence d’optimisation des requêtes entrainent l’explosion des coûts. Cette dérive est d’autant plus difficile à maîtriser que les coûts sont répartis entre l’infrastructure, les modèles, l’intégration et l’exploitation.

À cela s’ajoute le phénomène du Shadow AI de plus en plus présent dans les entreprises. Les métiers développement directement leurs agents IA, sans impliquer ni d’ailleurs informer la DSI, à partir d’outils SaaS ou de plateformes low-code. Ces initiatives non cadrées ni gouvernées créent des failles de sécurité, des silos de données et rendent impossible toute vision consolidée du TCO sans compter les risques opérationnels.

4. L’Action Layer ou le risque « Write »

Le franchissement de la frontière entre Read et Write marque un changement de nature de l’agent IA. En mode Read, l’agent observe et assiste la décision sans interaction directe avec les systèmes transactionnels. En mode Write, il est en capacité d’agir sur le SI, d’exécuter des opérations et de modifier des états métiers. À ce stade, l’agent ne relève plus de l’aide à la décision, mais de l’exécution, avec des exigences de contrôle, de sécurité et de traçabilité comparables à celles d’un composant applicatif critique.

Un agent mal cadré peut déclencher des transactions erronées, modifier des référentiels critiques ou provoquer des effets de bord complexes à détecter a posteriori. L’Action Layer doit reposer sur des garde-fous explicites (guardrails), une gestion des identités et des accès (IAM) rigoureuse, ainsi que des dispositifs de validation humaine pour les actions sensibles. Sans ces briques, le passage à l’agentique expose directement le SI à des risques trop importants.

5. La non-conformité à l’AI Act

En Europe, la montée en puissance de la régulation renforce les exigences autour des systèmes d’IA. L’AI Act impose progressivement des obligations de traçabilité, d’explicabilité et d’auditabilité des décisions prises par une intelligence artificielle. Une architecture agentique qui ne permet pas de retracer les sources utilisées, de comprendre le raisonnement suivi par l’agent ou de démontrer le respect des règles d’usage s’expose à des sanctions lourdes.

Au-delà de l’enjeu réglementaire, l’absence de conformité rend tout simplement impossible le maintien en production d’un agent IA. Pour les DSI, la conformité est un pré-requis d’architecture, étroitement lié aux choix de stack, de gouvernance et de supervision, comme cela est déjà le cas pour les architectures RAG opérées en production.

2. Architecture SI AI-Ready

Un SI composable, API-first et « agent-callable »

Dans une architecture agentique, chaque fonction métier (commande, facturation, identité, support, référentiels, services IT, etc.) est exposée sous forme de services API-first, documentés, versionnés et sécurisés. Cette approche architecturale par composants permet à l’agent IA d’interagir avec le SI de manière contrôlée, sans dépendre d’écrans ou de parcours utilisateurs pensés pour des humains.

Un SI « agent-callable » est un SI AI-Ready dans lequel les capacités d’action sont clairement définies, limitées et gouvernées. L’agent n’est pas amené à explorer le système par lui-même, il agit dans un périmètre strictement autorisé, en cohérence avec les règles métiers et les politiques de sécurité existantes.

Une couche SI conversationnelle

La couche conversationnelle est le point d’entrée des architectures agentiques. Elle permet de traduire une demande exprimée en langage naturel en une série d’actions compréhensibles par le SI. Ce n’est pas une simple interface type chabot, cette brique permet de normaliser les intentions, de contextualiser les demandes et de les router vers les bons services ou agents spécialisés.

En séparant l’interface conversationnelle de la logique d’exécution, la DSI conserve la maîtrise des usages tout en offrant aux métiers une meilleure expérience en phase avec leurs pratiques au quotidien.

Le Knowledge Layer

La fiabilité et la performance d’un agent IA repose sur la maîtrise de l’accès aux différentes données et documentations de l’entreprise. Le Knowledge Layer est la seule et unique source de vérité sur laquelle l’agent fonde ses raisonnements.
Cette couche repose sur des architectures de type RAG ou GraphRAG comprenant les données structurées, les documents métiers et les référentiels afin de garantir la cohérence et la pertinence des réponses générées.

Cette couche est essentielle pour se prémunir des dérives sémantiques et autres hallucinations. En opérant le RAG en production avec des mécanismes de versioning, de monitoring et de monitoring en continu, L’IA générative devient un composant fiable du SI comme n’importe quel moteur de règles ou service BI.

L’Action Layer

L’Action Layer est LA couche la plus critique des architectures agentiques. C’est elle qui permet à l’agent IA de passer de la simple intention à la véritable exécution en appelant les APIs, en déclenchant des workflows ou en modifiant des états métiers.
Cette capacité d’action doit être particulièrement encadrée. Chaque action possible doit être explicitement autorisée, tracée et, lorsque c’est nécessaire, soumise à une validation humaine.

L’Action Layer comprend une intégration native des systèmes de sécurité SI comme la gestion des identités et des accès (IAM), la séparation des environnements et la journalisation des opérations.

Le Trust & Control

Enfin, une architecture AI-Ready intègre dès sa conception une brique de Trust & Control. Celle-ci est garante de la supervision des agents, de la traçabilité complète des décisions, de l’audit des actions exécutées et de la conformité réglementaires dont le RGPD bien sur l’AI Act.

Cette couche transverse permet à la DSI de s’assurer de la gouvernance, de la sécurité et de la conformité sans freiner l’innovation. La brique Trust & Control est le socle sur lequel reposent l’industrialisation des agents IA et le run à grande échelle, dans le respect des bonnes pratiques d’AgentOps et de LLMOps déjà éprouvées en production.

3. La Stack IA agentique recommandée

4. Les agents IA pour les métiers

L’IA agentique n’est pas qu’une technologie de plus, c’est un peu une nouvelle génération de travailleurs numériques spécialisés conçus pour opérer dans un périmètre métier précis, avec des règles, des données et des responsabilités clairement définies.

Les agents IA les plus efficaces dans la réalité des projets sont ceux qui s’intègrent dans des chaînes de valeur déjà existantes, en automatisent des tâches à faible valeur ajoutée ou en sécurisant des décisions opérationnelles.

Quelques exemples d’agents IA en production

5. Combien coûte un agent IA ?

Dans les projets d’IA agentique, la conception et la mise en œuvre de l’agent IA s’effecture en en trois phases pour éviter l’effet tunnel, sécuriser la mise en production et garantir un retour sur investissement mesurable. Cela permet à la DSI de piloter l’investissement dans le temps, en maîtrisant à la fois les risques techniques, les coûts et la valeur métier délivrée dans une logique d’amélioration continue dans la durée.

1. Le cadrage projet IA, environ 10K€

La première phase consiste à cadrer précisément les cas d’usage à fort impact / valeur. Elle vise à identifier les processus réellement automatisables, à prioriser les scénarios et à définir les indicateurs de performance qui permettront d’évaluer l’agent une fois en production.

Ce travail de cadrage couvre plusieurs cas d’usage, débouche sur une fiche agent formalisée (périmètre, règles, données, KPI) et s’accompagne d’une première preuve de valeur. Il permet également de définir l’architecture cible et une feuille de route réaliste à 90 jours.

Cette étape est déterminante : elle conditionne la robustesse de l’agent, son acceptation par les métiers et la capacité de la DSI à éviter les dérives de coûts ou de périmètre par la suite.

2. Le build Agent IA, entre 50 et 100K€

Le développement d’un agent IA métier et sa mise en production représentent un investissement généralement inférieur à 100 k€qui varie selon la complexité et les intégrations SI nécessaires.

Ce budget couvre bien plus que le simple assemblage de modèles. Il inclut l’intégration sécurisée au système d’information, le paramétrage et la gouvernance des APIs, la mise en place du socle AgentOps (logs, traces, métriques, évaluation continue), ainsi que les garde-fous nécessaires à une exploitation fiable. Le budget comprend généralement 6 mois de pilotage AgentOps et de supervision des performances.

3. Le Run & Scale, à partir de 5K€/mois

Une fois en production, un agent IA ne peut pas être laissé « en roue libre » sans supervision. Contrairement à une application Data classique, l’agent IA évolue en permanence (données, modèles, usages).  Ce véritable coût de fonctionnement de l’IA agentique se situe généralement entre 5k€ et 15 k€ par mois, en fonction du nombre d’agents, de leur criticité et des exigences opérationnelles. Cela comprend la supervision technique et sémantique, l’amélioration continue du backlog de connaissances et le suivi des KPI (qualité, coûts, sûreté,…)  

Chez Smartpoint, nous accompagnons les DSI dans la conception et l’industrialisation d’agents IA réellement opérables en production : architecture, gouvernance, coûts et passage à l’échelle.
Contactez-nous !

Pour aller plus loin dans l’analyse :

Selon Gartner, plus de 40% des projets d’IA agentique seront annulés d’ici fin 2027 (coûts, ROI, manque de contrôle des risques)

• Over 40% of Agentic AI Projects Likely to Be Abandoned by 2027

• CIO-online (Janvier 2026) : « Tarification des agents d’IA : un nouveau piège pour la DSI ? » : Lien
• Gartner (2025-2026) : « 30 % des projets d’IA générative seront abandonnés d’ici fin 2025 » : Lien
• Extencia (Décembre 2025) : « Agents IA : usages, création, coûts et risques en 2026 » : Lien
• McKinsey & Company (Décembre 2025) : « Adoption et impact de l’IA : enseignements des dernières études » : Lien
• Plateya (Janvier 2026) : « Tarif consultant IA en 2026 : guide complet et fourchettes » : Lien
• Smartpoint (Janvier 2026) : Industrialisation RAG, piloter l’IA Générative en production
  

Coûts des agents IA

Estimated reading time: 11 minutes

Le temps des POC IA (Proof of Concept) est désormais derrière nous. En 2026, il ne s’agit plus de démontrer qu’une IA peut répondre à une question mais de garantir qu’elle peut le faire à l’échelle du SI de manière performante et sécurisée dans la durée. Chez Smartpoint, nous constatons en effet que la réalité des projets est plus compliquée ! 51% des organisations utilisant l’IA déclarent avoir déjà subi au moins un effet négatif et indésirable, allant de la simple hallucination à l’erreur de tarification. Cette statistique, issue de l’étude McKinsey & Company, The state of AI in 2025: Agents, innovation, and transformation, souligne l’urgence d’une approche plus industrielle. Pour éviter que vos projets IA ne rejoignent les 30% de déploiements GenAI abandonnés après la phase de test (source Gartner), principalement en raison d’une mauvaise qualité des données ou de coûts d’exploitation mal maîtrisés, voici les conseils de nos consultants Data / IA.

Modernisation SI Data et plateforme BI : les fondamentaux d’une IA à l’échelle

Concevoir un RAG sur une plateforme data fragile, c’est comme piloter un avion sans ailes ! Chez Smartpoint, c’est devenu le mantra de nos consultants : l’IA générative ne pardonne pas le « à-peu-près », elle révèle au contraire l’impact de votre dette technique accumulée sur les résultats. Là où un humain repère une anomalie et l’écarte, un système d’IA l’absorbe, la réutilise et la propage à l’échelle. Un RAG en production repose sur vos actifs réels, vos référentiels, vos proccessus et les connaissances métiers.

Sans une gouvernance des données solide, le meilleur modèle du monde donnera des réponses instables et creusera les failles de sécurité. La modernisation de la plateforme data n’est pas une simple migration vers le Cloud ; c’est ce qui permet de rendre vos données exploitables et traçables pour des algorithmes qui se nourrissent du contexte. De la même manière, moderniser votre plateforme BI ne sert pas qu’à accélérer les tableaux de bord, c’est préparer tout un écosystème où l’IA devient la première consommatrice de données à grande échelle.

En 2026, l’architecture RAG est préférée au Fine-Tuning pour 90% des cas d’usage en entreprise selon LlamaIndex. Cela s’explique par la capacité à maintenir un couplage dynamique et en temps réel entre le LLM et la « vérité » de vos données métier, sans les coûts ni l’inertie des cycles de réentraînement.

Un pipeline qui couvre toute l’architecture Data IA, de l’ingestion au pilotage

Un RAG en production n’est pas une simple « brique IA » rajoutée sur votre SI Data. C’est un pipeline d’architecture Data complète qui va de l’ingestion de la donnée brute au pilotage des performances. Chez Smartpoint, nous recommandons d’orchestrer finement chaque étape pour éviter le risque de déraillement du système. L’industrialisation d’un RAG ne commence pas avec lla base de données mais dès la saisie de l’utilisateur. Chez Smartpoint, nous intégrons systématiquement une couche de Query Rewriting (ou Query Expansion). Puisque une bonne part des échecs de l’IA sont liés à des interactions humaines imprécises ou ambiguës, nous utilisons un LLM léger pour reformuler la requête initiale en une recherche structurée et optimisée pour le moteur vectoriel. Cette étape de « nettoyage sémantique » est le premier rempart contre les hallucinations et assure que le système cherche réellement ce que l’utilisateur a en tête.

La segmentation stratégique (Semantic Chunking)

Le premier écueil technique est l’ingestion et la segmentation (Chunking strategy). Il est absolument nécessaire de découper l’information pour qu’elle reste sémantiquement cohérente. Sans un découpage sémantique maîtrisé, les taux d’hallucinations oscillent entre 12% et plus de 20% selon les modèles, ce qui rend le système IA totalement inexploitable. Au-delà du simple découpage, nos experts Data IA préconisent l’adoption de stratégies de Parent-Child Retrieval (ou Small-to-Big). Le défi ide la mise à l’échelle est en effet souvent contradictoire… Pour une recherche vectorielle précise, il faut des segments courts, mais pour une génération de qualité, le LLM a besoin d’un contexte étendu. Chez Smartpoint, nous résolvons ce paradoxe en indexant des micro-segments (les « enfants ») pour la précision du retrieval, tout en renvoyant au modèle le bloc sémantique parent complet lors de l’inférence. Cette architecture garantit la pertinence technique sans sacrifier la richesse contextuelle nécessaire à une réponse exploitable.

Indexation et gouvernance des droits

L’indexation vectorielle demande un arbitrage entre base de données vectorielle pure ou extension vectorielle de votre socle existant. La gestion des droits est également un prérequis non négociable. Votre système doit s’assurer que l’IA ne révèle pas à un collaborateur des informations auxquelles il n’a pas accès dans le SI source (ERP, GED, RH) … sans compter les risques de révéler ou d’exposer des données sensibles.

IA en production : les 4 piliers (qualité, sécurité, coûts, supervision)

Pour passer du POC IA agentique à l’échelle industrielle, nos experts Data IA s’assurent de la solidité de quatre piliers critiques pour être en capacités d’opérer l’IA à l’échelle.

1. La Qualité (Groundedness) : L’IA se base-t-elle sur vos sources ou est-elle sujette à des hallucinations ? Votre SI agentique doit garantir une réponse vérifiable et une non-invention systématique.
2. La Stabilité : Votre système résiste-t-il à la dérive (drift) ? Il est impératif de monitorer les régressions potentielles liées aux changements de corpus ou aux mises à jour des modèles LLM (versioning).
3. Le FinOps : Contrôlez-vous les coûts des tokens et la latence ? Vous devez maintenir la performance sans exploser votre budget lors des montées en charge. Un piège classique en production consiste à vouloir saturer la fenêtre de contexte du modèle. Par ailleurs, nos experts Data IA surveillent de près le phénomène de Lost in the Middle, c’est à dire que la capacité d’attention des modèles s’effondre statistiquement lorsque l’information cruciale est située au centre d’un contexte trop dense. Limiter le top-k et privilégier un reranking précis n’est donc pas uniquement une stratégie de réduction de coûts FinOps pour économiser des tokens ; c’est une exigence de performance pure. En sélectionnant uniquement les segments les plus denses en information, nous évitons que le sens ne se noie dans la masse documentaire, garantissant ainsi la groundedness.
4. Supervision : Observabilité / LLMOps : La journalisation, la supervision et l’amélioration continue ne sont pas optionnelles. La difficulté est dans le perpétuel mouvement de l’écosystème IA : le corpus évolue, les droits changent et les contraintes de sécurité du SI sont la règle face à une charge utilisateur souvent imprévisible.

Grille d’évaluation « AI-Ready », les critères à prendre en considération

Pour savoir si votre produit IA sera viable en production, chez Smartpoint, nous utilisons cette grille de scoring (0 : Absent, 1 : Partiel, 2 : Industrialisé). Un score supérieur à 21/30 indique que votre projet IA peut être déployé dans votre SI.

L’IA comme système, pas comme démonstrateur

L’heure n’est plus à l’expérimentation mais à l’industrialisation ! le sujet n’est plus de « faire du RAG », mais d’opérer un RAG en production. Pour nos experts Data IA, cela suppose d’aborder l’IA générative comme un système complet et intégré, reposant sur une architecture data moderne, une gouvernance des données sans faille et une chaîne LLMOps maîtrisée de bout en bout pour garantir la stabilité face à la dérive (drift) sémantique. L’objectif est de doter votre SI d’une IA réellement opérable et pilotable, capable d’évoluer sans recréer la dette technique que l’on observe trop souvent lors du passage à l’échelle.

Chez Smartpoint, pure player data et IA à Paris, nous accompagnons les DSI et CDO pour déployer une IA générative fiable en production. Nous consolidons le socle de données et la gouvernance et nous modernisons la plateforme data, voire la plateforme BI, quand cela s’impose. Nous mettons en place une architecture RAG en production avec une évaluation continue, une supervision effective et des garde-fous clairs, afin que le système soit traçable, maîtrisé et exploitable à l’échelle.

Passez du POC à une IA générative exploitable en production

Votre pilote a fait ses preuves ? C’est ici que commence la réalité opérationnelle de l’IA. Tout l’enjeu est désormais de garantir la bonne tenue à l’échelle de l’IA, le strict respect des habilitations SI, la maîtrise de la latence et le pilotage FinOps.

Chez Smartpoint, nos experts Data IA vous proposent un atelier de cadrage pragmatique. L’objectif est d’auditer votre socle technique via notre grille de 15 critères pour définir une trajectoire de production réaliste. Nous arbitrons ensemble sur les cas d’usage prioritaires, fixons l’architecture Data cible et verrouillons les KPIs incluant la groundedness et la traçabilité des sources. Nous bâtissons un plan de mise en production sécurisé, intégrant les garde-fous et l’observabilité LLMOps nécessaires à la stabilité du système. En tant qu’ESN pure player Data et IA à Paris, nous accompagnons les DSI et CDO pour transformer ces défis en capacités durables. De la modernisation de la plateforme BI au protocole d’évaluation automatisé, nous sécurisons votre trajectoire vers une IA générative industrielle.

Contactez-nous pour activer votre feuille de route « RAG en production » et sécuriser enfin vos déploiements d’IA générative.

Sources :

• Smartday IA : IA générative, LLM et vectorisation - prenez le contrôle !
• Building RAG Systems in 2026 With These 11 Strategies
• LlamaIndex : RAG is dead, long live agentic retrieval (2025)
• Towards AI : 11 Strategies for Building Robust RAG Systems (2025)
• McKinsey & Company : The state of AI in 2025: Agents, innovation, and transformation, L'étude de référence pour comprendre les risques d'imprécision (inaccuracy) et l'impact des agents IA sur la productivité des organisations.

Tout savoir sur l'industrialisation RAG en 2026

L’explosion de l’A générative questionne les DSI sur l’avenir de leur système d’information. Le SI sera vraisemblablement piloté par le langage naturel. Pas sous la forme d’un chatbot “en plus”, mais via une interface en langage naturel (Natural Language Interface / NLI) capable de traduire une intention en requêtes, en décisions… et, lorsque c’est autorisé, en actions automatisés. Le sujet n’est pas de “faire de l’IA” mais bien de concevoir dès à présent une architecture SI AI-Ready qui supporte l’usage conversationnel ET l’exécution dans les standards conformes aux exigences d’une DSI.

Dans cet épisode 1, nous posons donc les bases : clarifier les concepts (conversationnel, piloté par le langage naturel, agentique), comprendre le passage du “read” au “write”, puis détailler les six briques qui rendent une architecture SI AI-Ready opérable : composabilité, API-first/headless, data layer gouvernée, knowledge layer, action layer, et Trust & Control.

SI conversationnel, SI agentique ou SI piloté par le langage naturel : on parle de quoi ?

Avec le développement de l’IAGen a vitesse grand V, tout le monde « chatte » avec ses outils et les éditeurs l’ont bien compris en intégrant cette fonctionnalité (avec plus ou moins de pertinence) dans les CRM, ERP, etc.. Mais un SI conversationnel n’a rien à voir avec un simple chatbot ajouté dans une application. C’est un SI dont l’architecture a été repensée pour intégrer une couche d’interface en langage naturel (NLI) capable de piloter les données et les processus. Imaginez une interface qui permet d’accéder aux bonnes données, de déclencher les bons workflows et, demain, d’exécuter certaines actions en production, de façon contrôlée. On se met alors à parler d’une nouvelle génération de SI, capable d’interagir, de prendre des actions en autonomie encadrée et de respecter les standards d’une DSI en matière de sécurité, conformité, traçabilité, qualité… et gouvernance de l’IA.

Science-fiction ? Pas vraiment. Commençons par clarifier quelques termes que l’on voit partout et qui sont souvent confondus. Leur point commun, c’est que la “conversation” masque une énorme complexité. pour que tout cela fonctionne à l’échelle, il faut un SI composable, avec des services métier et des APIs proprement exposés

• SI conversationnel : le SI “répond” et “guide” via une interface en langage naturel en s’appuyant sur des données et des connaissances gouvernées et contextualisées.
• SI piloté par le langage naturel : la conversation devient une interface de commande où l’utilisateur exprime une intention, le SI la traduit en requêtes et en exécution via des APIs et des workflows définis.
• SI agentique (agentic enterprise) : des agents IA spécialisés orchestrent des tâches de bout en bout. Ils collaborent entre eux, interagissent avec le SI et les utilisateurs ; le tout sous contrôle (garde-fous, validations, auditabilité, observabilité, human in the loop).

Couche conversationnelle (conversational layer) : l’interface en langage naturel du SI

La couche conversationnelle est donc cette brique qui permet d’interagir avec le SI via le chat, copilot ou encore la voix et elle est intégrée dans les applications. Elle permet de répondre à des questions en actions SI. Par exemple « Donne-moi la vue 360 de ce client et les derniers échanges », « , « Quel est le chiffre d’affaires par région vs objectif cette semaine ? », « Quels sont les incidents critiques depuis X temps ? », « Quels comptes ont des droits d’accès sur ce domaine de données ? », « Quels contrôles dois-je ajouter pour sécuriser ce pipeline avant mise en production ? » « Propose-moi la meilleure requête pour analyser le churn sur 12 mois », « Ouvre un ticket incident P2 pour la baisse de fraîcheur des données et assigne l’équipe DataOps », « Qui a accès à ces données ? », « Relance automatiquement les pipelines en échec sur les 24 dernières heures. » (…). Elle utilise le Natural Language Interface (NLI) qui permet de comprendre l’intention, le contexte et les droits d’accès spécifiques à l’utilisateur.

1. Comprendre l’intention : identifier le besoin, lever les ambiguïtés, reformuler si nécessaire.
2. Retrouver l’information : interroger les sources autorisées (applications, data platform, référentiels) en respectant le bon niveau de gouvernance.
3. Guider l’utilisateur : proposer une réponse actionnable, suggérer la prochaine étape, et préparer l’exécution (par exemple via une API) quand l’usage l’autorise.

SI agentique (agentic enterprise) : quand le SI répond ET exécute !

Un SI agentique est pensé pour exécuter des actions à partir d’une intention exprimée en langage naturel. Alors que la couche conversationnelle traduit une demande en informations, le SI agentique a la capacité d’agir sur le SI via des services composables et des API.

“Read” vs “Write” : interroger ET modifier l’état du SI

Le concept est simple. Lire n’engage pas le SI alors qu’écrire oui.

• Read : l’agent interroge le SI, agrège le contexte et explique ce qui se passe.
  Exemples : « Où en est la commande X ? », « Quels incidents P1 sur 7 jours ? », « Quel est le lineage de ce KPI ? »
• Write : l’agent déclenche des actions qui modifient l’état du SI, via des API et des workflows, avec des garde-fous.
  Exemples : créer un ticket, ouvrir un accès, relancer un pipeline, lancer un rollback, déclencher un workflow, mettre à jour un référentiel.

Chez Smartpoint, nous avons jusqu’à présent surtout vu et utilisé read-only mais la bascule est engagée sur des périmètres très précis et maîtrisés. C’est là que l’on passe du “copilot” qui commente… à un SI agentique qui opère.

Agents, orchestration, supervision : les trois briques qui rendent le modèle opérable

Un SI agentique s’appuie sur des agents IA capables d’exécuter des tâches outillées (APIs, workflows, moteurs de règles) dans un contexte prédéfini. Dans une architecture AI‑Ready, ces agents ne sont pas “greffés” sur le SI, ils consomment des services et des APIs conçus pour être appelés par des agents, de manière sécurisée et gouvernée.

Chaque agent IA a un rôle précis (support, traitement data, conformité, finance…), des sources autorisées, un périmètre d’action et des règles. Les agents IA sont par nature spécialisés sur un périmètre précis pour éviter toute confusion et autres hallucinations.

L’orchestration permet de distribuer les tâches. Elle séquence les étapes, choisit le bon agent, gère les dépendances et garantit une exécution cohérente. C’est la différence entre une conversation isolée et un processus industrialisable à l’échelle de la DSI, et c’est une brique centrale de toute architecture SI AI‑Ready crédible.

Et bien entendu, la supervision est indispensable (run, contrôle, traçabilité). Dans une architecture AI-Ready, on parle d’observabilité des agents.
Superviser permet de suivre les échanges, de contrôler les actions, de gérer les validations (human-in-the-loop), de suivre la qualité, de surveiller les coûts et de détecter les dérives. Sans supervision, un SI agentique reste un POC !

Pourquoi les systèmes d’informations actuels ne sont pas AI-Ready ?

Les SI ont été conçus pour exécuter des transactions pas pour dialoguer, ni contextualiser et encore moins agir de manière autonome.

Dans la réalité, Le SI est très fragmenté surtout dans les grandes entreprises qui ont un Legacy lourd qui s’est complexifié avec le temps. Entre ERP monolithiques, applications métier cloisonnées et intégrations spécifiques, le SI est loin d’être actionnable par des agents via des API, de façon gouvernée et opérable en production (“agent-callable »). Les workflows sont rigides, couplés au front et aux logiques applicatives ; et non exposés sous forme de services et d’API. Alors qu’un SI Ai-Ready a impérativement besoins de services composables et d’API standardisées pour fonctionner.

Côté données, l’architecture n’est pas “data AI‑ready” non plus. La donnée n’a pas été préparée pour l’IA : jeux de données disparates, définitions de KPI qui varient, fraîcheur incertaine, documentation incomplète. Sans une gouvernance data rigoureuse, des métadonnées exploitables et une traçabilité de bout en bout (sources, transformations, responsabilités), l’IA « répond » toujours… mais on ne peut pas lui faire confiance pour alimenter une vraie décision ni enclencher une action. Une architecture data AI‑Ready suppose au contraire des data products clairement définis, des contrats de données, des métriques de qualité, du lineage et une responsabilité explicite côté métiers et côté DSI.

-> À Lire sur le sujet : Pas d’IA en entreprise sans AI-Ready Data.

Une architecture AI Ready n’est pas qu’un sujet de data ou de modèle. C’est un sujet de Run. Un agent qui appelle des API doit respecter l’IAM (gestion fine des identités et des accès), gérer les secrets, être auditable, observable mais aussi maîtrisé en termes de coûts (FinOps). Tous ces composants doivent être au bon niveau sinon passer au « write » revient à mettre un copilote dans une voiture lancée en pleine vitesse sans frein ni ceinture de sécurité.  

Architecture AI-Ready : les 6 briques d’un SI conversationnel et agentique crédible

Un SI AI-Ready, c’est un SI où une intention exprimée en langage naturel peut être traduite en requêtes (data / applicatives), enrichie par du contexte (données / connaissances), puis, si le cadre le permet, exécutée dans les standards DSI.

1) SI Composable où comment passer du monolithe aux services réutilisables

Un SI agentique a besoin de fonctions “appelables”, c’est-à-dire des apacités exposées via des services/API. Quand l’essentiel de la valeur est enfermée dans des applications monolithiques ou des chaînes de traitements fortement couplées, l’IA se contente de commenter (read only). La composabilité, c’est la capacité à assembler des briques (commande, facturation, identité, référentiels, pricing…) sans réécrire l’ensemble à chaque itération.
Dans certains contextes, une approche event-driven apporte une vraie valeur. Elle réduit le couplage, améliore la résilience, et permet de faire évoluer le SI par itérations. Mais le point clé n’est pas “microservices partout” mais une décomposition utile, au bon niveau, avec des responsabilités claires.

2) API-first & headless où comment rendre le SI réellement “agent-callable” (AI-Ready)

Dans une architecture AI-Ready, un agent ne “pilote” pas des écrans, il consomme des capacités métier exposées via des API. Cela suppose des API propres, standardisées, versionnées, documentées et sécurisées, avec des contrats stables. “Headless” signifie simplement que l’action ne dépend pas d’une interface utilisateur ou d’un parcours applicatif, l’agent appelle un service, pas une IHM.
C’est un point de rupture classique entre POC et mise en production. On peut avoir une IA qui comprend, sans pour autant avoir un SI capable d’exécuter de manière fiable. Une approche API-first permet d’industrialiser l’accès au SI (applications, utilisateurs, partenaires … et demain agents) avec les mêmes exigences d’urbanisation SI et d’exploitation : contrôle d’accès (IAM), quotas, traçabilité, gestion des erreurs et gouvernance des interfaces. Sans ce socle, l’agent devient un contournement et donc un risque : surface d’attaque accrue, dette d’intégration, et difficultés d’audit en production.

3) Data layer gouvernée : un SI AI-Ready commence par des données fiables

Un SI conversationnel tient ses promesses uniquement si la donnée est compréhensible, à jour et fiable. Sinon, il répond vite… mais faux. La brique data, ce n’est pas “un lac de données de plus”. C’est une organisation qui rend la donnée consommable : data products, data contracts, métriques définies, métadonnées, qualité, fraîcheur, lineage et responsabilités.
Dans une architecture data AI‑Ready, ce socle est aussi un sujet d’exploitation. la DSI doit pouvoir piloter la disponibilité, la fraîcheur, la qualité, et comprendre l’impact d’un incident data sur un usage métier (ou agentique). Sans cette gouvernance, la conversation est agréable, mais la décision reste risquée.

4) Knowledge layer : RAG, graph, référentiels, sémantique

Dans une architecture AI-Ready, la “connaissance” ne se résume pas à faire du search dans des PDF ! C’est une brique à part entière qui fournit du contexte gouverné et actionnable aux assistants et aux agents, avec un niveau d’exigence compatible avec la mise en production.

Pour être crédible en production, un SI agentique repose sur trois mécanismes complémentaires.

D’abord, le RAG sert à récupérer le bon contexte opérationnel au bon moment, à partir de sources hétérogènes comme les procédures internes, la documentation, les tickets, les contrats ou les politiques internes, avec traçabilité des sources. Ensuite, un graphe de connaissance ou des référentiels structurent les relations clés du SI (client ↔ contrat ↔ produit ↔ incident ↔ droits d’accès ↔ organisation) pour passer d’un “texte plausible” à une représentation exploitable et cohérente. Enfin, un catalogue et des règles de gouvernance encadrent ce qui est consommable, ce qui fait référence, ce qui est à jour et ce qui est interdit … autrement dit, qui a le droit de voir quoi et sur quelle version de la vérité.

L’objectif est de produire une réponse sourcée, explicable et utilisable, pas une synthèse “belle à lire” qui ne tient pas la route au premier contrôle, audit ou incident.

5) Action layer : outillage, orchestration et garde-fous

C’est la brique qui fait passer le SI du “je réponds” à “j’exécute”. Dans une architecture AI-Ready, l’action ne se fait pas “dans le LLM”, elle se fait via des mécanismes d’exécution industrialisés : APIs, moteurs de workflow, orchestrateurs, règles métier, validations et gouvernance.

Cette couche doit intégrer les garde-fous attendus par une DSI comme le human-in-the-loop sur des actions sensibles, des seuils et des limites d’action, des circuits d’approbation, une séparation stricte des environnements dev / préprod / prod, la gestion des erreurs, idempotence quand nécessaire et surtout des chemins de rollback / compensation pour éviter le drame à chaque incident

Un agent n’agit pas parce qu’il “pense que c’est une bonne idée”. Il agit parce que l’action est définie, autorisée, testée et réversible, sur un périmètre explicite. C’est ce qui permet de démarrer proprement : d’abord des actions simples et fortement outillées (tickets, relances jobs, demandes d’accès, procédures standard) puis une montée en autonomie progressive en s’assurant de la maîtrise opérationnelle.​

6) Trust & Control : sécurité, auditabilité, observabilité, maîtrise des coûts

C’est la brique qui rend un SI agentique exploitable en production et surtout qui conditionne la crédibilité d’une architecture AI-Ready. Elle répond aux contraintes de sécurité (gestion des identités et des accès via RBAC/ABAC, gestion des secrets, chiffrement), de conformité (journalisation, traçabilité, preuves d’exécution) et d’exploitation (supervision, alerting, gestion des incidents).

Elle intègre aussi deux élément indispensables pour une architecture AI-Ready : la maîtrise des coûts (FinOps, suivi consommation LLM/compute, quotas, chargeback/showback) et la qualité de service (SLO/SLI) appliquée non seulement aux APIs et aux plateformes, mais aussi aux agents et aux données qu’ils consomment (disponibilité, fraîcheur, qualité, latence, taux d’erreur).

Avec ce socle Trust & Control, la DSI peut encadrer l’automatisation, piloter les risques, et industrialiser progressivement des cas d’usage “write” sur des périmètres maîtrisés, sans dégrader la sécurité ni l’opérabilité du SI.

Ces six briques permettent de poser une architecture AI-Ready solide : une interface en langage naturel qui n’est pas un gadget, des agents qui n’opèrent pas “dans le vide”, et un SI qui reste pilotable par une DSI.

Alors comment passer à un SI conversationnel ou agentique ?

Un SI conversationnel ou agentique ne se décrète pas à coups de prompts ! Il se conçoit avec une architecture SI AI-Ready, c’est à dire des capacités métier composables, exposées via des API, alimentées par une donnée et une connaissance gouvernées, et opérées avec les standards Run attendus par une DSI (sécurité, traçabilité, observabilité, maîtrise des coûts).

Chez Smartpoint, nous accompagnons les DSI et les CDO dans cette trajectoire de transformation de leurs systèmes d’information : diagnostic de maturité AI-Ready, priorisation des chantiers (API-first, data/knowledge, action layer, Trust & Control) et mise en production progressive de cas d’usage, du read-only vers des périmètres write supervisés.

Sources :

• 5 bonnes résolutions pour bâtir le SI conversationnel de 2030 : https://www.cio-online.com/actualites/lire-5-bonnes-resolutions-pour-batir-le-si-conversationnel-de-2030-16753.html
• De l’IA générative à l’IA agentique : pourquoi les entreprises doivent réinventer leur architecture GenAI : https://www.informatiquenews.fr/de-ia-generative-au-rag-agentique-pourquoi-les-entreprises-doivent-reinventer-leur-architecture-genai-106839
• Adopter les interfaces conversationnelles : guide pratique pour les DSI : https://www.alliancy.fr/fr/adopter-les-interfaces-conversationnelles-guide-pratique-pour-les-dsi-ad867f07-14b6-498e-9433-2be4ad9fa556
• Pas d’IA en entreprise sans AI-Ready Data.
• Les architectures data autonomes et auto-adaptatives : vers l’auto-pilotage de la donnée

L’IA générative n’est pas (encore) un collègue autonome ! Côté propension à halluciner, même sur une tâche cadrée comme le résumé de documents, les écarts entre modèles restent importants. Sur le Hallucination Leaderboard de Vectara (méthodologie HHEM), des modèles se situent autour de ~12% de taux d’hallucination alors que d’autres dépassent 20%. Autrement dit : sans “garde-fous” d’architecture, la dérive n’est pas un bug à la marge, c’est une variable du système.

L’IA en production est loin pour l’instant de « tourner toute seule ». Et l’ « human-on-the-loop », cette revue humaine souvent très coûteuse et difficile à industrialiser, ne suffit pas à rendre le système IA fiable. Tout l’enjeu est de fiabiliser l’IA en production sans exploser les coûts. Et c’est ici que l’architecture RAG (Retrieval-Augmented Generation), pensée en amont du projet, prend tout son sens. Elle permet de limiter les hallucinations, de tracer les sources et d’aligner le comportement du modèle sur les données de l’entreprise plutôt que sur sa seule mémoire statistique. Le principe est de ne pas laisser un LLM « livré à lui-même » mais d’ancrer ses réponses dans une base de connaissance externe.

Mais encore faut-il choisir la bonne architecture RAG pour que l’IA soit exploitable.

Le RAG où comment “ancrer” un LLM dans la réalité

Le RAG consiste à récupérer (retrieve) des éléments pertinents dans une base de connaissance et à les injecter dans le contexte envoyé au LLM pour générer (generate) une réponse plus fiable. Cette approche a été formalisée et nommée “RAG” dans les travaux fondateurs de Lewis et al. (2020), qui décrivent le principe d’une mémoire “non paramétrique” consultable au moment de l’inférence : au lieu d’attendre qu’un modèle “se souvienne” de tout, on lui donne accès à des preuves au moment où il répond.

Dans le cas d’une entreprise, la connaissance « utile » concerne le contexte propre à l’organisation : ses contrats, ses processus, son catalogue de produits et de tarifs, les référentiels métiers, la politique de sécurité, etc.​

C’est là que le RAG devient une question d’architecture : derrière un schéma simple se cachent des choix importants sur la segmentation, l’indexation, les modes de recherche et l’évaluation.

Le RAG standard, cet incontournable …. mais insuffisant dans la durée

Le “RAG naïf” est l’architecture de base la plus logique : on découpe les documents en chunks (segments), on calcule leurs embeddings, on les indexe dans une base vectorielle, puis on récupère les top-K les plus proches de la requête avant de générer la réponse à partir de ce contexte. C’est un bon point de départ car il est facile à diagnostiquer : si ça se dégrade, on voit vite si le problème vient de la donnée, du chunking, du retrieval, du prompt ou du modèle.

Le problème, c’est qu’en production, ce schéma montre vite ses limites. D’abord, le bruit : des chunks “presque pertinents” remontent et contaminent la réponse. Ensuite, les questions multi-parties : il faut souvent plusieurs preuves, souvent disséminées dans plusieurs sources. Ajoutons les ambiguïtés conversationnelles (“ça”, “le même”, “comme hier”), les trous de couverture (l’information n’existe tout simplement pas dans la base) et surtout le défaut structurel du RAG standard : si le retrieval se trompe, rien ne l’arrête. Le modèle répond quand même et il le fait avec aplomb, et c’est bien le problème !

Résultat ? On “améliore le prompt”, on “change d’embedding”, on “augmente le top-K”… et l’on finit souvent par augmenter les tokens, les coûts et la confusion, sans traiter le vrai sujet : la qualité du retrieval et le contrôle du contexte fourni au modèle.

Source : https://datascientist.fr/blog/guide-rag-2025-retrieval-augmented-generation

Architecture RAG « adulte”

Un bon RAG ne cherche pas le bon chunk du premier coup. Il commence par récupérer un ensemble de candidats en masse, puis il prend le temps, au bon endroit, de sélectionner les meilleurs. Cette séparation entre retrieve et rerank est devenue incontournable pour des assistants IA fiables, stables et économiquement tenables.

Concrètement, on “ratisse large” avec une recherche vectorielle, lexicale ou généralement une recherche hybride qui combine mots-clés (type BM25) et similarité sémantique (vecteurs). Dans la pratique, beaucoup de plateformes “enterprise search” généralisent ce couplage : hybrid search, fusion de classements (type RRF), puis reranking sémantique sur une shortlist. C’est un bon compromis entre pertinence, latence et coûts.

Pourquoi ce schéma d’architecture fonctionne ? Parce que le monde réel parle deux langues à la fois. D’un côté, les requêtes “mots-clés” qui doivent matcher exactement : une API, un acronyme, un numéro de ticket, un contrat, un bon de commande. De l’autre, des questions formulées en langage naturel avec synonymes, paraphrases et intention implicite. La recherche hybride évite de manquer le détail qui fait la différence tout en captant l’intention. Et le reranking remet de l’ordre : il re-classe les meilleurs candidats pour remonter les passages réellement exploitables.

Le bénéfice est immédiat : on augmente la pertinence sans faire exploser la latence, car l’étape “coûteuse” n’est exécutée que sur une shortlist. Le piège, lui, reste très classique : activer un reranker “par principe” sans protocole de mesure. Ce qui fait la réelle différence en production repose sur de l’ingénierie : jeux de requêtes représentatifs, métriques de retrieval (precision/recall@k, MRR, nDCG), évaluation bout-en-bout (groundedness, complétude, utilité) et traçabilité des paramètres (chunking, top-k, filtres, modèles, prompts) pour comparer proprement avant/après.

Le RAG conversationnel

Dès qu’on passe en mode assistant, la conversation devient un terrain glissant pour le retrieval. Les utilisateurs parlent en pronoms ou par référence (« çà » , « le même cas », « comme la dernière fois, etc.). Le RAG conversationnel introduit une brique fondamentale, le Query Rewriting, qui permet au LLM de transformer la nouvelle question en requête autonome en s’appuyant sur l’historique récent.

Résultat . une recherche plus stable, moins de contresens, un utilisateur qui n’a plus besoin de répéter. Mais cette mémoire doit être cadrée. Trop d’historique crée de la pollution (memory drift) : un détail d’il y a dix minutes contamine la recherche actuelle. Trop peu provoque l’amnésie. Et la réécriture elle-même doit être évaluée : une “bonne reformulation” peut, parfois, corriger la phrase… en déformant l’intention. Dans un assistant, ce n’est pas un détail : c’est la différence entre une aide et un contresens.

Le RAG adaptatif

Le RAG adaptatif, c’est celui qui a compris que toutes les questions ne méritent pas le même traitement. En production, en enchaine sans distinction des bavardages (“super”, “merci”), des FAQ simples (comme où trouver le process X ou Y) et des questions beaucoup plus complexes (preuves multi-sources, filtres sensible, contraintes de droits, outils externes). Traiter tout ça avec le même pipeline, C’est comme lancer un mode ‘enquête’ pour une question de FAQ : beaucoup d’effort pour très peu d’information. Du full RAG pour écraser une mouche !

Le principe du RAG adaptatif est simple, un routeur (classificateur léger ou LLM) évalue l’intention et dose l’effort. Pour certains échanges, on répond sans retrieval. Pour une question factuelle simple, on déclenche un RAG standard rapide. Et pour les cas complexes, on active un parcours “riche” : hybrid search, reranking, multi-requêtes, voire orchestration d’outils. À l’échelle, c’est l’un des leviers les plus rentables, parce qu’il évite de payer du retrieval (et encore plus du reranking) quand cela n’apporte rien, tout en réservant la cavalerie aux questions qui le méritent vraiment.

Mais comme souvent, le diable est dans le détail… Un mauvais routage casse tout. Si une question difficile est classée comme “simple”, on obtient une réponse fragile ; et l’erreur a l’air de venir du modèle  alors qu’elle vient du choix d’architecture. D’où la règle : le RAG adaptatif ne se pilote pas au feeling. Il se pilote avec un jeu de requêtes représentatif, des métriques de pertinence et une évaluation continue des décisions du routeur.

Le RAG correctif (CRAG)

Quand les enjeux sont importants, on ne peut pas se satisfaire de “croiser les doigts” en espérant que le retrieval tombe juste. Conformité, finance, opérations critiques, décisions engageantes, (…), il ne s’agit pas de répondre vite mais de s’assurer que ce qu’on a retrouvé est réellement exploitable. CRAG (Corrective Retrieval Augmented Generation) formalise cela : avant de générer, le système évalue la qualité du contexte récupéré, puis adapte son comportement selon un niveau de confiance. Si les passages sont solides, on avance. S’ils sont incomplets, ambigus ou hors sujet, on filtre, on complète, on relance la recherche, et, si nécessaire, on élargit vers d’autres sources quand la base interne ne couvre pas le besoin.

CRAG transforme une habitude artisanale, “on vérifie à la main”, en mécanisme industrialisable. C’est une vraie barrière de sécurité contre les hallucinations qui ne viennent pas du modèle, mais d’un retrieval imparfait. Oui, cela ajoute de la latence et un peu de complexité. Mais en production, c’est un arbitrage à faire : mieux vaut payer quelques centaines de millisecondes de contrôle que le coût d’une réponse fausse, formulée avec assurance… puis recyclée partout. Luc Doladille – Directeur Conseil & Delivery

L’Agentic RAG

L’Agentic RAG c’est encore un cran au-dessus. La recherche n’est plus un “lookup” déclenché une fois, c’est une orchestration. Un agent piloté par LLM raisonne étape par étape, décide quand et comment appeler le retrieval comme un outil parmi d’autres (API, calculs, règles métier). Certaines requêtes demandent de décomposer, croiser, itérer, vérifier. Dans ces cas-là, l’agent choisit quand récupérer et comment le faire pendant l’interaction, puis synthétise à partir d’éléments consolidés.

Mais il y a une règle simple : pas d’agentic sans base solide. Si les fondamentaux RAG ne tiennent pas la route (corpus, chunking, index, retrieval, évaluation), l’agent ne corrige pas le chaos : il l’amplifie.

Source https://www.llamaindex.ai/blog/rag-is-dead-long-live-agentic-retrieval

Graph RAG

GraphRAG s’attaque à la limite du RAG “tout vectoriel” : la similarité sémantique retrouve des passages qui “ressemblent” mais elle ne garantit pas de reconstruire un raisonnement. En effet, dans de nombreuses entreprises, ce qui compte n’est pas uniquement ce qui est dit, mais ce qui est lié à quoi : dépendances applicatives, chaîne de responsabilité, impacts réglementaires, relations client-fournisseur, causes et effets.

Le principe de GraphRAG est de raisonner en relations plutôt qu’en ressemblances. Au lieu de demander “quel texte ressemble à ma question ?”, le système structure une partie de la connaissance en graphe. Les entités deviennent des nœuds (personnes, applications, services, contrats, politiques, concepts), les relations deviennent des « arête »s (“dépend_de”, “affecte”, “autorise”, “interdit”, “régulé_par”, etc.). À la requête, GraphRAG identifie les entités clés, puis parcourt les chemins les plus pertinents pour reconstituer une chaîne explicable (qui dépend de quoi, quel changement impacte quoi, quelles règles s’appliquent, où sont les exceptions).

GraphRAG est particulièrement efficace dès que l’utilisateur pose des questions multi-hop : “si je change ce paramètre, quelles équipes et quels services sont impactés ?”, “quelles obligations s’appliquent à ce traitement dans ce pays et pour ce type de client ?”. En revanche, GraphRAG nécessite un effort de modélisation, d’extraction d’entités, de gouvernance et de maintien dans le temps. C’est une architecture à privilégier quand la valeurattendue est dans les liens et où l’explicabilité compte autant que la précision.

À quoi ressemble un RAG “industrialisable” ?

Un RAG est une chaîne complète conçue comme un système : on prépare la connaissance, on l’indexe, on organise la récupération et le classement, on contraint la génération puis on mesure et on itère. C’est cette continuité, du document source jusqu’au comportement observé, qui fait la différence entre un assistant “impressionnant” et un assistant “exploitable”.

On commence classiquemenyt par l’ingestion et la préparation de la connaissance. Une base RAG n’est utile que si elle est propre, gouvernée et maintenable : nettoyage, dédoublonnage, versioning, métadonnées exploitables (source, date, périmètre, confidentialité, BU, produit, pays). La segmentation n’est pas un détail technique, elle conditionne la pertinence du retrieval, la capacité à citer correctement et la stabilité des réponses quand le corpus évolue.

Vient ensuite l’indexation (double). Les utilisateurs cherchent enn effet à la fois des mots exacts et des formulations naturelles. C’est pourquoi on retrouve fréquemment un index lexical de type BM25 et un index vectoriel basé sur des embeddings, parfois réunis dans un même moteur via une recherche hybride. L’objectif n’est pas de choisir entre “keyword” et “sémantique”, mais d’éviter de perdre l’un ou l’autre.

La troisième brique, c’est le retrieval et le ranking : hybrid search, fusion de classements, reranking sur shortlist, filtres par métadonnées, gestion stricte des droits. Un RAG industrialisable sait récupérer… mais il sait surtout récupérer juste, et le prouver.

La génération, enfin, doit être cadrée : style, prudence, règles de non-invention, formats utiles (étapes, procédures, décisions argumentées, tableaux) et capacité à dire “je ne sais pas” quand le corpus ne couvre pas l’information. Et surtout un RAG industrialisable est observable. Sans traces, sans métriques et sans boucle de pilotage, on navigue à l’instinct — et l’instinct ne scale pas. On suit la latence, les coûts, la qualité, les dérives, les échecs de recherche, les prompts effectifs, et les variations liées aux changements de corpus ou de modèles. C’est le socle LLMOps du système : ce qui permet d’améliorer sans casser, de corriger sans régresser, et de tenir dans la durée.

En 2026, le vrai sujet n’est plus “faire du RAG” mais “opérer un RAG”

le RAG n’est pas un gadget, ni un bonus “prompt + vecteurs” qu’on ajoute en fin de projet. C’est une architecture de mise en production de l’IA générative avec des choix structurants, des arbitrages et des responsabilités. Et les systèmes qui tiennent dans la durée ne sont pas ceux qui empilent des briques, mais ceux qui savent concevoir puis piloter : choisir l’architecture adaptée au besoin, mesurer la pertinence et la dérive, corriger ce qui doit l’être, sécuriser ce qui doit l’être, et organiser l’exploitation au quotidien (cadence, qualité, coûts, conformité, traçabilité).

Il ne s’agit pas d’avoir un RAG “plus intelligent”, il doit être gouverné, mesuré et opéré pour transformer la promesse de l’IA en capacité industrielle.

Si vous voulez passer de la démo / POC à un dispositif fiable, stable et économiquement tenable, Smartpoint peut vous aider à cadrer la trajectoire : diagnostic de maturité, choix d’architecture, protocole d’évaluation, mise en place de l’observabilité et du run. Parce qu’au fond, la vraie question n’est plus “Est-ce que ça marche ?”, mais “Est-ce que ça marche encore… quand tout le monde l’utilise ?”.

Sources :

• 9 RAG Architectures Every AI Developer Must Know

• Hughes Hallucination Evaluation Model (HHEM) Leaderboard

• Design and develop a RAG solution

• RAG is dead, long live agentic retrieval

• Introducing the Next Generation of Vectara’s Hallucination Leaderboard

Questions fréquentes