Day in the Life of a Cloud Engineer

Le cloud engineer passe plus de temps à débrouiller des blocages qu'à écrire de l'infrastructure neuve. C'est la première surprise pour la plupart des gens qui découvrent le métier. Avant de vous projeter, vérifiez les offres en cours sur notre recherche d'emplois cloud pour voir ce que les entreprises demandent réellement.

Voici une journée réaliste, pas un dépliant RH. Les horaires varient selon l'entreprise, la taille de l'équipe et le fuseau des clients. Mais la structure générale ressemble à ça.

Le matin : trier avant de créer#

8h30. Le café en main, la première chose n'est pas de coder. C'est de regarder ce qui a pété pendant la nuit. Alertes dans l'outil de monitoring, tickets ouverts par le support, messages dans le canal Slack des astreintes.

On passe rarement plus de 30 minutes là-dessus quand tout va bien. Quand une alerte est légitime, la matinée y passe. Un nœud Kubernetes qui tourne en boucle, un job de sauvegarde qui a échoué, une facture cloud qui a grimpé sans raison claire.

9h30. Le daily de l'équipe. Quinze minutes, debout, ou assis devant une caméra si l'équipe est distribuée. On dit ce qu'on a fait, ce qu'on prévoit, ce qui bloque. C'est court, ou ça devrait l'être.

Après le daily vient le seul vrai bloc de travail de fond de la journée. Pour la plupart des cloud engineers, c'est entre 10h et 12h. C'est là qu'on écrit du Terraform, qu'on corrige un pipeline, qu'on documente une architecture.

Si vous avez deux réunions dans ce créneau, vous n'aurez rien fait de sérieux avant 14h. C'est un vrai problème dans beaucoup d'entreprises.

Les outils qu'on utilise vraiment#

Les offres d'emploi listent quinze technologies. Sur une journée normale, vous en touchez cinq ou six.

Un fournisseur cloud, AWS, Azure ou GCP selon l'entreprise. Terraform ou équivalent pour l'infrastructure décrite en code. Git, avec GitHub, GitLab ou Bitbucket. Un conteneur, souvent Docker et Kubernetes. Un outil de monitoring, Datadog, Prometheus, Grafana, CloudWatch. Un gestionnaire de tickets, Jira ou Linear. Et Slack, beaucoup de Slack.

Le reste arrive par épisode. Un peu de Python ou Bash pour automatiser. Un outil de sécurité quand l'équipe conformité demande quelque chose. Un tableur quand on essaie de comprendre la facture.

Un exemple concret de tâche

Prenons une demande qui arrive souvent : une équipe veut déployer une nouvelle application sur le cluster Kubernetes existant. Voici ce que le ticket contient réellement, et ce que vous devez produire.

Le ticket : « Il faut un namespace, des quotas CPU et mémoire, un ingress TLS, et que les secrets soient gérés dans le coffre existant. »

Votre livrable, après une heure ou deux : un module Terraform réutilisable, un fichier de valeurs Helm, une règle d'ingress, un accès en écriture sur le coffre de secrets limité au namespace, et deux lignes de documentation. Pas un schéma d'architecture de dix pages. Juste ça, testé sur un environnement de dev avant la prod.

L'après-midi : réunions et dépendances#

13h30. Retour au clavier, mais rarement pour longtemps. L'après-midi est souvent mangé par les autres.

Revue d'architecture avec une équipe produit. Réunion sécurité pour valider un accès. Point avec le fournisseur cloud sur un incident ouvert. Entretien technique si vous recrutez. Mise à jour du runbook avec un collègue.

La part exacte varie beaucoup. Dans une petite équipe, disons cinq personnes, vous pouvez viser 60% de travail technique et 40% de coordination. Dans une grande organisation, l'inverse est fréquent. Certains cloud engineers seniors passent trois heures par jour en réunion.

Un point qui surprend les nouveaux venus : vous passez beaucoup de temps à obtenir des accès. Demander, relancer, faire valider, attendre. C'est pénible. C'est aussi une réalité du travail en entreprise, surtout dans les secteurs régulés.

Les points de pression#

Le cloud engineer n'est pas dans un bureau calme à faire de la magie noire. Il y a de la pression, et elle vient de trois endroits.

La première, c'est la production. Quand un service tombe, vous êtes réveillé ou appelé. Les astreintes sont réelles dans ce métier. Si une offre ne mentionne pas l'astreinte, demandez.

La deuxième, c'est le coût. Le cloud coûte cher, et la direction regarde la facture. Vous serez celui qu'on interroge quand les dépenses montent.

La troisième, c'est la sécurité. Une mauvaise politique IAM, un bucket mal configuré, et c'est votre nom qui revient. La responsabilité pèse, surtout au-dessus du niveau junior.

Ce qui change entre junior et senior#

Un cloud engineer junior exécute des tickets. On lui dit quoi créer, il le crée, il demande de l'aide quand ça bloque. Il passe beaucoup de temps à lire de la doc et à comprendre ce qui existe déjà.

Un cloud engineer senior conçoit, arbitre, et dit non. Il passe moins de temps à écrire du code, plus de temps à expliquer un choix, à négocier un délai, à empêcher une équipe de faire une bêtise coûteuse. Il anticipe ce qui cassera dans six mois.

Le salaire suit cette différence, mais les fourchettes varient énormément selon le pays, la taille d'entreprise et le niveau réel du poste. En France, les ordres de grandeur souvent rapportés vont de 38 000 à 55 000 euros brut annuel pour un profil confirmé, parfois plus à Paris ou dans des contextes exigeants. Vérifiez toujours les chiffres actuels auprès de l'offre, de la convention collective concernée, et de l'entreprise elle-même. Aucune garantie ici.

Ce qui surprend les nouveaux venus#

Le métier est moins créatif qu'on l'imagine. Beaucoup de temps passe à lire de la doc, à comprendre un legacy, à retrouver pourquoi quelque chose existe.

On ne construit pas des cathédrales chaque semaine. On maintient, on répare, on automatise ce qui était manuel.

Autre surprise : le vocabulaire change d'une entreprise à l'autre. Le même travail s'appelle DevOps, Platform Engineer, SRE ou Cloud Engineer selon le recruteur. Regardez les missions concrètes, pas le titre.

Enfin, la progression technique plafonne vite si on ne touche jamais au code applicatif ni à la sécurité. Les profils qui restent lisibles dans les deux sens sont ceux qu'on cherche.

Ce que vous pouvez vérifier avant de postuler#

Avant d'envoyer votre candidature, voici ce qu'il faut clarifier. Ça vous évitera de mauvaises surprises.

• Qui fait l'astreinte, et à quelle fréquence
• La taille réelle de l'équipe cloud, et le ratio support par rapport au projet
• Les fournisseurs cloud utilisés, et depuis combien de temps
• Le niveau de maturité Terraform ou équivalent dans l'existant
• Qui arbitre les choix d'architecture quand deux équipes sont en désaccord
• La politique de télétravail, et le fuseau des équipes avec lesquelles vous allez travailler

Pour préparer vos candidatures, notre décodeur d'offres d'emploi peut vous aider à décrypter ce qu'une annonce demande vraiment, au-delà des mots à la mode. Vous trouverez aussi des ressources pratiques sur notre blog carrière pour préparer les entretiens techniques.

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 ?

Environ deux à trois heures pour un profil confirmé, plus pour un senior. C'est souvent ce qui surprend le plus les candidats qui sortent d'une formation ou d'un poste purement technique.

Faut-il maîtriser les trois grands fournisseurs cloud ?

Non, la maîtrise d'un seul fournisseur suffit pour démarrer dans la plupart des entreprises. Les concepts se transfèrent, mais les certifications et l'expérience terrain sur un écosystème précis sont ce qu'on demande.

Les astreintes sont-elles systématiques ?

Non, mais elles sont fréquentes, surtout en produit ou en environnement critique. Demandez toujours la fréquence, la compensation, et le niveau d'escalade attendu avant de signer.

Quelle est la différence concrète avec un DevOps ?

Les frontières sont floues et varient selon les entreprises. En pratique, le DevOps insiste sur la chaîne de livraison, le cloud engineer sur l'infrastructure et les services cloud. Lisez les missions de l'offre plutôt que le titre.

Peut-on devenir cloud engineer sans passer par l'administration système ?

C'est possible mais plus difficile. Les profils qui viennent de l'exploitation, du réseau ou de la sécurité s'adaptent souvent plus vite, car ils ont déjà vu ce qui casse en production.