Angular côté front et OpenShift ou Kubernetes pour l'hébergement accompagnent souvent les offres de développeur Java Quarkus. Le quotidien ressemble à celui d'un développeur Spring Boot : des API REST, de la persistance avec Hibernate, des messages Kafka, des tests. La différence tient au moment où le travail se fait. Quarkus résout l'injection de dépendances et une partie de la configuration pendant le build, Micronaut génère ses métadonnées à la compilation, et les deux produisent un exécutable natif avec GraalVM.
Le CV pose deux pièges. Un profil Spring Boot passé par une formation Quarkus connaît les annotations, mais pas les conséquences du build natif ni du thread d'I/O de Vert.x. Un profil Quarkus récent cite le natif partout alors que l'application tournait en JVM. Demandez sur quel mode tournait la production, pourquoi, et ce qui a cassé au premier build natif.
Pour un poste confirmé, une question sur la frontière entre code bloquant et non bloquant situe vite le niveau. Pour un senior, ajoutez le diagnostic d'une image native qui échoue au démarrage et le choix entre JVM et natif selon la charge. Le PDF contient l'entretien complet sur six axes, avec un cas de 20 minutes.
Les briques d'une application Quarkus ou Micronaut
Quarkus et ses extensions
Le framework Java de Red Hat, en version 3, avec des branches LTS (3.40 en octobre 2026). Chaque besoin passe par une extension (REST, Hibernate, Kafka, OIDC) qui prépare son travail au build. Une bibliothèque Java ajoutée sans extension marche souvent en JVM et pose problème en natif.
ArC (injection CDI)
L'implémentation de l'injection de dépendances de Quarkus. Elle suit la norme CDI, analyse les beans au build et retire ceux qui ne servent pas. Les erreurs d'injection sortent à la compilation, et certaines habitudes Spring, comme les beans créés dynamiquement, ne passent pas.
Quarkus REST et Mutiny
Quarkus REST, l'ancien RESTEasy Reactive, sert les API. Selon la signature de la méthode, elle tourne sur le thread d'I/O de Vert.x ou sur un thread de travail. Mutiny fournit les types Uni (un résultat) et Multi (un flux). Beaucoup d'incidents de performance viennent d'un appel bloquant posé sur le mauvais thread.
Hibernate ORM avec Panache
La persistance, en mode classique ou réactif avec Hibernate Reactive. Panache allège les entités et les repositories. Les sujets habituels de JPA restent valables : chargement paresseux, requêtes N+1, transactions.
GraalVM native image et Mandrel
La compilation en exécutable natif : démarrage rapide et mémoire réduite, contre un build long et une analyse en monde fermé. Tout ce qui passe par la réflexion, un proxy ou une ressource doit être déclaré. Mandrel est la distribution de GraalVM que Red Hat utilise pour Quarkus.
MicroProfile (SmallRye)
Config, Health, Fault Tolerance, OpenAPI, Reactive Messaging : les spécifications MicroProfile que Quarkus implémente avec SmallRye. Elles couvrent la configuration par profil, les sondes Kubernetes, les retry et les circuit breakers, et la connexion à Kafka.
Dev Services et tests
En développement et en test, Quarkus démarre seul une base ou un Kafka dans des conteneurs. @QuarkusTest teste l'application en JVM, @QuarkusIntegrationTest teste l'artefact construit, exécutable natif compris.
Micronaut
L'alternative la plus proche, en version 5. L'injection et l'AOP sont générées à la compilation par des processeurs d'annotations, sans réflexion à l'exécution. Micronaut Data génère aussi ses requêtes à la compilation. Un bon développeur Quarkus s'y retrouve vite, et l'inverse est vrai.
Kubernetes et OpenShift
Les extensions génèrent l'image de conteneur et les manifestes de déploiement. Sur OpenShift, le build se fait souvent dans le cluster. Le mode natif change le dimensionnement des pods : moins de mémoire, mais un débit maximal parfois inférieur à celui de la JVM.
Quarkus s'est installé là où l'on déploie beaucoup de petits services sur Kubernetes ou OpenShift et où la mémoire de chaque pod se paie. Une partie des postes porte sur une reprise : une application Java EE ou Spring à porter, avec des bibliothèques qui ne passent pas en natif. Une autre partie est du développement neuf, souvent avec Kafka et PostgreSQL. Micronaut apparaît moins souvent dans les offres françaises. Les deux frameworks reposent sur le même principe, le travail fait au build, et un développeur passe de l'un à l'autre sans repartir de zéro. Le mode d'exécution réel en production, JVM ou natif, se vérifie en entretien : le CV le précise rarement.
Les points techniques à valider chez un développeur Quarkus
- Modèle d'exécution : thread d'I/O et threads de travail
- Programmation réactive avec Mutiny
- Image native GraalVM et réflexion
- Persistance Hibernate et Panache
- Configuration, MicroProfile et résilience
- Tests, Dev Services et déploiement Kubernetes
Cinq questions à poser sur Quarkus et le natif
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é
Un endpoint Quarkus REST renvoie un Uni et appelle à l'intérieur un client JDBC classique. Sous charge, tout le service ralentit. Que se passe-t-il ?
Une bonne réponseUne méthode qui renvoie un Uni tourne par défaut sur le thread d'I/O de Vert.x, et l'appel JDBC bloque ce thread : les autres requêtes attendent derrière. Les corrections possibles sont d'annoter la méthode @Blocking pour la passer sur un thread de travail, d'utiliser un client réactif (Hibernate Reactive, client réactif PostgreSQL), ou @RunOnVirtualThread à partir de Java 21. Un profil qui a vécu le problème cite l'avertissement de Vert.x sur un thread bloqué dans les logs.
Signal d'alerte« Le Uni rend l'appel asynchrone tout seul », ou augmenter la taille d'un pool sans savoir sur quel thread tourne la méthode.
Question 2 · senior
Le build natif passe, mais l'application plante au démarrage sur une ClassNotFoundException dans une bibliothèque de sérialisation. Comment cherchez-vous ?
Une bonne réponseL'image native est construite en monde fermé : une classe chargée par réflexion, par proxy dynamique ou comme ressource sans être détectée au build n'existe pas à l'exécution. Il enregistre la classe pour la réflexion (@RegisterForReflection ou fichier de métadonnées), vérifie s'il existe une extension Quarkus pour la bibliothèque, et lance l'agent de traçage de GraalVM sur l'application en JVM pour produire la configuration manquante. Il relance ensuite les tests d'intégration sur l'exécutable natif, pas seulement en JVM.
Signal d'alerteRepasser en JVM sans comprendre la cause, ou déclarer toutes les classes du projet en réflexion.
Question 3 · confirmé
JVM ou natif pour un service qui reçoit un trafic fort et régulier toute la journée ? Et pour une fonction qui démarre à la demande ?
Une bonne réponseLe natif gagne au démarrage et en mémoire : il convient à une fonction serverless, à une montée en charge rapide ou à beaucoup de petits pods. Pour un service chargé en continu, la JVM et son compilateur JIT atteignent souvent un meilleur débit une fois chauds, et le build reste plus court. Il ajoute le coût du build natif en CI et un débogage moins confortable, et tranche sur des mesures de démarrage, de mémoire et de débit faites sur les deux builds.
Signal d'alerte« Le natif est toujours plus rapide », sans distinguer le temps de démarrage du débit.
Question 4 · confirmé
Une propriété de configuration modifiée par variable d'environnement dans le déploiement n'a aucun effet. Quelle piste suivez-vous ?
Une bonne réponseCertaines propriétés Quarkus sont fixées au build : elles sont lues à la compilation et ne changent plus ensuite. La documentation les signale par un cadenas dans la référence de configuration. Il vérifie ensuite le nom de la variable (points remplacés par des underscores, majuscules), le profil actif (%dev, %prod) et l'ordre de priorité des sources de MicroProfile Config.
Signal d'alerteRedémarrer le pod plusieurs fois en espérant que la valeur passe, ou n'avoir jamais entendu parler des propriétés fixées au build.
Question 5 · confirmé
Vous lisez des commandes dans Kafka avec SmallRye Reactive Messaging, et chaque message déclenche une écriture en base. Comment évitez-vous de perdre ou de doubler une commande ?
Une bonne réponseLe message est acquitté après l'écriture, pas avant, ce qui donne une livraison au moins une fois. L'écriture doit donc être idempotente, avec une clé métier unique, car Kafka peut relivrer après un redémarrage ou un rééquilibrage. Les messages en échec partent vers un topic d'erreurs (stratégie dead-letter-queue du connecteur Kafka) au lieu de bloquer la partition. La méthode est @Blocking ou réactive selon le client de base utilisé.
Signal d'alerteUn acquittement automatique sans savoir à quel moment l'offset avance, ou aucune idée qu'un message peut arriver deux fois.
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
Recruter sur Quarkus : les questions fréquentes
Un développeur Spring Boot peut-il tenir un poste Quarkus ?
Oui, la plupart des notions passent : injection de dépendances, JPA, API REST, tests. L'écart porte sur le travail fait au build, sur le thread d'I/O de Vert.x et sur les contraintes du natif. Posez une question sur un appel bloquant dans une méthode qui renvoie un Uni, et une autre sur la réflexion en natif. Si la personne raisonne juste sans connaître les annotations, la montée en compétence porte sur des détails. Si elle ne voit pas le problème, prévoyez un accompagnement.
Faut-il exiger Micronaut en plus de Quarkus ?
Rarement. Les deux frameworks font le même pari : résoudre l'injection et la configuration à la compilation pour démarrer vite et passer en natif. Les annotations et les outils diffèrent, les réflexes restent les mêmes. Si votre projet est en Micronaut, demandez au candidat Quarkus comment il traiterait l'injection générée par processeurs d'annotations et les clients HTTP déclaratifs. Exigez Micronaut seulement si le poste démarre sur un existant complexe sans période de prise en main.
L'image native est-elle obligatoire sur un projet Quarkus ?
Non. Beaucoup d'applications Quarkus tournent en JVM en production et profitent quand même du démarrage rapide et de la consommation mémoire réduite. Le natif se justifie pour du serverless, des montées en charge brutales ou un grand nombre de petits pods. Pour le recrutement, cela change le niveau attendu : sur un projet en natif, la personne doit savoir corriger un échec de build et tester l'exécutable, pas seulement lancer la commande.
À quoi ressemble un bon test technique Quarkus ?
Un exercice d'une heure au plus, fait pendant l'entretien. Donnez un petit service avec un endpoint qui renvoie un Uni et appelle JDBC, un test @QuarkusTest à faire passer et une propriété de configuration qui ne s'applique pas. La personne corrige et commente à voix haute. Vous voyez en peu de temps si elle comprend le modèle d'exécution, la configuration fixée au build et les Dev Services.
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.
