Portfolio GitHub : ce que les recruteurs regardent vraiment (et ce qu'ils ignorent)

Tout le monde vous dit « mettez votre code sur GitHub ». Mais personne ne vous dit ce qu’un recruteur technique cherche vraiment quand il ouvre votre profil. Est-ce qu’il compte vos commits ? Est-ce qu’il lit votre code ligne par ligne ? Est-ce qu’il regarde le nombre d’étoiles ? La réponse à ces trois questions est non. Voici ce qu’il regarde vraiment — et comment en tirer parti.

Ce qu’un recruteur voit en 60 secondes sur votre GitHub

Quand un recruteur ou un développeur senior ouvre votre profil GitHub, voici l’ordre de lecture naturel :

La photo et le nom — est-ce un vrai profil actif ou un compte fantôme créé pour la forme ?
La bio — qui êtes-vous, quelle est votre stack, êtes-vous en recherche d’emploi ?
Les repos épinglés — les 4 à 6 projets que vous avez mis en avant
Le README du premier repo ouvert — est-ce que ce projet est documenté ?
L’activité récente — est-ce que vous codez régulièrement ?

Ça fait environ 60 secondes. Si ces 5 points sont bons, vous passez à l’étape suivante. Si votre profil est vide ou que vos repos n’ont pas de README, vous êtes éliminé sans même que votre code soit lu.

Optimiser votre profil GitHub

La photo

Une vraie photo, professionnelle ou au moins neutre. Pas un avatar de jeu vidéo, pas le logo d’un framework. Les gens font confiance aux vrais visages.

La bio — 2 lignes max

Dites qui vous êtes et ce que vous cherchez :

Développeur web JavaScript/React | Ancien commercial reconverti | En recherche d’emploi — CDI ou freelance 🇫🇷

Ajoutez le lien vers votre portfolio ou votre LinkedIn dans la section dédiée.

Le README de profil

GitHub permet d’afficher un README sur votre page de profil (créez un repo avec votre nom d’utilisateur). C’est optionnel mais efficace : quelques lignes sur qui vous êtes, vos technologies, vos projets en cours. Pas de badges animés inutiles — quelque chose de sobre et lisible.

Les repos épinglés — le cœur du profil

Épinglez uniquement vos 2 à 4 meilleurs projets. Masquez ou archivez les exercices de tutoriels, les forks sans contribution, les repos « test-api-hello-world ». Ils polluent la vue et diluent l’impact de vos vrais projets.

Ce qui fait la différence : le README de chaque projet

C’est l’élément le plus sous-estimé et le plus discriminant. Un projet avec un bon README dit implicitement : ce développeur sait communiquer, il pense aux autres, il a une vision systémique de son travail.

Un README de projet efficace contient :

Le titre et une phrase de description — quel problème ça résout ?
Une capture d’écran ou un GIF — montrez l’interface, pas juste du code
Les technologies utilisées sous forme de badges ou liste
Le lien vers la démo live — obligatoire si le projet est déployé
Les instructions d’installation — git clone, npm install, variables d’environnement
Ce que vous avez appris ou ce que vous feriez différemment — montre votre recul

Quels projets mettre en avant ?

Ce qui fonctionne

Un projet qui résout un vrai problème (même petit) — surtout si lié à votre ancien métier
Un projet fullstack : front + API + base de données + déploiement
Un projet avec une interface soignée (même simple)
Un clone fonctionnel d’un outil connu, avec une feature originale ajoutée

Ce qui n’impressionne pas

La todo-list basique copiée d’un tutoriel (tout le monde en a une)
Des exercices d’algorithmes sans contexte
Un repo avec 1 commit « initial commit » et rien d’autre
Un projet sans démo en ligne (difficile à évaluer rapidement)

L’activité GitHub — utile mais pas critique

Le graphe de contributions vertes fait joli mais n’est pas la priorité. Un recruteur qui voit peu d’activité mais 2 bons projets bien documentés est bien plus convaincu qu’un profil avec 500 commits sur des repos vides.

Ce qui compte : avoir des commits récents sur vos projets principaux. Ça montre que vous progressez et que vos projets ne sont pas abandonnés.

Déployez tout

Un projet non déployé est un projet que le recruteur ne verra pas. Vercel et Netlify sont gratuits et déploient un projet React en 2 minutes. GitHub Pages suffit pour un site statique. Railway ou Render pour un back-end Node.js. Aucune excuse valable pour ne pas avoir de lien live.

Le portfolio site — nécessaire ou pas ?

Un portfolio site (thomasdurand.dev) est un plus, pas une obligation. Si vous êtes front-end, c’est une démonstration directe de vos compétences. Si vous êtes back-end, un GitHub bien organisé suffit.

Si vous faites un portfolio site, gardez-le simple et rapide : qui vous êtes, vos 3 meilleurs projets, comment vous contacter. Pas d’animation complexe qui prend 10 secondes à charger.

Portfolio prêt — passez à l’étape suivante

Retrouvez des offres d’emploi dev sélectionnées pour les juniors. Les recruteurs qui les publient regardent les projets, pas les diplômes.

Voir les offres d’emploi dev →