La plupart des sections compétences ratent pour la même raison. Elles ressemblent à un nuage de mots copié depuis l'offre, sans preuve, sans hiérarchie, et sans signal sur ce que la personne sait vraiment faire. Un recruteur qui passe six secondes sur un CV n'en tire rien.
La solution n'est pas d'ajouter plus de compétences. C'est de traiter cette section comme une preuve, pas comme un inventaire.
Pourquoi cette section compte plus qu'on ne le pense
Deux lecteurs regardent cette partie, et ils ne la lisent pas du tout pareil. L'ATS la lit comme une banque de mots-clés — si l'offre demande Kubernetes et Terraform, ces mots exacts doivent apparaître quelque part de lisible par la machine. Le recruteur humain, deux minutes plus tard, la lit comme une auto-évaluation du niveau. « Liste 18 outils, en maîtrise trois » est un schéma qu'il repère immédiatement.
Vous écrivez pour les deux. Faites passer les mots-clés pour franchir le filtre, et mettez en tête ceux qui matchent l'offre pour que l'humain arrête de scanner.
Ce qu'on y met vraiment
Groupez par catégorie, pas par niveau. « Avancé / Intermédiaire / Notions » se lit comme une estimation et n'apporte rien que le lecteur puisse vérifier. Les catégories donnent une structure et permettent d'ordonner par pertinence.
Une mise en page propre pour un poste backend :
- Langages : Python, Go, TypeScript
- Infrastructure : AWS (EC2, S3, Lambda), Docker, Terraform
- Data : PostgreSQL, Redis, ClickHouse
- Pratiques : CI/CD, revue de code, astreinte, gestion d'incident
Quatre catégories, dix à quinze éléments au total. Chaque ligne doit pouvoir être reprise en question par un recruteur ou un lead tech. Si une compétence figure dans la liste et que vous seriez gêné qu'on vous interroge dessus en entretien, elle n'a rien à faire là.
Compétences techniques vs compétences comportementales
Les compétences techniques sont des outils, des méthodes, des langages, des certifications. Elles vont dans la section compétences parce qu'elles sont scannables et qu'elles matchent des mots-clés. « PostgreSQL » est une compétence technique. « Encadrement de juniors » ne l'est pas — c'est une soft skill, et elle a sa place dans les puces d'expérience, là où vous pouvez la montrer en action.
La règle simple : si vous ne pouvez pas prouver la compétence avec une puce sous un poste, elle n'a rien à faire dans la section expérience. Si ce n'est pas un mot-clé qu'on pourrait taper dans un moteur de recherche, elle n'a rien à faire dans la section compétences.
Les soft skills en liste à part (« communication, leadership, esprit d'équipe ») sont du remplissage. Tous les CV en ont, aucune ne distingue, et le recruteur a décroché au troisième item.
Compétences à mettre sur un CV — la règle de priorisation
Ouvrez l'offre. Relisez la section des exigences deux fois. Les compétences que votre CV doit afficher, dans cet ordre :
- Toutes les compétences requises que vous avez vraiment, nommées comme l'offre les nomme. S'ils écrivent « AWS », vous écrivez « AWS ». S'ils écrivent « Amazon Web Services », vous écrivez ça.
- Deux ou trois compétences « souhaitées » que vous avez, surtout celles qui marquent de la séniorité.
- Deux compétences adjacentes qui montrent de l'étendue sans gonfler (un poste backend qui demande Python peut légitimement mentionner que vous travaillez aussi en Go).
Le reste, on coupe. Une section compétences qui colle à l'offre fait mieux qu'une plus longue mais générique — pour l'ATS comme pour l'humain.
Un format qui passe l'ATS
Les règles de parsing sont simples. Du texte brut, sur une seule colonne, dans le corps du document. Pas d'icônes, pas de barres de progression, pas de graphiques. La notation à cinq points qui rend si bien sur un template Canva est illisible pour la machine — elle apparaît dans l'ATS du recruteur comme cinq carrés noirs à côté d'un mot.
L'équipe Postulit a parsé des milliers de CV via notre outil LinkedIn-vers-CV, et le constat est constant : du texte propre dans des catégories bat tout ce qui est visuel. Pour voir comment votre section actuelle est parsée, passez-la dans n'importe quel outil de test ATS gratuit et regardez la sortie brute.
Erreurs classiques à corriger ce soir
Si votre section compétences finit par « et plus encore », enlevez « et plus encore ». Vous ne vendez pas des couteaux de cuisine.
Quelques cas à vérifier :
- Bourrer des mots-clés qu'on ne peut pas défendre — lister GraphQL parce qu'on a lu un article dessus la semaine dernière. Un recruteur technique vous le verra en vingt secondes.
- Des niveaux sans calibrage — votre Python « avancé » est l'intermédiaire d'un autre. Enlevez les étiquettes et laissez les puces d'expérience faire le calibrage.
- Les huit mêmes soft skills que tous les autres CV — si vous devez les inclure, intégrez-les dans des puces avec une preuve derrière.
- Des outils que plus personne n'utilise — Flash, Silverlight, jQuery en compétence principale en 2026. Ça date le CV.
Un exemple qui marche
Pour un·e analyste data confirmé·e qui postule en fintech :
- Analyse & modélisation : SQL (PostgreSQL, Snowflake), Python (pandas, scikit-learn), tests A/B
- Visualisation : Looker, Tableau, dbt
- Métier : signaux de fraude paiement, parcours KYC, rétention par cohorte
- Workflow : Git, modèles dbt en production, orchestration Airflow
Quatre catégories, douze items, chacun défendable en entretien. Chaque ligne renvoie à quelque chose que vous imaginez bien la personne avoir fait. C'est à ça que ressemble une bonne section compétences.
Écrivez la section compétences en dernier. Rédigez d'abord les puces d'expérience, regardez ce que vous avez prouvé, puis listez les compétences que ces puces soutiennent. L'ordre compte — dans l'autre sens, la liste finit toujours par dépasser ce que l'expérience peut couvrir.