Les CV DevOps et SRE partagent un défaut avec les CV de data engineering : ils ressemblent à un inventaire de stack. Kubernetes, Terraform, Prometheus, Argo, Datadog, Jenkins — le recruteur parcourt la liste sans rien apprendre sur votre capacité à tenir un système en production.
Ce que veut savoir le hiring manager est plus difficile : avez-vous réduit les pannes, avez-vous diminué le temps de déploiement, avez-vous tenu un Black Friday sans pager toute l'équipe. C'est ce CV-là qu'on rappelle.
Ce que regardent vraiment les hiring managers
Trois signaux, par ordre d'importance :
- Résultats de fiabilité. Chiffres SLO/SLA, gestion d'error budget, baisse de MTTR. Des chiffres venant de systèmes en production avec de vrais utilisateurs.
- L'échelle. Requêtes par seconde, taille du cluster, fréquence de déploiement, coût d'infra. « 200 microservices gérés » n'est pas la même chose que « 12 microservices gérés » — et les deux battent « microservices gérés ».
- Astreinte et réponse aux incidents. Fréquence des pages, cadence des postmortems, couverture des runbooks. La partie ingrate du métier est celle qui a brûlé le hiring manager.
La liste de stack vient après. Les ATS cherchent les mots-clés, donc gardez-les, mais jamais à la place d'un résultat.
La structure qui fonctionne
Une page si vous avez moins de 6 ans, deux pages sinon. L'ordre :
- Accroche — une ligne : poste, années d'expérience, signal de domaine (« Ingénieur DevOps · 7 ans · AWS multi-régions »).
- Compétences — 3 lignes max : cloud / IaC / monitoring ; langages ; tooling. Virgules, sans barres de niveau (elles passent mal en ATS et font puériles).
- Expérience — 4 à 6 bullets pour les postes récents, moins pour les plus anciens.
- Projets / open source — seulement si vous avez quelque chose avec du vrai trafic ou des stars. Un side project que personne n'utilise n'aide pas.
- Certifications — CKA, CKAD, équivalents AWS / GCP / Azure. Datées ; une certification expirée se lit pire que pas de certification.
- Formation — en bas de page sauf si vous avez obtenu le diplôme depuis moins de 2 ans.
Écrire des bullets qui portent
La formule à laquelle les recruteurs et hiring managers répondent : action + système + chiffre + résultat.
Faible : Maintenance de clusters Kubernetes.
Mieux : Maintien de 4 clusters GKE servant 12k RPS p99 sur 2 régions, disponibilité tenue à 99,97 % sur 18 mois.
Mieux encore avec ce qui a changé grâce à vous : Maintien de 4 clusters GKE servant 12k RPS p99 sur 2 régions ; introduction d'un failover multi-région qui a fait passer l'impact utilisateur d'une panne régionale de 40 minutes à moins de 90 secondes.
La dernière version est celle qu'on garde. Elle montre le système, l'échelle, et le travail qui a fait bouger la courbe.
Les chiffres à quantifier
DevOps et SRE sont étonnamment riches en chiffres. Une bullet sans métrique fait paresseux. Ce qui mérite d'être exposé :
- Uptime / SLO. « 99,95 % sur 12 mois » bat « haute disponibilité ».
- MTTR. « MTTR descendu de 47 min à 12 min sur 2 trimestres. »
- Fréquence de déploiement. « 22 déploiements par jour en rolling. »
- Coût d'infra. « Coût cloud réduit de 31 % YoY sans changer la forme des instances » ou « 480 k$/an économisés en rightsizing Redis. »
- Débit. RPS, événements par seconde, profondeur de file en pic.
- Taille de cluster et de fleet. Nombre de pods, de nœuds, répartition multi-région.
- Charge d'astreinte. « Pages par semaine ramenées de 9 à 2 en ajoutant des alertes sur indicateurs avancés. »
Si vous ne vous souvenez plus des chiffres exacts d'il y a deux ans, soyez juste sur l'ordre de grandeur. Un mauvais ordre de grandeur (1k vs 10k RPS) se fait griller en entretien ; un honnête « autour de 10k » non.
Ce qu'il faut couper
Trois sources fréquentes de gras sur ce type de CV :
- Inventaires d'outils sur plusieurs lignes. « Docker, Kubernetes, Helm, Kustomize, ArgoCD, FluxCD, Jenkins, GitLab CI, GitHub Actions, CircleCI, Spinnaker, Buildkite, ConcourseCI, Drone, TeamCity » — choisissez les 6 que vous utilisez vraiment, jetez le reste.
- Certifications de plus de 5 ans non renouvelées. Elles signalent des compétences obsolètes plus qu'elles n'aident.
- Responsabilités génériques. « Responsable de l'environnement de production » — c'est le cas de tout ingénieur DevOps. Remplacez par ce que vous avez précisément fait.
- Bullets de soft skills. « Bon communicant » — l'astreinte révélera la communication plus vite que votre CV.
Adapter SRE vs DevOps vs Platform Engineer
Les titres se chevauchent mais l'accent change.
- Postes SRE — partez sur les maths de fiabilité : définition SLO/SLI, error budget, réduction du toil, planification de capacité. Montrez la couche politique, pas seulement l'outillage.
- Postes DevOps engineer — partez sur la livraison : pipelines, fréquence de déploiement, lead time, couverture en IaC.
- Postes platform engineer — partez sur l'expérience développeur : abstractions self-service que vous avez construites, clients internes, taux d'adoption du paved path.
Vous postulerez souvent à des postes qui mélangent deux de ces orientations. La solution n'est pas d'écrire trois CV — c'est de tenir un CV maître avec toutes vos meilleures bullets et de choisir les 4 à 6 qui collent à chaque emphase.
Si vous gardez votre expérience dans un outil structuré (LinkedIn, Postulit, n'importe où avec des bullets taggées), permuter les bullets de tête par candidature devient trivial — sans réécrire le document à chaque fois.
La rubrique astreinte n'est pas optionnelle
Presque tous les CV DevOps/SRE sous-vendent l'histoire de l'astreinte. Le hiring manager en a fait, et cherche quelqu'un qui a survécu sans cramer, sans être celui qui page les autres.
Deux lignes en bas de chaque poste suffisent :
Astreinte : 1 semaine en primaire toutes les 5 semaines, rotation à 4 ingénieurs. Co-auteur du runbook équipe (24 services). Pages non actionnables descendues de ~40 % à ~8 % en réglant les seuils d'alerte et le routage par propriétaire.
Ca en dit plus sur vous que n'importe quelle liste d'outils.
Exemples de réécriture de bullets
Avant : Travail sur Terraform et l'infrastructure AWS.
Après : Propriété du monorepo Terraform sur 18 comptes AWS ; mise en place du versioning de modules et d'une pipeline de revue qui ont fait passer les mauvais déploiements de ~1/semaine à <1/mois.
Avant : Mise en place du monitoring avec Prometheus et Grafana.
Après : Construction de zéro de la stack Prometheus + Grafana pour 64 services ; introduction d'alertes SLO burn-rate, volume des fausses pages baissé de 73 % au premier trimestre.
Avant : Migration de services vers Kubernetes.
Après : Migration de 36 services d'EC2 vers EKS sur 7 mois ; conception de la stratégie de rollback qui a maintenu disponibles les 12 services monolithiques, zéro incident visible utilisateur pendant la fenêtre de bascule.
Le schéma reste le même : nommer le système, quantifier le travail, finir sur le résultat.
Les CV DevOps et SRE sont évalués par des gens qui ont fait le métier. Ils repèrent l'outillage sans contexte en deux secondes. Ouvrez sur ce qui est resté debout, ce qui est devenu plus rapide, ce qui a coûté moins grâce à votre travail — la liste de stack est la preuve qui suit, pas le titre.