Portfolio Projects for Data Engineer

Trois certificats de plus ne changeront rien à votre candidature Data Engineer. Le recruteur qui ouvre votre GitHub cherche une chose : un projet qui ressemble à du travail, pas à un tutoriel suivi en copiant du code. Voici trois projets qui remplissent ce rôle, et la façon de les présenter pour qu'ils soient lus.

Ce que les recruteurs regardent vraiment#

Ils passent rarement plus de deux minutes sur un dépôt. Ce temps est utilisé pour répondre à trois questions. Le code est-il lisible ? Y a-t-il une gestion des erreurs et des cas limites ? Le projet a-t-il un objectif métier, même modeste ?

Personne ne vous demande un système distribué de niveau Netflix. Un projet simple, exécuté de bout en bout et correctement documenté, bat un projet ambitieux abandonné à mi-chemin. La constance se voit tout de suite dans le README et dans l'historique Git.

Un autre point : les recruteurs lisent les commits. Un dépôt avec un seul commit "final project" envoyé en une fois ressemble à un devoir rendu. Un historique avec des étapes, des corrections, des messages clairs, montre une démarche réelle.

Projet 1 : un pipeline de données avec orchestration et tests#

L'idée : ingérer des données depuis une API publique ou un flux ouvert, les transformer, les charger dans une base, et planifier le tout. Choisissez une source qui bouge, météo, transports, données ouvertes d'une ville, afin que le pipeline ait une raison d'exister.

Ce qui fait la différence : l'orchestration et les tests. Utilisez Airflow, Dagster ou Prefect pour gérer les dépendances entre tâches. Ajoutez des tests unitaires sur les transformations, et des tests de données sur le résultat, par exemple sur les valeurs nulles ou les doublons.

Concrètement, un recruteur veut voir : un schéma de sortie propre, une gestion des échecs de l'API, un historique de reprise, et une commande unique pour lancer le tout en local avec Docker. Le README doit montrer comment reproduire le projet en cinq minutes.

Exemple de ligne de CV pour ce projet

Version faible : "Projet de pipeline de données avec Python et Airflow". Elle ne dit rien de mesurable ni de votre rôle.

Version qui travaille : "Pipeline de données temps réel (Python, Airflow, Postgres) : ingestion d'une API publique, 40k lignes par jour, tests de données intégrés, reprise automatique sur erreur, déploiement documenté via Docker."

Projet 2 : un modèle de données et un entrepôt analytique#

L'idée : partir d'un jeu de données désordonné, ventes, logs d'application, données de mobilité, et construire un modèle en étoile ou en flocon avec des tables de faits et de dimensions propres. Le livrable est un entrepôt consultable, avec des vues ou des modèles dbt.

Ce qui fait la différence : la logique de modélisation et la documentation. Expliquez pourquoi vous avez choisi tel grain pour la table de faits, comment vous gérez les changements de dimension dans le temps, et quels indicateurs métier vous permettez de calculer.

Ce projet montre que vous comprenez les données, pas seulement les outils. Un bon test : un analyste doit pouvoir poser trois questions métier simples sur votre entrepôt et obtenir des réponses sans lire votre code.

Exemple de ligne de CV pour ce projet

Version qui travaille : "Modélisation d'un entrepôt analytique (dbt, Snowflake/BigQuery) : transformation d'un export brut de 2 Go en modèle en étoile, documentation des métriques, requêtes analytiques réduites de plusieurs minutes à quelques secondes."

Évitez d'inventer des chiffres que vous n'avez pas mesurés. Si vous n'avez pas comparé les temps d'exécution, dites simplement que les requêtes sont indexées et documentées. L'honnêteté se repère vite.

Projet 3 : un pipeline de qualité de données avec alerting#

L'idée : prendre un flux de données existant, le vôtre ou celui d'un projet précédent, et y ajouter une couche de contrôle. Tests de fraîcheur, détection d'anomalies, validation de schéma, et notification quand quelque chose casse.

Ce qui fait la différence : la réaction à l'échec. Un contrôle qui affiche "erreur" dans un log ne sert pas à grand-chose. Montrez une alerte concrète, un seuil, un message clair, et une marche à suivre documentée pour l'exploitant qui reçoit l'alerte.

Ce projet est précieux parce qu'il touche à la réalité du métier. Les entreprises perdent du temps sur des données silencieusement fausses. Quelqu'un qui sait détecter et signaler ces problèmes a une longueur d'avance.

Comment présenter ces projets sur GitHub#

Le README est la vitrine. Il doit contenir, dans cet ordre : le problème traité, l'architecture en une image simple, comment lancer le projet, les choix techniques et leurs limites, et un exemple de sortie.

• Un schéma d'architecture lisible, même fait à la main
• Une section "Comment démarrer" avec les commandes exactes
• Un exemple de données d'entrée et de sortie
• Les choix techniques expliqués en deux ou trois phrases
• Les limites assumées et les pistes d'amélioration
• Un historique Git propre, avec des messages explicites
• Des tests exécutables avec une commande unique
• Un .env.example pour la configuration

Un dépôt sans README équivaut à un projet qui n'existe pas. Prenez une heure pour l'écrire comme si vous le présentiez à un collègue qui n'a jamais vu votre code.

Les erreurs qui font "tutoriel" à coup sûr#

Copier un projet célèbre en changeant les noms de variables. Le recruteur a vu ce pipeline de e-commerce vingt fois cette semaine. Choisissez une source de données et une problématique qui vous ressemblent, ou au moins qui ne sont pas dans le premier résultat de recherche.

Garder le code du tutoriel tel quel, y compris les commentaires expliquant des concepts de base. Les commentaires doivent éclairer les décisions, pas réexpliquer la syntaxe.

Aucune gestion d'erreur. Un pipeline qui ne gère pas un appel API qui échoue, un fichier manquant ou un schéma qui change, n'est pas un pipeline. C'est un script.

Des données inventées ou un objectif flou. Si le projet ne sert à personne, dites pourquoi il vous intéresse et ce qu'il démontre. Mieux vaut une petite chose honnête qu'une grande chose creuse.

Un dépôt gonflé de notebooks sans structure. Un notebook peut montrer l'exploration, mais le cœur du projet doit être du code modulaire, testé et exécutable.

Comment en parler en entretien#

Préparez un récit de deux minutes pour chaque projet : le problème, votre approche, la difficulté rencontrée, ce que vous feriez autrement. Ensuite, laissez le recruteur poser des questions. Ne récitez pas tout d'un bloc.

Attendez-vous à des questions précises. Pourquoi ce choix d'outil ? Comment gérez-vous un échec en pleine nuit ? Que se passe-t-il si le volume de données est multiplié par dix ? Préparez des réponses honnêtes, y compris les compromis que vous n'avez pas réglés.

Exemple de réponse sur un choix technique

Question : "Pourquoi Airflow et pas un simple cron ?"

Réponse possible : "Parce que mon pipeline a quatre tâches dépendantes, et que cron ne gère pas les dépendances ni les reprises. J'avais besoin de relancer une seule étape sans tout refaire. Airflow apporte ça, au prix d'une complexité que j'ai limitée en gardant un seul DAG simple."

Cette réponse montre que vous connaissez la limite de votre choix. C'est ce que les recruteurs veulent entendre.

Où trouver des idées et des offres#

Si vous cherchez une source de données ouverte pour alimenter ces projets, les portails de données publiques et les APIs ouvertes sont pleins de possibilités. Pour adapter vos projets à ce que les entreprises demandent réellement, consultez les offres sur notre moteur d'offres et les articles de fond de notre blog. Vous pouvez aussi décoder une offre d'emploi pour comprendre les attentes derrière les mots, ou vérifier la compatibilité de votre CV avec les systèmes de tri automatique.

Outils gratuits#

• jobrise.io/fr/free-ats-checker/
• jobrise.io/fr/free-jd-decoder/
• jobrise.io/fr/jobs/
• jobrise.io/fr/blog/

Questions fréquentes#

Faut-il faire les trois projets ou un seul en profondeur ?

Un seul projet traité en profondeur vaut mieux que trois projets superficiels. Si vous en avez le temps, ajoutez le troisième projet sur la qualité des données, c'est celui qui marque le plus car il touche à l'exploitation réelle.

Combien de temps faut-il pour construire un projet de ce type ?

Comptez deux à quatre semaines en travaillant à côté d'un emploi ou d'études, en visant une version fonctionnelle plutôt que parfaite. Le plus long n'est pas le code, c'est la documentation et les tests, et c'est justement ce qui fait la valeur du projet.

Faut-il déployer le projet en ligne ?

Ce n'est pas obligatoire, mais un projet accessible, même sur une petite instance ou un service gratuit, se consulte plus facilement. L'essentiel est que le recruteur puisse l'exécuter en local sans passer deux heures à résoudre des problèmes de configuration.

Les certificats ont-ils vraiment aucune valeur ?

Ils ont de la valeur pour structurer vos connaissances et parfois pour passer un premier filtre. Mais face à deux candidats, celui qui montre un projet concret et explique ses choix l'emporte presque toujours sur celui qui n'a qu'une liste de certificats.

Comment présenter ces projets si je n'ai pas d'expérience professionnelle ?

Mettez-les en avant dans une section dédiée du CV, avec une ligne par projet et les technologies utilisées. Sur LinkedIn et dans votre candidature, renvoyez vers le dépôt, et préparez le récit de deux minutes pour l'entretien, c'est là qu'ils prennent tout leur poids.