Carnet ouvert aux pages blanches posé sur un bureau sombre à côté d'un porte-mine, illustration d'un portfolio développeur à construire

Portfolio développeur : comment le construire pour décrocher entretiens et clients

L’essentiel en une minute

Un portfolio développeur sert à prouver, avant l’entretien ou l’appel, que vous savez livrer. Pour un junior, une personne en reconversion ou un freelance, c’est souvent la seule preuve qu’un recruteur ou un client peut vérifier sans vous avoir rencontré.

Ce guide suit neuf étapes, du choix des projets aux mentions légales. Il repose sur des sources publiques consultées le 26 octobre 2026 : enquêtes, documentations officielles, textes de loi et recommandations de la CNIL. Aucun test maison n’a été mené.

Points clés

  • Montrez peu de projets, mais documentés : 3 à 5 études de cas avec le problème, la stack, vos décisions, le résultat, le code et la démo.
  • Selon les données de plateforme de HackerRank, éditeur de tests techniques, l’activité de recrutement a progressé en 2024 de 9 % pour les juniors contre 19 % pour les seniors. Notre lecture : les débutants ont intérêt à compenser par des preuves.
  • L’offre gratuite de Vercel est réservée à un usage personnel non commercial : selon notre lecture, un portfolio qui vend des prestations relève de l’offre payante.
  • Un particulier peut rester anonyme en affichant son hébergeur ; un freelance doit publier des mentions légales complètes.
  • Visez les seuils « bons » des Core Web Vitals : LCP de 2,5 secondes, INP de 200 millisecondes, CLS de 0,1 au plus.

1. Comprendre le marché et ce qu’il faut prouver

Le marché est tendu, surtout pour les débutants. Le rapport 2025 de HackerRank, éditeur de tests techniques, indique que 74 % des développeurs interrogés peinent à décrocher un poste malgré une hausse du recrutement. L’enquête a porté sur 13 732 développeurs, managers, recruteurs, dirigeants et étudiants dans 102 pays, fin 2024 et début 2025 (HackerRank, Developer Skills Report 2025, consulté le 26 octobre 2026). Si vous changez de métier, notre guide de la reconversion développeur web fait le point sur le marché junior, les formations et leur financement.

D’une année sur l’autre, l’activité de recrutement mesurée sur la plateforme de l’éditeur a progressé de 22 % pour les lead developers, de 19 % pour les seniors, de 9 % pour les juniors et de 7 % pour les postes d’entrée. Ce sont des données de HackerRank, issues de son propre outil d’évaluation.

Graphique en barres horizontales : hausse de l'activité de recrutement en 2024 selon HackerRank, 7 % pour les postes d'entrée, 9 % pour les juniors, 19 % pour les seniors et 22 % pour les lead developers

Le même rapport relève que 66 % des développeurs préfèrent être évalués sur des compétences réelles plutôt que sur des tests théoriques. C’est une préférence de candidats, publiée par un éditeur qui vend ce type de tests. Notre lecture : un projet en ligne au code lisible montre justement des compétences réelles, avant tout test.

Côté freelance, l’enquête Stack Overflow 2026 indique que 10,5 % des 21 115 répondants à la question sur la taille de leur organisation travaillent seuls, en freelance ou en entreprise individuelle. Dans son commentaire, Stack Overflow arrondit et écrit que cette part a plus que doublé en un an, de 4 % à 10 % (Stack Overflow Developer Survey 2026, chapitre Work, consulté le 26 octobre 2026). Plus de répondants indépendants, c’est vraisemblablement plus de profils à départager.

Verdict : rendez la vérification facile. Un lecteur pressé doit comprendre ce que vous faites, pour qui, et voir la preuve que cela fonctionne.


2. Choisir 3 à 5 projets pour votre portfolio développeur

Trois à cinq projets suffisent, s’ils sont cohérents avec le poste ou la mission visés. Un portfolio développeur avec quinze dépôts inachevés oblige le lecteur à trier ; trois projets aboutis lui épargnent ce travail.

Choisissez des projets qui couvrent des compétences différentes :

  • Un projet complet. Interface, logique serveur et base de données. Pour le back-end, une API REST avec Node.js et Express documentée et testée vaut mieux qu’une interface de plus.
  • Un projet avec un vrai utilisateur. Le site d’une association, l’outil interne d’un proche : des contraintes et des retours réels. Demandez l’accord de la personne avant de la citer.
  • Une contribution open source. Une pull request acceptée montre que vous savez lire le code des autres.
  • Un projet lié à votre spécialité. Données, IA, sécurité ou mobile : celui qui ressemble le plus au poste visé.

Un projet livré en conteneur rassure aussi : un docker compose up qui lance l’application évite au recruteur de deviner vos dépendances. Notre tutoriel Docker pour débutants montre comment y arriver.

Verdict : si un recruteur ne devait regarder qu’un projet, lequel lui donnerait envie de vous appeler ? Mettez-le en premier.


3. Rédiger une étude de cas par projet

Une capture d’écran et une liste de technologies ne disent pas comment vous travaillez ; une étude de cas, si. Notre conseil éditorial : 200 à 400 mots par projet, en cinq rubriques.

  1. Le problème. Pour qui, quel besoin, quelle contrainte (délai, budget, public).
  2. La stack. Les technologies, et pourquoi celles-là.
  3. Vos décisions. Deux ou trois choix techniques expliqués, avec ce que vous avez écarté.
  4. Le résultat. Ce qui fonctionne, ce qui reste à faire, ce que vous referiez autrement. Ne citez un chiffre que si vous pouvez le prouver.
  5. Les liens. Le dépôt de code et la démo en ligne, côte à côte.

Précisez votre rôle quand le projet a été mené à plusieurs : « J’ai conçu l’API et la base de données ; l’interface a été réalisée par une autre personne. » En entretien, on vous interrogera sur chaque ligne. Notre guide de l’entretien technique développeur détaille les étapes et les questions classiques pour s’y préparer.

Si vous avez codé avec un assistant IA, dites-le et expliquez ce que vous avez vérifié vous-même : notre article freelance et IA montre comment présenter cette compétence comme un atout.

Verdict : une bonne étude de cas répond d’avance à la question d’entretien : « Pourquoi avez-vous fait ce choix ? »


4. Soigner son profil GitHub

Le lien GitHub figure souvent à côté du portfolio dans une candidature ; deux réglages documentés changent sa lisibilité : le README de profil et les dépôts épinglés. Si vous n’avez encore jamais poussé un projet, commencez par notre guide Git et GitHub pour débutant.

Le README de profil s’affiche en haut de votre page publique si quatre conditions sont réunies : un dépôt portant exactement votre nom d’utilisateur, public, avec un fichier README.md non vide à la racine (GitHub Docs, README de profil, consulté le 26 octobre 2026).

GitHub permet d’épingler jusqu’à six éléments, dépôts et gists confondus, puis de les réordonner (GitHub Docs, épingler des éléments). Épinglez les projets de votre portfolio, dans le même ordre.

Chaque dépôt épinglé mérite son README. Selon GitHub, il indique en général ce que fait le projet, pourquoi il est utile, comment démarrer, où trouver de l’aide et qui le maintient (GitHub Docs, à propos des README).

Sur LinkedIn, la section « Sélection » accepte des liens vers des sites externes, par exemple un blog ou un portfolio, ainsi que des images, documents et vidéos (aide LinkedIn, consultée le 26 octobre 2026).

Verdict : un README de profil court, six épingles et un README par projet suffisent. Notre sélection d’extensions VS Code aide à garder code et Markdown propres.


5. Choisir l’hébergement : 4 offres gratuites comparées

Quatre hébergeurs courants ont un niveau gratuit, aux règles d’usage différentes. Limites relevées le 26 octobre 2026 :

Critère GitHub Pages Netlify (Free) Vercel (Hobby) Cloudflare Pages (Free)
Prix Gratuit 0 $, 300 crédits par mois Gratuit Gratuit
Trafic Limite souple de 100 Go par mois 20 crédits par Go, 2 crédits par 10 000 requêtes 100 Go de Fast Data Transfer par mois Fichiers statiques gratuits et illimités
Déploiements 10 builds par heure (limite souple, sauf workflow GitHub Actions personnalisé) 15 crédits par déploiement en production 100 par jour 500 builds par mois
Taille Site de 1 Go au plus Non relevé Envoi CLI de 100 Mo au plus 20 000 fichiers, 25 Mio par fichier
Usage commercial Ni activité en ligne, ni e-commerce, ni SaaS Non précisé Interdit Aucune restriction dans le contrat général
Dépassement Site non servi ou e-mail du support Sites mis en pause Attente de 30 jours le plus souvent Non précisé

Sources : GitHub Pages, crédits Netlify, offre Hobby de Vercel, limites et tarification de Cloudflare Pages, contrat Self-Serve de Cloudflare.

Le piège pour les freelances est chez Vercel. Ses règles d’usage équitable qualifient de commercial tout déploiement servant le gain financier d’une personne impliquée, et citent la promotion d’un produit ou d’un service (Vercel, Fair Use Guidelines). Selon notre lecture, un portfolio qui présente vos offres entre dans cette définition : il faut l’offre Pro, à 20 $ par développeur et par mois selon la page Hobby, ou un autre hébergeur.

Chez Netlify, la limite est stricte : crédits épuisés, tous les projets sont mis en pause et affichent « Site not available », sans achat de crédits possible sur l’offre gratuite. À 15 crédits par déploiement, 300 crédits permettent au plus 20 mises en production par mois, selon notre calcul, trafic non compté. Les comptes créés avant le 4 septembre 2025 restent sur une ancienne offre, dite Legacy (Netlify, offres à crédits).

Chez Cloudflare, le contrat Self-Serve, mis à jour le 12 septembre 2025, ne réserve pas l’offre gratuite à un usage non commercial, mais permet à Cloudflare de mettre fin à un service gratuit à sa seule discrétion. GitHub Pages exclut les sites dont l’objet principal est de faciliter des transactions commerciales : un portfolio de candidat n’est pas concerné, un site de prestataire reste en zone grise. Pour aller au-delà du gratuit, voyez notre guide de l’hébergement cloud pour développeurs.

Verdict : pour un candidat salarié, les quatre conviennent. Pour un freelance, Cloudflare Pages est la seule offre gratuite du tableau dont nous avons lu un contrat général sans restriction commerciale ; une offre payante reste l’option la plus sûre. Notre guide pour automatiser ses déploiements explique comment brancher le déploiement sur votre dépôt.


6. Construire le site et brancher un domaine

Un portfolio développeur efficace tient en quatre pages, ou quatre sections d’une seule page : un en-tête qui dit qui vous êtes et ce que vous cherchez, les projets avec leurs études de cas, une courte présentation, et un contact. Un CV téléchargeable est un bonus utile : notre guide du CV développeur junior explique comment le structurer en une page.

Pour la construction, trois voies se valent. Un modèle adapté va vite ; un générateur de site statique produit des pages légères faciles à héberger sur les offres ci-dessus ; un site codé à la main devient lui-même un projet à montrer, surtout pour un poste front-end. Le choix compte moins que le résultat : rapide, lisible, à jour.

Une adresse à votre nom survit ensuite à un changement d’hébergeur. Les quatre services acceptent un domaine personnalisé ; Vercel en autorise 50 par projet sur l’offre Hobby, Cloudflare Pages 100 sur l’offre gratuite.

Pour GitHub Pages, la documentation recommande d’utiliser toujours un sous-domaine www, même avec le domaine nu, et de vérifier le domaine avant de l’ajouter pour éviter une prise de contrôle par un tiers, puis de cocher « Enforce HTTPS » dans les réglages (GitHub Docs, domaines personnalisés).

L’extension .dev impose le HTTPS : le registre de Google indique qu’elle figure dans la liste de préchargement HSTS (Google Registry, .dev, consulté le 26 octobre 2026). Un site servi en HTTP simple ne s’y affichera pas.

Verdict : quatre sections, une construction simple, votre nom en domaine et le HTTPS forcé.


7. Vérifier accessibilité et performance

Un portfolio développeur lent ou inutilisable au clavier contredit ce qu’il veut démontrer. Deux références suffisent : les Core Web Vitals pour la performance, les WCAG pour l’accessibilité.

Selon web.dev, un bon LCP (affichage du plus gros élément) est de 2,5 secondes au plus, un bon INP (réactivité) de 200 millisecondes au plus, un bon CLS (stabilité de la mise en page) de 0,1 au plus. Ils deviennent « mauvais » au-delà de 4 secondes, 500 millisecondes et 0,25, mesurés au 75e centile des visites (web.dev, seuils des Core Web Vitals, consulté le 26 octobre 2026).

Graphique en bandes : seuils des Core Web Vitals à viser pour un portfolio développeur, bon jusqu'à 2,5 secondes pour le LCP, 200 millisecondes pour l'INP et 0,1 pour le CLS, mauvais au-delà de 4 secondes, 500 millisecondes et 0,25

Ces seuils s’appliquent à des données de terrain. PageSpeed Insights ne les affiche que si la page a assez de visites réelles dans le rapport CrUX de Chrome, ce qui manque souvent à un site récent ou peu visité (PageSpeed Insights). En laboratoire, certains outils ne mesurent pas l’INP ; web.dev cite alors le Total Blocking Time comme indicateur approchant, sans équivalence (web.dev, INP).

Le score Lighthouse sur 100 reste utile. La documentation de Chrome juge bon un score de 90 à 100 et précise qu’un 100 parfait n’est pas attendu (Chrome for Developers, score Lighthouse). Visez 90, pas 100.

Côté accessibilité, les WCAG 2.2 du W3C, version du 12 décembre 2024, posent deux règles faciles à vérifier : une alternative textuelle pour tout contenu non textuel, et un contraste d’au moins 4,5:1 pour le texte courant, 3:1 pour les grands textes (W3C, WCAG 2.2).

Verdict : un site statique aux images compressées passe ces seuils sans effort. Testez d’abord sur mobile.


8. Ajouter mentions légales et RGPD

Un portfolio développeur publié en France reste un site soumis à la loi. Ce qu’il doit afficher dépend d’une question : l’éditez-vous à titre personnel ou professionnel ?

À titre personnel, l’anonymat est possible. L’article 1-1 de la loi pour la confiance dans l’économie numérique, créé par la loi du 21 mai 2024, permet à qui édite un site à titre non professionnel de ne publier que le nom et l’adresse de son hébergeur, à condition de lui avoir communiqué son identité (Légifrance, LCEN, version en vigueur, consultée le 26 octobre 2026).

À titre professionnel, un entrepreneur individuel, micro-entrepreneur compris, doit afficher nom et prénom suivis de « entrepreneur individuel » ou « EI », adresse, e-mail, téléphone, numéro d’immatriculation, numéro de TVA s’il existe, et les coordonnées de l’hébergeur (Entreprendre.Service-Public.gouv.fr, consultée le 26 octobre 2026). L’article 1-2 de la même loi punit le non-respect de ces obligations d’identification d’un an d’emprisonnement et de 75 000 € d’amende pour une personne physique.

Un formulaire de contact collecte des données personnelles. La CNIL demande d’informer la personne au moment de la collecte, notamment de l’identité du responsable, de la finalité, de la base légale, des destinataires, de la durée de conservation, de ses droits et de la possibilité de saisir la CNIL (CNIL, information des personnes).

La mesure d’audience peut se passer de consentement si l’outil sert uniquement à mesurer l’audience pour le compte exclusif de l’éditeur, produit des statistiques anonymes, ne recoupe pas les données avec d’autres traitements, ne transmet pas de données non anonymes à des tiers et ne suit pas l’internaute d’un site à l’autre. La CNIL recommande en outre d’informer les visiteurs, par exemple dans la politique de confidentialité, et de limiter la durée de vie des traceurs à 13 mois et la conservation des données à 25 mois (CNIL, mesure d’audience).

Verdict : le plus simple est de ne rien collecter. Une adresse e-mail affichée remplace le formulaire ; un outil exempté évite le bandeau de cookies ; la CNIL recommande tout de même une mention dans la politique de confidentialité.


9. Freelance : Malt, témoignages et page tarifs

Pour un freelance, le portfolio doit déclencher une demande de devis : il dit ce que vous vendez, à qui, et comment vous joindre. Statut et fiscalité relèvent d’un autre sujet, traité dans notre guide pour devenir développeur freelance.

Sur Malt, le portfolio accepte jusqu’à 20 éléments mêlant texte, images, vidéos, liens, compétences, secteurs et dates. Chacun doit présenter un projet avec un titre clair, le contexte et votre rôle (aide Malt, compléter son profil, mise à jour le 6 août 2026).

La même page demande une description de profil d’au moins 200 caractères et des expériences d’au moins 100 caractères, idéalement autour de 300. Les vidéos doivent être publiques sur YouTube ou Vimeo. Vos études de cas s’y recopient presque telles quelles.

Les témoignages rassurent plus qu’une liste de technologies. Citez-les avec le nom, la fonction et l’accord écrit de la personne, renvoyez vers vos avis Malt ou vos recommandations LinkedIn, et ne reformulez jamais un avis.

Une page tarifs, même indicative, filtre les demandes : un tarif journalier « à partir de », les missions acceptées et vos délais suffisent. Pour situer vos prix, comparez-les aux salaires des développeurs en France, en gardant à l’esprit qu’un tarif de freelance couvre aussi charges et périodes sans mission.

Verdict : une offre claire, trois études de cas, des avis vérifiables et un contact visible sur chaque page.


La checklist avant d’envoyer le lien

  • [ ] L’en-tête dit en une phrase ce que vous faites et pour qui.
  • [ ] 3 à 5 projets, chacun avec une étude de cas, le code et une démo.
  • [ ] Toutes les démos s’ouvrent sur mobile, sans compte à créer.
  • [ ] Le README de profil GitHub s’affiche, les épingles reprennent le portfolio.
  • [ ] Un contact visible sur chaque page.
  • [ ] Lighthouse à 90 ou plus ; Core Web Vitals dans le vert dès que PageSpeed Insights affiche des données de terrain.
  • [ ] Alternatives textuelles et contraste d’au moins 4,5:1.
  • [ ] Mentions légales adaptées, information RGPD si un formulaire existe.
  • [ ] Pour un freelance : offre, tarifs indicatifs, hébergement n’excluant pas l’usage commercial.

Les erreurs les plus fréquentes

Erreur Pourquoi c’est un problème Correction
Démo hors ligne Le lecteur conclut que le projet ne marche pas Vérifiez chaque lien avant envoi
Quinze projets sans explication Le lecteur trie à votre place Gardez 3 à 5 études de cas
Résultats chiffrés invérifiables Ils se démontent en entretien Ne citez que ce que vous prouvez
Freelance sur une offre non commerciale Le site peut être suspendu Choisissez une offre adaptée

Ce que nous n’avons pas pu vérifier

  • « Les recruteurs passent moins de 10 secondes sur un portfolio. » Le chiffre figure sur plusieurs pages concurrentes, sans source. Nous n’avons trouvé aucune étude qui le mesure.
  • « 73 % des recruteurs préfèrent un bon portfolio à un CV parfait, selon Stack Overflow. » L’enquête interroge des développeurs, pas des recruteurs, et les chapitres consultés n’en portent pas trace.
  • GitHub Pages pour un site de prestataire. Aucune précision de GitHub sur les sites vitrines de freelances.
  • L’usage commercial chez Netlify, absent des pages de tarifs et de crédits consultées. Pour Cloudflare, nous avons lu le contrat général, pas les éventuelles conditions propres à Pages.
  • Le prix des noms de domaine, qui dépend du registraire et de l’extension.
  • La page d’aide de Malt sur les avis et recommandations, inaccessible au moment de la rédaction.

Questions fréquentes

Combien de projets mettre dans un portfolio développeur ?

Trois à cinq, présentés en études de cas. Sur GitHub, vous pouvez épingler jusqu’à six dépôts et gists au total, selon la documentation de GitHub : épinglez ceux du portfolio.

Où héberger son portfolio gratuitement ?

GitHub Pages, Netlify, Vercel et Cloudflare Pages ont un niveau gratuit. Pour un freelance, évitez l’offre Hobby de Vercel, non commerciale selon ses règles d’usage équitable, et Netlify met les sites en pause une fois les 300 crédits mensuels épuisés.

Faut-il des mentions légales sur un portfolio personnel ?

Un site édité à titre non professionnel peut rester anonyme en affichant le nom et l’adresse de son hébergeur, selon l’article 1-1 de la loi pour la confiance dans l’économie numérique. Dès que vous vendez des prestations, les mentions complètes s’imposent.

Faut-il coder son portfolio soi-même ?

Ce n’est pas obligatoire. Un modèle bien adapté, rapide et accessible vaut mieux qu’un site fait main qui dépasse les seuils de web.dev. Pour un poste front-end, coder le site devient une preuve en soi : documentez-le comme un projet.


À propos de l’auteur

Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d’IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur.

Méthode. Synthèse fondée exclusivement sur des sources publiques consultées le 26 octobre 2026 : enquête Stack Overflow 2026, rapport HackerRank 2025, documentations de GitHub, LinkedIn, Netlify, Vercel et Cloudflare, web.dev, PageSpeed Insights, Chrome for Developers, W3C, Légifrance, Service-Public, CNIL et aide de Malt. Les chiffres attribués à un éditeur sont signalés comme tels. Aucun test n’a été mené, aucun lien n’est affilié et aucune relation commerciale ne lie l’auteur aux services mentionnés.

Une erreur ou une limite périmée ? Écrivez à [email protected] : l’article sera corrigé et la date de mise à jour modifiée.

Dernière mise à jour : 26 octobre 2026.

Image : Amanda Lawrence (Unsplash License).

Publications similaires