Pour préparer les questions d'entretien d'un développeur Pega, partez du case management. Le développeur modélise des case types en stages et en étapes, range ses règles dans une hiérarchie de classes et de rulesets, charge les données par des data pages et appelle les systèmes voisins en REST ou en SOAP. Les postes de run ajoutent les traitements de fond, l'analyse de performance et les montées de version.
Les offres demandent souvent la certification System Architect (CSA) ou Senior System Architect (CSSA), parfois Lead System Architect (LSA) pour les postes d'architecte. Les examens actuels portent sur Infinity '25, alors que beaucoup d'applications tournent encore en 8.x ou en '23. Un CV peut aligner les certifications et n'avoir travaillé qu'en interface traditionnelle. Constellation, l'interface par défaut des nouvelles applications, change la manière de construire les écrans et oblige à remonter de la logique dans le modèle.
Précisez avant l'entretien si le poste est en build ou en maintenance, et sur quelle version. Un développeur de run doit savoir lire un Tracer et un rapport PAL. Un développeur de projet neuf doit connaître Constellation et l'API DX. Le cas pratique du PDF suit une réclamation client de bout en bout.
Règles, cases et outils du développeur Pega
Case types, stages et étapes
Un dossier Pega (case) suit un cycle de vie découpé en stages, eux-mêmes faits d'étapes et de processus. Les chemins d'exception passent par des alternate stages. C'est la première chose à faire dessiner en entretien : un bon profil part du cycle de vie avant de parler d'écrans.
Classes, rulesets et résolution de règles
Les règles sont rangées dans une hiérarchie de classes (organisation, division, unité, puis Work- et Data-) et dans des rulesets versionnés. À l'exécution, Pega choisit la règle à appliquer selon la classe, la version et les circonstances. Comprendre ce mécanisme sépare un développeur autonome d'un débutant.
Data pages et modèle de données
Les data pages chargent les données à la demande, depuis la base ou une API, et les gardent en mémoire selon une portée (thread, requestor ou node) et une règle de rafraîchissement. Un mauvais réglage multiplie les appels aux systèmes voisins.
Data transforms, decision tables et activités
Les data transforms copient et calculent des valeurs, les decision tables et decision trees portent les règles métier, les declare expressions recalculent automatiquement. Les activités, proches du code, sont réservées aux cas qu'aucune autre règle ne couvre et signalées par les guardrails.
Connect REST, Service REST et API DX
Pega appelle d'autres systèmes par des règles Connect REST ou SOAP, souvent comme source d'une data page. Il expose ses dossiers par Service REST ou par l'API DX, qui permet à un autre front de créer et faire avancer des cases.
Constellation et interface traditionnelle
Constellation est l'interface par défaut des applications récentes : des vues configurées, un design system commun, des composants React quand il faut aller plus loin. Les applications plus anciennes utilisent l'interface traditionnelle, avec des sections, UI Kit ou Theme Cosmos. Demandez sur laquelle la personne a travaillé.
Job schedulers et queue processors
Les traitements de fond (relances, imports, envois) passent par des job schedulers et des queue processors, qui ont remplacé les agents. Ils tournent sur des nœuds dédiés. En maintenance, une grande partie des incidents se trouve ici.
Tracer, PAL et Pega Diagnostic Center
Le Tracer suit l'exécution règle par règle, le Performance Analyzer mesure une interaction, Pega Diagnostic Center regroupe les alertes de production. Un développeur de run qui ne les utilise pas cherche à l'aveugle.
Branches, Deployment Manager et PegaUnit
Le travail en équipe passe par des branches de rulesets fusionnées après revue. Deployment Manager empaquette l'application, lance les tests PegaUnit et les contrôles de guardrails, puis déploie d'un environnement à l'autre, sur Pega Cloud ou sur une infrastructure propre.
On trouve le développeur Pega chez les intégrateurs partenaires de Pegasystems et dans les grandes organisations qui ont construit sur la plateforme leurs applications de gestion de dossiers et de relation client. Une partie des missions porte sur la maintenance d'applications en 8.x ou en Infinity '23, avec incidents, dette technique et montées de version. L'autre partie porte sur des applications neuves en Constellation, parfois amorcées avec Pega Blueprint, l'outil de conception assisté par IA de l'éditeur. Les offres d'architecte ajoutent Kubernetes, les pipelines de livraison et l'authentification OIDC ou SAML.
Ce qu'un développeur Pega doit maîtriser seul
- Conception de case types
- Classes, rulesets et résolution de règles
- Data pages et intégrations REST
- Traitements de fond et performance
- Constellation et API DX
- Branches, tests et livraison
Questions techniques pour un développeur Pega
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é
Une data page charge la liste des agences depuis une API à chaque ouverture de dossier. Que changez-vous ?
Une bonne réponseLa portée et la stratégie de rafraîchissement. Une liste de référence commune à tous passe en portée node, rechargée si elle a plus de quelques heures. Une donnée propre à l'utilisateur va en requestor, une donnée propre au dossier en thread. La réponse de l'API est mappée par un data transform de réponse, avec une gestion d'erreur sur la source. Si la liste dépend d'un critère, la data page devient paramétrée.
Signal d'alerteAppeler le connecteur depuis une activité à chaque ouverture, ou copier toute la liste dans chaque dossier.
Question 2 · confirmé
Vous modifiez une règle et rien ne change en recette. Comment le diagnostiquez-vous ?
Une bonne réponseLa résolution de règles : la classe où la règle a été enregistrée par rapport à la classe du dossier, le ruleset et sa version dans la pile de l'application de l'utilisateur, la disponibilité de la règle (bloquée, retirée), une version circonstanciée qui prend le pas, une branche pas encore fusionnée. La personne utilise le Tracer ou l'outil d'analyse de la résolution pour voir quelle règle est réellement exécutée.
Signal d'alerte« Je vide le cache et je redémarre le serveur », ou enregistrer la règle dans un autre ruleset jusqu'à ce que ça marche.
Question 3 · junior à confirmé
On vous demande une activité pour copier dix propriétés d'un objet de données vers le dossier. Que proposez-vous ?
Une bonne réponseUn data transform, plus lisible, plus rapide à maintenir et sans avertissement des guardrails. L'activité reste un dernier recours, pour une logique qu'aucune autre règle ne couvre. Si une valeur doit se recalculer quand une autre change, une declare expression. La personne cite les guardrails et le score de conformité de l'application.
Signal d'alerteUne activité avec des étapes Property-Set, ou une étape Java pour aller plus vite.
Question 4 · confirmé
Des milliers de dossiers doivent être relancés par e-mail chaque nuit. Avec quoi le faites-vous ?
Une bonne réponseUn job scheduler qui sélectionne les dossiers chaque nuit et place un élément par dossier dans un queue processor, qui envoie les relances en parallèle et rejoue les échecs. La personne sait que les agents sont l'ancien mécanisme, remplacé par ces deux règles, et qu'il faut des nœuds dédiés aux traitements de fond. Quand la relance dépend du délai de chaque dossier, un SLA peut suffire.
Signal d'alerteUne seule activité qui boucle sur tous les dossiers dans un même requestor, ou un nouvel agent avancé.
Question 5 · senior
Une application en interface traditionnelle doit passer sur Constellation. Qu'est-ce qui ne se transpose pas tel quel ?
Une bonne réponseLes sections sur mesure, le HTML et le JavaScript ajoutés, les contrôles personnalisés et les activités appelées depuis l'interface. Constellation affiche des vues configurées dans App Studio, communique par l'API DX et repose sur un design system commun. Une partie de la logique remonte dans le modèle (data pages, data transforms, validations) et un besoin d'affichage particulier passe par un composant Constellation DX en React. La personne propose de commencer par un case type à faible personnalisation.
Signal d'alerte« On convertit les sections automatiquement », ou ne connaître Constellation que de nom.
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
Développeur Pega : réponses pour le recruteur
CSA, CSSA, LSA : quelle certification Pega demander ?
La Certified Pega System Architect (CSA) correspond à un développeur qui configure des cases sous encadrement. La Senior System Architect (CSSA), qui suppose la CSA, vise un développeur autonome et revient le plus souvent dans les offres de postes confirmés. La Lead System Architect (LSA) concerne les architectes qui conçoivent l'application et tranchent les choix techniques. Vérifiez la version de l'examen : un examen récent porte sur Infinity '25.
Quelles différences entre un développeur Pega de build et un développeur de run ?
En build, le développeur conçoit les case types, le modèle de données et les écrans, désormais souvent en Constellation. En run, il traite les incidents, lit des Tracer et des rapports PAL, débloque des queue processors et réduit la dette technique. Les deux partagent la résolution de règles et les data pages. Un profil de run qui n'a jamais touché Constellation reste pertinent sur une application traditionnelle, moins sur un projet neuf.
Quel exercice pratique proposer à un développeur Pega ?
Le test technique se fait sur un environnement de formation Pega ou au tableau, en direct. Demandez de dessiner un case type à partir d'un besoin court, puis de commenter une capture de Tracer ou une règle mal placée. Pour un poste de run, partez d'un incident réel anonymisé. Une heure suffit pour voir si la personne raisonne en règles, en classes et en données.
Un développeur Java peut-il devenir développeur Pega ?
Oui, et c'est un parcours fréquent. Il apporte la rigueur sur les intégrations, la performance et les tests. Il doit en revanche désapprendre le réflexe de tout écrire en code : dans Pega, une activité ou une étape Java est un dernier recours, signalé par les guardrails. La CSA est une première étape, la CSSA marque l'autonomie. En entretien, vérifiez qu'il ne cherche pas à contourner la plateforme.
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.
