Le poste change de forme selon l'organisation. Dans une grande DSI, l'architecte sécurité applicative écrit les patterns que les équipes reprennent : flux OAuth 2.0 et OpenID Connect par type d'application, passage de l'identité entre microservices, accès aux secrets, place de la gateway. Ailleurs, il passe la plupart de ses semaines en revues de dossiers d'architecture et en analyses de menace. Beaucoup d'annonces récentes y ajoutent la sécurité des applications d'IA générative. Les questions d'entretien d'architecte sécurité applicative partent de ce que la personne fera vraiment.
Beaucoup de candidats viennent du pentest ou de l'AppSec. Ils connaissent les vulnérabilités, mais pas toujours les décisions de conception qui les évitent pour cinquante équipes à la fois. Un vrai profil d'architecte parle d'audience d'un jeton, de révocation, de rotation des secrets, de latence d'un contrôle d'autorisation et de ce qui reste à la charge du code quand la plateforme a fait sa part.
Un développeur senior ou l'architecte applicatif a sa place dans le jury. Il voit vite si les patterns proposés tiennent dans un vrai code et dans un vrai délai. Le PDF propose 30 questions sur six axes et un cas de 20 minutes.
Standards et briques qu'un architecte sécurité applicative prescrit
OAuth 2.0 et OpenID Connect
Les protocoles qui délèguent l'authentification au fournisseur d'identité et donnent des jetons aux applications. Le RFC 9700, publié en 2025, fixe les bonnes pratiques de sécurité d'OAuth 2.0. OAuth 2.1, qui les reprend, est encore un brouillon de l'IETF. Un architecte doit dire quel flux convient à une application web, mobile ou serveur.
Jetons et échange de jetons
Les JWT portent l'identité et les droits d'un appel. L'échange de jeton (RFC 8693) produit un jeton plus restreint pour appeler un service en aval. DPoP (RFC 9449) et les jetons liés à un certificat mTLS (RFC 8705) rendent un jeton volé inutilisable. Ces notions séparent vite un architecte d'un intégrateur.
Identité des services : mTLS, SPIFFE, service mesh
Entre services, l'identité passe par des certificats courts délivrés par la plateforme, avec SPIFFE/SPIRE, Istio ou les identités managées du cloud. Elle remplace les mots de passe partagés entre applications. Le mesh dit quel service appelle, jamais quel utilisateur.
Moteurs d'autorisation
Open Policy Agent, OpenFGA ou Cedar sortent les règles d'accès du code pour les écrire sous forme de politiques testables. Le choix dépend du modèle de droits (rôles, attributs, relations) et de la latence acceptable. Le sujet revient dès qu'une application dépasse quelques services.
Coffres à secrets
HashiCorp Vault, son fork open source OpenBao, Azure Key Vault, AWS Secrets Manager ou Google Secret Manager. L'architecte fixe comment une application s'authentifie au coffre, qui lit quoi, et comment les secrets tournent. La question du premier secret, celui qui ouvre le coffre, montre si la personne a déjà déployé l'outil.
Gateway d'API et OWASP API Security Top 10
La gateway authentifie, limite le débit et journalise. Elle ne sait pas si l'utilisateur a le droit de lire tel objet : ce contrôle reste dans le service. Le Top 10 OWASP API Security (édition 2023) sert de base aux exigences d'exposition.
Analyse de menace et OWASP ASVS
STRIDE, des outils comme OWASP Threat Dragon et les schémas de flux servent à repérer les menaces sur un dossier d'architecture. L'ASVS, en version 5.0.0 depuis le 30 mai 2025, fournit les exigences vérifiables qui en découlent. Le Top 10 OWASP a été mis à jour en 2025.
Sécurité des applications LLM
L'OWASP Top 10 pour les applications LLM (édition 2025) et MITRE ATLAS décrivent les risques : injection de prompt, fuite de données, agentivité excessive, sorties non contrôlées. Pour un assistant RAG ou un agent, l'architecte décide des droits, des outils et des validations humaines.
Cyber Resilience Act
Le règlement (UE) 2024/2847 vise les produits comportant des éléments numériques. Le signalement des vulnérabilités activement exploitées s'applique depuis le 11 septembre 2026, la plupart des autres obligations au 11 décembre 2027. Pour un éditeur de logiciel, il change la conception des mises à jour et la gestion des composants.
Le titre d'architecte sécurité applicative recouvre des postes rattachés au RSSI ou à la direction de l'architecture. Dans le premier cas, la personne revoit les projets et valide les exigences avant l'homologation. Dans le second, elle construit les patterns, les bibliothèques et les modules que les équipes réutilisent. Les missions de conseil demandent souvent les deux, sur un SI inconnu et en peu de temps. Le passé de développeur aide beaucoup : un architecte qui n'a jamais intégré un flux OAuth ni lu une politique d'autorisation propose des cibles que les équipes contournent. Sur HelloWork et Free-Work, plusieurs offres récentes associent déjà le titre à l'IA générative : RAG, agents, OWASP Top 10 pour les LLM.
Six sujets de conception attendus d'un architecte sécurité applicative
- Patterns d'authentification et de délégation
- Autorisation et identité entre services
- Gestion des secrets et des clés applicatives
- Sécurité des API et des flux
- Analyse de menace d'architectures
- Sécurité des applications à base de LLM
Cinq questions d'entretien, des jetons aux secrets
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 microservice reçoit le jeton d'accès d'un utilisateur et doit appeler deux autres services internes. Faites-vous suivre le même jeton ?
Une bonne réponsePas tel quel quand les services n'ont pas le même niveau de sensibilité. Le jeton reçu a une audience précise ; le réutiliser ailleurs revient à accepter un jeton qui n'était pas prévu pour soi. Un bon candidat cite l'échange de jeton (OAuth 2.0 Token Exchange, RFC 8693) pour obtenir un jeton d'audience et de portée réduites qui garde l'identité de l'utilisateur, ou à défaut un jeton de service accompagné du sujet de l'utilisateur dans un champ signé. Chaque service vérifie l'audience, l'émetteur et l'expiration.
Signal d'alerte« On transmet le jeton partout, c'est plus simple », ou un compte de service unique avec tous les droits qui appelle les services en aval sans trace de l'utilisateur d'origine.
Question 2 · senior
Les règles d'accès d'une application métier sont dispersées dans le code de vingt microservices. Proposez-vous un moteur d'autorisation central ?
Une bonne réponseLe candidat sépare le point de décision (PDP) des points d'application (PEP) et cite des options comme Open Policy Agent, OpenFGA (modèle relationnel inspiré de Zanzibar) ou Cedar. Il garde un contrôle grossier à la gateway et la décision fine au plus près du service, avec un déploiement local ou en sidecar pour ne pas créer un point de panne unique ni ajouter de latence. Il prévoit les journaux de décision, les tests des politiques et une migration service par service.
Signal d'alerteTout mettre dans la gateway, ou un service central appelé en synchrone à chaque requête sans parler de disponibilité, de cache ni de latence.
Question 3 · senior
Dans cent applications, l'exploitation recopie les secrets à la main dans les fichiers de configuration à chaque livraison. Comment les faites-vous passer à un coffre, et lesquelles migrez-vous en premier ?
Une bonne réponseUn coffre central (HashiCorp Vault, OpenBao, Azure Key Vault, AWS Secrets Manager ou Google Secret Manager) avec une authentification de l'application par l'identité de la plateforme, des droits par application et par environnement, et des journaux d'accès. La migration commence par l'inventaire et le classement des secrets, puis les applications les plus exposées. Les secrets sont changés au moment de la bascule, puisque les anciennes valeurs ont circulé. Le candidat prévoit l'injection (agent, CSI driver, appel API) adaptée à chaque type d'hébergement.
Signal d'alerte« On met les secrets chiffrés dans le dépôt Git » comme cible finale, ou une migration qui garde les mêmes valeurs sans rotation.
Question 4 · senior
Une équipe veut ouvrir une API interne sur internet en plaçant simplement la gateway devant. Que vérifiez-vous avant de donner votre accord ?
Une bonne réponseQue l'API vérifie elle-même les droits sur chaque objet (le risque BOLA du Top 10 OWASP API Security), car la gateway ne connaît pas les propriétaires des données. Que les réponses ne renvoient pas plus de champs que nécessaire, que les schémas d'entrée sont validés, que les quotas sont posés par client, et que les opérations d'administration restent internes. Le candidat demande aussi l'inventaire des routes exposées, la journalisation, et souvent une API dédiée à l'extérieur plutôt que l'API interne telle quelle.
Signal d'alerte« La gateway fait l'authentification, donc c'est sécurisé », sans un mot sur le contrôle d'accès au niveau de l'objet.
Question 5 · senior
Un assistant RAG répond aux salariés à partir de documents SharePoint. Comment garantissez-vous qu'il ne cite jamais un document que la personne n'a pas le droit de lire ?
Une bonne réponseLe filtrage se fait à la recherche, avec les droits de l'utilisateur qui pose la question, et non dans le prompt. Les droits des documents sont indexés avec eux et resynchronisés, et l'identité de l'utilisateur est propagée jusqu'à l'index (appel au nom de l'utilisateur). Le candidat traite les droits retirés après indexation, les liens de partage trop larges dans SharePoint, et teste avec des comptes aux droits différents.
Signal d'alerte« On demande au modèle de ne pas révéler les documents confidentiels », ou un index alimenté par un compte qui lit tout sans filtrage par utilisateur.
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é applicative, les questions fréquentes
Architecte sécurité applicative ou ingénieur AppSec : quel poste ouvrir ?
L'ingénieur AppSec travaille application par application : revue de code, outils SAST et DAST, tests, accompagnement d'une équipe. L'architecte fixe les règles et les patterns que toutes les équipes suivent, et tranche entre sécurité, coût et délai sur les dossiers d'architecture. Quand les standards existent et qu'il manque des bras pour les appliquer, le poste est celui d'ingénieur. Si chaque équipe invente sa propre authentification, il faut un architecte.
Faut-il un passé de développeur pour ce poste ?
Ce n'est pas une obligation, mais c'est le meilleur indicateur. Un architecte sécurité applicative qui a codé un client OAuth, intégré un coffre à secrets ou écrit une politique d'autorisation propose des solutions que les équipes adoptent. Sans ce passé, il doit au moins avoir travaillé de près avec des développeurs, et savoir décrire le code ou la configuration que son pattern impose, ligne par ligne s'il le faut.
Sur quoi porte le test technique d'un architecte sécurité applicative ?
Un schéma plutôt que du code. À partir du dossier d'architecture d'une application fictive avec ses flux, ses API et un assistant à base de LLM, le candidat dégage en 20 minutes les menaces principales, les patterns à imposer et les risques à accepter. L'ordre des priorités et la précision des exigences comptent. Un candidat solide pose des questions sur les données et les utilisateurs avant de proposer des solutions.
Quelles certifications regarder sur le CV ?
Le CSSLP de l'ISC2 porte sur la sécurité du cycle de développement, et le CISSP avec sa concentration ISSAP sur l'architecture de sécurité. Elles attestent une culture générale. Elles ne disent rien de la maîtrise d'OAuth, d'un moteur d'autorisation ou d'un coffre à secrets en production. Une contribution open source, une conférence ou un pattern publié par la personne renseignent souvent mieux qu'un sigle.
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.
