Il décide comment isoler, connecter, sécuriser, dimensionner et faire évoluer les ressources cloud sur lesquelles les produits pourront durablement s’appuyer.
Le poste ne se résume ni à créer des ressources chez un fournisseur cloud, ni à traduire un schéma d’architecture en scripts. Il tient la couche de fondation : organisation des comptes et environnements, réseau, compute, stockage, identités, politiques de sécurité, infrastructure as code, sauvegarde, capacité et cycle de vie. Une infrastructure peut être fonctionnelle le jour de sa livraison tout en étant impossible à exploiter six mois plus tard.
La frontière avec les métiers voisins est volontairement stricte. Le DevOps Engineer fluidifie la chaîne de livraison. Le Platform Engineer transforme des capacités techniques en produit interne pour les développeurs. Le SRE protège la fiabilité d’un service en production. Le Cloud Infrastructure Engineer, lui, construit les fondations et rend ces choix exécutables, reproductibles, sécurisés et maintenables.
Celui qui exécute sait provisionner. Celui qui tient le poste sait pourquoi une ressource doit être isolée, quel flux doit être autorisé, quelle dépendance rend un changement risqué et comment revenir en arrière. La tension centrale du métier oppose vitesse de mise à disposition et maîtrise du patrimoine : aller vite sans créer un socle manuel, opaque ou sur-privilégié.
Repères marché
Le marché associe fréquemment ce titre à des postes DevOps, CloudOps ou Platform, ce qui produit des candidatures difficiles à comparer. Les profils capables de combiner une vraie profondeur réseau, une pratique rigoureuse de l’infrastructure as code, une maîtrise des identités et une expérience des environnements hybrides restent recherchés.
Les certifications sont courantes et utiles pour situer un écosystème, mais elles prédisent mal la capacité à conduire un changement risqué, à raisonner le rayon d’impact ou à reprendre un socle hérité. La rareté se situe moins dans la connaissance des services que dans le jugement d’infrastructure.
Contexte
En ESN, l’évaluation insiste sur la capacité à intervenir dans un patrimoine hérité, à composer avec les standards du donneur d’ordre, les limites contractuelles, les droits partagés et la nécessité de transmettre une infrastructure exploitable par d’autres. Le candidat doit savoir faire progresser un socle qu’il ne contrôle pas entièrement.
Niveau 1
Junior
Intervient sur un périmètre borné à partir de standards établis. Il sait déployer et modifier des composants courants, vérifie les prérequis, documente ce qu’il change et sollicite une validation lorsque l’impact dépasse son domaine. La différence avec un simple exécutant tient à sa capacité à ne pas masquer une inconnue par une valeur par défaut.
Cliquer pour lire
Niveau 2
Confirmé
Prend en charge un environnement ou un domaine d’infrastructure de bout en bout. Il relie réseau, identités, compute, stockage et infrastructure as code, traite les dépendances entre ces couches et sait conduire un changement réversible. Il garantit que la ressource peut être reproduite, maintenue et transmise.
Cliquer pour lire
Niveau 3
Sénior
Arbitre les choix de mise en œuvre selon le risque, le rayon d’impact, la sécurité, le coût et la trajectoire de migration. Il repère les exceptions qui deviendront une dette structurelle, séquence les transformations sans exiger de remise à plat et sait contredire une demande qui fragilise le socle. Il pense en patrimoine cloud, pas en ticket de provisioning.
Cliquer pour lire
Niveau 4
Expert
Ne se distingue pas par un catalogue plus large de services cloud. Il tranche les arbitrages les plus coûteux et en assume explicitement le prix : maintenir temporairement deux modèles d’infrastructure, ralentir une migration pour préserver la réversibilité, ou accepter un surcoût pour obtenir une isolation vérifiable. Il transforme ces décisions en standards utilisables par les autres.
Cliquer pour lire
C’est le cœur du poste : une mauvaise isolation, un adressage incohérent ou une dépendance réseau mal comprise contaminent toutes les couches construites au-dessus.
Une fondation cloud n’est maîtrisée que si elle est reproductible, traçable, modifiable sans dérive et supprimable proprement ; l’infrastructure as code est évaluée comme un mécanisme de contrôle, pas comme une compétence d’outil.
Les droits, l’exposition et le cloisonnement sont des propriétés de conception du socle. Les traiter après le déploiement transforme une erreur locale en risque transversal.
Le Cloud Infrastructure Engineer doit comprendre les domaines de panne, la restauration, les quotas et le dimensionnement, sans se substituer au SRE dans le pilotage quotidien de la fiabilité applicative.
Le poids est plus faible mais non accessoire : une infrastructure sans attribution des coûts, documentation de changement ni transfert aux équipes qui l’exploitent devient rapidement un patrimoine orphelin.
La méthode en action
La scorecard en un regard — survoler un axe
Cloud, plateforme et fiabilité