La rubrique compétences d’un CV de développeur est souvent la plus longue et la moins lue. Elle accumule tout ce que le candidat a touché un jour : trois langages vus en cours, un framework essayé le temps d’un week-end, une base de données installée pour un tutoriel. Le recruteur, lui, cherche deux informations simples : la stack que vous maîtrisez vraiment, et la preuve que vous l’avez utilisée dans un contexte réel. Cet article explique comment passer de l’inventaire à une rubrique qui sert votre candidature, du premier filtre par mots-clés jusqu’à l’entretien technique.
Pourquoi une liste de vingt technologies dessert
Une liste longue part d’une bonne intention : ne rater aucun mot-clé. Elle produit pourtant l’effet inverse sur les deux lecteurs successifs de votre CV.
Le premier est le recruteur ou le chargé de recrutement, qui trie souvent des dizaines de candidatures pour un même poste. Il compare votre page à l’offre, cherche les trois ou quatre technologies indispensables et vérifie qu’elles apparaissent ailleurs que dans la liste. Quand Java, Python, Go, Rust, C#, PHP et TypeScript se suivent sans hiérarchie, il ne sait pas lequel est votre langage principal. Il peut vous classer dans la pile des profils dispersés, ou pire, vous rappeler pour un poste Go alors que vous n’avez écrit que quelques centaines de lignes dans ce langage.
Le second lecteur est le lead technique ou le développeur qui fera passer l’entretien. Lui prend la liste au pied de la lettre. Chaque technologie inscrite devient une question potentielle : « Vous avez mis Kafka, comment gériez-vous les consommateurs en erreur ? » Une compétence que vous ne pouvez pas défendre pendant cinq minutes fragilise toutes les autres. Un candidat qui reconnaît « je l’ai seulement utilisé en lecture » sur trois lignes de sa rubrique perd en crédibilité, même s’il est excellent sur le reste.
Il y a enfin un effet de signal. Un profil confirmé se reconnaît précisément à sa capacité à choisir. Une rubrique resserrée, qui assume une stack principale et quelques compléments, se lit comme celle de quelqu’un qui sait ce qu’il vaut. La fiche métier de l’Onisep sur le développeur informatique 🔗 le rappelle d’ailleurs : le métier consiste à concevoir et faire évoluer des applications, pas à collectionner des outils.
Grouper sa stack par usage plutôt que par ordre alphabétique
L’ordre alphabétique est le pire ordre possible : il place Angular avant TypeScript et Ansible avant Kubernetes, sans rien dire de votre profil. Regroupez plutôt vos technologies par usage, dans l’ordre où une fonctionnalité les traverse.
Une organisation qui fonctionne pour la plupart des profils :
- Langages : ceux que vous écrivez chaque semaine, du plus utilisé au moins utilisé ;
- Frameworks et bibliothèques : côté interface, côté serveur, côté données ;
- Données : bases relationnelles, bases clé-valeur, files de messages, entrepôts ;
- Infrastructure et livraison : conteneurs, cloud, intégration continue, supervision ;
- Pratiques : tests automatisés, revue de code, conception d’API, accessibilité, observabilité.
Quatre ou cinq lignes suffisent. Un développeur backend n’a pas besoin d’une ligne « interface » s’il n’a jamais livré d’écran en production. À l’inverse, un développeur front-end gagne à détailler la ligne « pratiques » (performance web, accessibilité, design system), car c’est là que se joue la différence entre deux profils React.
Voici une rubrique d’un développeur backend avant et après regroupement.
Avant : « Compétences : Agile, Angular, AWS, Docker, Git, Java, JavaScript, Jenkins, Jira, Kafka, Kotlin, Kubernetes, Linux, MongoDB, MySQL, Node.js, PostgreSQL, Python, React, Redis, Spring Boot, SQL, Terraform. »
Après :
- Langages : Kotlin, Java, SQL ; Python pour les scripts
- Serveur : Spring Boot, API REST documentées en OpenAPI
- Données : PostgreSQL (modélisation, optimisation de requêtes), Redis, Kafka
- Livraison : Docker, GitHub Actions, déploiement sur Kubernetes géré par l’équipe plateforme
- Pratiques : tests d’intégration avec Testcontainers, revue de code, observabilité
Le second bloc contient moins de mots, mais le lecteur sait immédiatement quel est le cœur du profil et ce qui relève du complément. Angular, React et MongoDB ont disparu : le candidat les avait croisés sans jamais les utiliser durablement. Le modèle de CV de développeur backend applique exactement ce principe, en deux lignes seulement.
Indiquer un niveau sans barres de progression
Les barres de progression, les étoiles et les pourcentages de maîtrise sont à bannir. Ils ne reposent sur aucune échelle commune : votre « quatre étoiles sur cinq » en Python ne dit rien à un lecteur qui ne connaît pas votre référence. Ils posent aussi un problème technique, car beaucoup de logiciels de recrutement extraient mal les éléments graphiques, et l’information disparaît purement et simplement.
Trois façons plus utiles de donner un niveau :
- La place dans la ligne. La première technologie citée est la principale. Ce simple ordre transmet l’essentiel sans aucun mot supplémentaire.
- Une précision d’usage entre parenthèses. « PostgreSQL (modélisation, optimisation de requêtes) » dit plus qu’« PostgreSQL avancé ». « Kubernetes (déploiement d’applications sur un cluster existant) » est plus honnête et plus rassurant qu’un Kubernetes nu, que le lead associera à l’administration de clusters.
- Une durée ou un contexte. « Go, utilisé depuis un an sur deux services internes » situe précisément votre niveau sans le surestimer.
Pour les langues, gardez les repères habituels (natif, courant, professionnel) et rattachez l’anglais à un usage réel : documentation, revues de code, réunions avec une équipe étrangère. C’est un critère de tri dans de nombreuses équipes produit.
Évitez enfin les qualificatifs absolus, « expert » en tête. Ils appellent la question la plus difficile de l’entretien et ne vous apportent rien au premier tri.
Relier chaque technologie à une expérience du CV
La rubrique compétences n’est qu’un index. La preuve se trouve dans les expériences, et un bon CV de développeur permet de passer de l’un à l’autre sans effort : chaque technologie importante de la rubrique réapparaît dans au moins une puce d’expérience ou de projet.
Concrètement, relisez votre rubrique ligne par ligne et posez-vous une question pour chaque technologie : dans quelle expérience l’ai-je utilisée, et pour produire quoi ? Trois cas se présentent.
- Vous trouvez une puce qui le montre. Parfait. Vérifiez que la puce nomme la technologie et décrit un livrable : « Réécriture du calcul des remises en Kotlin, avec tests d’intégration sur PostgreSQL » plutôt que « Développement backend ».
- Vous l’avez utilisée, mais aucune puce n’en parle. Ajoutez-la dans la ligne de contexte de l’expérience (« Équipe de 6 développeurs, Kotlin / Spring Boot / PostgreSQL sur AWS ») ou dans une puce existante.
- Vous ne la retrouvez nulle part. C’est probablement une technologie survolée. Retirez-la, ou déplacez-la vers une mention plus modeste (« notions », « projet personnel »).
Ce travail a un bénéfice direct en entretien. Le lead qui vous interroge sur une technologie de la liste trouvera dans vos expériences le contexte où vous l’avez utilisée, et vous pourrez raconter une situation précise plutôt que réciter une définition. Les modèles de CV de TechCV, comme celui du développeur full-stack, suivent cette logique : la ligne de contexte de chaque poste donne la stack, et les puces la mettent en œuvre.
Adapter la rubrique à chaque offre
Une stack bien présentée n’est pas figée. Elle s’ajuste à chaque candidature, sans mensonge, en jouant sur l’ordre et le niveau de détail.
Reprenez les mots exacts de l’offre. Si l’annonce écrit « Node.js », n’écrivez pas « Node ». Si elle parle de « TypeScript », ne vous contentez pas de « JavaScript ». Les logiciels de tri comparent des chaînes de caractères, et les recruteurs non techniques aussi. Un mot-clé présent dans votre parcours mais absent de la rubrique est une occasion perdue.
Réordonnez les lignes. Pour un poste orienté données, la ligne « Données » remonte en tête. Pour une équipe plateforme, la ligne « Infrastructure et livraison » prend la première place et se détaille.
Développez une ligne, réduisez les autres. Si l’offre insiste sur les tests, ajoutez les outils et les pratiques correspondants (tests de contrat, tests de bout en bout, couverture suivie en intégration continue) et resserrez le reste pour garder une page.
Ne recopiez pas une technologie que vous n’avez jamais pratiquée. La tentation est forte quand l’offre la cite en premier. Préférez une formulation honnête dans l’accroche (« à l’aise en Java, en cours de montée en compétence sur Go ») : un lead apprécie davantage un candidat lucide qu’une découverte gênante pendant l’entretien.
La même logique vaut pour les deux lignes qui ouvrent le CV : notre article sur le titre et l’accroche d’un CV tech montre comment y placer la stack principale, et celui sur les ATS des scale-up explique comment écrire les noms de technologies pour qu’ils soient retrouvés.
Le contenu de la rubrique change d’une offre à l’autre, mais sa mise en forme doit rester impeccable. Un éditeur comme celui de TechCV garde la mise en page stable pendant que vous réordonnez vos lignes, et produit un PDF dont le texte reste sélectionnable : les logiciels de tri lisent alors vos compétences dans le bon ordre, au lieu de les mélanger comme le font souvent les CV en colonnes. Vous pouvez partir de votre CV actuel et le retravailler directement dans l’éditeur de CV.
Questions fréquentes
Combien de technologies faut-il citer sur un CV de développeur ?
Il n’y a pas de nombre magique, mais une rubrique de quatre ou cinq lignes regroupées par usage, avec une douzaine de technologies au total, couvre la plupart des profils. Au-delà, vérifiez que chaque élément ajouté correspond à une expérience que vous pouvez raconter.
Faut-il mentionner Git, Jira ou Agile ?
Git est attendu de tout développeur : le citer ne vous distingue pas, mais son absence peut surprendre un logiciel de tri. Placez-le dans la ligne « livraison ». Jira et « Agile » apportent peu ; décrivez plutôt votre façon de travailler dans les expériences (sprints, revues de code, mises en production fréquentes).
Comment présenter une technologie apprise seul ?
Comme les autres, mais avec son contexte : « Rust (projet personnel d’outil en ligne de commande, publié sur GitHub) ». Le recruteur sait ainsi que la compétence est réelle sans la confondre avec une pratique professionnelle.
Les soft skills ont-elles leur place dans la rubrique compétences ?
Pas sous forme de liste d’adjectifs. Les pratiques d’équipe (revue de code, documentation, accompagnement d’alternants) prouvent bien mieux votre façon de travailler, et elles ont leur place dans la ligne « pratiques » ou dans les puces d’expérience.