Faut-il une architecture data différente pour la BI, l'IA et le self-service ?

Non. La BI, l'IA et le self-service ne réclament pas trois architectures data distinctes, mais une seule architecture data à socle commun, surmontée de trois couches d'exposition adaptées à chaque usage. Le socle (ingestion, stockage, qualité, gouvernance) reste partagé. Ce qui change, c'est la manière dont la donnée est servie à chaque public.

La tentation inverse est pourtant fréquente. Un entrepôt pour la BI, un lac pour les modèles, des extractions ouvertes pour les métiers en autonomie : à chaque besoin, sa pile technique. L'intention est louable, puisque chaque usage a bien ses contraintes propres. Mais le résultat est presque toujours le même : des silos qui se multiplient et des chiffres qui finissent par diverger d'un outil à l'autre.

L'idée reçue à déconstruire tient en une phrase. On croit que des usages très différents imposent mécaniquement des fondations différentes. Dans les faits, ce sont les couches hautes qui diffèrent, pas les fondations. Un modèle de prévision, un tableau de bord de direction et un export libre alimenté par un métier puisent dans les mêmes données sources, transformées par les mêmes pipelines, contrôlées par les mêmes règles de qualité.

La vraie question n'est donc pas "une ou plusieurs architectures", mais "qu'est-ce qui doit être commun, et qu'est-ce qui doit être spécifique". C'est cet arbitrage qui sépare une plateforme cohérente d'un assemblage coûteux et ingérable.

Non, pas trois architectures data, mais un socle commun

La BI, l'IA et le self-service partagent bien plus qu'on ne le croit. Avant de produire un dashboard, d'entraîner un modèle ou d'ouvrir un jeu de données à un métier, il faut collecter, stocker, nettoyer et gouverner la donnée. Ces étapes ne changent pas selon l'usage final. Elles constituent le socle, et ce socle n'a aucune raison d'exister en trois exemplaires.

Le socle partagé : ingestion, stockage, qualité, gouvernance

Le socle d'une architecture data regroupe les briques qui rendent la donnée disponible et fiable, quel que soit ce qu'on en fera ensuite. On y trouve quatre fonctions structurantes.

• L'ingestion : la connexion aux sources (CRM, ERP, outils SaaS, fichiers, flux) et le rapatriement des données vers un point central. Que la donnée finisse dans un rapport ou dans un modèle, elle entre par la même porte.
• Le stockage : l'endroit où la donnée repose, brute puis transformée. Un data warehouse pour le structuré, un lac pour les formats variés, ou les deux réunis. C'est une décision de socle, pas une décision d'usage.
• La qualité : les contrôles qui garantissent que la donnée est juste, complète et cohérente. Une donnée fausse produit un dashboard faux et un modèle faux. La qualité ne se négocie pas usage par usage, elle se garantit en amont, une fois pour tous.
• La gouvernance : les règles, les rôles et la traçabilité qui disent qui répond de quoi et d'où vient chaque chiffre. C'est le rôle d'un Data Architect que de penser cette ossature dans sa globalité, plutôt que de la laisser se reconstruire à chaque projet.

Mutualiser ces quatre fonctions, c'est se donner une source unique et fiable. Les dupliquer, c'est ouvrir la porte aux incohérences.

Pourquoi trois stacks en silo font diverger les chiffres

Le problème des architectures séparées par usage n'est pas théorique. Il se matérialise très vite, et toujours de la même façon.

Imaginons une organisation qui monte un entrepôt pour sa BI, un lac séparé pour ses data scientists et des extractions ad hoc pour ses métiers. Trois équipes, trois environnements, trois logiques de transformation. Le même indicateur, calculé trois fois, donne trois résultats légèrement différents. Le chiffre d'affaires du dashboard de direction ne colle pas avec celui du modèle de prévision, qui ne colle pas avec l'export du contrôleur de gestion.

Au-delà de l'incohérence, le silo coûte cher sur trois plans. Il duplique l'infrastructure (stockage, calcul, licences), il multiplie les pipelines à maintenir (la même donnée transformée trois fois), et il éclate la gouvernance (impossible de tracer une définition partagée). Ce mécanisme est précisément celui par lequel les coûts d'une architecture data augmentent sans que personne ne sache l'expliquer.

Pour rendre concret ce qui sépare réellement les trois usages, il faut descendre au niveau de la consommation. C'est là, et seulement là, que les besoins divergent.

Oui, trois couches de service différentes sur cette architecture data

Si le socle est commun, alors où sont les différences ? Elles se logent dans la couche de service, celle qui expose la donnée à son public. Chaque usage consomme la même matière première, mais sous une forme adaptée à ses contraintes. C'est cette couche, et elle seule, qui se décline en trois.

La couche BI : données modélisées et indicateurs certifiés

La BI a besoin de stabilité et de confiance. Un comité de direction ne discute pas la définition du chiffre d'affaires à chaque réunion. Il attend un indicateur certifié, historisé, identique d'un mois sur l'autre et d'un rapport à l'autre.

La couche BI s'appuie donc sur des données fortement modélisées : des data marts thématiques, des modèles en étoile, des indicateurs dont la règle de calcul est figée et documentée. La fraîcheur est généralement périodique, car une décision stratégique ne dépend pas de la dernière seconde. Ce qui prime ici, c'est la cohérence, pas la vitesse brute. L'entrepôt reste le socle naturel de cette couche, comme le détaille l'évolution du reporting au self-service.

La couche IA : données brutes, fraîches et calcul dédié

L'IA inverse plusieurs priorités. Là où la BI veut du structuré et du stable, un modèle se nourrit souvent de données brutes, variées et volumineuses, parfois non structurées (texte, images, logs). Le data scientist a besoin d'accéder à la donnée avant qu'elle soit agrégée, pour construire ses propres variables.

La fraîcheur dépend du cas d'usage. Une prévision mensuelle se contente d'un traitement par lots, tandis qu'une détection de fraude impose un flux continu. Le moteur change aussi : Python, Spark, parfois du calcul GPU, plutôt que du SQL analytique. Mais attention au contresens. Cette couche spécifique ne justifie pas une architecture à part. Comme le rappelle l'analyse sur le fait de savoir s'il faut une architecture spécifique pour l'IA, la plupart des projets tiennent parfaitement sur une fondation data saine, simplement mieux gouvernée. L'IA générative en analytics elle-même s'appuie sur les données déjà présentes dans la plateforme.

La couche self-service : jeux de données prêts à l'emploi et droits d'accès

Le self-service répond à un troisième besoin : rendre les métiers autonomes sans les laisser sans garde-fous. L'utilisateur n'est ni analyste BI ni data scientist. Il veut explorer, filtrer, visualiser, sans coder et sans casser quoi que ce soit.

Cette couche expose donc des jeux de données préparés, fiables et documentés, accompagnés de droits d'accès stricts et d'une définition partagée des indicateurs. Sans ce cadre, l'autonomie dégénère en désordre : des fichiers Excel parallèles, des tableaux de bord bricolés, des chiffres contradictoires. C'est précisément ce que décrivent les conditions de succès d'une BI en libre-service. L'autonomie sans cadre ne produit pas de la valeur, elle produit de la donnée incontrôlée.

L'architecture data qui réconcilie les trois : socle unique, couches distinctes

Une fois posé que le socle est commun et que seules les couches de service diffèrent, reste à savoir quelle architecture concrète permet de tenir les deux à la fois. La réponse tient en un modèle : un socle unique, modulaire, surmonté de couches d'exposition spécialisées.

Le lakehouse comme socle commun à la BI et à l'IA

Pendant des années, les organisations ont jonglé avec deux étages séparés : un lac pour stocker le brut et le non structuré, un entrepôt pour analyser le structuré. Deux environnements, deux fois la donnée, deux fois la gouvernance.

Le lakehouse répond exactement à cette tension. Il combine le stockage massif et les formats ouverts du lac, utiles à l'IA, avec la modélisation et la gouvernance de l'entrepôt, utiles à la BI. Un seul socle de stockage alimente les trois usages, chacun avec son moteur de calcul. La BI requête en SQL, l'IA entraîne ses modèles, le self-service explore, sans dupliquer la donnée. C'est ce qui en fait aujourd'hui le socle le plus complet pour relier ces besoins, comme le montre le comparatif des grandes options de stockage.

Ce socle s'inscrit dans une logique d'architecture modulaire, où ingestion, stockage, transformation et restitution évoluent indépendamment. Cette modularité est la condition pour faire cohabiter trois usages sans tout reconstruire à chaque évolution.

La couche sémantique qui garantit le même chiffre partout

Le socle commun règle le stockage. Il ne règle pas, à lui seul, la cohérence des indicateurs. C'est le rôle de la couche sémantique, qui s'intercale entre les données et les outils.

Sans elle, chaque outil recalcule ses indicateurs à sa façon. La BI applique sa règle, le self-service la sienne, et l'écart apparaît au premier comité. Avec elle, la règle de calcul est définie une seule fois et s'impose à tous. Le même indicateur renvoie la même valeur, qu'on l'ouvre dans un dashboard de direction ou dans un export métier. C'est le garde-fou qui rend le self-service possible sans sacrifier la fiabilité de la BI.

Quand une architecture data dédiée par usage se justifie quand même

Affirmer qu'un socle commun couvre la quasi-totalité des besoins ne veut pas dire que la séparation est toujours une erreur. Certaines situations appellent légitimement une brique dédiée. Les nommer évite l'excès inverse, qui consisterait à tout refuser au nom de la mutualisation.

Les cas limites : volume IA massif, temps réel, conformité

Trois situations justifient réellement un composant spécifique, ajouté au socle plutôt que construit à part.

• Le temps réel à forte volumétrie : une détection de fraude ou une recommandation instantanée impose un flux continu. Dans ce cas, on ajoute un flux pour ce périmètre précis, sans basculer toute l'architecture en temps réel.
• Les volumes massifs de non structuré : images, vidéos, texte à grande échelle appellent un stockage adapté. Un lakehouse bien gouverné absorbe le besoin sans recréer un silo isolé.
• Les contraintes de conformité fortes : un périmètre soumis à des exigences réglementaires strictes peut justifier un cloisonnement et des contrôles renforcés sur ce seul domaine. Cette logique rejoint les modèles décentralisés, où chaque domaine pilote ses données comme un produit, à l'image de l'opposition entre Data Mesh et Data Fabric.

Le principe directeur reste le même dans les trois cas. On paie l'incrément que le cas d'usage justifie, rien de plus. Faire évoluer une architecture, ce n'est pas la refaire, c'est la compléter avec discernement. Et aucun ajout technique ne compense des fondations défaillantes : la qualité et la gouvernance des données passent toujours avant le choix des composants.

Architecture data : pas trois stacks, trois couches

La question de départ appelait une réponse binaire, elle en a une. Non, la BI, l'IA et le self-service ne demandent pas trois architectures data. Ils demandent un socle commun, robuste et gouverné, sur lequel s'appuient trois couches de service taillées pour chaque public. Le socle assure la fiabilité et la cohérence. Les couches assurent l'adaptation à chaque usage.

Le vrai risque n'a jamais été de trop mutualiser. Il a toujours été de fragmenter : trois piles techniques, trois définitions, trois vérités qui s'opposent en comité. Une architecture qui tient dans le temps n'est pas celle qui empile le plus de technologies, c'est celle qui sait ce qu'elle partage et ce qu'elle différencie.

Quelques questions permettent de tester sa propre situation. Vos indicateurs renvoient-ils la même valeur en BI et en self-service ? Vos modèles puisent-ils dans la même donnée gouvernée que vos dashboards ? Combien de fois la même transformation est-elle écrite dans votre organisation ? Vos décisions d'architecture suivent-elles vos cas d'usage, ou la dernière tendance ? Les réponses disent, mieux qu'un audit technique, si votre plateforme repose sur un socle ou sur des silos. Cet arbitrage s'inscrit dans une réflexion plus large sur la stratégie data de l'organisation.

👉 À lire aussi : Architecture Data : comment faire des choix qui tiennent dans le temps ?

👉 À lire aussi : Data Lake vs Data Warehouse vs Data Lakehouse : un comparatif pour les décideurs data