Le portfolio GitHub qui décroche un entretien en data science

Un recruteur technique qui reçoit une candidature en data science ouvre le lien GitHub avant de lire le CV en détail. Il y passe rarement plus d'une minute. Cette minute décide de la suite. Pourtant, la majorité des portfolios que nous relisons en formation échouent sur des points qui n'ont rien à voir avec le niveau technique du candidat.

Voici ce qui est réellement regardé, dans quel ordre, et comment structurer trois projets pour franchir ce filtre.

Ce qu'un recruteur regarde, dans l'ordre

La séquence est presque toujours la même :

1. La page d'accueil du profil — y a-t-il des dépôts épinglés, ou trente forks abandonnés ?
2. Le README du premier projet — comprend-on en dix lignes le problème traité et le résultat obtenu ?
3. La structure du dépôt — est-ce un dossier organisé ou vingt fichiers à la racine ?
4. Un notebook ouvert au hasard — s'exécute-t-il ? Les sorties sont-elles visibles ? Y a-t-il du texte entre les cellules ?
5. L'historique des commits — un travail étalé dans le temps, ou un unique commit « final version » ?

La structure d'un projet crédible

Un dépôt de projet data lisible tient dans cinq éléments. Ni plus, ni moins.

prediction-abandon-clients/
├── README.md              ← le plus important
├── data/
│   └── README.md          ← origine des données + comment les obtenir
├── notebooks/
│   ├── 01-exploration.ipynb
│   └── 02-modelisation.ipynb
├── src/
│   └── preprocessing.py   ← le code réutilisable, hors notebook
└── requirements.txt       ← les versions des bibliothèques

Deux détails font une grande différence :

• Ne versionnez jamais les données volumineuses. Un data/README.md qui indique la source et la commande de téléchargement vaut mieux qu'un fichier de 200 Mo dans l'historique Git.
• Sortez le code réutilisable des notebooks. Un fichier src/preprocessing.py importé dans le notebook montre que vous savez écrire du code destiné à être maintenu, pas seulement exploré.

Le README : la pièce maîtresse

Un bon README de projet data suit toujours le même plan, et tient sur un écran :

La section « limites » est celle que personne n'écrit — et c'est précisément celle qui impressionne un relecteur expérimenté. Reconnaître qu'un modèle se dégrade sur les clients récents, ou que le jeu de données est déséquilibré, prouve que vous avez compris votre propre travail.

Un candidat qui écrit « rappel de 0,71 sur la classe minoritaire, choisi parce qu'un faux négatif coûte dix fois plus cher qu'un faux positif » vient de démontrer plus de compétence que trois notebooks à 99 % d'accuracy.

Les trois projets à avoir

Inutile d'en accumuler dix. Trois projets bien choisis couvrent l'ensemble des compétences attendues, et chacun raconte quelque chose de différent.

Projet 1 — L'analyse exploratoire

Un jeu de données, des questions métier, des visualisations et des conclusions écrites. Pas de Machine Learning. Ce projet démontre que vous savez interroger des données et communiquer un résultat — la compétence la plus recherchée et la moins enseignée.

Bon signal : les graphiques ont des titres explicites et chaque conclusion est justifiée par une figure.

Projet 2 — La modélisation complète

Un problème de prédiction traité de bout en bout : nettoyage, features, comparaison d'au moins trois modèles, validation croisée, analyse des erreurs. C'est le projet qui prouve la maîtrise méthodologique.

Bon signal : une section « analyse des erreurs » qui montre où le modèle se trompe, pas seulement à quel point.

Projet 3 — Le projet déployé

Une API FastAPI, une petite interface Streamlit ou un conteneur Docker. Même simple, ce projet vous distingue immédiatement : il montre qu'un modèle ne s'arrête pas au notebook. C'est aussi ce qui différencie un profil junior employable d'un profil purement scolaire.

Bon signal : un lien vers une démonstration en ligne accessible en un clic.

Les erreurs qui font fermer l'onglet

• Un dépôt sans README, ou un README qui se limite au titre du projet.
• Des notebooks sans sortie — le relecteur ne va pas exécuter votre code pour voir le résultat.
• Des cellules d'erreur laissées telles quelles au milieu du notebook.
• Un seul commit intitulé « projet final » : aucune trace de démarche.
• Du code copié d'un tutoriel sans aucune adaptation, reconnaissable au premier coup d'œil.
• Des identifiants ou clés d'API laissés dans le code : c'est éliminatoire, y compris pour des raisons de sécurité.
• Un profil GitHub vide : pas de photo, pas de bio, pas de dépôt épinglé.

Soigner le profil lui-même

Le profil GitHub est une page d'accueil, pas un espace de stockage. Trois actions rapides et rentables :

• Épinglez vos trois projets (fonction « Pin repositories ») pour qu'ils apparaissent en premier.
• Rédigez une bio d'une ligne : « Data scientist junior — Python, scikit-learn, séries temporelles. Basé à Alger. »
• Créez un README de profil (un dépôt portant votre nom d'utilisateur) avec vos compétences, vos projets et un moyen de vous contacter.

Un calendrier réaliste

Construire ce portfolio demande entre huit et douze semaines à raison de six heures par semaine :

Faites relire votre portfolio par quelqu'un qui ne connaît pas le sujet. S'il ne comprend pas ce que fait un projet, un recruteur pressé ne le comprendra pas non plus.

Pour choisir vos sujets, notre liste de 10 projets de Machine Learning pour débutants fournit les jeux de données et le piège principal de chacun. Et si vous construisez ce portfolio dans le cadre d'une reconversion, l'article devenir Data Scientist sans diplôme décrit le plan complet sur douze mois.