Un CV de développeur backend a une tâche précise. Il doit convaincre un lecteur technique, souvent un ingénieur qui recrute plutôt qu'un recruteur, que vous savez construire et faire tourner des systèmes qui tiennent sous une charge réelle. Lister des langages ne suffit pas. Beaucoup de candidats connaissent les mêmes langages. Ce qui distingue un bon CV backend, c'est la preuve d'un jugement : ce que vous avez construit, ce que cela devait encaisser, et ce que vous avez décidé quand ça a cassé.
Placez une vraie section stack technique en haut
Un poste backend est filtré en partie sur l'adéquation à la stack. Facilitez la tâche. Regroupez vos technologies pour qu'un lecteur les parcoure en quelques secondes : langages, frameworks, bases de données, infrastructure et outillage.
Soyez honnête sur le niveau. Il y a une différence entre un langage avec lequel vous livrez du code en production chaque jour et un que vous avez utilisé une fois dans un projet perso. Si un CV liste quinze technologies comme si toutes se valaient, l'entretien révèle vite l'écart. Listez celles que vous pouvez défendre, et placez la plus forte en premier.
Décrivez des systèmes, pas seulement des tâches
La version faible d'une puce backend, c'est « développé des API REST avec Node.js ». Cela ne dit rien au lecteur sur l'échelle, la fiabilité, ou le problème que l'API résolvait.
La version forte nomme le système et ses contraintes :
Construit l'API de paiement traitant 300 requêtes par seconde en pic, avec des clés d'idempotence pour rendre les nouvelles tentatives sûres après un incident de double prélèvement.
Cette ligne montre la technologie, l'échelle et une vraie décision d'ingénierie déclenchée par quelque chose qui a réellement mal tourné. Un intervieweur technique la lit et a déjà trois questions de suivi, ce qui est exactement ce que vous voulez.
Montrez des chiffres qui parlent à un lecteur backend
Les indicateurs frontend et backend sont différents. Pour le backend, les chiffres qui portent concernent le débit, la latence, la fiabilité et le coût. Requêtes par seconde. La latence p99 que vous avez fait baisser. La disponibilité que vous avez tenue. Le pourcentage retranché d'une facture cloud en corrigeant une requête.
Réduit la latence p99 du point d'entrée de recherche de 1,2 s à 280 ms en ajoutant une réplique de lecture et une couche de cache.
Si vous n'avez pas de chiffres de production solides issus d'un poste, utilisez l'échelle que vous connaissez : taille de base de données, nombre de services, taille de l'équipe, fréquence de déploiement.
Incluez les parties qui ne sont pas que du code
Le travail backend ne se résume pas à écrire des endpoints. Mentionnez ce qui montre que vous savez porter un système en production : concevoir un schéma, mettre en place du monitoring et des alertes, gérer un incident et son post-mortem, écrire la migration qui a déplacé des données sans interruption.
Cela signale la séniorité plus clairement qu'un nom de framework de plus. Un développeur qui a été d'astreinte et a livré une migration sans interruption n'est pas le même recrutement que celui qui n'a écrit que du code de fonctionnalité, et le CV doit le rendre visible.
Restez sur le travail pertinent
Deux pages au maximum, une si vous débutez. Les postes récents et pertinents reçoivent le détail ; les plus anciens, une ligne ou deux. Un CV backend qui s'étire sur quatre pages parce que chaque endpoint CRUD est documenté signale un jugement faible sur ce qui compte, soit l'inverse de ce que vous cherchez à prouver.
Si votre quotidien vit déjà sur LinkedIn, Postulit peut le transformer en un brouillon de CV structuré, ce qui vous donne une base propre pour ajouter le détail au niveau système qu'un poste backend demande.
Prenez vos deux postes les plus récents et réécrivez une puce de chacun sous la forme système-et-contrainte : nommez le système, l'échelle traitée, et une décision prise sous pression. C'est la puce sur laquelle un intervieweur backend s'arrête.