Portfolio Projects for Machine Learning Engineer

Vous avez trois certificats en ligne, un dépôt GitHub rempli de notebooks, et aucun recruteur ne vous rappelle. Le problème n'est pas votre niveau. C'est que les certificats prouvent que vous avez suivi un cours, pas que vous savez livrer un modèle qui tient en production.

Un reviewer passe rarement plus de deux minutes sur un projet. Dans ces deux minutes, il cherche des preuves concrètes : un problème réel, des décisions que vous avez prises, un résultat mesuré, un code qu'on peut exécuter. Si tout cela est absent, il passe au candidat suivant.

Voici trois types de projets qui donnent ces preuves, comment les présenter, et ce qui les fait basculer dans la case "copie de tutoriel".

Ce que les reviewers regardent vraiment#

Ils ne lisent pas votre code ligne par ligne au premier passage. Ils scannent le README, puis le dépôt, puis la structure. Ce qu'ils cherchent tient en quelques questions simples.

• Est-ce que je comprends le problème en trente secondes ?
• Le projet est-il exécutable sans passer trois heures à installer des dépendances ?
• Y a-t-il une baseline, et le modèle la bat-il ?
• Les métriques sont-elles définies et justifiées ?
• Le code ressemble-t-il à un code de production ou à un notebook de cours ?
• Y a-t-il des tests, un suivi d'expérience, une gestion des données ?

La réponse à ces questions décide de l'entretien. Les badges de certification, eux, ne répondent à aucune d'entre elles.

Un outil comme un vérificateur de CV compatible ATS vous montre aussi comment ces projets ressortent quand un logiciel lit votre CV avant un humain. Et si vous hésitez sur ce qu'une offre attend vraiment, un décodeur d'offres d'emploi vous aide à extraire les compétences demandées.

Projet 1 : un système de recommandation avec des contraintes réelles#

C'est le classique qui impressionne encore, à condition de sortir du cours. Prenez un vrai jeu de données public, par exemple des avis produits ou des interactions utilisateur, et construisez un moteur de recommandation qui gère des cas difficiles.

Le piège est de s'arrêter à "j'ai entraîné un modèle de factorisation". Le reviewer veut voir autre chose : le problème du démarrage à froid, le filtrage des faux comptes, le choix entre pertinence et fraîcheur, la latence d'inférence.

Un exemple concret de ce qu'il faut montrer :

• Baseline : recommandation des articles les plus populaires, couverture de 12 % sur les utilisateurs actifs.
• Modèle : factorisation matricielle, couverture de 34 %, précision@10 en hausse de 0,09.
• Contrainte ajoutée : filtrage des utilisateurs avec moins de cinq interactions, gestion du démarrage à froid par métadonnées produit.

L'écart entre la baseline et votre modèle, c'est le cœur du projet. Sans cet écart chiffré, vous n'avez rien prouvé.

Projet 2 : un pipeline de traitement de texte avec du bruit réel#

Les données textuelles propres n'existent pas. Un projet qui traite des avis clients, des tickets de support ou des annonces d'emploi vous oblige à gérer l'encodage, les doublons, les libellés incohérents, la classe minoritaire.

Choisissez une tâche de classification avec un enjeu compréhensible : détecter les avis trompeurs, trier des tickets par urgence, repérer les offres frauduleuses. Le reviewer comprend le besoin immédiatement, ce qui compte plus que la complexité du modèle.

Ce qui fait la différence : le prétraitement est versionné, le déséquilibre des classes est traité explicitement, et vous expliquez pourquoi vous avez choisi une métrique plutôt qu'une autre. La précision est souvent trompeuse sur des classes déséquilibrées. Dites-le.

Projet 3 : un modèle déployé avec suivi de dérive#

C'est le projet qui sépare un profil junior d'un profil qui a compris la production. Pas besoin d'infrastructure lourde. Un service d'inférence simple, des logs de prédictions, et un mécanisme qui détecte quand les données d'entrée dérivent.

Concrètement : vous exposez votre modèle via une API, vous stockez les prédictions, et vous comparez chaque semaine la distribution des entrées à celle du jeu d'entraînement. Quand un seuil est franchi, le système alerte. C'est exactement le genre de problème qu'une équipe rencontre dès le premier mois.

Vous n'avez pas besoin d'outils payants. Un script de suivi avec quelques statistiques de distribution suffit, à condition de l'expliquer et de montrer le code.

Comment présenter ces projets sur GitHub#

Le README est votre vitrine. Il doit répondre aux questions du reviewer sans qu'il ait à lire le code.

• Une phrase qui décrit le problème et le public visé.
• Une section "Résultats" avec les chiffres de la baseline et du modèle.
• Une section "Installation" avec une commande qui fonctionne du premier coup.
• Un schéma simple du pipeline, même fait à la main.
• Les limites connues du projet, écrites sans langue de bois.

Structurez le dépôt comme un vrai projet : code dans des modules, notebooks éventuellement dans un dossier à part, configuration séparée, tests sur les fonctions critiques. Un notebook unique à la racine, c'est le signal d'un tutoriel suivi pas à pas.

Comment les mettre sur votre CV#

Un projet sur le CV n'est pas une description de technologie. C'est un résultat avec un contexte. La formule qui marche : verbe d'action, problème traité, méthode, chiffre.

Exemple faible : "Projet de recommandation avec Python et scikit-learn".

Exemple réécrit : "Conçu un moteur de recommandation pour 40 000 produits, doublé la couverture des suggestions par rapport à la baseline popularité, géré le démarrage à froid par métadonnées."

La deuxième version dit ce que vous avez fait, pour quel volume, avec quel écart. Un recruteur technique peut vous poser une question dessus, ce qui est exactement ce que vous voulez.

Comment en parler en entretien#

Ne récitez pas le README. Racontez une décision que vous avez prise et pourquoi. Les intervieweurs ML veulent comprendre votre raisonnement, pas votre liste d'outils.

Voici un script réaliste pour répondre à "parlez-moi de votre projet le plus abouti" :

"J'ai construit un système de recommandation sur un catalogue de 40 000 produits. Ma baseline était la popularité, avec 12 % de couverture. J'ai implémenté une factorisation matricielle, et j'ai atteint 34 % de couverture avec un gain de 0,09 en précision@10. Le vrai défi était le démarrage à froid, que j'ai traité avec les métadonnées produit plutôt qu'en ignorant les nouveaux utilisateurs. Si c'était à refaire, j'ajouterais un suivi de dérive en production."

La dernière phrase est importante. Elle montre que vous connaissez les limites de votre travail.

Les erreurs qui font basculer un projet dans la case tutoriel#

Il y en a quelques-unes qui reviennent tout le temps. Les voici, sans détour.

• Un notebook unique, sans module de code réutilisable.
• Des résultats sans baseline comparée, donc impossibles à interpréter.
• Un README qui ne contient que le titre du projet et une liste de technologies.
• Aucune mention des limites ou des cas d'échec du modèle.
• Un projet qui reproduit exactement un tutoriel connu, avec les mêmes données.
• Des métriques citées sans dire sur quel jeu de données elles ont été mesurées.

Si vous cochez deux de ces cases, le projet ne vous apporte rien. Mieux vaut un projet plus petit mais propre qu'un projet ambitieux mais illisible.

Où trouver des idules de projet qui recrutent#

Les offres d'emploi sont votre meilleure source d'inspiration. Lisez les descriptions de postes Machine Learning Engineer et repérez les problèmes récurrents : recommandation, détection d'anomalie, traitement de texte, prédiction de séries temporelles. Vous pouvez parcourir des offres actuelles sur la page des offres d'emploi pour voir ce qui revient, puis adapter vos sujets en conséquence.

D'autres retours d'expérience et méthodes sont disponibles dans les articles du blog, si vous voulez creuser un point précis de la préparation.

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#

Combien de projets faut-il dans un portfolio Machine Learning Engineer ?

Trois projets bien présentés valent mieux que dix projets moyens. Un seul projet avec une baseline, des chiffres et un dépôt propre impressionne plus que cinq notebooks sans contexte.

Faut-il déployer tous ses projets en ligne ?

Non, un seul projet déployé suffit à montrer que vous savez passer à la production. Les autres peuvent rester sur GitHub, à condition que le README explique clairement l'architecture et les résultats.

Les projets de cours ou de MOOC ont-ils de la valeur ?

Ils ont de la valeur seulement si vous les avez modifiés en profondeur : nouvelles données, nouvelle métrique, contrainte ajoutée. Un projet recopié pas à pas depuis un cours se repère en trente secondes.

Comment présenter un projet si je n'ai pas d'expérience professionnelle ?

Mettez-le en avant comme une expérience à part entière, avec les mêmes formulations qu'un poste : contexte, action, résultat. Précisez le volume de données et les écart mesurés, même sur des données publiques.

Faut-il montrer ses modèles sur son profil LinkedIn ?

Oui, avec un lien vers le dépôt et une phrase qui résume le résultat, pas la liste des technologies. Le lecteur doit comprendre l'apport du projet avant de cliquer.