Principes Data Mesh (3 topologies de produits) • Contrats ODCS v3 • Sémantique Apache Ossie (OSI) • Tour de Contrôle Collibra Multi-Env & Glu Opérationnelle dc43
Sondes de fraîcheur (SLA), volumétrie, dérive statistique (drift) et télémétrie d'exécution des contrats.
dc43 Telemetry + Lakehouse MonitoringSanté de l'infra AWS, clusters Spark, échecs de jobs, latence API Gateway et traces AgentCore.
Coûts par Domaine/Pays, Build (Producteur) vs Consommation (Lecteur/IA), détection des produits « Zombies ».
dc43 • Budget Policies DatabricksCorrélation dans un cockpit Ops unique entre pannes infra, violations de contrats ODCS et impact aval.
dc43 + Lakehouse Monitoring) + Sondes Infra → Datadog (Cockpit Ops unique) • Statut métier → Collibra
Q&A en langage naturel ancré sur la couche sémantique Consumer-Aligned.
OssieMetric & AIContext)Dashboards gouvernés et modèles sémantiques BI multi-dimensionnels.
ML, RAG, scoring (churn, propension), forecasting sur features certifiées.
Exposition applicative externe à fort volume / faible latence.
Agents métiers spécialisés (ex: Coach Facture) avec actions bornées.
Une seule politique pour les humains et les agents IA : règles d'accès et stratégies de protection définies dans Collibra, portées par les contrats ODCS, appliquées automatiquement sur chaque moteur.
customProperties → Hooks dc43 vers Unity Catalog (RLS/CLS), Snowflake & Serving API
Concepts métiers canoniques (Client, Contrat, PDL), attributs et graphe de relations inter-entités (FKG).
OssieDataset & OssieRelationship liés aux contrats ODCS.
Règles de calcul des KPIs (Marge nette, Churn), dimensions autorisées et contexte métier pour les agents IA.
OssieMetric, OssieExpression & OssieAIContext.
Traduction automatique des définitions sémantiques vers les moteurs d'exécution physiques et analytiques.
ossie-converters + dc43-service → Tables Delta stockées, UC Metric Views & Snowflake Semantic Views.
Définition des Domaines, Data Products, Ports, Contrats, Ontologies, KPIs, Stratégies de Protection et Workflows.
Synchronisation bidirectionnelle des contrats ODCS et produits ODPS avec Collibra et gestion des versions (DEV/UAT/PROD).
CollibraContractStore & Hooks UCRègles DQ déclarées dans le contrat ODCS, exécutées dans les pipelines et publiées en scorecards dans Collibra.
Lineage contractuel amont/aval dès la conception (avant dev) + lineage technique fin capturé à l'exécution.
dc43)Partage physique sans copie + partage du contrat et de la sémantique métier.
Consommation croisée transparente entre One B2C (Databricks) et les entités sur Snowflake.
ossie-converters (Snowflake Semantic Views).
Interopérabilité native avec les plateformes S&EM et BI Groupe.
Conception par les Data Modelers / DPO des ontologies d'objets métiers et des règles de KPIs (Apache Ossie) synchronisées avec Collibra.
ossie.modelsInterface web métier (pour DPO / Data Managers) permettant d'éditer les contrats ODCS, lier les attributs/privacy Collibra et analyser l'impact sans écrire de YAML.
open-data-contract-standardGénération assistée par IA des pipelines Spark/DLT et tests à partir des contrats approuvés, et promotion contrôlée DEV → UAT → PROD.
dc43 en CI/CD (remplace Dataiku - ADR-09)Reflet fidèle des systèmes sources (ATLAS / NOVA), typé et nettoyé techniquement.
dc43-integrations (spark.io)
Objets Métiers cœur (Client, Contrat, PDL/PodRef, Facture) porteurs de l'ontologie métier.
dc43-integrations (spark.io)
Produits d'usage analytique, BI spécialisée et Talk to my Data portant la couche sémantique des KPIs.
dc43-integrationsdc43-integrationsPoint d'entrée unique des agents, propagation du token Okta utilisateur (OBO) et auditabilité complète.
Inférence LLM standardisée S&EM et filtrage de sécurité sur les prompts/réponses.
Interroge Collibra pour fournir le contexte sémantique (Ontologie & KPIs), vérifier que le produit est Consumer-Aligned, actif et avec un score DQ valide, et exécuter la requête certifiée.
Outils MCP d'inférence ML, d'accès aux applications métiers B2C et d'actions approuvées.
dc43) est-elle indispensable entre Collibra et Databricks ?Pourquoi compter sur la discipline humaine et des conventions documentaires est une illusion (« Wishful Governance »), et comment répondre aux objections sur l'ajout de cette brique.
Dans 90 % des plateformes Data, on achète Collibra d'un côté et Databricks de l'autre, puis on rédige des normes sur Confluence en espérant que les équipes les respecteront de manière constante. En réalité, sans glu technique automatisée :
df.write.saveAsTable() classique dans Spark sans jamais vérifier si le contrat est approuvé dans Collibra.dc43) + Comment la challenger nous-mêmes
dc43 n'est ni un nouveau catalogue (c'est Collibra) ni un moteur de calcul (c'est Spark/Databricks) : c'est le harnais logiciel automatisé qui force le code à respecter la gouvernance déclarative sans dépendre de la bonne volonté humaine.
dc43 n'enferme aucune donnée ni aucun métamodèle propriétaire. Il manipule exclusivement des standards ouverts (Bitol ODCS v3, ODPS, Apache Ossie) et pilote les APIs natives de Collibra et Unity Catalog. Si demain un éditeur couvre 100 % du flux, les contrats ODCS restent intacts.dc43 fait de l'application ascendante et descendante active (Contract Enforcement) au moment du read/write Spark et du gate CI/CD multi-environnements.Comparaison structurée des options lorsque plusieurs solutions coexistent entre l'écosystème Databricks (One B2C) et l'écosystème AWS/S&EM (DataStone).
dc43 → Exécutées par Databricks DQX / Lakeflow Expectations (ou GX en plugin)
dc43 plutôt que de coder en dur en API GX.dc43 devra formater le payload ValidationResult en conséquence.ossie-converters, partage à la fois la table ET la formule du KPI avec Snowflake.Détail intégral des questions taguées sur le schéma, statut actuel côté DataStone, et notre positionnement architectural cible pour débloquer One B2C.
| ID | Capacité | Question posée à DataStone & Enjeu pour One B2C | Statut DataStone (Oct. 2026) | Notre Positionnement & Résolution Architecturale |
|---|---|---|---|---|
| Q1 High |
Access Management | Question : Quel système est maître pour les accès sur Databricks (l'outil AM poussant les grants/masques dans Unity Catalog, ou défini dans UC et remonté) ? Comment éviter la double administration et à quelle granularité ? Enjeu : Sans cela, la gestion des accès reste manuelle et l'onboarding des pays est bloqué. |
Stream 3 en retard ; architecture cible non stabilisée (Okta parmi plusieurs options). | Approche ABAC pilotée par Contrat : Okta gère les groupes (SCIM). Collibra détient la Stratégie de Protection portée par les customProperties du contrat ODCS. dc43 pose automatiquement les Tags gouvernés dans Unity Catalog qui déclenchent les Row Filters (RLS) et Column Masks (CLS) sans double administration. |
| Q2 High |
Agent Identity & Rights | Question : Les agents agissent-ils au nom de l'utilisateur (OBO) ou avec leur propre identité de service ? AWS AgentCore est-il le standard S&EM pour les droits des agents, y compris sur Databricks ? Enjeu : Condition pour « une seule politique pour humains et agents ». |
AgentCore fait partie de l'architecture cible Talk to my Data (AM-03, ADR-12). | Double Identité (Service Identity + User OBO) : L'agent s'authentifie sur AgentCore Gateway avec son identité de service (pour l'audit), mais AgentCore Identity propage le jeton OAuth2 de l'utilisateur humain (OBO) jusqu'à Unity Catalog pour appliquer ses masques RLS/CLS exacts. |
| Q3 High |
Data Intelligence Engine | Question : Collibra supporte-t-il un modèle fédéré (extensions par domaine, mapping vers concepts S&EM, performance MCP pour les agents, lien aux actifs physiques) ? Quand le métamodèle est-il prêt et qui possède l'ontologie B2C ? Enjeu : Le principe du Federated Knowledge Graph dépend de la capacité de Collibra. |
Métamodèle Collibra non prêt ; ~500 termes documentés hors Collibra ; CDOs pressentis comme owners. | Sémantique à 2 niveaux (Apache Ossie) + Cache MCP : On formalise dès maintenant les ~500 termes en modèles Apache Ossie (Ontologie sur Aggregated, KPIs sur Consumer-Aligned) liés aux contrats ODCS. Synchronisation vers Collibra via dc43 dès que le métamodèle est prêt, et exposition basse latence aux agents MCP. |
| Q4 High |
Agentic & MCP | Question : Comment les agents et serveurs MCP de One B2C se branchent-ils dans le modèle DataStone (Supervisor Agent, connecteurs MCP, agent-to-agent) ? Y a-t-il une MCP Gateway partagée ? Enjeu : Réutiliser plutôt que reconstruire ; éviter la divergence signalée au Steerco. |
Risque de divergence avec des initiatives MCP / agents indépendantes noté (ADR-04). | Fédération via AgentCore MCP Gateway : One B2C enregistre ses serveurs MCP sur la Gateway AgentCore standard. Pour éviter le code ad-hoc divergent, les serveurs MCP Data sont générés/pilotés par les métadonnées (Contrats ODCS + Modèles Apache Ossie validés dans Collibra). |
| Q5 Medium |
Talk to my Data & LLM Access | Question : La Marketplace est le point d'entrée unique DataStone : la même capacité peut-elle être exposée dans Copilot Studio ? Confirmer AWS Bedrock comme chemin LLM (Genie non validé) et la migration des agents existants (Coach Facture). | Approche à aligner (désalignement signalé) ; stack AWS (AgentCore) retenue pour Talk to my Data. | Multi-canal MCP + Exécution UC Metric Views : Copilot Studio et la Marketplace consomment tous deux l'AgentCore MCP Gateway (propulsé par Bedrock). Sous le capot, Apache Ossie compile les KPIs en Unity Catalog Metric Views, réconciliant Bedrock (LLM) et Databricks (calcul SQL). |
| Q6 Medium |
Serving & Cache / APIs | Question : Comment le contrat de droits S&EM est-il appliqué sur les copies dérivées et les APIs en dehors de Unity Catalog ? Enjeu : Les Data Apps & APIs exposent des données clients à fort volume. |
Non couvert dans la documentation DataStone revue (AM-04, ADR-13). | Portabilité du Contrat ODCS : Comme la stratégie de protection (RLS/CLS/Consentement) est portée par le contrat ODCS du port (et non enfermée dans Unity Catalog), le déploiement via dc43 génère automatiquement les vues filtrées/politiques sur le Serving Store et l'API Gateway. |
| Q7 High |
Data Quality | Question : Great Expectations (GX) est-il formellement décidé comme outil DQ ? Si oui, comment tourne-t-il sur Databricks, comment les résultats sont-ils publiés vers Collibra / Marketplace, et quand GX Assistant est-il disponible ? | GX annoncé comme cible sans décision formelle ; GX Assistant sur Stream 4 ; éditeur DQ sur roadmap Marketplace. | Découplage Spécification (ODCS) / Moteur (DQX ou GX) : Les règles DQ sont écrites au standard ODCS. dc43-integrations les exécute dans Spark (via DQX ou GX sous le capot) et publie immédiatement les scorecards vers Collibra et la Marketplace sur DEV, UAT et PROD. |
| Q8 Medium |
Governance, Catalog & Lineage | Question : Confirmer Unity Catalog comme catalogue technique et source de lineage synchronisé avec Collibra via Edge. Qui possède le lineage externe (Informatica, Kafka, Nova) ? Quel timing face aux premiers Data Products B2C ? | Aucune décision formelle sur le lineage ; forte dépendance au delivery Collibra. | Double Lineage (Déclaratif ODPS/ODCS + Runtime UC) : N'attendons pas Collibra Edge pour documenter les flux externes (Kafka/Nova) : les Input/Output Ports des contrats ODCS/ODPS (dc43) portent le lineage inter-systèmes dès la phase de Build, complété par le lineage colonne d'Unity Catalog. |
| Q9 Medium |
Open Data Interoperability | Question : Confirmer Iceberg comme standard de partage entre Databricks, AWS SMUS et Microsoft Fabric. Comment l'interopérabilité Databricks ↔ SMUS sera-t-elle implémentée et gouvernée ? | SMUS natif Iceberg ; Fabric Delta ↔ Iceberg ; Databricks ↔ SMUS sur la roadmap DataStone. | Delta + UniForm (Iceberg) + UC Iceberg REST API : Activation de UniForm sur les ports Aggregated et Consumer-Aligned exposés via l'API Iceberg REST d'Unity Catalog (ou Delta Sharing si masquage dynamique requis). |
| Q10 Medium |
Unified Observability | Question : Datadog est-il disponible et licencié pour tous les pays B2C ? Est-il validé S&EM (gestion des logs) ? Peut-il couvrir la Data Observability ou faut-il un autre outil ? | Datadog retenu pour la supervision technique ; Data Observability et couverture pays restent ouverts. | Convergence Ops dans Datadog (Sondes Data → Cockpit Datadog) : Collibra n'est pas un moteur de télémétrie temps réel ! Pour éviter de séparer TechOps et DataOps, dc43 (contrôles de contrats/DQ) et Databricks Lakehouse Monitoring (drift/fraîcheur) jouent le rôle de sondes et poussent leurs métriques et événements (via OpenTelemetry, sans PII) dans Datadog pour corréler pannes infra et incidents data. Collibra ne reçoit que l'état de conformité synthétique (badge Vert/Rouge). |
| ➕ 6 Nouvelles Questions Architecturales à Ajouter au Revue DataStone (Angles Morts du Tableau Initial) | ||||
| Q11 New • High |
Gouvernance Multi-Environnements (DEV / UAT / PROD) | Question à ajouter : Comment Collibra et DataStone gèrent-ils le cycle de vie et les évolutions de versions des Data Products, Contrats et Règles Sémantiques en DEV et UAT (avant la mise en PROD) ? Enjeu : Si Collibra ne gouverne que la PROD, on découvre les ruptures de contrat et problèmes de privacy après la mise en production. |
Angle mort classique des déploiements Collibra Groupe (souvent connectés uniquement à la PROD). | Cycle de vie versionné par environnement (dc43 + Collibra) : Chaque Port de Data Product dans Collibra trace la version active du contrat ODCS par environnement (dev, uat, prod) et bloque la promotion CI/CD en cas de rupture de compatibilité aval. |
| Q12 New • High |
Interopérabilité Branches Snowflake & Sémantique | Question à ajouter : Au-delà de SMUS et Fabric (Q9), plusieurs branches sœurs utilisent Snowflake. Comment garantit-on non seulement la lecture des tables (Iceberg), mais surtout que les KPIs soient calculés avec la même règle métier entre Snowflake et Databricks ? | Snowflake et l'interopérabilité des formules de KPIs sont absents de Q9. | Fédération Iceberg REST + Apache Ossie : Lecture physique croisée via Iceberg REST / Lakehouse Federation, et compilation du même modèle Apache Ossie via ossie-converters vers Databricks (UC Metric Views) et Snowflake (Semantic Views / Cortex). |
| Q13 New • High |
Harnais d'Éligibilité IA (Coupe-Circuit DQ & Source-Aligned) | Question à ajouter : Quel mécanisme technique empêche un agent « Talk to my Data » d'interroger des tables Source-Aligned mal préparées ou un produit Consumer-Aligned dont le contrôle de Data Quality du jour a échoué ? | Aucun filtre d'éligibilité dynamique mentionné entre les couches Data et MCP. | Condition d'Accès MCP Strict : Le serveur MCP Sémantique / Collibra refuse toute requête LLM si : 1) product_type != consumer_aligned, 2) contract_status != active, ou 3) dq_score != passed. |
| Q14 New • Med |
Outillage d'Authoring IA (Contrats ODCS & Ossie) | Question à ajouter : Collibra n'étant pas un éditeur de contrats ODCS ni de modèles Apache Ossie, quel outil ergonomique assisté par IA est fourni aux DPO et Data Modelers pour concevoir ces spécifications sans écrire de YAML à la main ? | Seul un futur « DQ rules editor » est évoqué sur la roadmap Marketplace (Q7). | Studio Web d'Authoring (dc43-contracts-app + SDKs Python) : Interface web métier couplée à un assistant IA manipulant directement les objets Pydantic open-data-contract-standard et ossie.models synchronisés avec Collibra. |
| Q15 New • Med |
Modèle FinOps (Build vs Consommation & IA) | Question à ajouter : Lorsqu'un Data Product est consommé en Zero-Copy (Iceberg) par une autre branche ou interrogé via Talk to my Data (Bedrock), comment s'opère la séparation des coûts entre le domaine producteur et le consommateur ? | Boîte FinOps présente sur le schéma mais règles de refacturation inter-entités non définies. | Modèle Producteur / Consommateur découplé : Le domaine producteur paie le Build Spark et le stockage S3 ; chaque consommateur interroge le port avec son propre SQL Warehouse / Compute Snowflake et paie ses tokens Bedrock via les tags propagés par dc43/AgentCore. |
| Q16 New • Med |
Purge RGPD & Droit à l'Oubli de Bout en Bout | Question à ajouter : Comment les politiques de rétention et le droit à l'oubli RGPD (critiques en B2C) sont-ils propagés automatiquement depuis les produits Source-Aligned jusqu'aux produits Consumer-Aligned et au Serving Cache ? | Non mentionné dans le schéma initial. | Stratégie de Cycle de Vie pilotée par Contrat : Les clés client et durées de rétention déclarées dans les customProperties ODCS / Collibra pilotent les jobs automatisés de purge (Delta Deletion Vectors / Vacuum + invalidation du Serving Cache). |
Présenter soi-même les limites, coûts d'entrée et angles morts de son architecture en entretien démontre une maturité d'architecte senior.
dc43) en DEV, UAT et PROD.dc43-contracts-app réduit fortement cette friction).dc43.dc43-integrations pour détourner les événements non conformes au contrat ODCS sans arrêter le flux.dc43-service (et un cache MCP) sert de tampon haute disponibilité devant Collibra.