Portfolio Projects for Data Analyst

Un recruteur ouvre votre portfolio, voit trois projets repris d'un tuto YouTube, et passe au candidat suivant. Les certificats ne changent rien à ça. Ce qui fait la différence, c'est un projet qui montre une décision prise à partir de données réelles.

Je vais vous donner trois projets précis, ce qu'un reviewer regarde vraiment dedans, et comment les poser sur un CV, GitHub et en entretien.

Pourquoi les certificats ne suffisent plus#

Un certificat dit que vous avez suivi un cours. Il ne dit pas que vous savez cadrer un problème sale, nettoyer un fichier cassé, et défendre un chiffre devant quelqu'un qui le conteste.

Les recruteers voient passer des dizaines de CV avec les mêmes badges SQL, Python, Power BI. Le badge filtre à la marge. Le projet décide.

Ce qu'un reviewer cherche vraiment#

Quand quelqu'un ouvre votre repo, il cherche trois réponses. Quel problème vous avez résolu. Quelle décision votre analyse a permise. Et est-ce que le travail est reproductible.

Le niveau esthétique du dashboard arrive après. Un rapport moche avec une vraie conclusion passe. Un dashboard joli sans conclusion ne passe pas.

Projet 1 : l'analyse de churn avec décision de rétention#

Prenez un jeu de données clients, par exemple un export abonnements ou un dataset public de churn télécom. Le but n'est pas de prédire le churn. Le but est de dire qui contacter cette semaine.

Le livrable attendu

Vous devez sortir une liste priorisée de comptes à risque, avec pour chacun la raison principale du risque et l'action suggérée. Pas un modèle. Une décision.

Exemple de ligne de CV

Avant : « Analyse de churn avec Python et pandas sur un dataset télécom ».

Après : « Segmenté 7 000 comptes clients, identifié 3 facteurs de départ (baisse d'usage, retard de paiement, ticket support non résolu), priorisé 420 comptes à contacter, estimé une perte évitable de 60 k€ à 90 k€ selon le taux de rétention retenu ».

Notez la fourchette et la réserve. Un chiffre unique et sans contexte se fait démolir en entretien.

Projet 2 : le pipeline de données qui tient la route#

Beaucoup de portfolios montrent un notebook. Presque aucun ne montre un pipeline. C'est votre avantage.

Le livrable attendu

Une source de données qui arrive régulièrement (un export CSV hebdomadaire, une API, un flux RSS de prix), un script de nettoyage, une table de sortie, et un contrôle qualité qui alerte quand un chiffre sort de la plage normale.

Exemple de ligne de CV

« Automatisé un flux hebdomadaire de 12 fichiers de ventes (40 000 lignes), ajouté 4 contrôles qualité (doublons, valeurs manquantes, ruptures de série, écarts de totaux), réduit le temps de reporting de 3 h à 15 min par semaine ».

Le temps gagné est le genre de détail qui fait poser une question. Préparez la réponse.

Projet 3 : l'analyse critique d'un dashboard existant#

Celui-ci est sous-utilisé. Prenez un tableau de bord public de votre secteur, ou un reporting interne dont vous avez la version anonymisée, et démontez-le.

Le livrable attendu

Un rapport court qui liste les métriques mal définies, les biais de sélection, les ruptures de série non signalées, et une version corrigée avec un jeu de métriques différent. Trois pages suffisent.

Ce projet montre un truc rare : vous savez quand un chiffre ment. C'est exactement ce qu'on attend d'un analyste qui doit présenter à une direction.

Comment présenter ça sur GitHub#

Le reviewer passe 30 secondes sur votre repo. Structurez pour ce rythme.

• Un README qui commence par la question métier, pas par « ceci est un projet de data analysis ».
• Un schéma simple des données en entrée et en sortie, même fait à la main.
• Un fichier requirements.txt ou environment.yml figé avec les versions.
• Un dossier notebooks/ pour l'exploration et un dossier src/ pour le code qui tourne en production.
• Un exemple de sortie réelle (capture ou CSV tronqué), pas seulement le code qui la produit.
• Une section « Limites » écrite franchement : ce que l'analyse ne couvre pas, ce qui fausserait la conclusion.

La section limites est souvent la première lue. Elle dit si vous réfléchissez ou si vous recopiez.

Comment les poser sur le CV#

Une ligne par projet maximum. Format : verbe d'action, périmètre chiffré, résultat, réserve si nécessaire.

Gardez les détails techniques pour GitHub. Sur le CV, le recruteur veut savoir si vous avez bougé un indicateur. Trois lignes de projets bien écrites valent plus qu'une liste de six outils.

Si votre CV passe par un ATS avant d'être lu, vérifiez qu'il reste lisible par la machine : notre vérificateur de CV ATS gratuit vous montre ce qui casse la lecture automatique.

Les erreurs qui font « tuto » à coup sûr#

Un projet sorti d'un tuto se repère en trente secondes. Voici les signaux.

• Le dataset est Iris, Titanic ou un CSV de Kaggle déjà nettoyé.
• Le README décrit les étapes du tuto, pas le problème résolu.
• Aucune décision ne sort de l'analyse, juste des graphiques.
• Le code est un seul notebook de 400 cellules sans fonction.
• Les chiffres sont donnés sans incertitude ni fourchette.
• Personne n'a jamais contesté votre conclusion, et ça se voit.

Si vous reprenez un tuto, changez le dataset, changez la question, et ajoutez une contrainte réaliste (données manquantes, délai, volume). Là ça devient votre projet.

Comment en parler en entretien#

Ne racontez pas le code. Racontez la décision.

Script type

« On perdait des clients sur le segment PME et personne ne savait pourquoi. J'ai repris 12 mois de données d'usage, de facturation et de tickets support. Trois facteurs ressortaient, le plus net était la baisse d'usage après le deuxième mois. J'ai proposé de prioriser 420 comptes sur ce critère. On n'a pas pu mesurer l'effet sur toute la base, mais sur les 80 comptes contactés en test, 23 ont relancé leur usage. »

Notez la fin. Vous admettez ce que vous ne savez pas. C'est plus crédible qu'un résultat gonflé.

Réponse attendue si on conteste votre chiffre

« C'est une estimation, la fourchette vient du taux de rétention observé sur le panel test. Si vous me donnez le vrai taux de rétention de la base, je recalcule en deux minutes. » C'est la bonne réponse. Vous montrez que vous tenez le raisonnement, pas le chiffre.

Adapter les projets au poste visé#

Un poste orienté reporting attendra plus de SQL et de BI. Un poste orienté produit attendra plus de méthodo de test et d'A/B. Un poste junior acceptera des données publiques, un poste confirmé non.

Lisez l'offre avant de choisir vos trois projets. Un décodeur d'offre d'emploi vous sort les compétences réellement demandées derrière le jargon, et notre offres d'emploi vous montre ce qui se recrute en ce moment dans votre domaine.

Combien de projets, et combien de temps#

Trois projets solides valent mieux que huit moyens. Comptez deux à trois semaines par projet si vous travaillez à côté, en incluant la rédaction du README et la préparation de l'oral.

Ne cherchez pas la perfection. Un projet publié avec des limites assumées bat un projet parfait jamais mis en ligne.

Questions fréquentes#

Faut-il payer des certificats en plus des projets ?

Un certificat utile sert à passer un filtre RH sur une techno précise (Power BI, dbt, un cloud). Il ne remplace jamais un projet. Si vous avez déjà trois projets solides, l'argent est mieux placé dans un hébergement, un nom de domaine, ou une formation courte sur un outil que l'offre mentionne explicitement.

Puis-je utiliser des données de mon employeur actuel ?

Seulement avec autorisation écrite et anonymisation réelle. Sinon, reconstruisez un jeu de données public qui ressemble au vôtre, en gardant la même question métier. Un recruteur comprend parfaitement la contrainte de confidentialité, il comprend moins un CV qui casse un accord de non-divulgation.

Combien de temps un reviewer passe-t-il sur mon portfolio ?

Environ trente secondes pour décider s'il creuse. D'où l'intérêt d'un README qui répond dès la première ligne à la question « quel problème est résolu ». Les détails techniques viennent ensuite, pour ceux qui restent.

Mes projets doivent-ils être dans la même langue que le poste visé ?

Code et noms de variables en anglais, quoi qu'il arrive. Le README et les conclusions peuvent être en français si vous postulez en France, mais gardez une version courte en anglais dans le repo si vous visez des boîtes internationales ou du remote. Les deux versions se maintiennent sans effort si le texte reste court.

Que faire si mon analyse ne trouve rien d'intéressant ?

C'est un résultat. Écrivez-le : « Sur ce périmètre et cette période, aucun écart significatif n'apparaît, voici pourquoi et ce que j'aurais testé ensuite ». Un reviewer expérimenté préfère cette honnêteté à une conclusion forcée, et ça vous donne un point de discussion en entretien. Pour d'autres idées de cadrage, nos articles de blog couvrent les méthodes d'analyse et la préparation d'entretien.