Java 17 ou 21, Spring Boot, Kafka ou RabbitMQ, Docker, Kubernetes ou OpenShift, une CI GitLab et souvent Argo CD : presque toutes les offres de développeur Java Spring Boot microservices citent cette pile. Le travail consiste à faire évoluer des services qui s'appellent en REST et échangent des événements, puis à les exploiter quand l'un d'eux ralentit. Les questions d'entretien utiles partent de ces situations de production.
Les versions bougent vite. Spring Boot 4 est sorti en novembre 2025 avec Spring Framework 7, Jackson 3 et des mécanismes de nouvelle tentative intégrés. La branche 3.5 n'a plus de support open source depuis juin 2026, et beaucoup de services tournent encore en 3.x, parfois en 2.7. Côté Spring Cloud Netflix, Hystrix, Ribbon et Zuul ne sont plus maintenus depuis plusieurs années, Resilience4j et Spring Cloud Gateway les ont remplacés.
Le profil à éviter a découpé un monolithe en dix services qui partagent la même base et s'appellent en chaîne sans timeout. Demandez où passe la frontière d'un service, comment un appel se protège et comment deux équipes testent leur contrat. Le PDF ajoute 30 questions, un cas de 20 minutes et une grille de notation.
Spring Boot, Spring Cloud et les outils autour des services
Spring Boot 3 et 4
Le framework qui démarre un service Java avec sa configuration, son serveur web et ses dépendances. La version 4, sortie fin 2025, repose sur Spring Framework 7 et Jackson 3, et demande toujours Java 17 au minimum. Une montée de version 2.x vers 4 est un vrai chantier, utile à aborder en entretien.
Spring Cloud Gateway
Le point d'entrée des appels externes. Elle route chaque requête vers le bon service et applique des filtres communs : vérification du jeton, limitation de débit, CORS. Elle a pris la place de Zuul dans les architectures Spring.
Configuration externalisée (Spring Cloud Config, ConfigMaps)
La même image tourne en développement, en recette et en production. Les valeurs propres à chaque environnement viennent de variables, de ConfigMaps et Secrets Kubernetes ou d'un serveur Spring Cloud Config adossé à un dépôt Git. Les mots de passe ne doivent jamais être embarqués dans le JAR.
Resilience4j et la résilience de Spring Framework 7
Resilience4j fournit circuit breaker, nouvelles tentatives, limitation de débit et bulkhead, souvent via Spring Cloud Circuit Breaker. Spring Framework 7 ajoute @Retryable et @ConcurrencyLimit directement dans le framework pour les besoins simples. Hystrix, encore présent sur des CV, n'est plus maintenu.
Kafka ou RabbitMQ avec Spring
Spring for Apache Kafka et Spring AMQP servent à publier et consommer des événements entre services. Les questions portent sur la gestion des erreurs, les messages en double, l'ordre et la publication fiable après une écriture en base.
Spring Data JPA et une base par service
Chaque service possède ses tables, le plus souvent dans PostgreSQL, avec Spring Data JPA et Hibernate. Les autres services passent par son API ou ses événements. Un profil qui a connu une base partagée entre services sait expliquer ce que cela coûte.
Micrometer et OpenTelemetry
Micrometer mesure le service (latence, erreurs, JVM, pools) et Micrometer Tracing suit une requête d'un service à l'autre, avec un export OpenTelemetry. Spring Boot 4 propose un starter OpenTelemetry. Spring Cloud Sleuth, son prédécesseur, a disparu avec Spring Boot 3.
Docker, Kubernetes et Helm
Les services sont livrés en images Docker et déployés sur Kubernetes ou OpenShift, souvent avec des charts Helm et Argo CD. Le développeur règle les sondes de santé, la mémoire de la JVM par rapport aux limites du conteneur et l'arrêt progressif.
Tests : JUnit, Testcontainers, tests de contrat
JUnit et Mockito pour la logique, Testcontainers pour lancer un vrai PostgreSQL ou un vrai Kafka pendant les tests. Pact ou Spring Cloud Contract vérifient qu'un service fournisseur respecte ce que ses consommateurs attendent, avant la mise en production.
Le niveau attendu change surtout avec le périmètre. Un développeur confirmé fait évoluer un ou deux services, écrit des tests sérieux et sait lire une trace pendant un incident. Un senior conçoit le découpage, la cohérence entre services et la stratégie de tests de contrat, et accompagne les montées de version de Spring Boot. Le poste se rapproche du DevOps quand l'équipe gère elle-même ses déploiements sur Kubernetes, et s'en éloigne quand une équipe plateforme fournit les pipelines et l'observabilité. Les virtual threads de Java 21, activables dans Spring Boot par une propriété, commencent à remplacer le réactif pour tenir beaucoup d'appels simultanés. Demandez si la personne les a déjà utilisés en production et ce qu'elle a dû surveiller.
Les acquis à contrôler chez un développeur Spring Boot microservices
- Spring Boot : beans, configuration et transactions
- Découpage des services et propriété des données
- Résilience des appels synchrones
- Kafka ou RabbitMQ et idempotence
- Traçage distribué et métriques
- Tests de contrat et déploiement Kubernetes
Cinq incidents de microservices Spring Boot à faire analyser
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 · confirmé à senior
Le service Commande appelle le service Stock, qui répond en huit secondes depuis ce matin. Tous les threads du service Commande sont occupés. Que mettez-vous en place ?
Une bonne réponseUn délai d'attente explicite sur le client HTTP (RestClient, WebClient ou interface @HttpExchange), plus court que celui de l'appelant. Un circuit breaker Resilience4j qui coupe les appels quand le taux d'échec ou de lenteur dépasse un seuil, avec une réponse de repli prévue. Un bulkhead ou une limite d'appels simultanés pour que Stock ne consomme pas tous les threads. Des nouvelles tentatives seulement sur des appels idempotents, avec attente croissante et un peu d'aléa. Il cite parfois @Retryable et @ConcurrencyLimit, intégrés à Spring Framework 7, pour les cas simples.
Signal d'alerteAugmenter la taille du pool de threads ou le timeout. Des nouvelles tentatives sans limite, qui multiplient la charge sur un service déjà lent.
Question 2 · confirmé
Votre service enregistre une commande en base puis publie un événement dans Kafka. Il plante entre les deux. Que se passe-t-il, et comment l'évitez-vous ?
Une bonne réponseLa commande existe et l'événement est perdu, ou l'inverse selon l'ordre des opérations : c'est le problème de la double écriture. La correction classique est l'outbox transactionnelle : l'événement est écrit dans une table de la même base, dans la même transaction que la commande, puis publié par un processus séparé, ou lu dans le journal de la base par un outil de CDC comme Debezium. La publication peut alors arriver deux fois, donc le consommateur est idempotent.
Signal d'alerte« @Transactional couvre aussi Kafka. » Les transactions Kafka ne rendent pas l'écriture en base et l'envoi atomiques entre eux.
Question 3 · senior
Une commande doit réserver du stock puis déclencher un paiement : trois services, trois bases. Comment gardez-vous les données cohérentes sans transaction distribuée ?
Une bonne réponseUne saga : une suite d'étapes locales, chacune dans sa propre transaction, avec une action de compensation si une étape échoue (libérer le stock si le paiement est refusé). Elle est orchestrée par un service qui pilote les étapes, ou chorégraphiée par des événements. Les étapes sont idempotentes, les événements publiés via une outbox, et la commande passe par des statuts intermédiaires visibles. Il assume une cohérence à terme, et sait expliquer à un métier ce qu'il voit pendant les quelques secondes de transition.
Signal d'alerteUne transaction XA entre trois services, ou une base commune « pour simplifier ». Aucun plan si le paiement échoue après la réservation.
Question 4 · confirmé
Une méthode annotée @Transactional, appelée depuis une autre méthode de la même classe, ne démarre pas de transaction. Pourquoi ?
Une bonne réponseSpring applique @Transactional par un proxy placé devant le bean. Un appel interne passe par this et contourne le proxy, donc l'annotation est ignorée. Même chose pour une méthode privée. Corrections : déplacer la méthode dans un autre bean, utiliser TransactionTemplate pour une transaction programmatique, ou passer au tissage AspectJ. Il sait que le même mécanisme concerne @Async, @Cacheable et @Retryable.
Signal d'alerteAucune idée du proxy. Ajouter @Transactional sur toutes les méthodes « pour être sûr ».
Question 5 · confirmé
Une requête traverse la gateway puis quatre services, et un utilisateur signale une lenteur. Comment trouvez-vous le service en cause ?
Une bonne réponsePar le traçage distribué : Micrometer Tracing avec un export OpenTelemetry vers Tempo, Jaeger, Zipkin ou l'outil APM de l'équipe. Chaque service ajoute ses spans à la même trace, propagée par l'en-tête W3C traceparent, et l'identifiant de trace apparaît dans les logs. La trace montre quel appel prend le temps, et les métriques de latence par endpoint (p95, p99) confirment si le problème est général. Il sait que Spring Cloud Sleuth a été remplacé par Micrometer Tracing depuis Spring Boot 3.
Signal d'alerteOuvrir les logs de chaque service et comparer les horodatages à la main. Ne pas savoir comment l'identifiant de trace passe d'un service à l'autre.
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
Ce que l'on demande avant de recruter un développeur Java microservices
Spring Boot ou Spring Framework : faut-il exiger les deux ?
Spring Boot est une couche au-dessus de Spring Framework : il configure automatiquement ce que Spring Framework fournit (injection de dépendances, transactions, Spring MVC). Un développeur qui ne connaît que les annotations de Boot bloque vite sur un bean qui ne se crée pas ou une transaction ignorée. Pour un poste confirmé, vérifiez qu'il comprend les proxies, la portée des beans et la gestion des transactions, pas seulement les starters.
Un développeur Java qui n'a connu que des monolithes peut-il tenir un poste microservices ?
Oui, si les bases Spring sont solides et si le poste n'est pas senior. Ce qui lui manquera au début : les appels réseau qui échouent, les données réparties entre services, les messages en double et le traçage. Posez-lui les questions de résilience et de messagerie. Un candidat qui raisonne juste sur un timeout ou une outbox, même sans l'avoir pratiqué, apprend vite. Un senior, lui, doit avoir exploité des services en production.
Quel test technique proposer à un développeur Spring Boot ?
Un petit service à faire évoluer pendant une heure fonctionne bien : ajouter un endpoint avec sa validation et son test, protéger un appel vers un service lent, ou corriger un consommateur Kafka qui crée des doublons. Préparez le projet à l'avance pour que la personne ne perde pas de temps sur la configuration. Un exercice de ce type montre la façon de lire un code existant, ce que les exercices d'algorithmes ne montrent pas.
Spring Boot 3 ou 4 sur le CV : la version compte-t-elle ?
Elle compte moins que l'expérience des montées de version. Spring Boot 3 a imposé Java 17, les packages jakarta et une nouvelle configuration de Spring Security. Spring Boot 4 apporte Spring Framework 7 et Jackson 3. Un candidat qui a porté un service de 2.7 vers 3 ou 4 connaît les pièges des dépendances et des propriétés renommées. Demandez-lui ce qui a cassé et comment il l'a vu.
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.
