Portfolio de développeur junior : entretien avec Élodie Marchand, recruteuse tech

Mis à jour le 9 octobre 2026 · Rédaction annu-forums.fr

Un portfolio de développeur junior n'a pas besoin de ressembler à une vitrine exhaustive pour être utile. Quelques projets aboutis, compréhensibles, accessibles et documentés permettent déjà de voir ce que vous savez construire, les arbitrages que vous faites et la manière dont vous travaillez. À Lyon, Élodie Marchand, recruteuse spécialisée en métiers du numérique, répond aux questions de la rédaction sur ce qui retient l'attention lors de la lecture d'un portfolio et d'un profil GitHub.

Pour une personne en reconversion, le portfolio sert aussi à rendre le parcours intelligible sans le surjouer. Le récit détaillé proposé dans Reconversion dev web à 42 ans : 18 mois jusqu'au premier CDI peut aider à situer cette étape dans une trajectoire plus large, tandis que cet entretien se concentre sur les éléments concrets qu'un lecteur peut vérifier dans vos projets.

Montrer une sélection plutôt qu'un catalogue

Q : Un recruteur attend-il beaucoup de projets dans un portfolio junior ?

Élodie Marchand : En général, je préfère voir quelques projets réellement terminés plutôt qu'une longue liste de dépôts inachevés. L'enjeu n'est pas de remplir une page, mais de donner des points d'appui à la lecture : quel problème le projet cherche-t-il à résoudre, que peut-on essayer, et que révèle le code sur votre démarche ? Un projet modeste mais propre, avec une intention claire et une documentation utile, peut en dire davantage qu'une succession d'exercices laissés à l'état d'ébauche.

Je conseille de choisir des réalisations que vous êtes capable d'expliquer sans réciter un discours préparé. Vous devez pouvoir dire ce que vous avez fait, ce qui vous a posé problème, ce que vous modifieriez et ce que vous avez appris. Cette capacité à situer son travail est souvent plus éclairante que l'ambition affichée du sujet.

Q : Quels types de projets sont les plus parlants ?

Élodie Marchand : Je cherche surtout de la cohérence entre les projets et le chemin que la personne souhaite emprunter. Une interface soignée peut rendre visible une attention portée à l'expérience utilisateur, tandis qu'un projet qui manipule des données peut faire apparaître une réflexion sur leur organisation. Il n'est pas nécessaire de couvrir tous les domaines : mieux vaut assumer une sélection qui montre des compétences réelles et une progression lisible.

Un projet personnel gagne aussi en intérêt lorsqu'il répond à un besoin identifiable, même simple. Les personnes qui débutent peuvent trouver des repères pratiques dans Apprendre HTML et CSS en 2026 : entretien avec une développeuse front-end, puis transformer ces bases en une réalisation dont elles maîtrisent pleinement les détails.

Transformer un tutoriel en projet personnel

Q : Un projet issu d'un tutoriel peut-il figurer dans un portfolio ?

Élodie Marchand : Oui, à condition de le présenter honnêtement. Un tutoriel est un support d'apprentissage légitime : il permet de découvrir des outils, une structure de projet ou une méthode de résolution. Ce qui devient intéressant dans un portfolio, c'est le moment où vous vous écartez de l'exemple pour prendre des décisions. Ajouter une fonctionnalité, utiliser un autre jeu de données, revoir l'interface ou modifier une règle métier montre que vous ne vous êtes pas contenté de reproduire des étapes.

Je recommande de signaler le point de départ dans le README, puis d'expliquer précisément les différences apportées. Cette transparence évite toute ambiguïté et valorise votre apprentissage. Elle donne aussi un sujet de discussion naturel en entretien : vous pouvez raconter ce que vous avez compris, ce que vous avez changé et pourquoi.

Q : Faut-il chercher un projet très original pour se distinguer ?

Élodie Marchand : L'originalité n'est pas une obligation. Un sujet déjà connu peut être très pertinent s'il est bien exécuté et s'il vous permet de démontrer un raisonnement. Je regarde moins l'idée brute que la manière dont elle est menée : la clarté du périmètre, la qualité des choix, la facilité d'utilisation et la capacité à reconnaître les limites du projet. Une réalisation volontairement simple, mais tenue jusqu'au bout, est souvent plus convaincante qu'un concept ambitieux dont les éléments essentiels restent flous.

Cette attention aux compétences concrètes rejoint les questions posées autour de l'avenir du métier de développeur web. Votre portfolio ne doit pas prédire l'avenir : il doit permettre de comprendre comment vous apprenez, construisez et améliorez un produit aujourd'hui.

Faire du README une véritable porte d'entrée

Q : Que doit contenir le README d'un projet ?

Élodie Marchand : Pour moi, le README est la première aide à la lecture. Il devrait présenter l'objectif du projet, idéalement avec une capture d'écran qui donne un aperçu immédiat de l'interface ou du résultat. Il doit aussi indiquer les technologies utilisées, la manière d'installer et de lancer le projet, ainsi que les choix importants effectués. Ce n'est pas une formalité ajoutée à la fin : c'est une façon de rendre votre travail accessible à une personne qui ne connaît ni votre environnement ni vos intentions.

J'apprécie également qu'il explique les limites connues ou les pistes d'amélioration. Cela ne fragilise pas le projet, au contraire : vous montrez que vous savez prendre du recul. Un README trop général, qui ne dit ni ce que fait le projet ni comment l'essayer, laisse le lecteur seul devant le dépôt.

Q : Comment décrire ses choix techniques sans noyer le lecteur ?

Élodie Marchand : Je conseille de sélectionner les décisions qui ont eu une conséquence visible sur le projet. Vous n'avez pas besoin de commenter chaque dossier ou chaque dépendance. En revanche, si vous avez choisi une structure particulière, un mode de stockage des données ou une approche de test, expliquez le besoin auquel ce choix répondait. Une phrase claire sur une décision comprise vaut mieux qu'une liste de termes techniques sans contexte.

Le bon équilibre consiste à écrire pour une personne curieuse mais pressée. Elle doit pouvoir comprendre le projet rapidement, puis trouver davantage de détails si elle souhaite aller plus loin. Le README est donc un document de guidage : il organise la découverte sans remplacer l'exploration du code.

Vérifier la démonstration avant de partager le lien

Q : Une démonstration en ligne est-elle indispensable ?

Élodie Marchand : Cela dépend du projet, mais un lien de démonstration qui fonctionne facilite beaucoup la découverte. Il évite au lecteur de devoir installer immédiatement le projet pour en comprendre le résultat. Avant de partager ce lien, je conseille de le tester dans les conditions les plus simples possibles : ouvrir l'adresse, parcourir les fonctions principales et vérifier que les éléments attendus restent accessibles. Un lien mort ou une page qui ne se charge pas interrompt très vite la lecture.

Pour un site statique, GitHub Pages permet de publier directement depuis un dépôt GitHub public. Cette possibilité peut être particulièrement adaptée à un portfolio ou à une démonstration simple. L'important reste de préciser ce que le visiteur doit regarder et de maintenir le lien lorsque le projet évolue.

Q : Comment présenter un projet dont la démonstration ne peut pas être publique ?

Élodie Marchand : Je privilégie l'honnêteté et la clarté. Si une démonstration n'est pas possible, le README peut détailler les étapes de lancement, montrer des captures pertinentes et expliquer les fonctionnalités principales. Vous pouvez aussi indiquer les contraintes qui empêchent une mise en ligne, sans entrer dans des justifications confuses. Le lecteur doit malgré tout pouvoir se faire une idée concrète du résultat et de votre participation.

Lorsqu'un projet implique le choix d'un mode de données, il est utile d'être capable de l'expliquer simplement. Le guide SQL ou NoSQL pour votre premier projet de développeur en 2026 ? propose des pistes pour réfléchir à ce type de décision et la restituer dans votre documentation.

Laisser apparaître une pratique Git compréhensible

Q : Que révèle l'historique de commits d'un dépôt ?

Élodie Marchand : Un historique lisible aide à comprendre comment le projet a été construit. Je ne cherche pas une perfection artificielle, mais des messages qui disent ce qui a changé et une progression qui reste intelligible. Des commits aux libellés clairs rendent le dépôt plus facile à relire, pour vous comme pour une autre personne. Ils peuvent aussi montrer que vous avez l'habitude d'avancer par étapes plutôt que de déposer un bloc de modifications sans repère.

Il n'est pas utile de réécrire son parcours pour fabriquer une histoire idéale. Un projet comporte parfois des essais, des corrections et des retours en arrière. Ce qui compte est que l'ensemble reste compréhensible et que vous sachiez commenter votre méthode si la question se présente. L'historique peut soutenir votre discours, mais il ne le remplace pas.

Q : Quelle place donner aux tests dans un portfolio junior ?

Élodie Marchand : Les tests sont pertinents lorsqu'ils répondent à un risque ou à une fonction importante du projet. Je préfère voir quelques tests assumés, accompagnés d'une explication sur ce qu'ils protègent, plutôt qu'une présence purement décorative. Si vous n'avez pas testé une partie du projet, vous pouvez aussi expliquer votre priorité et ce que vous auriez souhaité couvrir ensuite. Cette lucidité compte dans l'appréciation d'une démarche.

Les habitudes de versionnage, de vérification et de débogage se travaillent progressivement. Bonnes pratiques développeur débutant : Git, tests, debug 2026 rassemble des repères complémentaires pour faire de ces gestes une partie cohérente de votre pratique quotidienne.

Soigner le profil GitHub sans le surcharger

Q : Que regardez-vous sur un profil GitHub au-delà des dépôts ?

Élodie Marchand : Le profil peut orienter la lecture, surtout lorsqu'il permet d'identifier rapidement les projets les plus représentatifs. GitHub propose un dépôt spécial portant le même nom que le nom d'utilisateur : le README de ce dépôt s'affiche en tête du profil public. C'est un espace utile pour une courte présentation, les technologies que vous souhaitez mettre en avant et des liens vers vos réalisations principales. Il ne doit pas devenir une autobiographie exhaustive.

Les dépôts épinglés jouent un rôle similaire. Je conseille de choisir ceux qui correspondent le mieux à votre niveau actuel et à la direction que vous souhaitez donner à votre recherche. Vérifiez leurs noms, leur README, leur statut et leurs liens avant de les mettre en avant. Un profil ordonné rend la navigation plus simple.

Q : Quelles erreurs faut-il absolument éviter sur un dépôt public ?

Élodie Marchand : La plus importante concerne les secrets. Il ne faut jamais publier de clé d'API, de mot de passe ou de jeton dans un dépôt public. Les supprimer ensuite ne suffit pas, car ces informations restent dans l'historique : elles doivent être révoquées. C'est un réflexe de sécurité essentiel, même pour un projet d'apprentissage. Une vérification attentive avant chaque publication évite une situation qui peut être difficile à corriger.

Je me méfie aussi des dépôts vides, des liens qui ne fonctionnent plus et des projets laissés sans indication. Ils ne doivent pas être cachés à tout prix, mais ils n'ont pas forcément leur place parmi les réalisations mises en avant. Le guide Cybersécurité développeur débutant : guide essentiel 2026 aide à replacer ces réflexes de protection dans une pratique plus large.

Raconter sa reconversion avec précision et simplicité

Q : Que devrait contenir une page à propos lorsqu'on change de métier ?

Élodie Marchand : Une page à propos peut expliquer sobrement votre parcours, votre transition et ce qui vous attire dans le développement. Je conseille d'éviter les formules grandiloquentes au profit d'éléments concrets : les compétences que vous avez travaillées, les projets qui illustrent votre progression et le type de contexte dans lequel vous souhaitez continuer à apprendre. Une reconversion n'a pas besoin d'être justifiée comme une rupture spectaculaire ; elle peut être présentée comme une évolution réfléchie.

Les expériences antérieures peuvent apporter des qualités utiles, à condition de faire le lien avec le présent. Organisation, échange avec des utilisateurs, attention au détail ou compréhension d'un domaine sont des exemples de sujets que vous pouvez évoquer si vous pouvez les relier à votre manière de construire des projets.

Q : Comment parler de son portfolio en entretien ?

Élodie Marchand : Je recommande de préparer une visite guidée courte et souple. Commencez par l'objectif du projet, puis montrez une fonctionnalité représentative, un choix technique et une difficulté rencontrée. Terminez par ce que vous amélioreriez avec davantage de temps. Cette structure évite de commenter chaque écran et vous aide à mettre en valeur votre raisonnement plutôt qu'à simplement faire défiler une démonstration.

Un témoignage comme Reconversion dev web à 45 ans : témoignage et feuille de route rappelle que le parcours n'est pas linéaire. En entretien, il est plus utile de parler avec précision de ce que vous savez faire aujourd'hui et de ce que vous cherchez à approfondir que de tenter de masquer vos zones d'apprentissage.

Idées reçues : vrai ou faux

• Un portfolio doit montrer tout ce que vous avez codé : faux. Une sélection cohérente est plus facile à lire et à défendre.
• Un projet de tutoriel est interdit : faux. Il peut être présenté s'il est personnalisé et documenté avec transparence.
• Le README est secondaire si le code est bon : faux. Il aide le lecteur à comprendre, installer et évaluer le projet.
• Un commit parfait est obligatoire : faux. Un historique clair et honnête est plus utile qu'une mise en scène.
• Supprimer un secret publié règle le problème : faux. Il faut aussi le révoquer, car il demeure dans l'historique.
• Une reconversion doit être longuement justifiée : faux. Un récit simple, relié à des projets concrets, suffit souvent.

Trois choses à retenir

• Choisissez des projets terminés, dont vous comprenez les choix et les limites.
• Rendez chaque projet facile à découvrir grâce à un README, une capture et un lien vérifié lorsque cela est possible.
• Faites de votre profil GitHub et de votre page à propos des outils de lecture simples, honnêtes et à jour.

Le portfolio ne remplace pas l'échange, mais il prépare un entretien plus précis. S'il permet à une personne de comprendre ce que vous avez construit et ce que vous souhaitez apprendre ensuite, il remplit déjà son rôle.

Sources

• Documentation GitHub, « Managing your profile README » et « GitHub Pages »