Portfolio Projects for Data Scientist

Vous avez trois certificats en ligne, un dépôt GitHub rempli de notebooks, et pourtant aucun recruteur ne vous rappelle. Le problème n'est pas votre niveau. C'est que vos projets ressemblent à des exercices corrigés, et les gens qui lisent des portfolios en voient vingt par jour.

Un certificat dit que vous avez suivi un cours. Un projet bien construit dit que vous savez poser un problème, le traiter, et le défendre. Voici trois projets qui font la différence, et la manière de les présenter pour qu'ils travaillent pour vous.

Ce que regardent vraiment les recruteurs#

Ils ne lisent pas votre code en premier. Ils regardent le README, la qualité de la question posée, et la façon dont vous mesurez le résultat. Trois minutes maximum au premier passage.

Ce qui les convainc, dans l'ordre : un problème réel et délimité, des données dont vous maîtrisez les limites, une méthode justifiée plutôt qu'empilée, et une évaluation honnête. Un modèle avec 92 % de précision ne veut rien dire sans la baseline et sans le coût des erreurs.

Le reste du dossier compte aussi. Un CV lisible par un logiciel de tri est la porte d'entrée, sinon personne ne verra vos projets. Passez-le au vérificateur ATS gratuit avant de postuler.

Projet 1 : un problème métier avec une baseline explicite#

Prenez un vrai problème d'entreprise, même petit. Prévision de churn sur une base clients, détection de retards de livraison, estimation du temps de traitement dans un service. L'important est que la question vienne du terrain, pas d'un dataset trouvé au hasard.

Travaillez à fond la baseline. Un modèle qui bat de 2 points une règle simple et visible est plus impressionnant qu'un score élevé sans point de comparaison. Dites explicitement ce que ferait quelqu'un sans machine learning, puis montrez votre gain.

Exemple de ligne de CV avant et après :

Avant : « Projet de prédiction de churn avec Random Forest et XGBoost. »

Aprres : « Réduction de 18 % du taux de faux négatifs sur la détection de churn (base de 40 000 clients), contre une baseline de règle métier, avec analyse du coût des erreurs par segment. »

La deuxième version donne l'échelle, la métrique, la comparaison et l'angle business. C'est ce que le recruteur cherche.

Projet 2 : un pipeline de données que vous avez construit de bout en bout#

La majorité des candidats montrent un notebook propre sur un CSV téléchargé. Presque personne ne montre comment les données arrivent là. C'est votre chance.

Construisez un pipeline simple : ingestion, nettoyage, transformation, entraînement, puis un script de prédiction qui tourne sans notebook. Ajoutez des tests sur les étapes de nettoyage, et documentez les décisions que vous avez prises quand les données étaient sales.

Peu importe l'outil. Un script Python avec un Makefile, ou un petit projet Docker, suffit. Ce qui compte est de montrer que vous pensez à la reproductibilité et à la maintenance, pas seulement à la modélisation.

Projet 3 : une analyse que vous racontez comme une histoire#

Choisissez un sujet qui vous intéresse vraiment, et traitez-le comme une enquête. Les données de mobilité dans votre ville, l'évolution des prix dans un secteur que vous connaissez, une comparaison de politiques publiques. Le sujet importe moins que la rigueur.

Le livrable n'est pas le modèle. C'est une note courte ou un tableau de bord qui répond à une question, avec les limites de l'analyse écrites noir sur blanc. Trois graphiques bien choisis valent mieux que trente.

Ce type de projet montre une compétence rare : la capacité à transformer des données en décision. C'est exactement ce qu'on attend d'un data scientist, bien au-delà de la technique.

Comment présenter vos projés sur GitHub#

Le README est votre vitrine. Il doit répondre à quatre questions sans scroller : quel problème, quelles données, quels résultats, quelles limites. Mettez-les en haut, avant l'installation.

• Un titre clair et une phrase de contexte en haut du README
• La source des données, leur date, et leurs biais connus
• La baseline et votre métrique principale, avec les chiffres
• Les limites et les cas où le modèle échoue
• Un script de reproduction en une commande
• Des captures d'écran ou un lien vers une démo si possible
• Un dossier structuré : données, notebooks, src, résultats
• La licence et l'état du projet, même s'il est terminé

Rangez les notebooks exploratoires dans un sous-dossier, et gardez le code principal dans des fichiers Python importables. Un dépôt propre dit quelque chose de vous avant même qu'on lise le code.

Les erreurs qui font « tutoriel »#

Copier un projet de bout en bout depuis une formation en ligne est le piège numéro un. Le recruteur a vu ce projet vingt fois, souvent avec les mêmes noms de variables et les mêmes graphiques. Même avec du bon code, ça vous classe dans la pile des débutants.

Autres signaux qui font décrocher : un dataset Kaggle traité sans question propre, des métriques choisies parce qu'elles sont flatteuses, un modèle de deep learning sur un problème qui se règle avec une régression, et un README vide. Un projet qui ne dit rien sur ses limites donne l'impression que vous ne les avez pas vues.

Enfin, évitez l'accumulation. Trois projets solides et différents battent dix projets superficiels. La qualité de la finition fait toute la différence.

Comment en parler en entretien#

Préparez un pitch de deux minutes par projet, dans le même ordre : le problème, votre approche, le résultat, ce que vous referiez autrement. La dernière partie est celle qu'on écoute le plus attentivement, parce qu'elle révèle votre jugement.

Exemple de réponse :

« On voulait réduire les désabonnements sur une base de 40 000 clients. J'ai commencé par une règle métier simple pour avoir une référence honnête, puis j'ai testé deux modèles. Le XGBoost a réduit les faux négatifs de 18 %, ce qui correspondait à environ 200 clients détectés en plus par cycle. Le point faible, c'est que le modèle est moins bon sur les clients de moins de trois mois, et j'ai documenté cette limite dans le README. Si c'était à refaire, je passerais plus de temps sur la segmentation avant de modéliser. »

Cette réponse montre la méthode, l'honnêteté et la capacité à apprendre. C'est bien plus fort qu'une liste d'algorithmes.

Préparez aussi les questions techniques qu'on peut vous poser sur vos choix. Pourquoi cette métrique et pas une autre, pourquoi ce modèle, comment vous avez géré les valeurs manquantes. Si la description du poste est floue, décodez-la d'abord avec l'analyseur d'offre d'emploi pour savoir quelles compétences mettre en avant.

Où trouver l'inspiration et les offres#

Regardez les offres dans votre domaine pour voir quelles compétences reviennent, via nos offres d'emploi data. Les descriptions de postes vous diront si l'on attend surtout du NLP, de la vision, ou de l'analytique, et vous pourrez caler vos projets en conséquence.

Pour la suite de votre préparation, nos autres guides sur le blog carrière couvrent la préparation d'entretien et la négociation. Un bon portfolio ouvre la porte, mais c'est votre préparation qui la fait rester ouverte.

Questions fréquentes#

Combien de projets faut-il dans un portfolio data scientist ?

Trois projets bien finis suffisent largement. Choisissez-les complémentaires, par exemple un projet métier, un pipeline de données et une analyse exploratoire, plutôt que trois variations du même exercice.

Faut-il utiliser les données de Kaggle ?

Elles sont acceptables si vous formulez votre propre question et que vous ne copiez pas un kernel existant. Précisez toujours la source, la taille du jeu de données et ses limites connues.

Mon projet doit-il utiliser du deep learning ?

Non, et souvent ce serait un mauvais choix. Un modèle simple, bien évalué et bien expliqué, impressionne plus qu'un réseau de neurones mal calibré sur un problème qui n'en a pas besoin.

Dois-je publier mon code en open source sur GitHub ?

Oui, sauf si les données sont sensibles ou sous licence restrictive. Dans ce cas, publiez le code avec des données d'exemple et expliquez clairement la contrainte dans le README.

Combien de temps consacrer à un projet de portfolio ?

Comptez deux à quatre semaines par projet en travaillant à côté d'un emploi ou d'études. Le plus long n'est pas la modélisation, c'est le nettoyage des données et la rédaction du README.