Portfolio et GitHub : démontrer une expertise IA sans multiplier les projets

Ce que le lecteur cherche en ouvrant votre GitHub

Le lecteur n'est pas toujours celui qu'on imagine. Un recruteur regarde d'abord si les dépôts sont lisibles et récents. Un hiring manager cherche à savoir dans quel type de problème vous êtes à l'aise. Un responsable technique, lui, ouvre un ou deux fichiers et se demande si les décisions tiennent debout. Aucun des trois ne lit l'intégralité du code.

Trois questions doivent trouver leur réponse en moins de deux minutes : quel problème ce projet traite-t-il, quelles décisions ont été prises et pourquoi, comment sait-on que le résultat était acceptable. Un dépôt qui répond à ces trois questions vaut davantage qu'une page de profil couverte de contributions.

L'objectif de ce guide n'est pas de vous faire produire dix projets. C'est de rendre démontrable ce que vous savez déjà faire.

Choisir les projets à montrer

Épinglez deux ou trois dépôts, pas davantage. Le critère de sélection n'est pas la difficulté technique perçue, mais la capacité du projet à illustrer une compétence que vous revendiquez dans votre profil et dans vos candidatures.

• Un projet qui recoupe le type de poste visé : un même sujet traité proprement pèse plus qu'un sujet spectaculaire hors cible.
• Un projet dont vous pouvez parler vingt minutes en entretien sans relire le code.
• Un projet où une contrainte réelle vous a forcé à arbitrer : volume, coût, qualité de données, délai.
• Éventuellement un projet plus court mais très bien documenté, qui sert de démonstration de méthode.

Les dépôts restants n'ont pas besoin d'être supprimés. Il suffit qu'ils ne soient pas mis en avant, et qu'aucun d'eux ne contredise ce que vous affirmez savoir faire.

Projet tutoriel ou projet qui démontre une compétence

Un dépôt issu d'un cours ou d'un tutoriel n'est pas disqualifiant en soi. Il le devient quand rien n'indique ce que vous y avez apporté. Le lecteur technique reconnaît immédiatement une structure de tutoriel : mêmes fichiers, même jeu de données, même conclusion.

Le README est le livrable principal

Sur un profil IA, le README fait le travail que le code ne peut pas faire en deux minutes. Il se lit de haut en bas, du contexte vers les détails, et non l'inverse. Une structure qui fonctionne, quel que soit le sujet :

• Problème et contexte : ce qui ne marchait pas avant, et pour qui.
• Ce que fait le projet, en une phrase, plus une capture ou un exemple d'entrée/sortie.
• Architecture : les composants et surtout la raison de chacun.
• Décisions et alternatives écartées : deux ou trois suffisent, si elles sont justifiées.
• Données : origine, volume, licence, biais ou limites connues.
• Évaluation : méthode, jeu de test, résultats, y compris ce qui échoue.
• Limites et suites possibles.
• Exécution : dépendances, variables d'environnement, commande de lancement.

Un exemple d'utilisation concret — une requête et sa réponse réelle, une capture d'écran de l'interface, un court extrait de log — remplace des paragraphes de description. Il évite aussi au lecteur d'avoir à installer quoi que ce soit pour se faire une idée.

Qualité du dépôt et reproductibilité

La reproductibilité n'a pas besoin d'être industrielle. Elle doit simplement être honnête : soit le projet se lance, soit le README dit clairement ce qui manque et pourquoi, par exemple une source de données non redistribuable.

• Dépendances figées et instructions d'installation testées sur une machine vierge.
• Configuration par variables d'environnement, avec un fichier d'exemple sans secret.
• Un jeu de données d'exemple, réduit ou synthétique, quand les données réelles ne peuvent pas être publiées.
• Quelques tests sur les parties déterministes : parsing, transformations, formats de sortie.
• Un historique de commits lisible, sans dépôt de fichiers volumineux ni de données sensibles.

Un dépôt qui ne se lance pas et ne le dit pas produit l'effet inverse de celui recherché : le lecteur suppose que le projet n'a jamais fonctionné.

Dire ce que vous avez réellement fait

Sur un projet collectif, d'école ou d'entreprise, la contribution individuelle doit être explicite. Une phrase suffit : quelle partie vous avez conçue, quelle partie vous avez reprise, ce qui existait avant vous. Cette précision n'affaiblit jamais une candidature ; son absence, en revanche, peut fragiliser la crédibilité du projet aux yeux du recruteur dès que l'entretien technique creuse un détail.

La même règle vaut pour le code assisté. Utiliser des outils de génération est aujourd'hui banal ; présenter comme conception personnelle un ensemble que vous ne pouvez pas défendre ligne à ligne ne l'est pas.

Projets GenAI, RAG et agents, ou ML plus classique

Les deux familles se démontrent différemment, et la confusion coûte cher en entretien.

• GenAI, RAG, agents : la partie visible est facile à produire ; ce qui distingue, c'est le traitement des documents, la stratégie de recherche, le protocole d'évaluation, la gestion des réponses sans source et le comportement en cas d'échec.
• ML plus classique : la valeur se lit dans la construction du jeu de données, la validation adaptée au problème, le traitement des fuites de données, la comparaison à une référence simple et la stabilité dans le temps.
• Dans les deux cas : une métrique choisie pour la bonne raison, et un résultat comparé à une baseline, valent mieux qu'un score isolé.

Une démonstration en ligne est utile quand elle est stable et sans coût pour vous. Une courte vidéo ou deux captures suffisent lorsque l'hébergement permanent n'est pas raisonnable.

Ce qu'il vaut mieux ne pas publier

Le portfolio est aussi un test de discernement. Publier ce qui ne devait pas l'être disqualifie plus vite qu'un dépôt vide.

• Données client, extraits de production, documents internes, même anonymisés à la main.
• Clés d'API et identifiants, y compris dans l'historique des commits d'un dépôt devenu public.
• Code d'un employeur ou d'un client sans autorisation écrite, y compris « nettoyé ».
• Données personnelles, jeux de données dont la licence interdit la redistribution.
• Projets abandonnés au premier commit et mis en avant comme s'ils étaient aboutis.

Quand le travail le plus significatif est couvert par une clause de confidentialité, la solution n'est pas de le publier partiellement : c'est de le décrire dans votre profil et en entretien, en parlant du problème, des contraintes et des décisions, sans exposer ni code ni données.

Erreurs fréquentes

• Épingler dix dépôts, dont sept sans README.
• Décrire la stack et jamais le problème.
• Annoncer une performance sans dire sur quel jeu ni comparée à quoi.
• Laisser un notebook unique de 900 lignes comme seule trace du projet.
• Rendre public un dépôt d'exercices techniques d'entreprise.
• Présenter un projet que l'on ne peut plus expliquer six mois après.

Un portfolio crédible n'est pas une accumulation : c'est un petit ensemble cohérent avec ce que vous dites savoir faire, et que vous pouvez défendre. Le prolongement naturel de ce travail, c'est l'entretien, où le même projet devra être raconté sous forme de décisions plutôt que d'outils.

• AI Engineering
• Évaluation