Les offres parlent d'architecte sécurité cloud, de cloud security architect ou d'architecte sécurité cloud et IA. Le poste se situe entre le RSSI et les équipes qui construisent. Il ne règle pas lui-même chaque service de détection : il décide de ce que la plateforme doit garantir et vérifie que les projets le respectent. Les questions d'entretien d'architecte sécurité cloud partent des décisions que la personne a prises, pas des outils qu'elle cite.
Deux profils se présentent souvent. Les uns viennent de la sécurité des systèmes d'information, avec EBIOS RM, ISO 27001 et la gouvernance, mais ont rarement lu une politique IAM ou un plan Terraform. Les autres sont d'anciens ingénieurs cloud, solides sur AWS, Azure ou Google Cloud, moins à l'aise avec l'analyse de risques et les textes (NIS2, DORA, HDS, règlement sur l'IA). Le poste demande les deux.
L'entretien déroule une revue d'architecture réelle : le projet, les risques retenus, les mesures exigées, la dérogation accordée et sa date de fin. Le PDF comprend 30 questions sur six axes et un cas de 20 minutes sur un assistant d'IA générative branché sur des documents internes.
Les référentiels et briques qu'un architecte sécurité cloud arbitre
Modèle de responsabilité partagée
Le fournisseur sécurise l'infrastructure, le client sécurise ce qu'il y configure : identités, données, réseau, applications. La frontière se déplace entre IaaS, PaaS et SaaS. L'architecte doit la décrire service par service, parce que la plupart des incidents cloud viennent de la part du client.
Zero trust
Un modèle qui n'accorde aucune confiance à un accès parce qu'il vient du réseau interne. Chaque accès est authentifié, autorisé selon l'identité, l'état du poste et le contexte, puis journalisé. Le NIST le décrit dans la publication SP 800-207. En entretien, la question porte sur son application aux administrateurs et aux flux entre applications, pas seulement aux utilisateurs.
Identités humaines et identités de charge de travail
La stratégie d'identité couvre la fédération avec l'annuaire de l'entreprise (Entra ID, Okta), l'accès à privilèges avec élévation temporaire, et les identités des applications et des pipelines : rôles, identités managées, comptes de service, fédération OIDC. Les clés d'accès de longue durée sont la première cible à faire disparaître.
Gestion des clés et chiffrement
Les services de clés des fournisseurs (AWS KMS, Azure Key Vault, Cloud KMS), les HSM dédiés et les gestionnaires de clés externes. L'architecte décide quelles données demandent une clé gérée par le client, une clé importée (BYOK) ou une clé conservée hors du cloud (HYOK), selon la classification des données et ce que l'exploitation peut tenir.
EBIOS Risk Manager
La méthode d'analyse de risques de l'ANSSI, en cinq ateliers, du socle de sécurité jusqu'aux scénarios opérationnels et au traitement du risque. Sur un projet cloud, elle sert à justifier les mesures exigées et les risques résiduels acceptés par le métier. Beaucoup d'offres la demandent, souvent avec ISO 27005.
NIS2, DORA, HDS et SecNumCloud
NIS2 étend les obligations de cybersécurité à un grand nombre d'entités. Sa transposition française passe par le projet de loi dit Résilience, adopté par le Sénat en mars 2025 et toujours en attente à l'Assemblée nationale début novembre 2026. Le règlement DORA s'applique au secteur financier depuis janvier 2025 et encadre les prestataires informatiques tiers, fournisseurs cloud compris. HDS s'impose pour héberger des données de santé, SecNumCloud pour les données les plus sensibles. L'architecte traduit ces textes en exigences techniques.
Journalisation et intégration au SOC
Journaux d'activité des comptes, connexions et changements d'identité, flux réseau, accès aux données, alertes des outils de détection. L'architecte décide ce qui part au SIEM (Microsoft Sentinel, Splunk, Google Security Operations ou autre), ce qui reste en archive et combien de temps, et quels scénarios de détection le SOC doit couvrir.
Sécurité des services d'IA
Les assistants et agents construits sur Azure OpenAI, Amazon Bedrock ou Vertex AI posent des questions nouvelles : fuite de données par le contexte, injection de prompt, droits des agents sur les outils, journalisation des échanges. L'OWASP publie un Top 10 des risques des applications LLM, et l'ANSSI des recommandations pour les systèmes d'IA générative. Le règlement européen sur l'IA ajoute ses obligations selon l'usage.
L'architecte sécurité cloud rend compte au RSSI ou à la direction de l'architecture. Il travaille avec les architectes cloud, l'équipe plateforme, le SOC, la conformité et le DPO. Selon l'organisation, il conçoit surtout les architectures de référence et les revues de projets, ou il porte aussi la mise en conformité réglementaire de la plateforme. Les certifications CCSP de l'ISC2, CCSK de la Cloud Security Alliance et les certifications sécurité des fournisseurs, comme AWS Certified Security Specialty, Microsoft SC-100 ou Google Professional Cloud Security Engineer, attestent des connaissances. La pratique se juge sur des décisions prises et défendues devant un projet.
Six domaines attendus d'un architecte sécurité cloud
- Architectures de référence et zero trust
- Stratégie d'identité et accès à privilèges
- Chiffrement et maîtrise des clés
- Segmentation et flux hybrides
- Analyse de risques, réglementation et dérogations
- Détection, SOC et sécurité des services d'IA
Cinq questions d'entretien, de la revue d'architecture aux clés
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · senior
Un projet vous présente une application exposée sur internet, une base managée et un accès depuis le datacenter. Comment conduisez-vous la revue d'architecture ?
Une bonne réponseIl part des données traitées et de leur classification, puis suit les flux : qui accède, d'où, avec quelle identité. Il vérifie l'exposition (point d'entrée unique, WAF, protection DDoS), l'accès privé à la base, le chiffrement et ses clés, les identités des composants, les journaux envoyés au SOC et les sauvegardes. Il compare au socle et à l'architecture de référence, liste les écarts avec leur risque et rend un avis écrit : accepté, accepté sous conditions datées, ou refusé.
Signal d'alerteUne checklist générique cochée sans lien avec les données ni les flux, ou un avis oral sans trace.
Question 2 · confirmé
Un audit trouve 300 clés d'accès de longue durée utilisées par des scripts et des pipelines. Quelle stratégie proposez-vous ?
Une bonne réponseUn inventaire avec la dernière utilisation et le propriétaire de chaque clé, puis le remplacement par des identités sans secret : rôles assumés, identités managées, comptes de service attachés aux ressources, fédération OIDC pour les pipelines GitLab ou GitHub. Les clés qui restent ont une durée limitée, une rotation et une surveillance. Une règle préventive empêche d'en créer de nouvelles hors exception.
Signal d'alerteUne rotation de toutes les clés tous les 90 jours comme seule réponse.
Question 3 · senior
Un métier exige que ses données soient chiffrées avec sa propre clé. Comment choisissez-vous entre clé du fournisseur, clé gérée par le client, clé importée et clé conservée hors du cloud ?
Une bonne réponseIl part de la menace à couvrir. La clé du fournisseur protège contre le vol de supports. La clé gérée par le client dans le KMS donne la main sur les droits, la rotation et la révocation, et trace chaque usage. La clé importée (BYOK) répond à une exigence de génération hors du fournisseur. La clé conservée hors du cloud (HYOK, gestionnaire externe) vise l'accès du fournisseur, au prix de la disponibilité et de services incompatibles. Il documente le choix par classe de données.
Signal d'alertePrésenter BYOK comme une protection contre l'accès du fournisseur, ou imposer une clé externe partout sans mesurer l'effet sur la disponibilité.
Question 4 · confirmé
Une équipe demande une dérogation pour exposer une base de données sur internet pendant une migration. Comment la traitez-vous ?
Une bonne réponseIl comprend le besoin et cherche une autre voie (lien privé, réplication par un service managé, accès restreint par adresse source avec authentification forte). S'il accorde la dérogation, elle est écrite, limitée dans le temps et le périmètre, assortie de mesures compensatoires, acceptée par le propriétaire du risque côté métier et suivie jusqu'à sa clôture, avec une alerte à l'échéance.
Signal d'alerteUne dérogation orale sans date de fin, ou un refus sans proposer d'alternative.
Question 5 · senior
Les équipes veulent un assistant d'IA générative qui répond à partir des documents internes, sur un service d'IA du cloud. Quelles exigences de sécurité fixez-vous ?
Une bonne réponseLe respect des droits existants : l'assistant ne restitue que les documents que l'utilisateur peut déjà lire, avec un filtrage par identité au moment de la recherche. Un accès privé au service, des données qui restent dans la région choisie et ne servent pas à entraîner le modèle, des protections contre l'injection de prompt par des documents piégés, des droits minimaux si l'assistant appelle des outils, des échanges journalisés vers le SOC avec une durée de conservation, et une revue au regard du RGPD et du règlement sur l'IA.
Signal d'alerteUn index unique de tous les documents ouvert à tous les utilisateurs, ou le filtre de contenu du fournisseur présenté comme la seule protection.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Architecte sécurité cloud, les questions fréquentes
Quelle différence entre un architecte sécurité cloud et un ingénieur sécurité cloud ?
L'ingénieur sécurité cloud met en place et exploite les contrôles sur un cloud donné : garde-fous de l'organisation, services de détection, gestion des clés, traitement des alertes. L'architecte sécurité cloud décide de ce que ces contrôles doivent garantir, sur un ou plusieurs clouds. Il rédige les exigences et les architectures de référence, revoit les projets, mène les analyses de risques et répond aux questions réglementaires avec le RSSI. Dans une petite équipe, une même personne fait souvent les deux.
Un architecte sécurité cloud doit-il connaître plusieurs clouds ?
Il doit en connaître un en profondeur et savoir transposer ses exigences aux autres. Les principes sont communs (identités, chiffrement, segmentation, journaux), les mécanismes changent : SCP et politiques IAM sur AWS, Azure Policy et Entra ID sur Azure, contraintes d'organisation et VPC Service Controls sur Google Cloud. Sur une plateforme multicloud, il doit savoir exprimer une même exigence sur chacun.
Quelles certifications sont attendues d'un architecte sécurité cloud ?
Les plus courantes sont la CCSP de l'ISC2, la CCSK de la Cloud Security Alliance et les certifications sécurité des fournisseurs, comme AWS Security Specialty, Microsoft SC-100 ou Google Professional Cloud Security Engineer. Une formation EBIOS RM ou ISO 27005 compte pour l'analyse de risques. Aucune de ces certifications ne montre la capacité à arbitrer entre un projet pressé et une exigence de sécurité ; le récit de dérogations réellement accordées ou refusées le montre.
Faut-il un test technique pour un architecte sécurité cloud ?
Un exercice sur des commandes a peu d'intérêt à ce niveau. Une revue d'architecture en direct est plus parlante : sur un schéma de projet avec ses flux, ses données et un calendrier serré, le candidat expose les risques, les exigences et l'avis rendu. On voit la profondeur technique, la méthode et la capacité à trancher. Delectus propose ce type de cas dans le PDF de cette page.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
