CV principal : comment le construire et l'entretenir (guide pour développeurs)

Un CV principal (on parle aussi de CV maître) est le registre complet et privé de votre carrière : chaque poste, chaque projet, chaque chiffre, chaque outil, dans un fichier qu’aucun employeur ne voit. Vous en tirez des versions personnalisées ; vous ne l’envoyez jamais. Les développeurs en ont plus besoin que la plupart, parce qu’une carrière dans le logiciel produit plus de détails qu’un CV de deux pages ne peut en contenir, et le détail que vous coupez aujourd’hui est celui que demandera l’offre du mois prochain.

Ce guide explique ce qu’est un CV principal, pourquoi en garder un, comment le construire section par section, comment le tenir à jour et comment en sortent les versions personnalisées. Pour l’étape de personnalisation elle-même, lisez comment adapter votre CV à une fiche de poste ; cet article s’arrête là où celui-là commence.

Ce qu’est un CV principal

Voyez-le comme une base de données, et un CV comme le résultat d’une requête. Le CV principal contient la table entière : quatre, six ou dix pages de postes, de puces, de projets, de conférences, de certifications et de compétences, chacun avec ses dates et ses chiffres. Un CV personnalisé est une vue d’une ou deux pages de cette table, filtrée pour une offre.

Trois propriétés en découlent.

Privé. Personne d’autre que vous ne lit le CV principal. Cela change ce qui y a sa place. La puce sur la migration qui a échoué et ce que vous en avez appris va dans le CV principal, parce qu’un intervieweur peut vous interroger dessus, même si elle n’entrera jamais dans une version personnalisée.

Complet. Le CV principal pèche plutôt par excès. Six à dix puces par poste, là où un CV personnalisé en garde trois. Les projets perso qui n’ont abouti à rien. L’outil interne que seule votre ancienne équipe connaît.

Stable. Vous y ajoutez et vous n’en retirez jamais. Un CV personnalisé est jetable ; le CV principal est ce que vous entretenez.

Il diffère du CV universitaire, lui aussi long et complet mais envoyé tel quel aux employeurs. Un CV principal est un document de travail, et la mise en forme peut attendre.

Pourquoi les développeurs devraient garder un CV principal

Votre mémoire s’efface plus vite que votre carrière n’évolue. Deux ans après un projet, vous vous souvenez d’avoir « travaillé sur le service de facturation ». Vous ne vous souvenez pas d’avoir réduit le p99 de 800 ms à 120 ms, que le service tournait en Go avec un backend Postgres, ni d’avoir écrit le runbook. Les chiffres disparaissent en premier. Un CV principal les capture tant que le tableau de bord est encore ouvert.

Les orientations de carrière divergent. Un ingénieur backend qui a aussi fait de la data a deux prochains postes plausibles. Les puces qui vendent un poste plateforme (astreinte, Kubernetes, réduction des coûts) ne sont pas celles qui vendent un poste data (pipelines, modélisation d’entrepôt de données, dbt). Un seul CV principal contient les deux ensembles ; une version personnalisée en choisit un.

Chaque projet compte quelque part. La contribution open source, le hackathon, le module Terraform écrit pour votre propre homelab : rien de cela ne tient dans un CV visant un poste frontend, et chacun pourrait être exactement ce que demande une autre offre. Si ce n’est pas écrit, vous n’y penserez pas au moment où ça compte.

Chaque chiffre a besoin d’une source. Un chiffre sur un CV doit résister à une question d’entretien. Le CV principal est l’endroit où vous notez, à côté de « temps de build réduit de 60 % », ce que vous avez mesuré, de combien à combien, et comment. Quand une version personnalisée porte le chiffre, vous pouvez le défendre.

La personnalisation devient une sélection. Avec un CV principal, personnaliser prend quelques minutes : choisir les puces qui correspondent, les reformuler dans les termes de l’offre, couper le reste. Sans lui, personnaliser revient à reconstruire votre passé de mémoire à chaque fois, et c’est là que les CV s’éloignent de la vérité.

La cohérence partout. Votre profil LinkedIn, vos CV personnalisés et vos réponses en entretien devraient concorder sur les dates, les intitulés et les chiffres. Une source unique de vérité rend cela automatique.

Comment construire un CV principal, section par section

Ouvrez un simple fichier Markdown. La mise en forme, les modèles et les limites de pages sont pour la version personnalisée. Le CV principal veut de la structure et de l’exhaustivité.

En-tête

Nom, e-mail, téléphone, ville et liens : GitHub, LinkedIn, un site personnel si vous en avez un. Notez la forme exacte sous laquelle vous voulez qu’ils apparaissent, pour que les versions personnalisées ne diffèrent pas (une avec « +33 », une sans).

Des résumés, un par orientation de carrière

Écrivez un résumé de trois lignes pour chaque type de poste auquel vous pourriez postuler. Un résumé backend, un résumé plateforme, un résumé data. Chacun cite les deux ou trois points forts qui comptent pour cette orientation. Quand vous personnalisez, vous partez du plus proche et vous l’ajustez.

Expérience

Pour chaque poste : employeur, intitulé, lieu, dates avec le mois, et la stack utilisée. Puis des puces, six à dix par poste, chacune une action avec un résultat. Notez plus que ce que vous montrerez jamais :

• Ce que vous avez construit, avec le nom de l’outil.
• Ce qui a changé grâce à cela, avec un chiffre quand vous en avez un.
• L’échelle : utilisateurs, requêtes par seconde, volume de données, taille de l’équipe.
• Ce dont vous étiez responsable : astreinte, un service, une migration, des recrutements.
• La collaboration qu’une offre pourrait demander : travail transverse, mentorat, travail avec le produit.

Sous chaque puce qui porte un chiffre, ajoutez une courte note sur son origine. « Tableau de bord Grafana, mars 2025, p99 avant et après le cache. » Vous ne montrerez jamais la note ; vous serez content de l’avoir en entretien.

Projets

Projets perso, travail open source, participations à des hackathons, outils internes. Pour chacun : nom, lien, dates, votre rôle, la stack, et deux ou trois puces sur ce que vous avez fait et ce qui en est sorti. Les étoiles, téléchargements ou utilisateurs si vous en avez. Un projet sans résultat y va quand même, avec une ligne sur ce que vous avez appris.

Compétences, regroupées et datées

Regroupez-les : langages, frameworks, infrastructure, données, pratiques. À côté de chacune, notez l’année où vous l’avez utilisée sérieusement pour la dernière fois. La liste de compétences d’un CV personnalisé ne devrait contenir que ce sur quoi on peut vous interroger aujourd’hui ; la colonne « dernière utilisation » vous dit lesquelles.

Formation et certifications

Diplômes avec établissement, dates et tout ce qui est pertinent (sujet de mémoire, un cours en lien avec votre travail). Certifications avec l’organisme et la date d’expiration.

Conférences, écrits, communauté

Conférences, meetups, articles de blog qui ont eu de l’écho, podcasts, programmes de mentorat. La plupart des CV personnalisés les laissent de côté ; certaines offres les valorisent.

Un journal des modifications

En bas, une liste datée de ce que vous avez ajouté et quand. Elle facilite la mise à jour suivante et vous montre d’un coup d’œil quand vous avez touché le fichier pour la dernière fois.

Modèle de CV principal (exemple fictif)

Le squelette ci-dessous montre la forme. La personne, les entreprises et les chiffres sont inventés. L’exemple est traduit en français.

Exemple (fictif) : Arjun Mehta, ingénieur backend, Bangalore

# Arjun Mehta
Bangalore, IN · arjun.mehta@example.com · +91 98xxx xxxxx
github.com/arjunm-example · linkedin.com/in/arjunm-example

## Résumés
### Backend / plateforme
Ingénieur backend, 6 ans sur des systèmes de paiement et de grand livre en Go
et Python. Responsable de services à 4 000 req/s ; a réduit de 30 % le coût
d'infrastructure chez Finlo.
### Data engineering
Ingénieur avec 3 ans de construction de pipelines batch et streaming
(Airflow, Kafka, BigQuery), en plus de 6 ans de backend.

## Expérience

### Finlo Payments · Senior Software Engineer
Bangalore · avril 2023 à aujourd'hui · Go, PostgreSQL, Kafka, Kubernetes, GCP
- Responsable du service de grand livre (pic à 4 000 req/s, 11 consommateurs
  en aval).
- A réduit la latence p99 d'écriture de 410 ms à 95 ms en regroupant les
  insertions dans le grand livre et en ajoutant une file d'écriture anticipée.
  > Source : tableau de bord Grafana de latence du grand livre, juin 2024,
  > fenêtre de 7 jours.
- A réduit de 30 % les dépenses GCP de l'espace de noms paiements (de 18 000
  à 12 600 USD par mois) en redimensionnant les pools de nœuds et en passant
  les traitements par lots sur des instances spot.
  > Source : export de facturation GCP, T3 2024 comparé au T1 2024.
- A piloté la migration de 6 services de Cloud Run vers GKE en 4 mois.
- Rotation d'astreinte paiements (1 semaine sur 5) ; a écrit le runbook
  d'incident utilisé par 12 ingénieurs.
- A accompagné 2 ingénieurs juniors ; tous deux ont livré leur premier
  service en production en un trimestre.
- A remplacé une couche de nouvelles tentatives maison par un schéma de
  file de lettres mortes Kafka ; les doubles versements sont tombés à zéro
  dans les 6 mois suivants.
- (Pas pour la plupart des CV) A mené un prototype de réécriture du grand
  livre en Rust, que nous n'avons pas livré ; a rédigé le document de
  décision.

### Brightcart · Software Engineer
Pune · juillet 2019 à mars 2023 · Python, Django, MySQL, Redis, AWS
- A construit l'API de suivi des commandes (Django REST) pour 200 000
  commandes par jour.
- A migré la recherche de produits de requêtes LIKE MySQL vers
  Elasticsearch ; le temps de recherche médian est passé de 1,2 s à 90 ms.
  > Source : Datadog APM, novembre 2021.
- A construit les premiers pipelines Airflow de l'équipe data (12 DAG,
  chargements nocturnes vers Redshift).
- A écrit le Terraform de l'environnement de préproduction (auparavant
  configuré à la main).
- A fait passer plus de 40 entretiens pour des postes backend en 2 ans.

## Projets
### kafka-replay (open source) · 2024 à aujourd'hui
CLI qui rejoue des topics Kafka dans un cluster local pour le débogage. Go.
310 étoiles sur GitHub, utilisé par 3 équipes chez Finlo.
### homelab-terraform · 2022
Modules Terraform pour un homelab Proxmox. Inachevé ; m'a appris l'API
Proxmox et les providers Terraform.

## Compétences (dernière utilisation)
- Langages : Go (2025), Python (2025), SQL (2025), Rust (2024, prototype),
  TypeScript (2022)
- Infrastructure : Kubernetes (2025), Terraform (2025), GCP (2025),
  AWS (2023), Docker (2025)
- Données : Kafka (2025), PostgreSQL (2025), Airflow (2023), Redshift
  (2023), Elasticsearch (2022), BigQuery (2024)
- Pratiques : astreinte, runbooks d'incident, documents de conception, mentorat

## Formation
B.E. en génie informatique, Université de Pune, 2015 à 2019

## Conférences et écrits
- « Ledger write paths at 4k rps », meetup Go de Bangalore, septembre 2024
- Blog : « Dead-letter queues without the drama », 2024 (12 000 vues)

## Journal des modifications
- 2025-09 : ajout des étoiles de kafka-replay, chiffres de coût du T3
- 2025-03 : ajout de la puce sur le mentorat, note sur le prototype Rust
- 2024-11 : fichier créé à partir du CV de 2023 + notes Brightcart

Remarquez ce que contient ce fichier et qu’aucun CV personnalisé n’aurait : des lignes de source sous les chiffres, une puce « pas pour la plupart des CV », un projet inachevé, une année de dernière utilisation pour chaque compétence, et deux résumés. C’est le rôle du CV principal.

Comment le tenir à jour

Un CV principal meurt quand les mises à jour deviennent une corvée : faites-les donc petites et rattachez-les à des événements que vous remarquez déjà.

Mettez à jour quand vous livrez. Quand un projet sort ou qu’un chiffre bouge, ajoutez la puce dans la semaine. Les chiffres sont sur le tableau de bord maintenant ; dans un an, ils n’y seront plus.

Gardez-le sous contrôle de version. Un fichier Markdown dans un dépôt Git privé vous donne l’historique gratuitement. Vous voyez ce que vous avez ajouté et quand, et vous pouvez comparer le CV principal avec n’importe quelle version personnalisée qui en est issue.

Relisez-le chaque trimestre. Quinze minutes, quatre fois par an : relire les puces du poste actuel, ajouter ce qui s’est passé, mettre à jour les années de dernière utilisation. Mettez-le dans votre agenda.

Notez la source avec le chiffre. L’habitude d’écrire « Source : … » sous chaque chiffre prend dix secondes et vous évite la question d’entretien à laquelle vous ne sauriez pas répondre.

Tenez un « brag document » à côté. L’idée du brag document de Julia Evans, une liste continue de ce que vous avez fait au travail, alimente le CV principal. Le brag document est brut ; le CV principal est trié.

Si votre CV principal a des rubriques trop minces, un poste avec deux puces et aucun chiffre, Resume Matcher a une étape d’enrichissement pour cela : il repère les rubriques faibles, vous pose jusqu’à six questions à leur sujet et rédige deux à quatre nouvelles puces à partir de vos réponses, sans ajouter de détails que vous n’avez pas donnés.

Les orientations de carrière : quand un seul CV principal ne suffit pas

La plupart des développeurs s’en sortent avec un CV principal et plusieurs résumés. Certains non. Si votre parcours backend et votre parcours data ont des listes de compétences, des sélections de projets et des résumés différents, deux CV principaux sont plus propres qu’un seul fichier rempli d’annotations emmêlées.

Resume Matcher est construit autour de cette idée. Vous pouvez garder jusqu’à cinq CV principaux, un par orientation de carrière, dont un marqué par défaut. La page de personnalisation présélectionne le CV par défaut ; vous changez quand une offre appelle une autre orientation. Chaque CV principal est un CV complet à part entière, créé à partir d’un fichier PDF ou Word importé ou des questions de l’Assistant CV, et chacun peut contenir des sections personnalisées si vous avez besoin d’un bloc que la mise en page standard n’a pas.

Comment les versions personnalisées naissent du CV principal

Personnaliser, c’est sélectionner et formuler. Pour une offre, vous prenez les puces qui correspondent à ses exigences, vous les reformulez dans ses termes, vous choisissez le résumé de cette orientation, vous réduisez la liste des compétences à ce qui intéresse l’offre et à ce que vous avez utilisé ces dernières années, et vous coupez le reste pour tenir sur une ou deux pages. Le CV principal ne change pas. Le guide de personnalisation détaille chacune de ces étapes avec un exemple.

Dans Resume Matcher, chaque CV personnalisé est un document distinct qui renvoie au CV principal dont il est issu. Le modèle propose des modifications ciblées de votre résumé, de vos puces et de vos compétences ; le code vérifie chacune, verrouille votre nom, vos employeurs, vos intitulés, vos dates et vos diplômes, et annule tout chiffre absent du CV principal. Vous relisez une comparaison avant/après, puis vous confirmez ou régénérez. Le CV principal reste tel que vous l’avez écrit : la prochaine offre part donc de la même source complète. Les versions personnalisées enregistrées restent modifiables et s’exportent en PDF depuis n’importe lequel des sept modèles.

Gardez le CV principal. Tout le reste n’en est qu’une vue.

Si cet article vous a aidé

Si ce squelette vous a évité une reconstruction de mémoire, une étoile sur Resume Matcher sur GitHub aide d’autres candidats à le trouver. Vous pouvez me suivre, Saurabh Rai, sur GitHub, X et LinkedIn.