Métier

Cloud Architect

Architecte Cloud · Cloud Engineer · Solutions Architect · Platform Architect

Mis à jour le 27 avril 2026

Missions

Le Cloud Architect définit les fondations techniques sur lesquelles reposent les systèmes de production. Son périmètre va de la conception des VPCs et des politiques IAM au choix des services managés (RDS, Lambda, BigQuery, Pub/Sub), en passant par la stratégie de haute disponibilité, le disaster recovery, et la gouvernance multi-compte ou multi-projet.

Dans une startup qui passe à l’échelle, il est souvent le premier à formaliser l’Infrastructure as Code (Terraform ou Pulumi) et à mettre en place des guard-rails pour que les équipes produit puissent déployer en toute autonomie sans casser la sécurité ou exploser le budget. Dans un grand compte, il pilote des migrations cloud de systèmes legacy, négocie les architectures avec les directions métier et assure la conformité réglementaire (ISO 27001, SOC 2, HDS pour la santé).

Compétences clés

La maîtrise d’au moins une plateforme cloud majeure — AWS, GCP ou Azure — est le prérequis. AWS reste dominant sur le marché français, mais GCP est très présent dans les organisations data-intensive, et Azure domine les grands comptes Microsoft. Une certification professionnelle (AWS Solutions Architect Professional, GCP Professional Cloud Architect) est fortement valorisée et souvent exigée au niveau senior.

L’Infrastructure as Code est non-négociable : Terraform est le standard de facto, Pulumi monte dans les équipes engineering-first. La conteneurisation (Docker, Kubernetes) fait partie du socle de base. Le FinOps — analyse des coûts, rightsizing des instances, stratégie Spot/Reserved/Savings Plans — est devenu une compétence distinctrice à partir du niveau confirmé, car les coûts cloud sont désormais une ligne de P&L visible pour le management.

La sécurité réseau cloud (VPC peering, Private Link, WAF, gestion des secrets via Vault ou AWS Secrets Manager) et la supervision (Datadog, CloudWatch, Prometheus/Grafana) complètent le profil senior.

Trajectoire d’évolution

Le Cloud Architect arrive rarement débutant — le rôle se construit à partir d’une expérience en DevOps, en SRE ou en Backend senior. Un confirmé commence à prendre en charge des architectures complètes de services : choix des patterns de déploiement, design des pipelines CI/CD, optimisation des coûts. Le passage senior implique des responsabilités transverses : définition des standards d’infrastructure à l’échelle de l’organisation, arbitrages entre plusieurs équipes, pilotage des migrations majeures.

Les Cloud Architects les plus expérimentés évoluent vers des rôles de Principal Engineer (décisions d’infrastructure à horizon 3-5 ans), de VP Engineering ou de CTO dans des organisations cloud-native.

En entretien

Les entretiens Cloud Architect sont centrés sur le design : on vous demandera de concevoir une architecture pour un cas concret (système de traitement d’événements à 100k TPS, plateforme ML, migration d’un ERP on-premise). L’examinateur attend des questions sur les SLOs, les coûts et les compromis de sécurité — pas une solution unique présentée comme évidente.

Les certifications cloud sont un signal fort mais ne remplacent pas la capacité à défendre des choix architecturaux sous contrainte. Préparez des exemples d’incidents liés à l’infrastructure que vous avez gérés, avec chiffres de disponibilité et leçons retenues.

Fourchette de salaire

Estimation France entière, brut annuel. Médian basé sur la séniorité confirmée (3-5 ans).

44k € Médian 74k € 118k €

Questions d'entretien typiques

  1. 01

    Comment choisissez-vous entre une architecture multi-cloud et une architecture mono-cloud pour une scale-up ?

  2. 02

    Décrivez votre approche pour migrer une application monolithique vers des conteneurs en production sans downtime.

  3. 03

    Comment mettez-vous en place une stratégie de disaster recovery avec un RTO inférieur à 15 minutes ?

  4. 04

    Un pic de coût cloud inattendu de 40 % apparaît en fin de mois. Comment l'investigez-vous ?

  5. 05

    Comment implémentez-vous le principe de moindre privilège à l'échelle dans un compte AWS avec 50 équipes ?