Le piège du portfolio surchargé : ce que regardent vraiment les recruteurs en dix secondes

Tu as passé trois week-ends à peaufiner ton portfolio. Tu as ajouté tous tes projets, depuis le todo-list du premier cours jusqu'à ta dernière app React. Tu as écrit une description pour chacun. Tu es fier du résultat. Tu envoies le lien dans dix candidatures. Aucun retour.

Toi, tu te dis que tu ne montres pas assez. Que tu devrais ajouter encore deux ou trois projets pour faire bonne mesure. Tu retournes coder, pour étoffer la liste.

Le problème, ce n'est pas que ton portfolio est trop maigre. C'est qu'il est trop chargé pour la manière dont les recruteurs le lisent. Un recruteur tech passe entre six et quinze secondes sur un portfolio avant de décider s'il continue. Dans ces dix secondes, il ne lit pas. Il scanne. Et un portfolio surchargé est invisible.

Cet article t'explique ce que ces dix secondes contiennent vraiment, ce que tu dois mettre en avant, et pourquoi avoir trois projets bien présentés vaut cent fois mieux que d'en avoir quinze noyés dans la masse.

Le problème : tu confonds preuve de travail et preuve de compétence

Quand tu ajoutes un projet, tu démontres que tu as fait quelque chose. Quand un recruteur regarde un projet, il cherche à savoir ce que tu sais faire. Ce n'est pas la même question.

Ajouter quinze projets, dont treize sont des tutoriels suivis ou des exercices basiques, te dessert. Le recruteur ne voit plus tes deux projets sérieux, il voit une longue liste qui ressemble à du remplissage. Pire, il commence à se demander pourquoi tu n'as pas su distinguer ce qui vaut la peine d'être montré.

La logique est la même qu'avec un CV : montrer trop, c'est diluer le signal. Un CV de junior avec quatre lignes de "missions" claires et impressionnantes pèse plus qu'un CV avec quinze lignes vagues. Un portfolio fonctionne pareil. Trois projets que le recruteur peut comprendre, tester et discuter en entretien, c'est largement suffisant.

À cela s'ajoute un biais cognitif simple : ce qu'on voit en premier compte démesurément. Si ton premier projet listé est un clone de calculatrice fait pendant ton premier cours, le recruteur en déduit immédiatement ton niveau. Même si tu as un projet plus solide en cinquième position, il ne l'atteindra pas.

Le principe : ce que le recruteur cherche en dix secondes

Quand un recruteur ouvre ton portfolio, son cerveau cherche cinq signaux dans cet ordre. Si les trois premiers passent, il continue. Sinon, il ferme l'onglet.

1. Quelque chose qui marche en ligne

Le tout premier réflexe du recruteur, c'est de cliquer sur un projet et de tester. Pas lire la description, pas voir une capture d'écran. Cliquer et utiliser. Un projet sans démo en ligne, c'est un projet qui n'existe pas.

Tu as au moins un lien "Démo" ou "Voir le site" visible sur chaque projet. Vercel, Netlify, Render, peu importe l'hébergement, mais quelque chose doit tourner.

2. Un GitHub propre, avec des commits récents

Le deuxième réflexe, c'est de cliquer sur ton GitHub. Le recruteur regarde la graph d'activité, l'historique de commits, le README du repo principal. Un graph vide depuis trois mois est un mauvais signal. Un repo avec un seul commit "Initial commit" est un mauvais signal. Pas de README ou un README vide est un mauvais signal.

Un bon README, c'est cinq sections : ce que fait le projet, comment l'installer, comment le lancer, les technos utilisées, une capture d'écran ou un GIF. Cinq minutes de travail, énorme retour sur investissement.

3. Une stack alignée sur ce qu'il cherche

Le recruteur a un poste à pourvoir. Si l'offre demande React et Node, il cherche React et Node dans tes projets. Si tu lui montres trois projets en Vue et un projet en jQuery, il ferme.

Cela ne veut pas dire que tu dois mentir ou faire semblant de connaître. Cela veut dire que tu adaptes l'ordre et la mise en avant en fonction du poste. Tes projets React en haut quand tu postules pour du React. Tes projets backend en haut quand tu postules pour du back.

4. Une présentation claire et soignée

Pour un dev frontend, l'esthétique du portfolio est elle-même un projet. Pour un dev backend, on est plus tolérant, mais la présentation reste un signal. Un portfolio qui a l'air bâclé, c'est un dev qui pourrait livrer du code bâclé.

Pas besoin de design exceptionnel. Sobre, lisible, structuré, ça suffit largement. Une bonne typographie, un peu d'espace, des sections claires.

5. Un signe de continuité dans le métier

Le recruteur veut voir que tu fais ça sérieusement, pas en dilettante. Un blog technique, des contributions open source, des articles, des talks, un profil LinkedIn actif. Tout ce qui montre que tu existes dans la communauté tech, même modestement.

Un seul article de blog qui raconte un projet en détail vaut plus que dix projets sans contexte.

Exemple : la différence entre un portfolio bavard et un portfolio efficace

Portfolio bavard (à éviter) : douze projets listés, dont un convertisseur de température, une calculatrice, un todo-list, un site portfolio "à propos de moi", un clone de Tinder, trois projets d'examen, deux fork de tutoriels. Pas de démo sur la moitié. Trois projets avec README inexistant. Une vidéo de présentation sur la page d'accueil qui dure 4 minutes.

Portfolio efficace (à reproduire) : trois projets mis en avant, présentés sous forme de cartes claires :

• Une application météo avec géolocalisation. Stack : React, OpenWeather API, Vercel. Démo cliquable. Lien GitHub avec README détaillé. Capture d'écran d'accueil.
• Une API REST de gestion de bibliothèque personnelle. Stack : Node, Express, PostgreSQL, déployée sur Render. Documentation Swagger accessible. Tests automatisés visibles dans le repo.
• Un dashboard Twitch qui affiche les streamers en ligne. Stack : Next.js, Twitch API, TypeScript. Démo en ligne avec connexion réelle.

Le deuxième portfolio gagne, même si la personne du premier a plus travaillé. Parce que le recruteur peut le scanner en dix secondes, identifier ce que sait faire le candidat, et décider d'aller voir le code.

Note bien : ni le projet météo ni le projet Twitch ne sont des projets originaux. Ce sont des projets classiques bien exécutés. C'est l'exécution qui fait la différence, pas l'originalité de l'idée.

Pièges classiques à éviter

Mettre en avant des projets de tutoriel

Tu mets le projet "Pokedex avec React" en première position. Le recruteur le reconnaît instantanément, parce que c'est le tutoriel le plus suivi de YouTube. Tu viens de signaler que tu reproduis, tu ne crées pas.

Les projets de tutoriel n'ont pas leur place sur ton portfolio principal. Tu peux les laisser sur GitHub sans les mettre en avant. Si tu n'as que des projets de tutoriel, tu n'as pas encore de portfolio, tu as une collection d'exercices.

Cacher la stack technique

Tu présentes un projet sans mentionner les technologies utilisées, en pensant que ça doit se deviner. Le recruteur ne devine pas. Il scanne. Et si le mot "React" n'apparaît pas, il considère que tu n'as pas fait du React.

Pour chaque projet, tu listes la stack en évidence, sous forme de badges ou de tags. C'est le premier truc qu'on regarde après le titre.

Mettre une bio gigantesque sur la page d'accueil

Tu commences par trois paragraphes sur ton parcours, ta passion pour le code, ton chemin de reconversion. Le recruteur ne lit pas tout ça. Il ne lit jamais tout ça.

Une phrase suffit. "Développeur web fullstack JavaScript/TypeScript, en reconversion après dix ans dans la finance." C'est tout. Le reste est dans la section "À propos" pour qui veut creuser.

Mettre des stats de "skill" en pourcentages

Les barres "JavaScript : 85%", "React : 70%". Personne ne sait ce que ça veut dire, et tout le monde devine que tu as choisi le chiffre toi-même. Ça nuit à ta crédibilité plus que ça ne te sert.

Une simple liste des technologies que tu maîtrises est plus honnête et plus lisible. Si tu veux nuancer, tu peux ajouter "Confirmé sur" et "En apprentissage".

Laisser un projet cassé en ligne

Pire que ne pas avoir de démo : avoir une démo qui plante. Le recruteur clique, voit une erreur 500 ou un écran blanc, ferme. Tu perds plus que tu ne gagnes.

Tu testes chaque démo une fois par mois, depuis un navigateur incognito sur ton téléphone. Si quelque chose est cassé, tu répares ou tu retires.

Ne pas avoir d'identité visuelle cohérente

Ton portfolio est en bleu, tes captures sont en violet, ton CV est en rouge, ton LinkedIn n'a pas de couleur. Visuellement, ça donne l'impression que tu n'as pas réfléchi à comment tu te présentes.

Tu choisis deux ou trois couleurs et tu les appliques partout. C'est un détail qui n'a l'air de rien et qui change la perception.

Le portfolio minimum efficace en quatre points

Voici à quoi devrait ressembler ton portfolio si tu repars de zéro aujourd'hui.

Une page d'accueil avec ton nom, une phrase de présentation, et trois projets phares présentés en cartes. Pour chaque projet : un titre, une phrase, la stack, un lien démo, un lien GitHub.

Une section "À propos" plus longue, pour ceux qui veulent connaître ton parcours. Photo si tu veux, parcours résumé, motivation. Pas plus de quatre paragraphes.

Une section "Contact" avec ton email, ton LinkedIn, ton GitHub. Pas de formulaire compliqué qui ne marche pas la moitié du temps.

Optionnel mais valorisant : une section "Écrits" ou "Blog" avec deux ou trois articles techniques, même courts. Cela signale ta curiosité et ta capacité à expliquer ce que tu fais.

Pour aller plus loin

Si tu n'as pas encore de projets sérieux à mettre en avant, l'article sur comment construire un portfolio quand on n'a aucun client propose une démarche concrète. Pour comprendre les erreurs plus larges côté juniors, l'article sur les 10 erreurs qui font fuir les recruteurs tech couvre les autres signaux qui pèsent en candidature.

Côté formation, si tu cherches à muscler ton portfolio sur des technos demandées, les modules React, Next.js et Fullstack React + Symfony incluent tous un projet complet pensé pour être ajouté au portfolio.

Questions fréquentes