Sur les plateformes de missions, ces postes s'intitulent encore souvent « développeur Java J2EE » ou « Java JEE », même quand la pile réelle mélange Spring et un serveur d'applications. Le quotidien : corriger et faire évoluer une application livrée en EAR ou en WAR, lire des descripteurs XML, comprendre des transactions gérées par le conteneur et préparer des montées de version repoussées pendant des années. Les questions d'entretien pour un développeur Java EE portent donc sur cet existant.
Les noms ont changé. Java EE a été confié à la fondation Eclipse sous le nom Jakarta EE, et depuis Jakarta EE 9 les packages javax.* s'appellent jakarta.*. Jakarta EE 11, publié en juin 2025, demande Java 17, ajoute Jakarta Data et retire les Managed Beans. JSF est devenu Jakarta Faces. Côté serveurs, WebLogic 15.1.1 est certifié Jakarta EE 9.1 et JBoss EAP 8 implémente Jakarta EE 10.
Vérifiez surtout ce que la personne sait faire seule sur le serveur : lire ses logs, trouver une fuite de connexions dans un pool JDBC, expliquer pourquoi une transaction a été annulée. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.
Les spécifications et serveurs qu'un développeur Java EE fait tourner
EJB (Jakarta Enterprise Beans)
Les composants métier historiques de la plateforme : beans stateless, stateful et singleton, timers, et beans pilotés par message (MDB) pour JMS. Le conteneur gère les transactions et la concurrence. Dans beaucoup d'applications anciennes, la logique métier est écrite en EJB, et les erreurs de transaction viennent souvent de là.
CDI
L'injection de dépendances de Jakarta EE, avec ses portées et ses intercepteurs. La plateforme s'appuie de plus en plus sur CDI : Jakarta EE 11 a retiré les Managed Beans à son profit, et les transactions peuvent se déclarer avec @Transactional sur un bean CDI.
JPA (Jakarta Persistence) avec Hibernate ou EclipseLink
La couche d'accès aux données, configurée dans persistence.xml et branchée sur une datasource du serveur. Hibernate est fourni avec JBoss EAP et WildFly, EclipseLink est l'implémentation par défaut de WebLogic. Jakarta EE 11 ajoute Jakarta Data, des repositories déclaratifs proches de Spring Data.
JSF (Jakarta Faces) et PrimeFaces
Le framework d'interface côté serveur de nombreuses applications de gestion, presque toujours avec la bibliothèque de composants PrimeFaces. Les problèmes classiques : sessions qui grossissent, pages lentes, cycle de vie mal compris. PrimeFaces existe en version jakarta pour les serveurs récents.
JAX-RS et services SOAP
JAX-RS (Jakarta RESTful Web Services) expose les API REST. Les services SOAP (JAX-WS) restent fréquents entre applications anciennes, mais ne font plus partie de la plateforme Jakarta EE 11 et passent par une implémentation séparée comme Apache CXF ou Eclipse Metro.
JMS (Jakarta Messaging)
La messagerie entre applications, avec des files et des topics. Les messages sont lus par des MDB, sur des brokers comme ActiveMQ Artemis (intégré à JBoss), les JMS de WebLogic ou IBM MQ. Les questions portent sur les messages en erreur, l'ordre et les transactions XA.
Serveurs d'applications : WebLogic, WebSphere, JBoss EAP, WildFly, Payara
Ils hébergent l'application et fournissent datasources, files JMS, sécurité et transactions. WebLogic et WebSphere sont des produits commerciaux d'Oracle et d'IBM. JBoss EAP est la version supportée par Red Hat de WildFly, qui est libre. Demandez lequel la personne a administré, et à quel point.
Maven, packaging EAR/WAR et descripteurs
L'application est construite avec Maven et livrée en WAR ou en EAR, accompagnée de descripteurs XML : web.xml, ejb-jar.xml, weblogic.xml, jboss-deployment-structure.xml. Les conflits de bibliothèques entre l'application et le serveur sont une source d'incidents classique.
Outils de migration (OpenRewrite, Eclipse Transformer, MTA)
Pour passer de javax à jakarta ou changer de serveur : OpenRewrite réécrit le code source avec des recettes, Eclipse Transformer convertit des binaires, et Migration Toolkit for Applications de Red Hat analyse une application et liste ce qui doit changer. Un candidat qui a migré une application en cite au moins un.
Le poste mêle maintenance corrective, petites évolutions et chantiers de modernisation sur des applications parfois anciennes, souvent encore en Java 8. Le développeur intervient sur tout l'empilement : écrans JSF, EJB, requêtes JPA, messages JMS, configuration du serveur. L'administration du serveur peut revenir à une équipe d'exploitation, mais le développeur doit savoir lire ses logs et ses statistiques de pools. Les chantiers de migration prennent plusieurs formes : montée de version de Java, passage de javax à jakarta, changement de serveur (WebLogic ou WebSphere vers JBoss EAP, WildFly, Open Liberty) ou réécriture en Spring Boot. L'entretien doit distinguer un profil de maintenance d'un profil qui a mené l'un de ces chantiers de bout en bout.
Six points techniques à valider sur un profil Java EE
- EJB, CDI et transactions gérées par le conteneur
- JPA et accès aux données sous JTA
- JSF, Servlets et services REST ou SOAP
- JMS et beans pilotés par message
- Serveurs d'applications et packaging
- Migration vers Jakarta EE ou Spring Boot
Les questions à poser à un développeur Jakarta EE sur un existant en production
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 EJB stateless appelle un autre EJB qui lève une exception. La transaction est-elle annulée ?
Une bonne réponseCela dépend du type d'exception. Une exception système (RuntimeException non annotée, erreur du conteneur) annule la transaction et le conteneur détruit l'instance du bean. Une exception applicative, c'est-à-dire une exception vérifiée ou une exception annotée @ApplicationException, n'annule rien par défaut, sauf avec @ApplicationException(rollback = true) ou un appel à setRollbackOnly(). Il rappelle que l'attribut par défaut est REQUIRED, donc les deux beans partagent la même transaction.
Signal d'alerte« Toute exception annule la transaction. » Ou ne pas savoir qui démarre la transaction dans un EJB.
Question 2 · senior
Après une montée en charge, le serveur journalise des erreurs du type « no resources currently available » sur le pool JDBC. Comment cherchez-vous la cause ?
Une bonne réponseIl regarde d'abord les statistiques du pool dans la console ou en ligne de commande : connexions actives, attente, pic, échecs. Puis il cherche des connexions jamais rendues (JDBC manuel sans try-with-resources) avec les options de détection de fuite du serveur, qui donnent la pile d'appel de l'emprunt. Il prend des thread dumps pour voir les threads qui attendent une connexion ou une requête lente, et vérifie les transactions longues et le nombre maximal de sessions côté base. Il n'agrandit le pool qu'après, en restant sous la limite de la base.
Signal d'alerteDoubler la taille du pool et redémarrer, sans chercher pourquoi les connexions ne reviennent pas.
Question 3 · confirmé
Une page JSF met plusieurs secondes à s'afficher et la session HTTP grossit à chaque clic. Que regardez-vous ?
Une bonne réponseLa portée des beans : un bean @SessionScoped qui garde de grosses listes, au lieu d'un @ViewScoped ou @RequestScoped. L'enregistrement de l'état des vues (côté serveur ou client) et le nombre de vues gardées en session. Les getters appelés plusieurs fois par le cycle de vie JSF et qui lancent une requête en base à chaque appel. Pour une grande table PrimeFaces, le chargement paresseux (LazyDataModel) au lieu de tout charger en mémoire.
Signal d'alerteAugmenter la mémoire du serveur, ou accuser le navigateur.
Question 4 · confirmé
Un MDB lève une exception chaque fois qu'il lit le même message. Que se passe-t-il, et comment évitez-vous qu'il bloque la file ?
Une bonne réponseLa transaction est annulée, le message revient dans la file et repart vers le MDB, en boucle : un message empoisonné. Il configure sur la destination un nombre maximal de tentatives, un délai entre elles et une file d'erreur (error destination dans WebLogic, dead letter address dans ActiveMQ Artemis sous JBoss). Il lit la propriété JMSXDeliveryCount pour tracer les relivraisons, et surveille la file d'erreur avec une procédure de rejeu.
Signal d'alerteAttraper l'exception et ne rien faire, ce qui perd le message sans trace. Ou purger la file à la main.
Question 5 · senior
L'application démarre sous WildFly sur votre poste, mais lève une ClassCastException sur le serveur WebLogic de recette. Où cherchez-vous ?
Une bonne réponseUn conflit de chargeurs de classes : une bibliothèque embarquée dans WEB-INF/lib (une API JPA, un parseur XML, Jackson) existe aussi dans le serveur, et la même classe est chargée deux fois par deux chargeurs différents. Il lance mvn dependency:tree, passe en scope provided ce que le serveur fournit, et règle la priorité des classes de l'application : prefer-application-packages ou prefer-web-inf-classes dans weblogic.xml, exclusions dans jboss-deployment-structure.xml côté JBoss. Il compare aussi les versions de Java et des API des deux serveurs.
Signal d'alerte« Ça marche chez moi », puis copier des JAR au hasard dans le répertoire lib du domaine.
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
Java EE, J2EE, Jakarta EE : les questions des recruteurs
J2EE, Java EE, Jakarta EE : parle-t-on du même profil ?
Oui, ce sont trois noms successifs de la même plateforme. J2EE date des années 2000, Java EE a suivi, puis Oracle a confié la plateforme à la fondation Eclipse, qui l'a renommée Jakarta EE. Sur les offres, « Java J2EE » désigne souvent un développeur Java côté serveur au sens large, parfois sur Spring. Précisez dans l'annonce les briques réelles : EJB, JSF, serveur d'applications, ou Spring Boot.
Un développeur Spring Boot peut-il reprendre une application EJB ?
Oui, avec un temps d'adaptation. Les notions de base sont proches : injection de dépendances, transactions déclaratives, JPA. Ce qui change : le serveur d'applications, ses datasources et ses chargeurs de classes, les règles d'annulation des transactions EJB, JSF et JMS. Pour un poste centré sur la maintenance d'un existant lourd, privilégiez un profil qui a déjà travaillé sur un serveur d'applications. Pour une migration vers Spring Boot, la double compétence est un atout.
Comment évaluer un profil Java EE sans long test technique à la maison ?
Préparez un petit projet qui démarre sur WildFly ou Payara, avec un défaut réel : une transaction qui ne s'annule pas, une LazyInitializationException, un MDB qui boucle sur un message. Donnez une heure pour trouver et corriger, en commentant à voix haute. Vous voyez la façon de lire une pile d'appel et des logs serveur, ce qui compte plus sur ce poste que l'écriture d'un code neuf.
Faut-il exiger l'expérience du serveur d'applications utilisé chez vous ?
Pour un poste où le développeur configure et dépanne le serveur, oui, car les consoles, les scripts (WLST, jboss-cli) et les descripteurs diffèrent d'un produit à l'autre. Pour un poste centré sur le code, l'expérience d'un autre serveur se transpose vite. Les concepts restent les mêmes : datasources, JNDI, files JMS, chargeurs de classes. Vérifiez surtout que la personne a déjà diagnostiqué un incident sur un serveur, quel qu'il soit.
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.
