Pour les designers et les développeurs front-end, le portfolio compte souvent plus que le CV. C'est la preuve. Un CV affirme que vous savez faire le travail ; un portfolio montre le travail et, surtout, comment vous y réfléchissez.
La plupart des portfolios échouent de l'une de deux façons : trop de projets médiocres, ou de belles captures d'écran sans explication du problème, de votre rôle ou du résultat. Ce guide corrige les deux.
Points clés
- Trois à cinq projets solides battent une douzaine de projets moyens — les évaluateurs y consacrent deux à trois minutes au total.
- Chaque projet a besoin de la même ossature : problème, votre rôle, processus, solution, impact.
- Montrez le milieu désordonné — croquis, itérations, arbitrages — pas seulement l'écran final soigné.
- Développeurs : un lien actif plus un README propre plus du code lisible pèsent plus qu'un site sophistiqué.
Choisir ce qui y figure
- 1Listez chaque projet que vous pourriez montrer — travail, freelance, projets perso, travaux d'études, hackathons, open source.
- 2Notez chacun selon : la pertinence pour les postes que vous voulez, la part du résultat que vous pouvez revendiquer, et si vous pouvez expliquer votre contribution précise.
- 3Gardez les 3-5 meilleurs. Écartez tout ce que vous devriez fortement nuancer ou dont vous ne pouvez pas parler à cause d'un accord de confidentialité.
- 4Assurez-vous que l'ensemble montre de la variété — des types de problèmes différents, pas cinq versions du même écran.
Un projet personnel dont vous pouvez parler en profondeur bat un vrai projet que vous avez à peine touché. Redessinez un produit que vous utilisez, construisez un outil dont vous aviez besoin, ou contribuez à un dépôt open source.
La structure de l'étude de cas
Une étude de cas est une histoire courte à la forme fixe. Visez quelque chose qu'un lecteur peut parcourir en deux minutes et lire entièrement en cinq.
1. Aperçu (2-3 phrases) Ce qu'est le produit, pour qui, quel était le projet. 2. Mon rôle Votre intitulé, l'équipe, la période, ce dont vous étiez responsable par rapport à ce à quoi vous avez contribué. 3. Le problème Le problème utilisateur ou métier, et comment vous saviez qu'il était réel (données, recherche, plaintes). 4. Processus Les 3-4 mouvements clés que vous avez faits. Montrez des artefacts : croquis, flux, prototypes, expériences, PR. Incluez au moins un arbitrage ou une impasse et pourquoi vous avez changé de direction. 5. La solution Le résultat final, avec des visuels ou un lien actif. Annotez les décisions qui comptent. 6. Impact Des chiffres si vous en avez (conversion, temps de chargement, réussite de tâche, adoption). Sinon, des résultats qualitatifs et ce que vous mesureriez ensuite. 7. Ce que j'ai appris Une ou deux réflexions honnêtes.
Au lieu de
« J'ai repensé le tunnel de commande pour améliorer l'expérience utilisateur. » + 4 captures d'écran soignées.
Écrivez
« L'abandon de panier était de 68 % sur mobile. J'ai mené 5 sessions utilisateurs, trouvé que le formulaire d'adresse était le point de sortie, testé une autocomplétion à 2 champs contre l'original à 9 champs et déployé le gagnant. L'abandon est tombé à 51 % en 6 semaines. » + avant/après + les deux prototypes testés.
Si vous êtes développeur
- Chaque projet : un lien de démo en direct et un lien de dépôt, tous deux fonctionnels. Une démo cassée est pire que pas de démo.
- Rédigez un vrai README : ce qu'il fait, une capture ou un GIF, la stack technique, comment le lancer en local, ce que vous feriez ensuite.
- Épinglez vos 4-6 meilleurs dépôts sur votre profil GitHub et ajoutez un README de profil.
- Mettez en avant les signaux de qualité du code : tests, CI, commits clairs, structure sensée. Les évaluateurs ouvrent bel et bien le code.
- Les contributions open source comptent — reliez les PR fusionnées et dites brièvement ce que chacune a fait.
- Pour les postes back-end ou data où rien n'est visuel, un schéma d'architecture clair et un exposé écrit remplacent les captures d'écran.
# Nom du projet Une phrase sur ce qu'il fait et pour qui.  ## Pourquoi je l'ai construit 2-3 phrases. ## Stack Langages, frameworks, bibliothèques notables, hébergement. ## Le lancer en local Étapes. ## Décisions notables - Décision et sa raison - Un arbitrage que vous avez fait ## La suite Courte liste.
Si vous êtes designer
- Montrez les artefacts du processus, pas seulement les comps finales : notes de recherche, flux utilisateurs, wireframes, itérations.
- Incluez les versions non livrées et dites pourquoi — cela démontre du jugement.
- Gardez un haut niveau visuel sur le site du portfolio lui-même ; c'est un échantillon de travail que vous le vouliez ou non.
- Reliez chaque décision à un besoin utilisateur ou un objectif métier, pas au goût personnel.
- Pour les postes UX, commencez par la réflexion ; pour les postes visuels ou de marque, commencez par le savoir-faire — mais les deux ont besoin des deux.
Où l'héberger
- Un site personnel sur votre propre domaine est l'option la plus forte — contrôle total, donne une impression d'engagement.
- Rapide à publier : un modèle sur un créateur de sites, ou un site statique simple sur GitHub Pages, Vercel ou Netlify.
- Les designers peuvent compléter avec Behance ou Dribbble pour la portée, mais gardez les vraies études de cas sur votre propre site.
- Développeurs : GitHub n'est pas négociable ; un site portfolio est un plus.
- Ayez toujours une version PDF ou diapositives d'une ou deux études de cas pour quand quelqu'un demande par e-mail.
Un portfolio avec des animations sur mesure qui prend des semaines et ne contient toujours qu'un projet n'aide personne. Publiez d'abord un site simple et rapide avec trois vraies études de cas, puis améliorez-le.
Erreurs courantes
- Trop de projets, aucun expliqué en profondeur.
- Des captures d'écran sans énoncé du problème, rôle ni résultat.
- Revendiquer des résultats d'équipe sans dire ce que vous avez fait personnellement.
- Aucune information de contact ni moyen évident de vous joindre.
- Des liens protégés par mot de passe ou cassés dans la version envoyée aux recruteurs.
- Enterrer le meilleur projet en troisième page.
Passez à la pratique
Créez gratuitement un CV compatible ATS — aide à la rédaction par IA, téléchargements illimités, sans filigrane.
Commencer mon CVQuestions fréquentes
Combien de projets un portfolio doit-il contenir ?
Trois à cinq. Les évaluateurs dépassent rarement le troisième. La profondeur sur quelques-uns bat l'étendue sur beaucoup.
Puis-je inclure un travail sous accord de confidentialité ?
Parlez-en d'abord à votre entreprise. Souvent, vous pouvez montrer le processus et les résultats à haut niveau sans exposer de détails confidentiels ni d'écrans non publiés. En cas de doute, décrivez-le avec des mots plutôt que de le montrer.
Ai-je besoin d'un portfolio si je suis développeur back-end ?
Un site portfolio est facultatif, mais un profil GitHub solide avec des dépôts épinglés, de bons README et des contributions visibles fait le même travail.
Qu'est-ce qui vient en premier, le portfolio ou le CV ?
Mettez le lien du portfolio en haut de votre CV et de LinkedIn. Pour les postes de design et front-end, attendez-vous à ce que le portfolio soit examiné avant que quiconque lise le CV attentivement.