Préparation entretien Cloud Solutions Architect, ce qui vous attend

La profondeur technique est rarement le problème pour un SRE : vous avez vu de la prod à l'échelle, du failover, du réseau et du coût. L'écart, c'est le customer-facing. En tant que SRE, vous résolvez des problèmes ; en tant que Cloud SA, vous traduisez un besoin métier en architecture et vous la vendez en direct devant un client qui peut être méfiant. Le round qui recale le plus les profils ops, c'est l'architecture review, parce qu'elle donne l'impression d'un exercice de system design alors qu'on attend un design d'engagement client : découverte d'abord, besoin avant solution, coût comme contrainte de premier ordre. Entraînez-vous à ce round à froid et répétez le whiteboard à voix haute devant quelqu'un qui joue le client. Côté certif, passez l'architecte cœur de la plateforme visée : c'est un signal recruteur attendu en France. Sur le behavioral, ne pitchez pas seulement des incidents résolus ; trouvez 2 ou 3 histoires où vous avez convaincu une équipe ou un stakeholder, c'est ça qu'on cherche.

La trame du loop reste proche (recruteur, hiring manager, screen technique, architecture review, scénario client), mais l'angle change. Chez OVHcloud et Scaleway, le positionnement souveraineté et cloud de confiance est central : on attend que vous sachiez argumenter le RGPD, la localisation des données en Europe, et pour la santé l'hébergement de données de santé (HDS). Beaucoup de scénarios client tournent autour de "comment je quitte un hyperscaler US ou je construis une stratégie multi-cloud sans dépendance". Préparez-vous à parler réversibilité, conformité européenne et coût comparé. La profondeur services brute attendue peut être un cran sous celle d'AWS (catalogue plus restreint), mais la capacité à cadrer un besoin de souveraineté et à le traduire en architecture pèse plus lourd. Pas de Leadership Principles à la AWS ici ; le round comportemental reste classique, centré sur la relation client et le travail avec les équipes commerciales et delivery.

Vous avez l'atout que beaucoup de candidats n'ont pas : de vraies migrations livrées, avec des contraintes réelles. Le piège ESN, c'est que vos missions sont décrites côté projet, pas côté décision d'architecture, et qu'on ne voit pas votre part dans les trade-offs. Avant le loop, ressortez 2 ou 3 migrations et ré-écrivez-les en mode "j'ai recommandé / j'ai arbitré / j'ai défendu devant le client", avec l'échelle, le coût et le résultat. Pour l'angle avant-vente, le gros écart est le whiteboard et la simulation client : en delivery vous exécutez un design validé, en avant-vente vous le construisez en direct et le présentez à un sceptique. Entraînez ce round précisément. Côté rémunération en France : un poste avant-vente avec OTE (part variable) paie souvent mieux qu'un poste delivery à part technique égale, comptez plutôt le haut de la fourchette 60–90 k€ de base à Paris, plus le variable.

Non, et c'est l'erreur classique des profils dev. Un bon entretien de system design répond à "est-ce que cette architecture tient à l'échelle". Une architecture review de Cloud SA répond à "est-ce que vous menez l'engagement client comme un vrai SA". Concrètement : un candidat system design attaque le design ; un bon Cloud SA commence par la découverte (échelle, conformité, existant, budget, échéance), propose ensuite, et place le coût comme contrainte de premier ordre tout du long. Le jury joue souvent le client et teste votre sang-froid quand on conteste vos choix. Une réponse techniquement brillante mais sans cadrage client donne l'image d'un dev qui joue au SA, et c'est exactement ce qui recale. Gardez votre profondeur technique, mais enveloppez-la dans une conversation client : reformulez le besoin, chiffrez le coût, défendez vos trade-offs sécurité et résilience sans braquer.

Oui, la barre L4 / IC3 décrite ici s'applique que vous veniez du SWE, du SRE, du customer success ou directement de l'architecture. Les profils SWE / SRE ont en général la profondeur technique mais doivent travailler la découverte du besoin et le cadrage centré client. L'architecture review est le point de recalage le plus fréquent pour ces profils, parce qu'elle donne l'impression d'un system design alors qu'on attend un design d'engagement client. Entraînez ce round à froid.

Le process prend 5 à 8 semaines. Ajoutez 4 à 6 semaines de prep si vous êtes rouillé sur les services de la plateforme ; 8 à 12 semaines si vous venez du SWE / SRE sans expérience customer-facing. La certif d'architecte plus le framework well-architected couvrent l'essentiel de la surface technique ; les Leadership Principles d'AWS (si vous postulez là) demandent une prep dédiée.

Traiter l'architecture review comme un entretien de system design. Les rounds d'architecture Cloud SA portent sur le design d'engagement client : découverte d'abord, besoin avant solution, coût comme contrainte de premier ordre. De bonnes réponses de system design sans le cadrage client donnent l'image d'un candidat dev qui joue au SA.

L'essentiel de la variation est marginal. Les grandes boîtes tech (FAANG, scale-ups, SaaS mid-size) suivent un process à 1–2 rounds près de ce qui est décrit. Les petites startups tournent souvent sur moins de rounds (3 à 4) mais la barre par round reste similaire ; les boîtes moins matures tech sautent parfois system design ou comportemental. Lisez l'offre et demandez au recruteur lors du pré-screen, il vous dira ce qui vient.

Ce guide couvre la barre générale au niveau L4 / IC3. Le scan gratuit lit votre offre d'emploi spécifique et renvoie les questions prédites pour ce poste + cette entreprise, un benchmark de salaire calibré et (avec votre CV) une analyse des écarts d'expérience et un passage ATS de CV. PDF par e-mail.