CV ingénieur DevOps : compétences, exemple et conseils

Exemple de CV d’ingénieur DevOps

Cet exemple fictif montre comment présenter un environnement technique et des responsabilités. Adaptez-le à votre expérience réelle.

Quelles compétences mettre sur un CV d’ingénieur DevOps ?

Selon votre expérience, vous pouvez notamment faire apparaître :

• DevOps ;
• CI/CD ;
• Git ;
• GitLab CI ;
• GitHub Actions ;
• Jenkins ;
• Azure DevOps ;
• Docker ;
• Kubernetes ;
• Helm ;
• Terraform ;
• Ansible ;
• Infrastructure as Code ;
• Linux ;
• Bash ;
• Python ;
• PowerShell ;
• AWS ;
• Azure ;
• Google Cloud ;
• cloud computing ;
• containers ;
• orchestration ;
• monitoring ;
• observability ;
• Prometheus ;
• Grafana ;
• ELK / Elastic Stack ;
• OpenSearch ;
• logs ;
• alerting ;
• GitOps ;
• Argo CD ;
• Flux ;
• secrets management ;
• Vault ;
• artifact repositories ;
• Nexus ;
• Artifactory ;
• Nginx ;
• reverse proxy ;
• scripting ;
• automatisation ;
• configuration management ;
• infrastructure ;
• haute disponibilité ;
• sauvegarde ;
• incident management ;
• troubleshooting ;
• sécurité ;
• patching ;
• IAM selon votre rôle ;
• FinOps si réellement pratiqué ;
• Agile ;
• Scrum.

Ne cherchez pas à tout afficher.

Le recruteur doit surtout identifier votre stack principale et votre niveau réel d’autonomie.

Précisez immédiatement votre environnement DevOps

Le terme « DevOps » couvre des postes très différents.

Vous pouvez être davantage orienté :

• cloud ;
• CI/CD ;
• Kubernetes ;
• plateforme ;
• infrastructure ;
• automatisation ;
• exploitation ;
• SRE ;
• sécurité ;
• Microsoft Azure ;
• AWS ;
• environnements hybrides.

Par exemple :

Ingénieur DevOps – AWS / Kubernetes / Terraform

est beaucoup plus précis que :

Ingénieur DevOps

seul.

Quel titre mettre sur un CV d’ingénieur DevOps ?

Quelques exemples :

Ingénieur DevOps – AWS / Kubernetes

DevOps Engineer – Terraform & Kubernetes

Ingénieur DevOps Cloud – Azure

DevOps / Platform Engineer

Ingénieur DevOps – CI/CD et Infrastructure as Code

Cloud DevOps Engineer

Ingénieur DevOps – Linux / Docker / Kubernetes

Gardez un titre cohérent avec votre véritable expérience.

Exemple d’accroche pour un CV d’ingénieur DevOps

Exemple généraliste

Ingénieur DevOps avec 6 ans d’expérience en automatisation d’infrastructures et chaînes CI/CD. Environnements Linux, Docker, Kubernetes, Terraform et AWS. Contribution à la fiabilisation des déploiements et à la réduction des tâches manuelles d’exploitation.

Exemple cloud

Cloud DevOps Engineer spécialisé AWS et Infrastructure as Code. Déploiement d’environnements via Terraform, automatisation CI/CD, conteneurisation Docker et exploitation de workloads Kubernetes.

Exemple Kubernetes

Ingénieur DevOps spécialisé Kubernetes avec expérience sur des plateformes conteneurisées en production. Helm, GitLab CI, Terraform, Prometheus/Grafana et automatisation Bash/Python.

Évitez :

Passionné de DevOps, cloud et nouvelles technologies.

Cela ne permet pas d’évaluer votre niveau.

Faites apparaître la taille de votre environnement

Le contexte technique est essentiel.

Vous pouvez quantifier :

• nombre d’applications ;
• nombre de clusters ;
• nombre de namespaces ;
• nombre de serveurs ;
• nombre de pipelines ;
• fréquence de déploiement ;
• nombre d’équipes accompagnées ;
• nombre d’environnements ;
• volume de ressources cloud.

Par exemple :

Exploitation de 5 clusters Kubernetes hébergeant une quarantaine de services.

Maintenance de plus de 80 pipelines CI/CD.

Support DevOps auprès de 12 équipes de développement.

Automatisation du déploiement de plus de 200 ressources cloud.

Cela situe immédiatement votre expérience.

Comment présenter CI/CD ?

Évitez :

CI/CD.

Précisez :

Conception et maintenance de pipelines d’intégration et de déploiement continus.

Compilation.

Tests automatisés.

analyse de qualité.

création des artefacts.

déploiement par environnement.

contrôles avant mise en production.

Cela montre ce que vous faites réellement.

Comment présenter GitLab CI ?

Vous pouvez écrire :

GitLab CI — création et maintenance de pipelines pour build, tests, packaging et déploiement.

Mise en place de templates réutilisables pour plusieurs projets.

Gestion des variables et environnements.

Optimisation des temps d’exécution.

Le contexte est plus utile que le nom de l’outil seul.

Comment présenter GitHub Actions ?

Par exemple :

Création de workflows GitHub Actions pour tests, build d’images Docker et déploiement automatisé.

Mise en place de workflows réutilisables.

Gestion des secrets via les mécanismes prévus par la plateforme.

Cela montre une vraie pratique.

Comment présenter Jenkins ?

Vous pouvez écrire :

Administration et évolution de pipelines Jenkins.

Création de pipelines as code.

Intégration avec Git, registry et outils de qualité.

Traitement des jobs instables.

Standardisation des pipelines entre projets.

Cela permet de différencier un simple utilisateur d’un ingénieur qui structure la plateforme.

Comment présenter Azure DevOps ?

Si vous l’utilisez :

Azure DevOps — pipelines de build et release, repositories et automatisation de déploiements vers Azure.

Décrivez ensuite dans vos expériences les projets concernés.

Comment présenter un pipeline de bout en bout ?

Par exemple :

Commit Git tests analyse qualité build image Docker publication dans registry déploiement Kubernetes contrôles post-déploiement.

Une telle formulation aide à comprendre votre niveau d’intervention.

Comment quantifier l’amélioration du CI/CD ?

Exemples :

Temps moyen du pipeline réduit de 25 à 12 minutes.

Déploiement d’une release réduit de 45 minutes à moins de 10 minutes.

Passage de déploiements hebdomadaires à plusieurs déploiements quotidiens sur certaines applications.

Réduction des opérations manuelles nécessaires avant mise en production.

Utilisez uniquement des résultats fiables.

Comment présenter Docker ?

Évitez :

Docker : expert.

Préférez :

Création et optimisation d’images Docker pour des applications Java et Node.js.

Utilisation de builds multi-stage.

Gestion des variables de configuration.

Publication dans un registry interne.

Analyse des problèmes de conteneurisation.

Cela montre votre pratique réelle.

Comment présenter l’optimisation des images Docker ?

Vous pouvez écrire :

Réduction de la taille des images via builds multi-stage et suppression des dépendances inutiles.

Standardisation des images de base.

Amélioration du temps de build et de transfert.

Si vous avez un chiffre :

Image réduite de 1,2 Go à 350 Mo.

Cela constitue un résultat très concret.

Comment présenter Kubernetes ?

Le terme seul ne suffit pas.

Vous pouvez écrire :

Déploiement et exploitation d’applications sur Kubernetes.

Gestion des Deployments, Services, ConfigMaps et Secrets selon le périmètre.

Analyse des pods et événements.

Gestion des ressources.

Diagnostic des incidents.

Mise à jour des workloads.

Cela permet de comprendre votre autonomie.

Comment présenter un cluster Kubernetes ?

Si vous administrez réellement la plateforme :

Administration opérationnelle de plusieurs clusters Kubernetes.

Gestion des namespaces.

quotas et ressources.

mises à jour selon les procédures.

supervision.

troubleshooting.

gestion de certains composants de plateforme.

Si vous ne gérez que les applications, précisez plutôt :

Déploiement et exploitation de workloads sur Kubernetes.

Comment présenter Helm ?

Vous pouvez écrire :

Création et maintenance de charts Helm pour standardiser les déploiements Kubernetes.

Gestion des valeurs par environnement.

Versionnement des charts.

Déploiement via pipeline CI/CD.

Cela montre une pratique concrète.

Comment présenter Argo CD ?

Si vous travaillez en GitOps :

Argo CD — synchronisation des configurations Kubernetes depuis Git.

Gestion des environnements via repositories dédiés.

Analyse des différences entre état attendu et état déployé.

Utilisation dans une approche GitOps.

Ne mentionnez GitOps que si le processus fonctionne réellement ainsi.

Comment présenter GitOps ?

Vous pouvez écrire :

Déploiements Kubernetes gérés à partir de configurations versionnées dans Git.

Pull requests pour les changements.

Synchronisation automatisée vers les environnements.

Traçabilité des versions déployées.

Cela rend le concept concret.

Comment présenter Terraform ?

Évitez :

Terraform.

Préférez :

Terraform — provisionnement de ressources cloud et gestion de l’infrastructure sous forme de code.

Création de modules réutilisables.

Gestion des variables par environnement.

Revue des plans avant application.

Cela montre votre niveau.

Comment présenter des modules Terraform ?

Par exemple :

Création de modules Terraform standardisant réseaux, machines virtuelles ou services cloud.

Réutilisation sur plusieurs environnements.

Versionnement et documentation.

Réduction des différences de configuration entre projets.

Cela peut être particulièrement différenciant.

Comment présenter Terraform State ?

Si vous intervenez réellement sur cette partie :

Gestion du state distant selon l’architecture définie par l’équipe.

Séparation des environnements.

Gestion des verrouillages.

Traitement des écarts entre infrastructure et configuration.

N’entrez pas dans des détails excessifs si ce n’est pas central au poste.

Comment présenter Infrastructure as Code ?

Vous pouvez écrire :

Automatisation du provisionnement d’environnements via Terraform.

Versionnement de la configuration dans Git.

Revue par pull request.

Déploiement reproductible entre développement, recette et production.

Cela illustre clairement le principe.

Comment présenter Ansible ?

Si vous l’utilisez :

Ansible — automatisation de la configuration de serveurs Linux.

Déploiement de packages et fichiers de configuration.

Gestion de services.

Création de rôles réutilisables.

Cela montre une vraie pratique du configuration management.

Terraform ou Ansible : comment les différencier sur le CV ?

Vous pouvez implicitement montrer leur usage :

Terraform — provisionnement de l’infrastructure.

Ansible — configuration des systèmes et services.

Il n’est pas nécessaire de faire un cours, mais l’usage concret évite les listes de technologies sans contexte.

Comment présenter AWS ?

AWS seul est trop large.

Précisez les services réellement utilisés.

Par exemple :

AWS — EC2, IAM, VPC, S3, RDS et services de conteneurs selon le périmètre.

Puis montrez ce que vous faites :

provisionnement Terraform ;

supervision ;

CI/CD ;

sécurisation ;

exploitation.

N’énumérez pas 25 services pour améliorer artificiellement la densité de mots-clés.

Comment présenter Azure ?

Vous pouvez écrire :

Azure — machines virtuelles, services Kubernetes ou services applicatifs selon l’environnement.

Automatisation du provisionnement via Terraform.

Intégration avec pipelines Azure DevOps.

Supervision et gestion opérationnelle.

Adaptez précisément à votre expérience.

Comment présenter Google Cloud ?

Si vous l’utilisez :

Déploiement et exploitation de ressources GCP.

Infrastructure as Code.

CI/CD.

supervision.

gestion des accès selon votre périmètre.

Le nom des services réellement maîtrisés peut être ajouté.

Comment présenter un environnement multi-cloud ?

Évitez :

Expert multi-cloud

si vous avez surtout utilisé un fournisseur.

Préférez :

Expérience principale sur AWS, avec participation à plusieurs projets Azure.

Cela est plus crédible.

Comment présenter Linux ?

Linux reste souvent une compétence centrale.

Vous pouvez écrire :

Administration de systèmes Linux utilisés pour l’hébergement des applications et outils DevOps.

Gestion des services.

analyse des logs.

permissions.

configuration.

scripting.

troubleshooting.

automatisation.

Précisez les distributions si cela est utile.

Comment présenter Bash ?

Vous pouvez écrire :

Scripts Bash pour automatiser les opérations d’exploitation, contrôles de santé et tâches de déploiement.

Ajoutez éventuellement :

réduction d’opérations manuelles ;

génération de rapports ;

intégration dans les pipelines.

Comment présenter Python ?

Pour un ingénieur DevOps :

Scripts Python destinés à l’automatisation d’opérations d’infrastructure et au traitement de données techniques.

Intégration avec APIs.

génération de configurations.

contrôles automatisés.

Ne vous présentez pas comme développeur Python si votre pratique est essentiellement scripting.

Comment présenter PowerShell ?

Dans un environnement Microsoft :

Scripts PowerShell pour automatiser la configuration, la gestion de ressources Azure ou certaines tâches d’administration Windows.

Cela peut être particulièrement pertinent sur Azure DevOps.

Comment présenter Git ?

Évitez :

Git.

Précisez :

Versionnement du code infrastructure et des pipelines sous Git.

Utilisation de branches et pull requests.

revue de changements.

tags ou releases selon le processus de l’équipe.

Git doit apparaître comme un outil de collaboration.

Comment présenter une registry Docker ?

Par exemple :

Publication des images dans une registry privée.

Gestion du versionnement.

intégration aux pipelines.

nettoyage des anciennes versions selon les politiques définies.

Le nom de la plateforme peut être précisé si pertinent.

Comment présenter Nexus ou Artifactory ?

Vous pouvez écrire :

Nexus / Artifactory — stockage et gestion d’artefacts utilisés par les pipelines de build et déploiement.

Si vous administrez réellement le produit :

configuration des repositories ;

droits ;

rétention ;

maintenance.

Comment présenter la supervision ?

Vous pouvez écrire :

Mise en place ou exploitation de la supervision infrastructure et applicative.

Création de dashboards.

définition d’alertes.

analyse des incidents.

amélioration progressive des seuils.

Cela va au-delà de la simple consultation d’un écran.

Comment présenter Prometheus ?

Par exemple :

Prometheus — collecte de métriques sur clusters et applications.

création d’alertes.

intégration avec Grafana.

analyse des incidents de performance ou disponibilité.

Comment présenter Grafana ?

Vous pouvez écrire :

Création de dashboards Grafana pour suivre disponibilité, consommation de ressources et métriques applicatives.

Adaptation des tableaux aux besoins des équipes.

Cela montre votre contribution.

Comment présenter Elastic Stack ?

Si vous l’utilisez réellement :

Centralisation et analyse des logs via Elastic Stack.

Création de recherches et dashboards.

Utilisation des logs lors des incidents.

Le niveau d’administration de la plateforme peut être précisé séparément.

Comment présenter l’observabilité ?

Évitez simplement :

Observability.

Précisez :

Centralisation des métriques et logs.

création de dashboards.

alerting.

corrélation des informations lors des incidents.

accompagnement des équipes sur l’instrumentation.

Cela rend la compétence concrète.

Monitoring ou observabilité : faut-il mettre les deux ?

Vous pouvez utiliser :

Monitoring / observabilité

si votre travail couvre à la fois :

• supervision de l’infrastructure ;
• métriques applicatives ;
• logs ;
• alertes.

Le contenu de l’expérience doit ensuite montrer ce que vous faites réellement.

Comment présenter les incidents de production ?

Vous pouvez écrire :

Participation à la résolution d’incidents de production.

Analyse des métriques et logs.

identification du composant défaillant.

mise en œuvre d’un contournement.

correction durable avec l’équipe concernée.

documentation de l’incident.

Cela montre votre capacité opérationnelle.

Comment présenter un incident critique ?

Par exemple :

Intervention lors d’une indisponibilité d’un service en production.

Analyse des logs et métriques.

identification d’une saturation de ressources.

restauration du service.

ajustement de la configuration.

ajout d’une alerte afin de détecter plus tôt la situation.

Cette structure montre le cycle complet.

Comment présenter un post-mortem ?

Si votre organisation utilise cette pratique :

Participation aux analyses post-incident.

Formalisation de la chronologie.

identification des facteurs techniques.

définition des actions préventives.

suivi jusqu’à mise en œuvre.

Évitez de vous attribuer une responsabilité globale si l’analyse est collective.

Comment présenter l’astreinte ?

Si vous participez réellement :

Participation à une rotation d’astreinte sur les services critiques.

Cela peut être utile pour des postes demandant une responsabilité opérationnelle.

Comment présenter la disponibilité ?

Si elle est mesurée :

Contribution au maintien d’une disponibilité supérieure à 99,9 % sur le périmètre.

ou :

Amélioration de la disponibilité grâce à l’automatisation de certains mécanismes de reprise.

Ne vous attribuez pas seul un résultat collectif.

Comment présenter un SLA ?

Vous pouvez écrire :

Suivi des services soumis à des objectifs de disponibilité.

Analyse des incidents ayant un impact sur les engagements.

contribution aux actions de fiabilisation.

Cela suffit si vous n’êtes pas responsable contractuel du SLA.

Comment présenter la haute disponibilité ?

Vous pouvez écrire :

Contribution à la mise en place d’architectures redondantes.

répartition des workloads.

tests de bascule.

supervision des composants critiques.

Adaptez selon votre niveau réel d’architecture.

Comment présenter le scaling ?

Si votre environnement utilise de l’auto-scaling :

Configuration ou exploitation de mécanismes d’auto-scaling adaptés à la charge.

analyse des ressources.

ajustement des seuils.

suivi de l’impact sur performance et coût.

Cela peut être intéressant sur le cloud ou Kubernetes.

Comment présenter les performances ?

Vous pouvez écrire :

Analyse de la consommation CPU, mémoire et I/O.

identification des goulots d’étranglement.

adaptation des ressources.

collaboration avec les développeurs sur les optimisations applicatives.

Cela montre une approche transverse.

Comment présenter la sécurité ?

DevOps ne signifie pas automatiquement DevSecOps.

Si votre rôle couvre la sécurité :

Intégration de contrôles de sécurité dans les pipelines.

gestion des secrets.

mise à jour des images.

application des standards de configuration.

correction de vulnérabilités d’infrastructure.

Restez fidèle à votre périmètre.

Comment présenter DevSecOps ?

Si vous avez réellement travaillé dans cette approche :

Intégration de contrôles automatisés dans la chaîne CI/CD.

scans des dépendances ou images selon les outils utilisés.

traitement des vulnérabilités avec les équipes.

sécurisation de la gestion des secrets.

Ne vous présentez pas comme expert cybersécurité si votre activité principale reste DevOps.

Comment présenter Vault ?

Vous pouvez écrire :

Vault — gestion centralisée de secrets utilisés par les applications ou pipelines.

intégration aux environnements de déploiement.

limitation des secrets stockés directement dans les repositories.

Précisez votre niveau si vous administrez la plateforme elle-même.

Comment présenter les secrets dans Kubernetes ?

Par exemple :

Gestion des secrets via les mécanismes et outils définis par la plateforme.

limitation de leur exposition dans les configurations.

intégration avec un gestionnaire de secrets externe lorsque prévu.

Évitez les affirmations absolues sur la sécurité sans contexte.

Comment présenter IAM ?

Si votre rôle intervient sur les permissions cloud :

Gestion ou contribution à la définition des rôles et permissions nécessaires aux workloads.

application du principe de moindre privilège selon les standards internes.

Ne revendiquez pas une responsabilité complète sur l’IAM si elle appartient à l’équipe sécurité ou cloud.

Comment présenter les scans d’images ?

Vous pouvez écrire :

Intégration d’un scan automatique des images de conteneurs avant déploiement.

traitement des vulnérabilités identifiées avec les équipes de développement.

Ajoutez l’outil si pertinent.

Comment présenter la gestion des patches ?

Par exemple :

Mise à jour régulière des images de base et composants d’infrastructure.

planification des changements.

validation avant production.

suivi des vulnérabilités corrigées.

Cela montre une pratique de maintenance continue.

Comment présenter la sauvegarde ?

Si votre périmètre la couvre :

Automatisation et supervision des sauvegardes des composants concernés.

tests de restauration.

documentation des procédures.

intégration aux plans de reprise.

N’ajoutez cette compétence que si vous intervenez réellement dessus.

Comment présenter un PRA ?

Vous pouvez écrire :

Participation aux exercices de reprise.

automatisation de certaines étapes de reconstruction de l’environnement.

validation des procédures.

analyse des écarts après test.

Cela peut être très pertinent pour un profil infrastructure.

Comment présenter la documentation ?

Un bon ingénieur DevOps doit souvent documenter :

• architecture ;
• pipelines ;
• procédures ;
• runbooks ;
• incidents ;
• mécanismes de déploiement.

Vous pouvez écrire :

Rédaction de runbooks d’exploitation.

documentation des pipelines.

création de procédures de reprise et troubleshooting.

mise à jour des schémas d’architecture.

Cela montre votre capacité à rendre l’environnement maintenable.

Comment présenter un runbook ?

Par exemple :

Création de runbooks pour les incidents récurrents et opérations de maintenance.

description des contrôles à effectuer.

commandes nécessaires.

critères d’escalade.

Cela peut contribuer à réduire le temps de résolution.

Comment présenter le travail avec les développeurs ?

DevOps ne doit pas apparaître comme une équipe isolée.

Vous pouvez écrire :

Accompagnement des développeurs dans la mise en place des pipelines.

standardisation de la conteneurisation.

aide au diagnostic des problèmes de déploiement.

définition de bonnes pratiques communes.

Cela montre l’aspect collaboration.

Comment présenter le support aux équipes de développement ?

Par exemple :

Support DevOps auprès de 8 squads.

création de templates CI/CD.

accompagnement sur Docker et Kubernetes.

résolution des incidents de pipeline.

documentation en self-service.

C’est particulièrement intéressant pour une plateforme interne.

Comment présenter le self-service ?

Dans une approche plateforme :

Mise à disposition de templates et modules permettant aux équipes de déployer de nouveaux services de façon standardisée.

réduction des demandes manuelles adressées à l’équipe infrastructure.

Cela peut montrer un niveau plus mature.

Comment présenter un Internal Developer Platform ?

Si vous travaillez réellement sur ce type de plateforme :

Contribution à une plateforme interne permettant aux développeurs de provisionner et déployer leurs applications selon des standards communs.

Décrivez ensuite :

• templates ;
• pipelines ;
• IaC ;
• observabilité ;
• accès.

N’utilisez pas le terme uniquement parce qu’il est tendance.

DevOps ou Platform Engineer : comment se positionner ?

Un Platform Engineer peut être davantage centré sur la construction d’une plateforme interne et l’expérience développeur.

Un DevOps Engineer peut avoir un périmètre plus large mêlant :

• CI/CD ;
• infrastructure ;
• cloud ;
• exploitation ;
• automatisation.

Les intitulés varient selon les entreprises.

Sur votre CV, gardez votre véritable titre et décrivez votre périmètre.

DevOps ou SRE : quelle différence sur le CV ?

Un poste SRE peut mettre davantage l’accent sur :

• fiabilité ;
• disponibilité ;
• SLI/SLO ;
• incidents ;
• automatisation ;
• capacité ;
• observabilité.

Si votre travail ne couvre pas réellement ces responsabilités, ne remplacez pas artificiellement « DevOps » par « SRE ».

Comment présenter les SLI et SLO ?

Si votre organisation les utilise réellement :

Contribution à la définition ou au suivi de SLI/SLO sur certains services.

création des métriques nécessaires.

dashboards.

alertes.

analyse des écarts.

Cela peut être pertinent sur un profil SRE ou DevOps senior.

Comment présenter le FinOps ?

Si vous travaillez sur l’optimisation des coûts :

Analyse de la consommation cloud.

identification des ressources surdimensionnées ou inutilisées.

mise en place d’actions d’optimisation.

suivi des économies.

Ne vous présentez pas comme spécialiste FinOps pour une simple suppression ponctuelle de ressources.

Comment quantifier l’optimisation cloud ?

Par exemple :

Réduction de 18 % des coûts cloud du périmètre via rightsizing et arrêt automatique de certains environnements hors utilisation.

ou :

Mise en place d’un reporting de coût par environnement permettant d’identifier plusieurs ressources inutilisées.

Cela montre un impact business.

Comment présenter la création d’environnements éphémères ?

Si vous avez cette pratique :

Automatisation de la création d’environnements temporaires pour les branches ou pull requests.

destruction automatique après utilisation.

amélioration de la capacité de test des équipes.

Cela peut être très différenciant.

Comment présenter plusieurs environnements ?

Vous pouvez écrire :

Gestion de configurations distinctes pour développement, intégration, recette et production.

standardisation via templates et IaC.

limitation des divergences entre environnements.

Cela montre votre maîtrise du cycle de delivery.

Comment présenter la gestion de configuration ?

Vous pouvez écrire :

Centralisation des paramètres par environnement.

séparation du code et de la configuration.

versionnement lorsque pertinent.

gestion sécurisée des secrets.

Cela montre une pratique saine sans entrer dans des détails trop techniques.

Comment présenter Nginx ?

Si vous l’administrez :

Nginx — reverse proxy, routage et configuration de services web.

diagnostic des erreurs de configuration.

gestion des certificats selon le périmètre.

Cela peut être utile pour des environnements web.

Comment présenter les certificats TLS ?

Vous pouvez écrire :

Suivi et renouvellement des certificats utilisés par les services.

automatisation de certaines opérations lorsque possible.

contrôle après déploiement.

Cela peut être pertinent en infrastructure.

Comment présenter les bases de données ?

Un ingénieur DevOps peut les exploiter sans être DBA.

Vous pouvez écrire :

Support d’infrastructure autour de bases PostgreSQL ou MySQL.

sauvegardes.

supervision.

déploiement.

coordination avec les spécialistes bases de données.

Évitez de revendiquer une expertise DBA si ce n’est pas votre rôle.

Comment présenter la migration vers le cloud ?

Par exemple :

Participation à la migration d’applications depuis des VM on-premise vers AWS.

conteneurisation.

création de l’infrastructure Terraform.

mise en place des pipelines.

accompagnement de la bascule.

Cela montre un projet de bout en bout.

Comment présenter une migration vers Kubernetes ?

Vous pouvez écrire :

Conteneurisation de plusieurs applications précédemment déployées sur VM.

création des manifests ou charts Helm.

adaptation des pipelines.

mise en place du monitoring.

accompagnement des développeurs.

migration progressive vers Kubernetes.

Quantifiez si possible le nombre d’applications.

Comment présenter une migration Jenkins vers GitLab CI ?

Par exemple :

Migration de 40 pipelines Jenkins vers GitLab CI.

création de templates communs.

simplification de la maintenance.

suppression de plusieurs jobs redondants.

documentation pour les équipes.

Cela constitue une réalisation forte.

Comment présenter la standardisation ?

Vous pouvez écrire :

Création de templates CI/CD communs à plusieurs applications.

modules Terraform partagés.

images Docker standardisées.

réduction des différences entre équipes.

Cela montre une capacité à industrialiser.

Comment présenter une réduction du temps de déploiement ?

Par exemple :

Automatisation du pipeline de déploiement réduisant une mise en production de 60 à 15 minutes.

ou :

Suppression de plusieurs étapes manuelles et fiabilisation du rollback.

Ce type de résultat est particulièrement pertinent en DevOps.

Comment présenter une baisse des erreurs de déploiement ?

Vous pouvez écrire :

Standardisation des pipelines et automatisation des contrôles avant production.

réduction du nombre d’incidents liés aux déploiements sur le périmètre.

Si vous disposez d’une mesure :

–35 % d’incidents de déploiement en 12 mois.

Restez prudent sur l’attribution.

Comment présenter le rollback ?

Si vous travaillez sur les stratégies de retour arrière :

Mise en place de mécanismes de rollback automatisés ou documentés pour réduire le risque lors des releases.

Cela montre une bonne prise en compte de la fiabilité.

Comment présenter blue-green ou canary ?

Si vous avez réellement utilisé ces stratégies :

Mise en place de déploiements progressifs afin de limiter le risque des nouvelles versions.

Précisez :

blue-green ;

canary ;

selon votre cas.

Ne les ajoutez pas simplement comme mots-clés.

Comment présenter l’automatisation ?

Évitez :

Automatisation.

Précisez ce qui a été automatisé :

provisioning d’environnements ;

déploiements ;

contrôles ;

sauvegardes ;

création de comptes ;

monitoring ;

reporting ;

cleanup de ressources.

Puis ajoutez le gain.

Quels résultats chiffrés mettre sur un CV DevOps ?

Vous pouvez notamment mesurer :

• temps de déploiement ;
• fréquence de déploiement ;
• nombre de pipelines ;
• nombre d’applications ;
• taux d’automatisation ;
• disponibilité ;
• incidents ;
• MTTR si réellement suivi ;
• coût cloud ;
• temps économisé ;
• temps de provisioning.

Exemples :

Provisionnement d’un nouvel environnement passé de 2 jours à 30 minutes.

60 pipelines standardisés.

Déploiement automatisé de 35 microservices.

Réduction de 40 % du temps moyen de restauration sur le périmètre.

Coûts cloud réduits de 15 %.

Ces chiffres rendent votre impact immédiatement visible.

Comment présenter le MTTR ?

Si votre organisation le mesure réellement :

Contribution à une réduction du MTTR grâce à l’amélioration des alertes, dashboards et procédures de diagnostic.

N’utilisez pas cet indicateur uniquement parce qu’il est associé au SRE.

Comment présenter le lead time ?

Si votre équipe suit cette métrique :

Réduction du délai entre validation du code et mise en production grâce à l’automatisation du pipeline.

Vous pouvez donner le chiffre avant/après si fiable.

Comment présenter la fréquence de déploiement ?

Par exemple :

Passage d’un déploiement hebdomadaire à plusieurs releases par semaine grâce à l’automatisation des pipelines.

Cela montre un effet direct sur la capacité de livraison.

Comment faire un CV d’ingénieur DevOps junior ?

Pour un profil junior, développez davantage :

• alternance ;
• stage ;
• projets techniques ;
• Linux ;
• Docker ;
• Git ;
• CI/CD ;
• Terraform ;
• cloud.

Par exemple :

Ingénieur DevOps en alternance – Entreprise X

Maintenance de pipelines GitLab CI

Création d’images Docker

Déploiement d’applications sur Kubernetes

Scripts Bash

Provisionnement de ressources via Terraform

Création de dashboards Grafana

Participation au traitement d’incidents

Cela constitue déjà une base solide.

Comment faire un CV DevOps sans expérience professionnelle ?

Un projet personnel peut avoir de la valeur s’il est concret et présenté comme tel.

Par exemple :

Projet personnel – plateforme Kubernetes

Déploiement d’un cluster de test

Conteneurisation d’une application

Pipeline CI/CD

Terraform

Helm

Prometheus / Grafana

documentation du projet

Évitez de présenter un lab personnel comme une infrastructure de production.

Comment passer d’administrateur systèmes à DevOps ?

Mettez en avant les compétences transférables :

• Linux ;
• scripting ;
• infrastructure ;
• supervision ;
• incidents ;
• cloud.

Puis montrez votre progression sur :

• Git ;
• CI/CD ;
• Docker ;
• IaC ;
• Kubernetes ;
• automatisation.

Votre parcours peut être très cohérent.

Comment passer de développeur à DevOps ?

Vous pouvez valoriser :

• Git ;
• pipelines ;
• automatisation ;
• compréhension du cycle de build ;
• debugging ;
• code.

Puis démontrez les nouvelles compétences :

• cloud ;
• infrastructure ;
• Docker ;
• Kubernetes ;
• Terraform ;
• monitoring.

Évitez de minimiser votre expérience développeur : elle peut être un avantage.

Comment faire un CV d’ingénieur DevOps expérimenté ?

Un profil senior doit davantage montrer :

• architecture ;
• standardisation ;
• autonomie ;
• incidents critiques ;
• plateforme ;
• mentoring ;
• coûts ;
• fiabilité ;
• choix techniques.

Par exemple :

Référent Kubernetes pour une plateforme hébergeant 70 services.

Définition des standards CI/CD.

Conception de modules Terraform communs.

accompagnement de 10 équipes.

revue des changements sensibles.

Cela montre un niveau plus élevé.

Comment montrer un rôle de référent DevOps ?

Vous pouvez écrire :

Référent DevOps auprès de plusieurs équipes de développement.

revue des pipelines.

accompagnement sur les choix de déploiement.

standardisation des pratiques.

support sur les incidents complexes.

mentorat de profils juniors.

Cela valorise la séniorité sans inventer un management hiérarchique.

Comment présenter du management ?

Si vous encadrez réellement :

Management de 4 ingénieurs DevOps.

répartition des sujets.

suivi des priorités.

accompagnement technique.

entretiens individuels.

recrutement.

Distinguez bien management et lead technique.

Quelle formation mettre sur un CV d’ingénieur DevOps ?

Les parcours peuvent notamment inclure :

• école d’ingénieurs informatique ;
• master systèmes et réseaux ;
• cloud ;
• cybersécurité ;
• développement logiciel ;
• infrastructure.

Présentez :

diplôme – spécialité – établissement – année

Pour un profil expérimenté, la stack récente et les réalisations prennent généralement davantage de poids.

Faut-il mettre les certifications AWS, Azure ou Kubernetes ?

Oui si vous les avez réellement obtenues et qu’elles sont pertinentes.

Indiquez leur intitulé exact.

Elles peuvent renforcer un profil, mais elles ne remplacent pas une expérience réelle de production.

Un recruteur cherchera surtout à comprendre :

• ce que vous avez déployé ;
• ce que vous administrez ;
• votre niveau d’autonomie.

Faut-il mettre toutes ses certifications ?

Non.

Sélectionnez celles qui sont :

• pertinentes pour le poste ;
• suffisamment récentes ;
• cohérentes avec votre expérience.

Évitez de noyer les informations importantes dans une longue liste.

Un CV d’ingénieur DevOps doit-il être compatible avec les ATS ?

Les recruteurs peuvent rechercher les candidats selon des technologies très précises.

Votre CV doit donc rendre clairement visibles :

• ingénieur DevOps ;
• DevOps Engineer ;
• CI/CD ;
• Docker ;
• Kubernetes ;
• Terraform ;
• Ansible ;
• AWS / Azure / GCP ;
• Linux ;
• Git ;
• Jenkins / GitLab CI / GitHub Actions ;
• Prometheus ;
• Grafana ;
• Infrastructure as Code.

Par exemple :

Ingénieur DevOps – AWS / Kubernetes / Terraform / GitLab CI

est beaucoup plus précis que :

Ingénieur Cloud & Automation

si l’offre recherche explicitement un DevOps.

L’objectif n’est pas d’accumuler artificiellement des technologies, mais de rendre votre stack et votre expérience immédiatement identifiables.

Faut-il adapter son CV à chaque offre ?

Oui.

Une offre peut être davantage orientée :

• AWS ;
• Azure ;
• Kubernetes ;
• Terraform ;
• CI/CD ;
• plateforme ;
• SRE ;
• DevSecOps ;
• Linux.

Vous pouvez donc adapter :

• le titre ;
• l’accroche ;
• la stack mise en avant ;
• les projets détaillés ;
• les certifications.

Sans inventer une technologie.

Exemple de structure pour un CV d’ingénieur DevOps

1. Coordonnées

Nom, téléphone, e-mail, localisation, LinkedIn et GitHub si pertinent.

2. Titre

Ingénieur DevOps – AWS / Kubernetes / Terraform

3. Accroche

Quelques lignes présentant votre expérience, votre environnement et votre spécialisation.

4. Stack technique

Cloud AWS

Containers Docker · Kubernetes · Helm

Infrastructure as Code Terraform · Ansible

CI/CD GitLab CI · Jenkins

Observabilité Prometheus · Grafana

Scripting Bash · Python

Uniquement les outils réellement utilisés.

5. Chiffres clés

Par exemple :

60 pipelines

35 microservices

4 clusters

10 équipes accompagnées

6. Expériences professionnelles

Pour chaque poste :

• entreprise ;
• dates ;
• architecture ;
• stack ;
• responsabilités ;
• automatisations ;
• incidents ;
• résultats.

7. Formation

Diplôme informatique ou infrastructure.

8. Certifications

Uniquement celles réellement obtenues.

Exemple d’expérience à mettre sur un CV

Ingénieur DevOps – Entreprise X 2022 – aujourd’hui

• Exploitation d’une plateforme Kubernetes hébergeant plus de 30 services
• Création et maintenance d’environ 60 pipelines GitLab CI
• Automatisation du provisionnement cloud via Terraform
• Création de modules Terraform réutilisables
• Conteneurisation d’applications sous Docker
• Déploiement Kubernetes via Helm
• Mise en place de dashboards Prometheus / Grafana
• Centralisation et analyse des logs
• Scripting Bash et Python pour automatiser des opérations récurrentes
• Participation au traitement des incidents de production
• Création de runbooks et documentation technique
• Accompagnement de plusieurs équipes de développement sur les pratiques CI/CD
• Réduction du temps moyen de déploiement de 40 à 12 minutes
• Provisionnement d’un nouvel environnement réduit de plusieurs heures à moins de 30 minutes
• Standardisation des pipelines sur plusieurs équipes
• Contribution à la réduction des incidents liés aux déploiements

Exemple fictif à adapter à votre parcours. Les chiffres doivent correspondre à vos réalisations réelles.

Cette présentation permet de comprendre immédiatement la stack, l’échelle, votre niveau d’autonomie et l’impact de votre travail.

Les erreurs à éviter sur un CV d’ingénieur DevOps

Faire une liste interminable de technologies

Montrez surtout celles utilisées en production.

Mettre Kubernetes sans expliquer votre niveau

Déployer une application et administrer une plateforme ne sont pas la même chose.

Se présenter comme expert multi-cloud avec une expérience limitée

Précisez votre cloud principal.

Ne donner aucun résultat

Le DevOps se prête très bien aux gains de temps, automatisation et fiabilité.

Oublier Linux

Il reste central dans de nombreux environnements.

Se déclarer DevSecOps sans responsabilité sécurité réelle

Expliquez les contrôles effectivement intégrés.

Se déclarer SRE sans travailler sur la fiabilité

Gardez un titre cohérent.

Lister Terraform sans montrer ce qui est provisionné

Infrastructure as Code doit être démontrée.

Oublier les équipes de développement

Le DevOps comporte aussi une dimension de collaboration et d’industrialisation.

Ingénieur DevOps : ce que montrent les données récentes

Le métier Ingénieur / Ingénieure DevOps – code ROME M1827 arrive en 100e position du classement CVReader croisant le volume de profils candidats récents avec celui des offres France Travail.

Sur les périodes étudiées :

• 82 profils candidats correspondant au métier apparaissent parmi les CV récents analysés par CVReader ;
• 151 offres France Travail correspondant au code ROME M1827 ont été observées sur la période retenue ;
• le métier se classe 49e côté candidats dans notre échantillon récent.

Méthodologie

Les statistiques rapprochent :

• les CV analysés par CVReader au cours des 3 derniers mois ;
• les offres France Travail des 30 derniers jours.

Ces périodes correspondent respectivement à un vivier récent de candidats et à la demande actuelle publiée par les employeurs.

Les volumes ne représentent pas l’ensemble du marché français et ne doivent pas être interprétés comme un ratio direct entre candidats et postes disponibles.

Questions fréquentes sur le CV d’ingénieur DevOps

Quelles compétences mettre sur un CV d’ingénieur DevOps ?

Mettez en priorité votre cloud principal, Linux, CI/CD, Docker, Kubernetes, Infrastructure as Code, scripting et observabilité selon votre expérience réelle.

Faut-il mettre toutes les technologies DevOps que l’on connaît ?

Non. Concentrez-vous sur celles utilisées réellement, idéalement en production, et contextualisez-les dans vos expériences.

Comment rédiger une accroche DevOps ?

Précisez vos années d’expérience, votre cloud ou environnement principal, votre stack et deux ou trois responsabilités importantes comme Kubernetes, Terraform ou CI/CD.

Quels chiffres mettre sur un CV DevOps ?

Le nombre de pipelines, applications, clusters ou équipes accompagnées, ainsi que les gains de temps de déploiement, provisioning ou résolution d’incidents peuvent être particulièrement utiles.

Faut-il mettre Kubernetes ?

Oui si vous l’utilisez réellement. Précisez si vous déployez des applications ou si vous administrez aussi la plateforme.

Faut-il mettre Terraform ?

Oui si vous l’utilisez pour provisionner ou maintenir de l’infrastructure. Décrivez idéalement ce que vous automatisez.

Quelle différence entre DevOps et SRE ?

Les deux métiers peuvent se recouper, mais un poste SRE est souvent davantage centré sur la fiabilité, les objectifs de service, les incidents et l’automatisation opérationnelle. Les périmètres varient selon les entreprises.

Comment passer d’administrateur systèmes à DevOps ?

Valorisez votre expérience Linux, infrastructure et scripting, puis montrez vos compétences nouvelles en Git, CI/CD, Docker, Terraform, cloud et Kubernetes.