Comment rédiger un CV pour un poste d'ingénieur DevOps

Ce qu'un recruteur cherche en premier

Un recruteur DevOps lit un CV en cherchant deux choses avant tout : quelles parties de la chaîne d'outils vous avez réellement opérées, et si vous avez porté une responsabilité en production ou simplement touché à cela dans un bac à sable. Il scanne, il ne lit pas, en première passe. Cela signifie que le premier tiers de la page doit répondre à « qu'ont-ils fait tourner en production, et à quelle échelle » sans que le lecteur ait à le chercher.

C'est différent d'un CV d'ingénieur logiciel, où le scan porte sur les langages et la conception système. Un recruteur DevOps ou SRE veut voir les outils d'orchestration et de provisionnement spécifiques (Kubernetes, Terraform, Ansible, Pulumi), quel cloud (AWS, Azure, GCP — et quels services à l'intérieur, car « AWS » seul ne leur dit pas grand-chose), l'outillage CI/CD (Jenkins, GitLab CI, GitHub Actions, CircleCI, ArgoCD), et si vous avez assumé l'astreinte. Si votre CV s'ouvre sur un résumé générique parlant d'être un « professionnel orienté résultats », vous avez utilisé les six secondes dont vous disposiez sur quelque chose qui ne leur dit rien.

Indiquez la pile que vous avez utilisée, et votre responsabilité spécifique dans celle-ci, dans la première entrée de poste, dans les deux premières lignes. « Propriété des modules Terraform provisionnant des clusters EKS sur trois comptes AWS » fait le travail. « Responsable de l'infrastructure et des processus de déploiement » ne le fait pas, car cela survivrait à être copié tel quel sur le CV d'un administrateur système ou d'un ingénieur build. C'est le test : si une phrase pourrait figurer aussi bien sur le CV d'un autre métier, supprimez-la.

Les certifications et ce qu'elles valent réellement

Il n'existe pas de licence pour exercer en tant qu'ingénieur DevOps — pas d'ordre professionnel, rien d'équivalent à une qualification de barreau ou un numéro d'agrément gaz. Les certifications fonctionnent donc ici comme un signal, pas comme un seuil, et les recruteurs varient considérablement dans le poids qu'ils leur accordent. Il vaut mieux être honnête sur cette variation plutôt que de prétendre qu'il y a une réponse établie.

Les certifications qui sont effectivement reconnues dans ce domaine sont limitées : AWS Certified DevOps Engineer – Professional, AWS Certified Solutions Architect, Azure Administrator (AZ-104) ou Azure DevOps Engineer Expert (AZ-400) de Microsoft, Professional Cloud DevOps Engineer de Google, Certified Kubernetes Administrator (CKA) et Certified Kubernetes Application Developer (CKAD) de la CNCF, et Terraform Associate de HashiCorp. Si vous en détenez une, listez-la avec l'année — les certifications dans ce domaine vieillissent, car les services et le contenu des examens changent tous les ans ou deux, et un certificat de niveau associé de 2019 se lit différemment d'un certificat obtenu en 2025.

Ce qui n'aide pas : lister tous les cours Udemy ou Coursera que vous avez terminés. Un recruteur qui doit déterminer si « Docker & Kubernetes: The Complete Guide » est une certification reconnue par un éditeur ou un cours de week-end supposera le second et passera à autre chose. Si l'apprentissage autonome est vraiment pertinent, mettez-le dans une courte ligne « en cours d'apprentissage » plutôt que de le présenter comme équivalent à une certification — la différence est immédiatement visible pour quiconque dans le domaine, et prétendre le contraire vous coûte de la crédibilité sur tout le reste de la page.

Une chose mérite d'être dite directement : il n'existe aucune preuve solide que les certifications sont corrélées à la performance au travail dans ce domaine, et de nombreux ingénieurs expérimentés à des postes seniors n'en détiennent aucune. Traitez-les comme un raccourci utile pour un recruteur faisant un premier tri, pas comme une preuve de compétence pour quelqu'un de technique faisant le second.

Comment l'expérience se démontre normalement dans ce domaine

Le travail DevOps ne produit pas le type de portfolio qu'un designer ou un rédacteur peut montrer. Personne ne peut regarder votre fichier d'état Terraform. Le CV doit donc faire le travail de démonstration lui-même, à travers des détails qui sont vérifiables en principe même si le lecteur ne les vérifie pas.

Les détails qui ont du poids :

• L'échelle : nombre de nœuds, clusters, services ou environnements dont vous étiez responsable. « Géré la plateforme Kubernetes » est vague ; « exploité un cluster EKS de 40 nœuds servant 12 services de production » ne l'est pas.
• Les métriques opérationnelles avant-après que vous pouvez réellement attribuer à votre travail : fréquence de déploiement, délai de mise en œuvre des changements, temps moyen de récupération (MTTR), taux d'échec des changements — les quatre métriques DORA sont ce qui se rapproche le plus d'un langage de mesure partagé dans ce domaine, et nommer celle que vous avez fait bouger, et d'à peu près combien, est bien plus fort que « amélioration de l'efficacité du déploiement ».
• Propriété des incidents : si vous étiez la personne appelée, pas simplement quelqu'un dans une équipe qui avait une rotation d'astreinte. « Astreinte principale pour l'infrastructure de paiement, une semaine sur quatre » est spécifique. « Participation à la réponse aux incidents » ne l'est pas.
• Travaux de migration et de plateforme : passage d'EC2 aux conteneurs, d'un monolithe aux microservices, de Kubernetes autogéré à un plan de contrôle managé, de Jenkins à GitOps avec ArgoCD. Les migrations sont un matériau naturel pour le CV car elles ont un avant, un après et une durée clairs.
• Coût : l'optimisation des coûts cloud est quelque chose que les recruteurs sensibles au FinOps recherchent spécifiquement et c'est rarement mentionné. Si vous avez redimensionné des instances, déplacé des charges de travail vers du spot, ou renégocié de la capacité réservée et que cela a réduit les dépenses, dites-le — c'est l'un des rares endroits où un chiffre a sa place, à condition que vous puissiez le défendre en entretien.

Ce qui ne démontre pas l'expérience : une simple liste de noms d'outils sans contexte. « Compétences : AWS, Docker, Kubernetes, Terraform, Jenkins, Prometheus, Grafana » en haut de la page dit à un recruteur que vous avez entendu parler de ces outils. Cela ne lui dit pas ce que vous en avez fait. Chaque outil nommé devrait réapparaître, attaché à une tâche, quelque part dans la section expérience — s'il ne le fait pas, le recruteur suppose raisonnablement une exposition plutôt qu'une propriété.

Ce qui doit figurer sur la page, spécifiquement

• Le fournisseur cloud et la profondeur à l'intérieur. Pas seulement AWS — quels services. EC2 et S3 est basique ; EKS, RDS, conception de politiques IAM, peering VPC et Lambda pour l'automatisation sont un autre niveau de la plateforme.
• Outillage d'infrastructure-as-code et si vous avez écrit des modules ou les avez consommés. Il y a une vraie différence entre écrire un module Terraform réutilisable utilisé par d'autres équipes et appliquer celui de quelqu'un d'autre.
• Détails de l'orchestration de conteneurs : les distributions Kubernetes importent (vanilla, EKS, GKE, AKS, OpenShift), tout comme les outils environnants — Helm, Kustomize, les service meshes comme Istio ou Linkerd si vous les avez utilisés.
• Stack d'observabilité : Prometheus, Grafana, Datadog, la pile ELK/EFK, OpenTelemetry. Dites ce que vous avez instrumenté, pas seulement quel tableau de bord vous avez regardé.
• Plateforme CI/CD et conception de pipeline, y compris si les pipelines étaient quelque chose que vous avez configuré dans un template existant ou quelque chose que vous avez conçu de zéro, incluant la gestion des artefacts et la stratégie de rollback.
• Points de contact sécurité et conformité pertinents pour ce rôle : gestion des secrets (Vault, AWS Secrets Manager), support d'audit SOC 2 ou ISO 27001, travail IAM à moindre privilège. Si vous avez traversé un audit de conformité en tant qu'ingénieur devant produire les preuves, cela vaut une ligne — les auditeurs et les recruteurs reconnaissent tous deux cela comme un type spécifique de pression.
• Langage utilisé pour l'automatisation et l'outillage — Python, Go, Bash — nommé comme outil pour un usage (écrire des opérateurs personnalisés, scripts d'automatisation, CLI internes), pas comme une liste générique de « langages de programmation ».

Ce que les candidats de ce domaine oublient régulièrement

L'écart le plus courant est le contexte d'équipe et organisationnel. DevOps se situe entre développement et opérations par définition, et un CV qui ne dit pas avec qui vous avez travaillé — « intégré à deux équipes produit », « seul ingénieur plateforme supportant 30 développeurs », « partie d'une équipe SRE de quatre personnes couvrant l'astreinte follow-the-sun » — laisse le recruteur incapable de juger le périmètre. Le même travail d'infrastructure signifie quelque chose de différent fait seul versus fait au sein d'une équipe plateforme de douze personnes.

Le deuxième écart est l'échec. Les ingénieurs dans ce domaine sont souvent mal à l'aise de mettre une panne sur leur CV, mais un incident bien géré, avec une description claire de ce qui a cassé, de ce que vous avez fait, et de ce qui a changé après, est une preuve plus forte de séniorité qu'une autre ligne sur « le maintien de la disponibilité ». N'importe qui peut revendiquer une haute disponibilité ; tout le monde ne peut pas décrire ce qu'il a fait la seule fois où elle n'était pas disponible.

Le troisième est le travail de maintenance ennuyeux qui maintient une plateforme en marche — correctifs, mises à jour de dépendances, rotation de certificats, tests de sauvegarde et restauration. C'est peu glorieux, donc les gens le coupent, mais un recruteur construisant une équipe lourde en ops se souciera souvent plus de savoir si vous avez réellement mené un exercice de reprise après sinistre que si vous avez utilisé le tout dernier outil de la pile.

Enfin, les gens laissent de côté ce qu'ils ont décidé de ne pas faire. L'ingénierie de plateforme consiste autant à dire non à la complexité inutile qu'à construire des choses. Une ligne comme « recommandation contre une migration service mesh pour des raisons de coût et de charge opérationnelle » signale un jugement qu'une liste d'outils ne signalera jamais.

Que faire ensuite

Passez en revue votre CV actuel ligne par ligne et demandez-vous, pour chaque puce : cette phrase pourrait-elle, inchangée, figurer sur le CV d'un administrateur système ou d'un développeur backend ? Si oui, ajoutez l'outil spécifique, l'échelle spécifique, ou la métrique spécifique jusqu'à ce qu'elle ne le puisse plus. Vérifiez ensuite que chaque outil que vous avez nommé dans une liste de compétences apparaît également attaché à une tâche dans votre section expérience — si ce n'est pas le cas, ajoutez soit la tâche, soit retirez l'outil.

Si vous envoyez des candidatures et n'entendez rien en retour, il vaut la peine de vérifier si l'écart est le CV ou l'adéquation — beaucoup de postes DevOps annoncés sous un seul titre couvrent un travail réel assez différent, de l'ingénierie de plateforme à la gestion de version en passant par le pur SRE, et un CV ajusté pour l'un se lit comme une inadéquation pour l'autre. jobmarket.pro lit chaque annonce en entier et prépare la candidature à partir de votre expérience réelle, adaptée à ce que ce poste spécifique demande, plutôt que d'envoyer le même CV à chaque publication avec le titre du poste changé.