Comment rédiger un CV pour un emploi tech (ingénieurs logiciels, développeurs, data)
Le CV tech n'est pas simplement un CV générique avec une section langages de programmation boulonnée dessus. Les recruteurs et hiring managers d'ingénierie lisent les CVs tech d'une manière spécifique : ils scannent pour les technologies qui correspondent au rôle, ils veulent voir des projets livrés avec un scope mesurable, ils cherchent la coordination GitHub-portfolio-site personnel comme signal d'être un ingénieur pratiquant plutôt qu'un titulaire de diplôme et ils pondèrent différentes sections différemment des recruteurs corporate. La section compétences techniques, la section projets, les contributions open source, les métriques d'ingénierie — celles-ci changent comment le document se lit et comment le candidat est évalué. Ce guide couvre le CV tech depuis la base : quoi mettre dans la section compétences et comment l'organiser, quand les projets comptent plus que les emplois, comment gérer les liens GitHub et portfolio, le keyword matching ATS qui détermine si votre CV atteint des yeux humains, les métriques spécifiques à l'ingénierie qui quantifient l'impact, les différences entre CVs d'ingénieur junior et CVs d'ingénieur staff, et comment le CV tech se coordonne avec la présence en ligne plus large (LinkedIn, GitHub, site personnel) que les hiring managers examineront.
Le CV tech se lit différemment — ce qui change
Avant les tactiques, la différence structurelle. Les CVs tech sont évalués à travers un objectif différent des CVs corporate, et la différence façonne chaque section :
- Le hiring manager d'ingénierie lit le CV en parallèle (ou après) un scan rapide de votre GitHub, votre site personnel si vous en avez un et votre LinkedIn. Le CV n'est pas le seul signal ; c'est un signal dans une évaluation multi-source
- La section compétences techniques est lue en premier par les recruteurs comme par les ingénieurs, mais ils cherchent des choses différentes. Les recruteurs scannent pour les correspondances de mots-clés contre la JD ; les ingénieurs scannent pour voir si la profondeur et l'ampleur correspondent à la séniorité du rôle
- Les projets comptent souvent plus que l'historique d'emploi aux niveaux junior et mid. Un projet auto-dirigé qui a livré quelque chose de réel signale initiative et exécution d'une manière qu'un stage ou premier emploi ne peut pas
- L'historique de travail est lu pour le scope, l'impact et la séniorité du contexte — pas seulement pour les noms d'entreprise. Travailler dans l'équipe d'auth dans une startup de 50 personnes est différent de travailler dans l'équipe d'auth dans une entreprise de 50 000 personnes ; le CV doit rendre le scope lisible
- La présence GitHub est vérifiée. Un candidat avec un profil GitHub actif (commits réels, multiples dépôts, graphique de contribution montrant activité récente) est traité comme un ingénieur plus crédible qu'un sans — même si la compétence sous-jacente est identique
- Le CV est d'une page jusqu'à ce qu'il ne puisse pas l'être. Deux pages sont acceptables pour les ingénieurs avec 8+ années d'expérience, mais la deuxième page doit contenir de la substance réelle, pas du remplissage
- L'éducation compte au niveau junior (surtout pour les nouveaux diplômés), devient moins importante au niveau mid et devient presque non pertinente au niveau senior+. Ajustez la proéminence en conséquence
- Les certifications comptent pour les rôles cloud spécifiques (AWS, GCP, Azure) et les spécialités spécifiques (sécurité, réseaux) mais sont en grande partie non pertinentes pour les rôles généraux d'ingénierie logicielle
Le reste de ce guide est construit autour de ces faits structurels. Chaque section adresse quoi écrire, comment l'organiser, quoi accentuer et quoi couper — calibré spécifiquement pour les rôles d'ingénierie plutôt que pour les rôles corporate génériques.
La section compétences techniques — comment l'organiser
La section compétences techniques est la section la plus scannée sur un CV tech. Recruteurs comme ingénieurs la regardent en premier. Comment elle est organisée détermine si elle transmet compétence ou bruit :
- Organisez par catégorie, pas comme une seule liste plate. Langages, frameworks, bases de données, infrastructure/cloud, outils, méthodologies — chacun comme son propre groupe. Un mur de 40 technologies séparées par virgules se lit comme un déversement de buzzwords ; les mêmes 40 organisées par catégorie se lisent comme une carte structurée de compétences
- Listez les technologies que vous pouvez discuter avec confiance dans une entrevue technique. L'intervieweur choisira de cette section pour concevoir des questions techniques ; si vous listez Rust parce que vous l'avez utilisé pour un tutoriel il y a trois ans, vous échouerez l'entrevue
- Ordonnez chaque catégorie par compétence genuine, pas par ce que vous souhaiteriez être vrai. Si vous êtes le plus fort en Python et le plus faible en Go, mettez Python en premier — l'ordre est lu comme signal de confiance
- Évitez les étiquettes de niveau de compétence (Débutant / Intermédiaire / Expert / 8 sur 10). Elles sont subjectives, souvent inexactes et créent des questions embarrassantes en entrevues. Soit listez une technologie parce que vous pouvez la discuter avec confiance, soit laissez-la dehors
- Faites correspondre le vocabulaire technique dans la description du poste. Si la JD dit 'React, Node.js, PostgreSQL, AWS', utilisez ces termes exacts — pas 'frameworks JavaScript, serveurs web, bases de données relationnelles, plateformes cloud'. Le keyword matching ATS est littéral
- Listez les versions ou dialectes spécifiques quand pertinent : 'Python 3.x', 'PostgreSQL 14+', 'React 18 avec hooks'. La spécificité signale la profondeur
- Sautez les bases que tout le monde est supposé avoir. Lister 'HTML, CSS, Git, ligne de commande' sur un CV de senior engineer est du remplissage qui évince le signal réel
- Si vous avez une expertise spécialisée (compilateurs, systèmes distribués, infrastructure ML, systèmes temps réel), créez une ligne séparée 'spécialités' ou 'domaines' qui la fait remonter. La spécialisation est plus précieuse que l'ampleur au niveau senior
Le test pour la section compétences techniques : un ingénieur la lisant devrait pouvoir prédire à quoi votre travail quotidien a réellement ressemblé. Si la section est un nuage de mots générique qui pourrait correspondre à n'importe quel candidat, elle échoue. Si elle est organisée, calibrée et honnête, elle fait la plus grande partie du travail de l'écran technique avant que l'écran technique se produise.
Organiser la rubrique compétences pour qu'elle signale une vraie maîtriseMontrer les projets — quand les projets comptent plus que les emplois
Les CVs tech incluent souvent une section Projets en plus de l'Expérience Professionnelle. Pour certains candidats la section Projets est la partie la plus forte du CV. Quand en inclure une et comment l'utiliser :
- Ingénieurs juniors et nouveaux diplômés : la section Projets est essentielle. Avec un historique de travail limité, les projets sont la preuve primaire que vous pouvez livrer du code. Placez cette section au-dessus ou juste après l'Éducation
- Changeurs de carrière entrant en ingénierie : la section Projets est essentielle. C'est le pont entre votre expérience antérieure et votre capacité d'ingénierie — et la seule preuve que vous avez effectivement construit quelque chose
- Ingénieurs mid-level avec un historique de travail fort : la section Projets est optionnelle. Incluez-la si vous avez des projets parallèles qui démontrent des compétences que votre historique de travail ne démontre pas (open source, expériences ML parallèles, une bibliothèque publiée, une extension Chrome populaire)
- Ingénieurs seniors et au-dessus : la section Projets est généralement non nécessaire. L'historique de travail à ce niveau devrait porter le poids. Exception : maintenance notable d'open source, travail publié bien connu ou contributions communautaires significatives
- Chaque entrée de projet doit avoir : nom du projet (avec lien vers le dépôt ou URL en direct), description d'une ligne de ce qu'il fait, le stack tech utilisé et 1-2 bullet points sur ce qui était non-trivial dans sa construction
- Préférez 2-4 projets forts à 8 faibles. Une app todo suivant un tutoriel n'aide pas ; un projet qui a résolu un problème réel et dont vous pouvez discuter en profondeur, oui
- Si le projet est un clone ou un suivi de tutoriel, ne le listez pas comme projet. Listez-le comme 'exercice d'apprentissage' si jamais, ou omettez
- Les liens en direct comptent plus que les liens de dépôt pour les projets orientés utilisateur. Un site déployé sur lequel le hiring manager peut cliquer est dramatiquement plus convaincant qu'un dépôt qu'il doit cloner
- Si le projet avait des collaborateurs, nommez-les et votre rôle spécifique. 'Construit API backend et couche de base de données pour projet d'équipe de 4 personnes' est honnête et spécifique ; revendiquer la paternité unique d'un projet d'équipe est le genre de chose qui se fait prendre dans l'entrevue
Le CV tech le plus fort au niveau junior/mid a souvent 2-3 projets substantiels dont le candidat peut parler en profondeur, avec des démos en direct. Cela surpasse souvent un historique de travail plus long mais moins différencié. Construisez les projets délibérément pour être la preuve la plus forte de votre CV.
GitHub, portfolio et travail démontrable
Les liens que vous incluez sur votre CV tech sont lus comme preuve que vous êtes un ingénieur pratiquant plutôt qu'un détenteur de credentials. Quels liens inclure et comment les présenter :
- GitHub : incluez pour presque tous les rôles d'ingénierie. Assurez-vous que le profil vers lequel vous liez est réel (commits récents, multiples dépôts, readme de profil peuplé). Un GitHub vide ou stagnant lié sur votre CV est pire qu'aucun lien
- Site personnel : incluez si vous en avez un et qu'il est à jour. Le site n'a pas besoin d'être fancy ; un portfolio simple avec liens vers projets, une bio courte et des informations de contact suffit. Un site cassé ou de l'ère 2019 est pire qu'aucun site
- LinkedIn : incluez. Même si vous pensez que LinkedIn est surtout du bruit, les recruteurs le vérifient et un profil vide signale un manque de professionnalisme
- Profil Stack Overflow : incluez seulement si vous avez une réputation significative et des réponses de haute qualité. Un profil de 50 réputation ne signale rien ; un profil de 50 000 réputation signale une vraie expertise
- Blog personnel ou écriture technique : incluez si vous écrivez du contenu technique régulièrement. Les posts de blog d'ingénierie démontrent la capacité de communication, la profondeur technique et une habitude de réflexion — toutes signaux que les hiring managers valorisent
- Présentations à conférences, podcasts, apparitions vidéo : incluez si vous en avez. Ils fonctionnent comme validation tierce que vous pouvez communiquer des idées techniques
- Rendez tous les liens cliquables dans le PDF (Word et Google Docs supportent tous deux cela quand vous 'Insérer hyperlien'). Les recruteurs cliqueront ; les liens cassés ou non cliquables vous coûtent le click-through
- Curatez avant de lier. Avant d'ajouter votre lien GitHub, regardez votre profil avec des yeux frais. Épinglez vos 4-6 meilleurs dépôts au profil. Assurez-vous que les README de dépôt sont écrits. Supprimez ou archivez les dépôts qui existent seulement comme tutoriels à moitié terminés. Le hiring manager formera une impression en 30 secondes de regarder votre profil — assurez-vous que c'est l'impression que vous voulez
Chaque lien sur votre CV tech est une promesse — cliquer dessus révélera plus de preuves de votre capacité d'ingénierie. Si cliquer révèle moins que ce que le CV suggérait, la candidature s'affaiblit. Les liens sont nets-positifs seulement si le matériel sous-jacent est à la hauteur de ce que le CV implique.
ATS pour rôles tech — le keyword matching qui compte
La plus grande partie de l'embauche tech dans les grandes entreprises passe encore par des systèmes ATS qui filtrent sur des mots-clés. La dynamique du matching ATS pour les rôles d'ingénierie :
- ATS pour les rôles tech exécute souvent un matching littéral de mots-clés contre la JD. Si la JD dit 'React' et votre CV dit 'React.js', certains systèmes ne feront pas correspondre. Utilisez l'orthographe exacte de la JD où possible
- Listez les technologies dans plusieurs sections, pas seulement dans la section Compétences. Un ingénieur senior qui a utilisé Kubernetes en production dans trois entreprises différentes devrait avoir 'Kubernetes' apparaissant dans ces trois descriptions de poste plus la section Compétences — l'algorithme de matching pondère les occurrences
- Les frameworks et outils spécifiques comptent plus que les catégories générales. 'React, Vue, Angular' est mieux que 'frameworks JavaScript'. 'PostgreSQL, MongoDB, Redis' est mieux que 'bases de données'
- Acronymes et formes complètes : incluez les deux. 'Machine Learning (ML)' couvre à la fois les requêtes 'ML' et 'machine learning'. 'Continuous Integration (CI/CD)' fait la même chose
- Variations communes : 'Node.js' et 'Nodejs' et 'Node' sont tous la même technologie mais les systèmes ATS peuvent ne pas le savoir. Si la JD dit 'Node.js', faites correspondre cette forme exacte
- Certifications et frameworks spécifiques à l'industrie : incluez si pertinents. 'PCI DSS', 'HIPAA', 'SOC 2', 'RGPD' si vous avez travaillé avec. 'Agile', 'Scrum', 'Kanban' si vous avez exécuté ces processus
- Évitez le keyword-stuffing qui casse la lisibilité. Le CV est lu par des humains après avoir passé l'ATS ; si le lecteur humain voit un mur de noms de technologie sans contexte, la candidature échoue à l'écran humain même si elle a passé l'écran ATS
- Adaptez par candidature. La liste de mots-clés qui passe un CV à travers l'ATS de Google est différente de la liste de mots-clés qui le passe à travers le Greenhouse d'une startup. Faites correspondre la JD spécifique
Le matching ATS est un premier obstacle nécessaire pour les rôles tech dans la plupart des grandes entreprises. Traitez-le comme un exercice littéral de matching : faites correspondre le vocabulaire de la JD, listez les technologies en contexte (dans les descriptions de poste, pas seulement dans la liste Compétences) et supposez que le matching est bête. Une fois passé l'ATS, le lecteur humain prend le contrôle et le contenu compte plus que la densité de mots-clés.
Comment fonctionne l'ATS et les règles de mots-clés pour le franchirQuantifier l'impact d'ingénierie
Les CVs tech souffrent souvent du même problème d'affirmations génériques que les CVs corporate : 'développé des features', 'amélioré la performance', 'travaillé sur la plateforme'. L'impact spécifique quantifié est ce qui sépare un CV tech fort d'un générique :
- Performance : 'réduit la latence p99 de l'API de 850ms à 120ms' bat 'amélioré la performance de l'API'. Les chiffres spécifiques sont crédibles ; les affirmations vagues ne le sont pas
- Échelle : 'géré 50K req/sec en pic' ou 'traité 2B événements/jour' ancre le travail dans une échelle réelle. Sans chiffres, le lecteur doit imaginer ; avec des chiffres, il comprend
- Coût : 'réduit le coût d'infrastructure AWS de 180K$/an par optimisation de base de données et tier-rightsizing' est le langage qui atterrit avec le leadership d'ingénierie. La réduction de coûts est souvent la métrique d'ingénierie à plus haut levier
- Fiabilité : 'réduit le taux d'incidents de production de 8/mois à 1/mois' ou 'amélioré le SLO du service de 99,5 % à 99,95 %' sont des métriques concrètes de fiabilité
- Équipe et scope : 'tech lead pour équipe de 6 ingénieurs' ou 'détenu conception end-to-end et implémentation du service de paiements' dit au lecteur votre scope de responsabilité. Sans cela, le travail pourrait être n'importe quoi de 'écrit une feature' à 'conçu le système entier'
- Livraison : 'livré 12 releases de production en 18 mois avec zéro incident majeur' ou 'livré projet 3 semaines en avance sur le calendrier en parallélisant infrastructure et travail de feature' raconte une histoire de livraison
- Adoption : 'bibliothèque interne utilisée par 15+ équipes' ou 'projet open source avec 8K étoiles GitHub' quantifie l'impact du travail qui n'a pas de métriques orientées client
- Quand vous n'avez pas de chiffres spécifiques, donnez des descriptions spécifiques. 'Migré le service de paiements de monolithe à architecture event-driven, avec zéro downtime pendant le cutover' est concret même sans un chiffre
Le pattern : chaque bullet devrait répondre 'et alors ?' Si un bullet dit 'développé des features', le et-alors est invisible. Si il dit 'développé flux de checkout qui a entraîné la hausse de conversion de 2,1 % à 3,2 % pendant l'expérience de 6 semaines', le et-alors est juste là. Réécrivez les bullets génériques jusqu'à ce qu'ils aient soit un chiffre, soit un résultat spécifique concret.
Comment quantifier l'impact technique avec des chiffres crédiblesOpen source, projets parallèles, hackathons
L'embauche en ingénierie valorise les contributions hors du travail rémunéré comme preuve d'engagement genuine avec le métier. Comment les gérer dans le CV :
- Contributions open source : incluez si substantielles. 'Maintainer de X (description du projet, 8K étoiles)' est signal élevé. 'Contribué bug fix à bibliothèque populaire Y' est signal moyen. 'Soumis PR au projet Z' est signal faible à moins que le PR ait été substantiel
- Listez la nature de la contribution : maintainer, contributeur régulier, contributeur occasionnel, contributeur ponctuel. La distinction compte et le cadrage honnête construit la crédibilité
- Si vous avez créé une bibliothèque ou outil open source populaire, menez avec sur le CV. Un projet open source largement utilisé est un des signaux les plus forts possibles de capacité d'ingénierie
- Projets parallèles : incluez 2-3 des plus forts dans une section Projets. Sautez les projets parallèles qui sont des suivis de tutoriel, à moitié terminés ou n'existent que comme dépôts privés
- Hackathons : incluez seulement si vous avez gagné ou êtes classé à un notable. Une 2e place à un hackathon majeur universitaire ou industriel vaut la peine d'être listée ; la participation à un hackathon de collège non, à moins que vous soyez très junior
- Projets internes d'entreprise : généralement ne comptent pas comme 'open source' même si discutés publiquement. Incluez-les sous expérience professionnelle à la place
- Implication communautaire : organisateur de meetup, conférencier, invité de podcast, écrivain technique — incluez ceux-ci si substantiels. Ils signalent un ingénieur qui s'engage avec la communauté plus large plutôt que juste faire son travail
- Soyez honnête sur le scope. 'Contribué à React' pourrait signifier 'ouvert un issue qui a été fermé sans PR' ou 'écrit 30 PRs qui ont été livrés'. L'affirmation du CV et les preuves GitHub doivent correspondre
Le rôle de l'open source et des projets parallèles change avec la séniorité. Au niveau junior, ce sont des preuves essentielles d'être un ingénieur pratiquant. Au niveau mid, ils différencient. Au niveau senior, ils signalent un engagement continu avec le métier au-delà du travail quotidien. Calibrez la proéminence à votre étape de carrière.
Éducation et certifications — ce qui compte
Les rôles tech pondèrent éducation et certifications très différemment des autres industries. Le paysage actuel :
- Ingénieurs juniors (0-2 ans) : l'éducation compte. Diplôme d'informatique ou apparenté d'une institution connue a du poids. Listez l'éducation proéminemment, près du haut du CV
- Ingénieurs mid-level (3-7 ans) : l'éducation compte moins. L'historique de travail est le signal primaire. Déplacez l'éducation vers le bas du CV à moins que vous ayez un diplôme particulièrement notable (école top-tier, diplôme avancé en champ pertinent)
- Ingénieurs seniors (8+ ans) : l'éducation est presque non pertinente pour la plupart des rôles. Une entrée d'une ligne en bas suffit. L'exception sont les rôles qui valorisent explicitement les credentials académiques (research engineering, certains rôles ML/AI)
- Diplômés de bootcamp : listez le bootcamp. Le marché d'embauche pour les diplômés de bootcamp a mûri ; les bootcamps réputés (Hack Reactor, App Academy, Lambda School historiquement) sont reconnus. Associez avec des projets forts pour compenser le temps d'apprentissage plus court
- Ingénieurs autodidactes sans éducation CS formelle : menez avec projets et historique de travail. Listez l'apprentissage auto-dirigé ('autodidacte, concentré sur développement web full-stack depuis 2019') honnêtement. N'inventez pas de credentials, mais ne vous sentez pas obligé d'en lister si vous n'en avez pas
- Certifications AWS / GCP / Azure : comptent pour les rôles concentrés sur le cloud (DevOps, SRE, cloud architect, ingénierie d'infrastructure). Listez le niveau spécifique de certification (Associate, Professional, etc.)
- Certifications de sécurité (CISSP, OSCP, CEH) : comptent pour les rôles de sécurité. Listez avec date obtenue
- Certifications générales de logiciel (Oracle Java, Microsoft .NET) : en grande partie ignorées. Les lister sur un CV de senior engineer est du remplissage
- Complétions de cours en ligne (Coursera, Udemy, edX) : généralement ne listez pas. Elles signalent que vous pouvez compléter un cours, pas que vous pouvez faire le travail. Exception : compléter un programme spécialisé (Stanford ML, spécialisation deep learning d'Andrew Ng) pourrait justifier une mention d'une seule ligne
- PhD : listez en haut si récent et pertinent ; déplacez vers le bas avec la séniorité. PhD est un signal fort pour les rôles orientés recherche et un signal neutre (parfois légèrement négatif pour la perception 'trop académique') pour les rôles d'ingénierie produit
Le pattern : l'éducation est un signal d'ingénieur junior qui s'estompe avec le temps. Les certifications sont des signaux de rôles spécialisés qui comptent quand elles sont pertinentes et sont du remplissage quand elles ne le sont pas. Calibrez la proéminence de ces sections à où vous êtes dans votre carrière.
CV tech remote-friendly — la nouvelle norme
Une part significative des rôles d'ingénierie en 2026 sont à distance ou hybrides. Le CV devrait signaler la remote-readiness, qui est maintenant une considération d'embauche en soi :
- Si vous avez de l'expérience de travail à distance, marquez-la : 'Senior Engineer (à distance), Acme Corp, 2022-2025'. Les recruteurs scannent pour cela ; l'expérience à distance est un signal positif pour les rôles à distance
- Emplacement : incluez ville et pays actuels, mais signalez la flexibilité si pertinent. 'Paris, France (ouvert au remote, fuseaux horaires UE)' ou 'San Francisco, CA (ouvert au remote aux US)'. 'Ouvert à la relocation' vague est plus faible que la disponibilité spécifique
- Fuseau horaire : listez-le si vous postulez pour des rôles à distance dans une géographie différente. 'Fuseau horaire : CET (UTC+1)' rend la planification plus claire
- Expérience avec outils de communication : dans un contexte pertinent au remote, mentionner l'expérience avec Slack, Notion, Linear, Figma, pair programming basé sur vidéo et workflows async-first signale fit pour la culture d'ingénierie à distance
- Langage d'auto-direction : 'mené le projet end-to-end de la spec au déploiement' signale l'autonomie que le travail à distance exige. 'Travaillé avec l'équipe pour livrer X' est neutre ; 'piloté X du concept au lancement indépendamment' est plus fort pour le remote
- Documentation et écriture : soulignez toute écriture technique, paternité de design docs ou contributions RFC. Les équipes à distance sur-reposent sur la communication écrite ; les ingénieurs qui écrivent bien sont plus faciles à embaucher à distance
- Signaux de chevauchement de fuseau horaire : si vous avez explicitement travaillé à travers les fuseaux horaires (un ingénieur US travaillant avec une équipe à Berlin, ou vice versa), mentionnez-le. La compétence de collaboration asynchrone est non-triviale
- Évitez de signaler une inflexibilité remote-only si vous êtes ouvert à l'onsite. Le biais existe encore dans certaines entreprises ; si vous êtes flexible, signalez la flexibilité
La remote-friendliness est passée d'être une préférence du candidat à être un critère d'embauche. Montrer sur le CV que vous avez travaillé à distance, communiqué asynchrone et opéré avec auto-direction est maintenant partie du travail du CV — pas seulement pour les rôles entièrement à distance mais pour les hybrides et même certains rôles onsite où la remote-readiness est traitée comme signal de qualité.
CVs pour junior vs mid vs senior vs staff/principal
L'accent du CV d'ingénierie change dramatiquement à travers les étapes de carrière. Ce qui fonctionne pour un CV junior coulera un CV staff et vice versa :
Ingénieur junior (0-2 ans)
Menez avec l'éducation, surtout si d'un programme connu. Suivez avec une section Projets substantielle — 2-3 projets qui démontrent que vous pouvez livrer du code. Incluez tous les stages sous Expérience. La section Compétences est proéminente et liste les langages, frameworks et outils que vous avez effectivement utilisés. CV total : une page.
Quantifiez les projets où possible ('construit X utilisé par Y utilisateurs', 'bibliothèque open source avec Z étoiles'). Utilisez des verbes d'action ('construit', 'implémenté', 'conçu'), pas de langage passif. Le CV junior vend le potentiel et la capacité de livrer — rendez les deux visibles.
Ingénieur mid-level (3-7 ans)
Menez avec l'Expérience, avec des bullets quantifiés forts par rôle. La section Compétences suit. La section Projets devient optionnelle (incluez si elle ajoute du signal que votre historique de travail n'a pas). L'éducation se déplace vers le bas. CV total : une page, occasionnellement saignant en deux.
Le CV mid-level vend le travail livré et la croissance. Montrez la progression dans les rôles (promu, scope élargi, mentoré d'autres). Montrez la propriété de systèmes complets, pas juste le travail de features. Le lecteur demande 'cette personne est-elle prête pour le niveau suivant ?'
Ingénieur senior (8+ ans)
Menez avec une brève déclaration de résumé (3-4 lignes) qui cadre votre spécialité et années d'expérience. Suivez avec Expérience, avec chaque rôle concentré sur scope, leadership technique et impact. La section Compétences devient plus courte (pas besoin de lister HTML/CSS), plus concentrée sur tech pertinente pour senior (conception de système, patterns architecturaux, plateformes spécifiques). L'éducation est une entrée d'une ligne en bas.
Le CV senior vend jugement, leadership technique et scope. Quantifiez le scope en termes de taille d'équipe, complexité de système, impact business. Montrez que vous avez mené des migrations, pris des décisions architecturales, mentoré d'autres ingénieurs. Le lecteur demande 'cette personne peut-elle opérer au niveau senior immédiatement ?'
Ingénieur Staff / Principal (12+ ans)
La déclaration de résumé est essentielle — 4-6 lignes qui cadrent votre aire de spécialité, le type de travail que vous faites au niveau staff/principal (stratégie technique cross-équipe, impact organisationnel, investissements techniques profonds) et quel genre de rôle vous cherchez. Chaque rôle décrit le scope technique et organisationnel, pas juste le travail.
Le CV staff/principal vend l'impact démontré au scope staff. Exemples : 'piloté la migration de la plateforme de Rails monolithique aux microservices pendant 2 ans, influençant 8 équipes', 'paternité de la stratégie architecturale qui est devenue la base pour les 3 prochaines années d'investissement en plateforme'. Sans preuves au scope staff, le CV se lit comme un CV senior et est filtré pour les rôles senior.
La déclaration de résumé pour rôles techniques
La déclaration de résumé en haut d'un CV tech est optionnelle pour les rôles junior et de plus en plus importante du niveau mid vers le haut. Comment en écrire une qui fait du travail :
- Longueur : 3-5 lignes. Assez longue pour cadrer votre spécialité, assez courte pour que le lecteur la lise réellement
- Menez avec les années d'expérience et la spécialité primaire : 'Ingénieur backend avec 7 ans d'expérience concevant des systèmes distribués à haute échelle, principalement en Go et Python.' C'est la première chose que le lecteur voit et cela devrait ancrer le CV entier
- Suivez avec une phrase sur le type de travail que vous faites bien : 'Je me concentre sur la frontière entre conception d'API et infrastructure, avec une expérience profonde dans les architectures event-driven et les internes de base de données.'
- Terminez avec ce que vous cherchez : 'À la recherche de rôles senior+ où je peux mener la conception d'un système backend critique et grandir dans le scope staff dans les 2 prochaines années.'
- Évitez les descripteurs génériques : 'passionné', 'orienté résultats', 'attentif aux détails'. Ceux-ci sont zéro-signal et se lisent comme du remplissage
- Évitez de résumer le reste du CV. Le résumé devrait ajouter des informations que le lecteur ne peut pas obtenir en scannant le reste — spécifiquement votre aire de spécialité, votre direction de carrière et ce qui fait de vous un candidat cohérent
- Adaptez par candidature. Le résumé est le lieu le plus facile pour signaler que le CV est ciblé sur ce rôle spécifique. Un résumé écrit pour un rôle d'infrastructure backend dans une entreprise de bases de données devrait se lire différemment du résumé de la même personne écrit pour un rôle de backend produit dans une entreprise SaaS
- Sautez le résumé entièrement si vous êtes un ingénieur junior. À cette étape de carrière, le résumé risque le remplissage sans ajouter de signal ; laissez votre travail parler pour lui-même
La déclaration de résumé est un immobilier à fort levier en haut du CV. Utilisée bien, elle dit au lecteur qui vous êtes en tant qu'ingénieur en 3-5 lignes et cadre tout ce qui suit. Utilisée mal (adjectifs génériques, aspirations vagues), c'est du remplissage qui évince le signal réel.
Rédiger un résumé de CV tech qui cadre votre spécialitéChoix de format de CV tech — une page vs deux pages
La question une page vs deux pages est plus nuancée pour les CVs tech que pour les autres industries. Le cadre :
- Une page : ingénieurs juniors (0-3 ans), la plupart des ingénieurs mid-level (3-7 ans) et ingénieurs dans des marchés où une page est la norme culturelle (la plupart de l'industrie tech US)
- Deux pages : ingénieurs seniors avec expérience substantielle (8+ ans), ingénieurs staff/principal avec scope significatif à communiquer, ingénieurs dans des marchés où deux pages sont normales (la plupart de l'Europe, en particulier Allemagne, France, UK)
- Jamais trois pages. Si vous ne pouvez pas ajuster votre CV en deux pages, le problème est l'édition, pas l'espace. Coupez les rôles plus anciens à des résumés d'une ligne, coupez le détail des rôles de carrière précoce, taillez les projets moins pertinents
- Si vous avez un document plus long de style CV (style académique, avec publications, présentations, brevets), gardez-le séparé. Le CV est le résumé orienté recruteur ; le document plus long est pour les demandes de suivi
- Format : colonne unique ou deux colonnes ? Colonne unique est plus sûre pour ATS. Si vous utilisez deux colonnes (sidebar pour compétences/contact, colonne principale pour expérience), testez le parsing en passant le PDF à travers un resume parser en ligne avant de soumettre
- Police : restez avec les polices standard (Calibri, Helvetica, Arial, Source Sans, Inter). Les polices de designer peuvent casser le parsing ATS. Texte de corps 10-11pt, titres 12-14pt
- Couleur : minimale. Une couleur d'accent pour les titres de section va bien ; le design en couleurs complètes est non nécessaire et peut casser ATS. Le contenu est le signal, pas le design
- Photo : pas dans les CVs tech US. Dans les pays européens où les photos sont normales (Allemagne, France), incluez une photo professionnelle
- Format de fichier : PDF. Toujours PDF. Les documents Word se reflusent sur des machines différentes et paraissent cassés ; les PDFs rendent consistement. Nommez le fichier consistement : 'Prénom-Nom-CV.pdf' ou 'Prénom-Nom-SeniorEngineer-CV.pdf'
Les décisions de format devraient servir le contenu, pas le distraire. Un CV tech qui utilise des polices standard, une structure simple et une couleur modeste est plus lisible qu'un qui essaie de ressembler à un portfolio de design. L'exception est l'ingénierie de design ou les rôles front-end où une certaine sophistication visuelle sur le CV même est un signal pertinent — mais même là, la retenue se lit comme confiance.
Coordonner CV, LinkedIn, GitHub et site personnel
Le CV tech est un document dans une présence en ligne coordonnée. Les hiring managers d'ingénierie regarderont multiples surfaces, et l'incohérence entre elles est un signal négatif. Le playbook de coordination :
- LinkedIn : devrait raconter la même histoire que le CV en termes de rôles, dates et scope. Le headline peut être plus aspirationnel ('Senior Backend Engineer intéressé par les systèmes distribués et le developer tooling'), mais la substance devrait correspondre. Un LinkedIn qui contredit le CV (dates différentes, titres différents, scope différent) détruit la confiance
- GitHub : devrait être vivant. Commits récents, readme de profil peuplé, 4-6 dépôts épinglés qui représentent votre meilleur travail, READMEs de dépôt propres. Un GitHub vide lié depuis le CV est pire qu'aucun lien. Si GitHub est rare, investissez un week-end pour le nettoyer avant d'envoyer le CV
- Site personnel : optionnel mais puissant quand bien fait. Une page simple avec une bio d'un paragraphe, des points forts de projets, un lien de téléchargement de CV et infos de contact suffit. Évitez Flash, formulaires de contact cassés, liens morts, dates de dernière mise à jour de 2020
- Cohérence de nom et identité : utilisez le même nom et la même photo à travers CV, LinkedIn, GitHub, site personnel. Les recruteurs font des références croisées ; un 'James Smith' sur le CV qui est 'Jim Smith' sur LinkedIn crée de la friction
- Adresse e-mail : cohérente à travers toutes les surfaces. Utilisez un e-mail professionnel (votrenom@votredomaine.com ou prenom.nom@gmail.com), pas un e-mail d'université ou un username de 2005
- Numéro de téléphone, emplacement et fuseau horaire : cohérents à travers les surfaces. Les signaux d'emplacement conflictuels paraissent comme de l'inattention
- Si vous avez un portfolio de travail publié (posts de blog technique, présentations, articles), liez depuis le CV à la source canonique — votre site personnel ou un profil centralisé, plutôt que 10 liens séparés
- Auditez avant de postuler. Avant d'envoyer le CV, cliquez sur chaque lien dessus comme si vous étiez un recruteur. Regardez le profil LinkedIn avec des yeux frais. Parcourez le GitHub. Si vous trouvez quelque chose qui contredit ou sape le CV, réparez-le avant de postuler
Le hiring manager construit une seule impression de vous à partir des surfaces coordonnées, pas des impressions séparées de chacune. Le CV qui pointe vers une présence en ligne cohérente se lit comme plus crédible qu'un avec un CV fort et un LinkedIn/GitHub faible ou contradictoire. Les trente minutes de nettoyage à travers les surfaces est un des usages à plus haut levier du temps dans une recherche d'emploi tech.
Comment aligner votre profil LinkedIn sur votre CV