Il dessine l’infrastructure avant de la construire : où tourne quoi, ce que ça coûte, et ce qui se passe quand ça tombe.
L’architecte cloud conçoit l’infrastructure d’une entreprise ou d’un produit : régions et réseaux, calcul et stockage, identités et accès, sauvegardes et reprise. Il la décrit en code, avec Terraform, pour qu’elle soit reproductible.
Il travaille avec l’ingénieur DevOps, qui construit et exploite, et avec l’architecte logiciel, qui conçoit l’application. Lui répond aux questions de structure : combien de comptes, quel réseau, quelle base gérée, quel plan de reprise, pour quel budget.
Pour une entreprise d’Afrique de l’Ouest, il tranche des questions concrètes : héberger en Europe, en Afrique ou chez un hébergeur local, selon la latence, la loi sur les données personnelles et le coût ; garder un serveur sur site pour l’agence sans liaison fiable ; prouver que la reprise fonctionne avant la panne. Il fixe avec le client deux repères qui pilotent tout : le RTO, délai admis pour redémarrer, et le RPO, quantité de données qu’on accepte de perdre.
Dessiner l’architecture cible et la justifier : par exemple, une organisation AWS à plusieurs comptes (production, recette, outils), un réseau privé par environnement et des schémas que l’équipe et le client comprennent.
Décrire toute l’infrastructure en modules Terraform versionnés : par exemple, un module « application web » réutilisé pour chaque pays, dont toute modification est relue et planifiée avant d’être appliquée.
Supprimer les points uniques de défaillance : par exemple, une base de données gérée répliquée sur deux zones, un cluster Kubernetes qui remplace seul un nœud défaillant et un équilibreur de charge qui écarte les instances malades.
Survivre à la panne d’une région entière : par exemple, des sauvegardes copiées dans une seconde région, un plan de bascule documenté et un exercice de reprise mené sur un environnement vierge pour vérifier le RTO et le RPO promis.
Ne payer que ce qui sert : par exemple, le coût de chaque changement Terraform estimé par Infracost avant la fusion, des instances réservées pour la charge stable et un arrêt automatique des environnements de recette la nuit et le week-end.
Verrouiller les accès et les données : par exemple, des rôles IAM au plus juste, des clés gérées par un service de chiffrement, un journal d’audit central et une revue régulière des comptes et des permissions inutilisés.
De la base vers le haut : ce qu'il manie chaque jour.
Cloud
Infrastructure en code
Calcul et conteneurs
Réseau et accès
Données et reprise
Supervision et coûts
Il conçoit pour la panne qui n’est pas encore arrivée, parce qu’elle arrivera un vendredi soir.
Chaque ressource laissée allumée se paie chaque mois, et il doit savoir dire combien avant de dire oui.
Une infrastructure que lui seul comprend est un risque, pas un atout.
Une modification d’infrastructure se relit, se planifie et se teste, parce qu’une faute de frappe peut détruire une base de production.
0 à 2 ans
Il écrit des modules Terraform sur une architecture déjà dessinée, documente les environnements et prépare des comparatifs de coûts relus par un architecte confirmé.
3 à 5 ans
Il conçoit l’infrastructure d’un produit ou d’une filiale, mène les exercices de reprise et défend ses choix de coût et de disponibilité devant le client.
6 ans et plus
Il définit la plateforme cloud de toute l’entreprise, ses comptes, ses règles de sécurité et son budget, et arbitre entre cloud public, hébergeur local et serveurs sur site.
École d’ingénieurs ou master en informatique, puis plusieurs années comme ingénieur DevOps, administrateur système ou développeur backend. Les certifications AWS Certified Solutions Architect, HashiCorp Terraform Associate et CKA sont les plus demandées ; un dépôt Terraform propre, avec ses modules et son plan de reprise, les complète.
Des réalisations Wiicode où ce métier est au cœur de la stack.
Responsable infrastructure, architecte d’entreprise, CTO, consultant cloud.
Vous ne trouvez pas votre métier ?Candidature spontanée