Portfolio Projects for Backend Developer

Vous cherchez un poste de backend developer et vos certificats ne suffisent pas à décrocher un entretien. C'est normal. Un recruteur technique passe trente secondes sur votre profil, et un certificat ne lui dit rien sur votre façon de résoudre un problème réel.

Trois projets bien construits changent la donne. Pas trois tutoriels copiés, trois projets où l'on voit que vous avez pris des décisions, subi des contraintes, et assumé les conséquences.

Ce que les recruteurs regardent vraiment#

Ils ne cherchent pas la liste de vos technologies. Ils cherchent des indices de jugement technique. Trois questions reviennent toujours dans leur tête.

Avez-vous identifié un problème, ou seulement suivi un mode d'emploi ? Avez-vous géré les cas limites, les erreurs, les données sales ? Et surtout, votre code tient-il la route quand on l'exécute, ou s'arrête-t-il à la première requête imprévue ?

Le reste, la syntaxe, les frameworks, les design patterns à la mode, s'apprend sur le tas. Le jugement, non.

Projet 1 : une API de gestion avec contraintes réelles#

Prenez un domaine que vous connaissez. La facturation d'une petite activité, la gestion des stocks d'un commerce, le suivi des réservations d'une salle de sport. Le sujet importe peu, la contrainte compte.

Faites-en une API REST ou GraphQL avec authentification, pagination, filtrage, et gestion des erreurs. Ajoutez des contraintes qui existent dans la vraie vie : un champ obligatoire qui change d'un client à l'autre, une suppression en cascade qu'il faut empêcher, un état métier qui ne peut pas revenir en arrière.

Ce qui fait la différence : documentez vos choix. Pourquoi Postgres et pas Mongo pour ce cas ? Pourquoi ce format d'erreur ? Une phrase dans le README vaut plus que dix lignes de code en plus.

Un exemple concret de présentation dans le README :

API de gestion des réservations, 14 endpoints, authentification JWT, tests d'intégration sur les parcours critiques. J'ai choisi une approche transactionnelle pour les réservations concurrentes après avoir reproduit un problème de double réservation en local. Le schéma est migré avec des fichiers SQL versionnés plutôt qu'un ORM, pour garder la visibilité sur les requêtes exécutées.

Projet 2 : un service qui traite des données en arrière-plan#

Un CRUD, tout le monde en fait un. Ce qui manque souvent dans les portfolios, c'est le traitement asynchrone. File d'attente, worker, retry, idempotence.

Construisez un service qui reçoit un fichier ou un flux, le traite par lots, et renvoie un résultat. Import de catalogue produits, génération de rapports, agrégation de logs. Le sujet est secondaire. Les mécanismes sont le point.

Montrez que vous savez gérer un job qui échoue au milieu. Un worker qui redémarre sans tout refaire. Une tâche exécutée deux fois sans effet secondaire. Ce sont les problèmes que les équipes backend rencontrent chaque semaine.

Pour le langage, prenez celui que vous ciblez dans vos candidatures. Go, Python, Java, Node, peu importe. Un projet dans un langage que vous maîtrisez mal se voit tout de suite dans les entretiens.

Vous pouvez vérifier si votre façon de présenter ces projets passe les filtres automatiques avec notre vérificateur de compatibilité ATS gratuit.

Projet 3 : de l'observation et de la fiabilité#

Le troisième projet est plus discret et souvent plus convaincant. Prenez l'un de vos deux premiers projets et rendez-le observable. Logs structurés, métriques, healthcheck, gestion propre de l'arrêt.

Poussez plus loin : conteneurisez, ajoutez une configuration par environnement, écrivez un script de démarrage qui fonctionne sur une machine neuve. Documentez comment déployer, comment diagnostiquer une panne, comment revenir à une version précédente.

Ce projet montre quelque chose que les certificats ne montrent jamais : vous pensez au moment où ça casse en production. C'est exactement ce qu'on attend d'un backend developer, même junior.

Présenter ses projets sur le CV#

Un projet sur le CV n'est pas une description de fonctionnalité. C'est un résultat, avec un contexte et une difficulté surmontée.

Avant :

Projet personnel : API de gestion de stocks avec Node.js et MongoDB.

Après :

API de gestion de stocks (Node.js, PostgreSQL, Docker) : 20 endpoints, authentification par rôles, import CSV de 50 000 lignes avec reprise sur erreur. J'ai réduit le temps d'import de plusieurs minutes à moins d'une minute en traitant les lots dans une file d'attente.

La différence n'est pas dans la longueur. C'est qu'on voit un problème rencontré, une décision prise, un effet mesuré.

Trois conseils pour la mise en page :

• Une ligne de contexte, une ligne de difficulté, une ligne de résultat. Pas de paragraphe.
• Les chiffres doivent être vrais et défendables. Si vous n'avez pas mesuré, ne mettez pas de chiffre.
• Adaptez la description au poste visé. Un poste orienté données mettra en avant le traitement de lots, un poste orienté plateforme l'observabilité.

Si vous avez du mal à extraire les mots-clés d'une offre, notre analyseur d'offre d'emploi gratuit peut vous aider à voir ce que l'employeur demande vraiment.

Structurer le dépôt GitHub#

Un dépôt vide de contexte se lit comme un exercice. Quelques éléments suffisent pour changer cette impression.

• Un README en trois parties : ce que fait le projet, comment le lancer en cinq minutes, décisions techniques et arbitrages.
• Un fichier de démarrage qui marche du premier coup sur une machine sans configuration préalable.
• Des tests sur les parcours principaux, même peu nombreux. Trois tests qui couvrent les cas limites valent mieux que trente tests triviaux.
• Un exemple de requête ou de jeu de données pour tester sans tout saisir à la main.
• Une section "ce que je ferais différemment". Elle montre de la maturité technique.

Évitez les noms de branches "test1", les commits "fix", les fichiers de configuration avec vos mots de passe. Un recruteur qui ouvre le dépôt voit tout ça en dix secondes.

Les erreurs qui font "tutoriel"#

Certaines choses déclenchent un doute immédiat chez un lecteur technique.

Le projet qui reproduit exactement un tutoriel YouTube, avec les mêmes noms de variables et le même README. Le CRUD sans gestion d'erreur. Le dépôt avec un seul commit géant. Le projet déployé nulle part, sans instructions de démarrage.

Autre signal faible : la liste de technologies dans le README qui ne correspond pas à ce qu'on trouve dans le code. Si vous annoncez Redis et qu'il n'apparaît que dans une dépendance non utilisée, ça se voit.

Enfin, méfiez-vous du projet fourre-tout. Un projet avec vingt fonctionnalités mal finies donne une moins bonne impression qu'un projet étroit mais propre.

En parler en entretien#

On va vous demander de présenter un projet. Préparez une réponse de deux minutes, pas plus.

La structure qui fonctionne : le problème, la contrainte la plus difficile, la décision que vous avez prise, ce que vous referiez différemment. Restez sur du concret. "J'ai choisi une file d'attente parce que le traitement synchrone dépassait le timeout de l'API" est une bonne phrase. "J'ai utilisé une architecture scalable et moderne" n'en est pas une.

Préparez aussi les questions qu'on vous posera sur les limites. Comment ça se comporte avec dix fois plus de données ? Que se passe-t-il si deux requêtes arrivent en même temps ? Si vous n'avez pas traité ce cas, dites-le franchement et expliquez comment vous vous y prendriez. L'honnêteté technique est mieux notée qu'une réponse inventée.

Pour trouver des offres où ces projets feront la différence, notre moteur de recherche d'emplois regroupe les annonces techniques actuelles. Et si vous voulez creuser un point précis, les autres guides du blog de jobrise couvrent la préparation d'entretien et la rédaction de CV.

Questions fréquentes#

Combien de projets faut-il dans un portfolio backend ?

Trois projets bien construits suffisent largement. Un seul projet très abouti, avec tests, documentation et décisions expliquées, vaut mieux que cinq projets superficiels.

Faut-il déployer ses projets en ligne ?

Ce n'est pas obligatoire, mais un projet accessible ou au moins exécutable localement en quelques minutes rassure. L'essentiel est que le recruteur puisse le lancer sans passer une heure à résoudre des problèmes de configuration.

Mes projets personnels doivent-ils utiliser la même stack que le poste visé ?

Pas nécessairement, mais un écart trop grand crée un doute. Si vous visez des postes Java et que tout votre portfolio est en PHP, précisez dans le README pourquoi vous avez fait ce choix et montrez que vous connaissez les deux environnements.

J'ai suivi un tutoriel pour apprendre, est-ce que je peux le mettre dans mon portfolio ?

Vous pouvez, mais modifiez le projet en profondité avant de le présenter. Changez le domaine, ajoutez une contrainte qui n'était pas dans le tutoriel, écrivez vos propres tests. Un projet qui copie un tutoriel mot pour mot se repère immédiatement.

Combien de temps faut-il consacrer à chaque projet ?

Comptez deux à quatre semaines par projet en travaillant à côté d'un emploi. Ce qui compte n'est pas la durée mais la profondeur : un projet court et propre est préférable à un projet abandonné à moitié.