Un développeur PL/SQL Oracle passe ses journées dans des packages : calculs de primes ou de commissions, alimentation d'un infocentre, contrôles avant envoi d'un fichier réglementaire. Il écrit le SQL, l'enveloppe dans des procédures, programme les traitements de nuit et répond quand l'un d'eux déborde sur la matinée. Selon le poste, il maintient aussi des écrans Oracle Forms ou développe sous APEX. On le trouve beaucoup chez les éditeurs, les banques, les assureurs et les ESN qui les servent.
Les CV se ressemblent : PL/SQL, Oracle 19c, Toad, Unix, parfois Forms. La différence se fait sur trois habitudes. Le bon profil écrit un seul MERGE là où d'autres écrivent une boucle. Il lit le plan d'exécution réel avant de toucher à un index. Il laisse remonter une erreur au lieu de l'étouffer dans un WHEN OTHERS.
Les cinq premières questions de la page sont accompagnées de la réponse attendue et de ce qui doit vous alerter. Le PDF couvre l'entretien entier : 30 questions sur six axes, un cas de 20 minutes sur un calcul nocturne de commissions et une grille de 1 à 4.
L'environnement Oracle d'un développeur PL/SQL
PL/SQL et packages
Le langage procédural d'Oracle. Le code est rangé dans des packages : une spécification qui expose les procédures et fonctions utilisables, un corps qui contient l'implémentation. Un package bien découpé sert d'API d'écriture sur les tables métier. Demandez comment la personne organise un package et ce qu'elle y met en public.
SQL Oracle
La plus grande partie de la performance se joue ici. MERGE, fonctions analytiques (ROW_NUMBER, LAG, SUM OVER), requêtes hiérarchiques avec CONNECT BY ou WITH récursif. Un développeur PL/SQL solide écrit d'abord une requête et ne passe au procédural que lorsque la logique l'exige.
BULK COLLECT et FORALL
Les deux instructions qui traitent les lignes par paquets au lieu d'une à une. BULK COLLECT lit un lot dans une collection, FORALL écrit le lot en un seul échange avec le moteur SQL. Sur un batch de plusieurs millions de lignes, l'écart se compte en heures.
Plans d'exécution et statistiques
DBMS_XPLAN affiche le chemin choisi par l'optimiseur pour une requête, DBMS_STATS tient à jour les statistiques sur lesquelles il s'appuie. AWR, ASH et SQL Monitor donnent l'historique, mais dépendent des packs Diagnostics et Tuning, des options payantes que toutes les bases n'ont pas.
Batchs et ordonnancement
Les traitements de nuit sont lancés par DBMS_SCHEDULER ou par un ordonnanceur d'entreprise (Control-M, VTOM, $Universe), souvent via des scripts shell sous Unix ou Linux. Les fichiers entrent par SQL*Loader ou par des tables externes. La reprise après échec est la question à poser.
Oracle Forms, Reports et APEX
Forms et Reports font tourner beaucoup d'applications de gestion anciennes, encore maintenues chez des éditeurs et dans l'administration. APEX sert à construire des applications web directement sur la base, avec du SQL et du PL/SQL. Ne les exigez que si le poste les utilise vraiment.
Versions d'Oracle Database
La 19c reste la version la plus répandue en production. Oracle a renommé en octobre 2025 sa version 23ai en Oracle AI Database 26ai, qui apporte notamment le type BOOLEAN en SQL et les vecteurs. Les sujets de l'entretien restent les mêmes, mais un candidat à jour connaît les nouveautés de la version du poste.
Outillage de développement
SQL Developer ou Toad pour écrire et déboguer, Git pour versionner le code, utPLSQL pour les tests unitaires, Liquibase ou Flyway pour les scripts de livraison. Beaucoup d'équipes livrent encore des scripts à la main : demandez comment ils sont rejoués d'un environnement à l'autre.
Le poste change selon l'employeur. Chez un éditeur, le développeur PL/SQL fait évoluer un progiciel dont la logique métier vit dans la base, avec des livraisons chez de nombreux clients. Dans une banque ou une assurance, il tient des batchs de calcul et des chaînes réglementaires où un retard de nuit se voit le lendemain matin. En ESN, il arrive sur un code existant, parfois ancien, qu'il doit comprendre avant de le modifier. Les projets de migration vers PostgreSQL ouvrent aussi des missions où il faut lire le PL/SQL pour le convertir. Les certifications Oracle (OCA, OCP Developer) attestent les bases du langage, l'entretien vérifie la pratique sur des volumes réels.
Les savoir-faire PL/SQL à contrôler
- SQL ensembliste et fonctions analytiques
- Packages, curseurs et gestion des exceptions
- Traitements de masse avec BULK COLLECT et FORALL
- Lecture des plans d'exécution et optimisation
- Transactions, verrous et triggers
- Tests, livraison et reprise des batchs
Batchs, triggers, plans : cinq questions de développeur PL/SQL
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 batch PL/SQL parcourt deux millions de lignes une par une et met trois heures à tourner. Que changez-vous en premier ?
Une bonne réponseD'abord, voir si un seul ordre SQL suffit : un INSERT ... SELECT ou un MERGE fait le travail en une passe, sans boucle. Si la logique exige du PL/SQL, un BULK COLLECT avec une clause LIMIT (quelques milliers de lignes par paquet) puis un FORALL pour l'écriture, ce qui réduit les allers-retours entre les moteurs SQL et PL/SQL. SAVE EXCEPTIONS garde les lignes en erreur sans arrêter le paquet. La personne mesure avant et après, sur un volume réaliste.
Signal d'alerteUn COMMIT à chaque ligne « pour ne pas saturer les undo », un BULK COLLECT sans LIMIT qui charge deux millions de lignes en mémoire de session, ou « on ajoute un index » sans avoir regardé où passe le temps.
Question 2 · confirmé
Un trigger FOR EACH ROW lève ORA-04091, table en mutation. D'où vient l'erreur et comment la corrigez-vous ?
Une bonne réponseLe trigger ligne interroge ou modifie la table sur laquelle il est posé, alors qu'elle est en cours de modification. Les corrections propres : un compound trigger qui collecte les identifiants au niveau ligne et fait le contrôle dans la section AFTER STATEMENT, ou sortir la règle du trigger pour la placer dans le package qui sert d'API d'écriture, ou une contrainte déclarative si la règle s'y prête.
Signal d'alertePRAGMA AUTONOMOUS_TRANSACTION dans le trigger pour faire taire l'erreur. Le trigger lit alors des données qui ne tiennent pas compte de la modification en cours et la règle devient fausse.
Question 3 · junior à confirmé
Dans un package hérité, vous trouvez WHEN OTHERS THEN NULL à la fin de plusieurs procédures. Que faites-vous ?
Une bonne réponseIl retire ce bloc ou le remplace. L'erreur est journalisée avec SQLCODE, SQLERRM et DBMS_UTILITY.FORMAT_ERROR_BACKTRACE pour retrouver la ligne fautive, puis relancée avec RAISE. Les erreurs attendues (NO_DATA_FOUND sur un SELECT INTO, une règle métier violée) sont traitées par leur nom ou par RAISE_APPLICATION_ERROR avec un code entre -20000 et -20999. Le journal passe par une procédure en transaction autonome, qui survit au rollback.
Signal d'alerteGarder le bloc « pour que le batch ne plante pas ». L'erreur disparaît, la transaction continue avec des données incomplètes et personne ne sait ce qui a échoué.
Question 4 · senior
Après une livraison en journée, les applications reçoivent ORA-04068, l'état des packages a été effacé. Qu'est-ce qui s'est passé, et comment l'éviter ?
Une bonne réponseLe package recompilé contient des variables globales, donc un état propre à chaque session. Toute session qui l'avait déjà utilisé perd cet état au premier appel suivant. Pistes : limiter les variables globales de package, séparer spécification et corps pour ne recompiler que le corps quand le contrat ne change pas, livrer hors charge, ou utiliser l'edition-based redefinition pour faire coexister l'ancienne et la nouvelle version.
Signal d'alerteNe pas savoir qu'une variable déclarée dans un package vit pendant toute la session, ou proposer de redémarrer les serveurs d'application à chaque livraison comme seule solution.
Question 5 · confirmé
Une requête dans un package prend 40 secondes en production et une seconde sur votre poste. Comment cherchez-vous la cause ?
Une bonne réponseIl récupère le plan réellement exécuté avec DBMS_XPLAN.DISPLAY_CURSOR et le format ALLSTATS LAST, puis compare lignes estimées et lignes réelles à chaque étape. Il regarde les statistiques des tables (DBMS_STATS), les valeurs des variables de liaison au moment de la compilation, les conversions implicites (un VARCHAR2 comparé à un nombre) et les fonctions appliquées à une colonne indexée. Si la base a les licences, AWR, ASH et SQL Monitor donnent l'historique.
Signal d'alerteAjouter un hint INDEX dès le départ, ou se fier au seul EXPLAIN PLAN, qui donne un plan théorique et peut différer de celui qui tourne réellement.
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 un développeur Oracle : les questions fréquentes
Quel niveau de SQL attendre d'un développeur PL/SQL ?
Un niveau élevé. La plupart des problèmes de performance d'un batch Oracle se règlent en remplaçant une boucle par une requête. Attendez une aisance avec MERGE, les jointures externes, les fonctions analytiques comme ROW_NUMBER ou LAG, et les requêtes hiérarchiques. Un développeur qui écrit beaucoup de PL/SQL mais peu de SQL produit souvent du code lent et difficile à maintenir. Faites écrire une requête pendant l'entretien, même courte.
Faut-il évaluer Oracle Forms ou APEX dans le même entretien ?
Seulement si le poste les utilise. Forms concerne surtout la maintenance d'applications de gestion anciennes, chez des éditeurs ou dans le secteur public. APEX sert à construire des écrans web sur la base. Dans les deux cas, le socle reste le même : SQL, packages et gestion des erreurs. Ajoutez un axe dédié avec quelques questions sur les déclencheurs Forms ou les processus APEX, sans remplacer l'évaluation du PL/SQL lui-même.
Quel exercice donner pour un test technique PL/SQL ?
Un exercice court en direct fonctionne mieux qu'un long devoir à la maison. Donnez une procédure qui traite une table ligne à ligne et demandez de la réécrire, puis un plan d'exécution à commenter. En trente minutes, vous voyez si la personne pense en SQL ensembliste, si elle gère les rejets et si elle sait lire un plan. Demandez-lui de parler pendant qu'elle avance.
Un développeur PL/SQL peut-il travailler sur une migration vers PostgreSQL ?
Oui, et c'est souvent lui qui comprend le mieux le code à convertir. Il devra apprendre les écarts de PostgreSQL : pas de packages, une chaîne vide différente de NULL, des transactions gérées autrement dans les procédures, l'absence de transactions autonomes. Vérifiez qu'il a déjà lu un rapport Ora2Pg ou converti quelques procédures. Notre fiche sur le développeur PostgreSQL PL/pgSQL détaille ces écarts.
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.
