Agents IA en production, ce qui fait la différence

Un LLM, aussi performant soit-il, ne fait pas le printemps et encore moins un agent en production. Il lui manque quatre composantes critiques : une couche RAG pour interroger vos données internes en temps réel sans réentraînement, une couche d’intégration SI pour agir sur vos systèmes via API et MCP, une couche de gouvernance pour garantir son auditabilité et conformité avec l’AI Act, et un socle AgentOps pour être supervisé, mesuré et maintenu dans la durée.

Sans ces quatre couches, le comportement de l’agent est imprévisible : hallucinations, dérives, et aucun log pour comprendre pourquoi. Les organisations qui ont réussi leur MEP ont toutes résolu ces problèmes. Cet article détaille comment, des prérequis techniques au déploiement.

ROI des déploiements réussis
171 %

de retour sur investissement moyen pour les organisations qui ont franchi le cap de la production

Délai de retour sur investissement
4 à 9 mois

selon le domaine métier / service client en tête (4 mois), engineering en queue de peloton (9 mois)

Premier frein à la MEP
46 %

des organisations citent l’intégration SI comme premier obstacle à la mise en production des agents IA

Deuxième frein à la MEP
42 %

pointent la qualité de la donnée comme frein majeur, avant même le choix du modèle LLM

Troisième frein à la MEP
43 %

citent les coûts d’implémentation comme obstacle, signe que le sujet dépasse le seul budget LLM

Focus France
Déploiement à l’échelle
13 %

des entreprises françaises ont déployé l’IA agentique à grande échelle en 2026

Mesure du ROI
8 %

des entreprises françaises mesurent réellement le ROI de leurs projets IA, contre 17 % qui n’arrivent pas à en percevoir la valeur

La différence entre preuve de valeur (POV) et viabilité en production

Un agent IA en production, ce n’est pas un chatbot amélioré. C’est un composant logiciel avec des flux de données, des appels API, des règles de gouvernance et une supervision humaine (human on the loop). Et nombre de projets IA échouent après avoir pourtant validé un POC : l’agent hallucine, les logs n’existent pas, la donnée en entrée n’est pas nettoyée, personne n’a défini qui est responsable des erreurs.

1. Les quatre composantes critiques pour la réussite de votre agent IA

La mémoire et le contexte métier (RAG)

Un LLM sans base de connaissance connectée à vos données internes ne sait rien de votre organisation. Le RAG (Retrieval-Augmented Generation) permet la recherche sémantique dans vos documents, vos bases de données et vos référentiels avec la capacité de génération du LLM. L’agent ne « devine » pas, il sait parce qu’il interroge vos sources en temps réel. La qualité du RAG (chunking, indexation, scoring de pertinence) détermine directement la fiabilité des réponses.

L’intégration SI

Un agent efficace doit pouvoir agir sur vos systèmes. L’orchestration passe donc par une intégration avec votre SI : API Gateway, connecteurs métiers (ERP, CRM, ITSM, etc.), gestion des identités (IAM), contrôle des actions via MCP (Model Context Protocol). C’est cette couche d’intégration qui fait de votre LLM en agent IA en capacités d’exécuter et pas seulement de répondre.

La gouvernance et le contrôle

L’AI Act entre en application. Ainsi, tout agent manipulant de la donnée sensible doit disposer de garde-fous, de traçabilité complète, de mécanismes d’audit et d’un human-in-the-loop sur les décisions critiques. Un agent non gouverné est un agent à risque pour la conformité réglementaire, pour la sécurité des données, pour la responsabilité juridique et pour sa propre fiabilité dans la durée.

L’AgentOps

La mise en production n’est pas la fin du projet, c’est le début de l’exploitation. Logs, traces, métriques, évaluation continue, détection de dérives, alertes, runbook, gestion des versions ; l’agent a besoin de ce socle pour rester opérationnel dans la durée. Une entreprise sur deux a désormais un responsable dédié « AgentOps » (contre 11 % en 2024). La maturité opérationnelle est le principal facteur de différenciation entre les organisations qui capturent de la valeur et les autres. (Source : Synthèse Digital Applied 2026)

2. Les prérequis techniques et organisationnels à votre agent IA

La gouvernance des données et la responsabilité

La gouvernance est l’indicateur le plus fiable de maturité de votre DSI.

  • Désigner un responsable produit IA, le AI agent owner, c’est la personne qui va assumer la qualité des réponses, les choix de paramétrage et les arbitrages en cas d’incident.
  • Définir les seuils de supervision humaine, c’est à dire les types de réponses que l’humain doit valider avant l’action et quand est ce que l’agent doit escalader.
  • Documenter les cas limites et les comportements attendus y compris les refus. Un agent sans périmètre défini répondra à tout et avec beaucoup d’assurance !
  • Mettre en place un comité de pilotage IA avec revue périodique des métriques, des incidents et des évolutions.

Le sponsoring

Le déploiement d’un agent IA touche les processus, les habitudes de travail et l’organisation. Il est nécessaire d’avoir un un sponsor clairement identifié au niveau direction pour éviter que les équipent opérationnelles freinent l’adoption ou contournent l’agent mais aussi que le projet d’enlise dans les demandes d’exception et les validations de sécurité.

Le sponsor doit être visible, impliqué dans la définition du périmètre et prêt à arbitrer quand l’agent produit des résultats inattendus.

Le change management

Le change management est le prérequis le plus souvent sous-estimé dans le déploiement d’agent IA. Former les utilisateurs, c’est leur faire comprendre ce que l’agent fait précisément, ce qu’il ne fait pas et pourquoi un esprit critique reste indispensable. Un utilisateur qui délègue sans vérifier est un risque opérationnel tout aussi important q’un agent mal configuré.

Cela suppose de redéfinir les processus en amont, à savoir qui valide les sorties de l’agent, comment une erreur est signalée et comment l’agent s’insère dans les flux de travail existants. Cela suppose aussi de construire une culture du feedback, les utilisateurs doivent comprendre que leurs signalements améliorent l’agent et que leurs retours sont effectivement pris en compte, sans quoi il n’y pas de courbe d’apprentissage continue de l’agent.

39 % des organisations citent le change management et la formation comme obstacle majeur à l’adoption des agents IA, un chiffre qui monte à 51 % dans les ETI et PME. (Source Anthropic / Material – The 2026 State of AI Agents Report)

Les agents IA « standards » par domaine métier

Certains modèles d’agents IA sont propches d’une organisation à l’autre. Ces neuf catégories couvrent les cas d’usage que nous rencontrons régulièrement chez Smartpoint. Ils s’intègrent aux systèmes existants sans remettre en cause l’architecture en place.

Selon Anthropic (State of AI Agents 2026), les cas d’usage à plus fort impact déclaré sont l’analyse de données et la génération de reportings (60 %) et l’automatisation des processus internes (48 %). Le développement logiciel est le domaine où les organisations anticipent le plus grand impact dans les 12 prochains mois (57 %).

Ces agents ont un socle commun. Ils accèdent à des sources documentaires structurées, ils ont des mécanismes de modération par supervision humaine pour les cas d’escalade, et des KPI de qualité. Ce qui varie, c’est le niveau d’intégration avec les systèmes / applications métiers et le niveau d’autonomie accordé à l’agent.

Domaine Agents types Résultats attendus
Engineering
  • Pipeline Scaffolder
  • QA & non-régression
  • Documentation & Onboarding
  • Incident Copilot
  • Réduction des incidents en production
  • Couverture de tests augmentée
  • Onboarding accéléré
Finance
  • Closing Copilot
  • Agent de réconciliation
  • Invoice Coding Assistant
  • Reporting Generator
  • Clôture accélérée
  • Écarts réduits
  • Piste d’audit renforcée
Service Client
  • Triage & Routing
  • Reply Drafting
  • After-Call Summary
  • Quality Monitor
  • Traitement plus rapide
  • Réponses plus cohérentes
  • Meilleur routage
Data Steward
  • Glossary Builder
  • Data Contract Checker
  • Access & Policy Assistant
  • Data quality améliorée
  • Dérives détectées plus tôt
  • Accès maîtrisés
Support IT
  • Ticket Copilot end-to-end
  • Runbook Assistant
  • Knowledge Curator
  • Meilleure résolution des tickets
  • Exécution sécurisée
  • Base de connaissance à jour
Opérations IT
  • Copilote SRE
  • Change Risk Analyzer
  • Optimisation FinOps
  • Moins d’incidents critiques
  • Diagnostic accéléré
  • Coûts cloud maîtrisés
Commerce
  • Analyse de compte
  • Copilote RFP/RFI
  • Préparation de rendez-vous
  • Qualification des comptes
  • Réponses aux appels d’offres accélérées
  • Qualité CRM
Achats
  • Comparaison fournisseurs
  • Rapprochement commande/facture
  • Brief de négociation
  • Choix fournisseurs optimisés
  • Rapprochements automatisés
Juridique & Conformité
  • Revue contractuelle
  • Check-list AI Act / RGPD
  • Rédacteur de politiques IA
  • Conformité renforcée
  • Traçabilité et preuves auditables

Un agent IA sur-mesure ?

Les agents IA standards couvrent les cas d’usage les plus fréquents. Mais certains besoins ou contraintes demande une approche sur-mesure : des données sensibles, des contraintes réglementaires spécifiques, des architectures existantes complexes dans lesquelles à intégrer et des enjeux de scalabilité que les solutions packagées ne savent pas adresser.

Voici quelques cas d’usages qui ont demandé à nos équipes IA Smartpoint la conception d’agents IA spécificuqe

Cas 1 Secteur bancaire : Plateforme d’agents conversationnels omnicanale

Grande institution financière, plusieurs dizaines d’entités, plusieurs dizaines de millions de clients.

L’enjeu n’était pas de créer un chatbot FAQ clasqiue. Il s’agissait d’industrialiser une plateforme capable de traiter plusieurs dizaines de milliers de conversations par jour, sur des populations distinctes (clients particuliers, clients professionnels, collaborateurs) avec des niveaux de sensibilité différents.

  • Un routage sémantique dynamique combinant LLM, RAG, NLU et escalade humaine pour avoir un système capable d’orienter chaque demande vers le bon traitement selon son contenu réel.
  • L’exploitation de bases documentaires produits existantes pour des réponses contextualisées
  • Des mécanismes de gouvernance des interactions intégrés dès la conception : modération, audit, gestion des cas limites.
  • Des composants réutilisables pour plusieurs fronts. Le même socle technique alimente l’assistant client, l’assistant conseiller et l’assistant RH avec des configurations spécifiques
  • Une réduction progressive des escalades grâce à l’apprentissage continu et l’augmentation de la couverture dans la durée.

Résultat : plusieurs dizaines de milliers de conversations traitées quotidiennement, avec un passage prévu vers des agents transactionnels à horizon proche.

Cas 2 Secteur banque d’investissement : Document AI sur documents financiers complexes

Banque corporate & investment banking, documents financiers hautement structurés, environnement contraint (produits dérivés, conformité).

Les documents financiers complexes (term sheets de produits dérivés, dossiers de conformité clients) sont des objets fortement structurés mais peu standardisés. L’enjeu était d’automatiser leur traitement tout en garantissant la fiabilité.

  • Des pipelines de traitement complets ont été mis en place : ingestion, parsing, extraction, validation, normalisation, historisation, monitoring.
  • L’architecture repose sur une hybridation rule-based et LLM-based : Sur les données très structurées, les règles métier sont plus fiables et moins coûteuses à l’inférence et sur les parties libres ou ambiguës des documents, le LLM prend le relais.
  • Des pratiques MLOps rigoureuses complètent le dispositif : tests unitaires, non-régression, contrôle qualité à chaque release. L’ensemble est exposé via API REST pour intégration dans les systèmes métiers existants.

Cas 3 Secteur bancaire : Agent cyber pour la détection de fuites de données

Grande banque de détail, logs applicatifs volumineux, enjeux RGPD et conformité.

La détection de fuites de données dans des logs volumineux est un problème car l’analyse manuelle systématique est impossible. Ce cas illustre un agent IA en contexte cyber, un domaine où les exigences de traçabilité, d’auditabilité et de fiabilité sont très fortes. La conformité RGPD et AI Act a été intégrée dès la conception.

  • Un prétraitement sémantique des événements pour filtrer le bruit et extraire les signaux pertinents.
  • Un classifieur sémantique à trois niveaux (non sensible / douteux / sensible) pour prioriser les alertes et calibrer les actions.
  • Un déclenchement automatique d’actions correctives : blocage, notification DPO, ouverture de ticket dans l’outil ITSM.
  • Un dispositif d’audit et de supervision complet : interface de validation pour les analystes, dashboards de suivi, scoring des cas.

Cas 4 Secteur de l’énergie : assistant RH conversationnel

Entreprise industrielle nationale, plusieurs milliers de collaborateurs, RH régionalisées.

Conception et mise en place d’assistant RH conversationnel. +70 % de réponses satisfaisantes dès le premier mois, 4,3/5 de satisfaction moyenne sur plus de 5 000 sessions.

  • Un déploiement contrôlé par groupes utilisateurs pilotes avec itération rapide avant le passage à l’échelle.
  • Une supervision humaine via back-office intégré. Les équipes RH peuvent relire les conversations, corriger les réponses et alimenter l’amélioration continue.
  • Un pilotage rigoureux de la qualité et de l’adoption : sessions suivies, satisfaction mesurée, alertes sur les baisses de performance.

Cas 5 Private Equity : assistant IA pour l’analyse financière et le reporting

Société de gestion, documents financiers non structurés, données sensibles.

Dans un environnement private equity, les reportings financiers sont particulièrement volumineux, hétérogènes et surtout confidentiels. L’enjeu était de permettre aux équipes d’interroger cette donnée via une interface IA, tout en construisant des modèles de prédiction de performance.

  • Un RAG sur documents financiers permettant une interrogation conversationnelle : l’analyste pose une question en langage naturel, l’agent retrouve les passages pertinents dans les reportings et construit une réponse sourcée.
  • Des modèles prédictifs pour les benchmarks sectoriels et les extrapolations de performance : le LLM aide à rédiger et le ML aide à prédire
  • Une aide à la production de rapports : l’agent accélère leur production en pré-remplissant les sections standardisées
  • Une industrialisation et une supervision d’exploitation continues car un agent IA sur des données sensibles sans supervision représente un fort risque réglementaire (et réputationnel)

Agent IA standard ou agent sur-mesure, comment choisir ?

Si vos cas d’usage correspondent aux neuf familles (service client, finance, engineering, support IT, etc.) et que votre SI ne présente pas de contraintes d’intégratio « exotiques », une plateforme d’agents sur étagère est le choix le plus rapide et le plus économique. L’AI Agent Factory de Smartpoint couvre les principaux cas d’usages avec des agents préconfigurés, un socle AgentOps intégré et une conformité AI Act native.

Combien coûte un agent IA ?

Sprint Agent Blueprint
10-15 K€
4 à 6 semaines
  • Cadrage et business cases : 3 à 5 cas d’usage priorisés par scoring risque/valeur
  • Fiche de cadrage Agent et KPI
  • Proof-of-value
  • Architecture cible et roadmap 90 jours
1er agent en production
50-85 K€
8 à 12 semaines selon complexité et écosystème IT
  • 1 agent livré en production avec intégration SI complète
  • Socle AgentOps : logs, traces, évaluation, supervision
  • Garde-fous, traçabilité, tests, runbook
  • Run initial de 6 mois inclus
Run & Scale
5-15 K€ / mois
Supervision et amélioration continue
  • 1 à 3 agents supervisés en production
  • Backlog d’amélioration et KPI qualité/coûts/sûreté
  • Supervision et support selon criticité
  • Industrialisation : templates, connecteurs, déploiements
Options sur devis selon périmètre : trust & control (guardrails, traçabilité et auditabilité), accélérateurs sectoriels et spécifiques métiers. Pour les environnements réglementés ou les déploiements à fort volume, nous concevons un agent sur-mesure intégré à votre infrastructure.

Le sur-mesure est un choix qui s’impose dès que l’une de ces conditions est réunie :

  • Vos données sont sensibles ou classifiées et ne peuvent pas transiter par une infrastructure mutualisée
  • Votre environnement réglementaire impose une traçabilité totale de chaque décision de l’agent (DORA, AI Act haut risque, NIS2)
  • Votre SI existant demande une intégration avec des systèmes legacy ou des APIs propriétaires
  • Le volume et la criticité du déploiement dépassent ce qu’une plateforme standard peut absorber sans dégradation.

Sachez que 92 % des fournisseurs IA revendiquent des droits d’usage larges sur les données qu’ils traitent. (Source : TermScout, via Stanford Law School, 2025). Un agent IA spécifique déployé dans votre infrastructure vous assure que vos données ne quittent pas votre SI et que chaque interaction est auditée sous votre propre gouvernance.

Qu’il s’agisse d’une plateforme conversationnelle traitant des conversations ou des transactions, d’un agent cyber détectant des fuites de données dans des logs applicatifs ou d’un assistant RH, les prérequis sont les mêmes. Un agent IA en production, c’est d’abord une décision architecturale, une gouvernance claire et une organisation prête à assumer la supervision. La technologie est finalement la partie la plus simple.

Les organisations qui réussissent leurs déploiements d’agents IA partagent ont toutes investi dans la qualité des données avant de concevoir l’agent. Elles ont défini clairement les périmètres, les seuils de supervision et les responsabilités avant la MEP et elles ont outillé leurs agents (logs, métriques, alertes, feedback loop).

80 % des organisations qui ont franchi ce cap déclarent un ROI mesurable, avec un retour médian de 4 à 9 mois selon le domaine.

Un agent IA qui fonctionne vraiment en production est le résultat d’une démarche industrielle, portée par une organisation qui a compris que l’IA n’est pas une nouvelle fonctionnalité mais bien un nouveau composant critique de l’architecture Data / IA et décisionnelle de l’entreprise.

Agent IA sur étagère ou développement spécifique, parlons-en.

Smartpoint est une ESN spécialisée en Data et IA, certifiée ISO 27001 et ISO 27701. Nos équipes conçoivent, industrialisent et opèrent des agents IA en production, des cas d’usage standards aux environnements les plus contraints.

Échangez avec un expert IA

IA dans l’assurance en 2026 : de l’expérimentation à l’industrialisation

En 2025, quasiment tous les acteurs du secteur de l’assurance avaient lancé des projets d’intelligence artificielle (Voir le compte rendu de notre Smart Day IA de mars 2025 avec les témoignages de MGEN et du Groupe Vyv). En 2026, avancer sur l’IA est une évidence mais le problème est de comprendre pourquoi tant de projets n’ont pas franchi l’épreuve de la mise en production.

+400 cas d’usage IA ont été référencés dans l’assurance par Klein Blue Praxia. Seule une minorité est réellement industrialisée.

Selon L’Argus de l’Assurance, 2026 marque le changement d’échelle avec le passage en production des premiers cas d’usage, principalement sur l’automatisation de la souscription, la détection de fraude, la priorisation des sinistres et l’analyse documentaire accélérée. Les directions générales attendent désormais des résultats tangibles.

Mais ce basculement suppose une condition préalable que beaucoup d’organisations n’ont pas encore remplie, disposer des données prêtes, gouvernées, fiables et traçables. Et c’est le sujet de fond de cette année que nous rencontrons chez nos clients issus du secteur assurantiel.

Les cas d’usage IA à valeur immédiate en assurance

Le secteur de l’assurance a une particularité, c’est que la plupart de ses processus métiers sont documentaires, séquentiels et répétitifs et c’est précisément ce que l’IA traite le mieux. Voici les cinq domaines où la valeur est la plus immédiate.

1. L’automatisation du traitement des sinistres

Le traitement des sinistres représente 60 % des coûts opérationnels d’un assureur. L’IA avec NLP, vision par ordinateur et extraction documentaire, permet d’automatiser jusqu’à 80 % des sinistres simples comme la classification automatique par type et gravité, l’extraction des informations des constats et factures, l’estimation des dommages et la proposition de règlement.

Source : BGB Formation / McKinsey — Formation IA Assurance 2026

Cette industrialisation réduit les délais de traitement, améliore la satisfaction client et libère les gestionnaires qui peuvent se concentrer sur les dossiers plus complexes. Mais elle suppose une infrastructure documentaire fiable : des données bien structurées, des pipelines robustes, une traçabilité bout en bout.

C’est l’approche que nous avons industrialisée pour le Crédit Agricole sur leur plateforme ANDOR : extraction automatique sur documents financiers complexes, pipelines robustes, conformité intégrée. C’est une architecture directement transposable au traitement des sinistres et des justificatifs.

2. La tarification dynamique et le scoring actuariel

Les modèles de tarification IA permettent d’exploiter des données à un niveau de granularité et de précision jusqu’alors inattegniable par les méthodes actuarielles classiques comme les données comportementales, les télématiques, les historiques de sinistres enrichis et les signaux externes.

Et La pression concurrentielle est très forte avec les insurtechs qui déploient rapidemeny des modèles de tarification IA de plus en plus sophistiqués. Les assureurs traditionnels qui n’adoptent pas l’IA risquent une sélection adverse progressive sur leur portefeuille. Là encore, la qualité des données d’entraînement conditionne directement la précision du modèle et donc la rentabilité technologique.

3. La détection de fraude

La fraude représente plus de 2,5 milliards d’euros par an pour les assureurs français. Les modèles IA de détection de fraude embarquent scoring comportemental, graph analytics (réseaux de fraude organisés), analyse documentaire (détection de faux justificatifs) et analyse des données de déclaration.

Selon le rapport Deloitte Insights FSI Predictions 2025, les assureurs IARD qui intègrent des capacités IA multimodales dans la détection de fraude pourraient générer des économies de 20 % à 40 % et réduire les sinistres frauduleux à hauteur de 80 à 160 milliards de dollars d’ici 2032 à l’échelle mondiale.

4. L’assistance aux conseillers et la relation client

Les assistants IA pour les conseillers vente, les gestionnaires de sinistres ou directement les assurés; révolutionne littéralement l’efficacité opérationnelle : Réponses contextualisées, aide à la vente, selfcare sinistres, réduction des escalades.

Ces cas d’usage GenAI sont parmi les plus rapides à déployer à condition que les bases documentaires métier (contrats, FAQs, règles de gestion) soient structurées et gouvernées. Un assistant IA est aussi bon que les données sur lesquelles il s’appuie…

C’est le modèle que nous avons industrialisé chez BPCE avec une plateforme d’assistants IA déployée sur 40 entités : assistant client omnicanal, assistant conseiller pour l’aide à la vente et le support métier, assistant RH couvrant congés et mutuelles. Plus de 10 000 conversations par jour, avec une réduction progressive des escalades grâce à l’apprentissage continu. Une architecture directement transposable aux équipes commerciales et aux centres de gestion d’un assureur.

5. La souscription intelligente

L’automatisation de la souscription, notamment en assurance entreprise, réduit les délais de traitement, améliore la cohérence des décisions et libère les souscripteurs pour les risques complexes. Les modèles IA analysent les données internes, les données tiers (score financier, données sectorielles) et les historiques pour qualifier rapidement l’éligibilité et proposer une tarification personnalisée.

Le frein à l’industrialisation de l’IA ? la donnée, pas le modèle

Les principaux points de blocage qui freinent l’IA chez nos clients dans l’assurance n’est pas d’ordre IT, il concerne les données :

  • Des données adhérents fragmentées entre des systèmes legacy qui ne se parlent pas (core system, CRM, portail sinistres, outils actuariels).
  • Une traçabilité insuffisante, personne ne sait exactement qui possède quoi, comment les données ont été transformées, ni sur quelle version un modèle a été entraîné.
  • Des reportings qui divergent selon l’outil ou le service : C’est LE signal classique d’une gouvernance des données non opérée.

Ces trois problèmes forment ce que nous appelons la dette de gouvernance. Et elle bloque l’IA aussi inexorablement qu’une mauvaise architecture des données.

Un modèle IA ne corrige pas les données déficientes, il les industrialise à une échelle jusqu’alors jamais atteinte. Si vos données de sinistres sont incohérentes, votre modèle de priorisation produira des incohérences à grande échelle et avec force de conviction. C’est précisément notre approche en gouvernance des données comme fondation de l’IA.

AI Act et assurance : le compte à rebours réglementaire

Vos modèles IA sont classés « à risque élevé »

La qualification d’IA à risque élevé n’est ni théorique ni marginale pour les assureurs, elle découle directement de la nature même de l’activité assurantielle à savoir tarification, scoring de souscription, détection de fraude et priorisation des sinistres. Tous ces modèles sont concernés par l’AI Act.

Le 2 août 2026 est une échéance majeure. À cette date, les systèmes qualifiés d’IA à risque élevé doivent être pleinement conformes au cadre européen.

Ce que cela implique concrètement pour les CDO et DSI d’assurance

  • Explicabilité des modèles : toute décision automatisée (refus de souscription, scoring sinistre, suspicion de fraude) doit pouvoir être expliquée à l’assuré et à l’autorité de contrôle.
  • Traçabilité des données d’entraînement : vous devez pouvoir documenter l’origine, la qualité et les transformations des données ayant servi à entraîner vos modèles.
  • Documentation des modèles : fiches techniques, évaluations des risques, logs de supervision.
  • Gouvernance humaine : maintien d’une supervision humaine sur les décisions à fort enjeu.

Sans data lineage structuré et politique de qualité des données opérée, ces obligations sont impossibles à satisfaire.

Solvabilité 2, NIS2, RGPD : le cocktail réglementaire complet

L’AI Act n’est pas la seule contrainte. Les CDO d’assurance doivent composer avec un environnement réglementaire particulièrement contraint :

  • Solvabilité 2 impose la traçabilité et la qualité des données actuarielles utilisées dans les modèles de calcul des provisions, du SCR et de l’ORSA. Les données de risque doivent être auditables.
  • NIS2 (transposée en France en 2024) oblige les entités essentielles et importantes à documenter et tracer les flux de données critiques dans le cadre de la gestion des risques cyber. Les grandes compagnies d’assurance sont directement concernées.
  • RGPD et données de santé plus particulièrement pour les mutuelles et institutions de prévoyance qui traitent ces données particulièrement sensibles. Toute utilisation dans un modèle IA (remboursement, prévention, tarification santé) est soumise aux exigences les plus strictes.

Ces réglementations convergent toutes vers la même exigence technique à savoir disposer impérativement de données prouvables, auditables, défendables. La gouvernance des données n’est plus un projet de fond, c’est devenu une obligation opérationnelle.

Comment les CDO et DSI d’assurance s’organisent ?

Selon le rapport CDO Insights 2026 d’Informatica et Deloitte, 90 % des entreprises prévoient d’augmenter leurs investissements en gestion des données. Les priorités sont de renforcer la gouvernance des données et de l’IA (52 %), améliorer les processus opérationnels (46 %) ey améliorer la confidentialité et la sécurité (43 %).

Dans l’assurance, les organisations les plus avancées sur ces sujets ont fait le choix structurant de traiter la gouvernance des données avant de déployer leurs modèles IA, et non après avoir constaté les échecs. Concrètement, voici le plan d’actions selon nos experts Smartpoint :

  • Un benchmark et une sélection d’une solution de Data Quality adaptée à leur architecture (Collibra, DataGalaxy, Alter X, ataccama…)
  • La mise en place d’un programme de gouvernance couvrant les données critiques : adhérents, sinistres, données actuarielles, données de conformité
  • Une organisation cible avec des Data Owners métier identifiés et actifs, pas des rôles nominaux sur un organigramme
  • Un pilotage continu de la qualité des données avec des indicateurs et des alertes (pas un audit annuel)

Par où commencer ? 3 étapes en 90 jours

La gouvernance des données n’est pas un projet avec une date de fin. Mais il existe un chemin pragmatique pour démarrer sans tout traiter en parallèle.

Action 1 : Identifier vos données critiques pour l’IA

Pas toutes les données, uniquement celles dont la qualité conditionne vos cas d’usage IA prioritaires : données sinistres pour l’automatisation, données adhérents pour le scoring, données comportementales pour la tarification. Le périmètre cible est de 20 à 40 datasets critiques pour une gouvernance opérable.

Action 2 : Qualifier votre exposition AI Act

Faites l’inventaire de vos modèles IA en production ou en cours de déploiement. Quels sont ceux qui traitent des décisions à fort enjeu (tarification, refus, scoring sinistre) ? Ce sont vos systèmes à risque élevé au sens de l’AI Act et ils nécessitent une documentation et une gouvernance spécifiques. Notre expertise en cybersécurité des plateformes Data & IA couvre ce périmètre.

Action 3 : Lancer la gouvernance sur un périmètre limité

Ne pas chercher à tout gouverner d’un coup ! Nous vous recommandons de choisir un domaine métier (sinistres ou souscription) et de mettre en place les rôles Data Owner / Steward, les règles de qualité et le data catalog. Il est nécessaire de valider le modèle sur ce périmètre avant de l’étendre à d’autres. C’est l’approche que nous privilégions pour l’organisation data et les modèles de gouvernance.

Pas d’IA sans données

L’intelligence artificielle dans l’assurance est devenu un impératif concurrentiel, réglementaire et opérationnel. Les assureurs qui industrialisent leurs projets IA en 2026 ne seront pas ceux qui ont les meilleurs modèles, ce seront aux qui ont mis leurs données en état de les alimenter.

La bonne nouvelle, c’est que ce travail de fondation (gouvernance, qualité, traçabilité) crée de la valeur au-delà de l’IA. Il fiabilise le pilotage, simplifie la conformité et renforce la confiance des métiers dans leurs données.

La mauvaise nouvelle est que chaque mois de retard est un mois de plus où vos modèles tournent sur des données dont vous ne garantissez pas la fiabilité. Et c’est un mois de plus d’exposition réglementaire face au 2 août 2026.

Audit flash

Vous souhaitez évaluer votre maturité data pour l’IA ?

Smartpoint propose un audit flash Data Governance à 3 000 €HT : diagnostic sur un périmètre métier défini, livrable structuré, résultats en 2 semaines.

3 000 €HT Engagement fixe
2 semaines Délai livrable
1 périmètre Métier défini

Pour aller plus loin

Articles Smartpoint sur la gouvernance des données et l’IA :

Smartpoint, ESN parisienne indépendante, pure player Data & IA depuis 2006. +300 experts. ISO 27001/27701.

Data Mesh, Data Fabric, Lakehouse : quelle architecture data pour moderniser votre plateforme ?

Temps de lecture
12 minutes
Auteurs
Luc Doladille & Emmanuelle Parnois

Mis à jour le 9 juin 2026

Chez Smartpoint, nous constatons que nombreux sont les DSI et les CDO qui ont comme priorité de moderniser leur plateforme Data en repensant l’architecture. Et c’est un choix très structurant car certes, les technologies ont changé (mais elles évoluent sans cesse) mais surtout la multiplication des projets IA a rendu ce choix urgent.

Alors, oui, il faut moderniser votre plateforme data mais entre Data Mesh, Data Fabric et Data Lakehouse, quelles sont les alternatives en termes de choix d’architecture qui s’offrent à vous, quelles sont les conséquences et les impacts ? Voici nos éléments de réponse.

Pourquoi le choix de l’architecture Data est déterminant ?

Jusqu’à présent, l’architecture data était un sujet exclusivement de DSI .Aujourd’hui, elle conditionne directement la capacité d’une organisation à déployer de l’IA à grande échelle.

68%

des DSI français placent la modernisation de l’architecture data dans leur top 3 des priorités pour 2026, portée par l’IA générative, les exigences réglementaires (RGPD, DORA) et la pression des métiers.

Source : Silicon.fr — Les Benchmarks de l’IT 2026, d’après Gartner France (2025)

Cette urgence de modernisation de l’architecture Data est motivée par :

  1. L’IA générative a besoin d’une infrastructure data solide. Les LLM (Large Language Models) et les architectures RAG (Retrieval-Augmented Generation) sont opérables en production que si les données sont fiables, accessibles et bien gouvernées. Une architecture classique legacy ETL/DWH on-premise freine l’industrialisation de l’IA.
  2. La réglementation s’est durcie. RGPD, DORA, NIS2 et AI Act, les exigences de traçabilité, d’auditabilité et de souveraineté des données imposent une gouvernance que seules les architectures Data modernes peuvent vraiment supporter (À lire notre guide Architectures Data Modernes – édition 2024)
  3. Les métiers perdent patience ! La pression pour un accès plus rapide, plus simple et plus autonome à la donnée ne vient plus seulement des équipes data mais aussi des directions métiers qui veulent des réponses rapides et ne plus attendre des semaines.

Ces trois priorités ouvre le débat du bon choix d’architectures selon votre contexte et votre écosystème IT.

Qu’est-ce que le Data Lakehouse et pourquoi c’est devenu une norme dans les SI ?

Le Data Lakehouse est une architecture hybride qui combine la flexibilité et le faible coût d’un Data Lake (stockage massif de données brutes) avec la structure, la performance et la gouvernance d’un Data Warehouse. Il repose sur un format de stockage ouvert (Delta Lake, Apache Iceberg), une séparation stricte du stockage et du calcul et un moteur unifié capable de gérer simultanément des workloads SQL analytiques, du machine learning et du streaming temps réel.

Ce que le Lakehouse apporte à votre SI Data

L’architecture Lakehouse élimine le problème de la duplication des données entre un Data Lake (flexible mais ingouvernable) et un Data Warehouse (performant mais rigide et coûteux). Avec un Lakehouse, les mêmes données servent tous les usages BI, ML et streaming, sans pipeline de synchronisation.

Les caractéristiques du Data Lakehouse :

  • Format de table ouvert (Delta Lake / Apache Iceberg) : transactions ACID, versioning, time travel, évolution des schémas sans interruption de service
  • Séparation stockage / calcul : le stockage sur S3, GCS ou ADLS est totalement indépendant du moteur de requête, vous payez séparément ce que vous stockez et ce que vous calculez
  • Couche de métadonnées unifiée (Unity Catalog, Iceberg REST) : gouvernance centralisée du lineage, des accès et de la qualité sur l’ensemble de la plateforme
  • Interopérabilité multi-cloud : les formats ouverts sont lisibles par plusieurs moteurs (Spark, Snowflake, Athena, BigQuery Omni) ce qui limite le lock-in vendor

En 2026, Apache Iceberg s’est imposé comme le format de table ouvert dominant, devant Delta Lake. Snowflake a lancé Polaris Catalog (open source, compatible Iceberg), AWS a introduit S3 Tables nativement sur Iceberg, et Google BigQuery l’a adopté comme format d’interopérabilité prioritaire. Pour les DSI, cela signifie qu’un choix d’architecture basé sur Iceberg garantit aujourd’hui la meilleure portabilité multi-cloud et limite significativement le risque de lock-in éditeur.

ÉDITEURS PRINCIPAUX : Microsoft Fabric, Databricks (inventeur du concept), Snowflake, Google BigQuery, AWS et dbt Labs pour la couche de transformation.

Pour qui est le Lakehouse ?

Le Lakehouse est une architecture Data particulièrement adapté à toute organisation qui reconstruit ou modernise sa plateforme data from scratch. Si vous avez des usages BI analytique, machine learning et data engineering, si vous avez besoin de traiter des données hétérogènes (structurées, semi-structurées, non structurées) et si vous voulez éviter de maintenir deux plateformes Data ; Le Data Lakehouse est un bon choix.

Qu’est-ce que le Data Fabric et quand est ce que cette architecture est à privilégier ?

Le Data Fabric est une couche d’intégration intelligente qui connecte des sources de données hétérogènes et distribuées (on-premise, cloud, SaaS) sans forcément les déplacer. Il s’appuie sur des métadonnées actives, des graphes de connaissance et souvent de l’IA pour automatiser la découverte, l’intégration et la gouvernance des données à travers l’ensemble du système d’information.

Ce que le Data Fabric apporte à votre SI Data

Alors que le Lakehouse centralise les données, le Data Fabric fait l’inverse. Dans la réalité des SI de grands groupes, vous ne centraliserez jamais tout. Des données critiques resteront dans vos ERP SAP, vos bases Oracle legacy, vos SaaS Salesforce ou Workday. La Data Fabric crée une couche d’accès et de gouvernance unifiée par-dessus cette complexité sans migration massive.

Les caractéristiques du Data Fabric :

  • Métadonnées actives fédérées (Informatica IDMC, IBM Knowledge Catalog, Google Dataplex) : Contrairement aux métadonnées passives et statiques, elles s’appuient sur l’IA et des graphes de connaissance pour analyser en continu les données, détecter les schémas, déclencher des alertes et automatiser la classification, sans déplacer physiquement les données
  • Virtualisation des données : une couche d’accès unifié permet d’interroger et de mixer des sources disparates (bases on-premise, cloud, SaaS, ERP) sans ETL ni duplication; les données restent là où elles sont, seules les métadonnées sont intégrées (Denodo, Tibco, Dremio)
  • Gouvernance fédérée automatisée : les politiques de sécurité, de conformité (RGPD, DORA, AI Act) et de qualité sont définies centralement puis appliquées automatiquement par le ML sur l’ensemble des sources sans intervention manuelle par équipe
  • Connectivité hybride et multi-cloud native : des connecteurs préconstruits relient en natif les environnements on-premise, AWS, Azure, GCP et les applications SaaS ; ce qui en fait un modèle d’architecture de choix pour les SI qui ne peuvent pas migrer intégralement vers le cloud

Le Data Fabric est donc à privilégier dans des SI où une migration totale vers le cloud est impossible ou trop risquée (banques, industriels, secteur public), et dans une contexte de fortes contraintes règlementaires où les données ne peuvent pas quitter certains périmètres géographiques ou systémiques (souveraineté, DORA, données de santé).

ÉDITEURS PRINCIPAUX : Talend (Qlik)IBM Data FabricInformatica IDMCDenodo leader en virtualisation de données, SAP incontournable pour les environnements SAP.

Pour qui est le Data Fabric ?

Le Data Fabric est une artchitecture Data à privilégier dans une organisation avec un SI existant complexe, des enjeux de souveraineté ou de réglementation forte et qui n’a pas les moyens ou la volonté de tout migrer dans un seul cloud. Dans la réalité, nous constatons que Le Data Fabric est souvent une étape de transition ou un complément d’un Lakehouse plutôt qu’une architecture cible autonome.

Qu’est-ce que le Data Mesh et pourquoi il est complémentaire avec les deux autres ?

Le Data Mesh n’est pas une technologie mais un principe organisationnel. Il repose sur la décentralisation de la propriété et la production des données. Chaque domaine métier (finance, RH, supply chain, marketing) devient responsable de ses propres « Data Products » qui sont des jeux de données documentés, versionnés, découvrables et utilisables directement par les consommateurs. Une plateforme data commune, souvent un Lakehouse fournit l’infrastructure partagée où les équipes domaines gèrent leur propre pipeline et leur propre qualité.

Ce que le Data Mesh apporte à votre SI Data

Le Data Mesh répond à la limite organisationnelle des architectures centralisées où l’équipe data centrale devient un goulet d’étranglement dès lors que les demandes métiers explosent. En rendant chaque domaine propriétaire de ses données (ownership), le Data Mesh distribue la responsabilité et accélère la mise à disposition.

Les quatre principes fondateurs :

  1. Ownership par domaine : chaque équipe métier produit et maintient ses Data Products
  2. Data as a Product : les données sont traitées comme un produit avec SLA, documentation et versioning
  3. Plateforme data en self-service : l’infrastructure partagée permet aux domaines d’agir en autonomie
  4. Gouvernance fédérée : des standards communs (sécurité, qualité, intéropérabilité) sont définis centralement mais appliqués localement

Pour qui est le Data Mesh ?

Le Data Mesh est à privilégier dans les organisations où l’équipe data centralisée est devenue un frein. Dès lors que vous avez plusieurs centaines de collaborateurs ayant des interactions régulières avec la data et une culture Product développée, c’est une bonne solution.

En revanche, le Data Mesh sans maturité organisationnelle préalable produit l’effet inverse, ça devient un total « Data Mess » avec une prolifération incontrôlée de pipelines hétérogènes que personne ne maintient et une gouvernance approximative.

Il est important de noter que le Data Mesh est un modèle organisationnel, pas une technologie. Il s’appuie toujours sur une plateforme data commune, souvent un Lakehouse comme infrastructure partagée. L’un sans l’autre ne fonctionne pas.

Data Mesh vs Data Fabric vs Lakehouse, le comparatif

Critère Data Lakehouse Data Fabric Data Mesh
Nature Architecture technique Couche d’intégration Paradigme organisationnel
Principe Centralisation + unification Interconnexion sans migration Décentralisation par domaine
Gouvernance Centralisée
(Unity Catalog, Iceberg REST)
Automatisée par métadonnées actives Fédérée
(standards communs, ownership local)
Point fort Performance, IA/ML, maîtrise du TCO Hétérogénéité SI, souveraineté, conformité Scalabilité organisationnelle
Point faible Migration initiale coûteuse Complexité d’intégration Maturité organisationnelle élevée requise
Prérequis clé Données migrables vers le cloud SI hétérogène non migratable Culture produit + équipes data autonomes
Exemple France Scale-up, ETI, grand compte en projet greenfield data Grand groupe, banque, industrie, secteur public CAC40 data-mature, ETI 500+ avec culture produit
Horizon 6 – 18 mois 12 – 36 mois 18 – 48 mois
Technologies Databricks, Snowflake, Microsoft Fabric, Delta Lake, Iceberg, dbt IBM, Informatica IDMC, Denodo, Talend (Qlik), SAP Lakehouse commun + dbt + catalogue data (Atlan, Unity Catalog)

Ces trois modèles ne sont pas des options mutuellement exclusives sur un même axe. Le Lakehouse est souvent la plateforme technique sur laquelle s’appuie un Data Mesh. Le Data Fabric peut coexister avec un Lakehouse pour gérer les sources legacy non migrées. Il s’agit de couches d’architecture complémentaires, pas de concurrents.

Comment choisir le bon modèle d’architecture Data pour votre organisation ?

Évidemment, ll n’existe pas de réponse universelle car le bon modèle d’architecturé Data dépend de quatre variables parmi lesquels vous devez arbitrer.

Variable 1 : Quelle est votre niveau dans votre maturité data ?

  • Maturité faible à moyenne (DWH on-premise, pipelines ETL fragiles, peu de données en self-service), nous vous recommandons chez Smartpoint de commencer par le Lakehouse. C’est le socle technique qui vous permettra ensuite de déployer de l’IA et d’envisager un Data Mesh.
  • Maturité élevée mais SI très hétérogène (ERP, bases legacy, cloud multi-fournisseurs), nous vous recommandons de mettre en place une couche Data Fabric en complément ou en transition.
  • Maturité élevée et organisation à forte culture Data Product, nous cous recommandons d’engager la transformation vers le Data Mesh en vous appuyant sur un Lakehouse comme infrastructure commune.

Variable 2 : quel est votre roadmap IA ?

Si vous avez des projets d’IA générative (copilotes métiers, RAG, agents autonomes) à déployer dans les 12 prochains mois, la priorité est pour nous de pouvoir disposer rapidement d’un socle Lakehouse opérationnel avec une couche de gouvernance unifiée. Aucun modèle d’architecture de donnée ne remplacera la nécessité de disposer d’une donnée fiable, accessible et gouvernée pour alimenter vos LLM.

En 2026, les agents IA autonomes (LangGraph, AutoGen, agents Databricks) consomment et produisent de la donnée en temps réel. Cela impose latence faible, gouvernance des accès en temps réel et pipelines capables d’ingérer des retours d’agents. Un Lakehouse mal configuré pour le streaming devient un goulot d’étranglement dès que vos agents passent à l’échelle.

Variable 3 : quels sont vos enjeux de souveraineté et de conformité ?

Si vous opérez dans un secteur fortement réglementé (finance, santé, secteur public) ou si la localisation des données est une contrainte légale, le Data Fabric a des mécanismes natifs pour gérer la donnée distribuée sans nécessiter de migration totale vers un cloud tiers. Associé à une offre de cloud souverain (SecNumCloud), il peut répondre aux exigences DORA et RGPD les plus strictes.

À cela s’ajoute désormais l’AI Act, pleinement applicable en 2026. Pour tout système IA classé à haut risque, il impose une traçabilité complète des données d’entraînement et de fine-tuning, ainsi qu’une documentation des pipelines de données associés. Concrètement, votre architecture data doit être capable de produire un lineage complet et auditable (via Unity Catalog, OpenLineage ou Apache Marquez) sous peine de non-conformité réglementaire. Ce critère doit entrer dans votre décision architecturale au même titre que le RGPD.

Variable 4 : quelle est la taille de votre organisation data ?

En dessous d’une quinzaine de personnes dans l’équipe data, un Data Mesh créera plus de complexité organisationnelle qu’il n’en résoudra. Concentrez-vous sur la solidité technologique de votre Lakehouse et sur la qualité de vos pipelines. Le Data Mesh viendra quand la pression organisationnelle le rendra indispensable.

Les erreurs les plus fréquentes que nous observons chez nos clients DSI

Erreur n°1 : confondre Data Fabric et Data Lakehouse. Ce sont deux niveaux d’abstraction différents. L’un intègre et connecte (Fabric) alors que l’autre stocke, transforme et restitue de façon unifiée (Lakehouse). Ils coexistent souvent dans les architectures cibles matures.

Erreur n°2 : lancer un Data Mesh sans maturité organisationnelle. Le Data Mesh sans culture produit forte et sans équipes data bien formées produit une prolifération incontrôlée de pipelines hétérogènes que personne ne maintient. La transformation organisationnelle prend 18 à 36 mois. Le Data Mesh ce n’est pas un projet IT, c’est un projet de transformation.

Erreur n°3 : choisir une architecture sur la base du discours éditeur. Snowflake parle de Lakehouse, Databricks parle de Lakehouse aussi, Microsoft parle de Fabric et Google parle de Lakehouse natif IA. Chaque éditeur habille ses produits avec les buzz words du moment. Ce qui est le plus important, c’est la bonne évaluation de vos cas d’usage réels, de votre stack existante et de votre trajectoire IA à 24 mois.

Erreur n°4 : ne pas intégrer le TCO dans la décision. Le choix de passer à un Lakehouse cloud-native peut réduire significativement le TCO en 18 à 24 mois (séparation stockage/calcul, formats ouverts, fin des licences DWH on-premise) mais la migration elle-même a un coût initial réel qui doit être modélisé et présenté au CODIR avec un plan de retour sur investissement.

Erreur n°5 : empiler les modèles d’architecture. Avoir un Lakehouse sur AWS, une couche Data Fabric et lancer un programme Data Mesh en parallèle sans logique architecturale produit une complexité ingérable. L’architecture cible doit être définie avant les choix technologiques.

Erreur n°6 : sous-estimer les coûts cloud en production. Databricks, Snowflake et Microsoft Fabric facturent à la consommation. Des workloads IA non optimisés peuvent multiplier la facture par 3 ou 4 en quelques semaines. Le FinOps data :pilotage des coûts par workload, par domaine, par équipe, doit être intégré dès la conception de l’architecture, pas après la première facture surprise.

Vers quelle architecture data cible ?

La tendance que nous observons chez nos clients français en 2026 est la convergence progressive vers une architecture à trois couches :

  1. Socle Lakehouse : Stockage ouvert, séparation stockage/calcul et gouvernance unifiée avec Databricks, Snowflake ou Microsoft Fabric selon votre stack cloud et dbt comme couche de transformation standard
  2. Couche de gouvernance et d’intégration selon votre écosystème : Un catalogue de données (Microsoft Purview, Atlan, Collibra) pour les stacks cloud-natives ou une couche Data Fabric complète (IBM, Informatica, Denodo) pour les SI avec sources legacy non migrées et fortes contraintes réglementaires (RGPD, DORA, AI Act)
  3. Organisation Data Mesh progressive pour les domaines métiers les plus matures, en s’appuyant sur la plateforme commune comme infrastructure de self-service, domaine par domaine, jamais en transformation globale

Cette architecture cible n’est pas à déployer d’un coup. Les DSI qui réussissent leur modernisation de leur plateforme data en 2026 le font en phases de 6 à 12 mois, en commençant par consolider le socle Lakehouse avant d’adresser les dimensions organisationnelles.

La roadmap Architecture Data cible

  • Data Lakehouse, Data Fabric et Data Mesh ne s’opposent pas ; ils répondent à des problèmes différents et peuvent être complémentaires dans une architecture cible mature.
  • Le Lakehouse est le point d’entrée naturel pour toute modernisation de plateforme data, quel que soit votre horizon Data Mesh ou Data Fabric.
  • Le choix du modèle doit précéder le choix de l’éditeur; ne laissez pas Databricks, Snowflake ou Microsoft décider de votre architecture cible.
  • La modernisation data est le prérequis n°1 à l’industrialisation de l’IA ; sans socle data solide, vos projets LLM resteront des pilotes.
  • Faites évaluer votre maturité data actuelle avant toute décision architecturale ; un diagnostic évite des choix prématurés et des dépenses inutiles.

Comment Smartpoint accompagne les DSI et CDO dans leur choix d’architecture data

Chez Smartpoint, nous sommes une ESN pure player Data & IA qui consacre 100 % de ses ressources à ces enjeux. Depuis 2015, nous accompagnons les DSI et CDO de grandes organisations françaises dans la définition et la mise en œuvre de leurs architectures data cibles, de l’audit de maturité au déploiement en production.

Notre approche est volontairement indépendante des éditeurs. Nous évaluons Databricks, Snowflake, Microsoft Fabric et les solutions open source en fonction de vos cas d’usage réels, de votre contexte réglementaire et de votre trajectoire IA.

Vous êtes DSI ou CDO et vous souhaitez évaluer votre architecture data cible pour 2026-2027 ? Nos experts sont disponibles pour réaliser votre diagnostic de maturité data et votre revue architecturale.

→ Découvrir notre offre Architecture Data / IA
→ Prendre rendez-vous avec un expert

Vous êtes DSI ou CDO ?

Faites évaluer votre architecture data cible pour 2026

Nos experts Smartpoint réalisent un diagnostic de maturité data et une revue architecturale sans engagement.

Prendre rendez-vous avec un expert →

Article rédigé par les experts Data & IA de Smartpoint, mis à jour en mai 2026.

Ressources complémentaires

Data Warehouse ou Lakehouse : quelle architecture choisir pour votre SI Data ?

Temps de lecture estimé : 9 min Architecture Data & IA & Modernisation SI Data Smartpoint Paris

Le faut débat des architectures data

Il y a encore quelques années, le débat fait rage dans toutes les comités d’architecture. D’un côté, les gardiens du temple du data warehouse, reconnu pour sa stabilité, sa gouvernance et sa fiabilité De l’autre, les évangélistes du lakehouse portés par son agilité, sa scalabilité et sa compatibilité avec l’IA. Depuis, les lignes ont bougé. Non pas qu’un camp ait eu raison de l’autre mais parce que les équipes terrain ont constaté que les deux approches n’étaient pas en concurrence mais bien complémentaires. Les deux se conjuquent parfaitement dans un SI Data performant.

Nous vous proposons dans cet article de partager nos retours d’expérience sur ce que nous constatons au quotidien chez Smartpoint sur les différents projets de modernisation de plateformes data que nous menons pour des DSI et des CDO qui doivent arbitrer dans des contextes généralement très contraints.

Le data warehouse, cet incontournable du SI Data

Le data warehouse a mauvaise réputation, jugé trop rigide, trop lent, trop cher. Cette caricature a la vie dure alors que le datawarehouse a au contraire su batir sa légitimité sur la confiance dans la durée.

C’est le Datawarehouse qui est derrière le dashboard P&L du contrôleur de gestion, le rapport réglementaire Bâle 4 de l’Analyste Risques ou encore la clôture des comptes trimestriels. Son atout coeur ? La reproductibilité du résultat.

Le modèle schema on write, qui impose de définir la structure avant d’ingérer la donnée, est certes une forte contrainte mais elle oblige les équipes à documenter, à modéliser et à trancher sur la sémantique métier avant. C’est coûteux en amont mais c’est ce qui permet à un KPI d’avoir la même signification pour tout le monde dans l’entreprise.

D’ailleurs plateformes cloud-native modernes, comme Snowflake, BigQuery, Azure Synapse ou Redshift, ne s’y sont pas trompées et ont dépoussiéré le datawarehouse. Séparation compute/storage, scalabilité élastique, support du semi-structuré (JSON, Parquet), connecteurs natifs vers les outils BI et ML; le datawarehouse 2026 n’a plus grand-chose à voir avec les appliances Teradata d’il y a quinze ans !

Pour la BI critique, le reporting financier, la conformité réglementaire et tout contexte où la donnée doit être auditée, certifiée, gouvernée; le data warehouse reste pour Smartpoint l’architecture de référence.

— Smartpoint · Architecture Data & IA

Le lakehouse, le socle de la data moderne

Avant le lakehouse, l’architecture Data était vécue comme une épreuve … Two-stack hell : un datalake pour ingérer sans contrainte (S3/ADLS, tout format, tout schéma) et un warehouse pour la BI. Entre les deux, un no man’s land de jobs Spark mal versionnés, de schémas qui driftent et de pipelines qui tombent en pleine nuit parce qu’un upstream a étrangement changé un type de colonne. La double ingestion et le double compute faisaient dériver les coûts sans aucune valeur ajoutée. Sans data contract formalisé entre les deux mondes, chaque modification en amont était une véritable bombe à retardement pour les pipelines en aval.

Conceptualisé et popularisé notamment par Databricks avec Delta Lake, puis standardisé via Apache Iceberg et Apache Hudi; Le lakehouse s’est imposé comme la réponse architecturale la plus solide après des années de recalculs, d’engagements de service non tenus et de dette technique accumulée à coups de patchs. Le principe consiste à poser une couche de gestion transactionnelle (garanties ACID, versioning, time travel) directement sur un stockage objet économique comme S3, ADLS ou GCS, puis à exposer au-dessus une couche SQL pour l’analytique et une autre Python/Spark pour les workloads machine learning.

Nos équipes de data engineers ont tout se suite étaient séduites par le modèle schema on read qui consiste à ingérer d’abord et à structurez ensuite. L’inverse du datawarehouse, plus besoin de modéliser parfaitement dès le départ. La donnée brute atterrit dans la zone bronze, elle est nettoyée en silver, puis agrégée et enrichie en gold. C’est l’architecture médaillon et elle est devenue le cadre de référence pour la plupart des plateformes data modernes.

Mais le vrai Game Changer du lakehouse, c’est son rapport natif à l’IA. En effet, nos équipes de data scientists et de ML engineers opèrent dans l’écosystème Python (Scikit-learn, PyTorch, HuggingFace, Pandas) et ils ont besoin d’accéder à de la donnée brute, à du feature store et à des volumes massifs pour l’entraînement. Le lakehouse met ces capacités à disposition nativement alors que le datawarehouse contraignait les équipes à multiplier les exports, les conversions et autres compromis.

En bref, si votre roadmap Data 2026 inclut du ML, de la GenAI, du RAG ou de l’analytique temps réel (et c’est plus que probable !), le lakehouse s’impose clairement.

Le comparatif entre Data Warehouse et Data Lakehouse

Voici un tableau récapitulatif des différents critères de comparaison entre ces deux architectures data par nos architectes Data.

CritèresData WarehouseData Lakehouse
Structure des donnéesSchema on write, rigide mais solideSchema on read, flexible mais demande de la discipline
Time to ingestLong (modélisation requise)Court (ingestion brute possible)
Performance analytique BIExcellente nativementBonne à très bonne selon l’optimisation (Z-Order, partitioning)
Workloads ML / IALimité, nécessite des exportsNatif avec accès direct depuis Spark, Python, notebooks
Coût infrastructureÉlevé à très élevé (compute + storage couplés)Optimisable (stockage objet cheap + compute élastique)
GouvernanceMature : lineage, RBAC, audit nativementDe mieux en mieux : Unity Catalog, Iceberg REST mais est à outiller
Conformité RGPD / AI ActOutils maturesNécessite une couche de gouvernance dédiée
ÉvolutivitéDifficile sans refonte de modèleHaute : Ajout de sources sans impact majeur
Maturité de l’écosystèmeTrès matureMature et en croissance rapide

Ce tableau ne fait pas foi et nous sommes amenés à challenger ces critères dans chaque contexte client : Cas d’usages prioritaires, régulations du secteur d’activité, SI Data legacy, maturité des équipes. Un travail d’arbitrage architectural nécessite un cadrage et ne se résume jamais en un simple benchmark même si cela donne des repères.

L’architecture médaillon, le meilleur des mondes

Nous avons déjà prôné l’architecture Médaillon (ou medallion architecture) à de nombreuses reprises (Architecture Data : le modèle Médaillon, la solution à la dette technique ?), elle est devenue le modèle de référence pour organiser un lakehouse et par extension, pour structurer la transition entre ingestion brute et analytique gouvernée.

Le principe est simplissime et redoutablement efficace :

  • Zone Bronze : La donnée brute telle qu’elle est ingérée. Logs applicatifs, flux Kafka, extractions API, fichiers CSV mal formatés. Pas de transformation, tout est conservé et c’est la source of truth de l’historique.
  • Zone Silver : La donnée nettoyée avec déduplication effectuée, typage homogénéisé et règles de qualité appliquées. C’est la zone où on commence à faire confiance à la donnée
  • Zone Gold : La donnée agrégée, enrichie, modélisée pour un usage métier spécifique. C’est dans cette zone qu’on retrouve les datasets prêts pour le reporting BI, les feature stores ML ou les RAG pipelines GenAI.

Ce qui est intéressant dans le modèle Médaillon, c’est qu’il réconcilie l’approche du Lakehouse et cette du Datawhare. La zone gold se comporte comme un datamart : gouvernée, structurée, fiable. Les zones bronze et silver conservent la flexibilité du datalake. Et l’ensemble est dans le même système Data avec un seul catalogue et un seul plan de gouvernance des données.

Chez Smartpoint, nous implémentons ce modèle architectural avec Delta Lake sur Databricks, Apache Iceberg sur des stacks AWS ou GCP ou encore dbt pour orchestrer les transformations silver vers gold sur Snowflake ou BigQuery. Le choix de la technologie est finalement assez secondaire, c’est davantage la discipline d’implémentation qui fait la différence dans ce type de projet.

Extrait de cas d’usages d’arbitrage d’architectures Data

Cas 1
Reporting financier & conformité réglementaire
Choix Data Warehouse
Un grand bancaire français devait produire ses reportings prudentiels (COREP, FINREP), ses arrêtés comptables et ses tableaux de bord risques. La donnée devait être certifiée, traçable et reproductible. Le choix architectural s’est porté sur un data warehouse Snowflake. Le lakehouse alimente le data warehouse en amont (ingestion, nettoyage) mais c’est le data warehouse qui certifie.
Cas 2
IA générative & ML industrialisé
Choix Lakehouse
Notre client dans le retail souhaitait entraîner des modèles de prévision de la demande, déployer un moteur de recommandation produit et expérimenter un assistant GenAI pour ses équipes merchandising. Il avait besoin d’accéder à des téraoctets de données historiques, d’un feature store partagé et d’un environnement d’expérimentation rapide. Le choix s’est porté sur le lakehouse natif de Databricks.
Cas 3
Modernisation d’un SI Data hérité
Architecture hybride médaillon
C’est le cas le plus fréquent que nous rencontrons. Notre client, une entreprise industrielle, exploitait un entrepôt Teradata depuis des années : flux batch nocturnes, datamarts métiers et dette technique accumulée. La migration full-replace vers un lakehouse était trop risquée. Nous avons migré progressivement vers une architecture médaillon (lakehouse en bronze et silver) tout en maintenant le data warehouse existant pour la zone gold et le reporting, afin de préserver la confiance métier. Moderniser le SI Data, oui … mais de manière incrémentale. Modernisation de la BI et du SI Data : réduire la dette de la plateforme décisionnelle pour alimenter l’IA

Comment Smartpoint accompagne la modernisation de votre plateforme Data

Chez Smartpoint, nous sommes agnostiques. Nos Architectes Data / IA vous aident à choisir la bonne solution architecturale en fonction de votre réalité opérationnelle : Stack existante, roadmap Data / IA, maturité équipe, contraintes de gouvernance, compliance, etc.

Nos prestations de service pour moderniser votre plateforme Data :

Consulting & Design

Nous commençons par un audit de la plateforme data existante : sources, volumétrie, usages BI, projets ML en cours ou planifiés, maturité DataOps. Puis, nous co-construisons la cible architecturale avec vos équipes et les sponsors métiers.

Build & Automate

Nous intégrons la plateforme data cible : ingestion (Kafka, Fivetran, custom), transformation (dbt, Spark, Azure Data Factory), stockage (Delta Lake, Iceberg, BigQuery), orchestration (Airflow, Dagster), observabilité (Great Expectations, Monte Carlo).

Nous appliquons les pratiques DataOps dès la conception : CI/CD, tests de qualité, lineage automatique.

Evolve & Scale

Nous accompagnons nos clients dans l’évolution de leur plateforme data avec l’intégration de nouvelles sources, de nouveaux cas d’usage ML, des montées en charge ou encore l’intégration des workloads GenAI (RAG, fine-tuning, LLMOps).

Run & Monitor

Pour les clients qui ne souhaitent externaliser le run, nous assurons la supervision opérationnelle de la plateforme data : SLA, alerting, gestion des incidents, optimisation des coûts cloud. Nous proposons d’ailleurs une offre experte à Tunis dans notre centre de services.

Notre différence tient dans notre positionnement : Nous sommes un pur player Data & IA, basé à Paris, avec vingt ans d’expérience sur des projets de modernisation complexes dans des secteurs régulés. Et c’est cette expertise pointue et spécialisée dont nos clients ont besoin quand ils sont confrontés à ces enjeux et veulent sécuriser leurs roadmap data & IA.

Alors, Lakehouse ou datawarehouse ?

Dans les faits, ce n’est pas une bonne question ! Celle que nous posons aux DSI ou CDO que nous rencontrons, est « Quelle est la nature de votre donnée, qui sont vos utilisateurs et quelle est votre ambition IA ? »

Si votre priorité est la confiance métier sur du reporting structuré alors le datawarehouse reste le bon choix. Si votre priorité est la vitesse d’ingestion et les workloads ML, le lakehouse est une bonne fondation. Si vous devez faire les deux, et c’est souvent le cas, l’architecture médaillon vous donnera le cadre pour y parvenir sans remettre en question votre plateforme à chaque projet.

L’architecture data n’est pas tant un chantier technologique qu’un levier d’industrialisation de l’IA au sein de l’organisation. Et comme tout levier, son efficacité tient entièrement à la qualité de son calibrage.

Smartpoint est une ESN pure player Data & IA basée à Paris, accompagnant DSI et CDO dans la conception et la mise en œuvre de plateformes data cloud-native depuis 2006. Agréée CIR.

IA à l’échelle : le vrai problème n’est pas le modèle, c’est la gouvernance des données

Paris, le 17 avril 2026 – Auteurs : Maxime Lamendin et Emmanuelle Parnois

Depuis deux ans, les entreprises investissent massivement dans l’intelligence artificielle. Et pourtant, le passage à l’échelle n’est pas au rendez-vous. De nombreux projets restent bloqués en phase pilote sans jamais réussir le crash test de la mise en production. Les modèles sont là. Les use cases sont identifiés. Alors où est le problème ?

Le coup de frein aux projets IA est globalement toujours le même chez nos clients : Ce n’est pas le modèle. C’est la donnée.

Ou plus précisément c’est la confiance, ou l’absence de confiance, dans les données qui alimentent ces modèles.

Selon le rapport CDO 2026 publié par Informatica, 57 % des leaders Data citent la fiabilité des données comme un obstacle majeur au passage de leurs pilotes GenAI vers la production. Et 76 % reconnaissent que la gouvernance de leur organisation n’a pas suivi le rythme d’adoption de l’IA. Ces chiffres reflètent la réalité opérationnelle de la grande majorité des CDO et DSI en 2026 que nous observons également sur le terrain.

L’illusion du problème « Modèle »

Lorsqu’un projet IA déçoit, le réflexe est de chercher la solution du côté du modèle : changer de LLM, affiner les prompts, augmenter la puissance de calcul, tester une autre architecture RAG. C’est beaucoup plus simple que de rouvrir le dossier complexe des données elle-mêmes !

Mais voilà, un modèle d’IA aussi performant soit-il, ne corrige pas les données sur lesquelles il s’appuie, il les exploite. Si les définitions métier ne sont pas claires, les sources pas fiables, la traçabilité incomplète, ou encore les données d’entraînement biaisées ou périmées ; le modèle va industrialiser ces défauts avec une vitesse et une portée inédites. L’IA générative et les projets agentiques ne font qu’amplifier le phénomène … et avec beaucoup de conviction.

« Avoir confiance en ses données, c’est la base. Sans cela, pas d’analytique, pas de prédictif, ni de data science et encore moins d’intelligence. »

Mehdi Gargouri, Directeur Général, Smartpoint

La dette de données gangrène vos projets IA

Le concept de « dette technique » est bien connu des équipes IT. La dette de données l’est beaucoup moins ; pourtant ses effets sont tout aussi néfastes.

Déjà en 2019, IBM révélait que jusqu’à 80 % du temps des équipes data peut être consacré à la préparation, la correction et la réconciliation des données avant d’en extraire la moindre valeur. Et selon Gartner, la mauvaise qualité des données coûte en moyenne 12,9 millions de dollars par an aux organisations. Concrètement, derrière ces chiffres, on parle d’heures heures passées à débattre de la source d’un indicateur plutôt que de prendre une décision. Ce sont les projets IA repoussés parce que personne ne fait confiance aux données d’entraînement. Ce sont les pipelines reconstruits à la main avant chaque mise en production…

Cette dette s’est constituée année après année, souvent invisible car les symptômes étaient globalement tolérés : des reportings contestés, des KPI qui divergent selon les outils, une donnée introuvable, etc. Individuellement, chaque problème semble gérable. Collectivement, ils constituent un frein structurel à toute ambition IA.

« La « dette de gouvernance » devient une véritable asphyxie opérationnelle. Alors que l’usage de l’IA se généralise, la grande majorité de nos clients pointent leurs dispositifs de gouvernance comme clairement insuffisants. »

Maxime Lamendin, Data Governance Practice Manager, Smartpoint

Pour aller plus loin sur les causes profondes de ce phénomène, notre article Pourquoi la gouvernance des données est devenue incontournable pour les DSI et CDO en dresse un panorama complet.

Données partout, confiance nulle part : le paradoxe de 2026

Le rapport CDO 2026 met en lumière un paradoxe frappant que nous appelons le paradoxe de la confiance et que nous rencontrons souvent chez nos clients : 65 % des leaders Data estiment que leurs équipes font confiance aux données utilisées pour l’IA. Mais cette confiance est souvent aveugle car elle est la plus élevée là où la maîtrise des données est la plus faible.

En clair, vos équipes font confiance à des données qu’elles ne maîtrisent pas. Elles ne savent pas justement ce que les données ne savent pas. Et elles utilisent ces données pour alimenter des modèles d’IA qui, à leur tour, prennent des décisions ou formulent des recommandations avec force de conviction. C’est un risque opérationnel réel et une responsabilité qui incombe directement au CDO.

La même étude révèle que 86 % des organisations prévoient d’augmenter leurs investissements en gestion des données en 2026, avec trois priorités en tête : sécurité et confidentialité des données (43 %), gouvernance des données et de l’IA (41 %), montée en compétences (39 %). Force est de constater qu’après deux ans d’euphorie autour des modèles de l’IA, les entreprises se recentrent sur … la base.

Ce que signifie vraiment gouverner ses données

La gouvernance des données est un terme souvent mal compris. On la réduit à la conformité RGPD, à un choix d’outillage ou à un programme qualité. Elle n’est ni l’un ni l’autre seul.

Gouverner ses données, c’est construire le cadre qui rend la donnée défendable, en réunion de direction quand un KPI est contesté, devant un auditeur quand une origine de donnée est demandée, dans un modèle d’IA quand la fiabilité du corpus conditionne la qualité des outputs.

Chez Smartpoint, nous structurons la gouvernance des données autour de six dimensions fondamentales qui constituent un socle data solide, fiable et prêt à supporter des usages avancée comme l’IA et l’automatisation avancée.

  1. La qualité des données : La capacité à disposer de données exactes, cohérentes, fraîches et exploitables au bon moment. Sans elle, la gouvernance reste déclarative. C’est le moment où les principes se confrontent au réel. Notre guide sur la politique de qualité des données détaille comment la construire opérationnellement.
  2. La responsabilité : Qui décide, qui s’engage, qui arbitre, qui corrige ? Une gouvernance sans Data Owner identifié et actif reste un principe sans effet. C’est l’un des sujets les plus sous-estimés et pourtant les plus structurants. Notre article sur l’organisation data et les modèles de gouvernance en explore les modèles concrets.
  3. La traçabilité : La capacité à retracer l’origine d’une donnée, ses transformations successives, ses usages. C’est désormais une exigence réglementaire (RGPD, AI Act, NIS 2) autant qu’un prérequis technique. Sans data lineage, vous ne pouvez pas répondre à la question la plus simple mais la plus redoutée : « D’où vient ce chiffre ? ».
  4. La conformité et la souveraineté : Dans un contexte où l’AI Act entre en application générale en août 2026 et où NIS 2 élargit les obligations aux entités importantes dans de nombreux secteurs, la gouvernance est devenue le bras armé de la conformité. Notre article Du RGPD à la souveraineté numérique dresse le panorama des obligations en vigueur.
  5. L’outillage : Data catalog, data lineage, MDM. Ces briques ne gouvernent pas à votre place mais elles rendent la gouvernance exécutable à l’échelle. Notre guide sur l’outillage de la gouvernance aide à choisir les bons composants selon votre maturité et votre architecture.
  6. Le pilotage : Des règles, des contrôles, des indicateurs, une logique d’amélioration continue. Une gouvernance qui ne se mesure pas reste une gouvernance de conviction.

« La gouvernance est devenue la condition à l’industrialisation de l’exploitation de la Data. »

Luc Doladille, Directeur Conseil, Smartpoint

L’IA agentique accélère (encore) l’urgence

Si le sujet de la gouvernance des données était déjà critique avec l’IA générative, il prend une autre dimension avec l’essor de l’IA agentique. Selon le rapport CDO 2026, 47 % des organisations ont déjà adopté des agents IA capables d’agir de manière autonome, c’est à dire interroger des sources de données, déclencher des actions, enchaîner des décisions sans validation humaine à chaque étape.

Dans ce contexte, la tolérance à l’ambiguïté dans les données n’est absolument plus tolérable. Un agent mal informé ou alimenté par des données non gouvernées ne fait pas quelques erreurs ponctuelles … Il les automatise, les répète et les amplifie à l’échelle de l’organisation.

50 % des leaders Data travaillant sur des agents IA citent d’ailleurs les problèmes de qualité et de récupération des données comme le défi principal pour passer en production. Ce chiffre ne va absolument pas diminuer avec un meilleur modèle … mais avec une meilleure gouvernance des données, si.

Par où commencer « le chantier » de la gouvernance ?

La gouvernance des données n’est pas un projet avec une date de fin, c’est un programme progressif. Et la bonne nouvelle, c’est qu’il n’est pas nécessaire de tout traiter en même temps.

Chez Smartpoint, nous recommandons de démarrer sur trois axes principaux applicables en moins de 90 jours :

  1. Identifier les données critiques. Pas toutes les données ! Qelles dont la qualité conditionne les décisions les plus importantes, les obligations réglementaires les plus contraignantes ou les cas d’usage IA les plus prioritaires. Un périmètre de 30 à 50 datasets critiques est un terrain de gouvernance opérable.
  2. Clarifier les rôles avant de choisir les outils. Un data catalog déployé dans une organisation où les Data Owners ne sont pas identifiés sera vide dans six mois. L’outillage rend la gouvernance exécutable mais il ne la remplace pas.
  3. Partir des irritants réels. Les KPI qui divergent en comité de direction, les projets IA bloqués faute de confiance dans les données, les équipes qui passent plus de temps à qualifier les données qu’à les exploiter, (…). Chacun de ces irritants a une réponse de gouvernance précise. C’est par là qu’il faut commencer.

Notre article Par où commencer et quelle roadmap adopter détaille une trajectoire sur 18 à 36 mois, de la stabilisation des fondations jusqu’à la gouvernance fédérée dans des architectures distribuées.

La gouvernance des données n’est plus un sujet de fond ou traité à postériori

Pendant longtemps, la gouvernance des données a été le sujet toujours prévu dans les schémas directeurs mais jamais réellement lancé. La pression opérationnelle, les projets jugés plus urgents, la complexité perçue du chantier ont toujours été autant de raisons de le repousser.

Mais ce temps est derrière nous.

L’IA générative n’a pas créé le problème de gouvernance des données. Elle l’a rendu impossible à ignorer. Un modèle IA bien entraîné sur un corpus mal gouverné ne corrige pas les problèmes, il les accentue avec une vitesse et une portée inégalées jusqu’alors.

La gouvernance des données n’est plus un prérequis BI. C’est le socle de toute industrialisation IA responsable.

Les organisations qui investissent aujourd’hui dans la fiabilité, la traçabilité et la qualité de leurs données ne font pas de la conformité. Elles s’assurent, contrairement à leurs concurrents, de pourvoir faire confiance à leurs modèles, de mettre en production sans hésiter et de prendre leurs décisions sur des données défendables.

Pour aller plus loin

Smartpoint est une ESN parisienne indépendante, spécialisée Data & IA depuis 2006. Nos consultants certifiés DAMA accompagnent les DSI et CDO sur la gouvernance des données, l’architecture data, l’IA générative et la conformité réglementaire.

Comment choisir son ESN Data & IA pour moderniser sa plateforme data et déployer du RAG souverain ?

En 2026, moderniser la plateforme data est devenu un chantier qu’on ne peut pas repousser, c’est même le prérequis à tout projet d’IA industrialisé. Mais face à la multiplication des ESN qui affichent une expertise Data & IA, comment un DSI ou un CDO fait-il le bon choix ? Voici les critères qui comptent vraiment.

En résumé
  • Un ESN généraliste traite la data comme une activité parmi d’autres, un pure player Data & IA y consacre 100 % de ses ressources. Ce n’est pas le même niveau d’expertise en production.
  • Moderniser sa plateforme data et déployer du RAG sont deux projets indissociables car un RAG fiable en production exige des données propres, gouvernées et tracées à la source.
  • L’IA souveraine, c’est-à-dire déployer des LLMs sans exposer vos données à des clouds étrangers, est devenue un critère de sélection décisif avec l’AI Act pour les DSI français.
  • L’agrément CIR de votre ESN peut réduire le coût net de votre projet Data & IA de 30 %, peu d’ESN en disposent dans ce domaine.
  • 6 critères permettent de sélectionner et départager les ESN Data IA : spécialisation, delivery en production, DataOps/LLMOps, souveraineté, CIR et couverture nationale.

Pourquoi la modernisation de la plateforme data est devenue urgente

Pendant des années, les DSI ont pu différer la refonte de leur patrimoine data. Les entrepôts legacy fonctionnaient, certes pas parfaitement et de manière coûteuse, mais ils fonctionnaient. Mais ce temps est révolu.

À lire sur ce sujet : Modernisation de la BI et du SI Data : réduire la dette de la plateforme décisionnelle pour alimenter l’IA

Trois forces convergentes ont rendu la modernisation non-négociable en 2026. D’abord, l’IA générative exige des données propres : déployer un RAG ou des agents IA sur une plateforme mal gouvernée produit des hallucinations, des fuites de données et des résultats ingouvernables en production. Ensuite, l’AI Act impose une traçabilité complète des données utilisées pour alimenter les modèles IA, ce que les architectures legacy ne savent pas faire nativement. Enfin, les coûts de la dette technique data sont de plus en plus lourds, en termes de maintenance et d’évolutions mais aussi en termes de retards accumulés face à vos concurrents. Reste à trouver le bon partenaire.

Le constat terrain de Smartpoint

Les entreprises qui réussissent à industrialiser leurs usages IA ne sont pas celles qui ont les meilleurs modèles. Ce sont celles dont la DSI a structuré, certifié et piloté leurs données comme des actifs critiques du SI, avant même de commencer à parler de LLM.

Estimated reading time: 0 minute

ESN généraliste ou pure player Data & IA ?

La première différence est structurelle. Une ESN généraliste couvre une dizaine de domaines de compétences entre développement applicatif, infrastructure et production, ERP, cybersécurité et quelque part dans l’offre « Data & IA ». En réalité, les profils Data y sont souvent moins seniors, la veille technologique est moins systématique et les retours d’expérience en production IA moins capitalisés.

Un pure player Data & IA consacre 100 % de ses ressources, de sa R&D et de ses recrutements à ce seul domaine. Ses architectes ont travaillé sur des dizaines de projets de modernisation data. Ses ingénieurs LLMOps ont opéré des RAG en production. Sa veille technologique porte sur les plateformes, frameworks et standards qui structurent les stacks data & IA : Databricks, dbt, Iceberg, Mistral, LangChain… pas sur des sujets généraux.

Signal d’alarme

Si l’ESN que vous évaluez ne peut pas nommer précisément sa stack DataOps (orchestrateur, framework de tests, outil d’observabilité data), ni expliquer la différence opérationnelle entre MLOps et LLMOps, c’est que la pratique data n’est pas son cœur de métier, quelle que soit sa taille.

Les 6 critères pour choisir son ESN Data & IA à Paris et en France

01. Spécialisation réelle, pas un label marketing

Demandez le ratio de consultants data sur l’effectif total, les certifications techniques récurrentes, le nombre de projets data en production livrés ces 24 derniers mois ainsi que des références clients avec les coordonnées pour vérifier. Une spécialisation sérieuse se mesure, elle ne se déclare pas.

02. Capacité à livrer en production, pas juste des POC

La majorité des projets IA échouent entre le POC et la mise en production. Demandez des références spécifiques de projets industrialisés : pipeline data en CI/CD, RAG opéré avec monitoring, modèle ML supervisé sur plusieurs mois. Si l’ESN ne peut citer que des démonstrateurs, passez votre chemin.

03. Maîtrise du DataOps, MLOps et LLMOps

Ces trois pratiques sont essentielles pour concevoir et opérer un SI data industrialisé. DataOps pour des pipelines fiables et observables, MLOps pour les modèles classiques, LLMOps pour les LLMs et les systèmes RAG. Une ESN qui ne maîtrise que l’un des trois ne peut pas vous garantir une plateforme Data performante, ni une IA stable en production.

04. Approche souveraineté & conformité AI Act

Est-elle en capacités de déployer vos LLMs on-premise ou dans votre cloud privé ? Intègre-t-elle la conformité RGPD et AI Act dès la conception des architectures ? La souveraineté des données est un prérequis pour les DSI de grands comptes et les entreprises réglementées.

05. Agrément Crédit Impôt Recherche (CIR)

Rares sont les ESN françaises à détenir l’agrément CIR dans le domaine Data & IA. Cet agrément peut vous faire bénéficier d’un crédit d’impôt de 30 % sur les dépenses R&D éligibles comme les architectures innovantes, LLMs, RAG, agents IA. Un levier financier trop souvent ignoré.

06. Couverture nationale et modes d’intervention flexibles

Basée à Paris ou non, l’ESN doit pouvoir intervenir sur l’ensemble du territoire français sans compromis sur la qualité des livrables. Vérifiez les modèles d’engagement disponibles : régie, centre de services, engagement capacitaire, nearshore mais aussi les certifications comme ISO 27001 et 27701.

Modernisation de la plateforme data et RAG, pourquoi est-ce indissociable ?

L’une des erreurs les plus fréquentes est de vouloir déployer du RAG sans avoir préalablement modernisé les fondations data. Le résultat est inexorablement le même avec des hallucinations non détectables, des réponses non traçables et l’impossibilité de contrôler la qualité des sources.

Le RAG fonctionne en allant chercher des documents pertinents dans une base de connaissances pour les injecter dans le contexte d’un LLM. La qualité de ses réponses dépend donc directement de la qualité, de la fraîcheur et de la structuration des données sources. Si vos données sont mal gouvernées, non versionnées, sans lignage et sans contrats de données, votre RAG sera donc aussi fiable que vos données, c’est-à-dire peu.

Les étapes vers un RAG en production
Modernisation
de la plateforme data
Automatisation
des pipelines & DataOps
Gouvernance &
qualité des données
Vectorisation
& indexation
RAG supervisé
avec LLMOps
Agents IA
métier

C’est pourquoi choisir une ESN capable de couvrir l’ensemble de cette trajectoire, de l’architecture de la plateforme jusqu’à l’opération du RAG en production, vous permet de sécuriser votre SI Data dans la durée ; alors que de prendre des prestataires spécialisés sur chaque brique ou une ESN généraliste rend votre projet bien plus risqué.

IA souveraine ? Le critère que les DSI ne peuvent plus ignorer

L’IA souveraine désigne la capacité à déployer et opérer des modèles d’IA (LLMs, RAG, agents) dans un environnement entièrement maîtrisé, c’est à dire votre cloud privé, votre datacenter ou un cloud européen certifié, sans transfert de données vers des infrastructures étrangères.

À lire sur le sujet : Plateforme IA souveraine, opérer un RAG en production en toute confiance

Pourquoi c’est devenu urgent

Deux facteurs convergents ont mis l’IA Souveraine dans les priorités des DSI. Le premier est réglementaire avec l’AI Act, le RGPD et les exigences sectorielles (santé, finance, défense) qui imposent une traçabilité et une localisation des données incompatibles avec un envoi systématique vers des API cloud américaines. Le second est plus stratégique voir géopolitique, alimenter vos LLMs avec des données propriétaires sensibles via une API publique expose potentiellement ces données à des usages que vous ne contrôlez pas.

Ce que cela implique concrètement pour votre choix d’ESN

Votre ESN doit être capable de :

  • Déployer des modèles open-source (Mistral, LLaMA, Gemma) sur votre infrastructure sans dépendance à une API externe
  • Construire des architectures RAG avec un vector store auto-hébergé (Qdrant, Weaviate, pgvector) et des embeddings locaux
  • industrialiser la chaîne LLMOps avec observabilité, sécurité et traçabilité
  • Concevoir une architecture réversible, capable de changer de modèle, de fournisseur d’infrastructure ou de composant technique sans remettre à plat tout le dispositif.
  • Documenter l’architecture conformément aux exigences AI Act : registre des systèmes IA, classification par niveau de risque, garde-fous
Point de vigilance

Certaines ESN « souveraines » déploient simplement des API d’éditeurs américains dans votre VPC cloud. Ce n’est pas de la souveraineté car les données transitent toujours par les serveurs de l’éditeur. La vraie souveraineté commence au niveau du modèle.

Automatisation des pipelines data, quels attendus vis à vis de l’ESN ?

L’automatisation des pipelines data est souvent perçu comme un sujet purement technique. C’est surtout une capacité organisationnelle qui détermine la vélocité de votre SI data et la fiabilité de tout ce qui en dépend : BI, ML, IA générative.

Un pipeline data industrialisé selon les pratiques DataOps repose sur les quatre piliers que sont l’automatisation CI/CD (chaque modification de pipeline est testée et déployée automatiquement), les tests de qualité données (règles de validation, contrats de données), l’observabilité end-to-end (monitoring des latences, volumes, fraîcheur, qualité) et la gestion des environnements (developpement, staging, production clairement séparés avec rollback possible).

Nous vous invitons à poser ces questions à votre sélection d’ESN Data IA. Si la réponse est vague, il est fort probable que l’expertise le soit aussi.

ESN Data & IA à Paris mais aussi sur tout le territoire, ce que propose Smartpoint

Smartpoint est l’une des rares ESN françaises entièrement dédiées à la Data et à l’Intelligence Artificielle depuis sa création en 2006, ce qui en fait une des plus large concentration de consultants et d’experts Data et IA en France. Cette spécialisation se traduit par une profondeur d’expertise que les ESN généralistes ne peuvent pas égaler.

Nos équipes interviennent sur l’ensemble de la chaîne de valeur : architecture data cloud et modernisation des plateformes, automatisation des pipelines avec DataOps/LLMOps, IA générative industrialisée et RAG souverain, gouvernance des données conforme RGPD & AI Act.

Basés à Paris, nous intervenons sur l’ensemble du territoire français, en mode on-site, hybride ou via nos centres de compétences nearshore certifiés ISO 27001 et 27701 selon vos contraintes.

Notre agrément CIR, obtenu en décembre 2025, nous place parmi les rares ESN françaises habilitées à mener des projets Data & IA éligibles à ce dispositif fiscal, ce qui peut réduire le coût net de vos projets R&D de 30 %.

FAQ

Questions fréquentes sur les critères de choix d’une ESN Data IA

Une ESN généraliste propose la Data & IA parmi une dizaine d’autres activités. Les profils data y sont moins spécialisés, la capitalisation sur les projets data moins importante. Un pure player concentre 100 % de ses recrutements, de sa R&D et de son expérience terrain sur ce seul domaine, ce qui se traduit par des consultants plus seniors et une meilleure capacité à industrialiser.
Techniquement oui, mais le résultat sera peu fiable. Un RAG est aussi bon que les données qu’il indexe. Sur une plateforme mal gouvernée, sans qualité certifiée, sans lignage, le RAG produira des réponses hallucinées ou non traçables, impossibles à superviser en production.
L’IA souveraine désigne la capacité à opérer des modèles d’IA sur une infrastructure entièrement maîtrisée, sans dépendance à des API ou des clouds étrangers. Pour un DSI, c’est devenu stratégique pour la conformité RGPD et AI Act, pour éviter les risques de fuite de données propriétaires et pour réduire la dépendance à un fournisseur unique.
Posez trois questions précises : quel est votre framework de tests de qualité données en CI/CD ? Comment gérez-vous le versioning des pipelines et les rollbacks en production ? Quels outils utilisez-vous pour l’observabilité des flux data ? Une ESN sérieuse répondra avec des outils précis (Great Expectations, dbt tests, Monte Carlo, OpenLineage…). Une réponse vague est un signal d’alarme.
Non, il s’applique aux travaux qui visent à dépasser l’état de l’art avec une démarche expérimentale structurée. Sont typiquement éligibles : architectures data innovantes, pipelines LLMOps sur mesure, RAG avec techniques d’indexation non standardisées, agents IA autonomes. L’ESN agréée vous accompagne pour qualifier l’éligibilité de votre projet.

Metrics Layer et Semantic Layer : le socle de la BI

Les entreprises se sont presque habituées à fonctionner avec des KPI incohérents d’un tableau de bord à l’autre et les équipes s’en accommodaient. Certes c’était un irritant, parfois couteux, mais tolérable tant que la BI restait principalement consommée dans des dashboards.

Ce temps est derrière nous. La modernisation de la BI ne consiste pas à seulement remplacer un outil décisionnel par un autre, ni à migrer Cognos ou Business Objects vers une plateforme Data cloud-native. La BI moderne, ce n’est plus que de la restitution, elle alimente désormais des insights automatisés, des alertes en temps réel, des interfaces en langage naturel, des APIs analytiques, des copilotes et de plus en plus des agents IA de déclencher des actions.

Une divergence de définition n’a plus la même résonnance, elle se diffuse et pollue l’ensemble. C’est tout le sens métier qui est compromis.

C’est pour ces raisons que la Metrics Layer et la Semantic Layer sont devenus indispensables à la BI moderne. Elles sont la condition sine qua non pour qu’un indicateur conserve la même signification, quel que soit le canal sur lequel il est exposé, consommé, interrogé ou réutilisé. La vraie modernisation de la BI dépasse les considérations d’ergonomie, de vitesse, de performance ou de cloud ou pas cloud ou encore d’ergonomie ; elle passe par la construction d’un commun de sens partagé.

La BI moderne n’est plus dans le dashboard mais dans toutes les interfaces où circule le sens métier

Le principal changement est que les KPIs ne sont plus que des dans des rapports, ils circulent dans les outils métiers, les applications embarquées, les copilotes analytiques, les requêtes en langage naturel … et bientôt dans des workflows décisionnels toujours plus autonomes.

La BI est plus diffuse, conversationnelle, embarquée et agentique.

Et cela change tout en termes d’architecture Data BI. Tant que l’analyste officiait comme intermédiaire quasi incontournable entre les données et les décisions, la correction humaine était implicite. Les erreurs et autres incohérences étaient identifiées et redressées.

Mais lorsqu’un assistant IA répond directement à une question du type « quel était notre taux de churn sur le trimestre dernier ? », il ne sait pas improviser le sens métier. Il a besoin d’un cadre avec un langage métier cohérent, des définitions immuables, des relations explicites, des règles d’agrégation, des exclusions documentées et des hiérarchies compréhensibles.

Historiquement, nous avions une BI centrée sur data visualisation ; elle se déporte sur la sémantique gouvernée. Une « bonne » plateforme décisionnelle doit être aujourd’hui en capacités de garantir que le chiffre est bon, compris par tous ceux qui le consomme de la même manière quel que soit le canal utilisé. Plus la BI est augmentée, plus la gouvernance des métriques est un sujet d’architecture Data.

La Metrics Layer et la Semantic Layer ne répondent pas au même besoin mais sont indissociables

Déjà, revenons sur leurs définitions.

  • La Metrics Layer centralise la définition des indicateurs métier. Elle formalise les calculs, les agrégations, les dimensions autorisées, les filtres applicables, les exceptions, les variantes de calcul et si nécessaire, les fenêtres temporelles. Elle précise donc ce qui définit réellement le chiffre d’affaires, la marge, le stock disponible, le revenu net, le churn, le coût d’acquisition, le délai moyen de traitement ou encore le turnover. Son rôle est de remplacer les définitions éparsespar un référentiel de métriques commun, versionné, gouverné et réutilisable dans les tableaux de bord, les APIs, les requêtes en langage naturel, les copilotes et les agents.
  • La Semantic Layer organise le sens métier autour de ces indicateurs. Elle relie les métriques à des objets, à un vocabulaire partagé, à des synonymes, à des hiérarchies, à des dimensions, à des relations entre entités et à des descriptions compréhensibles par les utilisateurs métier. Elle précise donc ce que recouvrent réellement des notions comme par exemple un client actif, une commande livrée, un revenu récurrent, une marge commerciale, un stock exploitable ou un canal de vente en les replaçant dans leur contexte d’usage. Son rôle est de remplacer les interprétations par un référentiel sémantique commun, documenté, gouverné et réutilisable.

En clair, la Metrics Layer stabilise le calcul, la Semantic Layer stabilise l’interprétation. La première garantit que le chiffre est produit de façon cohérente et la seconde qu’il est compris de manière cohérente.

semantic layer

Source : Alwyn DSouza : https://medium.com/towards-data-engineering/why-data-teams-need-a-semantic-layer-83947a5a0057

Le vrai problème de l’IA n’est pas le modèle mais l’absence de sens métier exécutable

Lorsque les réponses générées par un copilote analytique ne sont pas aux attendus, la tentation est grande de condamner le modèle ou la qualité des données. Alors que dans les faits, c’est souvent lié à l’absence de contexte métier exécutable.

Une donnée structurée ne parle pas d’elle-même. Un nom de colonne, une table ou une relation physique ne suffisent pas à dire ce que signifie réellement un KPI dans l’organisation. Une IA peut repérer des schémas, émettre des hypothèses, rapprocher des concepts. Elle ne peut pas deviner par elle-même ce que votre entreprise entend exactement par revenu récurrent net, client actif, commande livrée, stock exploitable ou marge commerciale. Tant que ce sens n’est pas explicitement gouverné, versionné et exposé dans une couche réutilisable, cela ne peut pas fonctionner.

La Semantic Layer ne doit pas être vue comme une simple couche de documentation. Elle a pour rôle de rendre le sens métier directement exploitable par les systèmes. Elle formalise les définitions, les relations, les hiérarchies et les contextes nécessaires pour qu’une plateforme BI, une API analytique, une interface en langage naturel, un copilote ou un agent IA interprète les données de façon cohérente. La semantic Layer est une brique d’architecture à part entière, au croisement de l’analytics, de la gouvernance et de l’AI readiness.

Attention à la dérive sémantique !

Il ne suffit pas d’ajouter une couche sémantique. Encore faut-il qu’elle reste alignée dans la durée sur le modèle physique, sur les transformations opérées et sur les règles métier en production. Sans cela, la plateforme donne une impression de cohérence alors qu’elle diffuse en réalité un sens devenu obsolète.

Une métrique peut rester exposée alors que son calcul a changé. Une relation logique peut rester documentée alors qu’elle ne reflète plus la chaîne de traitement réelle. Une colonne renommée peut ne pas être répercutée correctement. Un libellé métier peut perdurer alors que son périmètre a évolué. La couche sémantique cesse alors d’être ce facteur de stabilité pour devenir une source invisible d’écart.

Dans le cas des dashboards traditionnels, cette dérive produisait des analyses non pertinentes. Dans un univers de BI conversationnelle, de copilotes et d’agents, c’est particulièrement critique. Une réponse fausse mais fluide dégrade la confiance plus vite qu’une absence de réponse.

La dette BI n’est donc plus seulement une dette de pipelines, d’outils ou de restitution. C’est aussi une dette de sémantique. Moderniser la BI, c’est réduire cet écart entre calcul réel, définition métier et interprétation exposée.

Le RAG, les copilotes et les agents ne remplacent pas une couche sémantique gouvernée

Le RAG ne remplace pas la sémantique. Un copilote connecté à de la documentation interne peut très bien retrouver une définition ou expliquer une règle métier. C’est utile mais cela ne suffit pas à garantir la cohérence d’un KPI dans un environnement décisionnel moderne.

Si la logique de calcul est disséminée (requêtes SQL, tableaux de bord, exports Excel..), l’IA ne va rien arranger du tout, elle va au contraire fluidifier l’accès à des bases instables.

Pour que la BI augmentée soit fiable, elle doit s’appuyer sur plusieurs briques : données fiables, chaîne de transformation maîtrisée, métriques versionnées, couche sémantique documentée, data lineage, contrôle d’accès, observabilité, puis seulement des interfaces de restitution ou de conversation.

La bonne architecture, ce n’est pas trancher entre dashboard ou copilote, ni entre RAG et semantic layer. C’est une architecture Data dans laquelle la couche sémantique a un rôle de pivot entre la plateforme data, la BI moderne et les usages IA. Sans cela, la requête en langage naturel, le digest automatisé ou l’agent analytique diffusera des informations possiblement erronées, et ce à grande vitesse. (À lire sur ce sujet « Your Data Architecture Is Ready. Your Semantic Layer Isn’t. Here’s Why That’s the Real AI Problem.« 

Les symptômes d’une plateforme BI sans Metrics Layer

On se rend vite compte au quotidien si votre plateforme BI repose bien sur une Metrics Layer ! Les équipes finance, commerce et opérations utilisent des chiffres différents pour décrire une même réalité. Le self-service BI est resté largement théorique, dès qu’une question est sensible, tout le monde se tourne vers les deux ou trois experts historiques. Les projets de migration de legacy BI sont laborieux non pas à cause du volume de rapports mais par ce que les règles métier sont implicites et disséminées dans les dashboards, les requêtes SQL, les exports Excel ou les habitudes des équipes. Elles n’ont jamais été formalisées dans un référentiel commun, au mieux partiellement.

Et c’est précisément là que la dette analytique fait son nid. Le patrimoine décisionnel d’une entreprise n’est pas que dans les outils, les rapports ou les pipelines, il est aussi dans la logique métier accumulée au fil des années. Ainsi, remplacer tel outil BI par un autre ne suffit pas. On modernise l’interface, parfois le run, mais sans repenser le socle de sens qui va soutenir tous les usages.

C’est aussi l’un des constats que nous faisons chez Smartpoint, ESN spécialisée en Data et IA.

la dette de la plateforme décisionnelle ne vient pas seulement d’outils vieillissants, d’ETL historiques ou de l’architecture data. Elle vient tout autant de la dispersion du sens métier, sans point de gravité clair, sans gouvernance unifiée des métriques et sans couche commune pour stabiliser les définitions. Tant que cette dette n’est pas traitée, la modernisation n’aura pas lieu. Il est important de palier à l’absence d’un référentiel de métriques partagé, gouverné et exploitable dans toute la chaîne BI et IA.

Partir des KPI critiques et reconnecter la sémantique à l’architecture

Chez Smartpoint, ESN spécialisée en Data et IA, nous vous conseillons de ne pas vous lancer tout de suite dans un vaste programme de glossaire métier !

Mieux vaut vous concentrer sur les KPI critiques, c’est-à-dire sur ceux qui sont les plus exposés dans l’entreprise : comités, tableaux de bord, exports, alertes, requêtes en langage naturel, APIs, outils métiers, copilotes, agents et applications embarquées. Ce sont eux qui portent le plus de valeur, mais aussi le plus fort risque de divergence.

La bonne démarche consiste d’abord à identifier ces métriques, à versionner leur définition, à documenter les hypothèses, les filtres, les règles d’exclusion et les exceptions, à désigner des owners, puis à relier ces objets à la qualité des données, au data lineage, aux droits d’accès et au change management de la plateforme. La couche sémantique ne doit plus rester à côté de l’architecture data, elle doit devenir une brique du modèle opérable.

C’est aussi ce qui distingue une approche purement aval d’une approche plus proche du design-time. Plus la sémantique est éloignée de la modélisation physique, des transformations et des workflows de changement, plus le risque de dérive augmente. À l’inverse, plus la gouvernance des métriques, le lineage, la qualité et la sémantique sont rapprochés, plus la plateforme décisionnelle gagne en stabilité. L’enjeu n’est donc pas seulement de mieux documenter mais d’intégrer la sémantique au cœur même du cycle de changement.

`

Définir le sens une fois, le réutiliser partout

Au niveau des éditeurs, tous convergent vers une même direction : définir les métriques et le contexte métier une fois, puis les réutiliser dans les tableaux de bord, les usages conversationnels, les APIs et les cas d’usage IA.

  • Chez Microsoft, lorsqu’une question porte sur les données, Copilot s’appuie sur le modèle sémantique Power BI pour répondre.
  • Chez dbt, la Semantic Layer centralise les définitions de métriques dans la couche de modélisation et les rend cohérentes dans les outils et les applications.
  • Google Cloud présente quant-à-lui Looker comme une plateforme orientée API, dotée d’une couche sémantique et d’une interface en langage naturel, tandis que sa documentation indique que Conversational Analytics s’appuie sur la couche sémantique LookML comme source de vérité.
  • Snowflake explique que ses Semantic Views rapprochent les données brutes de la compréhension métier et fournissent une couche cohérente pour Cortex Analyst, les outils BI et même SQL.
  • Databricks, de son côté, positionne ses Metric Views comme un moyen centralisé, gouverné et réutilisable de définir les KPI, puis d’y ajouter des métadonnées sémantiques utiles aux tableaux de bord AI/BI et aux interfaces en langage naturel.
  • Chez Tableau, on “traduit les données dans le langage de l’entreprise”, tandis que Tableau Pulse pousse les métriques directement dans Slack, Teams et les e-mail.
  • Qlik parle moins semantic layer mais la logique est proche : Qlik Answers mixe analytics et contenu non structuré pour produire des réponses contextualisées et explicables, avec citations des sources, tandis que Qlik Cloud Analytics distribue analytics, IA, data products, embedded analytics et orchestration.

A lire sur ce sujet pour aller plus loin :

Et bientôt l’interopérabilité sémantique ?

Si la couche sémantique devient le pivot des produits analytics, dashboards, copilotes, agents et interfaces en langage naturel, un nouveau risque émerge : recréer un vendor lock-in au niveau même du sens métier.

C’est pourquoi l’interopérabilité sémantique devient un enjeu majeur. Sa portabilité comptera bientôt autant que celle des données elles-mêmes. Le sujet dépasse la technique : il touche à la gouvernance, la réversibilité, l’architecture cible et la capacité à faire évoluer la plateforme sans enfermer l’entreprise dans une nouvelle dépendance.

Moderniser la BI, c’est fiabiliser l’architecture décisionnelle

Aujourd’hui, moderniser la BI ne consiste pas à ajouter un énième outil de restitution, mais à bâtir une plateforme décisionnelle garantissant un sens métier unifié. Et cela demande de concevoir un socle solide : données fiables, chaîne de transformations maîtrisée, métriques versionnées, couche sémantique, data lineage, observabilité et contrôle d’accès.

Metrics Layer pour réduire la dette analytique.
Semantic Layer pour relier définitions métier et architecture data.
Cette articulation ouvre le chemin d’une BI statique à une BI exploitable à l’échelle, y compris en conversationnel et IA.

Chez Smartpoint, spécialiste Data & IA, nous sommes convaincus qu’on ne modernise pas durablement la BI en changeant l’outil. On la reconstruit avec un socle de sens gouverné, réutilisable et opérable dans toute la chaîne décisionnelle.

Quelle différence entre Metrics Layer et Semantic Layer ?

La Metrics Layer stabilise le calcul des KPI. la Semantic Layer stabilise leur interprétation métier.

Pourquoi la couche sémantique est critique pour l’IA ?

Parce qu’un copilote ou un agent IA ne peut pas deviner seul ce que signifie un indicateur dans votre entreprise.

Le RAG remplace-t-il la couche sémantique ?

Non. Le RAG aide à retrouver du contexte documentaire, mais il ne remplace pas une définition gouvernée des métriques.

BI augmentée, RAG, copilotes : la nouvelle stack décisionnelle

Auteurs : Luc Doladille et Emmanuelle Parnois

Quand on parle de BI, on pense rapports, dashboard, KPI et requêtes plus ou moins complexes. Le self-service BI a permis un accès plus simple aux données et a ouvert la porte à plus d’autonomie des métiers. Mais ce qui change profondément la BI, c’est l’IA.

On peut maintenant interroger les données en langage naturel, générer des analyses à la demande, produire automatiquement des narratifs, détecter des anomalies, simuler des scénarios et, de plus en plus, déclencher des actions.
La BI a aussi adopté l’IA générative. Tous les éditeurs vont dans le même sens : requêtes en NLQ, copilotes analytics, recommandations contextuelles, résumés automatiques, interfaces conversationnelles, assistants de Data Viz et orchestration de certaines étapes d’analyse.

Fini la BI descriptive qui se résumait à de la restitution. Désormais, elle explique, compare, alerte et propose des actions.

En revanche, si l’interface devient conversationnelle, le socle lui doit être renforcé pour ne pas générer des erreurs et autres hallucinations avec une portée inégalée. Une mauvaise réponse formulée avec beaucoup d’assurance par un copilote conversationnel est particulièrement inacceptable sur des KPI métiers, des données financières, des niveaux de stocks par exemple ou encore des prévisions.


Plus l’IA facilite l’accès à l’analyse, plus la gouvernance, la couche sémantique, le data lineage, le RAG et la maîtrise de la plateforme BI sont critiques.

Luc Doladille, Directeur Conseil Data IA, Smartpoint

De la BI self-service à la BI augmentée par l’IA

La BI en libre service est devenu un standard ces dernières années avec Power BI, Qlik Sense ou encore Tableau ; même si les vrais usages en volume côté métiers sont encore à la marge dans les organisations que nous accompagnons. L’IA vient de faire basculer d’un coup la Data Viz dans une autre dimension. On n’en est plus à consulter ni à créer des dashboards, on dialogue désormais avec les données.

Copilot est maintenant intégré à Power BI et permet de retrouver des rapports, d’interroger des modèles sémantiques et des agents de données Fabric, et d’assister l’utilisateur dans son analyse (Lire Copilot dans l’intégration de Power BI). De son côté, Tableau Agent (anciennement Tableau Pulse et Einstein Copilot) promet l’autonomie analytique des métiers via l’exploration en langage naturel, l’instanciation automatique de visualisations, la capacité de mener des calculs complexes et la recommandation contextuelle de pistes d’analyse. Qlik Answers va encore plus loin dans l’analytique conversationnel en permettant l’exploitation des données structurées et des bases documentaires métiers non structurées avec un système de citation des sources.

La BI sort de son périmètre historique et passe à l’Analytics Agentique, proactive et prescriptive. Elle ne se contente plus de livrer des chiffres, elle commence à expliquer les écarts, à formuler des hypothèses prédictives, à signaler des anomalies en temps réel et, dans les architectures Data les plus modernes à orchestrer les actions métier.

Chez Smartpoint, ESN spécialisée en Data et IA, nos experts BI observent d’ailleurs une convergence technologique chez les acteurs historiques :

  • Qlik et l’IA gouvernée : Qlik met en avant des réponses gouvernées et explicables comme socle indispensable de l’analytics agentique. Pour une DSI, c’est un garde-fou car cela suppose que l’action suggérée par l’IA repose bien sur un Data Lineage vérifiable.
  • Microsoft et les Translytical task flows : Microsoft met en avant des flux de tâches dits « translytiques » dans Power BI dont la finalité est de casser le silo entre analyse et opérationnel en permettant, directement depuis un rapport, de mettre à jour des enregistrements dans le CRM ou de déclencher des automatisations via Power Automate
  • Tableau et l’Agentic Analytics Platform : La solution de Salesforce se positionne désormais comme une plateforme analytique agentique où l’IA ne répond pas seulement à une question, elle est un agent capable de naviguer dans les données pour identifier des causes racines et suggérer des remédiations immédiates.

Qu’est ce que l’IA générative apporte à la BI ?

C’est le développement du NLQ (Natural Language Query) qui a vraiment changé la nature des usages BI. Plus besoin de requêtes SQL, on peut parler en langage métier, cela démocratise enfin les usages et surtout cela permet à une plus large population de l’entreprise d’exploiter les données. Copilot peut répondre sur des rapports, des modèles sémantiques ou des agents de données Fabric. Tableau Agent peut transformer des prompts en visualisations et en calculs. La BI est plus accessible au plus grand nombre … mais encore plus dépendante de la qualité des données qui alimentent l’interface.

Ensuite, la narration automatisée permet à la BI augmentée de raconter ce qu’elle voit. Tableau déploie des résumés de dashboards et des améliorations de Q&A. Qlik Answers produit des réponses explicables basés sur des bases documentaires. Microsoft positionne Copilot comme un assistant capable de résumer et de guider l’analyse. Ce passage du visuel au récit change la perception même de la BI.

Le troisième changement est plus fondamental. On est en train de glisser d’une BI essentiellement descriptive vers une BI plus prédictive, prescriptive et opérationnelle : Détection d’anomalies, scénarios « what-if », prévisions, exploration contextuelle, alerting plus intelligent, recommandations. Tableau promet des capacités de prévision toujours plus fines et une analyse temps réel plus granulaire. Power BI rapproche de plus en plus analyse et action via les task flows. Qlik pousse une logique où la conversation ne s’arrête pas à la réponse, mais peut aboutir à la prochaine étape. Clairement, c’est toute la boucle OODA du pilotage qui s’accélère : observer, s’orienter, décider, agir.

La BI traditionnelle ne disparaît pas, elle se réinvente.

La Business Intelligence évolue à vitesse grand V. L’essor de l’IA générative interroge, va-t-elle remplacer la BI ? La réponse est non.

Comme sur d’autres sujets, l’IA vient automatiser les tâches de premier niveau : retrouver un rapport, générer un commentaire, résumer une tendance, proposer un visuel ou encore suggérer des pistes d’exploration. Le gain de productivité est considérable, mais il ne remplace pas les KPI certifiés, les règles de gestion, la granularité métier, la logique de consolidation ni les arbitrages humains.

En réalité, plus l’interface utilisateur se simplifie, plus la sémantique et le modèle analytique sous-jacent deviennent stratégiques.

La BI entre dans une nouvelle ère.

La BI que nous connaissions, longtemps perçue comme un “écran final”, devient désormais une infrastructure centrale, garante de la confiance dans les données. Les data products analytics de Qlik, les semantic models de Power BI ou la sémantique gouvernée de Tableau en sont des illustrations : tous visent à bâtir le socle d’une BI augmentée et gouvernée.

Car une question posée en langage naturel n’est pertinente que si le système sait exactement ce qu’est une marge, un churn, un lead qualifié ou un stock disponible. En d’autres termes, la conversation ne remplace pas le socle : elle le met à nu.

Chez Smartpoint, nos experts Data IA voient dans cette mutation une formidable opportunité : replacer la BI au cœur de l’écosystème data et lui redonner sa mission première : rendre la donnée fiable, accessible et intelligible dans un monde piloté par l’IA.

La différence entre BI Traditionnelle et BI Augmentée

FonctionnalitésBI traditionnelleBI augmentée (2026)
Interface utilisateurDashboards statiques, requêtes SQL, self-service limité (Power BI, Qlik Sense, Tableau) Conversationnelle en NLQ, copilotes (Copilot Power BI, Tableau Agent, Qlik Answers), narration automatique et task flows
Usages principauxDescriptive (KPI, rapports, restitution)Prédictive/prescriptive : anomalies, what-if, alerting temps réel, actions auto (OODA accéléré), analytics agentique
Socle techniqueModèles analytiques basiques, data vizCouche sémantique (metrics layer, semantic models), RAG, data lineage (Purview/Fabric), gouvernance critique (OneLake, Rule-Based Semantic)
ProductivitéAutomatisation limitée, métiers dépendants de la DSIGain énorme : NLQ, résumés automatisé, data viz par prompt
Accessible à tous mais attention à la « surconfiance »
RisquesErreurs visibles (filtres absents, data viz incohérentes)Hallucinations plausibles sur KPI métiers (LLM fallback), erreurs amplifiées
Exige vérification humaine
Gouvernance requiseBasique (accès, fraîcheur données)Avancée : sémantique transverse, auditabilité, traçabilité sources, conformité AI Act/SecNumCloud
PlateformesPower BI, Qlik Sense, TableauMicrosoft Fabric (convergence), Qlik (agentique gouverné), Tableau (exploration IA), DigDash (souveraineté)

Le vrai danger ? « Halluciner » sur des KPI métiers

Le risque majeur de cette nouvelle BI augmentée ne réside pas seulement dans l’erreur ; il réside dans l’erreur plausible.

Autrefois, un tableau de bord mal conçu laissait quelques indices : absence de filtres, doutes sur la source, visualisation incohérente… Aujourd’hui, un copilote conversationnel peut produire une réponse concise, convaincante … et complètement fausse. Et une mauvaise réponse formulée avec assurance par un copilote est inacceptable. Chez Smartpoint, nous considérons que le déploiement d’un Semantic Link ou d’un Metrics Layer n’est plus une option mais un prérequis de sécurité opérationnelle

La documentation de Microsoft Copilot est explicite sur le sujet : selon la requête, l’outil peut s’appuyer sur le modèle sémantique de l’entreprise ou, dans certains cas, sur les connaissances générales du LLM. Sans ancrage solide dans la donnée métier, le système ne livre pas nécessairement la vérité métier, il fournit une réponse statistiquement plausible.

Dans le cas de KPI financiers, de prévisions de ventes ou de stocks critiques, cela peut avoir des conséquences lourdes.

Les causes sont souvent basiques : indicateurs mal définis, fraîcheur, documentation non mise à jour, données incomplètes, configuration de sécurité défaillante, confusion entre plusieurs versions d’un KPI ou périmètre d’analyse insuffisament précis

Et la conversation masque la faiblesse du socle. Plus l’interface est fluide et “propre”, plus le risque de surconfiance augmente. Ce n’est pas un hasard si Qlik met l’accent sur la traçabilité et l’explicabilité ou si Tableau recommande une revue humaine systématique des réponses générées par l’IA.

La BI augmentée offre un gain de temps considérable mais elle peut aussi accélérer la diffusion d’une erreur avec une assurance déconcertante.

Chez Smartpoint, nos experts Data et IA sont convaincus que la vraie puissance de l’IA dans la BI n’est pas dans la génération instantanée de réponses, mais dans la solidité du socle qui les rend justes, auditées et explicables.

Pourquoi la gouvernance est au coeur cœur de la nouvelle stack décisionnelle

Longtemps considérée comme une annexe des projets data, la gouvernance des données devient aujourd’hui la condition sinequanone de la fiabilité dans une BI conversationnelle et augmentée.

1. La couche sémantique, le socle de confiance

La première brique de cette nouvelle architecture décisionnelle, c’est la couche sémantique transverse : metrics layer, glossaire métier, définitions partagées, objets certifiés, sécurité d’accès, règles de calcul explicites. C’est elle qui permet de parler le même langage, de Power BI à Tableau ou encore Qlik.

Microsoft pousse cette logique encore plus loin. Les Semantic Models, le catalogue OneLake et Semantic Link renforcent l’interopérabilité entre IA, BI et data engineering autour d’une couche partagée et gouvernée. Tableau, de son côté, étend en 2026 son Rule-Based Semantic Model Authoring pour élargir les modèles tout en conservant des règles d’accès maîtrisées. Qlik adopte une approche différente, mais complémentaire qui consiste à fournir des réponses gouvernées, explicables et réutilisables pour l’analytics agentique.

2. Le catalogue, le lineage et l’auditabilité

Deuxième brique, la traçabilité et la gouvernance opérationnelle. Microsoft intègre désormais Purview et Fabric pour offrir une gestion unifiée : traçabilité, classification, labels de sensibilité, protection et audit des données. OneLake sert de datalake unifié et logique avec un catalogue centralisé accessible depuis plusieurs points d’entrée. Cette approche est essentielle pour la BI augmentée car une bonne réponse ne doit pas seulement sembler juste, elle doit être rattachable à une chaîne de transformation, une source identifiée, un propriétaire et un gestion des droits sous contrôle.

3. Le RAG, le maillon intelligent

Enfin, le Retrieval-Augmented Generation (RAG) trouve naturellement sa place dans la stack décisionnelle. Dans la BI, il ne remplace pas le modèle analytique, il l’enrichit. Son rôle est de rattacher chaque réponse à un contexte validé : définition du KPI, règle de gestion, note de clôture, référentiel produit ou encore procédure métier.

Des outils comme Qlik Answers incarnent cette nouvelle approche : mélange de données structurées, documents certifiés, citations et explications de raisonnement. Bien employé, le RAG devient un levier puissant de transparence. Mal utilisé, c’est un cache-misère sur un socle instable…

Chez Smartpoint, nous voyons dans cette convergence entre couche sémantique, documents vérifiés et gouvernance renforcée comme les fondements d’une BI “AI-ready” , c’est à dire une BI capable d’exploiter l’IA sans renoncer à la rigueur, à la traçabilité ni en la confiance dans les données.

Quelle plateforme choisir une BI augmentée crédible ?

Souvent, nos clients nous demandent « Quelle est la plateforme la plus innovante ? » alors que la vraie question est plutôt « Quelle plateforme est la mieux alignée avec l’architecture data cible, le niveau de maturité en matière de gouvernance, les contraintes réglementaires et le modèle opérationnel que l’entreprise souhaite mettre en place ? »

En 2026, tous les éditeurs affichent une feuille de route IA très ambitieuse. La question n’est donc pas de savoir qui fait de l’IA dans sa solution, mais avec quel socle décisionnel et quelle gouvernance.

Microsoft, la convergence dans l’écosystème

Microsoft Fabric et Power BI sont (presque) incontournables si votre organisation est déjà ancrée dans l’écosystème Microsoft. Cette combinaison permet de rapprocher, au sein d’un même environnement, le data lake, les modèles sémantiques, la gouvernance et l’action.

  • OneLake offre un data lake unifié dédié à la donnée d’analyse.
  • Direct Lake optimise l’exploration interactive sur de gros volumes directement depuis OneLake.
  • Power BI ajoute des usages plus opérationnels, notamment via les task flows, qui rapprochent la donnée et l’action.

Cette intégration renforce la sémantique gouvernée, la cohérence et la fiabilité des analyses.

Qlik , la gouvernance et les analytics “agentique”

Qlik se distingue par son approche pour une BI augmentée gouvernée. La plateforme pousse le concept d’analytics agentique, c’est à des réponses contextualisées, expliquées, sourcées et réutilisables avec une priorité sur la traçabilité et à la qualité des données. Chez Smartpoint, nos experts Data et IA considèrent également que la gouvernance est le nerf de la guerre dans cette nouvelle génération de BI powered-by-IA.

Son ouverture aux données structurées et non structurées, ainsi que ses capacités avancées d’analytics et de machine learning en font un très bon choix de plateforme pour les organisations qui priorisent une autonomie analytique solide et surtout traçable.

Tableau, l’exploration augmentée au service des analystes

Tableau conserve sa longueur d’avance historique sur l’expérience Analyste et l’exploration intuitive. Les nouvelles fonctionnalités IA permettent notamment :

  • La génération de data visualisations à partir de prompts en langage naturel
  • Des résumés automatisés de tableaux de bord,
  • Le renforcement de la sémantique gouvernée pour assurer la cohérence et la fiabilité des analyses

Tableau reste une référence pour les équipes qui privilégient créativité, rigueur analytique et gouvernance.

DigDash, l’alternative française souveraine et « AI-Native »

Clairement, pour nos expert Data IA, DigDash est en train de s’imposer comme une réponse stratégique aux enjeux de souveraineté. L’éditeur a pris de front la convergence Data/IA en intégrant l’IA au cœur de son moteur analytique. À Lire Souveraineté des données : le cas oublié de la business intelligence par DigDash.

  • DigDash Agent & NLQ : L’assistant conversationnel permet de générer des visualisations et des analyses complexes en langage naturel sans compromis sur la rigueur du modèle de données.
  • Analytics Prédictif : Régressions, lissages, calculs statistiques avancés pour passer de la BI descriptive au prédictif.
  • Souveraineté « by design » : Face à l’AI Act et aux exigences SecNumCloud, DigDash offre une maîtrise totale de l’hébergement et des flux, échappant nativement aux contraintes du Cloud Act.

Le choix d’une plateforme Data souveraine ? Un critère de plus en plus déterminant pour les DSI françaises

Rappelons que L’AI Act est entré en vigueur le 1er août 2024 et sera pleinement applicable à partir du 2 août 2026 avec certaines obligations déjà actives. En parallèle, l’ANSSI est oeuvre sur l’extension de périmètre de NIS 2 alors que les exigences de gestion du risque cyber ne cessent de croitre. Aujourd’hui, intégrer l’auditabilité, la traçabilité, la gouvernance des accès, la localisation des flux et la maîtrise des dépendances sont en passe de devenir des critères en termes d’architecture Data / IA.

Le sujet de la souveraineté ou de l’hybridation des plateformes Data n’est plus anecdotique. Pour une DSI française, le choix d’une plateforme souveraine devient un critère de résilience.

Nos experts Data IA accompagnent d’ailleurs de plus en plus d’organisations dans la conception d’architectures hybrides qui exploitent la puissance de calcul des LLM mondiaux et le stockage sécurisé sur des environnements qualifiés SecNumCloud.

Luc Doladille, Directeur Conseil, Smartpoint

D’ailleurs, Microsoft précise que Copilot n’est pas encore pris en charge dans les clouds souverains. À l’inverse, OVHcloud met en avant ses offres et ses environnements SecNumCloud ainsi que ses engagements sur le traitement des données dans l’Union européenne. Scaleway, de son côté, communique sur son entrée officielle dans le processus de qualification SecNumCloud. L’offre n’est pas encore mature mais le sujet est bel et bien posé.

Alors, la BI survivra-t-elle à la déferlante de l’IA générative ?

La réponse est un oui ! Mais attention, la BI augmentée n’est pas une nouvelle génération dataviz conversationnelle. C’est un socle décisionnel gouverné, l’infrastructure de confiance indispensable pour alimenter les copilotes, les agents et le RAG sans sacrifier la fiabilité métier.

En 2026, la nouvelle stack décisionnelle n’est pas une simple addition de BI et d’IA. C’est une fusion cohérente entre BI augmentée, couche sémantique, RAG, gouvernance et plateforme opérable.

La véritable valeur d’un SI Data réside ans sa capacité à produire une réponse vraie, explicable, traçable et défendable. Ce qui fait aujourd’hui la différence sur le terrain, c’est l’implémentation rigoureuse d’un metrics layer, d’un glossaire métier unifié, d’un lineage exploitable et d’un RAG bien discipliné.

Chez Smartpoint, nous accompagnons les directions IT pour bâtir ces garde-fous, concevoir et mettre en oeuvre des plateformes Data IA qui tiennent la charge en production. Car dans un monde piloté par l’IA, le chat ne vaut rien sans un socle de vérité inébranlable !

En bref

Qu’est-ce que la BI augmentée ?

La BI augmentée désigne une business intelligence enrichie par l’IA, le langage naturel, les copilotes et l’automatisation de certaines analyses pour accélérer l’accès aux insights.

Pourquoi le RAG est important dans la BI ?

Le RAG permet de rattacher une réponse à des documents, à des règles de gestion ou à des définitions métier validées. Il renforce la traçabilité et limite les réponses seulement plausibles.

Pourquoi la gouvernance est incontournable dans une BI conversationnelle ?

Parce qu’un copilote analytique peut produire une réponse convaincante mais erronée si les KPI, la couche sémantique, le lineage ou les droits d’accès ne sont pas maîtrisés.

Migrer Cognos, Business Objects ou Talend en 2026 : les étapes pour moderniser la BI sans casser le run

En 2026, la modernisation de la BI est devenue un chantier prioritaire pour de nombreuses DSI. Il faut en effet réussir à faire évoluer le SI décisionnel sans recréer la dette qu’on cherche justement à réduire.​ Il faut garantir la continuité de service tout en réduisant la dépendance éditeurs et les coûts (licences, MCO) tout en gagnant en sécurité et en auditabilité. Côté CDO, l’enjeu est la cohérence des KPI, le time-to-data, la qualité des donnée, le self-service BI mais gouverné et l’exploitation de l’IA.

Le problème n’est pas seulement l’âge de Cognos, SAP Business Objects ou Talend, mais la somme des problèmes accumulés au fil des ans : rapports critiques non documentés, univers et couches sémantiques sur-sollicités, jobs Talend qui encapsulent une logique métier implicite, KPI “identiques” mais divergents, usages multipliés sans gouvernance des données adaptée.​

Une migration Cognos, SAP BusinessObjects ou Talend ne peut donc pas être appréhendée comme un simple projet de remplacement d’outil “lift-and-shift”. C’est un projet de rationalisation du patrimoine décisionnel, de reconstruction de la logique métier et de modernisation globale.​

Et l’urgence est réelle : Cognos Analytics 11.2.x sort du support standard au 30 avril 2026, Talend 7.3 est déjà en fin de vie avec un support étendu achetable jusqu’à décembre 2026, et SAP pousse les clients BI 4.3 vers BI 4.3 SP5 ou BI 2025 pour rester à jour sur les standards de plateforme, de connectivité et de sécurité.​

La bonne question n’est donc pas “Par quoi remplacer Cognos, BO ou Talend ?”, mais “Comment migrer sans compromettre le run, sans perdre la confiance des métiers et sans recréer une nouvelle dette décisionnelle dans un outil plus récent ?”.

Étape 1 : Cartographier le patrimoine décisionnel réel (et non supposé)

La première erreur classique en migration Cognos, SAP BusinessObjects ou Talend est de démarrer par le choix de la cible (Power BI, dbt, Fabric…). L’outil est secondaire, le patrimoine décisionnel est prioritaire.

Chez Smartpoint, nos experts data commencent toujours par une cartographie exhaustive du patrimoine BI réel :

  • Rapports actifs vs rapports dormants (la plupart sont rarement utilisés)
  • Univers, packages et couches sémantiques réellement sollicités
  • Jobs Talend critiques pour l’alimentation des référentiels
  • Dépendances entre reporting, transformations et KPI sensibles (finance, supply, conformité)
  • Jeux de données exposés aux métiers et leurs métadonnées​​

Pourquoi cette phase est critique ? Dans les environnements legacy, l’outil n’est que la façade. La vraie complexité se cache dans les règles métier implicites, les enchaînements de traitement et les contournements historiques. On ne migre pas des dashboards. On migre un système de preuve décisionnel.

Étape 2 : Sélectionner ce qu’il faut migrer, fusionner, refondre ou supprimer

Migrer Cognos, BusinessObjects ou Talend, c’est d’abord sélectionner. Nos experts migration BI catégorisent le patrimoine en 4 catégories :​​

CatégoriesDéfinitionExemples
MigrerUsage stable, logique métier fiableRapports financiers consolidés, KPI de pilotage critiques
FusionnerPlusieurs rapports/traitements couvrent le même besoin3 rapports CA “identiques” issus de sources divergentes
RefondreLogique métier valide mais construction legacy inadaptéeUnivers BO/Cognos ou jobs Talend à réingénier
SupprimerNon utilisé, obsolète ou non certifiéRapports dormants

Le ROI est immédiat. Cette rationalisation réduit de 50% en moyenne le périmètre de migration, les coûts et la dette BI. Dans les environnements Cognos ou BO legacy, une large part du patrimoine est redondante ou obsolète.

Étape 3 : Extraire la logique métier AVANT de migrer l’outil

C’est une étape trop souvent sous-estimée en migration Cognos, Business Objects ou Talend. Les DSI expriment le besoin simplement : “Migrer BO vers Power BI” ou “Sortir de Cognos”. On pense rapports, interfaces, performances… alors que la vraie difficulté est généralement dans la logique métier encapsulée.​

Les DSI sous-estiment systématiquement l’étape critique : extraire la logique métier cachée dans Cognos/BO/Talend.

Luc Doladille, Directeur Conseil Data IA, Smartpoint


Où se cache cette logique métier ?

OutilsLogique métier encapsuléeExemples
CognosRègles de calcul complexes, packages sémantiquesAgrégations hiérarchiques, jointures historiques
BusinessObjectsUnivers sur-sollicités, filtres implicitesDéfinitions KPI métier, règles de scoping
TalendChoix métier ETL, contrôles qualitéExceptions non documentées, arbitrages métier

Pour Talend, c’est encore plus critique. Les chaînes d’intégration contiennent des choix métier critiques, des contrôles qualité, des exceptions, voire des arbitrages non documentés. Remplacer Talend sans extraire cette logique, c’est tout simplement déplacer la dette sans la comprendre.​

À cette étape, Smartpoint livre une base de connaissance métier et technique indépendante de l’outil source (prête à être intégrée dans Power BI, Fabric ou autre plateforme Data cible)  comprenant les règles de calcul, les définitions des KPI et les contrôles métier.

Étape 4 : Architecture cible brique par brique (jamais monolithe)

Une migration BI réussie ne consiste pas à remplacer un monolithe par un autre. Nos architectes data s’attachent à concevoir une architecture BI modulaire et gouvernable.

Les 5 briques essentielles :

  • Stockage / calcul : Adapté au volume et à la fréquence (lakehouse Snowflake / Fabric)
  • Transformation : ELT moderne (dbt, Databricks)
  • Metrics Layer : sémantique unifiée et versionnée (KPI cohérents)
  • Exposition analytique : headless BI (Power BI, Tableau et API)
  • Gouvernance : qualité, observabilité, sécurité, lignage

Le piège fréquent à ce stade est de se focaliser sur une suite BI en particulier. Faire par exemple de Power BI la réponse à tout. Power BI est un bon outil de restitution et de self-service BI gouverné mais il ne gère pas de transformation lourde ni la gouvernance complexe de KPI.

Même chose pour Talend. Passer à dbt, à un ELT cloud ou à une nouvelle plateforme data n’a de valeur que si on a qualifie en amont ce que l’on transforme, pourquoi, à quelle fréquence, avec quels tests et pour quels consommateurs des données.

Selon nos consultants spécialisés en architectures de data modernises, le sujet n’est pas quel outil choisir mais quelles briques moderniser et son niveau d’autonomie dans la plateforme Data globale (Data Mesh, Data Fabric). D’ailleurs, la réalité est souvent best-of-breed.

Étape 5 : Cutover progressif, pas de big bang

Il est évidemment hors de question de « couper » Cognos, BO ou Talend du jour au lendemain. La modernisation BI passe obligatoirement par une coexistence temporaire maîtrisée entre legacy et plateforme data cible.

Pour ce, nos consultants en migration Data cadrent systématiquement :

  • Les lots qui doivent migrer en priorité (KPI critiques, rapports métiers)
  • Les usages Legacy maintenus pendant la transition
  • La version du KPI faisant foi (legacy ou cible)
  • La gestion d’éventuels double calculs (seuils d’écart, arbitrage automatique)
  • La manière dont les écarts doivent être gérés (reprise manuelle, alertes, investigations)

Sans ce cadrage préalable, l’équipe Data se retrouvent à piloter deux environnements, deux vérités possibles des mêmes KPI et la confiance utilisateurs de dégrade ce qui risque de nuire à la nouvelle plateforme avant même qu’elle ne soit déployée.  

Étape 6 : Refactoring dans des standards modernes

Une migration Cognos, BO ou Talend, c’est surtout une occasion inespérée de prendre le temps de remettre à plat tous les standards qui n’avaient jamais été formalisés. Concrètement, cela veut dire industrialiser pour ne pas reproduire la dette BI dans la plateforme cible :

  • Versionning des développements (Git pour rapports et ETL)
  • Tests automatisés (unitaires, intégration)
  • Documentation des flux et des transformations (lineage automatique)
  • Règles métier explicites (metrics layer documenté)
  • Séparation des environnements (développement, test et production)
  • Observabilité des pipelines (alerting, monitoring temps réel)
  • Contrôles qualité industrialisés (SLO data quality)

Une migration devient le chantier de delivery qui reconstruit la chaine de confiance. C’est l’opportunité de faire entrer le SI décisionnel dans une logique de plateforme data moderne (data mesh, data products, gouvernance fédérée)

Étape 7 : Valider les KPI avec les métiers

Beaucoup de projets de migration sont un échec (environ 80% selon Gartner) car les métiers remettent en question les chiffres. Et Cela parle à toutes les DSI.

Une migration BI ne se valide pas par simple comparaison tableaux de bord entre ancien et nouveau. Elle demande de mener une campagne exhaustive de validation métiers

  • Règles de calcul (formules, agrégations, hiérarchies)
  • Seuils d’écarts acceptables (tolérances business)
  • Périodes de référence (cohérence temporelle)
  • Données de contrôle (échantillons critiques)
  • Profils statistiques (min/max, distributions, nullité)
  • Intégrité référentielle (clés étrangères, liens inter-tableaux)

On n’est pas dans l’esthétique Data Viz mais dans la confiance dans les chiffres sur lesquels les métiers vont s’appuyer pour prendre des décisions.

La couche sémantique (glossaire métier, data catalog avec lignage KPI), la documentation des indicateurs et les tests parallèles entre ancien et nouveau sont des critères décisifs de succès. C’est ici que se joue la différence entre une migration subie et une modernisation réellement utile.

Étape 8 : Enfin, décommissionner réellement !

Cette dernière étape est essentielle pour optimiser le ROI. Concrètement, il s’agit de désactiver tous les rapports remplacés, archiver ce qui doit l’être (exigences règlementaires ou métiers), fermer les dépendances techniques devenues inutiles, refaire une passe sur les licences et maintenance associés et mettre à jour la documentation. En clair, c’est le grand ménage !

À lire sur le sujet

  • De Power BI à data products, l’architecture BI temps réel de 2026
De Power BI à data products, l’architecture BI temps réel de 2026
  • Architecture data mesh & data catalog : la stratégie gagnante
Architecture data mesh & data catalog : la stratégie gagnante

Pilotage temps réel : pourquoi le streaming est le must-have de la BI en 2026

Paris, le 4 mars 2026
Auteurs : Luc Doladille et Emmanuelle Parnois

Le décisionnel « dans le rétroviseur » a fait son temps. Dans la plupart des organisations, la BI reste pourtant encore structurée autour d’extractions nocturnes, de chaînes ETL historiques et de dashboards générés à J+1 … alors que visualiser l’activité à postériori n’est plus suffisant. L’enjeu aujourd’hui est de rapprocher donnée, décision et action. Et c’est justement cela que le streaming apporte au SI décisionnel. On ne peut pas remettre au lendemain une fraude, une rupture de stock, une chute de marge ou problème logistique, le signal doit être envoyé dans les flux métiers au moment où il est exploitable. Tous les éditeurs de data streaming comme ceux de plateformes d’analytics agentiques partagent cette même vérité : l’IA s’alimente d’un contexte vivant, de données fraîches, traçables et gouvernées.

Terminé le batch ?

Pas tout à fait ! Le batch reste incontournables pour les usages réglementaires, les consolidations financières, les traitements historiques lourds ou les analyses peu sensibles à la latence. En revanche, il ne peut plus être seul moteur de pilotage de l’entreprise. Lorsqu’une décision métier dépend d’un événement survenu il y a quelques secondes ou quelques minutes, la fraîcheur de donnée est une variable métier essentielle pas un simple composant d’architecture data. Chez Smartpoint, spécialiste 100% Data IA, nous accompagnons nos clients depuis 20 ans dans l’évolution de leur plateforme data et nous constatons clairement un virage vers une BI streaming-first. Le flux temps réel devient un élément natif de l’architecture BI plutôt qu’un dispositif exotique réservé aux besoins les plus avancés.

Techniquement, cela repose sur la capture de l’événement à la source, via des patterns de type CDC (change data capture), des plateformes d’event streaming comme Kafka et des moteurs de traitement capables de travailler au temps de l’événement plutôt qu’au temps d’arrivée. Kafka sert désormais de plateforme d’event streaming pour alimenter des pipelines temps réel et des usages analytiques critiques. En parallèle, Apache Flink (ainsi que Structured Streaming dans l’écosystème Spark) permettent d’industrialiser un traitement continu. Flink met notamment en avant des garanties de cohérence de type exactly-once et une gestion native du temps d’événement. Le sujet n’est donc plus le simple transport de données mais la continuité du signal entre l’événement, son traitement et la décision métier.

Le schéma d’architecture le plus lisible reste souvent celui d’une architecture Kappa ou plus largement d’une approche stream-first : un même socle événementiel alimente les usages opérationnels et analytiques, au lieu de faire cohabiter des chaînes batch d’un côté et temps réel de l’autre. Le bénéfice ne tient pas seulement à la latence, il est aussi dans une urbanisation data plus simple, plus cohérente et plus durable.

Luc Doladille, Directeur Conseil, Smartpoint

De l’Operational Analytics au Live Steering

Le sujet n’est donc pas de produire un nouveau dashboard plus beau ou plus rapidement. Il s’agit de faire évoluer la BI vers l’Operational Analytics puis vers ce que l’on appelle le Live Steering, c’est à dire une donnée qui ne sert plus uniquement à constater mais à orienter directement l’exécution dans les outils métiers. Une anomalie de stock doit pouvoir déclencher une alerte d’approvisionnement, une dérive de marge doit remonter dans le CRM, un incident logistique doit influencer le TMS (transport management system) ou le WMS (Warehouse management system) et un écart dans un comportement client doit pouvoir ajuster en quasi temps réel une action marketing ou une priorité de traitement.

ThoughtSpot décrit d’ailleurs cette nouvelle génération d’analytics comme une capacité à combler l’écart entre le moment où l’on a besoin d’une réponse et celui où on l’obtient réellement, avec des insights de confiance délivrés en secondes plutôt qu’en jours.

Et cette évolution change le rôle du décisionnel. Certes, le pilotage mensuel ou hebdomadaire reste indispensable pour la trajectoire globale, la planification et l’arbitrage. Mais le pilotage temps réel, lui, gère l’exécution au quotidien. Il agit exactement là où se joue désormais la performance de l’entreprise et sa compétitivité : fraude, pricing dynamique, optimisation supply chain, disponibilité produit, qualité de service ou expérience client. La BI n’est plus une couche de restitution séparée du réel, elle devient un composant de l’action opérationnelle.

Alerting intelligent et Agentic BI, et le signal devient action

Chez Smartpoint, nos experts Data et IA recommandent l’Agentic BI. À ne pas confondre avec le chatbot analytique qui attend une question … l’agent analytics surveille en continu l’environnement de données, il détecte les variations significatives, il propose une décision et peut l’exécuter selon le niveau de gouvernance autorisé. ThoughtSpot de son côté définit l’Agentic Analytics comme une approche où les agents IA ne se contentent plus de faire remonter un insight. Ils surveillent les flux, détectent les anomalies, décident et agissent selon les objectifs métier. Et bien entendu, cette autonomie n’exclut pas la supervision humaine. Au contraire, elle la repositionne aux bons endroits, là où le risque ou l’impact la rendent indispensable.

Chez Smartpoint, nous avons structuré notre démarche autour d’un cycle très simple, inspiré de l’OODA Loop et appliqué à l’analytique temps réel : observer, analyser, décider, agir.

La fin du dashboard statique, on passe à des interfaces éphémères

Autre évolution structurante, le dashboard n’est plus forcément figé selon un formalisme prédéfini. Les nouvelles approche d’Agentic BI Dashboard promettent un monde où l’interface analytique est dynamique, éphémère et générée à la volée selon l’intention de l’utilisateur métier. En clair, au lieu de maintenir une usine de tableaux de bord statiques, on laisse un agent IA comprendre la question, aller chercher les bonnes sources, exécuter les traitements nécessaires, puis composer le rendu visuel adapté. Évidemment, ce n’est pas absolument pas la réalité au sein des DSI mais Qlik a déjà fait des annonces en ce sens avec Qlik Answers comme Tableau Next et ThoughtSpot.

Il faut aussi noter, dans cette tendance de fond, la montée en puissance du Model Context Protocol (MCP). Il ne remplacera ni la gouvernance, ni la modélisation, mais il standardise la connexion entre les applications IA, les sources de données et les outils. Présenté comme un protocole ouvert , le “port USB-C” de l’IA », il facilite l’accès à des systèmes externes sans multiplier les connecteurs spécifiques. Le MCP ne porte pas, à lui seul, la BI du futur. En revanche, c’est un accélérateur concret pour des interfaces analytiques conversationnelles capables d’interroger SQL, API, fichiers ou moteurs de calcul sans empiler des couches de code ad hoc.

En tant que pure player data IA, chez Smartpoint nous pensons qu’il faut prendre du recul face aux promesses de l’agentic analytics. Un agent analytique crédible n’a pas vocation à raisonner « au jugé » sur des calculs sensibles. Nos ingénieurs Data IA se concentrent au contraire sur l’exécution de code, par exemple en Python, pour fiabiliser les traitements et sécuriser les résultats, plutôt que de déléguer le raisonnement numérique au seul modèle. Sur des sujets aussi critiques que la marge, la fraude ou la performance commerciale, cette exigence méthodologique change tout côté DSI.

Quel système data pour un décisionnel temps réel ? Architecture et outils

Selon nos architectes Data IA, l’architecture BI temps réel s’organise autour de quatre couches.

1. Ingestion et transport d’événements

La première est celle de l’ingestion et du transport événementiel. Kafka reste la référence pour nos équipes Data IA avec tout son écosystème de connecteurs, de CDC et de patterns event-driven. Les plateformes managées sont de plus en plus fréquentes parce que les équipes veulent consacrer moins d’énergie à l’exploitation de clusters et davantage à la qualité, à la gouvernance et aux data products.

2. Traitement in-flight

La deuxième couche est celle du traitement in-flight. Flink, PyFlink, Spark Structured Streaming et les capacités temps réel de Databricks permettent de filtrer, enrichir, agréger et corréler les événements avant leur exposition analytique. C’est essentiel pour un SI décisionnel moderne qui ne se résume pas à sa vitesse mais aussi en sa capacité à combiner faible latence, tolérance aux pannes, gestion du temps d’événement et garanties de traitement cohérentes.

3. Serving layer analytique faible latence

La troisième couche est celle de la serving layer analytique faible latence. Sur ce terrain, ClickHouse et StarRocks s’imposent dans de nombreux scénarios de requêtes sub-secondes, de dashboards à forte concurrence et de workloads orientés agents. ClickHouse se positionne comme une base analytique open source pour le real-time analytics, tandis que StarRocks met en avant des requêtes multi-tables à latence sub-seconde et une capacité à servir des agents IA à forte concurrence (Voir comparatif dans les sources).

4. Plateformes unifiées cloud et data/AI

La quatrième couche est celle des plateformes unifiées cloud et data/AI. Microsoft Fabric pousse une logique de Real-Time Intelligence couvrant l’ingestion, la transformation, le stockage, l’analytique, la visualisation, l’IA et les actions temps réel. BigQuery est recommandé pour une analytique à grande échelle proche du temps réel. Snowflake, avec Unistore, est pour nos experts Data IA la solution lorsque l’on veut rapprocher le transactionnel et l’analytique dans une même plateforme. Globalement, tous les éditeurs convergent vers des architectures moins fragmentées où le décisionnel ne vit plus à plusieurs jours de distance de l’opérationnel !

De la corrélation à la causalité : pourquoi un agent seul ne suffit pas

Dans les secteurs régulés, il y a une problématique incontournable, celle de la validation.

Un bon agent de pilotage ne doit pas seulement corréler un signal et proposer une action. Il doit aussi pouvoir expliquer, sourcer, justifier et dans certains cas, se faire contredire. C’est là que les architectures multi-agents sont particulièrement adaptées avec un agent d’accès à la donnée et à la sémantique, un agent d’analyse ou de simulation, puis un agent de validation chargé de vérifier les seuils, les droits, les incohérences ou la nécessité d’une approbation humaine. L’enjeu est de rendre le pilotage automatisé certes, mais aussi auditable.

Une trajectoire de modernisation BI en 3 mois ?

En tant qu’expert en Data IA, nous prônons une approche incrémentale qui permet d’amorcer la trajectoire sans refaire le SI Décisionnel.

J1 à J30 : cadrer le data product temps réel

Identifier un cas d’usage où la fraîcheur de donnée a un impact business immédiat : fraude, stock, supply chain, pricing, relation client. Cartographier les sources, définir les KPI et les encoder dans une semantic layer gouvernée.

J31 à J60 : lancer le pilote streaming

Brancher un premier flux live, exposer un data product exploitable, mesurer la latence, la qualité, l’adoption et la capacité d’action dans le système cible. L’objectif n’est pas de faire du temps réel partout, mais de prouver la valeur sur un périmètre précis.

J61 à J90 : industrialiser l’alerting et préparer la sortie du legacy


Mettre en place des alertes intelligentes, les workflows d’escalade, l’observabilité des flux et les premières règles d’automatisation. Puis construire la roadmap de décomissionnement progressif des dashboards et des suites legacy qui génèrent plus de valeur.

En 2026, la BI n’est plus seulement un système de reporting. Elle devient une capacité de pilotage opérationnel, branchée sur le réel, nourrie par des flux continus, gouvernée par une couche sémantique stable et de plus en plus capable d’agir. Les organisations qui sauront passer d’une information stockée à une information vivante auront clairement une longueur d’avance avec moins de latence entre le signal, sa compréhension et la décision. Et, en matière de modernisation BI, c’est là qu’on arrête de piloter dans le rétroviseur !

Plus d’informations ? Besoins d’accompagnement ou de conseils ? Laissez-nous un message, nos experts Data-IA reviennent vers vous dans la journée.

Pour aller plus loin :