🎯 Leadership & Trade-offs in Data Engineering

Bienvenue dans ce module final où tu vas développer les soft skills et la pensée stratégique qui distinguent un Data Engineer Senior d’un Staff/Principal Engineer. Ce n’est plus seulement “comment coder” mais “comment décider, communiquer et influencer”.

Prérequis

Niveau	Compétence
✅ Requis	Tous les modules techniques (M01-M34)
✅ Requis	Expérience en équipe data
💡 Recommandé	Avoir géré des projets ou mentoré

🎯 Objectifs du module

À la fin de ce module, tu seras capable de :

Naviguer les trade-offs techniques avec confiance
Communiquer efficacement avec différents stakeholders
Rédiger une documentation technique de qualité
Estimer des projets data réalistement
Gérer les incidents et post-mortems
Comprendre les career paths en Data Engineering

1. L’Art des Trade-offs

1.1 Pourquoi les Trade-offs sont Inévitables

┌─────────────────────────────────────────────────────────────────────────────┐
│                    LA RÉALITÉ DE L'ENGINEERING                              │
│                                                                             │
│   "Il n'y a pas de solution parfaite, seulement des trade-offs."           │
│                                                                             │
│   Chaque décision technique implique :                                      │
│                                                                             │
│   • Gagner quelque chose                                                    │
│   • Perdre quelque chose d'autre                                            │
│   • Accepter des risques                                                    │
│                                                                             │
│   Le rôle du Senior/Staff Engineer :                                        │
│                                                                             │
│   ❌ Trouver la solution parfaite (n'existe pas)                            │
│   ✅ Identifier les trade-offs                                              │
│   ✅ Choisir consciemment ce qu'on sacrifie                                 │
│   ✅ Communiquer ces choix clairement                                       │
└─────────────────────────────────────────────────────────────────────────────┘

1.2 Les Trade-offs Fondamentaux

┌─────────────────────────────────────────────────────────────────────────────┐
│                    TRADE-OFF #1 : COST vs PERFORMANCE                       │
│                                                                             │
│   Performance                                                               │
│       ▲                                                                     │
│       │         ┌─────────────────┐                                        │
│       │        ╱                   │                                        │
│       │       ╱   Zone optimale    │                                        │
│       │      ╱    (sweet spot)     │                                        │
│       │     ╱                      │                                        │
│       │────╱───────────────────────┘                                        │
│       │   ╱                                                                 │
│       │  ╱  Diminishing returns                                            │
│       │ ╱   (plus de $ = peu de gain)                                      │
│       └──────────────────────────────────▶ Cost                            │
│                                                                             │
│   QUESTIONS À POSER :                                                       │
│   • Quel est le coût d'une seconde de latence en plus ?                    │
│   • Le business justifie-t-il 2x le budget pour 20% de perf ?              │
│   • Peut-on optimiser le code avant d'ajouter des resources ?              │
└─────────────────────────────────────────────────────────────────────────────┘

1.3 CAP Theorem : Consistency vs Availability

┌─────────────────────────────────────────────────────────────────────────────┐
│                    CAP THEOREM                                              │
│                                                                             │
│   Dans un système distribué, tu ne peux avoir que 2 sur 3 :                │
│                                                                             │
│                         Consistency                                         │
│                             ▲                                               │
│                            ╱ ╲                                              │
│                           ╱   ╲                                             │
│                          ╱     ╲                                            │
│                         ╱  CA   ╲                                           │
│                        ╱ (RDBMS) ╲                                          │
│                       ╱───────────╲                                         │
│                      ╱             ╲                                        │
│                     ╱    CP    AP   ╲                                       │
│                    ╱  (HBase) (Cass) ╲                                      │
│                   ▼─────────────────────▼                                   │
│             Partition                 Availability                          │
│             Tolerance                                                       │
│                                                                             │
│   EN PRATIQUE (systèmes distribués = P obligatoire) :                      │
│                                                                             │
│   CP (Consistency + Partition Tolerance)                                   │
│   • Données toujours cohérentes                                            │
│   • Peut refuser des requêtes si partition                                 │
│   • Ex: HBase, MongoDB (strong consistency), Zookeeper                     │
│   • Use case: Transactions financières, inventory                          │
│                                                                             │
│   AP (Availability + Partition Tolerance)                                  │
│   • Toujours disponible                                                    │
│   • Données peuvent être temporairement incohérentes                       │
│   • Ex: Cassandra, DynamoDB, CouchDB                                       │
│   • Use case: Social feeds, analytics, caching                             │
└─────────────────────────────────────────────────────────────────────────────┘

1.4 Latency vs Throughput

┌─────────────────────────────────────────────────────────────────────────────┐
│                    LATENCY vs THROUGHPUT                                    │
│                                                                             │
│   LATENCY = Temps pour traiter UNE requête                                 │
│   THROUGHPUT = Nombre de requêtes par seconde                              │
│                                                                             │
│   ┌─────────────────────────────────────────────────────────────────────┐  │
│   │                                                                     │  │
│   │   OPTIMISER LATENCY :              OPTIMISER THROUGHPUT :           │  │
│   │   • Moins de batch size            • Plus de batch size             │  │
│   │   • Plus de parallélisme           • Moins de parallélisme          │  │
│   │   • Caching agressif               • Traitement en bulk             │  │
│   │   • Moins de network hops          • Compression                    │  │
│   │                                                                     │  │
│   │   Use case:                        Use case:                        │  │
│   │   API real-time, gaming            ETL batch, data migration        │  │
│   │                                                                     │  │
│   └─────────────────────────────────────────────────────────────────────┘  │
│                                                                             │
│   💡 EXEMPLE SPARK :                                                        │
│   • Streaming micro-batch 100ms = Low latency, lower throughput            │
│   • Batch job hourly = High latency, maximum throughput                    │
└─────────────────────────────────────────────────────────────────────────────┘

1.5 Flexibility vs Simplicity

┌─────────────────────────────────────────────────────────────────────────────┐
│                    FLEXIBILITY vs SIMPLICITY                                │
│                                                                             │
│   FLEXIBLE (ex: Spark sur K8s)          SIMPLE (ex: BigQuery)              │
│   ────────────────────────              ────────────────────                │
│                                                                             │
│   ✅ Customisation totale               ✅ Rapide à démarrer               │
│   ✅ Multi-cloud possible               ✅ Peu d'ops                        │
│   ✅ Pas de vendor lock-in              ✅ Équipe peut se focus sur data   │
│                                                                             │
│   ❌ Complexité ops élevée              ❌ Vendor lock-in                   │
│   ❌ Expertise requise                  ❌ Moins de contrôle                │
│   ❌ Time-to-market plus long           ❌ Coûts peuvent exploser           │
│                                                                             │
│   QUAND CHOISIR QUOI :                                                      │
│                                                                             │
│   Startup, MVP, petite équipe     →     Simple (managed services)          │
│   Scale-up, équipe expérimentée   →     Flexible (mais progressif)         │
│   Enterprise, compliance stricte  →     Dépend du contexte                 │
└─────────────────────────────────────────────────────────────────────────────┘

1.6 Build vs Buy vs Open Source

┌─────────────────────────────────────────────────────────────────────────────┐
│                    BUILD vs BUY vs OPEN SOURCE                              │
│                                                                             │
│   ┌───────────────┬───────────────┬───────────────┐                        │
│   │     BUILD     │      BUY      │  OPEN SOURCE  │                        │
│   ├───────────────┼───────────────┼───────────────┤                        │
│   │ Custom code   │ Snowflake     │ Spark         │                        │
│   │ Internal tool │ Databricks    │ Airflow       │                        │
│   │               │ Fivetran      │ Kafka         │                        │
│   ├───────────────┼───────────────┼───────────────┤                        │
│   │ ✅ 100% fit   │ ✅ Fast start │ ✅ No license │                        │
│   │ ✅ Full control│ ✅ Support   │ ✅ Community  │                        │
│   │ ❌ Time/cost  │ ❌ $$$        │ ❌ Ops burden │                        │
│   │ ❌ Maintenance│ ❌ Lock-in    │ ❌ No SLA     │                        │
│   └───────────────┴───────────────┴───────────────┘                        │
│                                                                             │
│   FRAMEWORK DE DÉCISION :                                                   │
│                                                                             │
│   1. Est-ce un avantage compétitif ?                                       │
│      OUI → Consider BUILD                                                  │
│      NON → BUY ou OPEN SOURCE                                              │
│                                                                             │
│   2. Budget disponible ?                                                    │
│      Élevé + pas d'ops → BUY                                               │
│      Limité + équipe ops → OPEN SOURCE                                     │
│                                                                             │
│   3. Time-to-market critique ?                                             │
│      OUI → BUY                                                             │
│      NON → Évaluer toutes les options                                      │
└─────────────────────────────────────────────────────────────────────────────┘

Voir le code

# Outil : Trade-off Decision Matrix

def evaluate_tradeoffs(options: dict, criteria: dict) -> None:
    """
    Évalue des options selon des critères avec trade-offs explicites.
    
    options: {"Option A": {"cost": 3, "perf": 5, ...}, ...}
    criteria: {"cost": {"weight": 4, "direction": "lower"}, ...}
    """
    print("═" * 70)
    print("TRADE-OFF ANALYSIS")
    print("═" * 70)
    
    # Header
    header = f"{'Criterion':<20} {'Weight':<8}"
    for opt in options:
        header += f" {opt:<12}"
    print(header)
    print("-" * 70)
    
    scores = {opt: 0 for opt in options}
    
    for crit, config in criteria.items():
        weight = config['weight']
        direction = config.get('direction', 'higher')  # higher is better by default
        
        row = f"{crit:<20} {weight:<8}"
        for opt, values in options.items():
            val = values.get(crit, 0)
            # Adjust score based on direction
            adjusted = val if direction == 'higher' else (6 - val)
            scores[opt] += adjusted * weight
            row += f" {val:<12}"
        print(row)
    
    print("-" * 70)
    
    # Weighted scores
    score_row = f"{'WEIGHTED SCORE':<20} {'':<8}"
    for opt in options:
        score_row += f" {scores[opt]:<12}"
    print(score_row)
    
    # Winner
    winner = max(scores, key=scores.get)
    print(f"\n✅ Recommended: {winner} (score: {scores[winner]})")
    
    # Trade-offs summary
    print(f"\n⚠️  TRADE-OFFS TO ACCEPT:")
    for crit, config in criteria.items():
        winner_val = options[winner].get(crit, 0)
        best_val = max(options[opt].get(crit, 0) for opt in options)
        if winner_val < best_val and config.get('direction', 'higher') == 'higher':
            best_opt = [opt for opt in options if options[opt].get(crit, 0) == best_val][0]
            print(f"   • {crit}: {winner} ({winner_val}) < {best_opt} ({best_val})")

# Exemple : Choisir une solution de Data Warehouse
options = {
    "BigQuery": {"cost": 2, "performance": 5, "flexibility": 2, "ops_burden": 5, "learning_curve": 4},
    "Snowflake": {"cost": 2, "performance": 5, "flexibility": 3, "ops_burden": 5, "learning_curve": 4},
    "Spark+Delta": {"cost": 4, "performance": 4, "flexibility": 5, "ops_burden": 2, "learning_curve": 2},
    "Redshift": {"cost": 3, "performance": 4, "flexibility": 2, "ops_burden": 4, "learning_curve": 4},
}

criteria = {
    "cost": {"weight": 3, "direction": "higher"},  # higher = cheaper
    "performance": {"weight": 4, "direction": "higher"},
    "flexibility": {"weight": 2, "direction": "higher"},
    "ops_burden": {"weight": 4, "direction": "higher"},  # higher = less burden
    "learning_curve": {"weight": 2, "direction": "higher"},  # higher = easier
}

evaluate_tradeoffs(options, criteria)

2. Communication avec les Stakeholders

2.1 Adapter son Message

┌─────────────────────────────────────────────────────────────────────────────┐
│                    ADAPTER LE MESSAGE AU PUBLIC                             │
│                                                                             │
│   EXECUTIVES (CEO, CFO, VP)                                                │
│   ─────────────────────────                                                │
│   Ce qu'ils veulent :          Comment communiquer :                       │
│   • Impact business            • 1 slide max                               │
│   • ROI, coûts                 • Chiffres business (€, %, users)           │
│   • Timeline                   • Recommandation claire                     │
│   • Risques majeurs            • Pas de jargon technique                   │
│                                                                             │
│   PRODUCT MANAGERS                                                          │
│   ────────────────                                                          │
│   Ce qu'ils veulent :          Comment communiquer :                       │
│   • Feasibility                • Options avec trade-offs                   │
│   • Timeline réaliste          • Ce qui est possible vs impossible         │
│   • Dépendances                • User impact                               │
│   • Flexibilité                • Alternatives si deadline serrée          │
│                                                                             │
│   AUTRES ENGINEERS                                                          │
│   ────────────────                                                          │
│   Ce qu'ils veulent :          Comment communiquer :                       │
│   • Détails techniques         • Architecture diagrams                     │
│   • Pourquoi ce choix          • Code examples                             │
│   • Comment ça marche          • Documentation détaillée                   │
│   • Impact sur leur travail    • ADRs                                      │
└─────────────────────────────────────────────────────────────────────────────┘

2.2 Le Framework “Bottom Line Up Front” (BLUF)

Voir le code

# Exemple de communication BLUF

bad_communication = """
❌ MAUVAIS EXEMPLE (enterrer le lead) :

"Alors on a analysé plusieurs options pour le data warehouse. 
On a regardé Snowflake qui a des bonnes performances mais coûte cher.
On a aussi regardé BigQuery qui est bien intégré avec GCP.
Et puis il y a Redshift mais on n'est pas sur AWS.
Après avoir comparé les coûts, les performances, la facilité d'utilisation...
[10 minutes plus tard]
...donc on recommande Snowflake."

Problème : Le destinataire ne sait pas où on va pendant 10 minutes.
"""

good_communication = """
✅ BON EXEMPLE (BLUF) :

"Je recommande Snowflake pour notre data warehouse. Budget : $50K/an.

Pourquoi Snowflake :
• Meilleur rapport coût/performance pour notre volume (10TB)
• Équipe déjà formée sur SQL, courbe d'apprentissage minimale
• Auto-scaling = pas de gestion d'infrastructure

Alternatives considérées :
• BigQuery : similaire mais on n'est pas sur GCP
• Spark+Delta : moins cher mais 3 mois de setup, besoin d'ops

Trade-off accepté : vendor lock-in Snowflake

Next step : Validation budget avec Finance cette semaine."

Pourquoi c'est mieux :
• Conclusion en premier
• Chiffres concrets
• Alternatives mentionnées
• Trade-off explicite
• Action claire
"""

print(bad_communication)
print("=" * 70)
print(good_communication)

2.3 L’Art de Dire Non (Constructivement)

┌─────────────────────────────────────────────────────────────────────────────┐
│                    DIRE NON (SANS DIRE NON)                                 │
│                                                                             │
│   ❌ "Non, c'est pas possible."                                            │
│   ❌ "Ça va prendre trop de temps."                                        │
│   ❌ "Le système ne peut pas faire ça."                                    │
│                                                                             │
│   ✅ "Oui, ET voici ce que ça implique..."                                 │
│   ✅ "Oui, MAIS il faudra choisir entre X et Y."                           │
│   ✅ "Voici 3 options avec leurs trade-offs..."                            │
│                                                                             │
│   ─────────────────────────────────────────────────────────────────────    │
│                                                                             │
│   EXEMPLE :                                                                 │
│                                                                             │
│   PM: "On a besoin du dashboard real-time pour lundi."                     │
│                                                                             │
│   ❌ "Impossible, on n'a pas le temps."                                    │
│                                                                             │
│   ✅ "Pour lundi, je vois 3 options :                                       │
│                                                                             │
│      Option A : Dashboard real-time complet                                │
│      → 3 semaines, besoin de 2 engineers                                   │
│                                                                             │
│      Option B : Dashboard avec refresh toutes les 5 minutes                │
│      → Possible pour lundi, 90% des besoins couverts                       │
│                                                                             │
│      Option C : Métriques clés seulement, reste en V2                      │
│      → Lundi OK, on itère ensuite                                          │
│                                                                             │
│      Je recommande Option B. Qu'en penses-tu ?"                            │
└─────────────────────────────────────────────────────────────────────────────┘

2.4 Gérer les Conflits Techniques

┌─────────────────────────────────────────────────────────────────────────────┐
│                    RÉSOUDRE LES DÉSACCORDS TECHNIQUES                       │
│                                                                             │
│   ÉTAPE 1 : Comprendre l'autre position                                    │
│   ─────────────────────────────────────                                    │
│   • "Aide-moi à comprendre pourquoi tu préfères X ?"                       │
│   • "Quelles sont tes concerns avec mon approche ?"                        │
│   • Écouter vraiment, pas juste attendre son tour                          │
│                                                                             │
│   ÉTAPE 2 : Trouver le terrain commun                                      │
│   ─────────────────────────────────────                                    │
│   • "On est d'accord que l'objectif est Y, correct ?"                      │
│   • "On veut tous les deux éviter Z."                                      │
│                                                                             │
│   ÉTAPE 3 : Proposer un test                                               │
│   ───────────────────────────                                              │
│   • "Et si on faisait un PoC de 2 jours pour comparer ?"                   │
│   • "Définissons les critères de succès ensemble."                         │
│                                                                             │
│   ÉTAPE 4 : Disagree and commit                                            │
│   ─────────────────────────────                                            │
│   • Si pas de consensus : escalader ou time-box la décision                │
│   • Une fois décidé : supporter la décision à 100%                         │
│   • "Je n'étais pas d'accord mais je m'engage à faire réussir."            │
└─────────────────────────────────────────────────────────────────────────────┘

3. Documentation Technique

3.1 Types de Documentation

┌─────────────────────────────────────────────────────────────────────────────┐
│                    PYRAMID OF DOCUMENTATION                                 │
│                                                                             │
│                         ┌───────────┐                                      │
│                         │  Vision   │  ← Pourquoi on fait ça               │
│                         │  (ADRs)   │    (rarement mis à jour)             │
│                        ─┴───────────┴─                                     │
│                       ╱               ╲                                    │
│                      ╱   Architecture  ╲  ← Comment c'est structuré        │
│                     ╱    (Diagrams)     ╲   (mis à jour trimestriel)       │
│                    ─┴───────────────────┴─                                 │
│                   ╱                       ╲                                │
│                  ╱     How-to Guides       ╲  ← Comment faire X            │
│                 ╱      (Runbooks)           ╲   (mis à jour régulier)      │
│                ─┴───────────────────────────┴─                             │
│               ╱                               ╲                            │
│              ╱         API / Code Docs         ╲  ← Détails techniques    │
│             ╱          (Docstrings)             ╲   (auto-généré si poss.) │
│            ─┴───────────────────────────────────┴─                         │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

3.2 Template README Projet Data

Voir le code

# Template README pour projet Data Engineering

readme_template = """
# 📊 [Nom du Projet]

> [Une phrase qui explique ce que fait le projet]

## 🎯 Overview

[2-3 phrases sur le problème résolu et la solution]

### Key Features
- ✅ [Feature 1]
- ✅ [Feature 2]
- ✅ [Feature 3]

## 🏗️ Architecture

```
[Diagram ASCII simple ou lien vers image]

Source → Kafka → Spark → Delta Lake → Dashboard
```

**Stack technique :**
- Ingestion : [Kafka, Fivetran, etc.]
- Processing : [Spark, dbt, etc.]
- Storage : [S3 + Delta Lake, Snowflake, etc.]
- Orchestration : [Airflow, Dagster, etc.]

## 🚀 Quick Start

### Prerequisites
- Python 3.9+
- Docker
- [Autres dépendances]

### Installation
```bash
git clone [repo]
cd [project]
make setup  # ou pip install -r requirements.txt
```

### Run locally
```bash
make run  # ou docker-compose up
```

## 📁 Project Structure

```
├── src/                 # Code source
│   ├── ingestion/       # Jobs d'ingestion
│   ├── transformations/ # Transformations Spark/dbt
│   └── serving/         # APIs, exports
├── dags/                # Airflow DAGs
├── tests/               # Tests
├── docs/                # Documentation
│   └── architecture/    # ADRs
├── docker-compose.yaml
└── Makefile
```

## 🔧 Configuration

| Variable | Description | Default |
|----------|-------------|----------|
| `DATABASE_URL` | Connection string | `localhost` |
| `KAFKA_BROKERS` | Kafka brokers | `localhost:9092` |

## 📊 Data Model

[Lien vers documentation du data model ou schéma simplifié]

## 🧪 Testing

```bash
make test        # Unit tests
make test-e2e    # End-to-end tests
```

## 🚢 Deployment

```bash
make deploy-staging
make deploy-prod
```

## 📈 Monitoring

- Dashboards : [lien Grafana]
- Alerts : [lien PagerDuty/Slack]
- Logs : [lien Datadog/CloudWatch]

## 🆘 Troubleshooting

### Common issues

**Problem:** [Description]
```
Solution: [Commande ou explication]
```

## 👥 Team

- Owner : [Équipe/Personne]
- Slack : #[channel]
- On-call : [rotation]

## 📚 Related Documentation

- [ADR-001: Choix de Kafka](docs/architecture/decisions/001-kafka.md)
- [Runbook: Incident Pipeline](docs/runbooks/pipeline-incident.md)
"""

print(readme_template)

3.3 Template Runbook

Voir le code

# Template Runbook pour incident/opération

runbook_template = """
# 🔧 Runbook: [Nom de l'incident/opération]

## 📋 Overview

| Propriété | Valeur |
|-----------|--------|
| Severity | P1 / P2 / P3 |
| Time to resolve | ~XX minutes |
| Last updated | YYYY-MM-DD |
| Owner | @team-data |

## 🚨 Symptômes

Comment identifier ce problème :
- [ ] Alerte "[Nom de l'alerte]" déclenchée
- [ ] Dashboard montre [symptôme visible]
- [ ] Users reportent [comportement]

## 🔍 Diagnostic

### Étape 1 : Vérifier [X]
```bash
[Commande de diagnostic]
```

**Si output contient `ERROR`** → Aller à "Résolution A"
**Si output normal** → Continuer à Étape 2

### Étape 2 : Vérifier [Y]
```bash
[Commande de diagnostic]
```

## 🛠️ Résolution

### Résolution A : [Cas 1]

1. [Action 1]
```bash
[Commande]
```

2. [Action 2]
```bash
[Commande]
```

3. Vérifier que c'est résolu :
```bash
[Commande de vérification]
```

### Résolution B : [Cas 2]

[...]

## ⚠️ Rollback (si nécessaire)

```bash
[Commandes de rollback]
```

## 📞 Escalation

Si non résolu après 30 minutes :
1. Ping @senior-engineer sur Slack #data-incidents
2. Si P1 : Appeler on-call via PagerDuty

## 📝 Post-Incident

- [ ] Mettre à jour le ticket avec la résolution
- [ ] Si nouveau cas : mettre à jour ce runbook
- [ ] Si P1/P2 : scheduler post-mortem

## 📚 Références

- [Lien dashboard monitoring]
- [Lien logs]
- [Doc architecture système]
"""

print(runbook_template)

3.4 Diagrammes d’Architecture (C4 Model)

┌─────────────────────────────────────────────────────────────────────────────┐
│                    C4 MODEL : 4 NIVEAUX DE ZOOM                             │
│                                                                             │
│   LEVEL 1 : CONTEXT                                                         │
│   ─────────────────                                                         │
│   • Vue très haut niveau                                                   │
│   • Système + users + systèmes externes                                    │
│   • Pour : Executives, PM, nouveaux membres                                │
│                                                                             │
│   ┌─────────┐         ┌─────────────┐         ┌─────────┐                  │
│   │  Users  │────────▶│ Data Platform│────────▶│ BI Tools│                  │
│   └─────────┘         └─────────────┘         └─────────┘                  │
│                              │                                              │
│                              ▼                                              │
│                       ┌─────────────┐                                      │
│                       │ Source DBs  │                                      │
│                       └─────────────┘                                      │
│                                                                             │
│   LEVEL 2 : CONTAINER                                                       │
│   ───────────────────                                                       │
│   • Zoom sur le système                                                    │
│   • Applications, databases, file systems                                  │
│   • Pour : Tech leads, architects                                          │
│                                                                             │
│   ┌───────────────────────────────────────────────────────────────────┐   │
│   │                      DATA PLATFORM                                 │   │
│   │   ┌─────────┐   ┌─────────┐   ┌─────────┐   ┌─────────┐          │   │
│   │   │ Airflow │   │  Spark  │   │  Delta  │   │  dbt    │          │   │
│   │   │  (Orch) │──▶│(Process)│──▶│  Lake   │──▶│ (Trans) │          │   │
│   │   └─────────┘   └─────────┘   └─────────┘   └─────────┘          │   │
│   └───────────────────────────────────────────────────────────────────┘   │
│                                                                             │
│   LEVEL 3 : COMPONENT                                                       │
│   ───────────────────                                                       │
│   • Zoom sur un container                                                  │
│   • Composants internes                                                    │
│   • Pour : Developers                                                      │
│                                                                             │
│   LEVEL 4 : CODE                                                            │
│   ─────────────                                                             │
│   • Classes, fonctions                                                     │
│   • Rarement nécessaire (le code est la doc)                               │
└─────────────────────────────────────────────────────────────────────────────┘

4. Estimation de Projets Data

4.1 Pourquoi les Estimations sont Difficiles

┌─────────────────────────────────────────────────────────────────────────────┐
│                    LE CONE D'INCERTITUDE                                    │
│                                                                             │
│   Incertitude                                                               │
│       ▲                                                                     │
│   4x  │╲                                                                   │
│       │ ╲                                                                  │
│   2x  │  ╲                                                                 │
│       │   ╲                                                                │
│   1x  │────╲─────────────────────────────────────                          │
│       │     ╲                                                              │
│  0.5x │      ╲                                                             │
│       │       ╲__________________________________________                  │
│       └──────────────────────────────────────────────────▶ Temps           │
│        Idée    Design   Build    Test    Deploy                            │
│                                                                             │
│   Au début : estimation peut être 4x trop haute ou trop basse              │
│   Plus on avance : plus l'estimation devient précise                       │
│                                                                             │
│   💡 CONSÉQUENCE : Donner des RANGES, pas des chiffres précis              │
└─────────────────────────────────────────────────────────────────────────────┘

4.2 Techniques d’Estimation

Voir le code

# Techniques d'estimation

estimation_techniques = """
# ═══════════════════════════════════════════════════════════════
# TECHNIQUES D'ESTIMATION
# ═══════════════════════════════════════════════════════════════

## 1. THREE-POINT ESTIMATION (PERT)

Formule : (Optimiste + 4×Probable + Pessimiste) / 6

Exemple : Construire un pipeline ETL
- Optimiste (tout va bien) : 3 jours
- Probable (cas normal) : 5 jours  
- Pessimiste (problèmes) : 12 jours

Estimation = (3 + 4×5 + 12) / 6 = 5.8 jours
Communiquer : "5-6 jours, jusqu'à 12 si complications"

## 2. T-SHIRT SIZING

| Taille | Effort | Exemple Data Engineering |
|--------|--------|-------------------------|
| XS | < 1 jour | Fix config, add column |
| S | 1-3 jours | Nouveau job simple |
| M | 1-2 semaines | Pipeline complet |
| L | 2-4 semaines | Nouveau data source |
| XL | 1-2 mois | Nouvelle architecture |

## 3. STORY POINTS (Relative)

Comparer à une tâche de référence :
- Référence (8 points) : Pipeline Kafka → Delta existant
- Nouvelle tâche : "2x plus complexe" → 16 points

## 4. DÉCOUPAGE EN PHASES

Grande estimation → Somme de petites estimations

Projet "Real-time Dashboard" :
├── Phase 1: Setup Kafka (M) : 1-2 semaines
├── Phase 2: Pipeline Spark (M) : 1-2 semaines
├── Phase 3: ClickHouse (S) : 3-5 jours
├── Phase 4: Grafana (S) : 2-3 jours
├── Phase 5: Tests & Polish (M) : 1 semaine
└── Total : 5-8 semaines

## 5. RÈGLES D'OR

• Multiplier par 2 si technologie nouvelle
• Multiplier par 1.5 si intégration avec système legacy
• Ajouter 20% pour tests et documentation
• Ajouter 20% pour imprévus (meetings, bugs, etc.)
"""

print(estimation_techniques)

Voir le code

# Calculateur d'estimation PERT

def estimate_pert(optimistic: float, most_likely: float, pessimistic: float) -> dict:
    """
    Calcule une estimation PERT avec écart-type.
    """
    # PERT estimate
    expected = (optimistic + 4 * most_likely + pessimistic) / 6
    
    # Standard deviation
    std_dev = (pessimistic - optimistic) / 6
    
    # Confidence intervals
    ci_68 = (expected - std_dev, expected + std_dev)  # 68% confidence
    ci_95 = (expected - 2*std_dev, expected + 2*std_dev)  # 95% confidence
    
    return {
        "expected": round(expected, 1),
        "std_dev": round(std_dev, 1),
        "ci_68": (round(ci_68[0], 1), round(ci_68[1], 1)),
        "ci_95": (round(ci_95[0], 1), round(ci_95[1], 1)),
    }

def estimate_project(tasks: list) -> None:
    """
    Estime un projet composé de plusieurs tâches.
    
    tasks: [("name", optimistic, likely, pessimistic), ...]
    """
    print("═" * 70)
    print("PROJECT ESTIMATION")
    print("═" * 70)
    print(f"{'Task':<30} {'O':>6} {'M':>6} {'P':>6} {'Est':>8} {'Range':>12}")
    print("-" * 70)
    
    total_expected = 0
    total_variance = 0
    
    for name, o, m, p in tasks:
        result = estimate_pert(o, m, p)
        total_expected += result['expected']
        total_variance += result['std_dev'] ** 2
        
        range_str = f"{result['ci_68'][0]}-{result['ci_68'][1]}"
        print(f"{name:<30} {o:>6} {m:>6} {p:>6} {result['expected']:>8} {range_str:>12}")
    
    total_std = total_variance ** 0.5
    
    print("-" * 70)
    print(f"{'TOTAL':<30} {'':<20} {total_expected:>8} {total_expected-total_std:.1f}-{total_expected+total_std:.1f}")
    print(f"\n📊 Summary:")
    print(f"   Expected: {total_expected:.1f} days")
    print(f"   68% confidence: {total_expected-total_std:.1f} - {total_expected+total_std:.1f} days")
    print(f"   95% confidence: {total_expected-2*total_std:.1f} - {total_expected+2*total_std:.1f} days")
    print(f"\n💬 Communicate: \"{int(total_expected-total_std)}-{int(total_expected+total_std)} days, likely around {int(total_expected)} days\"")

# Exemple : Projet Real-Time Analytics
tasks = [
    ("Setup Kafka cluster", 3, 5, 10),
    ("Spark Streaming pipeline", 5, 8, 15),
    ("ClickHouse setup + schema", 2, 4, 7),
    ("Kafka → ClickHouse ingestion", 2, 3, 6),
    ("Grafana dashboards", 2, 3, 5),
    ("Testing & documentation", 3, 5, 8),
]

estimate_project(tasks)

4.3 Communiquer les Estimations

┌─────────────────────────────────────────────────────────────────────────────┐
│                    COMMUNIQUER LES ESTIMATIONS                              │
│                                                                             │
│   ❌ À ÉVITER                                                               │
│   ─────────────                                                             │
│   • "Ça prendra 2 semaines." (trop précis)                                 │
│   • "Je sais pas, c'est compliqué." (pas utile)                            │
│   • "ASAP" comme réponse à "Quand ?" (pas une estimation)                  │
│                                                                             │
│   ✅ BONNES PRATIQUES                                                       │
│   ───────────────────                                                       │
│   • Donner une RANGE : "2-4 semaines"                                      │
│   • Préciser les HYPOTHÈSES : "Si l'API est stable..."                     │
│   • Identifier les RISQUES : "Peut aller à 6 semaines si..."               │
│   • Proposer des MILESTONES : "V1 en 2 semaines, V2 en 4"                  │
│                                                                             │
│   TEMPLATE :                                                                │
│   ──────────                                                                │
│   "Je estime [X-Y semaines], plus probablement autour de [Z].              │
│    Ceci suppose que [hypothèse 1] et [hypothèse 2].                        │
│    Risque principal : [risque] qui pourrait ajouter [temps].               │
│    Je propose un checkpoint à [date] pour revalider l'estimation."         │
│                                                                             │
│   GÉRER LE "C'EST TROP LONG"                                                │
│   ─────────────────────────                                                 │
│   1. "Qu'est-ce qui est vraiment nécessaire pour [date] ?"                 │
│   2. "Voici ce qu'on peut livrer en [temps disponible]..."                 │
│   3. "Pour aller plus vite, il faudrait [plus de resources/moins de scope]"│
└─────────────────────────────────────────────────────────────────────────────┘

5. Incident Management

5.1 Niveaux de Sévérité

┌─────────────────────────────────────────────────────────────────────────────┐
│                    SEVERITY LEVELS                                          │
│                                                                             │
│   P1 - CRITICAL                                                             │
│   ─────────────                                                             │
│   • Service complètement down                                              │
│   • Perte de données                                                        │
│   • Impact financier majeur                                                │
│   → Response: Immédiat, all-hands, war room                                │
│   → SLA: Acknowledge < 15 min, Resolve < 4h                                │
│                                                                             │
│   P2 - HIGH                                                                 │
│   ──────────                                                                │
│   • Service dégradé significativement                                      │
│   • Feature majeure broken                                                 │
│   • Workaround existe mais pénible                                         │
│   → Response: Urgent, pendant heures ouvrées                               │
│   → SLA: Acknowledge < 1h, Resolve < 24h                                   │
│                                                                             │
│   P3 - MEDIUM                                                               │
│   ───────────                                                               │
│   • Feature mineure broken                                                 │
│   • Performance dégradée                                                   │
│   • Workaround facile existe                                               │
│   → Response: Next business day                                            │
│   → SLA: Resolve < 1 week                                                  │
│                                                                             │
│   P4 - LOW                                                                  │
│   ─────────                                                                 │
│   • Cosmétique, nice-to-fix                                                │
│   • Pas d'impact utilisateur                                               │
│   → Response: Backlog, quand on a le temps                                 │
└─────────────────────────────────────────────────────────────────────────────┘

5.2 Process de Gestion d’Incident

┌─────────────────────────────────────────────────────────────────────────────┐
│                    INCIDENT LIFECYCLE                                       │
│                                                                             │
│   1. DETECT              2. TRIAGE              3. RESPOND                  │
│   ────────               ────────               ──────────                  │
│   • Alert triggered      • Assign severity      • Incident Commander       │
│   • User report          • Identify owner       • Communication lead       │
│   • Monitoring           • Create ticket        • Technical responders     │
│                                                                             │
│   4. RESOLVE             5. COMMUNICATE         6. POST-MORTEM             │
│   ──────────             ─────────────          ─────────────              │
│   • Fix applied          • Status updates       • Blameless review         │
│   • Verified             • Stakeholder comms    • Timeline                 │
│   • Monitoring OK        • User notification    • Action items             │
│                                                                             │
│   RÔLES CLÉS :                                                              │
│   ─────────────                                                             │
│   • Incident Commander (IC) : Coordonne, prend les décisions               │
│   • Technical Lead : Résout le problème technique                          │
│   • Communication Lead : Updates stakeholders, status page                 │
│   • Scribe : Documente la timeline pour post-mortem                        │
└─────────────────────────────────────────────────────────────────────────────┘

5.3 Post-Mortem Template

Voir le code

# Template Post-Mortem (Blameless)

postmortem_template = """
# 📋 Post-Mortem: [Titre de l'incident]

**Date de l'incident:** YYYY-MM-DD
**Durée:** X heures Y minutes
**Severity:** P1/P2/P3
**Auteur:** @name
**Status:** Draft / Review / Final

---

## 📊 Summary

[2-3 phrases : quoi, impact, durée]

## 📈 Impact

| Métrique | Valeur |
|----------|--------|
| Users impactés | X |
| Durée downtime | X min |
| Données perdues | X rows |
| Revenue impact | $X |

## 🕐 Timeline (UTC)

| Time | Event |
|------|-------|
| 14:00 | Déploiement de la version X.Y.Z |
| 14:15 | Première alerte : latency spike |
| 14:20 | IC assigné : @name |
| 14:25 | Root cause identifié |
| 14:35 | Rollback initié |
| 14:45 | Service restauré |
| 15:00 | Monitoring confirmé stable |

## 🔍 Root Cause

[Explication technique détaillée de la cause]

## 🛠️ Resolution

[Comment le problème a été résolu]

## ✅ What Went Well

- Détection rapide grâce à [monitoring]
- Communication efficace entre équipes
- Rollback process a fonctionné

## ❌ What Went Wrong

- [Point 1]
- [Point 2]

## 🎯 Action Items

| Action | Owner | Priority | Due Date | Status |
|--------|-------|----------|----------|--------|
| Ajouter test pour ce cas | @dev1 | P1 | YYYY-MM-DD | TODO |
| Améliorer alerte | @dev2 | P2 | YYYY-MM-DD | TODO |
| Documenter dans runbook | @dev3 | P3 | YYYY-MM-DD | TODO |

## 📚 Lessons Learned

1. [Leçon 1]
2. [Leçon 2]

---

## ⚠️ REMINDER: Blameless Culture

Ce post-mortem vise à améliorer nos systèmes, pas à blâmer des individus.
Les erreurs humaines sont des symptômes de problèmes systémiques.
"""

print(postmortem_template)

6. Career Growth en Data Engineering

6.1 Career Ladder

┌─────────────────────────────────────────────────────────────────────────────┐
│                    DATA ENGINEERING CAREER LADDER                           │
│                                                                             │
│                                                                             │
│   MANAGEMENT TRACK              │              IC TRACK                     │
│   ────────────────              │              ────────                     │
│                                 │                                           │
│   VP of Data ─────────────────  │  ───────────────── Distinguished Eng     │
│        │                        │                            │              │
│   Director of DE ────────────   │   ──────────────── Principal Engineer    │
│        │                        │                            │              │
│   Engineering Manager ───────   │   ───────────────── Staff Engineer       │
│        │                        │                            │              │
│   Tech Lead ─────────────────── │ ──────────────────── Senior Engineer     │
│                                 │                            │              │
│                                 │                      Mid Engineer         │
│                                 │                            │              │
│                                 │                     Junior Engineer       │
│                                 │                                           │
│   Focus: People, Process        │        Focus: Technical Excellence       │
│   Leverage: Through others      │        Leverage: Through expertise       │
└─────────────────────────────────────────────────────────────────────────────┘

6.2 Compétences par Niveau

┌─────────────────────────────────────────────────────────────────────────────┐
│                    COMPÉTENCES PAR NIVEAU                                   │
│                                                                             │
│   JUNIOR (0-2 ans)                                                          │
│   ────────────────                                                          │
│   • Exécute des tâches bien définies                                       │
│   • Apprend les outils et patterns                                         │
│   • Demande de l'aide quand bloqué                                         │
│   • Code review : reçoit feedback                                          │
│                                                                             │
│   MID (2-5 ans)                                                             │
│   ─────────────                                                             │
│   • Autonome sur des features complètes                                    │
│   • Participe au design                                                    │
│   • Commence à mentorer les juniors                                        │
│   • Code review : donne et reçoit feedback                                 │
│                                                                             │
│   SENIOR (5-8 ans)                                                          │
│   ────────────────                                                          │
│   • Lead le design de systèmes                                             │
│   • Résout les problèmes ambigus                                           │
│   • Mentore activement                                                     │
│   • Influence au niveau équipe                                             │
│   • Communique avec stakeholders non-tech                                  │
│                                                                             │
│   STAFF (8+ ans)                                                            │
│   ─────────────                                                             │
│   • Définit la direction technique                                         │
│   • Résout les problèmes cross-équipes                                     │
│   • Influence au niveau organisation                                       │
│   • Établit les standards et best practices                                │
│   • Sponsorise et développe les seniors                                    │
│                                                                             │
│   PRINCIPAL (10+ ans)                                                       │
│   ───────────────────                                                       │
│   • Vision technique long terme                                            │
│   • Influence l'industrie (talks, papers, OSS)                             │
│   • Résout les problèmes "impossibles"                                     │
│   • Trusted advisor pour executives                                        │
└─────────────────────────────────────────────────────────────────────────────┘

6.3 Comment Progresser

Voir le code

# Conseils de progression de carrière

career_tips = """
# ═══════════════════════════════════════════════════════════════
# COMMENT PROGRESSER EN DATA ENGINEERING
# ═══════════════════════════════════════════════════════════════

## 1. JUNIOR → MID

✅ À FAIRE :
• Maîtriser les fondamentaux (SQL, Python, un outil ETL)
• Livrer des projets de A à Z (pas juste des tickets)
• Comprendre le "pourquoi" business, pas juste le "comment" technique
• Documenter son travail
• Demander du feedback régulièrement

❌ À ÉVITER :
• Rester dans sa zone de confort
• Ne jamais demander d'aide (ou toujours demander)
• Ignorer les soft skills

## 2. MID → SENIOR

✅ À FAIRE :
• Prendre ownership de systèmes complets
• Proposer des améliorations (pas juste exécuter)
• Mentorer au moins 1 junior
• Écrire des ADRs et documentation d'architecture
• Développer expertise dans 1-2 domaines profonds
• Présenter en interne (tech talks)

❌ À ÉVITER :
• Être le "héros" qui fait tout seul
• Ignorer les aspects non-techniques (communication, politique)
• Ne pas partager ses connaissances

## 3. SENIOR → STAFF

✅ À FAIRE :
• Résoudre des problèmes cross-équipes
• Influencer sans autorité directe
• Définir des standards adoptés par l'org
• Sponsoriser des projets (pas juste contribuer)
• Développer une vision technique
• Être la personne "go-to" pour un domaine

❌ À ÉVITER :
• Continuer à coder 100% du temps
• Ignorer l'impact organisationnel
• Ne pas développer les autres

## 4. CONSEILS GÉNÉRAUX

📈 Visibilité :
• Documenter et partager son travail
• Présenter aux stakeholders
• Contribuer à l'open source
• Écrire des blog posts (internes ou externes)

🤝 Réseau :
• Connaître les gens en dehors de son équipe
• Avoir des sponsors/mentors seniors
• Aider les autres (réciprocité)

📊 Impact :
• Mesurer et communiquer son impact
• Lier son travail aux objectifs business
• Garder un "brag document" à jour
"""

print(career_tips)

6.4 Le “Brag Document”

┌─────────────────────────────────────────────────────────────────────────────┐
│                    BRAG DOCUMENT (Self-Promotion Doc)                       │
│                                                                             │
│   Document personnel où tu notes tes accomplissements.                     │
│   À mettre à jour régulièrement (idéalement chaque semaine).               │
│   Utile pour : performance reviews, promotions, CV, interviews.            │
│                                                                             │
│   STRUCTURE :                                                               │
│   ───────────                                                               │
│                                                                             │
│   ## Q1 2024                                                                │
│                                                                             │
│   ### Projets                                                               │
│   • [Projet] : [Description 1 ligne]                                       │
│     Impact : [Métrique quantifiable]                                       │
│     Mon rôle : [Ce que j'ai fait spécifiquement]                           │
│                                                                             │
│   ### Améliorations                                                         │
│   • Réduit le temps de pipeline de 4h à 45min                              │
│   • Économisé $X/mois en optimisant le cluster                             │
│                                                                             │
│   ### Collaboration                                                         │
│   • Mentoré [Nom] sur [Sujet]                                              │
│   • Présenté [Sujet] à l'équipe                                            │
│                                                                             │
│   ### Feedback reçu                                                         │
│   • "[Citation positive d'un collègue/manager]"                            │
│                                                                             │
│   TIPS :                                                                    │
│   ───────                                                                   │
│   • Quantifier quand possible (%, $, temps)                                │
│   • Noter le contexte (sinon on oublie)                                    │
│   • Inclure les "petites" victoires aussi                                  │
│   • Mettre à jour PENDANT le trimestre, pas après                          │
└─────────────────────────────────────────────────────────────────────────────┘

7. Exercices Pratiques

Exercice 1 : Trade-off Analysis

Ton équipe doit choisir entre : - Option A : Snowflake (managed, $$$, facile) - Option B : Spark + Delta sur K8s (flexible, complexe, moins cher)

Contexte : Startup série B, équipe de 5 DE, budget $100K/an data infra.

Questions : 1. Identifie 5 critères de décision avec leurs poids 2. Score chaque option 3. Quel trade-off acceptes-tu avec ton choix ? 4. Comment communiquerais-tu cette décision au CTO ?

Exercice 2 : Communication BLUF

Réécris ce message en format BLUF :

“J’ai regardé plusieurs solutions pour le problème de performance du dashboard. D’abord j’ai essayé d’optimiser les requêtes SQL mais ça n’a pas suffi. Ensuite j’ai regardé l’indexation et ça aide un peu. J’ai aussi évalué ClickHouse comme alternative à PostgreSQL. Finalement, je pense qu’on devrait migrer vers ClickHouse. Ça va prendre environ 3 semaines.”

Exercice 3 : Estimation

Estime ce projet avec la méthode PERT :

“Construire un pipeline d’ingestion depuis une API REST vers Delta Lake”

Décompose en tâches, estime chaque tâche (O/M/P), calcule le total.

Exercice 4 : Post-Mortem

Rédige un post-mortem pour cet incident :

Le pipeline de données quotidien a échoué pendant 3 jours sans que personne ne s’en rende compte. Les dashboards affichaient des données obsolètes. Cause : le job Airflow était en retry infini, pas d’alerte configurée.

Exercice 5 : Career Planning

Où te situes-tu dans la career ladder ?
Quelles sont tes 3 principales compétences à développer ?
Crée ton “brag document” pour le dernier trimestre
Identifie 1 action concrète pour chaque compétence à développer

📚 Ressources

Livres

The Staff Engineer’s Path — Tanya Reilly
An Elegant Puzzle: Systems of Engineering Management — Will Larson
Designing Data-Intensive Applications — Martin Kleppmann
The Manager’s Path — Camille Fournier

Articles

Podcasts

🎓 Félicitations !

🎉 Tu as terminé le bootcamp “From Zero to Hero” !

Tu as maintenant : - ✅ Les compétences techniques d’un Senior Data Engineer - ✅ Les soft skills pour évoluer vers Staff/Principal - ✅ 2 projets intégrateurs dans ton portfolio - ✅ Une compréhension complète de la stack moderne data engineering

🚀 Et maintenant ?

Continue à pratiquer — La théorie ne suffit pas, construis tes propres projets
Partage tes connaissances — Enseigner aux autres solidifie ton apprentissage
Reste à jour — L’écosystème data évolue vite, continue à apprendre
Network — Rejoins les communautés data engineering

Tu es maintenant prêt à devenir un Data Engineer Senior/Staff. Bonne chance dans ta carrière ! 🚀

Retour au sommet