Recruter un développeur SAS DI revient souvent à confier un patrimoine existant. Des centaines de jobs DI Studio alimentent des datamarts SAS ou des tables Oracle, DB2 ou Teradata, tournent la nuit sous Control-M, $Universe ou Platform Process Manager et produisent les tables dont dépendent les études et le reporting. En ESN, la mission démarre souvent par la reprise d'un run fragile. Chez un client final, le poste inclut souvent la préparation d'une sortie de SAS 9, vers SAS Viya ou vers Python.
La difficulté tient au mélange des profils. Beaucoup de candidats écrivent du SAS Base et des macros sans avoir jamais travaillé avec les métadonnées. Ils ignorent l'analyse d'impact, la promotion d'un job par package ou le fait qu'un job déployé garde son ancien code tant qu'on ne le redéploie pas. D'autres connaissent l'interface sans savoir lire le code qu'elle génère ni ce qui s'exécute dans la base plutôt que dans SAS.
Lire le code généré par un job, c'est le minimum attendu d'un junior. Chez un senior, attendez l'inventaire d'un patrimoine DI avant une migration vers Viya ou Python, et le nombre de jobs qu'il a pu retirer.
L'environnement SAS d'un développeur DI Studio
SAS Data Integration Studio
L'outil graphique où l'on dessine les jobs : sources, transformations et tables cibles reliées par des flèches. DI Studio génère le code SAS correspondant, et c'est ce code qui tourne en production. Une personne expérimentée sait l'ouvrir, le lire et expliquer pourquoi un job est lent ou en erreur.
Serveur de métadonnées et SAS Management Console
Toutes les définitions (bibliothèques, tables, jobs, droits) sont enregistrées dans le serveur de métadonnées de SAS 9.4. SAS Management Console sert à l'administrer. Ces métadonnées permettent l'analyse d'impact, le lignage et la promotion des jobs d'un environnement à l'autre, ce qui distingue un développeur DI d'un développeur SAS Base.
SAS Base, macro-langage et PROC SQL
Le langage sous le capot. DATA step, PROC SQL et macros servent dans le code utilisateur, dans les transformations sur mesure et pour comprendre le code généré. Un profil DI qui ne lit pas un journal SAS dépend entièrement de l'interface.
Transformations de chargement
Table Loader pour écrire une table cible en remplacement, en ajout ou en mise à jour, SCD Type 2 Loader pour historiser les changements, Lookup pour enrichir un flux à partir d'une table de référence, Splitter ou Data Validation pour séparer et contrôler. Le choix de la bonne transformation se discute en entretien.
SAS/ACCESS et bases sources
Les modules SAS/ACCESS connectent SAS à Oracle, DB2, Teradata, SQL Server ou à une source ODBC. La question décisive est l'endroit où le calcul s'exécute. Une jointure renvoyée à la base (pass-through) peut prendre quelques minutes, la même jointure rapatriée dans SAS peut durer des heures.
Déploiement et ordonnancement
Un job DI Studio est déployé sous forme de programme SAS, puis planifié par Platform Process Manager (LSF) ou par l'ordonnanceur de l'entreprise, Control-M, $Universe ou VTOM. Le développeur doit savoir redéployer, relancer une journée et lire les codes retour.
SAS Viya et SAS Studio
La plateforme de SAS fonctionne sur Kubernetes et ne reprend pas DI Studio. Les traitements y sont construits dans SAS Studio, avec des flows et du code, et le moteur en mémoire CAS s'ajoute au moteur SAS classique. Beaucoup de missions actuelles portent sur ce passage.
Python et PySpark
L'autre destination des migrations. Réécrire un job SAS en pandas ou en PySpark demande de bien connaître les deux mondes : tri implicite, valeurs manquantes, formats de date SAS, arrondis. Le savoir-faire attendu porte surtout sur la comparaison des résultats avant de couper l'ancien traitement.
Les postes de développeur SAS DI se concentrent dans les grandes entreprises qui ont bâti leur décisionnel sur SAS 9 : banques, assurances, mutuelles, organismes publics, grande distribution. La plupart des recrutements passent par des ESN, sur des missions longues de maintenance et d'évolution. Le profil recherché est souvent confirmé ou senior, parce que l'existant est volumineux et peu documenté. Une partie croissante des missions ajoute l'inventaire du patrimoine SAS et sa migration vers SAS Viya ou vers Python, ce qui demande de savoir comparer des résultats ligne à ligne. La certification SAS Certified Data Integration Developer for SAS 9 atteste la connaissance de l'outil. La maîtrise du run se vérifie en entretien.
Les points techniques à valider chez un développeur SAS DI
- Conception de jobs DI Studio
- Métadonnées, promotion et analyse d'impact
- SAS Base, macros et code généré
- Chargements incrémentaux et historisation SCD
- Performance et exécution en base (pass-through)
- Migration vers SAS Viya ou Python
Des questions pour tester un développeur SAS DI
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 · junior à confirmé
Dans un job DI Studio, vous joignez une table clients et une table contrats stockées dans Oracle, vous filtrez puis vous chargez une table cible. Quelles transformations posez-vous, et où placez-vous le filtre ?
Une bonne réponseUne SQL Join avec la condition de filtre dans l'onglet Where, ou une Extract en amont, puis un Table Loader avec le bon mode de chargement (remplacement, ajout, mise à jour). Le filtre passe avant le chargement pour réduire le volume. Un bon profil vérifie que la jointure s'exécute dans Oracle et pas dans SAS, en évitant les fonctions SAS que la base ne sait pas traduire.
Signal d'alerteTout le job dans un seul bloc de code utilisateur, un filtre appliqué après le chargement, ou aucune idée de l'endroit où la jointure tourne.
Question 2 · confirmé
Vous devez ajouter une colonne à une table enregistrée dans les métadonnées et utilisée par une dizaine de jobs. Comment savez-vous lesquels sont touchés, et comment livrez-vous la modification en recette ?
Une bonne réponseL'analyse d'impact sur la table dans DI Studio pour lister les jobs et les transformations concernés. La modification se fait dans un dépôt projet (check out, check in) si la gestion des changements est active. La livraison passe par un export en package SAS (.spk), importé en recette avec la correspondance des bibliothèques et des serveurs. Enfin, les jobs modifiés sont redéployés.
Signal d'alerteModifier directement en production, copier les programmes .sas à la main d'un serveur à l'autre, ou découvrir les jobs touchés quand ils plantent.
Question 3 · confirmé
Aucune transformation standard ne fait ce dont vous avez besoin. Quand écrivez-vous du code utilisateur, et comment évitez-vous qu'il casse le lignage ?
Une bonne réponseEn dernier recours, et sur la plus petite portion possible. Les tables d'entrée et de sortie restent déclarées dans les métadonnées et le code utilise les macro-variables fournies par DI Studio (&_INPUT, &_OUTPUT) au lieu de noms codés en dur. Si le besoin revient dans plusieurs jobs, une transformation générée avec des paramètres, réutilisable et documentée.
Signal d'alerteDes chemins et des noms de bibliothèques écrits en dur, ou des jobs entiers en code utilisateur, que l'analyse d'impact ne voit plus.
Question 4 · confirmé
Une table de contrats doit garder l'historique des changements d'adresse et de produit. Comment la chargez-vous avec DI Studio ?
Une bonne réponseUn SCD Type 2 Loader avec la clé métier, la liste des colonnes dont un changement crée une nouvelle version, des dates de début et de fin de validité, un indicateur de ligne courante et une clé technique générée. Les colonnes techniques (date de chargement) sont exclues de la détection. Le candidat sait dire ce que devient une ligne qui disparaît de la source.
Signal d'alerteUn Table Loader en remplacement chaque nuit, qui efface l'historique, ou une détection de changement sur toutes les colonnes, qui crée une version par chargement.
Question 5 · confirmé
Un job de nuit qui prenait 40 minutes dure maintenant trois heures. Par quoi commencez-vous ?
Une bonne réponseLe journal avec l'option FULLSTIMER pour trouver l'étape qui a dérivé, en comparant temps réel et temps CPU. Puis les causes habituelles : volume en hausse, jointure qui ne s'exécute plus dans la base, tri d'une très grosse table, espace WORK saturé, index absent sur une table de référence. Il parle aussi des statistiques d'exécution que DI Studio sait collecter par job.
Signal d'alerte« On demande plus de mémoire sur le serveur », sans avoir ouvert le journal.
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 en SAS Data Integration : vos interrogations
Quelle différence entre un développeur SAS Base et un développeur SAS DI ?
Le développeur SAS Base écrit ses programmes à la main, dans Enterprise Guide ou un éditeur. Le développeur SAS DI construit des jobs dans DI Studio à partir de tables déclarées dans le serveur de métadonnées, ce qui donne l'analyse d'impact, le lignage et une promotion contrôlée entre environnements. Le second doit maîtriser le premier, car le code généré se lit et se corrige en SAS Base. L'inverse ne va pas de soi.
DI Studio existe-t-il encore avec SAS Viya ?
DI Studio appartient à SAS 9.4 et reste maintenu sur cette version. SAS Viya ne le reprend pas : les traitements s'y construisent dans SAS Studio, avec des flows graphiques et du code. Pour un recrutement, il faut donc distinguer les deux. Un excellent profil DI Studio n'a pas forcément pratiqué Viya, et une mission de migration demande en plus l'inventaire du patrimoine et la comparaison des résultats entre l'ancien et le nouveau système.
Quel test technique proposer à un développeur SAS DI ?
Un environnement DI Studio est rarement disponible pour un candidat externe. Un exercice sur papier fonctionne bien : un schéma de job à commenter, un extrait de journal SAS avec une étape lente à identifier, une demande d'historisation à transformer en paramètres de SCD Type 2 Loader. Ajoutez un court programme SAS Base à lire à voix haute. Vous verrez vite si la personne comprend le code que l'outil génère.
La certification SAS Data Integration Developer suffit-elle ?
La certification SAS Certified Data Integration Developer for SAS 9 montre une bonne connaissance de l'outil, des transformations et des métadonnées. Elle ne prouve pas l'expérience du run. Demandez un job repris en urgence, une chaîne accélérée ou une promotion entre environnements qui a posé problème. La grille du PDF Delectus AI donne un niveau de 1 à 4 par axe pour comparer les candidats certifiés et non certifiés sur les mêmes critères.
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.
