Ton portfolio est en ligne. Propre, animé, responsive, sorti en un après-midi avec un générateur d'interface, puis rempli tout le week-end. Douze projets au compteur. Le lien part dans quinze candidatures. Deux réponses automatiques, aucun entretien.
Le réflexe suivant est souvent d'en rajouter. Un projet de plus, une refonte du design, des barres de compétences. Le portfolio grossit, la boîte mail reste vide.
Un recruteur tech passe entre six et quinze secondes sur un portfolio avant de décider s'il continue. Cette durée n'a pas bougé depuis deux ans. Ce qui a changé, c'est le volume de candidatures qu'il traite et le fait qu'un beau portfolio ne coûte plus ni temps ni compétence. Quand tout le monde peut produire la même vitrine en dix minutes, la vitrine arrête de servir de filtre, et le filtre se déplace ailleurs.
Cet article détaille ce que contiennent ces dix secondes en 2026, où s'est déplacé le signal depuis l'arrivée des assistants de code dans les équipes, et comment présenter trois projets qu'un recruteur peut tester, comprendre et discuter en entretien.
Le problème : le soin visuel ne prouve plus rien
Pendant des années, un portfolio bien fini disait quelque chose de son auteur : il savait écrire du CSS, structurer une page, déployer un site. Le contenant faisait office de preuve. Aujourd'hui, un prompt de dix lignes sort une page complète avec hero, cartes projets, animations au scroll et mode sombre. Lovable, v0 et Bolt ont fait de la belle page un consommable.
Le recruteur le sait. Il a vu passer quarante portfolios en shadcn/ui ce mois-ci, même typographie, même dégradé. Sa lecture s'est déplacée vers ce qu'un générateur ne produit pas à ta place : un usage réel, un historique de travail, une capacité à expliquer ce qui tourne.
S'ajoute à cela un climat de méfiance. Le rapport 2026 de Greenhouse sur l'IA dans le recrutement indique que 91 % des responsables de recrutement américains ont détecté ou suspecté une tricherie assistée par IA dans les candidatures. Une part de cette suspicion retombe sur des candidats honnêtes dont le seul tort est d'avoir un dossier trop lisse. Un portfolio impeccable sans aucune trace de fabrication humaine derrière déclenche un doute qu'il ne déclenchait pas il y a deux ans.
La quantité pose le même souci qu'avant, en pire. Douze projets dont dix sortis d'une soirée de génération ne montrent pas dix fois plus de compétence, ils montrent une absence de tri. Le recruteur en déduit que tu ne trieras pas mieux dans une base de code.
Le principe : les six signaux du scan de dix secondes
Quand un recruteur ouvre ton portfolio, il enchaîne des vérifications rapides. Si les trois premières passent, il ouvre ton code. Sinon il ferme l'onglet.
1. Quelque chose qui tourne, tout de suite
Le premier réflexe reste de cliquer et d'utiliser, pas de lire ta description. Un projet sans démo accessible n'existe pas dans son évaluation.
Chaque projet mis en avant porte un lien visible vers une instance en ligne. Vercel, Netlify, Render, Railway, Fly.io, l'hébergeur importe peu tant que ça répond.
2. Un projet que quelqu'un d'autre que toi utilise
Voilà le signal qui a pris le plus de valeur en deux ans. Une démo prouve que le code s'exécute. Des utilisateurs prouvent que tu as géré ce que la génération automatique ne gère pas : un formulaire rempli n'importe comment, une authentification à maintenir, un bug remonté par quelqu'un qui ne lit pas les logs, une décision de produit à trancher.
Le seuil est bas. Un outil interne utilisé par l'association sportive du quartier, un bot Discord installé sur deux serveurs, une extension de navigateur avec trente installations. Trente utilisateurs réels pèsent plus lourd qu'un clone d'application connue avec zéro.
3. Un historique Git qui raconte un travail
Le deuxième clic va sur ton GitHub, et ce qu'on y regarde a changé. Le graphe d'activité vert compte moins qu'avant, parce que tout le monde a compris comment le remplir. L'attention s'est portée sur l'historique de commits lui-même.
Un dépôt avec un commit unique de 4 000 lignes intitulé "add project" indique qu'un agent a tout produit d'un coup et que personne n'a relu. Des commits petits, étalés sur plusieurs jours, avec des messages du type "fix: pagination cassée quand la liste est vide", indiquent un humain qui construit, teste et corrige.
Le README garde son rôle de porte d'entrée : ce que fait le projet, comment le lancer, la stack, une capture. Ajoute une ligne sur les limites connues, celle que personne n'écrit et qui rassure toujours.
4. Une trace de discipline face au code généré
Les entreprises ne cherchent plus des candidats qui refusent les assistants, mais des candidats capables de relire ce qu'ils produisent. Plusieurs cabinets ont remplacé l'exercice algorithmique par une revue de code : un fichier généré, une méthode qui n'existe pas et un appel déprécié glissés dedans, à toi de les trouver en expliquant comment.
Mon avis, et il ne fait pas l'unanimité : assume l'usage de l'IA sur ton portfolio au lieu de le cacher. Une section courte dans le README, du type "l'ossature du service de paiement vient d'un assistant, j'ai réécrit la gestion des erreurs après avoir vu qu'il avalait les échecs silencieusement", te place immédiatement du côté des candidats qui relisent. Ceux qui masquent tout se retrouvent à devoir défendre en entretien un code qu'ils n'ont jamais examiné.
5. Un problème identifiable, pas une démonstration de stack
Lister React, TypeScript et PostgreSQL sous une carte projet ne dit rien de ton jugement. Nommer le problème et le résultat, oui. "Les inscriptions au club se faisaient par SMS, le trésorier passait deux heures par semaine à recopier dans un tableur, l'appli a supprimé cette étape" fait le travail de trois paragraphes.
La stack reste visible sous forme de tags, en dessous. Le recruteur scanne les mots-clés de l'offre, il faut qu'ils apparaissent, mais ils ne portent plus la valeur du projet.
6. Un signe que tu existes dans le métier
Un article qui raconte un bug et sa résolution, une contribution acceptée sur un projet open source, un profil LinkedIn où tu publies autre chose que des félicitations. Un seul texte qui explique une décision technique vaut plus que dix projets muets, avec un avantage nouveau : c'est difficile à fabriquer en série.
Exemple : deux portfolios pour le même niveau réel
Le portfolio qui se fait fermer : douze projets, un assistant conversationnel sur PDF, un clone de plateforme de streaming, un générateur d'images, deux projets d'examen, trois dépôts issus de tutoriels. Chaque carte affiche une liste de technos et une phrase générique. Six projets sans démo, quatre dépôts avec un seul commit. Sur la page d'accueil, une vidéo de présentation de quatre minutes.
Le portfolio qui obtient un entretien : trois projets, présentés par le problème qu'ils règlent.
- Gestion des inscriptions d'un club de handball amateur. Utilisé par le bureau du club depuis huit mois, environ 140 licenciés enregistrés. Stack Next.js et PostgreSQL, déployé sur Vercel. Le README explique la migration des données depuis un tableur et pourquoi les paiements passent par un lien externe plutôt que par une intégration maison.
- Une API de suivi des prix sur une liste de produits. Node, Fastify, tâche planifiée quotidienne, documentation OpenAPI en ligne. Tests automatisés visibles, historique de commits étalé sur trois mois avec des correctifs datés.
- Une extension navigateur qui nettoie une interface pénible à utiliser. Publiée sur le store, quelques dizaines d'installations, deux issues ouvertes par des utilisateurs et refermées par des correctifs.
Le second candidat n'a pas forcément écrit plus de lignes que le premier, et il a pu générer une partie de son code. La différence tient à ce qu'un recruteur peut vérifier en quelques secondes puis discuter pendant quarante minutes.
Aucun de ces trois projets n'est original. Une gestion d'inscriptions, un suivi de prix, une extension de confort, ces idées traînent partout. L'exécution et l'usage font la différence, pas l'idée.
Les pièges spécifiques à 2026
Mettre en avant un projet que tu ne peux pas expliquer
C'est le piège numéro un et il coûte l'entretien entier. Le recruteur ouvre ton dépôt, pointe une fonction, demande pourquoi cette approche. Si la réponse est un silence, la conversation est terminée.
La règle de sécurité tient en une phrase : ne mets en avant que du code dont tu peux défendre chaque décision. Le reste peut rester sur GitHub sans être mis en vitrine.
Le nouveau projet de tutoriel
Le clone de Pokedex a été remplacé par l'assistant qui répond sur tes PDF. Même mécanique, même reconnaissance immédiate : le recruteur a vu ce projet cinquante fois ce trimestre, avec les mêmes bibliothèques et souvent la même arborescence de fichiers.
Un projet qui appelle une API de modèle de langage tient la route s'il traite un corpus précis pour un usage précis, avec un jeu de tests sur les réponses. Sans cela, c'est le todo-list de 2026.
Une démo qui plante ou qui a épuisé son quota
Le lien mort a désormais une variante. Ta démo appelle un modèle via une clé API, le crédit est épuisé depuis trois semaines, le recruteur tombe sur une erreur 429 au premier essai. Pire, la clé se retrouve exposée côté navigateur et un inconnu la consomme à ta place.
Passe tes appels par un backend, garde la clé côté serveur, mets une limite de requêtes, et prévois un mode dégradé qui affiche un résultat pré-calculé quand le quota tombe. Teste tes démos une fois par mois depuis une fenêtre privée sur ton téléphone.
Un README qui sent le texte généré
Une documentation de quatre-vingts lignes bourrée de superlatifs, de listes parfaitement équilibrées et de tirets cadratins produit l'effet inverse de celui recherché. Les recruteurs ont appris à repérer ces marqueurs sur les CV, ils les repèrent aussi sur un dépôt.
Un README court, écrit avec tes mots, qui mentionne une limitation et un choix regretté, passe bien mieux qu'une brochure.
Les barres de compétences en pourcentage
"JavaScript : 85 %", "React : 70 %". Personne ne sait sur quelle échelle, et tout le monde devine que le chiffre sort de nulle part. Une liste simple, séparée entre ce que tu pratiques régulièrement et ce que tu apprends, est plus lisible et plus honnête. Ce piège survit à toutes les modes, il reste présent sur la majorité des portfolios que je relis en fin de formation.
Le portfolio minimum efficace, version 2026
Une page d'accueil avec ton nom, une phrase de positionnement du type "développeur web fullstack JavaScript, en reconversion après dix ans dans la logistique", et trois projets en cartes visibles sans défilement sur un écran de portable. Le récit de parcours attend plus bas, personne ne le lit avant d'avoir vu les projets. Chaque carte porte un titre, le problème réglé en une phrase, la stack en tags, un lien démo et un lien code.
Sur chaque dépôt, un README de trente lignes maximum, une capture, une note sur ce qui est généré et ce que tu as réécrit, une autre sur les limites connues.
Une section À propos plus longue, quatre paragraphes au plus. Une section Contact avec email, LinkedIn et GitHub, sans formulaire fragile. Un ordre de projets réorganisé selon l'offre visée, cinq minutes par candidature qui changent le premier coup d'oeil.
Reste ce que ce format ne résout pas : si tes trois projets n'ont jamais rencontré d'utilisateur, la vitrine sera propre et le fond léger. Trouver ces premiers utilisateurs est le chantier de l'année, et il commence par une association, un commerçant ou un ancien collègue à qui tu proposes de régler un problème précis.
Pour aller plus loin
Si tu n'as pas encore de projet sérieux à montrer, l'article sur comment construire un portfolio quand on n'a aucun client propose une démarche pas à pas, et celui sur le premier projet à mettre sur un CV de junior aide à choisir quoi construire en premier. Pour la suite du processus, l'analyse de ce qu'on te demande en entretien technique junior décrit les exercices qui tombent réellement, et l'article sur les erreurs qui font fuir les recruteurs tech couvre les autres signaux d'une candidature.
Côté formation, les modules React, Fullstack avec Next.js et Fullstack React + Symfony se terminent par une application complète, pensée pour être déployée et défendue en entretien. Pour l'usage des modèles de langage dans une application, la formation Prompt Engineering et API LLM couvre ce que les recruteurs testent aujourd'hui.
