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