Le portfolio GitHub est souvent le premier signal technique avant l entretien. Voici comment l analyser en 15 minutes pour identifier les bons profils.
1Comment lire un repo data en 15 minutes
Question discriminante
Quel est votre processus pour évaluer rapidement un portfolio GitHub ?
- 1. README (2 min) — y a-t-il un README ? Explique-t-il le problème résolu, les données utilisées, les résultats ?
- 2. Structure des fichiers (2 min) — organisation logique ? requirements.txt ou pyproject.toml ? .gitignore configuré ?
- 3. Code source (5 min) — lire les 3-5 fichiers principaux. Conventions de nommage, commentaires, complexité
- 4. Tests et CI (3 min) — y a-t-il des tests ? Un GitHub Actions workflow ? Un badge de build ?
- 5. Historique des commits (3 min) — messages de commit descriptifs ? Progression logique du projet ?
2Le README : le premier vrai signal
Question discriminante
Qu est-ce qu un bon README pour un projet data ?
# Exemple de structure README data idéale
# Nom du projet
> Résumé en 1 phrase
## Problème
_Quel problème réel ce projet résout-il ?_
## Données
- Source : [lien ou description]
- Volume : X lignes, Y features
- Période : YYYY-MM-DD à YYYY-MM-DD
## Résultats
- Modèle : XGBoost, AUC = 0.87
- Amélioration vs baseline : +12%
## Architecture
```
data/ -> notebooks/ -> models/ -> api/
```
## Installation
```bash
pip install -r requirements.txt
python train.py
```
## Utilisation
_Exemple de commande ou d appel API_
- Bon signal — README avec contexte, données réelles (ou ouvertes), résultats chiffrés, instructions d installation
- Signal négatif — README générique auto-généré, pas de contexte métier, pas de résultats
3Qualité du code : ce qu on regarde
Question discriminante
Quels patterns dans le code révèlent la maturité d un Data Engineer ou Data Scientist ?
- Fonctions bien nommées — process_data() vs transform_monthly_revenue_by_region(). La seconde révèle quelqu un qui pense à la lisibilité
- Séparation des responsabilités — code découpé en fonctions claires, pas un script de 500 lignes
- Gestion des erreurs — try/except avec des messages d erreur descriptifs, pas silencieux
- Configuration externalise — paramètres dans config.yaml ou .env, pas de valeurs en dur dans le code
- Pas de credentials — aucune clé API, mot de passe, token dans le code. Utilisation de variables d environnement
4Tests et CI : le signal de maturité
Question discriminante
Qu est-ce que la présence de tests révèle sur un profil data ?
- Présence de tests — signal fort de maturité. Un profil qui teste son code a travaillé sur des systèmes en production
- Types de tests attendus — tests unitaires sur les fonctions de transformation, tests d intégration sur les pipelines
- GitHub Actions — un workflow CI qui lance les tests automatiquement à chaque push. Révèle une culture DevOps
- Coverage — un badge de coverage > 70% est un bon signal
- Signal négatif — aucun test dans un projet présenté comme projet de production
5Historique des commits
Question discriminante
Que révèle le message de commit 'wip', 'fix', 'test2' sur un candidat ?
- Bons messages de commit — 'feat: add daily revenue aggregation by region', 'fix: handle null values in customer_id column'
- Messages pauvres — 'wip', 'fix', 'update', 'test2' : signal que le candidat ne pratique pas le versioning de manière professionnelle
- Un seul commit — 'Initial commit' avec tout le code dedans : le candidat a développé localement et tout pushé d un coup. Pas de pratique Git
- Fréquence — commits réguliers sur plusieurs jours vs un seul gros commit : révèle une vraie démarche de développement incrémental
6Types de projets les plus révélateurs
Question discriminante
Quels types de projets GitHub sont les plus discriminants pour évaluer un profil data ?
- Très discriminants — pipeline ELT complet (ingestion → transformation → test → documentation), API de scoring ML en production, migration dbt d un projet réel
- Moyennement discriminants — analyses exploratoires sur Kaggle, tutoriels suivis, projets de cours
- Signal faible — notebooks déconnectés sans pipeline, forks de repos sans contributions, projets abandonnés mi-parcours
- Meilleur signal — un projet avec un vrai impact mesurable, même petit : 'automatisé le reporting hebdomadaire de 3h à 5 minutes'
7Grille d évaluation portfolio
| Critère | 3 — Excellent | 2 — Correct | 1 — Insuffisant |
|---|
| README | Contexte, données, résultats chiffrés | Description basique | Absent ou auto-généré |
| Structure | Modulaire, séparation claire | Correcte | Script monolithique |
| Tests | Tests + CI + coverage | Quelques tests | Aucun test |
| Commits | Descriptifs, historique logique | Corrects | 'fix', 'wip', 1 seul commit |
| Pertinence | Projet avec impact réel | Projet personnel structuré | Tutoriel ou Kaggle basique |