Un CV pour un poste de DevOps ou d'ingénieur plateforme se lit mieux lorsqu'il met en avant la fiabilité, la responsabilité d'astreinte, les migrations d'infrastructure et les outils dont dépendent d'autres équipes, plutôt que les puces axées sur les fonctionnalités qu'un CV d'ingénieur logiciel classique privilégie souvent. Les deux types de CV partagent la plupart des mêmes mécanismes : une expérience en ordre chronologique inverse, un court résumé, une section compétences, et des puces qui décrivent des résultats plutôt que des tâches. Ce qui change, c'est quels résultats comptent réellement dans ce genre de rôle, puisque les bénéficiaires du travail d'infrastructure sont généralement d'autres ingénieurs plutôt que des utilisateurs finaux, et que le travail lui-même reste souvent invisible quand tout se passe bien.
Pourquoi l'accent se déplace
Une fonctionnalité livrée par un ingénieur logiciel a généralement un avant-après visible : un écran qui n'existait pas, un parcours qui passait de cinq étapes à deux. Le travail d'infrastructure et de plateforme atteint rarement ce même résultat visible, car le meilleur résultat possible est souvent que rien ne change du point de vue de l'utilisateur : un déploiement qui réveillait quelqu'un à deux heures du matin ne le fait plus, un service qui s'effondrait sous la charge ne s'effondre plus. Un CV pour ce type de rôle doit rendre cette fiabilité invisible lisible pour une lectrice qui n'a jamais travaillé en infrastructure, en nommant ce qui dépendait du travail et ce qui aurait cassé sans lui.
Décrire honnêtement la fiabilité et la disponibilité
Le travail de fiabilité invite au même piège décrit dans chiffrer son impact d'ingénieur sur un CV sans inventer de chiffres : un chiffre tentant mais invérifiable comme « amélioration de la disponibilité de 40 % » alors qu'un tel chiffre n'a jamais vraiment été suivi. Là où une métrique réelle et vérifiable existe encore, issue d'un tableau de bord ou d'un rapport d'incident, elle a sa place telle quelle sur le CV. Là où elle n'existe pas, le périmètre et un état avant-après décrit portent le même poids sans le risque.
L'astreinte et la réponse aux incidents comme contenu de CV
La responsabilité d'astreinte mérite d'être nommée directement plutôt que noyée dans une ligne vague comme « support des systèmes de production », car elle signale un niveau de responsabilité opérationnelle qu'un rôle purement axé sur les fonctionnalités ne porte pas. Ce qui se lit bien, c'est la forme de cette responsabilité : quel système vous avez porté en astreinte, comment la rotation fonctionnait grossièrement, et une chose concrète qui a changé grâce à un incident géré.
Migrations et changements d'infrastructure qui méritent d'être nommés
Une migration, un changement de plateforme ou un changement d'outil mérite sa propre puce lorsqu'il s'agit du type de projet auquel d'autres ingénieurs ont dû s'adapter, plutôt qu'un changement purement interne que personne hors de l'équipe n'a remarqué. Nommer ce qui a bougé et pourquoi apporte généralement plus d'information que la simple mention du nom de la technologie cible.
Des outils dont dépendent d'autres équipes
Un outil interne mérite le même traitement qu'une fonctionnalité orientée client : ce qu'il fait, qui l'utilise, ce qu'il a remplacé. Présenter des projets personnels sur un CV d'ingénieur logiciel couvre la même structure sous-jacente pour un travail construit hors d'un poste formel, et elle s'applique tout aussi bien à un outil interne construit à l'intérieur d'un poste.
Exemple illustratif : une puce réécrite autour de la responsabilité d'infrastructure
Avant, vague et orienté fonctionnalité : « A travaillé sur l'infrastructure et le déploiement pour l'équipe backend. » Après, réécrit autour de la responsabilité, du périmètre et d'un état avant-après décrit : « A porté la pipeline de déploiement des onze services de l'équipe backend ; la pipeline exigeait auparavant une validation manuelle pour chaque service avant le déploiement, et après la refonte, une suite de tests réussie suffisait pour déployer automatiquement, réduisant de trois à un le nombre d'ingénieurs devant être disponibles au moment de la mise en production. »
Regrouper une longue liste d'outils et de plateformes
La section compétences d'un ingénieur plateforme s'étend souvent plus qu'un développeur classique, couvrant à la fois fournisseurs cloud, outils d'orchestration, systèmes de supervision et langages, exactement le type de liste longue et mixte qui bénéficie d'un regroupement par catégories plutôt que d'une seule ligne non triée.
Créez le vôtre
Le modèle Developer de CVBuilderKit est construit autour d'entrées orientées projet et responsabilité, ce qui convient aussi bien au travail d'infrastructure et de plateforme qu'au code applicatif. Partez de ce modèle, ou d'un document vierge, dans le générateur et retravaillez vos puces de fiabilité, d'astreinte et de migration autour de ce qui dépendait réellement du travail avant de chercher un chiffre que vous ne pouvez pas actuellement justifier.