Ce qu'un développeur Apache Camel doit savoir expliquer en entretien

Lire une file Artemis ou un topic Kafka, transformer le message, appeler une API ou déposer un fichier, et ne rien perdre en route : les questions d'entretien pour un développeur Apache Camel portent sur ces routes qui tournent en production. Le framework applique les patterns d'intégration (EIP) en Java, XML ou YAML, et se déploie aujourd'hui sur Spring Boot ou Quarkus, souvent dans Kubernetes.

Camel apparaît sur beaucoup de CV au milieu d'une liste Java. Certains candidats ont surtout maintenu des routes écrites par d'autres, sur Camel 2 ou Red Hat Fuse. D'autres ont conçu la gestion des erreurs, l'idempotence et les tests. La différence s'entend vite quand on demande ce que devient un message pendant qu'une API est en panne.

Vérifiez aussi la version. Camel 4 demande Java 17, a basculé sur jakarta et a retiré plusieurs composants. Un candidat qui a mené cette migration sait où se cachent les surprises. Le PDF contient un cas de 20 minutes sur des commandes envoyées vers un ERP par SFTP.

Les briques qu'un développeur Camel assemble

Apache Camel

Le framework open source de la fondation Apache. Une route décrit un flux : une entrée, des étapes de transformation ou de routage, une ou plusieurs sorties. Il fournit plusieurs centaines de composants (fichiers, JMS, Kafka, HTTP, SQL, SFTP...). En octobre 2026, la version courante est la 4.23, et les versions à support long sont la 4.18 et la 4.22.

Enterprise Integration Patterns

Le vocabulaire commun des flux : routeur selon le contenu, splitter, agrégateur, enrichissement, consommateur idempotent, canal de lettres mortes. Camel les fournit tous. Un développeur expérimenté sait lequel utiliser et comment le régler pour qu'il tienne un redémarrage.

Spring Boot et Quarkus

Les deux socles d'exécution courants. Camel Spring Boot suit les versions de Camel, Camel Quarkus a ses propres versions et permet une compilation native qui démarre vite et consomme peu de mémoire. Les routes s'écrivent de la même façon sur l'un ou l'autre.

ActiveMQ Artemis et JMS

Le broker de messages le plus souvent associé à Camel, successeur d'ActiveMQ Classic. Il apporte files persistantes, transactions, DLQ et groupes de messages pour garder l'ordre. Interrogez la personne sur le rejeu et l'ordre des messages.

Apache Kafka

Présent dans une bonne partie des offres d'intégration. Le composant Kafka de Camel lit et écrit des topics, avec une gestion des offsets qu'il faut régler à la main pour ne pas perdre de message quand un traitement échoue.

REST DSL et OpenAPI

Camel sait exposer des API REST et en appeler. Le contrat OpenAPI peut être écrit d'abord ou généré depuis les routes. Sur ce point, le poste rejoint celui d'un développeur d'API, avec la validation des entrées et des codes d'erreur justes.

Red Hat Fuse et le build Red Hat d'Apache Camel

Fuse a longtemps été la distribution supportée de Camel, souvent sur Karaf avec des routes en XML Blueprint. Red Hat propose aujourd'hui un build d'Apache Camel pour Spring Boot et Quarkus. Beaucoup de missions consistent à sortir de Fuse 7.

Camel K, Camel JBang et Kaoto

Camel K fait tourner des routes directement dans Kubernetes. Le projet Apache continue, mais le support Red Hat de Camel K 1.10 a pris fin en juin 2025. Camel JBang lance une route depuis un simple fichier pour prototyper, et Kaoto la dessine dans un éditeur visuel.

Outils de test

Le support de test de Camel (MockEndpoint, AdviceWith, NotifyBuilder) remplace les systèmes externes dans les tests unitaires. WireMock simule les API, Testcontainers démarre de vrais brokers ou serveurs SFTP. Un développeur sans tests de routes livre des flux fragiles.

Le développeur Camel travaille dans une équipe d'intégration ou dans une équipe Java qui possède ses propres flux. Les offres associent Camel à Spring Boot, Kafka, RabbitMQ ou ActiveMQ, Docker et Kubernetes, et parfois à un autre outil d'intégration comme webMethods ou Apigee. Une partie des postes porte sur du neuf, une autre sur la reprise de routes Fuse ou Camel 2 à migrer vers Camel 4. Précisez dans l'offre la version de Camel en place, le socle (Spring Boot ou Quarkus), les brokers utilisés et la part de migration, car un profil qui n'a connu que la maintenance de routes existantes n'aura pas les mêmes réflexes qu'un profil qui les a conçues.

Les compétences Camel à valider avant une offre

• Routes Camel et patterns d'intégration (EIP)
• Messagerie JMS et Kafka
• Gestion des erreurs et rejeu
• Idempotence et transactions
• Tests automatisés des routes
• Déploiement Spring Boot, Quarkus et Kubernetes

Cinq questions sur les routes, les erreurs et les tests

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.

1. Question 1 · confirmé

   Une route lit une file JMS et appelle une API REST qui tombe pendant vingt minutes. Que deviennent les messages, et comment les rejouez-vous ?

   Une bonne réponseLa réponse sépare deux mécanismes. La redelivery de Camel rejoue l'appel en mémoire, avec un nombre d'essais et un délai qui s'allonge, mais elle bloque le consommateur pendant ce temps. La redelivery du broker passe par une route transactionnelle : le message revient dans la file, Artemis compte les tentatives puis l'envoie dans sa DLQ. Pour une panne de vingt minutes, le candidat laisse le broker garder les messages ou suspend la route, plutôt que d'enchaîner les essais. Il distingue aussi les erreurs techniques (503, connexion refusée), qu'on rejoue, des erreurs fonctionnelles (400), envoyées directement en DLQ avec la cause en en-tête.

   Signal d'alerte« Je mets un try/catch dans un Processor et je logge l'erreur. » Des essais infinis sans délai, ou aucune idée de l'endroit où se trouve le message pendant les tentatives.

2. Question 2 · confirmé

   Les lignes d'une commande arrivent en messages séparés, et le système cible attend la commande complète. Comment configurez-vous l'agrégateur ?

   Une bonne réponseUne expression de corrélation sur le numéro de commande, une AggregationStrategy qui assemble les lignes, et des conditions de fin : le nombre de lignes annoncé dans un en-tête (completionSize ou completionPredicate), plus un completionTimeout en filet de sécurité. Le candidat prévoit un dépôt d'agrégation persistant, en base par exemple, pour ne pas perdre les commandes en cours au redémarrage. Il dit aussi ce qu'il fait d'une commande incomplète au bout du délai : une route à part, une alerte, pas un envoi silencieux.

   Signal d'alerteUn agrégateur en mémoire sans délai de fin, ou une HashMap statique remplie dans un Processor.

3. Question 3 · confirmé

   Le même fichier ou le même message arrive deux fois. Comment évitez-vous de créer deux factures ?

   Une bonne réponseLe motif Idempotent Consumer, avec une clé tirée du métier (numéro de facture) ou, pour un fichier, le nom et une empreinte du contenu. Le dépôt des clés est persistant et partagé entre instances : base de données, Infinispan, Redis ou Kafka. Le candidat sait régler le comportement en cas d'échec (retirer la clé pour autoriser un nouvel essai) et, pour le composant file, combine idempotent, readLock et déplacement des fichiers traités.

   Signal d'alerteUn dépôt en mémoire alors que l'application tourne sur plusieurs pods, ou « le broker garantit l'unicité ».

4. Question 4 · junior à confirmé

   Comment testez-vous une route qui lit un SFTP et appelle une API externe, sans avoir ces systèmes sous la main ?

   Une bonne réponseDes tests JUnit 5 avec le support de test de Camel (camel-test-spring-junit5 ou les tests Quarkus). AdviceWith remplace l'entrée de la route (replaceFromWith) et intercepte les appels sortants (weaveByToUri, mockEndpointsAndSkip). Des MockEndpoint vérifient le nombre de messages et leur contenu, NotifyBuilder attend la fin d'un traitement asynchrone. Les chemins d'erreur sont testés comme le reste. Pour l'intégration, WireMock simule l'API et Testcontainers démarre un vrai serveur SFTP ou un broker.

   Signal d'alerteDes tests uniquement à la main en recette avec Postman, ou des Thread.sleep pour attendre la fin de la route.

5. Question 5 · senior

   Vous reprenez des routes Red Hat Fuse 7 écrites en XML Blueprint sur Karaf. Comment les amenez-vous sur Camel 4 avec Spring Boot ou Quarkus ?

   Une bonne réponseCamel 4 demande Java 17 au minimum, passe de javax à jakarta et s'appuie sur Spring Boot 3. Le support OSGi et Blueprint ne fait plus partie du projet principal (il vit dans le sous-projet Camel Karaf). Le candidat commence par un inventaire des routes et des composants, vérifie dans le guide de migration ceux qui ont disparu (camel-rabbitmq, camel-cdi, camel-vm...) et leur remplaçant, puis réécrit les routes en Java DSL, XML ou YAML. La configuration sort dans des propriétés par environnement. Il écrit des tests sur l'existant avant de migrer, pour comparer les sorties, et avance route par route.

   Signal d'alerte« Je change la version dans le pom. » Aucune mention de jakarta, de Java 17 ou des composants retirés.

Recruter un développeur Apache Camel : les questions fréquentes

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.