ARCHITECTURE LAKEHOUSE DATABRICKS SUR AWS ONE B2C DATA INTELLIGENCE PLATFORM ↔ DATASTONE

D'une gouvernance déclarative
à un Lakehouse Contract-First exécutable et prêt pour l'IA

Comment structurer la plateforme One B2C sur AWS & Databricks autour de Collibra, des contrats ODCS v3, de la couche sémantique Apache Ossie (OSI) et d'une glu d'exécution automatisée (dc43) — tout en garantissant l'interopérabilité avec Snowflake / SMUS / Fabric et le cadrage strict des agents IA.

1. Principes Data Mesh

Domaines & 3 Types de Produits

Cloisonnement hybride AWS/UC et séparation stricte Source-Aligned, Aggregated et Consumer-Aligned.

2. Contrats & Sémantique

ODCS v3 + Apache Ossie

Ontologie d'objets métiers (Aggregated) et règles de KPIs (Consumer-Aligned) manipulées par SDK.

3. Tour de Contrôle Active

Collibra Multi-Env + Glu dc43

Gouverner DEV, UAT et PROD sans dépendre de la seule discipline humaine.

4. Interop & Harnais IA

Iceberg REST & AgentCore MCP

Partage sans copie avec Snowflake et protection absolue des systèmes « Talk to my Data ».

Dossier d'Architecture — One B2C Data Intelligence Platform Fil conducteur : Principes → Capacités → Solutions → Arbitrages SWOT → Risques & Angles Morts

ÉTAPE 1 : LES FONDATIONS

Les 6 Principes Fondamentaux d'Architecture

Slide 2 / 9

P1. Domaines Cloisonnés (Hybride) Souveraineté & FinOps

Un Data Domain reflète une capacité métier, un centre de coûts et un périmètre légal/pays. Il est isolé physiquement (Workspace Databricks + Bucket S3/KMS dédiés) et unifié logiquement dans un seul Metastore Unity Catalog régional (avec Workspace-Catalog Binding).

P2. Trois Topologies de Data Products Au-delà du Medallion

Le Medallion (Bronze/Silver/Gold) reste interne au pipeline. L'architecture expose 3 types de produits : 1) Source-Aligned (réalité système ATLAS/NOVA), 2) Aggregated (Objets métiers 360° & MDM), 3) Consumer-Aligned (KPIs et usages BI/IA).

P3. Contrats ODCS v3 & Approche Top-Down Contract-First

Chaque port est régi par un contrat Open Data Contract Standard (ODCS) manipulé par SDK Python/TS (zéro YAML manuel). Tout changement fait l'objet d'une analyse d'impact contractuelle avant le développement.

P4. Sémantique Opérationnelle à 2 Étages Apache Ossie (OSI)

Étage 1 (sur Aggregated) : Ontologie des objets métiers (Client, Contrat, PDL) et relations.
Étage 2 (sur Consumer-Aligned) : Formules certifiées des KPIs et contexte IA formalisés en Apache Ossie et compilés vers les plateformes.

P5. Collibra Tour de Contrôle Multi-Env DEV • UAT • PROD

Collibra ne gouverne pas que la PROD ! Il relie Produits, Ports, Contrats, Ontologies, KPIs, Stratégies de Protection et évolutions de versions dans tous les environnements, couplé à une glu d'exécution (dc43).

P6. Interopérabilité & Harnais IA Strict Zéro Hallucination

Échange bi-directionnel avec Snowflake / SMUS / Fabric (Iceberg + Ossie). Côté IA, interdiction absolue de brancher « Talk to my Data » sur des produits Source-Aligned ou sur un port dont la Data Quality est en alerte.

Ces 6 principes dictent l'ensemble des capacités et choix technologiques suivants. One B2C Data Intelligence Platform

ÉTAPE 2 : LE CHAÎNON MANQUANT

Pourquoi une « Glu Technique » (`dc43`) est nécessaire (et comment la challenger)

Slide 3 / 9

❌ L'illusion de la « Gouvernance par les Processus Humains »

Acheter Collibra d'un côté et Databricks de l'autre en comptant sur des conventions documentaires et la discipline constante des équipes est un vœu pieux :

1. Le code ignore le catalogue : Un df.write.saveAsTable() natif dans Spark n'a aucune idée de savoir si la version du contrat dans Collibra est Approved ou Draft en UAT/PROD.

2. Collibra Edge est passif (Post-Mortem) : Il scanne la PROD après que les tables ont été modifiées. Il ne bloque aucun breaking change en amont.

3. Sécurité & DQ fragmentées : Les masques Unity Catalog (Q1), les droits Serving API (Q6) et les règles GX (Q7) sont gérés manuellement dans des outils séparés.

✅ La Glu Opérationnelle (dc43) & Notre Auto-Challenge

Il faut une brique d'intégration qui transforme les métadonnées déclaratives (Collibra + ODCS + Ossie) en contrôles techniques automatisés non contournables :

dc43-contracts-app
Studio web d'édition ODCS/Ossie (zéro YAML) + analyse d'impact avant dev.

dc43-service
Sync multi-env Collibra ↔ ODCS/ODPS, matrice de compatibilité & hooks ABAC UC.

dc43-integrations
Intercepte le read/write Spark, exécute la DQ (DQX/GX) et publie les scores.

⚖️ Challenge Architectural : « Quel risque d'introduire dc43 ? »

Objection : Dépendance à une brique open-source tierce.
Réponse : dc43 est une fine couche d'orchestration sans enfermement. Les artefacts produits sont 100 % standards (Bitol ODCS v3, ODPS, Apache Ossie) et l'exécution utilise les fonctions natives de Unity Catalog, Spark et Collibra.

Principe clé : Automatiser l'application des contrats pour ne jamais dépendre d'un comportement humain idéalisé. One B2C Data Intelligence Platform

ÉTAPE 3 : MODÈLE DE DONNÉES & SÉMANTIQUE

Les 3 Types de Data Products & la Sémantique à 2 Étages (ODCS + Apache Ossie)

Slide 4 / 9

1. Source-Aligned Products Interdit aux LLMs

Exposent la réalité opérationnelle des systèmes amont découpée proprement (ex: SAP ISU, Salesforce, Kaluza, flux Enedis C12/C15, PodRef Kafka).

Contrat ODCS : Schéma physique, typage fort, SLA de fraîcheur, anonymisation primaire.

Sémantique : Glossaire technique source uniquement. Aucune règle de KPI transverse.

2. Aggregated Products Étage 1 : Ontologie

Consolidation inter-sources des Objets Métiers 360° & Golden Records du domaine (ex: Client B2C, Contrat d'Énergie, Point de Livraison PDL/PCE, Facture).

Sémantique Étage 1 (Collibra + Apache Ossie) :

• OssieDataset & OssieRelationship formalisent l'ontologie et le graphe de jointures.

• customProperties ODCS pointent vers les attributs métiers et stratégies Privacy Collibra.

3. Consumer-Aligned Products Étage 2 : KPIs & IA

Produits conçus pour les usages finaux (Cockpit Marge B2C, Suivi Churn, Reporting Réglementaire, Talk to my Data).

Sémantique Étage 2 (Apache Ossie OssieMetric) :

• Port Pattern A (Stocké) : Table Delta/Iceberg matérialisée par Spark + dc43 (arrêtés financiers figés, partage Snowflake, Serving API).

• Port Pattern B (Dynamique) : Unity Catalog Metric View (+ Materialization Lakeflow) pour les ratios non-additifs en BI et MCP.

Chaînage de Bout en Bout (Zéro YAML écrit à la main) : Collibra (Glossaire, KPIs, Privacy) ↔ Modèles Python Pydantic (open-data-contract-standard & ossie.models) → Orchestration dc43 → Implémentation sur Databricks (ABAC RLS/CLS, DQX/GX, Metric Views) & Snowflake (Semantic Views).

Les KPIs peuvent être à la fois stockés sur un port Delta (auditabilité) et exposés en Metric View (analyse dynamique). One B2C Data Intelligence Platform

ÉTAPE 4 : VUE D'ENSEMBLE

Panorama Cible : Des Capacités aux Solutions Techniques

Slide 5 / 9

OBSERVABILITÉ & FINOPS

Sondes Data (Q7/Q10) : Télémétrie dc43 + Lakehouse Monitoring

Cockpit Ops Unifié (Q10) : Datadog (corrèle Infra SRE + Télémétrie Data via OpenTelemetry)

FinOps (Q15) : Cost Data Product (DBUs + AWS CUR + Tags dc43/DABs)

État Métier : Badge de conformité → Collibra

1. CONSOMMATION (Ancrée sur Apache Ossie) : Talk to my Data (Marketplace / Copilot - Q5) • BI Spécialisée (Power BI sur UC Metric Views compilées depuis Ossie) • Data Science (Mosaic AI / SageMaker) • Data Apps & APIs (Q6)

2. ACCÈS & IDENTITÉ (Q1/Q2/Q6) : Okta SSO (Humains) + AgentCore Identity (OBO Agents) • Stratégies Privacy Collibra → ODCS customProperties → Hooks ABAC dc43 (Unity Catalog, Snowflake, Serving)

3. MOTEUR SÉMANTIQUE (Q3) : Étage 1 Ontologie (Aggregated) & Étage 2 KPIs (Consumer-Aligned) gouvernés dans Collibra, formalisés en Apache Ossie, compilés via ossie-converters + dc43

4. TOUR DE CONTRÔLE (Q7/Q8/Q11 - DEV/UAT/PROD) : Collibra (Catalogue, Rôles, Workflows, Statut de conformité) + dc43-service (Sync ODCS/ODPS, Compatibilité) + DQ (Spec ODCS exécutée par DQX / GX)

5. INTEROPÉRABILITÉ (Q9/Q12) : Delta + UniForm (Iceberg) + UC Iceberg REST + Delta Sharing ↔ Snowflake (Iceberg REST + Semantic Views via Ossie) ↔ AWS SMUS & MS Fabric

6. BUILD & AUTHORING CONTRACT-FIRST (Q14) : Modélisation (Ellie.ai/SqlDBM + SDK ossie) • Studio Contrats Web (dc43-contracts-app + IA) • Spec-Driven AI-DLC & Gate CI/CD dc43

7. EXECUTION PLANE (Databricks AWS par Domaine) : Workspaces & S3/KMS par Domaine + 1 Metastore UC/Région • Produits Source-Aligned → Aggregated (Ontologie Ossie) → Consumer-Aligned (KPIs Ossie) via dc43-integrations

AGENTIC & MCP (Q2/Q4)

MCP Gateway : AWS AgentCore Gateway + Identity (OBO)

LLM Access (Q5) : AWS Bedrock + Guardrails

Semantic & Gov MCP (Q3/Q13) : Collibra MCP Server (+ cache sémantique Ossie/ODCS) → SQL OBO sur UC

Apps & ML MCP : AgentCore Runtime

Chaque capacité métier ou technique dispose d'une solution claire et intégrée au socle Groupe. One B2C Data Intelligence Platform

ÉTAPE 5 : ARBITRAGES & INTEROPÉRABILITÉ

Ordres de Préférence & SWOT sur les Choix d'Architecture

Slide 6 / 9

1. Talk to my Data : Bedrock vs Genie (Q5)

🥇 #1 : AWS Bedrock + AgentCore MCP + Apache Ossie → UC Metric Views

Forces : Aligné S&EM (Bedrock), ouvert à Copilot Studio, zéro hallucination SQL grâce à Ossie + Metric Views.
Faiblesse : Requiert la compilation Ossie → Metric Views.

🥈 #2 : Databricks Genie (en sous-agent MCP)
Très fort sur Databricks natif, mais non validé S&EM et ne couvre pas les branches Snowflake/SMUS.

🥉 #3 (Exclu) : Text-to-SQL brut par LLM
Risque critique d'invention de règles de gestion.

2. Data Quality : DQX vs Great Expectations (Q7)

🥇 #1 : Spécification dans ODCS → Orchestration dc43 → Moteur DQX ou GX

Forces : Les règles DQ restent portables dans le contrat ODCS ; exécution Spark native rapide (DQX) ou compatible GX ; publication auto vers Collibra.
Opportunité : Débloque One B2C sans attendre le Stream 4.

🥈 #2 : API Great Expectations codée en dur
Lourd à maintenir en Spark Streaming/DLT et découplé des contrats de schémas ODCS.

3. Interop Snowflake / SMUS / Fabric (Q9/Q12)

🥇 #1 : Delta UniForm (Iceberg) + UC Iceberg REST API + Apache Ossie

Forces : Zéro copie S3, standard groupe Iceberg, et surtout partage des mêmes formules de KPIs avec Snowflake via ossie-converters.
Vigilance : Les masques RLS dynamiques nécessitent Delta Sharing ou des vues dédiées.

🥈 #2 : Delta Sharing (Inter-régions / RLS strict)
Idéal quand le filtrage ligne/colonne dynamique doit être évalué par le fournisseur Databricks.

Découpler le standard déclaratif (ODCS / Ossie / Iceberg) du moteur d'exécution protège One B2C des changements d'outils. One B2C Data Intelligence Platform

ÉTAPE 6 : GOUVERNANCE DE L'IA

Harnais Agentique : AWS Bedrock, AgentCore MCP & Sécurité On-Behalf-Of

Slide 7 / 9

Étape 1 : Identité OBO (Q2)

Okta → AgentCore Identity

L'utilisateur s'authentifie sur la Marketplace ou Copilot. AgentCore Identity valide son JWT Okta et échange le jeton en OAuth2 On-Behalf-Of (OBO) pour Databricks, tout en traçant l'identité de service de l'agent.

Étape 2 : Garde-Fou Collibra (Q3/Q13)

Collibra MCP / Cache Sémantique

Avant toute requête, le serveur MCP vérifie dans Collibra (alimenté par dc43) :
1) Produit = Consumer-Aligned,
2) Contrat ODCS = Active,
3) Score DQ = Vert (Passed).

Étape 3 : Sémantique (Q5)

Exécution Apache Ossie

Le LLM (AWS Bedrock) ne rédige jamais de SQL improvisé sur des tables brutes. Il appelle une métrique certifiée (OssieMetric) sur une Unity Catalog Metric View ou table Consumer-Aligned.

Étape 4 : Droits Données (Q1)

Masques Unity Catalog (ABAC)

Le SQL Warehouse exécute la requête sous l'identité OBO de l'utilisateur. Unity Catalog applique automatiquement les Row Filters (Pays) et Column Masks (Privacy) issus du contrat ODCS.

Et côté Développeurs / Data Modelers (En phase de Build) :

Pour les profils métiers (DPO, Data Modelers) qui n'utilisent pas d'IDE, l'interface web dc43-contracts-app intègre un assistant IA qui génère les contrats ODCS et modèles Apache Ossie via leurs SDKs Python typés. Pour les Data Engineers, l'agent Spec-Driven AI-DLC génère le code Spark/DLT directement à partir de ces contrats approuvés.

Sécurité de bout en bout : Une seule politique pour les humains et les agents IA. One B2C Data Intelligence Platform

ÉTAPE 7 : GOUVERNANCE PROGRAMME & STEERCO

Réponses aux Points Q1–Q10 & 6 Nouvelles Questions (Q11–Q16) pour DataStone

Slide 8 / 9

Comment notre architecture débloque les 10 points ouverts (Q1–Q10)

Q1 (Access Master) & Q6 (Serving API) : Collibra définit la stratégie de protection → portée par customProperties ODCS → appliquée par dc43 en ABAC sur Unity Catalog et sur le Serving Cache.
Q2 (Agent Identity) & Q4 (MCP Gateway) : AgentCore Identity (OBO Okta → UC) + Serveurs MCP pilotés par les contrats et modèles sémantiques (zéro divergence).
Q3 (Collibra FKG) & Q8 (Lineage) : Modélisation immédiate en ODCS + Apache Ossie synchronisée avec Collibra via dc43 (sans être bloqué par le retard du métamodèle Collibra).
Q5 (Bedrock vs Genie) : Bedrock (AgentCore) en façade conversationnelle + UC Metric Views compilées depuis Ossie en exécution.
Q7 (Data Quality GX) & Q10 (Datadog Ops Unifié) : Règles DQ dans ODCS (exécutées par DQX ou GX via dc43) ; télémétrie Data (dc43 + Lakehouse Monitoring) envoyée dans Datadog (via OpenTelemetry) pour unifier InfraOps et DataOps, tandis que Collibra ne reçoit que l'état de conformité synthétique.
Q9 (Interop Iceberg) : Delta + UniForm (Iceberg) + UC Iceberg REST API.

➕ 6 Nouvelles Questions Stratégiques à poser à DataStone (Q11–Q16)

Q11 (Multi-Environnements dans Collibra) : Comment DataStone gère-t-il les versions de contrats et schémas dans Collibra en DEV et UAT (et pas seulement en PROD) pour éviter les ruptures en production ?
Q12 (Branches Sœurs Snowflake & KPIs) : Au-delà de SMUS et Fabric, comment partage-t-on à la fois les tables Iceberg et les formules de KPIs (Apache Ossie) avec les branches sur Snowflake ?
Q13 (Coupe-circuit IA sur Incident DQ) : Comment AgentCore / Marketplace bloque-t-il techniquement un agent IA si le score DQ du jour d'un Data Product est en échec ou s'il est Source-Aligned ?
Q14 (Outillage d'Authoring Contrats & Sémantique) : Quel studio web assisté par IA est prévu pour que les DPO/Modelers éditent ODCS et Ossie sans écrire de YAML manuel ?
Q15 (FinOps Partage Zero-Copy & IA) : Quel modèle de refacturation sépare le coût de Build (Producteur) du coût de lecture Iceberg / Tokens Bedrock (Consommateur) ?
Q16 (Purge RGPD & Droit à l'Oubli) : Comment l'effacement RGPD se propage-t-il automatiquement des tables Delta jusqu'au Serving Cache hors Unity Catalog ?

Poser Q11 à Q16 démontre une vision complète du cycle de vie opérationnel que le schéma initial avait omise. One B2C Data Intelligence Platform

ÉTAPE 8 : BILAN CRITIQUE & GESTION DES RISQUES

Avantages, Inconvénients (Trade-Offs) & Angles Morts Potentiels

Slide 9 / 9

✅ Avantages Décisifs

Gouvernance Automatisée By-Design : Fin de l'écart entre la théorie Collibra et la réalité Spark grâce à l'exécution contractuelle (dc43).
IA de Confiance : Zéro hallucination sur les KPIs métiers grâce au binôme Consumer-Aligned + Apache Ossie et à l'identité OBO.
Découplage & Vélocité : One B2C avance immédiatement sans subir les retards des streams DataStone (Collibra, GX, AM).
Interopérabilité Complète : Partage physique (Iceberg) ET sémantique (Ossie) avec Snowflake, SMUS et Fabric.

⚖️ Inconvénients & Coûts (Trade-Offs)

« Taxe Shift-Left » initiale : Demander de concevoir et valider le contrat ODCS et le modèle Ossie avant de coder exige un changement culturel fort (compensé par l'assistance IA dans dc43-contracts-app).
Complexité d'ingénierie du Socle : L'intégration OAuth2 OBO de bout en bout (Okta → AgentCore → MCP → Unity Catalog) et les hooks multi-environnements demandent une équipe plateforme très solide.
Standards en évolution rapide : Apache Ossie et UC Metric Views sont jeunes et nécessitent une veille active sur les convertisseurs.

🔍 Angles Morts à Anticiper

1. Données Non-Structurées & RAG (PDFs, Audio Dimelo) : ODCS/Ossie ciblent le tabulaire. Action : Étendre les contrats aux UC Volumes & Vector Indexes (ACL par document/chunk).
2. Streaming Temps Réel Pur (Kafka PodRef) : On ne bloque pas un flux temps réel comme un batch. Action : Routage automatique vers une Dead-Letter Queue (DLQ) sur violation de contrat.
3. Quotas & Latence API Collibra : Collibra ne peut pas absorber le trafic runtime direct des jobs et agents. Action : Cache opérationnel dans dc43-service.
4. Rattrapages Historiques (Backfilling SAP ISU) : Gérer les corrections rétroactives sans fausser les arrêtés comptables passés (snapshots bitemporels).

Conclusion : Une architecture pragmatique, ouverte, gouvernée de bout en bout et lucide sur ses conditions de succès. One B2C Data Intelligence Platform

D'une gouvernance déclarative à un Lakehouse Contract-First exécutable et prêt pour l'IA