Les offres d'architecte microservices ou d'architecte événementiel citent Kafka en premier, puis RabbitMQ, Kubernetes ou OpenShift, une API gateway et parfois un service mesh comme Istio. Le langage change d'une offre à l'autre : Java, Go, .NET ou Node.js. Les questions d'entretien d'un architecte microservices portent donc moins sur un framework que sur les frontières, les contrats d'événements et les pannes.
L'outillage a beaucoup bougé. Kafka 4.0, sorti en mars 2025, fonctionne sans ZooKeeper, et les files de Kafka (share groups) sont utilisables en production depuis la version 4.2 de février 2026. RabbitMQ 4 a retiré les files classiques mirrorées au profit des quorum queues. AsyncAPI 3 décrit les contrats d'événements comme OpenAPI décrit les API REST. Un candidat qui a migré un cluster vers KRaft ou des files vers les quorum queues a des choses précises à raconter.
Le profil à écarter découpe par entité, un service Client, un service Produit, un service Adresse, et relie le tout par des appels synchrones. Demandez comment le candidat a trouvé les frontières, par event storming ou par l'étude des équipes, et ce qu'il a regroupé après coup. Le PDF ajoute 30 questions, un cas de 20 minutes et une grille de notation.
Brokers, patterns et outils de l'architecture événementielle
Apache Kafka
Le journal d'événements distribué le plus répandu. Les messages sont conservés pendant une durée choisie et peuvent être relus, ce qui permet d'ajouter un consommateur ou de rejouer un traitement. L'ordre n'est garanti qu'à l'intérieur d'une partition. Depuis la version 4.0, Kafka tourne uniquement en mode KRaft, sans ZooKeeper.
RabbitMQ
Un broker de messages orienté files, fort sur le routage, les accusés de réception par message et les files de travail. La version 4 a retiré les files mirrorées classiques, les quorum queues assurent désormais la réplication. Il reste un bon choix quand on n'a pas besoin de relire l'historique.
Event storming et DDD stratégique
L'event storming est un atelier, inventé par Alberto Brandolini, où métier et développeurs posent sur un mur les événements d'un processus dans l'ordre. Il fait apparaître les bounded contexts du Domain-Driven Design, c'est-à-dire les zones où un même mot garde un même sens. C'est la base d'un découpage par domaine plutôt que par entité.
Outbox et CDC (Debezium)
L'outbox transactionnelle écrit l'événement dans la base, dans la même transaction que la donnée métier. Un relais le publie ensuite, soit en interrogeant la table, soit avec un outil de capture des changements comme Debezium qui lit le journal de la base. C'est la réponse standard au problème de la double écriture.
Sagas et orchestrateurs
Une saga enchaîne des transactions locales dans plusieurs services, avec une compensation prévue pour chaque étape si la suite échoue. Elle est chorégraphiée par des événements ou pilotée par un orchestrateur, développé en interne ou fourni par un moteur de workflow comme Temporal ou Camunda.
Schema Registry, Avro et AsyncAPI
Le Schema Registry stocke les schémas des événements (Avro, Protobuf ou JSON Schema) et refuse un nouveau schéma incompatible avec les précédents. AsyncAPI documente les canaux, les messages et leurs propriétaires. Ensemble, ils évitent qu'un producteur casse ses consommateurs sans le savoir.
API gateway
Le point d'entrée des appels externes : routage, validation des jetons, limitation de débit, TLS. Kong, Apigee, Azure API Management ou Spring Cloud Gateway reviennent souvent dans les offres. La gateway ne doit pas porter de logique métier.
Service mesh (Istio, Linkerd)
Une couche réseau qui gère le chiffrement mTLS entre services, les délais d'attente, les nouvelles tentatives et la répartition du trafic, sans changer le code. Istio propose depuis fin 2024 un mode ambient en disponibilité générale, sans proxy sidecar dans chaque pod. Le mesh coûte en exploitation et ne se justifie pas pour cinq services.
OpenTelemetry et traçage asynchrone
Le standard ouvert pour les traces, métriques et logs. Le contexte de trace voyage dans les en-têtes HTTP et dans les en-têtes des messages Kafka, ce qui permet de suivre une commande à travers les services et les topics. Sans lui, un flux événementiel est très difficile à déboguer.
Le poste se rencontre sous plusieurs titres : architecte microservices, architecte événementiel, architecte d'intégration, parfois architecte solution avec une forte part d'asynchrone. L'architecte conçoit un nouveau système, reprend un découpage qui a mal vieilli, ou fixe les règles communes à de nombreuses équipes : format des événements, nommage des topics, compatibilité des schémas. Il est rarement seul responsable de la plateforme Kafka, souvent tenue par une équipe dédiée. Précisez ce que vous attendez de lui, la conception des flux métier ou l'exploitation du broker, car les questions changent.
Ce qu'un architecte microservices doit savoir concevoir
- Découpage par domaine et bounded contexts
- Conception et évolution des événements
- Cohérence des données : outbox, sagas, idempotence
- Brokers et garanties de livraison
- Appels synchrones, gateway et service mesh
- Observabilité, tests de contrat et rejeu
Découpage, schémas, ordre, rejeu : les questions à poser
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
Une équipe a découpé son système en services Client, Produit, Commande, Adresse et Prix. Passer une commande appelle quatre services avant de répondre. Qu'en pensez-vous, et que proposez-vous ?
Une bonne réponseUn découpage par entité, qui donne un monolithe distribué : chaque requête dépend de quatre services disponibles en même temps. Il propose de regrouper par capacité métier ou bounded context. La prise de commande garde sa propre copie du prix et de l'adresse au moment de la commande, alimentée par des événements, et n'appelle plus personne pour répondre. Il s'appuie sur l'event storming et sur l'historique des changements pour trouver les vraies frontières.
Signal d'alerteAjouter un cache ou une couche d'agrégation devant les quatre services, ou découper encore plus finement.
Question 2 · confirmé à senior
L'événement CommandeValidée est consommé par six équipes. Vous devez ajouter un champ et en renommer un autre. Comment faites-vous sans casser personne ?
Une bonne réponseLe schéma est dans un Schema Registry avec un mode de compatibilité, BACKWARD ou FULL selon les besoins. Ajouter un champ optionnel avec une valeur par défaut reste compatible. Un renommage se fait en deux temps : ajout du nouveau champ, ancien champ marqué déprécié et rempli pendant une période annoncée, puis retrait une fois les consommateurs migrés. Le contrat est décrit en AsyncAPI et les consommateurs ignorent les champs qu'ils ne connaissent pas.
Signal d'alerteChanger le schéma et prévenir par e-mail, ou créer un nouveau topic à chaque modification sans plan de migration.
Question 3 · senior
Une commande passe par cinq services qui réagissent chacun aux événements des autres. Plus personne ne sait dire où en est une commande. Que proposez-vous ?
Une bonne réponseUne chorégraphie devenue trop longue. Pour ce flux, il passe à une saga orchestrée : un orchestrateur qui garde l'état de chaque commande, envoie les commandes aux services, gère les délais et lance les compensations en cas d'échec. Un moteur comme Temporal ou Camunda, ou un orchestrateur maison avec un état persisté. Il garde la chorégraphie pour les réactions simples comme les notifications, et rend les statuts intermédiaires visibles au métier.
Signal d'alerteAjouter un service qui écoute tous les topics pour reconstituer l'état, ou revenir à une transaction distribuée en deux phases.
Question 4 · confirmé
Kafka garantit-il l'ordre des messages ? Pour une suite de mises à jour d'un même compte, que configurez-vous ?
Une bonne réponseL'ordre n'est garanti qu'à l'intérieur d'une partition. La clé du message est l'identifiant du compte, pour que tous ses messages aillent dans la même partition. Le producteur idempotent, actif par défaut depuis Kafka 3.0, évite doublons et inversions lors des nouvelles tentatives. Côté consommateur, une partition est traitée dans l'ordre, et un message envoyé vers un topic de nouvelle tentative casse l'ordre pour ce compte.
Signal d'alerte« Kafka garantit l'ordre » sans condition, ou une seule partition pour tout le topic sans parler de débit.
Question 5 · confirmé à senior
Quelles règles imposez-vous à tous les appels synchrones entre services ?
Une bonne réponseUn délai d'attente explicite sur chaque appel, plus court que celui de l'appelant. Des nouvelles tentatives seulement sur des appels idempotents, avec une attente croissante, un peu d'aléa et un budget limité. Un circuit breaker et une limite d'appels simultanés par dépendance, et une réponse dégradée prévue, comme une page produit sans recommandations. Une seule couche gère les nouvelles tentatives : la bibliothèque ou le mesh, pas les deux.
Signal d'alerteDes nouvelles tentatives à chaque couche, qui multiplient la charge sur un service déjà en difficulté. Aucun délai d'attente.
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
Questions fréquentes sur le recrutement d'un architecte microservices
Architecte microservices et architecte Kafka, est-ce le même poste ?
Non. L'architecte Kafka ou architecte data streaming conçoit et exploite la plateforme : dimensionnement du cluster, réplication, sécurité, connecteurs. L'architecte microservices et événementiel conçoit les flux métier qui l'utilisent : découpage des services, contenu des événements, cohérence entre services. Il doit connaître les garanties de Kafka sans forcément l'administrer. Si votre offre demande les deux, dites-le dans l'annonce et prévoyez des questions sur chaque partie.
Quelles compétences demander à un architecte événementiel ?
Un découpage par domaine, appuyé sur le DDD stratégique et l'event storming. La conception d'événements et l'évolution de leurs schémas. La cohérence des données entre services : outbox, sagas, consommateurs idempotents. Une connaissance précise d'au moins un broker, Kafka ou RabbitMQ, avec ses garanties de livraison et d'ordre. Enfin l'exploitation : traces à travers les messages, retard des consommateurs, files de lettres mortes et rejeu.
Quel test technique proposer à un architecte microservices ?
Une étude de cas courte vaut mieux qu'un exercice de code. Décrivez un monolithe et un objectif, par exemple rendre trois équipes autonomes, et demandez un découpage, les événements échangés et le traitement d'une panne. Vingt minutes suffisent pour voir si la personne raisonne par domaine ou par table, et si elle pense aux doublons, à l'ordre et au rejeu sans qu'on les lui souffle.
Un architecte microservices doit-il avoir travaillé avec Kubernetes ?
Il doit en comprendre les conséquences sur ses choix : déploiements progressifs, sondes de santé, mise à l'échelle, configuration par environnement, découverte des services. Il n'a pas à administrer un cluster si une équipe plateforme le fait. Méfiez-vous de l'inverse : un CV très riche en Kubernetes, Helm et Istio peut cacher un profil d'infrastructure qui n'a jamais découpé un domaine métier.
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.
