Un onboarding mal structuré fait fuir les bons profils data. Voici un plan en 3 phases sur 90 jours qui maximise l autonomie rapidement.
1Jours 1-30 : découverte et immersion
Question discriminante
Quels sont les objectifs des 30 premiers jours pour un Data Engineer ?
- Accès et environnements — avoir accès à tous les outils (cloud, repo Git, orchestrateur, data warehouse) dans les 3 premiers jours
- Comprendre l architecture — cartographier les sources de données, les pipelines, les destinations
- Lire le code existant — parcourir le repo dbt, les DAGs Airflow, les notebooks. Poser des questions sans juger
- Identifier les personnes clés — qui est le Data Owner de chaque domaine ? Qui connaît le système hérité ?
- Premier livrable modeste — corriger un bug simple, ajouter un test dbt, documenter une table non documentée
2Jours 31-60 : premières contributions
Question discriminante
Qu est-ce qu une bonne première contribution pour un Data Engineer confirmé ?
- Contribution autonome — traiter un ticket en autonomie complète : compréhension → développement → PR → review → merge → déploiement
- Observer le cycle complet — voir comment une demande métier se traduit en ticket, en code, en déploiement, en dashboard
- Identifier les points de friction — noter les processus inefficaces sans les critiquer immédiatement. Attendre d avoir le contexte
- Calibrer les standards de l équipe — comprendre les conventions de nommage, les patterns de code, les pratiques de review
3Jours 61-90 : montée en autonomie
Question discriminante
Comment un Data Engineer Senior démontre-t-il sa valeur dans ses 90 premiers jours ?
- Proposer des améliorations — après 60 jours de contexte, proposer une amélioration concrète avec un business case chiffré
- Traiter des tickets complexes — prendre en charge des sujets qui nécessitent une compréhension profonde du système
- Mentorer un junior — aider un collègue moins expérimenté. Signe d intégration réussie dans l équipe
- Documenter — tout ce qui n était pas documenté et qui vous a fait perdre du temps
4Cartographier l architecture existante
Question discriminante
Comment documentez-vous rapidement une architecture data que vous ne connaissez pas ?
# Questions à poser en semaine 1
# Sources
- Quelles sont les sources de données ? (BDD transactionnelles, APIs, fichiers, SaaS)
- Quelle est la fréquence de chaque source ?
- Qui est responsable de chaque source ?
# Pipelines
- Où est le code ? (GitHub, GitLab, dbt Cloud)
- Quel orchestrateur ? (Airflow, Prefect, ADF, Databricks)
- Comment sont gérées les erreurs ?
# Destinations
- Quel data warehouse ? (Snowflake, BigQuery, Redshift)
- Qui consomme les données ? (Power BI, Tableau, APIs)
- Quels sont les SLA ?
# Gouvernance
- Comment les définitions de métriques sont-elles documentées ?
- Qui valide les changements en production ?
- Quel est le process de déploiement ?
5Documentation de l existant
Question discriminante
Pourquoi documenter dès les premiers jours est stratégique ?
- Le moment idéal — les premières semaines, tout est nouveau. On remarque ce que les anciens ne voient plus. C est le meilleur moment pour documenter
- Créer de la valeur immédiate — une documentation de qualité est utile dès le premier jour pour les prochains arrivants
- Comprendre en profondeur — expliquer quelque chose force à le comprendre vraiment
- Support — dbt docs, Confluence, Notion, README dans le repo selon les habitudes de l équipe
6Erreurs classiques à éviter
Question discriminante
Quelles sont les erreurs les plus fréquentes dans les 90 premiers jours d un DE ?
- Tout critiquer dès l arrivée — 'chez mon ancien employeur on faisait mieux'. Attendre d avoir le contexte pour proposer des améliorations
- Travailler en silo — ne pas poser de questions par peur de paraître incompétent. Poser des questions est un signe d intelligence, pas de faiblesse
- Vouloir tout refactoriser — la dette technique existante a souvent une raison. La comprendre avant de vouloir la refactoriser
- Ne pas livrer rapidement — passer 3 semaines sur un projet trop ambitieux. Préférer des petites livraisons fréquentes pour établir la confiance
7Checklist 90 jours
| Phase | Livrables clés | Signe de succès |
|---|
| J1-30 | Architecture documentée, 1er bug corrigé en autonomie | Accès à tous les outils, comprend le cycle de déploiement |
| J31-60 | Ticket complexe traité de bout en bout, PR mergée sans retour majeur | Autonome sur les tickets standards, reviewer pour les Juniors |
| J61-90 | Amélioration proposée et validée, documentation à jour | Reconnu comme référent sur au moins un sujet technique |