De l’analyste de données à l’ingénieur de données : ma feuille de route d’autoformation sur 12 mois
. Une partie de moi a commencé ce voyage parce que l’ingénierie des données est actuellement l’une des carrières les plus en vogue et les mieux rémunérées. Je ne vais pas prétendre que ce n’était pas un facteur.
Mais il y a plus que cela.
J’apprends l’analyse de données depuis un certain temps maintenant. SQL, Power BI, Python (Pandas, NumPy, un peu Polars), nettoyage de données, EDA. Vous l’appelez, j’ai été dans les mauvaises herbes avec ça. Et je l’apprécie vraiment. Mais à un moment donné, j’ai commencé à être curieux de savoir ce qui se passait avant que les données n’arrivent sur mon bureau. Comment ça bouge ? Qui construit ces pipelines ? À quoi ressemble réellement l’infrastructure derrière tout cela ?
Cette curiosité a planté une graine.
Ensuite, l’IA a commencé à rendre une grande partie de ce que je fais plus rapide et plus facile. Ce qui est génial. Mais cela m’a aussi fait réfléchir : si l’IA peut gérer l’analyse, quel est mon avantage ? Que puis-je construire et comprendre qui va plus profondément ? Je travaille comme analyste de systèmes informatiques dans une startup et, même si j’apprécie ce travail, j’ai réalisé que je ne me mettais pas au défi comme je le voulais. J’étais prêt à en faire plus.
L’impulsion finale est venue d’une vidéo de Data With Baraa, où il a présenté un aperçu complet feuille de route pour l’ingénierie des données. Quelque chose dans le fait de le voir structuré et décomposé le rendait réel et réalisable. Me voici donc.
J’apprends l’ingénierie des données en public. Et cet article est le début de ce voyage.
De plus, je laisse simplement un avertissement indiquant que je ne suis pas affilié à Data with Baraa. Je partage juste mon parcours personnel. J’espère que ça aide.
Pourquoi l’ingénierie des données en particulier
Je veux passer un moment ici parce que je pense que cette question mérite une vraie réponse.
L’analyse des données m’a appris à travailler avec les données après leur arrivée. Nettoyez-le, explorez-le, visualisez-le, tirez-en des enseignements. Cet ensemble de compétences est vraiment précieux. Mais plus j’apprenais, plus je me heurtais au même mur. Les données avec lesquelles je travaillais avaient déjà été façonnées et déplacées par quelqu’un d’autre. Quelqu’un avait construit le pipeline qui me l’avait amené. Quelqu’un avait décidé comment il était stocké, comment il était structuré, à quelle fréquence il était rafraîchi.
Je voulais être cette personne.
L’ingénierie des données se situe en amont de l’analytique. Il s’agit en premier lieu de construire les systèmes qui rendent l’analyse possible. Pipelines de données, architecture de stockage, orchestration des workflows, traitement de données à grande échelle. Ce sont les fondations sur lesquelles tout le reste est construit. Et honnêtement, ce genre de travail d’infrastructure m’attire d’une manière que l’analyse pure ne m’attire plus.
Il y a aussi un argument pratique. Les postes d’ingénierie de données se classent systématiquement parmi les mieux rémunérés du secteur des données. À mesure que les outils d’IA automatisent de mieux en mieux la couche analytique, la demande de personnes capables de créer et de maintenir une infrastructure de données fiable ne fera qu’augmenter. Je préfère construire les tuyaux plutôt que de simplement les utiliser.
Et encore une chose. La startup dans laquelle je travaille n’utilise aucun des outils que je suis sur le point d’apprendre. Ce qui signifie que chaque heure que j’y consacre est entièrement autonome. Pas d’équipe avec laquelle apprendre, pas de projets de travail sur lesquels l’appliquer. Juste moi, Internet et tout ce que je peux construire par moi-même. C’est un défi que je choisis exprès.
Pourquoi je fais ça en public
Écrire sur ce que j’apprends est quelque chose en quoi je crois déjà profondément. Cela vous oblige à réellement comprendre quelque chose avant de l’expliquer. Cela vous tient responsable. Et au fil du temps, cela crée quelque chose qu’un CV seul ne pourrait jamais permettre.
Mais je serai également honnête quant à mes craintes, car je pense que c’est le but de le faire publiquement.
J’ai le syndrome des objets brillants. Là, je l’ai dit. J’ai exploré la conception graphique, l’animation, l’écriture, le marketing et l’informatique avant d’atterrir dans les données. Il y a toujours quelque chose de nouveau et d’excitant qui attire mon attention. L’ingénierie des données pourrait facilement être remplacée par la prochaine chose flashy dans mon flux si je ne le fais pas intentionnellement.
La cohérence en est une autre. Je travaille de 9h à 17h où je touche à peine aux outils que je vais apprendre. Il n’y a pas de renforcement naturel au travail, pas de collègue à qui je puisse répondre aux questions Airflow. Je construis cela entièrement sur mon temps libre, en dehors de mes responsabilités professionnelles.
Et l’équilibre. L’objectif est de trois à quatre heures par jour. Certains jours, cela semblera facile. D’autres jours, cela semblera impossible.
Publier ce voyage est mon système de responsabilité. Si je me tais, vous saurez que j’ai glissé. Et je préfère ne pas glisser.
Par quoi je commence
Je ne pars pas de zéro, ce qui aide. J’ai déjà des connaissances SQL de niveau débutant à intermédiaire grâce à mon travail d’analyse de données, les principes fondamentaux de Python et une certaine expérience pratique avec Pandas. Cela me donne une base sur laquelle bâtir plutôt que de reconstruire à partir de zéro.
Voici la pile d’apprentissage complète, à peu près dans l’ordre dans lequel je vais l’aborder.
1. SQL : aller plus loin que l’analyse
Je connais SQL. Mais l’analyse SQL et l’ingénierie SQL sont des animaux différents. J’approfondirai l’optimisation des requêtes, l’indexation, le travail avec de très grands ensembles de données et l’écriture de SQL conçu pour la performance plutôt que pour l’exploration. Si vous n’avez utilisé SQL que pour extraire et filtrer des données, il existe une toute autre couche en dessous qui mérite d’être comprise.
Pourquoi c’est le premier : Tout dans l’ingénierie des données touche finalement SQL. Être précis ici avant d’ajouter des outils plus complexes facilite le reste du voyage.
2. Python : de l’exploration au prêt pour la production
J’ai les bases. Pandas, NumPy, quelques Polars. Mais le Python que j’ai écrit vit principalement dans des cahiers. Explorateur, désordonné, pas construit pour durer. L’objectif est désormais d’écrire du code plus propre, plus structuré et réutilisable. Fonctions, modules, gestion des erreurs, scripts. Le genre de Python que vous mettriez réellement dans un pipeline.
Pourquoi c’est important : Python est le ciment qui unit la plupart des piles d’ingénierie de données modernes. Airflow l’utilise. PySpark est construit dessus. Se sentir à l’aise ici n’est pas négociable.
3. Git et GitHub : contrôle de version effectué correctement
Je vais être honnête. Mes connaissances Git sont actuellement « copiez la commande, j’espère que cela fonctionnera ». Cela doit changer. Le contrôle de version est fondamental pour travailler comme un ingénieur plutôt que comme un simple analyste. J’apprendrai les branchements, les requêtes d’extraction et comment gérer correctement le code dans les projets.
Pourquoi c’est important : Chaque projet que je construis à partir de maintenant est sur GitHub. C’est le portfolio, c’est la discipline et c’est ainsi que fonctionnent les vraies équipes.
4. Apache Spark et PySpark : traitement du Big Data
C’est là que les choses deviennent vraiment excitantes. Apache Spark est l’un des moteurs les plus utilisés pour traiter des données à grande échelle. PySpark est l’API Python, ce qui signifie que je peux utiliser un langage que je connais déjà un peu pour travailler avec des données distribuées à grande échelle.
Le passage de Pandas à Spark est un changement de mentalité. Pandas fonctionne sur une seule machine. Spark est conçu pour fonctionner sur des clusters. Apprendre à penser de manière distribuée est l’une des compétences qui différencient les ingénieurs de données des analystes.
Pourquoi c’est important : Si vous souhaitez travailler avec du Big Data dans un environnement de production, Spark est presque incontournable. Il apparaît constamment dans les descriptions de poste et est au cœur de l’écosystème Databricks vers lequel je vais construire.
5. Apache Airflow : orchestrer les pipelines de données
Les pipelines de données ne fonctionnent pas tout seuls. Vous avez besoin de quelque chose pour les planifier, les surveiller et gérer les échecs avec élégance. C’est là qu’interviennent les outils d’orchestration de flux de travail, et Airflow est mon choix.
J’ai envisagé quelques options ici. Les workflows Databricks sont parfaits si vous êtes déjà plongé dans l’écosystème Databricks. Azure Data Factory est logique pour les environnements fortement Azure. Mais Airflow est gratuit, open source, indépendant du cloud et largement utilisé dans l’industrie. Il vous enseigne également les concepts de base de l’orchestration d’une manière qui les transfère à d’autres outils. Commencer avec Airflow m’a semblé être la bonne décision, d’autant plus que j’essaie de maintenir les coûts à un niveau bas.
Pourquoi c’est important : L’orchestration est ce qui transforme une collection de scripts en un véritable pipeline. Comprendre Airflow, c’est comprendre comment les flux de travail des données de production sont gérés.
6. Databricks : la plateforme de données
À un moment donné, vous devez choisir une plate-forme de données et l’approfondir. Je vais avec Databricks. Il est construit sur Spark, il est très demandé et dispose d’une édition communautaire gratuite qui vous permet de vous entraîner sans payer de crédits cloud.
Les alternatives sont également solides. Snowflake est un entrepôt SQL propre et rapide que de nombreuses entreprises adorent. BigQuery est l’option sans serveur entièrement gérée de Google et véritablement excellente si vous optez pour Google Cloud. Mais Databricks se situe à l’intersection du Big Data, de l’apprentissage automatique et de l’ingénierie des données, d’une manière qui correspond à ce que je souhaite atteindre. C’était ce qui avait le plus de sens pour mes objectifs.
Pourquoi c’est important : Les employeurs veulent que vous ayez une expérience de plateforme. Il est plus précieux d’en approfondir un que d’en connaître un peu tous.
Comment je structure les 12 mois
La réponse honnête est que cela pourrait prendre plus de 12 mois. Et je suis d’accord avec ça. Je préfère prendre 15 mois et comprendre réellement ce que je fais plutôt que de me précipiter en 12 et de sortir fragile sur les fondamentaux.
L’approche générale consiste à parcourir chaque compétence dans l’ordre et à ne pas avancer tant que je n’ai pas construit quelque chose avec ce que je viens d’apprendre. Les tutoriels sont parfaits pour l’orientation, mais les projets sont le lieu où se produit le véritable apprentissage. Mon plan est de documenter ici chaque phase de Towards Data Science : les concepts, les projets, les frustrations et les victoires.
Pour suivre les progrès, j’utilise la feuille de route Notion de Data With Baraa comme épine dorsale. Il décompose chaque compétence en sujets principaux et me permet de savoir où j’en suis sans me laisser submerger par l’ensemble de la situation d’un seul coup.
En ce qui concerne le temps consacré, l’objectif est de trois à quatre heures par jour. Une partie de cela sera un apprentissage structuré. Certains vont construire. Certains écriront sur ce que je viens d’apprendre, qui constitue une forme d’étude à part entière.
À quoi ressemble le succès
L’objectif est de décrocher un rôle d’ingénierie de données bien rémunéré. C’est réel et je ne vais pas l’habiller.
Mais parallèlement à cela, je veux devenir une voix crédible dans cet espace. Quelqu’un qui construit des choses qui méritent d’être évoquées, documente le voyage sans filtrer les parties difficiles et rend peut-être le chemin un peu plus clair pour quelqu’un qui vient derrière moi.
L’écriture et l’apprentissage se nourrissent mutuellement. Le portfolio devient la preuve. La preuve construit la marque. C’est la vision.
À partir d’aujourd’hui
Cet article est ma date de début officielle. Je n’attends pas de me sentir prêt ou que tout soit parfaitement planifié. Je commence maintenant, j’écris au fur et à mesure et je laisse le processus être public et un peu compliqué.
Si vous êtes quelque part sur un chemin similaire. Que vous travailliez dans l’analyse en pensant à l’ingénierie, dans l’informatique en vous demandant quelle est la prochaine étape, ou simplement en essayant de développer des compétences qui conservent leur valeur dans un monde accéléré par l’IA. Suivez-le.
Je pense que nous aurons beaucoup de choses à dire. Je partagerai également mes apprentissages sur ma chaîne YouTube. Alors n’hésitez pas à vous abonner ci-dessous et à suivre.
Il s’agit du premier article d’une série en cours documentant mon parcours en ingénierie des données. Je publierai régulièrement sur mes progrès, les projets que je construis et tout ce que j’apprends en cours de route.
Et si vous souhaitez accéder au modèle Notion, au cas où vous seriez dans le même voyage que moi, vous pouvez y accéder ici.
Suivez mon voyage ci-dessous.
You may also like
