Day in the Life of a DevOps Engineer

Votre alarme sonne à 7 h 40 et la première chose que vous faites, c'est regarder votre téléphone pour voir si une alerte a pété pendant la nuit. C'est là que commence la journée d'un ingénieur DevOps de niveau intermédiaire, pas dans une salle de sport lumineuse avec un café parfait.

Je vais décrire une journée réaliste, avec les réunions, le travail de fond, les outils que vous ouvrez vraiment, et les moments où ça tire. Sans broderie.

Le réveil et la première vérification#

Avant même le petit déjeuner, vous ouvrez Slack ou Teams. Vous cherchez les notifications du canal d'alertes, les messages de l'équipe de garde, et les incidents ouverts dans Jira ou dans votre outil de ticketing. Cinq minutes suffisent pour savoir si la matinée sera calme ou pas.

Si tout est vert, vous arrivez au bureau ou vous vous connectez à 9 h. Sinon, vous commencez avant l'heure officielle. C'est un point que les gens découvrent en arrivant dans le métier : la frontière entre "pas encore au travail" et "au travail" est floue.

9 h à 10 h : le stand-up et le tri#

Le stand-up dure quinze minutes en théorie. En pratique, vingt-cinq quand un incident est en cours. Chacun dit ce qu'il fait, ce qui bloque, et ce qui a cassé la veille.

Juste après, vous faites le tri. Les emails, les pull requests en attente d'avis, les alertes de monitoring qui ne sont pas des urgences mais qu'il faut traiter. Vous videz la petite équipe de tâches avant de vous attaquer au gros morceau.

10 h à 12 h 30 : la vraie fenêtre de travail de fond#

C'est le créneau le plus précieux de la journée. Deux heures et demie sans réunion, où vous pouvez enfin avancer sur un sujet qui demande de la concentration.

Concrètement, un ingénieur DevOps de niveau intermédiaire passe ce temps sur des choses comme :

• Écrire ou modifier un pipeline CI/CD dans GitLab CI, GitHub Actions ou Jenkins
• Corriger un playbook Ansible ou un module Terraform qui ne se comporte pas comme prévu
• Mettre en place un tableau de bord Grafana pour une équipe applicative qui ne voit rien sur ses erreurs
• Automatiser une tâche manuelle que personne n'a eu le temps de traiter, comme le nettoyage d'images Docker dans le registre
• Rédiger de la documentation sur un processus que tout le monde fait à la main
• Passer une revue de code sur un dépôt d'infrastructure

Le mot clé ici est "sans interruption". Si vous avez des notifications Slack ouvertes sur le deuxième écran, cette fenêtre ne sert à rien. Les DevOps expérimentés coupent les notifications pendant ce créneau. Les débutants ne le font pas, et se demandent pourquoi ils n'avancent jamais.

12 h 30 à 13 h 30 : la pause, en théorie#

La pause déjeuner existe. Mais les jours d'incident ou de mise en production, elle est souvent avalée debout devant l'écran. Si vous êtes en télétravail, la tentation de "juste finir ce script" est forte. Résistez : l'après-midi sera plus long que prévu, en général.

13 h 30 à 14 h 30 : les réunions qui pèsent#

C'est le moment où se concentrent les réunions qui n'ont pas de lien direct avec le code. Point projet migration cloud avec l'architecte. Point sécurité avec la RSSI ou son adjoint. Revue de l'incident de la semaine dernière avec l'équipe applicative.

Trois réunions d'une heure dans la même journée, c'est trop. Deux, c'est gérable. Un ingénieur DevOps intermédiaire commence à dire non à certaines réunions, ou à envoyer quelqu'un d'autre. C'est un vrai changement par rapport au niveau junior, où l'on accepte tout par peur de manquer quelque chose.

14 h 30 à 16 h 30 : le deuxième bloc de travail, souvent fragmenté#

L'après-midi ressemble rarement au matin. Les messages arrivent, une équipe applicative a un problème de déploiement, un job de build casse pour une raison obscure. Vous jonglez.

Vous allez dans Grafana ou Datadog pour voir les métriques. Vous ouvrez kubectl pour regarder les pods Kubernetes. Vous fouillez les logs dans Loki, ELK ou CloudWatch. Vous vérifiez l'état des runners CI. Vous parlez cinq minutes à un développeur pour comprendre ce qu'il a changé.

Ce morcellement est la réalité du poste. Les gens qui viennent du développement pur sont souvent surpris : ils imaginaient écrire des scripts toute la journée. En fait, vous passez une bonne partie du temps à comprendre pourquoi quelque chose ne marche pas chez quelqu'un d'autre.

16 h 30 à 17 h 30 : la mise en production et la documentation#

C'est souvent le créneau choisi pour déployer, quand les équipes applicatives sont encore là pour réagir. Vous lancez le pipeline, vous surveillez, vous validez. Si ça casse, vous revenez en arrière.

Juste après, vous notez ce que vous avez fait. C'est ennuyeux et c'est ce qui vous sauvera dans six mois. Une fiche d'incident bien écrite, un README à jour, un commentaire dans le code Terraform qui explique pourquoi cette valeur est là.

Ce qui surprend les nouveaux arrivants#

Trois choses reviennent souvent.

La part des réunions. On entre dans ce métier en pensant qu'il est très technique, et c'est vrai, mais la coordination entre équipes prend du temps. À mesure qu'on monte en expérience, cette part augmente plutôt qu'elle ne diminue.

La quantité de connaissances contextuelles. Savoir utiliser Terraform ne suffit pas. Il faut savoir pourquoi cette équipe utilise AWS et pas GCP, quelles sont les contraintes de conformité, qui valide quoi, quel historique a mené à cette architecture parfois bancale.

La pression quand ça casse. Un incident de production à 16 h un vendredi, avec des clients impactés, ça se sent physiquement. Le cœur accélère, les mains sont froides. Les gens qui restent dans le métier apprennent à gérer ça. Les autres partent vers des postes plus calmes, et ce n'est pas un échec.

Comment le poste change entre junior et intermédiaire#

Un junior exécute des tickets. On lui dit "ajoute cette étape dans le pipeline", il le fait. Un intermédiaire commence à poser la question : "pourquoi cette étape existe, est-elle encore nécessaire, peut-on la supprimer ?"

L'intermédiaire conçoit des solutions simples pour des problèmes récurrents. Il automatise ce qu'il a fait trois fois à la main. Il dit non aux demandes qui créent de la dette technique sans apporter de valeur.

Il commence aussi à former. Un junior arrive dans l'équipe, c'est l'intermédiaire qui lui montre où sont les choses, comment lire les alertes, à qui parler pour les accès. C'est un bon test pour vérifier qu'on maîtrise vraiment un sujet.

Le salaire suit cette progression, mais il varie beaucoup selon le pays, la taille de l'entreprise et le niveau de responsabilité. En France, un poste DevOps intermédiaire se situe souvent dans une fourchette large, autour de 40 000 à 55 000 euros bruts annuels, parfois plus dans les grandes villes ou les secteurs réglementés. Vérifiez les chiffres actuels auprès des sources officielles et des offres en cours, les grilles bougent.

Une journée ne ressemble jamais à la précédente#

C'est la chose à accepter. Lundi peut être calme, avec du travail de fond et deux réunions. Mardi peut être un mur d'incidents dès 9 h. Vendredi peut être silencieux, ou au contraire le jour où tout se casse parce que quelqu'un a déployé à 16 h.

Ce qui reste constant : vous passez votre temps entre des machines et des gens, et votre valeur vient de votre capacité à faire le lien entre les deux.

Checklist pour préparer votre propre journée#

• Lire les alertes et messages d'incident avant de commencer
• Bloquer deux heures de travail de fond sans notifications
• Lister les trois tâches importantes du jour avant de répondre aux messages
• Garder un journal court de ce que vous faites, même trois lignes
• Prévoir une marge pour l'imprévu, il y en a toujours un
• Noter les questions sans réponse pour ne pas les perdre

Exemple concret de ce que vous pourriez écrire dans votre journal : "Refonte du job de build GitLab CI : ajout d'un cache pour les dépendances npm, temps de build passé de 11 à 4 minutes. Reste à documenter pour l'équipe mobile." Une phrase comme celle-ci, c'est déjà de la matière pour votre prochain entretien ou votre prochaine revue de performance.

Outils gratuits#

• jobrise.io/fr/free-ats-checker/
• jobrise.io/fr/free-jd-decoder/
• jobrise.io/fr/jobs/
• jobrise.io/fr/blog/

Questions fréquentes#

Combien de temps passe-t-on en réunions par jour ?

En pratique, entre une et trois heures pour un niveau intermédiaire, plus si vous coordonnez plusieurs équipes. C'est beaucoup plus que ce que la plupart des gens imaginent avant d'entrer dans le métier.

Quels sont les outils utilisés tous les jours ?

Git, un pipeline CI/CD, Terraform ou un équivalent, Kubernetes ou une plateforme de conteneurs, un outil de monitoring comme Grafana ou Datadog, et un gestionnaire de tickets. Les noms exacts changent selon l'entreprise, les concepts restent.

Le poste est-il très stressant ?

Il l'est quand quelque chose casse en production, surtout si des clients sont impactés. Entre les incidents, c'est un travail calme et méthodique. Si vous ne supportez pas les pics de pression ponctuels, ce métier vous coûtera cher.

Peut-on faire ce métier en télétravail ?

Oui, beaucoup d'équipes DevOps fonctionnent à distance ou en hybride. La contrepartie, c'est que la frontière avec la vie personnelle devient floue, surtout quand vous êtes de garde ou que vous travaillez avec d'autres fuseaux horaires.

Faut-il être développeur avant de devenir DevOps ?

Ce n'est pas obligatoire, mais savoir lire et écrire du code aide beaucoup. Les pipelines, les scripts d'automatisation et l'infrastructure décrite en code demandent une aisance avec les langages de programmation courants.