Un recruteur passe environ sept secondes sur le premier coup d'œil d'un CV de développeur. Ceux qui franchissent ce filtre maîtrisent déjà la structure. Les autres tombent presque toujours sur les mêmes erreurs : une liste de frameworks sans contexte, un résumé qui ressemble à un copier-coller du « À propos » LinkedIn, et des puces qui paraphrasent l'intitulé du poste au lieu de raconter ce qui a été livré.

Voici la version du CV que je rédigerais aujourd'hui pour un poste backend ou full-stack dans une entreprise de taille moyenne. Elle marche aussi pour des rôles seniors : c'est la structure qui reste, ce sont les preuves qui changent.

Commencez par ce que vous avez livré, pas par les outils

Le haut du CV doit répondre à une seule question : qu'est-ce que cette personne a construit, et est-ce que quelqu'un l'utilise. « Construit un pipeline Kafka » n'est pas une réalisation. « Construit un pipeline Kafka qui a remplacé un batch nocturne et réduit la latence du statut de commande de 20 minutes à moins de 30 secondes » en est une.

Trois règles pour chaque puce :

1. Commencer par le verbe, pas par la techno.
2. Inclure un chiffre, utilisateurs, latence, taux d'erreur, coût, n'importe quelle métrique.
3. Couper tout ce qui ne fait que reformuler le titre du poste.

Les technologies viennent plus bas. Les recruteurs les survolent, mais les responsables techniques lisent d'abord les puces pour juger si vous savez réfléchir.

Une structure qui fonctionne en 2026

Un CV de développeur en 2026 ressemble globalement à ça, de haut en bas :

• Prénom, nom, poste visé, ville, GitHub, portfolio, email. Pas de photo.
• Un résumé court, trois lignes maximum, écrit pour le poste visé.
• Expérience en ordre antéchronologique, quatre à six puces par poste.
• Projets sélectionnés, uniquement s'ils sont publics et récents.
• Compétences, regroupées (langages, infra, outils).
• Formation et certifications, en bas.

Une page si vous avez moins de cinq ans d'expérience. Deux pages si vous êtes senior ou si vous avez livré des produits qui méritent vraiment la place. Trois pages, c'est pour les CV académiques, pas pour l'ingénierie.

Le résumé, c'est la partie la plus difficile

La plupart des résumés de développeurs ne disent rien (« développeur full-stack passionné avec un grand souci du détail ») ou listent deux fois chaque techno. Un bon résumé ressemble plus à un positionnement : qui vous êtes, ce que vous avez construit, ce que vous cherchez ensuite.

Ingénieur backend, sept ans sur des systèmes de paiement et de comptabilité chez des fintechs et marketplaces. À l'aise pour porter un service de bout en bout, du schéma de base de données à l'astreinte. Recherche un poste senior dans une petite équipe, sur une base de code qui n'est pas un musée.

C'est assez précis pour que le recruteur sache s'il continue à lire. Les résumés génériques sont survolés, même quand l'expérience derrière est solide.

Stack technique : listez ce avec quoi vous livreriez lundi

La section compétences, c'est là que la majorité des CV de devs perdent en crédibilité. Lister vingt langages et quarante frameworks dit au recruteur que vous ne savez pas vraiment lesquels vous utilisez. Listez la stack avec laquelle vous seriez à l'aise d'ouvrir une pull request demain. Le reste, gardez-le dans une petite ligne « familier avec » si vraiment vous tenez à le mentionner.

Groupez pour qu'un manager technique scanne en deux secondes :

• Langages : TypeScript, Go, Python
• Infra : AWS (ECS, Lambda, RDS), Terraform, Postgres, Kafka
• Outils : Datadog, Sentry, GitHub Actions

Pas de notation (« Python ★★★★☆ »). Pas d'années par compétence. Les deux signalent un manque de confiance.

Open source et projets perso

Un seul lien GitHub vers un dépôt avec un README propre vaut mieux qu'un paragraphe sur l'open source. Si vous avez un projet qui montre du vrai génie logiciel, niveau production, testé, déployé, mettez le lien et écrivez une puce sur ce qu'il fait et ce qui était dur. Oubliez les dix-sept forks de tutos.

Même règle pour les projets perso. La barre, c'est : quelqu'un d'autre que vous l'utilise, ou ça vous a appris quelque chose que vous ne pouviez pas apprendre au boulot. Sinon, c'est du bruit.

La réalité ATS pour un CV de développeur

La plupart des équipes techniques utilisent un ATS, même celles qui jurent le contraire. Le CV doit survivre au parseur avant qu'un humain le lise. En pratique :

• PDF en sortie, mais généré depuis une source texte (pas d'image scannée).
• Une seule colonne. Deux colonnes embrouillent la plupart des parseurs.
• Des titres de section classiques (Expérience, Compétences), pas de variantes créatives.
• Les mots-clés de l'offre dans votre vraie expérience, pas planqués dans un pied de page.

Si vous partez d'un profil LinkedIn pour faire votre CV, Postulit s'occupe de la structure et de la couche ATS pour que vous puissiez vous concentrer sur la réécriture des puces.

Ce qu'il faut couper

Une courte liste de choses qui prennent de la place sans rapporter d'entretiens :

• Les loisirs, sauf s'ils sont vraiment liés (vous maintenez une bibliothèque populaire, vous organisez un meetup).
• La photo. Standard dans certains marchés européens, mais elle ajoute du biais et du bruit pour l'ATS.
• « Références disponibles sur demande. » C'est implicite.
• La liste de toutes les certifs jamais obtenues. Choisissez-en deux.
• Les soft skills en section dédiée. Montrez-les dans les puces.

Le but du CV, c'est de décrocher l'entretien téléphonique, pas de comprimer toute une carrière dans une feuille. Tout ce qui ne rapproche pas le lecteur du moment où il décroche son téléphone prend la place que quelque chose d'autre pourrait utiliser.