Seconde partie et conclusion de l'article « Les Prophètes de la Data »
Dans le premier volet, nous avons exploré les miroirs déformants des conseils d'experts. Une question restait en suspens : comment un aspirant data engineer peut-il tracer sa route ?
Commençons par nommer l'éléphant dans la pièce : le marché en 2025 est hostile aux juniors. Automatisation par les LLMs, compression des budgets, exigences accrues, les entreprises veulent des profils immédiatement opérationnels.
C'est leur choix, mais elles ont oublié une chose : les juniors d'aujourd'hui sont les seniors de demain.
Face à ce mur, une stratégie s'impose !
Comment démontrer sa valeur dans un marché saturé de candidats et de machines ? J'identifie quatre leviers : l'expérience, les certifications, les projets, et la visibilité.
Les choix qui façonnent une trajectoire
ESN ou client final : le faux dilemme. La question revient sans cesse : faut-il commencer en ESN ou viser directement un client final ?
L'ESN a ses défauts : intercontrat anxiogène, sentiment d'être une « ressource ». Mais pour un junior, c'est une rampe de lancement incomparable. En deux ou trois ans, vous traversez des contextes variés : banque, retail, industrie. Cette diversité accélère la maturation et vaccine contre le confort des habitudes.
Mais c'est quoi une bonne ESN, ou du moins une qui nous convient ?
- Une ESN qui me propose un environnement convivial et sain.
- Des missions intéressantes, stimulantes et la possibilité d'en changer ou d'évoluer.
- Grâce à elle, je dois pouvoir apprendre, échanger, rencontrer et partager avec d'autres experts dans un environnement bienveillant.
- Qui offre de bonnes conditions de travail (organisation, télétravail/TT, salaire etc.).
Le client final offre d'autres vertus : la profondeur, la continuité, le sentiment d'appartenance et le sens. Voir un projet sur plusieurs années a sa propre valeur.
C'est quoi un bon client final ? C'est exactement la même chose que dans une ESN.
Il n'existe pas de choix universellement supérieur. L'erreur serait de rester paralysé par l'indécision.
Le prix des opportunités. J'ai vu des collègues refuser des postes extraordinaires parce qu'ils impliquaient un déménagement. J'en ai vu d'autres accepter et transformer leur trajectoire.
Les opportunités les plus formatrices ne sont pas toujours disponibles localement. Berlin, Amsterdam, Londres et parfois même un autre continent. Suivre ces opportunités exige des sacrifices : éloignement familial, perte du réseau local, inconfort culturel.
La question n'est pas « dois-je partir ? » mais « qu'est-ce que je suis prêt à échanger, et contre quoi ? »
L'immobilisme : l'ennemi silencieux. Darwin l'avait compris : ce n'est pas l'espèce la plus forte qui survit, mais celle qui s'adapte le mieux. Le data engineer le plus brillant, s'il refuse d'évoluer, sera dépassé par un junior plus agile.
L'immobilisme a mille visages : refuser un nouveau framework, décliner une mission stimulante, rester dans une entreprise qu'on n'aime plus par peur de l'inconnu. Il se justifie toujours : « Le marché est mauvais », « J'attends le bon moment », « J'ai mon crédit à rembourser ». Ces phrases sont souvent des rationalisations.
Le remède ? L'inconfort délibéré, dosé, régulier. Un outil par trimestre. Une mission légèrement au-dessus de son niveau. Ces micro-risques, accumulés, construisent une trajectoire.
Les certifications
Je viens de repasser ma certification GCP Professional Data Engineer. Soyons honnêtes : ce n'est jamais un plaisir. Stressant, chronophage.
Ceux qui crient au loup ne sont souvent pas certifiés ou finissent par nous parler de la formation qu'ils vendent.
Le négatif existe.
Le temps d'abord : relire les docs, visionner des heures de vidéos. Le contenu ensuite : on ne migre pas des clusters Hadoop tous les jours, et pour GCP je n'ai jamais vu Cloud Spanner en production. Le prix enfin : 200 dollars, ça compte pour un étudiant.
Le positif aussi.
Balayer autant de sujets force à (re)découvrir des outils négligés. Le Reshuffle dans Cloud Dataflow, BigQuery Omni couplé aux BigLake Tables. La version 2025 de la certification GCP a enfin abandonné les questions data science inadaptées. Pour l'entreprise, ça tisse un partenariat avec le cloud provider. Pour soi, c'est une reconnaissance objective d'un socle de connaissances. Pour les avant-ventes, on a tous les patterns en tête.
En tant que junior, je referais exactement la même chose : une certification GCP ou AWS avec un compte d'essai gratuit. Excellente base pour commencer.
Lesquelles privilégier ?
- Cloud : GCP Professional Data Engineer, AWS Certified Data Engineer Associate
- Plateformes : Databricks Data Engineer Associate, Snowflake SnowPro Core
- Outils : dbt Analytics Engineering Certification
Conseil tactique : visez le cloud provider et les outils dominants dans vos offres d'emploi cible.
Les projets personnels
Les certifications prouvent que vous savez répondre à des QCM. Les projets prouvent que vous savez construire. La différence est fondamentale.
Mais soyons lucides : à l'ère des LLMs, tout le monde peut générer un projet de A à Z en quelques heures. Demandez à Claude de vous créer un pipeline Airflow qui ingère une API, transforme les données avec dbt et les stocke dans BigQuery, il le fera. Le code compilera. Le README sera impeccable. Et ce projet n'aura strictement aucune valeur sur votre CV.
Pourquoi ? Parce que ce qui compte n'est pas le livrable final. C'est le chemin parcouru pour y arriver.
Savoir lire et exploiter une documentation est une compétence fondamentale que les LLMs ne peuvent pas vous transmettre. Quand vous passez trois heures à comprendre pourquoi votre DAG Airflow ne se déclenche pas, vous apprenez quelque chose qu'aucun prompt ne peut enseigner. Quand vous découvrez un produit data en tâtonnant, en lisant les changelogs, en tombant sur des edge cases non documentés, vous construisez une intuition que le copier-coller de code généré n'apportera jamais.
Il y a aussi la mémoire. Ce que vous construisez de vos propres mains, étape par étape, reste ancré. Les erreurs commises, les solutions trouvées, les compromis acceptés, tout renforce votre expérience. Le code généré par un LLM glisse sur vous sans laisser de trace. Vous ne saurez pas le reproduire, ni l'adapter, ni le défendre en entretien. Un projet personnel réussi démontre plusieurs qualités invisibles sur un CV : la capacité à identifier un problème, à choisir une architecture, à itérer face aux obstacles, à documenter son travail. Ces qualités feront la différence entre vous et un autre data engineer qui fait du vibe coding.
Quel type de projet ? Évitez les tutoriels recopiés et les datasets Kaggle rebattus. Cherchez un problème qui vous intéresse personnellement : automatiser la collecte de données sur votre hobby, construire un dashboard pour suivre vos finances, agréger des sources obscures pour une passion de niche. L'originalité du sujet importe moins que l'authenticité de la démarche. Avec un peu de chance vous rencontrerez des problèmes classiques d'entreprises : données mal formatées, manquantes, incorrectes etc.
Exemple de projet : Une extraction de source de données réelle via DLT (API, scraping, fichiers publics), une transformation non triviale avec DBT (nettoyage, enrichissement, agrégation, modélisation), un stockage approprié (data lake, datawarehouse), une orchestration (Airflow, Dagster), et une restitution (dashboard, API, rapport). Ce pipeline end-to-end, même modeste, vaut plus que dix exercices isolés, à condition de l'avoir construit vous-même, les mains dans le cambouis.
La visibilité
Le meilleur projet du monde ne sert à rien s'il reste invisible. La visibilité est le multiplicateur de tout le reste.
Concrètement : publiez votre code sur GitHub avec un README soigné. Écrivez un article Medium ou LinkedIn expliquant votre démarche. Partagez vos apprentissages, vos erreurs, vos découvertes. Participez aux communautés : le subreddit r/dataengineering, les serveurs Discord spécialisés, les meetups locaux.
LinkedIn mérite une attention particulière. Quelques minutes par jour pour tisser votre réseau. Un profil soigné attire les recruteurs. Rapidement, ce sont eux qui viendront vous chercher.
Attention toutefois : la plupart des sollicitations seront génériques et peu qualifiées. Pour un premier poste, acceptez le jeu. Par la suite, détaillez vos expériences. Alignez votre profil avec vos envies d'abord, les attentes du marché ensuite.
Cette visibilité n'est pas de la vanité. Elle remplit deux fonctions. D'abord, clarifier votre pensée : expliquer un concept révèle les failles de votre compréhension. Ensuite, construire votre réseau. Les opportunités circulent par bouche-à-oreille. Être « le junior qui écrit des trucs intéressants sur dbt » ouvre des portes invisibles.
La pyramide des compétences
Passons maintenant à la question technique : quelles compétences acquérir, et dans quel ordre ? Je propose une progression en trois paliers, chacun bâti sur le précédent.
Premier palier : les fondations (0-6 mois)
SQL est le langage du data engineering. Pas un SQL basique de tutoriel, mais un SQL avancé : window functions, CTEs, optimisation de requêtes, lecture de plans d'exécution. Un junior qui maîtrise vraiment SQL est un atout pour une équipe de data engineers. L'inverse va juste générer plus de travail pour l'équipe lors des reviews ou du pair coding.
Python vient ensuite, mais pas n'importe quel Python. Concentrez-vous sur les bibliothèques data : pandas ou polars pour la manipulation, requests pour les APIs, pytest pour les tests. Apprenez à structurer un projet proprement : modules, environnements virtuels, gestion des dépendances. Créez du code réutilisable avec des classes, des fonctions bien découpées, une architecture lisible.
Git est non négociable. Commits atomiques, branches, pull requests, résolution de conflits. Ces compétences sont essentielles. Vous aurez la plupart du temps des missions avec GitHub ou GitLab. Il vous sera aussi fort utile de connaître a minima comment fonctionnent les systèmes de sécurité associés et les workflows/actions.
Enfin, familiarisez-vous avec au moins un data warehouse ou lakehouse SaaS : BigQuery, Snowflake, ou Databricks. Comprenez les concepts de base comme le stockage colonne, partitionnement, clustering et pratiquez sur les tiers gratuits généreusement offerts par ces plateformes.
Deuxième palier : l'outillage moderne (6-18 mois)
Une fois les fondations solides, le deuxième palier introduit les outils qui définissent le data engineering contemporain. Tout d'abord, pour accompagner cette partie je ne saurais que vous recommander le livre "Designing Data-Intensive Applications" de Martin Kleppmann, qui sera votre livre de chevet pour cette partie.
Ingestion : N'hésitez pas à apprendre DLT de dltHub pour l'extraction de données (fichiers, bases de données, APIs). C'est un outil moderne qui simplifie considérablement les pipelines d'ingestion.
Transformation : Avant de vous lancer, révisez les principes de la modélisation de données. Le livre de référence reste "The Data Warehouse Toolkit" de Ralph Kimball et Margy Ross : star schema, tables de faits, dimensions, slowly changing dimensions (SCD). Ces concepts ont 30 ans mais restent fondamentaux, même avec les outils modernes. dbt (data build tool) a révolutionné la transformation de données. Son paradigme SQL versionné, testé, documenté est devenu un standard de facto. Maîtriser dbt signifie comprendre les modèles, les tests, les sources, les macros, et savoir structurer un projet maintenable. Utilisez par exemple Elementary pour aller plus loin dans les tests. Les alternatives les plus utilisées sont Dataform et SQLMesh : pas la peine de maîtriser les trois, vous vous adapterez.
Orchestration : Airflow reste dominant, malgré ses défauts. Apprenez à écrire des DAGs propres, à gérer les dépendances, à configurer les connexions. Il existe aussi d'autres alternatives comme Dagster ou Prefect. N'utilisez ces outils que pour "appeler" ou "déclencher" du compute, pas pour le faire.
Formats de tables ouverts et choix de fichiers : Les formats de table ouverts comme Delta Lake ou Apache Iceberg pour ne citer qu'eux redéfinissent le stockage. Comprenez leurs avantages (ACID, time travel, schema evolution) et leurs différences. Profitez-en aussi pour regarder les formats de fichiers et les patterns efficaces, notamment Parquet et Avro. Databricks pousse Delta, et la plupart des autres acteurs convergent vers Iceberg.
Docker et les conteneurs sont désormais omniprésents. Savoir construire une image, utiliser docker compose, déployer sur Kubernetes (au moins conceptuellement) fait partie du bagage attendu. Personnellement j'utilise des services managés comme des tâches ECS ou des Cloud Run et ça fait très bien le job.
Clouds : Apprenez à connaître et testez les briques cloud d'un des deux meilleurs providers pour la data : GCP ou AWS, avec une préférence personnelle pour GCP qui inclut directement un des meilleurs data warehouses du marché (BigQuery).
Dernier conseil pour cette partie : Si possible privilégiez les versions core aux versions SaaS des produits open source. On apprend beaucoup plus en les mettant en oeuvre. Tout le monde sait utiliser des outils SaaS, faites de cette différence une force. Si l'entreprise traverse une crise, elle n'aura pas un abonnement récurrent hors de prix à payer. Par contre, je vous invite à prendre un support notamment pour soutenir ces companies.
Troisième palier : la spécialisation (18+ mois)
Le troisième palier n'est plus un chemin unique, mais une bifurcation. Selon vos affinités et votre marché, plusieurs spécialisations s'offrent à vous. Bien entendu ne vous fermez pas à d'autres pistes que celles que je mentionne ici.
Une spécialité streaming : Kafka, Flink, Spark Streaming ou Pub/Sub. Les architectures temps réel sont plus complexes mais très intéressantes. Si les systèmes distribués vous fascinent, c'est une voie royale.
Du data platforming : architecture multi-cloud, infrastructure as code (Terraform), observabilité. Cette spécialisation vous rapproche du DevOps et ouvre des postes de platform engineer.
De la gouvernance : data quality, data contracts, lineage, catalogues. Moins glamour, mais de plus en plus critique. Les entreprises réalisent tardivement que leurs données sont ingouvernables ; ceux qui savent structurer ce chaos sont recherchés.
Du ML engineering : feature stores, MLOps, déploiement de modèles. La frontière avec le data science s'estompe mais vous ne serez pas data scientist pour autant. Savoir opérationnaliser un modèle est une compétence précieuse.
L'AI Engineering : ce domaine explose (+143% de croissance selon LinkedIn). Vous maîtrisez la mise en œuvre des agents IA, l'orchestration multi-agents, les architectures RAG. Vous comprenez les protocoles émergents : MCP (Model Context Protocol) pour connecter les agents aux outils et données, A2A (Agent-to-Agent) pour la communication inter-agents. Côté outils : LangChain/LangGraph pour l'orchestration open-source, Google ADK ou AWS Strands pour de l'open-source orienté cloud providers.
Anatomie d'un parcours
Comment ces éléments s'assemblent-ils dans une carrière réelle ? Je propose un schéma indicatif, à adapter selon votre situation.
Mois 1-3 : Immersion dans SQL et Python. Projets d'exercice, pas encore de visibilité publique. Exploration des ressources gratuites (documentation officielle, tutoriels YouTube de qualité). Création d'un compte d'essai sur un cloud provider.
Mois 4-6 : Premier projet personnel end-to-end. Publication sur GitHub. Premier article ou post LinkedIn documentant l'expérience. Début de la préparation d'une certification cloud.
Mois 7-12 : Passage de la certification. Approfondissement de dbt et Airflow. Deuxième projet, plus ambitieux. Participation active aux communautés. Candidatures ciblées.
Mois 13-24 : Premier poste (idéalement). Apprentissage en contexte professionnel. Continuation de la veille et des projets personnels. Début de la spécialisation.
Ce calendrier est indicatif. Certains iront plus vite ; d'autres auront besoin de plus de temps ou piocheront parmi ces idées. L'essentiel est la progression régulière en trouvant le rythme qui nous convient, pas la vitesse absolue.
Ce qu'aucun tutoriel n'enseigne
Permettez-moi, avant de conclure, quelques observations que les formations omettent généralement.
La technique n'est que la moitié du métier. Savoir communiquer avec les stakeholders, documenter ses choix, défendre une architecture face à des non-techniques ou des très techniques. Ces «soft skills» sont aussi décisives que la maîtrise de Spark.
L'échec est un enseignant. Votre premier pipeline en production tombera. Votre première migration de schéma cassera quelque chose. Ces échecs, à condition d'être analysés et documentés, valent plus que dix succès sans friction.
Le syndrome de l'imposteur est universel. Même les seniors doutent. La différence est qu'ils ont appris à agir malgré le doute. N'attendez pas de vous sentir prêt pour candidater, publier, ou prendre des responsabilités.
Le marché fluctue. La difficulté actuelle à trouver un poste junior n'est pas éternelle. Les cycles économiques tournent ; les technologies évoluent ; de nouveaux besoins émergent. La constance de votre progression paiera, même si le timing semble défavorable.
Conclusion : le sommet et le chemin
J'ai intitulé cet article « L'Ascension du Mont Data » en pensant à une vérité que tout alpiniste connaît : le sommet n'est pas la récompense. C'est le chemin qui vous transforme. Chaque marche gravie, chaque difficulté surmontée, chaque moment où vous avez voulu abandonner mais avez continué, c'est là que se forge le data engineer.
Les outils, les certifications, les projets ne sont que des prises sur la paroi. C'est vous qui décidez de monter. C'est vous qui choisissez votre voie.
À l'ère des LLMs, cette agentivité devient votre avantage compétitif. Les machines peuvent générer du code. Elles ne peuvent pas décider pourquoi ce code devrait exister, ni assumer les conséquences de son existence. Cette responsabilité et cette liberté restent humaines.
Une dernière chose : vous ne rentrez pas dans des cases. Ni celles des algorithmes, ni celles que les gens voudraient vous imposer. Chacun a son chemin propre. Le parcours parfait n'existe pas, il est personnel.
Ces conseils ne sont pas exhaustifs. J'ai parlé à travers mon prisme, mes expériences, mes biais. Je ne sais pas tout. Comme tous les autres que vous lisez. Restez critiques. Prenez ce qui vous parle, laissez le reste. Si cet article vous a aidé ou donné des idées, alors j'ai réussi mon pari.
Le chemin est long, parfois ingrat. Mais le sommet existe. Et on n'y arrive qu'en gravissant chaque marche. Ne vous en faites pas, une fois le sommet gravi vous en trouverez d'autres.
