Portfolio Projects for Software Engineer

Trois certificats en ligne sur votre CV et toujours aucune réponse. Le recruteur ne doute pas de votre sérieux, il doute de votre capacité à livrer. Un certificat dit que vous avez suivi un cours. Un projet montre que vous avez pris des décisions, subi des problèmes et sorti quelque chose qui tourne.

Voici trois projets qui parlent pour vous, ce que les recruteurs regardent vraiment, et comment en parler sans réciter un tutoriel.

Ce que les recruteurs regardent dans un projet#

Ils ne lisent pas tout. Ils passent 30 à 60 secondes sur votre dépôt, et cherchent des réponses à trois questions.

Est-ce que ça marche ? Un README avec un lien vers une démo, ou des instructions de lancement qui fonctionnent du premier coup. Est-ce que vous avez décidé quelque chose ? Des choix de stack, des arbitrages, une contrainte assumée. Est-ce que vous avez fini ? Une v1 livrée vaut mieux qu'un chantier ambitieux à moitié codé.

Le code lui-même compte moins que vous ne le pensez. La structure, la gestion d'erreur, les tests sur la logique principale et les messages de commit sont plus parlants que la sophistication d'un algorithme.

Projet 1 : un outil interne qui traite de vraies données#

Reprenez un problème que vous avez vu en stage, en job étudiant, ou dans votre propre vie. Un suivi de budget, un planificateur de gardes, un extracteur de données de PDF, un tableau de bord pour un petit commerce de votre quartier.

La différence avec un clone d'application connue : le problème n'est pas inventé. Vous connaissez les cas limites parce que vous les avez vécus.

Ce qui rend ce projet convaincant :

• Vous modélisez des données réelles, avec leurs cas tordus (dates manquantes, montants négatifs, doublons).
• Vous gérez l'import et l'export, jamais présents dans les tutoriels.
• Vous définissez vous-même les règles de gestion, donc vous pouvez les défendre en entretien.

Livrables : un dépôt avec une démo en ligne, un jeu de données d'exemple anonymisé, une section "règles métier" dans le README.

Projet 2 : une API documentée avec tests et observabilité#

Prenez un domaine que vous maîtrisez : films, comptes de jeux, suivi de colis, réservation de salles. Écrivez une API REST ou GraphQL, mais concentrez-vous sur tout ce qui entoure le code métier.

Authentification par jeton, pagination, limitation de débit, gestion des erreurs avec des codes HTTP cohérents. Des tests qui couvrent la logique, pas seulement les routes heureuses. Des logs exploitables et un fichier de configuration d'environnement propre.

Ce projet prouve que vous savez ce qu'un service doit avoir pour survivre en production. C'est exactement ce qu'on attend d'un ingénieur logiciel après deux ans, et beaucoup de candidats plus expérimentés ne savent pas l'expliquer.

Livrables : une collection Postman ou une spec OpenAPI, un README avec un schéma de base de données, un paragraphe sur les compromis (pourquoi PostgreSQL plutôt qu'un stockage clé-valeur, par exemple).

Projet 3 : une contribution visible à un projet existant#

Choisissez un projet open source que vous utilisez, de taille moyenne, avec une activité récente et des issues marquées "good first issue" ou équivalent. Corrigez un bug réel, écrivez une doc manquante, améliorez un message d'erreur.

L'objectif n'est pas la ligne de code spectaculaire. C'est de montrer que vous savez lire du code que vous n'avez pas écrit, respecter des conventions, et dialoguer dans une pull request.

Ce projet compense ce que les deux autres ne montrent pas : votre capacité à travailler dans une base de code existante, avec d'autres contributeurs. Pour trouver des issues adaptées, filtrez les dépôts par langage et par labels sur les plateformes d'hébergement, et lisez les guides de contribution avant de proposer quoi que ce soit.

Comment présenter ces projets sur votre CV#

Une ligne par projet, jamais plus. Format : contexte, action, résultat technique.

Exemple concret. Version faible : "Développement d'une application de gestion de budget avec React et Node.js."

Version qui tient : "Application de suivi budgétaire (React, Node.js, PostgreSQL) : import CSV avec détection de doublons, règles de catégorisation configurables, déployée sur un serveur VPS avec CI."

La seconde version dit ce que le code fait réellement, et elle donne trois points d'accroche pour l'entretien. Ajoutez un lien vers le dépôt et un lien vers la démo, pas seulement un nom de projet.

Si vous avez peu d'expérience, remontez ces projets dans la partie haute du CV, juste après un résumé de deux lignes. Si vous avez déjà des postes à valoriser, gardez-les dans une section "Projets" en bas, mais gardez les liens cliquables.

Vous pouvez vérifier la lisibilité de votre CV par un système de recrutement automatique avec notre outil d'analyse de CV, et décoder les offres d'emploi pour cibler les compétences qu'elles demandent vraiment.

Le README qui fait la différence#

Un bon README répond aux questions avant qu'on ne les pose.

Structurez-le ainsi :

• Une phrase qui dit ce que fait le projet, pour qui.
• Un lien vers la démo, ou une capture d'écran si l'app est privée.
• Comment lancer le projet localement, en trois commandes maximum.
• Les choix techniques, en trois ou quatre points, avec la raison.
• Les limites connues et ce que vous feriez avec plus de temps.

La dernière section est celle que presque personne n'écrit, et c'est souvent elle qui déclenche l'entretien. Dire "la recherche est linéaire, je passerais à un index si le volume dépasse 10 000 enregistrements" montre une maturité que le code seul ne montre pas.

Pour tester si votre dépôt passe la barre, demandez à quelqu'un de le cloner et de le lancer sans votre aide. Si ça casse, c'est que le README ne suffit pas.

Les erreurs qui font "projet tutoriel"#

Les recruteurs et les ingénieurs qui font passer les entretiens reconnaissent un clone de tutoriel en quelques secondes. Voici les signaux.

Le README est celui du cours, avec les mêmes sections et le même ton. La démo est le projet exact du tutoriel, sans modification. Aucun cas d'erreur n'est géré : les formulaires vides passent, les requêtes échouent silencieusement. Les commits s'appellent "final", "final2", "fix". Il n'y a pas de données réelles, seulement "test" et "foo".

Autre signal : la stack est disproportionnée. Une todo list en microservices avec Kubernetes ne prouve pas votre niveau, ça prouve que vous ne savez pas dimensionner. Un projet simple et propre bat un projet complexe et bancale.

Enfin, un dépôt sans historique de commits, avec tout poussé d'un coup, laisse penser que le code vient d'ailleurs. Committez au fur et à mesure, avec des messages qui racontent une intention.

Comment en parler en entretien#

Préparez un pitch de 90 secondes par projet, puis laissez l'interlocuteur creuser. La structure : le problème, la contrainte principale, la décision que vous avez prise, ce que vous referiez autrement.

Script pour le projet 1, à adapter : "J'ai construit un outil de suivi budgétaire pour gérer mes dépenses réelles. Le point difficile, c'était l'import de relevés bancaires : chaque banque a son format, avec des colonnes dans des ordres différents et des montants parfois négatifs. J'ai écrit une couche de normalisation avec des règles de mapping déclaratives, et des tests sur un jeu de vingt relevés réels. Si c'était à refaire, je ferais l'import en arrière-plan avec une file d'attente, parce qu'un gros fichier bloque l'interface aujourd'hui."

Ce pitch contient une décision technique, une preuve (les tests sur des données réelles), et une autocritique honnête. C'est exactement ce qu'on écoute.

Quand on vous demande "pourquoi cette stack", ne répondez pas "parce que c'est populaire". Répondez par la contrainte : "Je voulais déployer sur un petit VPS sans coût récurrent, donc j'ai évité les services managés et j'ai utilisé SQLite au départ, puis PostgreSQL quand j'ai eu besoin de contraintes d'intégrité."

Où trouver des idées qui ne ressemblent pas aux autres#

Regardez autour de vous plutôt que sur les listes de "50 idées de projets". Les petites entreprises de votre quartier ont des fichiers Excel qui deviennent ingérables. Les associations ont besoin de gestion d'adhésions. Vous, personnellement, perdez du temps sur quelque chose chaque semaine.

Ces problèmes donnent des projets que personne d'autre n'a. Et ils vous donnent des anecdotes d'entretien bien meilleures que "j'ai suivi un cours sur React".

Pour explorer les offres et voir quelles compétences reviennent dans les postes qui vous intéressent, notre moteur de recherche d'emplois peut vous aider à caler vos projets sur la demande réelle. Et nos autres guides de carrière reviennent régulièrement sur la préparation des entretiens techniques.

Outils gratuits#

• jobrise.io/fr/free-ats-checker/
• jobrise.io/fr/free-jd-decoder/
• jobrise.io/fr/jobs/
• jobrise.io/fr/blog/

Questions fréquentes#

Faut-il mettre tous ses projets sur son CV ?

Non. Trois projets bien présentés valent mieux que huit lignes bâclées. Choisissez ceux qui couvrent des compétences différentes et qui sont en ligne, avec une démo ou un dépôt accessible.

Mes projets personnels sont-ils pris au sérieux sans expérience professionnelle ?

Oui, s'ils sont complets et défendables. Un recruteur junior sait que vous n'avez pas encore livré en entreprise, ce qu'il regarde c'est votre façon de raisonner et votre capacité à finir.

Combien de temps faut-il pour un bon projet de portfolio ?

Comptez deux à quatre semaines pour une v1 correcte, en travaillant quelques heures par jour. Mieux vaut un projet fini et déployé qu'un chantier de trois mois jamais mis en ligne.

Dois-je utiliser les technologies les plus récentes pour impressionner ?

Non, utilisez ce que vous maîtrisez assez pour aller au bout. Un projet en technologies établies, avec une gestion d'erreur propre et des tests, impressionne plus qu'un assemblage de nouveautés mal maîtrisées.

Faut-il payer pour héberger sa démo ?

Non, il existe des offres gratuites suffisantes pour une démo de portfolio. Si votre projet sort de ces limites, un petit VPS à quelques euros par mois fonctionne aussi, mais vérifiez les tarifs actuels chez l'hébergeur avant de vous engager.