github.com/votre-nom/
├── votre-nom/                    # Repo special pour le profil README
│   └── README.md                 # Presentation personnelle
├── data-platform-e2e/            # Projet phare - plateforme complete
│   ├── README.md
│   ├── docs/
│   │   ├── architecture/
│   │   │   ├── c4-context.png
│   │   │   ├── c4-container.png
│   │   │   └── decisions/        # ADR (Architecture Decision Records)
│   │   ├── runbook/
│   │   └── api-specs/
│   ├── infrastructure/           # IaC (Terraform/Pulumi)
│   ├── ingestion/
│   ├── transformation/
│   ├── serving/
│   └── monitoring/
├── streaming-analytics/          # Projet real-time
├── data-mesh-poc/                # Proof of Concept Data Mesh
├── architecture-katas/           # Exercices d'architecture
└── blog-articles/                # Articles techniques

# 🏗️ Nom du Projet

> Une phrase qui resume l'objectif et la valeur du projet.

## 📋 Vue d'ensemble

**Contexte** : Probleme metier resolu
**Solution** : Approche architecturale choisie
**Stack** : Technologies principales utilisees
**Statut** : 🟢 Production / 🟡 En cours / 🔴 Prototype

## 🏛️ Architecture

![Architecture Diagram](docs/architecture/overview.png)

### Decisions Architecturales Cles
| Decision | Choix | Justification |
|----------|-------|---------------|
| Message Broker | Kafka | Throughput > 100K msg/s requis |
| Processing | Flink | Exactly-once semantics |
| Storage | Delta Lake | ACID + time travel |

## 🚀 Quick Start

```bash
# Cloner et demarrer
git clone https://github.com/user/project.git
docker-compose up -d
```

## 📊 Resultats & Metriques
- Latence p99 : < 200ms
- Throughput : 150K events/s
- Disponibilite : 99.95%

## 📝 Documentation
- [Architecture Decision Records](docs/adr/)
- [Runbook](docs/runbook/)
- [API Documentation](docs/api/)

## 🎥 Demo
[![Demo Video](docs/demo-thumbnail.png)](https://youtu.be/xxx)

# modules/ingestion/main.tf

module "kafka_cluster" {
  source = "./modules/kafka"

  cluster_name    = "ecommerce-prod"
  broker_count    = 3
  instance_type   = "kafka.m5.large"
  storage_per_broker = 500  # Go

  topics = {
    "raw.orders"     = { partitions = 12, retention_hours = 168 }
    "raw.clickstream" = { partitions = 24, retention_hours = 72 }
    "raw.inventory"  = { partitions = 6,  retention_hours = 168 }
    "raw.user_events" = { partitions = 12, retention_hours = 72 }
  }

  schema_registry = {
    enabled       = true
    compatibility = "BACKWARD"
  }
}

module "debezium_connectors" {
  source = "./modules/debezium"

  kafka_bootstrap = module.kafka_cluster.bootstrap_servers

  connectors = {
    "postgres-orders" = {
      database_hostname = var.orders_db_host
      database_name     = "orders"
      table_include_list = "public.orders,public.order_items,public.payments"
      snapshot_mode     = "initial"
      transforms        = "route"
      transforms_route_type = "org.apache.kafka.connect.transforms.RegexRouter"
    }
  }
}

module "airbyte" {
  source = "./modules/airbyte"

  connections = {
    "mongodb-catalog" = {
      source      = "mongodb"
      destination = "s3-raw"
      schedule    = "every 6 hours"
      streams     = ["products", "categories", "reviews"]
    }
    "api-partners" = {
      source      = "rest-api"
      destination = "s3-raw"
      schedule    = "daily"
    }
  }
}

-- models/silver/orders/stg_orders.sql
-- Nettoyage et standardisation des commandes

{{
  config(
    materialized='incremental',
    unique_key='order_id',
    partition_by={'field': 'order_date', 'data_type': 'date'},
    cluster_by=['country_code', 'status']
  )
}}

WITH source AS (
    SELECT * FROM {{ source('raw', 'orders') }}
    {% if is_incremental() %}
    WHERE _ingested_at > (SELECT MAX(_ingested_at) FROM {{ this }})
    {% endif %}
),

cleaned AS (
    SELECT
        order_id,
        customer_id,
        CAST(order_date AS DATE) AS order_date,
        UPPER(TRIM(country_code)) AS country_code,
        CASE
            WHEN status IN ('PAID', 'COMPLETED') THEN 'COMPLETED'
            WHEN status IN ('PENDING', 'PROCESSING') THEN 'IN_PROGRESS'
            WHEN status = 'CANCELLED' THEN 'CANCELLED'
            ELSE 'UNKNOWN'
        END AS order_status,
        ROUND(total_amount, 2) AS total_amount_eur,
        currency,
        _ingested_at
    FROM source
    WHERE order_id IS NOT NULL
      AND total_amount > 0
)

SELECT * FROM cleaned

# great_expectations/expectations/orders_suite.yml
expectation_suite_name: orders_quality_suite
expectations:
  - expectation_type: expect_column_values_to_not_be_null
    kwargs:
      column: order_id
    meta:
      severity: critical

  - expectation_type: expect_column_values_to_be_between
    kwargs:
      column: total_amount_eur
      min_value: 0.01
      max_value: 100000
    meta:
      severity: warning

  - expectation_type: expect_column_values_to_be_in_set
    kwargs:
      column: country_code
      value_set: ["FR", "DE", "ES", "IT", "NL", "BE"]
    meta:
      severity: critical

  - expectation_type: expect_table_row_count_to_be_between
    kwargs:
      min_value: 400000
      max_value: 700000
    meta:
      severity: warning
      notes: "Volume journalier attendu ~500K commandes"

public class TrendDetectionJob {

    public static void main(String[] args) throws Exception {
        StreamExecutionEnvironment env =
            StreamExecutionEnvironment.getExecutionEnvironment();

        // Exactly-once semantics
        env.enableCheckpointing(60000, CheckpointingMode.EXACTLY_ONCE);
        env.getCheckpointConfig().setMinPauseBetweenCheckpoints(30000);
        env.setParallelism(8);

        // Source Kafka
        KafkaSource<PageViewEvent> source = KafkaSource
            .<PageViewEvent>builder()
            .setBootstrapServers("kafka:9092")
            .setTopics("raw.pageviews")
            .setGroupId("trend-detection-v1")
            .setStartingOffsets(OffsetsInitializer.committedOffsets(
                OffsetResetStrategy.LATEST))
            .setDeserializer(new PageViewEventDeserializer())
            .build();

        DataStream<PageViewEvent> events = env
            .fromSource(source, WatermarkStrategy
                .<PageViewEvent>forBoundedOutOfOrderness(
                    Duration.ofSeconds(10))
                .withTimestampAssigner((event, ts) ->
                    event.getTimestamp()),
                "kafka-source");

        // Aggregation par article - fenetre tumbling de 1 minute
        DataStream<TrendMetric> trends = events
            .keyBy(PageViewEvent::getArticleId)
            .window(TumblingEventTimeWindows.of(Time.minutes(1)))
            .aggregate(new ViewCountAggregate(),
                       new TrendWindowFunction());

        // Detection des tendances virales
        DataStream<ViralAlert> viralAlerts = trends
            .keyBy(TrendMetric::getArticleId)
            .process(new ViralDetectionFunction(
                /* seuil croissance */ 3.0,  // 300% d'augmentation
                /* fenetre comparaison */ 5  // vs 5 dernieres minutes
            ));

        // Sink vers Druid + Kafka alertes
        trends.sinkTo(druidSink());
        viralAlerts.sinkTo(kafkaSink("alerts.viral-content"));

        env.execute("Trend Detection Pipeline v2.1");
    }
}

# server/realtime_dashboard.py
import asyncio
import json
from fastapi import FastAPI, WebSocket
from aiokafka import AIOKafkaConsumer

app = FastAPI()
connected_clients: set = set()

async def kafka_consumer():
    """Consomme les metriques aggregees et les diffuse aux clients."""
    consumer = AIOKafkaConsumer(
        'metrics.realtime-dashboard',
        bootstrap_servers='kafka:9092',
        group_id='dashboard-ws-server',
        value_deserializer=lambda m: json.loads(m.decode('utf-8'))
    )
    await consumer.start()
    try:
        async for msg in consumer:
            metric = msg.value
            # Diffuser a tous les clients connectes
            disconnected = set()
            for client in connected_clients:
                try:
                    await client.send_json({
                        "type": "metric_update",
                        "data": {
                            "timestamp": metric["window_end"],
                            "top_articles": metric["top_10_articles"],
                            "total_views_per_min": metric["view_count"],
                            "active_users": metric["unique_users"],
                            "viral_alerts": metric.get("viral", [])
                        }
                    })
                except Exception:
                    disconnected.add(client)
            connected_clients -= disconnected
    finally:
        await consumer.stop()

@app.websocket("/ws/dashboard")
async def dashboard_ws(websocket: WebSocket):
    await websocket.accept()
    connected_clients.add(websocket)
    try:
        while True:
            await websocket.receive_text()  # Keep-alive
    except Exception:
        connected_clients.discard(websocket)

@app.on_event("startup")
async def startup():
    asyncio.create_task(kafka_consumer())

# data-products/commerce/orders-dataset/contract.yaml
apiVersion: datamesh/v1
kind: DataProduct
metadata:
  name: orders-dataset
  domain: commerce
  owner: commerce-data-team
  version: "2.3.0"

spec:
  description: |
    Dataset des commandes consolide, incluant les items,
    paiements et statuts de livraison. Source de verite pour
    toutes les analyses liees aux ventes.

  sla:
    availability: 99.9%
    freshness: "5 minutes"
    latency_p99: "200ms"
    support_hours: "24/7"
    incident_response: "30 minutes"

  schema:
    format: delta-lake
    location: "s3://data-mesh/commerce/orders/gold/"
    columns:
      - name: order_id
        type: STRING
        description: "Identifiant unique de la commande"
        pii: false
        nullable: false
      - name: customer_id
        type: STRING
        description: "Identifiant client (pseudo-anonymise)"
        pii: true
        nullable: false
      - name: order_date
        type: TIMESTAMP
        description: "Date et heure de la commande"
        nullable: false
      - name: total_amount_eur
        type: DECIMAL(10,2)
        description: "Montant total en euros TTC"
        nullable: false
      - name: country_code
        type: STRING
        description: "Code pays ISO 3166-1 alpha-2"
        nullable: false

  quality:
    checks:
      - type: completeness
        column: order_id
        threshold: 100%
      - type: freshness
        max_delay: "10 minutes"
      - type: volume
        min_records_per_day: 400000
        max_records_per_day: 700000
      - type: uniqueness
        column: order_id
        threshold: 100%

  access:
    classification: internal
    pii_columns: [customer_id]
    approved_consumers:
      - domain: marketing
        purpose: "Attribution et analyse de campagnes"
      - domain: finance
        purpose: "Reporting revenue et comptabilite"
      - domain: supply-chain
        purpose: "Prevision de demande"

  output_ports:
    - type: delta-table
      location: "s3://data-mesh/commerce/orders/gold/"
      format: parquet
    - type: rest-api
      endpoint: "https://api.data.company.com/commerce/orders"
      auth: oauth2
    - type: kafka-topic
      topic: "mesh.commerce.orders.events"
      format: avro

# platform/modules/domain-workspace/main.tf
# Provisionne un espace de travail complet pour un domaine

variable "domain_name" { type = string }
variable "team_members" { type = list(string) }
variable "budget_limit_monthly" { type = number }

# Storage isole par domaine
resource "aws_s3_bucket" "domain_data" {
  bucket = "data-mesh-${var.domain_name}-${var.environment}"

  tags = {
    Domain      = var.domain_name
    ManagedBy   = "data-platform-team"
    CostCenter  = var.domain_name
  }
}

# Schema Registry dedie
resource "confluent_schema_registry_cluster" "domain_sr" {
  environment { id = var.confluent_env_id }
  package     = "ESSENTIALS"
  region {
    id   = "eu-west-1"
    cloud = "AWS"
  }
}

# Compute pour transformations
resource "databricks_workspace" "domain_workspace" {
  name                        = "ws-${var.domain_name}"
  managed_resource_group_name = "rg-${var.domain_name}-databricks"
  sku                         = "premium"

  custom_parameters {
    virtual_network_id = var.vnet_id
    budget_policy_id   = databricks_budget.domain.id
  }
}

# Budget alerting
resource "aws_budgets_budget" "domain_budget" {
  name         = "mesh-${var.domain_name}-monthly"
  budget_type  = "COST"
  limit_amount = var.budget_limit_monthly
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator = "GREATER_THAN"
    threshold           = 80
    threshold_type      = "PERCENTAGE"
    notification_type   = "ACTUAL"
    subscriber_email_addresses = var.team_members
  }
}

# Data catalog registration automatique
resource "datahub_dataset" "auto_register" {
  for_each = toset(var.published_datasets)

  platform = "delta-lake"
  name     = "${var.domain_name}.${each.value}"
  domain   = var.domain_name
  owners   = var.team_members
}

# Recherche sur GitHub
# URL: github.com/search?type=issues

# Issues pour debutants sur les projets data
label:"good first issue" repo:apache/kafka is:open
label:"good first issue" repo:apache/flink is:open
label:"help wanted" repo:apache/iceberg is:open
label:"good first issue" repo:dbt-labs/dbt-core is:open
label:"good first issue" repo:dagster-io/dagster is:open
label:"beginner friendly" repo:airbytehq/airbyte is:open

# Filtrer par type de contribution
label:"good first issue" label:"documentation" repo:apache/spark
label:"good first issue" label:"testing" repo:apache/airflow
label:"good first issue" label:"bug" repo:trinodb/trino

# Sites agreges utiles
# goodfirstissue.dev - Aggregation multi-projets
# up-for-grabs.net - Issues filtrees par langage
# github.com/MunGell/awesome-for-beginners - Liste curee

# 1. Fork et clone
gh repo fork apache/iceberg --clone
cd iceberg

# 2. Creer une branche descriptive
git checkout -b fix/partition-pruning-null-values

# 3. Configurer le remote upstream
git remote add upstream https://github.com/apache/iceberg.git
git fetch upstream

# 4. Synchroniser avec main avant de commencer
git rebase upstream/main

# 5. Effectuer les modifications
# ... editer le code ...

# 6. Lancer les tests locaux
./gradlew test -p core
./gradlew test -p spark

# 7. Verifier le style de code
./gradlew spotlessCheck

# 8. Commit avec message conventionnel
git commit -m "Core: Fix partition pruning for null values (#8234)

When a partition column contains null values, the pruning
logic incorrectly skipped the entire partition instead of
only pruning non-matching values.

Added test coverage for null partition values in both
identity and bucket transforms."

# 9. Push et creer la PR
git push origin fix/partition-pruning-null-values
gh pr create \
  --title "Core: Fix partition pruning for null values" \
  --body "Fixes #8234

## Changes
- Fixed null handling in PartitionPruning.java
- Added 3 test cases for null partition values

## Testing
- Unit tests pass locally
- Tested with Spark 3.5 integration tests"

mon-projet-oss/
├── .github/
│   ├── ISSUE_TEMPLATE/
│   │   ├── bug_report.md
│   │   ├── feature_request.md
│   │   └── question.md
│   ├── PULL_REQUEST_TEMPLATE.md
│   ├── workflows/
│   │   ├── ci.yml           # Tests automatiques
│   │   ├── release.yml      # Publication automatique
│   │   └── stale.yml        # Fermeture auto issues inactives
│   └── CODEOWNERS
├── docs/
│   ├── getting-started.md
│   ├── architecture.md
│   └── contributing.md
├── src/
├── tests/
├── CHANGELOG.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── LICENSE                   # Apache 2.0 ou MIT recommande
├── README.md
└── SECURITY.md

---
title: "Comment nous avons reduit notre cout Snowflake de 60%
        sans sacrifier la performance"
date: 2025-03-15
tags: [snowflake, cost-optimization, data-architecture]
reading_time: 8 min
---

## Le Probleme (Hook - 2 paragraphes max)
En 6 mois, notre facture Snowflake est passee de 8K a 22K EUR/mois.
Voici comment nous avons inverse la tendance.

## Contexte (Pour qui c'est pertinent)
- Volume: 500 Go/jour, 50+ utilisateurs BI
- Stack: Airbyte + dbt + Snowflake + Tableau
- Equipe: 3 data engineers, 2 analysts

## Diagnostic (Qu'avons-nous decouvert)
### 1. Warehouses surdimensionnes
[Tableau comparatif avant/apres]

### 2. Requetes non-optimisees
[Exemples de query plans, avec les couts]

### 3. Clustering absent
[Impact mesure sur les scans]

## Solution (Etape par etape)
### Etape 1: Resource Monitors
```sql
CREATE RESOURCE MONITOR cost_control
  WITH CREDIT_QUOTA = 100
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;
```

### Etape 2: Auto-suspend agressif
[Configuration + resultats]

### Etape 3: Clustering strategique
[Tables ciblees + metriques]

## Resultats (Chiffres concrets)
| Metrique | Avant | Apres | Gain |
|----------|-------|-------|------|
| Cout mensuel | 22K EUR | 8.5K EUR | -61% |
| Query p95 | 12s | 8s | -33% |

## Lecons Apprises (Takeaways)
1. Monitorer les couts des le jour 1
2. Chaque warehouse doit avoir un owner
3. [...]

## Ressources
- [Lien documentation Snowflake]
- [Repo GitHub avec les scripts]

Tache                      | CTO | Data Arch | Data Eng | Product | Legal
==========================================================================
Selection techno DWH        |  A  |     R     |    C     |    I    |   I
Modelisation donnees        |  I  |     A     |    R     |    C    |   I
Politique de securite       |  A  |     C     |    I     |    I    |   R
Definition SLA              |  A  |     R     |    C     |    C    |   I
Migration donnees           |  I  |     A     |    R     |    C    |   I
Choix outil BI              |  I  |     C     |    I     |    A    |   I
Conformite RGPD             |  A  |     C     |    I     |    I    |   R
Data Quality Rules          |  I  |     A     |    R     |    C    |   I
Budget annuel data          |  A  |     R     |    I     |    C    |   I
Formation equipes           |  I  |     R     |    C     |    C    |   I

Objet : [DECISION REQUISE] Migration Data Warehouse - Impact Budget Q3

Bonjour [Nom],

RECOMMANDATION : Approuver la migration vers Snowflake pour un Go-Live en Q3.

POURQUOI MAINTENANT :
- Le contrat Oracle expire en septembre (penalites si renouvellement tardif)
- Les couts actuels augmentent de 25% par an
- L'equipe produit est bloquee pour le lancement du nouveau dashboard

IMPACT BUSINESS :
- Economie de 340K EUR/an sur le TCO
- Requetes analytiques 10x plus rapides
- Time-to-market reduit de 60% pour les nouveaux use cases

RISQUES SI ON NE FAIT RIEN :
- Renouvellement Oracle : +180K EUR/an
- Perte de 2 data engineers frustres par l'outil actuel
- Retard de 6 mois sur la roadmap produit

DECISION DEMANDEE : Validation du budget de 120K EUR pour le projet de migration.

[Votre nom]
Data Architect

Competence              | Alice | Bob  | Clara | David | Lacune?
================================================================
SQL avance              |   5   |  4   |   5   |   3   |  Non
Python                  |   4   |  5   |   3   |   4   |  Non
Spark / Big Data        |   3   |  4   |   2   |   1   |  OUI
Cloud (AWS/GCP/Azure)   |   4   |  3   |   4   |   2   |  Non
dbt / Transformation    |   2   |  1   |   5   |   3   |  Non
Streaming (Kafka)       |   1   |  3   |   1   |   2   |  OUI !!
Data Modeling           |   5   |  2   |   4   |   3   |  Non
CI/CD / DevOps          |   2   |  4   |   1   |   5   |  Non
Communication Business  |   3   |  2   |   4   |   1   |  OUI
ML / Data Science       |   1   |  3   |   1   |   2   |  OUI

BUS FACTOR (competence < 2 chez tous sauf 1) : Streaming, ML
ACTION : Recruter un profil Streaming senior, former David en communication

Niveau 1 : Junior Data Engineer (0-2 ans)
  - Execute des taches definies par le senior
  - Ecrit des pipelines simples avec supervision
  - Apprend les standards de l'equipe
  - Participe aux code reviews

Niveau 2 : Data Engineer (2-4 ans)
  - Concoit et implemente des pipelines autonome
  - Contribue aux choix techniques de son perimetre
  - Mentorise les juniors
  - Ecrit de la documentation technique

Niveau 3 : Senior Data Engineer (4-7 ans)
  - Lead technique sur des projets complexes
  - Influence les standards de l'equipe
  - Conduit des POCs et evalue de nouvelles technos
  - Interagit directement avec les stakeholders

Niveau 4 : Staff Data Engineer (7-10 ans)
  - Impact cross-equipes
  - Definit des patterns architecturaux reutilisables
  - Mentorise les seniors
  - Contribue a la strategie technique de l'organisation

Niveau 5 : Principal Data Engineer (10+ ans)
  - Vision technique a l'echelle de l'entreprise
  - Influence la roadmap technologique
  - Reconnu en interne et en externe (conferences, publications)
  - Bras droit du CTO sur les sujets data

# ADR-007 : Utiliser Apache Iceberg comme format de table

## Statut
Accepte (2025-03-15)

## Contexte
Notre Data Lakehouse stocke actuellement 45 TB de donnees au format
Parquet brut sur S3. Nous rencontrons les problemes suivants :
- Pas de support ACID pour les mises a jour (MERGE)
- Time-travel impossible pour le debugging
- Schema evolution penible (ajout de colonnes = re-ecriture)
- Pas de partition evolution sans reprocessing complet

L'equipe Analytics demande la capacite de faire des requetes "as-of"
pour les rapports reglementaires. L'equipe Data Engineering passe
20% de son temps sur des workarounds lies a ces limitations.

## Decision
Nous utiliserons Apache Iceberg comme format de table pour le
Data Lakehouse, avec le catalogue Nessie pour la gestion des metadonnees.

## Alternatives considerees

### Delta Lake (Databricks)
- (+) Tres mature, large communaute
- (+) Integration native Spark
- (-) Fort couplage avec l'ecosysteme Databricks
- (-) Historique de licence ambigue (pre-open source)
- (-) Moins performant sur les engines non-Spark (Trino, Flink)

### Apache Hudi
- (+) Bon support pour les upserts en streaming
- (+) Bonne integration avec AWS (EMR, Glue)
- (-) Complexite operationnelle elevee
- (-) Communaute plus petite
- (-) API moins intuitive qu'Iceberg

### Rester en Parquet brut
- (+) Zero effort de migration
- (-) Ne resout aucun des problemes actuels
- (-) La dette technique continuera de croitre

## Consequences

### Positives
- Support ACID natif pour les operations MERGE
- Time-travel pour les rapports "as-of"
- Schema evolution sans re-ecriture des donnees
- Hidden partitioning = moins d'erreurs utilisateur
- Compatible avec Spark, Trino, Flink, Dremio

### Negatives
- Courbe d'apprentissage pour l'equipe (estimee a 3 semaines)
- Migration des tables existantes (estimee a 6 semaines)
- Complexite operationnelle supplementaire (compaction, expiration)
- Dependance a un catalogue (Nessie) a operer

### Neutres
- Les performances de lecture sont similaires a Parquet brut
- Le cout de stockage augmente de ~5% (metadata overhead)

## Participants
- Alice Martin (Data Architect) - Auteur
- Bob Dupont (Senior Data Engineer) - Reviewer
- Clara Petit (Analytics Engineer) - Consultee
- David Roux (CTO) - Approbateur

# LADR-023 : Adopter Ruff comme linter Python

**Statut :** Accepte | **Date :** 2025-04-01 | **Auteur :** Bob Dupont

**Contexte :** Nous utilisons actuellement flake8 + isort + black,
soit 3 outils a configurer et maintenir. Les CI prennent 45s juste
pour le linting.

**Decision :** Remplacer flake8 + isort + black par Ruff, qui combine
les 3 fonctionnalites en un seul outil 10-100x plus rapide.

**Consequences :** CI linting passe de 45s a 2s. Un seul fichier de
configuration (ruff.toml). Migration : 1 jour de travail.

# Decision Log - Data Platform

| ID      | Date       | Decision                          | Statut     |
|---------|------------|-----------------------------------|------------|
| ADR-001 | 2024-01-15 | Utiliser AWS comme cloud provider  | Accepte    |
| ADR-002 | 2024-02-01 | Adopter dbt pour les transformations| Accepte   |
| ADR-003 | 2024-03-10 | Format Avro pour les events Kafka  | Accepte    |
| ADR-004 | 2024-04-22 | PostgreSQL pour le metadata store  | Accepte    |
| ADR-005 | 2024-06-01 | Utiliser Airflow 2.x               | Supersede  |
| ADR-006 | 2024-09-15 | Migrer de Airflow vers Dagster     | Accepte    |
| ADR-007 | 2025-03-15 | Apache Iceberg comme format table  | Accepte    |
| LADR-023| 2025-04-01 | Ruff comme linter Python           | Accepte    |
| ADR-008 | 2025-05-20 | Schema Registry Confluent          | En cours   |

Statuts possibles : Propose | En cours | Accepte | Rejete | Supersede | Obsolete

# RFP - Solution de Data Integration

## 1. Presentation de l'entreprise
- Secteur, taille, contexte technologique
- Stack actuelle et ecosysteme

## 2. Contexte et objectifs
- Probleme a resoudre
- Volumes de donnees (actuel et projection a 3 ans)
- SLA requis (latence, disponibilite, throughput)

## 3. Exigences fonctionnelles
- Support des sources : SGBD, API, fichiers, streaming
- Transformation : SQL, Python, visual
- Monitoring et alerting
- Data Quality integre
- Lineage et catalogue

## 4. Exigences non-fonctionnelles
- Performance : X events/sec, latence < Y ms
- Scalabilite : de 100 GB a 10 TB sans re-architecture
- Securite : chiffrement, RBAC, audit logs
- Haute disponibilite : RPO/RTO
- Conformite : RGPD, SOC2

## 5. Exigences d'integration
- Compatibilite avec AWS / Snowflake / dbt
- API REST pour l'automatisation
- Support Terraform / IaC

## 6. Modele de licensing
- Tarification demandee (par utilisateur, par volume, flat)
- Couts caches a declarer (formation, support, migration)

## 7. Criteres d'evaluation et ponderation
- Fonctionnalites : 30%
- Performance : 20%
- Cout total (TCO 3 ans) : 20%
- Facilite d'utilisation : 15%
- Support et communaute : 15%

## 8. Planning
- Date limite de reponse : JJ/MM/AAAA
- Demo : semaine du JJ/MM
- POC : semaines XX-YY
- Decision finale : JJ/MM/AAAA

Critere                    | Poids | Vendor A | Vendor B | Vendor C
===================================================================
Performance (latence P99)  |  20%  |   8/10   |   9/10   |   6/10
Facilite d'installation    |  10%  |   9/10   |   5/10   |   8/10
Qualite documentation      |  10%  |   7/10   |   9/10   |   5/10
Support pendant le POC     |  10%  |   6/10   |   8/10   |   9/10
Integration stack existante|  15%  |   8/10   |   7/10   |   4/10
Scalabilite testee         |  15%  |   7/10   |   9/10   |   5/10
UX / Developer Experience  |  10%  |   9/10   |   6/10   |   7/10
Cout total (TCO 3 ans)     |  10%  |   7/10   |   5/10   |   9/10
-------------------------------------------------------------------
SCORE PONDERE              | 100%  |  7.65    |  7.40    |  6.30
CLASSEMENT                 |       |   #1     |   #2     |   #3

Critere                          | Poids | Build | Buy  | Score B | Score $
==========================================================================
Avantage competitif ?             |  25%  |  Si OUI → Build weighted
Produit mature disponible ?       |  20%  |  Si OUI → Buy weighted
Equipe pour maintenir ?           |  15%  |  Si OUI → Build possible
Time-to-market urgent ?           |  15%  |  Si OUI → Buy weighted
TCO 3 ans                        |  15%  |  Calculer les deux
Risque de lock-in                 |  10%  |  Si eleve → Build weighted

EXEMPLE CONCRET : Outil de Data Quality
─────────────────────────────────────────
Avantage competitif ?      → Non (pas differenciateur)         → Buy
Produit mature ?           → Oui (Great Expectations, Soda)    → Buy
Equipe disponible ?        → Non (equipe surchargee)           → Buy
Time-to-market ?           → Urgent (audit en 3 mois)          → Buy
TCO 3 ans Build            → 450K EUR (dev + maintenance)
TCO 3 ans Buy              → 180K EUR (licence + integration)  → Buy
Lock-in ?                  → Faible (formats standards)         → Buy

DECISION : ACHETER (score unanime sur tous les criteres)

Dimension              | Niveau 1      | Niveau 2     | Niveau 3     | Niveau 4      | Niveau 5
                       | Ad Hoc        | Emergent     | Defini       | Gere          | Optimise
================================================================================================
Gouvernance            | Aucune regle  | Regles       | Politique    | Stewards      | Gouvernance
                       |               | informelles  | documentee   | actifs        | automatisee
-----------------------------------------------------------------------------------------------
Qualite des donnees    | Pas de        | Controles    | Rules        | Monitoring    | ML-powered
                       | controle      | manuels      | automatisees | proactif      | anomaly det.
-----------------------------------------------------------------------------------------------
Architecture           | Silos         | DWH central  | Data Lake    | Lakehouse     | Data Mesh
                       | departementaux| + quelques   | + catalogue  | + gouvernance | federe
                       |               | ETL          |              | unifiee       |
-----------------------------------------------------------------------------------------------
Equipe                 | 0-1 personne  | Petite equipe| Equipe       | Equipe        | Centre
                       | a temps       | centralisee  | structuree   | specialisee   | d'excellence
                       | partiel       |              | avec roles   | multi-profils | data
-----------------------------------------------------------------------------------------------
Culture Data           | Data =        | Quelques     | KPIs data    | Data-informed | Data-driven
                       | afterthought  | champions    | dans les     | decision      | a tous les
                       |               | data         | revues       | making        | niveaux
-----------------------------------------------------------------------------------------------
Self-Service           | Aucun         | Exports      | Dashboards   | Catalogue     | Data
                       |               | CSV manuels  | BI           | + requetes    | marketplace
                       |               |              |              | self-service  |

EXEMPLE D'ASSESSMENT :
Votre entreprise : Gouvernance=2, Qualite=1, Archi=3, Equipe=3, Culture=2, Self-Service=2
Moyenne : 2.2 / 5 → Niveau "Emergent" avec des poches de maturite

# Vision Data 2026-2029

## Mission
Faire de la donnee un actif strategique qui accelere la prise de
decision a tous les niveaux de l'organisation, en garantissant la
qualite, la securite et l'accessibilite des donnees.

## Principes directeurs
1. Data as a Product : chaque dataset a un owner, un SLA, et une doc
2. Self-Service First : 80% des besoins analytiques resolus sans ticket
3. Quality by Design : la qualite est integree dans les pipelines, pas ajoutee apres
4. Cloud-Native : infrastructure elastique, pay-as-you-go
5. Privacy by Default : RGPD et securite sont des prerequis, pas des ajouts

## Etat cible (a 3 ans)
- Gouvernance : Niveau 4 (stewards actifs dans chaque domaine)
- Qualite : Niveau 4 (monitoring proactif, SLA sur les datasets)
- Architecture : Niveau 4 (Lakehouse federe avec gouvernance unifiee)
- Equipe : Niveau 4 (20+ personnes, specialisees par domaine)
- Culture : Niveau 4 (data-informed decision making generalise)
- Self-Service : Niveau 4 (catalogue + requetes self-service)

## Alignement Business
- Objectif business #1 : Croissance revenus de 25% →
  Initiative data : Recommandation ML personnalisee
- Objectif business #2 : Reduction des couts de 15% →
  Initiative data : Optimisation supply chain par analytics
- Objectif business #3 : Compliance reglementaire →
  Initiative data : Lineage et audit automatises

ANNEE 1 : FONDATIONS (Build the Base)
======================================
Q1 │ Migration DWH vers Snowflake
   │ Mise en place CI/CD pour les pipelines dbt
   │ Recrutement : +2 Data Engineers, +1 Analytics Engineer
   │
Q2 │ Deploiement Data Catalogue (ex: DataHub)
   │ Definition Data Quality Rules pour les 10 datasets critiques
   │ Formation SQL pour les Product Managers
   │
Q3 │ Mise en place streaming Kafka pour les events temps-reel
   │ Implementation Data Contracts v1
   │ Gouvernance : nomination des Data Stewards par domaine
   │
Q4 │ Self-Service BI : migration Looker → Preset / Superset
   │ Premier Data Quality Dashboard
   │ Bilan annee 1 et ajustement roadmap

ANNEE 2 : ACCELERATION (Scale Up)
==================================
Q1 │ Data Mesh : decoupage en domaines (Marketing, Finance, Product)
   │ Chaque domaine a son Data Product Manager
   │
Q2 │ ML Platform v1 : MLflow + Feature Store
   │ Premier modele ML en production (churn prediction)
   │
Q3 │ Real-time Analytics : dashboards streaming
   │ Data Marketplace interne pour le self-service avance
   │
Q4 │ Reverse ETL : donnees actionnables dans les outils metier
   │ Recrutement : +1 Data Scientist, +1 ML Engineer
   │ Bilan annee 2

ANNEE 3 : EXCELLENCE (Optimize & Innovate)
==========================================
Q1 │ DataOps avance : observabilite E2E, incident response automatise
   │ Data Quality ML-powered (detection d'anomalies automatique)
   │
Q2 │ GenAI : chatbot data interne (Text-to-SQL)
   │ Data Literacy programme pour toute l'entreprise
   │
Q3 │ Advanced Analytics : prescriptive analytics, optimisation
   │ Centre d'Excellence Data formalise
   │
Q4 │ Bilan complet 3 ans
   │ Definition de la vision 2029-2032

COUTS                              | Annee 1   | Annee 2   | Annee 3   | Total
================================================================================
PERSONNEL
  Data Architect (1)               |   120K    |   125K    |   130K    |   375K
  Data Engineers (3→5→6)           |   270K    |   450K    |   540K    | 1,260K
  Analytics Engineers (1→2→3)      |    90K    |   180K    |   270K    |   540K
  Data Scientist (0→1→2)           |     0K    |   110K    |   220K    |   330K
  Data Product Manager (0→1→2)     |     0K    |   100K    |   200K    |   300K
  ───────────────────────────────────────────────────────────────────────────────
  Sous-total Personnel             |   480K    |   965K    | 1,360K    | 2,805K

INFRASTRUCTURE (Cloud)
  Compute (Snowflake/Spark)        |   120K    |   200K    |   250K    |   570K
  Stockage (S3/GCS)               |    30K    |    50K    |    70K    |   150K
  Streaming (Kafka/Confluent)      |    40K    |    60K    |    80K    |   180K
  ───────────────────────────────────────────────────────────────────────────────
  Sous-total Infrastructure        |   190K    |   310K    |   400K    |   900K

OUTILS & LICENCES
  BI Tool (Preset/Looker)          |    30K    |    45K    |    60K    |   135K
  Data Catalogue (DataHub)         |    15K    |    20K    |    25K    |    60K
  Orchestration (Dagster Cloud)    |    20K    |    30K    |    40K    |    90K
  Monitoring (Monte Carlo)         |    25K    |    35K    |    45K    |   105K
  ───────────────────────────────────────────────────────────────────────────────
  Sous-total Outils                |    90K    |   130K    |   170K    |   390K

FORMATION & CONSEIL
  Formations certifiantes          |    30K    |    25K    |    20K    |    75K
  Consulting externe               |    60K    |    30K    |    15K    |   105K
  ───────────────────────────────────────────────────────────────────────────────
  Sous-total Formation             |    90K    |    55K    |    35K    |   180K

================================================================================
TOTAL                              |   850K    | 1,460K    | 1,965K    | 4,275K

ROI ESTIME
  Revenus additionnels (ML/reco)   |     0K    |   200K    |   800K    | 1,000K
  Economies operationnelles        |    50K    |   200K    |   400K    |   650K
  Reduction risques compliance     |   100K    |   150K    |   200K    |   450K
  ───────────────────────────────────────────────────────────────────────────────
  TOTAL ROI                        |   150K    |   550K    | 1,400K    | 2,100K

  Payback period : ~28 mois
  ROI a 3 ans : 49% ((2,100 - 4,275 + valeur residuelle) / investissement)