🟥 Niveau 3 : Avancé
🎯 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 │
└─────────────────────────────────────────────────────────────────────────────┘
pythonVoir 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)
pythonVoir 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
pythonVoir 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
pythonVoir 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
pythonVoir 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)pythonVoir 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
pythonVoir 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
pythonVoir 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 :
- Identifie 5 critères de décision avec leurs poids
- Score chaque option
- Quel trade-off acceptes-tu avec ton choix ?
- 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
- Staff Engineer Archetypes
- Brag Documents — Julia Evans
- On Being a Senior Engineer
- How to Do a Post-Mortem
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 ! 🚀