Un programmeur statistique SAS travaille en binôme avec le biostatisticien d'une étude clinique. Il part des données collectées dans l'eCRF et des fichiers des prestataires, les convertit au format SDTM, construit les datasets d'analyse ADaM selon le plan d'analyse statistique, puis produit les TLF (tables, listings et figures) du rapport. Chaque sortie importante est reprogrammée par un second programmeur, de façon indépendante, avant d'être livrée. Le recrutement se fait chez les laboratoires, dans les CRO et chez les prestataires qui placent des programmeurs en régie chez un promoteur.
La maîtrise du langage SAS se lit facilement sur un CV, celle des standards beaucoup moins. Un développeur SAS venu de la banque écrit des macros propres et ne sait pas où placer une date partielle. À l'inverse, un profil clinique cite SDTM et ADaM sans avoir jamais défendu une dérivation devant un statisticien ou corrigé un rapport Pinnacle 21 la veille d'une livraison.
Le type d'études et la phase visée sont à demander au manager. Un junior doit savoir produire une table en double programmation. Un senior doit avoir écrit des spécifications ADaM et répondu à une autorité. Le PDF ajoute un cas sur les tables de tolérance d'une étude de phase II.
Standards et outils du programmeur SAS clinique
SAS Base, macro-langage et PROC SQL
Le langage de travail du poste. L'étape DATA et PROC SQL servent à fusionner, filtrer et dériver les données ; le macro-langage permet de réutiliser le même programme d'une étude à l'autre. Un log sans avertissement ni note de conversion fait partie du travail attendu, et les équipes l'exigent avant toute livraison.
SDTM
Le standard CDISC qui range les données collectées dans des domaines fixes : DM pour les patients, AE pour les événements indésirables, EX pour les prises de traitement, LB pour le laboratoire. Les agences américaine et japonaise l'exigent dans un dossier de soumission. Le programmeur y transpose les données telles qu'elles ont été recueillies, sans les imputer.
ADaM
Le standard des datasets d'analyse, construits à partir de SDTM. On y trouve ADSL, une ligne par patient avec ses populations d'analyse, des datasets de mesures répétées (structure BDS) et des datasets d'événements comme ADAE. Les imputations, les fenêtres de visite et les valeurs de baseline se calculent à cet endroit, selon le plan d'analyse statistique.
TLF, PROC REPORT et ODS
Les tables, listings et figures du rapport d'étude, souvent produits avec PROC REPORT et ODS au format RTF à partir de maquettes fournies par le biostatisticien. Les règles de présentation (dénominateurs, décimales, ordre des lignes, notes de bas de page) comptent autant que les chiffres eux-mêmes.
Double programmation et PROC COMPARE
La méthode de validation du métier. Un second programmeur refait la sortie à partir des spécifications, sans lire le code du premier, et compare les résultats avec PROC COMPARE. Demandez comment la personne traite un écart et ce qu'elle consigne dans le journal de validation.
define.xml et guides du relecteur
Le define.xml décrit chaque dataset, variable, liste de codes et méthode de dérivation pour le relecteur de l'agence. Il est accompagné de guides rédigés (cSDRG pour SDTM, ADRG pour ADaM) qui expliquent les choix propres à l'étude et les anomalies restantes.
Pinnacle 21
L'outil de contrôle de conformité le plus répandu, aujourd'hui édité par Certara. Il vérifie les datasets et le define.xml par rapport aux règles CDISC et à celles des agences. Savoir lire son rapport, corriger les vraies erreurs et justifier les autres est une compétence attendue dès le niveau confirmé.
R et pharmaverse
Un nombre croissant d'offres demande R en complément de SAS. L'écosystème pharmaverse, porté par plusieurs laboratoires, fournit des packages comme admiral pour construire des datasets ADaM. Un programmeur qui passe d'un langage à l'autre doit connaître les écarts de calcul par défaut, sur les arrondis ou les percentiles.
Les employeurs sont les laboratoires pharmaceutiques et les biotechs, les CRO qui conduisent les études pour eux et les sociétés de services qui placent des programmeurs en régie chez un promoteur, sur un modèle souvent appelé FSP. Les documents de travail sont fréquemment en anglais. Selon la structure, le programmeur reste sur une étude de bout en bout ou prend une partie des livrables de plusieurs études (SDTM d'un côté, TLF de l'autre). Un lead programmeur coordonne en plus les spécifications, le planning des livraisons et l'intégration de plusieurs études pour une soumission. Les promoteurs académiques, dans les CHU, utilisent moins les standards CDISC, ce qui change le profil recherché.
Les points à contrôler chez un statistical programmer
- Programmation SAS et macros
- Mapping SDTM et terminologie contrôlée
- Dérivations ADaM et traçabilité
- Production et validation des TLF
- Conformité de soumission : define.xml, Pinnacle 21
- R et reproductibilité des analyses
Baseline, dates partielles, QC : cinq questions au programmeur
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 patient a deux mesures de laboratoire le jour de sa première dose. Laquelle devient sa valeur de baseline dans ADLB, et comment le notez-vous ?
Une bonne réponseLa règle vient du plan d'analyse statistique. Le plus souvent, la baseline est la dernière valeur non manquante avant la première dose, en comparant date et heure à TRTSDTM. Sans heure, le plan précise si une mesure du jour compte comme pré-dose. Un seul enregistrement porte ABLFL = Y, BASE est reportée sur toutes les lignes du paramètre et CHG vaut AVAL moins BASE. La règle figure dans le define.xml.
Signal d'alertePrendre la première valeur par défaut, faire la moyenne des deux sans que le plan le prévoie, ou corriger à la main le numéro du patient dans le programme.
Question 2 · junior à confirmé
Votre table d'événements indésirables diffère d'un patient de celle du programmeur principal. Comment menez-vous la validation ?
Une bonne réponseIl compare d'abord les datasets avec PROC COMPARE, pas seulement les fichiers RTF, pour isoler le patient et la variable en cause. Il remonte ensuite à la spécification : une règle ambiguë se tranche avec le biostatisticien, un bug se corrige chez celui qui l'a. L'écart, sa cause et la correction sont consignés dans le journal de validation.
Signal d'alerteOuvrir le programme du collègue pour s'aligner sur lui, comparer les deux tables à l'œil, ou modifier son propre code jusqu'à obtenir le même chiffre sans comprendre l'écart.
Question 3 · confirmé
Le centre a saisi une date de début d'événement indésirable dont le jour est inconnu, en mars 2025. Que devient-elle dans SDTM, puis dans ADAE ?
Une bonne réponseDans SDTM, AESTDTC garde la date partielle au format ISO 8601, ici 2025-03, sans imputation. Dans ADAE, ASTDT est imputée selon le plan d'analyse, par exemple au premier jour du mois, ou à la date de première dose si le traitement a commencé ce mois-là, pour ne pas sous-estimer les événements apparus sous traitement. ASTDTF = D indique que le jour a été imputé.
Signal d'alerteImputer directement dans SDTM, inventer un 15 du mois sans indicateur, ou laisser la date vide dans ADAE en perdant l'événement des analyses.
Question 4 · confirmé
La veille d'une livraison, Pinnacle 21 remonte 40 erreurs et 300 avertissements sur votre package SDTM. Comment faites-vous le tri ?
Une bonne réponseIl classe par règle et par gravité. Les vraies erreurs se corrigent : variable obligatoire absente, valeur hors terminologie contrôlée, doublon de --SEQ, incohérence entre datasets et define.xml. Les messages qui reflètent la donnée telle qu'elle a été recueillie restent en l'état et sont justifiés dans le cSDRG. Il vérifie aussi que la version des règles et de la terminologie correspond à celle de l'agence visée.
Signal d'alerteVouloir zéro avertissement en modifiant les données, ignorer le rapport parce que « ce sont des warnings », ou ne pas savoir où documenter un problème non corrigé.
Question 5 · junior à confirmé
Vous reprenez une macro qui produit toutes les tables de laboratoire et elle plante sur une nouvelle étude. Comment la déboguez-vous ?
Une bonne réponseIl active MPRINT, MLOGIC et SYMBOLGEN, lit tout le log, y compris les notes de variables non initialisées, de conversion de type ou de doublons de BY. Il vérifie la portée des macro-variables (%LOCAL, %GLOBAL) et teste sur un petit nombre de patients. Si la macro fait partie d'une bibliothèque validée, la correction passe par la gestion des changements et une nouvelle validation.
Signal d'alerteNe chercher que les lignes ERROR, ou corriger la macro partagée directement dans l'espace de production pour que l'étude passe.
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
Ce qui revient avant d'embaucher un programmeur statistique
Programmeur statistique ou biostatisticien : qui fait quoi sur une étude ?
Le biostatisticien conçoit l'analyse. Il rédige le plan d'analyse statistique, calcule le nombre de patients nécessaires et dessine les maquettes des tables. Le programmeur statistique transforme les données en SDTM et en ADaM, puis produit et valide les sorties selon ce plan. Les frontières varient : dans une petite biotech, une même personne fait parfois les deux. Pour un poste de programmeur, attendez une programmation solide et une bonne lecture du plan, pas la conception des modèles.
Faut-il exiger R en plus de SAS ?
Cela dépend de l'équipe qui accueille la personne. SAS reste le langage de production de la plupart des laboratoires et des CRO, et beaucoup de bibliothèques de macros validées sont écrites en SAS. Si votre équipe produit déjà des datasets ADaM ou des tables en R, avec les packages pharmaverse par exemple, posez une question sur les écarts de calcul entre les deux langages. Sinon, une pratique de R est un plus, rarement un critère d'exclusion.
Comment évaluer un programmeur SAS sans données d'essai réelles ?
Des données fictives suffisent : quelques domaines SDTM simplifiés (DM, EX, AE, LB) et un extrait de plan d'analyse. Le test technique peut consister à dériver ADSL et une table d'événements indésirables par classe d'organe et terme préféré. Pendant l'entretien, faites commenter le log et les choix de dérivation. Les données réelles d'une étude ne doivent jamais servir d'exercice, même pseudonymisées, car elles restent couvertes par le protocole et le RGPD.
Un développeur SAS venu de la banque peut-il devenir programmeur statistique ?
Oui, à condition d'apprendre les standards CDISC, le vocabulaire des essais cliniques et la discipline de validation propre au secteur. Le langage est le même, les pratiques diffèrent : double programmation, procédures écrites, dossier pour les agences. En entretien, mesurez sa maîtrise de SAS et sa compréhension d'un plan d'analyse. Prévoyez une montée en compétence sur SDTM et ADaM, idéalement aux côtés d'un programmeur expérimenté sur ses premières études.
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.
