Dans le domaine de l’analyse statistique avancée, du traitement de données cliniques et de l’économétrie, le logiciel SAS (Statistical Analysis System) demeure une référence incontournable pour les méthodologistes et les biostatisticiens. La manipulation rigoureuse des données au sein de l’environnement SAS repose sur une architecture d’exécution spécifique qui distingue fondamentalement la phase de compilation de la phase d’exécution. Au cœur de ce processus se trouve la création de nouvelles variables, opération élémentaire mais stratégique, conditionnant la validité des modèles prédictifs, la précision des analyses psychométriques et la robustesse des inférences quantitatives. Qu’il s’agisse de dériver des scores standardisés, de segmenter des populations selon des critères nosologiques stricts ou de restructurer des métadonnées longitudinales, la maîtrise de l’étape DATA constitue le socle technique indispensable à toute démarche d’ingénierie des données empiriques.
Le traitement des données brutes en sciences sociales, épidémiologie ou recherche translationnelle requiert une transformation méthodique afin d’isoler le signal informationnel du bruit stochastique. L’enrichissement d’une table relationnelle par l’adjonction de variables construites ne relève pas d’une simple commodité syntaxique, mais d’une exigence épistémologique visant à opérationnaliser des concepts théoriques abstraits en entités mathématiques exploitables. L’élaboration de métriques composites, la correction de biais d’asymétrie par transformations logarithmiques et l’encodage logique de trajectoires individuelles imposent une compréhension exhaustive des mécanismes internes de SAS, notamment le fonctionnement de la mémoire vive et la séquence d’évaluation des instructions.
Ce guide exhaustif a pour vocation d’exposer de manière systématique l’ensemble des approches, fonctions et structures algorithmiques permettant de concevoir, transformer et valider de nouvelles variables dans SAS. En parcourant les aspects fondamentaux du vecteur de données du programme, les opérations arithmétiques, le traitement conditionnel complexe, les manipulations de chaînes, l’arithmétique temporelle, la vectorisation par tableaux et le contrôle qualité statistique, cet article offre aux chercheurs, analystes et data scientists les clés méthodologiques nécessaires pour bâtir des tables de données analytiques d’une intégrité irréprochable.
1. Introduction aux principes fondamentaux de la création de variables dans SAS
1.1 Le rôle du vecteur de données du programme (PDV) et de l’étape DATA
L’exécution de toute étape DATA dans le compilateur SAS repose sur une structure mémorielle transitoire hautement optimisée, désignée sous l’acronyme PDV pour Program Data Vector (Vecteur de Données du Programme). Le PDV constitue la zone de mémoire tampon où les variables de la table de sortie sont matérialisées, dimensionnées et modifiées séquentiellement avant leur écriture effective sur le support de stockage physique. Comprendre la dynamique du PDV est une condition préalable absolue pour appréhender comment et quand une nouvelle variable acquiert sa valeur au fil du traitement itératif.
Le cycle de vie de l’étape DATA s’articule en deux phases distinctes et consécutives : la phase de compilation et la phase d’exécution. Durant la compilation, SAS analyse syntaxiquement le script, alloue l’espace mémoire nécessaire au sein du PDV pour chaque variable mentionnée et construit la table des descripteurs, qui contient l’ensemble des métadonnées structurelles (noms, types, longueurs, libellés et formats). Lors de la phase d’exécution, SAS initie une boucle implicite. Pour chaque observation lue depuis une source externe ou une table existante, les variables nouvellement calculées sont initialisées par défaut à la valeur manquante, à moins qu’une instruction spécifique ne vienne modifier cette réinitialisation.
Cette boucle d’exécution implicite suit une chronologie rigoureuse : lecture de l’enregistrement entrant, exécution ligne par ligne des instructions de transformation arithmétique ou logique, transfert des données du PDV vers le bloc de mémoire tampon de sortie, et enfin écriture physique de l’observation sur le disque. Toute assignation d’une nouvelle variable au sein du script modifie instantanément l’emplacement mémoire correspondant dans le PDV. Ainsi, l’ordre d’apparition des instructions dans le code conditionne la disponibilité et la valeur de la nouvelle variable pour les calculs subséquents, illustrant la nature procédurale et déterministe de l’environnement SAS.
1.2 Typologie des variables SAS : formats numériques et chaînes de caractères
Contrairement à des environnements de programmation modernes supportant une grande diversité de types primitifs complexes (tels que les booléens purs, les entiers signés ou non signés, ou les structures énumératives), SAS simplifie son architecture sous-jacente en ne reconnaissant fondamentalement que deux types de données : le type numérique et le type caractère. Cette dichotomie élémentaire régit l’ensemble de l’allocation mémoire et détermine la nature des opérations analytiques admissibles pour chaque colonne d’une table de données.
Par défaut, toute variable déclarée ou assignée sans spécification explicite est considérée par le compilateur comme numérique. Les variables numériques sont stockées sous la forme de nombres à virgule flottante en double précision, conformes à la norme IEEE 754, occupant par défaut 8 octets en mémoire vive. Cette allocation confère une précision d’environ 16 à 17 chiffres significatifs, permettant de représenter aussi bien des valeurs entières que des approximations décimales infinitésimales. Il est crucial de noter que dans le paradigme SAS, les dates, les heures et les valeurs booléennes ne constituent pas des types distincts : elles sont encodées sous forme numérique, leur sémantique étant gouvernée par des formats d’affichage ou des conventions logiques internes.
À l’opposé, les variables de type caractère, désignées par l’adjonction explicite du suffixe dollar ($) lors de leur instanciation dans les instructions de lecture ou de dimensionnement, stockent des chaînes de caractères alphanumériques. Chaque caractère occupant un octet selon l’encodage de la session (souvent UTF-8 ou ASCII étendu), la longueur d’une variable caractère doit être rigoureusement anticipée pour prévenir toute perte d’information par troncation. Le typage structurel d’une variable est immuable une fois l’étape de compilation achevée : une variable numérique ne peut accepter de chaînes textuelles sans déclencher une conversion implicite potentiellement corruptrice, et inversement, une variable caractère ne peut être directement soumise à des opérateurs arithmétiques.
1.3 Pertinence méthodologique dans la gestion des données expérimentales
Dans le contexte des sciences empiriques et de la recherche clinique standardisée, la dérivation et l’adjonction de nouvelles variables au sein des tables d’analyse obéissent à des normes strictes de gouvernance des données. Les jeux de données issus des systèmes de saisie électronique ou de protocoles expérimentaux renferment fréquemment des mesures brutes disparates, caractérisées par des échelles hétérogènes, des artéfacts de mesure ou des formulations directes nécessitant un renversement psychométrique. La création de variables dérivées constitue l’étape pivot transformant ces intrants désordonnés en variables latentes ou composites exploitables.
L’application rigoureuse du principe d’immutabilité des tables sources est ici primordiale. En programmation SAS professionnelle, on ne modifie jamais directement la table brute d’origine. On procède systématiquement à la génération d’une nouvelle table dérivée dans une bibliothèque de travail ou d’archivage intermédiaire. Cette stratégie préserve l’intégrité de la piste d’audit (audit trail), un impératif méthodologique incontournable prescrit par les organismes de réglementation tels que la Food and Drug Administration (FDA) ou l’Agence Européenne des Médicaments (EMA), notamment sous les standards CDISC (Clinical Data Interchange Standards Consortium).
Enfin, la création programmée de variables via des scripts textuels reproductibles garantit une transparence méthodologique totale, contrairement aux modifications manuelles opérées au sein d’interfaces graphiques ou de tableurs bureautiques. Chaque étape de transformation, d’imputation ou de recodage catégoriel est consignée dans un code source documenté, assurant la pérennité institutionnelle des analyses et permettant la réplication exacte des estimations statistiques par des équipes d’audit indépendantes.
2. Création de variables ex nihilo : la méthode par saisie directe
2.1 Syntaxe de base de l’instruction INPUT
L’instruction INPUT constitue la pierre angulaire de l’acquisition de données brutes non structurées au sein de l’environnement SAS. Elle indique au compilateur comment lire les flux de données textuelles séquentielles et comment mapper chaque jeton d’information vers un emplacement mémoire dédié dans le PDV. L’ordre d’énonciation des variables au sein de l’instruction INPUT détermine précisément la séquence de peuplement des colonnes dans la table finale en cours de construction.
La syntaxe de base requiert la spécification du nom de chaque variable, immédiatement suivi, le cas échéant, de modificateurs de type et de lecture. Si le nom n’est suivi d’aucun symbole particulier, SAS présume une nature numérique. En revanche, la présence du symbole dollar ($) informe le compilateur que le champ entrant doit être interprété comme une chaîne de caractères. Trois modes fondamentaux de lecture régissent l’instruction INPUT : le mode libre (list input), le mode par colonnes (column input) et le mode formaté (formatted input). Le mode libre, le plus accessible, suppose que les valeurs successives soient délimitées par au moins un espace blanc et ne comportent pas d’espaces internes.
Dans des configurations expérimentales plus rigides, le mode par colonnes ou formaté permet de lire des variables contiguës dépourvues de séparateurs explicites en indiquant les positions physiques de début et de fin de chaque segment de données (par exemple, INPUT ID 1-4 Age 5-6 Groupe $ 7). Des contrôleurs de pointeurs avancés, tels que l’arobase simple (@) pour la retenue de ligne ou le double arobase (@@) pour le maintien du pointeur de lecture sur le même enregistrement à travers plusieurs itérations du PDV, confèrent à l’instruction INPUT une flexibilité syntaxique exceptionnelle pour transformer n’importe quel flux brut en variables parfaitement typées.
2.2 Insertion de données brutes via l’instruction DATALINES
Lorsque des données d’étalonnage, des constantes d’ajustement ou des échantillons restreints doivent être intégrés de manière autonome au sein d’un script d’analyse SAS sans recourir à un fichier externe (texte, CSV ou base de données relationnelle), l’instruction DATALINES (ou son équivalent historique CARDS) est sollicitée. Cette instruction indique au compilateur la clôture de la section des ordres procéduraux de l’étape DATA et l’ouverture immédiate d’un bloc de données brutes textuelles intégrées au flux du programme.
L’insertion des données via DATALINES obéit à des conventions typographiques strictes dictées par le mode de lecture préalablement défini dans l’instruction INPUT. Chaque ligne de texte tapée sous DATALINES représente, dans le cas général d’une lecture par liste standard, une observation unique qui sera aspirée séquentiellement par le PDV. Les espaces jouent un rôle critique de délimiteurs de champs : un double espace ou une tabulation mal interprétée peut décaler la distribution des valeurs le long du PDV, entraînant des erreurs d’incompatibilité de type ou des valeurs manquantes inattendues dans les colonnes subséquentes.
La clôture du bloc de données DATALINES requiert une rigueur absolue. L’interpréteur SAS lit les données ligne par ligne jusqu’à ce qu’il rencontre un terminateur explicite, constitué d’un point-virgule isolé placé sur une nouvelle ligne immédiatement sous la dernière observation. L’omission de ce point-virgule d’exécution ou la présence d’un point-virgule prématuré au sein même du texte brut interrompt brutalement l’analyse du flux de données ou contamine la phase de compilation des étapes syntaxiques ultérieures.
2.3 Exemple pratique : Encodage d’un échantillon expérimental de participants
Afin de concrétiser les principes énoncés précédemment, considérons la formalisation d’un protocole expérimental évaluant une intervention cognitive sur une cohorte préliminaire de participants. Dans cette situation, nous devons instancier simultanément quatre variables fondamentales : un identifiant unique (ParticipantID), une variable textuelle catégorisant le bras de randomisation (Groupe), l’âge chronologique des sujets (Age) et un score psychométrique initial mesuré sur une échelle psychologique continue (ScoreInitial).
Le script suivant illustre l’encodage complet et autonome de ce jeu de données au moyen des instructions DATA, INPUT et DATALINES, suivi de l’inspection des métadonnées et des valeurs par la procédure PROC PRINT :
DATA CohorteExperimentale;
INPUT ParticipantID $ Groupe $ Age ScoreInitial;
DATALINES;
SUBJ001 ACTIF 24 78.5
SUBJ002 PLACEBO 29 62.0
SUBJ003 ACTIF 31 84.2
SUBJ004 PLACEBO 22 55.8
SUBJ005 ACTIF 27 91.3
;
RUN;
PROC PRINT DATA=CohorteExperimentale NOOBS;
RUN;
À l’exécution de ce bloc de code, SAS lit successivement les cinq lignes de données. Pour chaque ligne, le compilateur remplit les quatre cases réservées dans le PDV, puis écrit l’observation consolidée dans la table de travail temporaire WORK.CohorteExperimentale. L’appel de la procédure PROC PRINT sans l’option d’observation par défaut (NOOBS) génère un rapport tabulaire propre confirmant la création adéquate des quatre variables, avec leurs assignations typologiques respectives (deux caractères, deux numériques), exemptes de toute distorsion de lecture.
3. Dérivation de nouvelles variables à partir de variables existantes
3.1 L’instruction SET et la lecture de jeux de données préexistants
Dans la grande majorité des flux d’ingénierie statistique, les variables ne sont pas saisies manuellement mais dérivées à partir de structures tabulaires volumineuses déjà entreposées dans des bibliothèques SAS temporaires ou permanentes. L’instruction SET représente le mécanisme fondamental par lequel SAS lit séquentiellement les observations d’un jeu de données source pour les transférer dans le PDV, permettant ainsi d’effectuer des calculs et de générer de nouveaux attributs analytiques dans une table cible distincte.
Lors de la phase de compilation d’une étape DATA comportant une instruction SET, SAS examine la table d’entrée et copie l’intégralité de sa structure de descripteurs dans le PDV de la nouvelle table. Cela implique une persistance intégrale des métadonnées originelles : les variables héritent automatiquement de leur type, de leur longueur mémoire, de leurs étiquettes explicatives (LABEL) et de leurs règles d’affichage personnalisées (FORMAT). Ce comportement automatisé assure une continuité parfaite de la traçabilité des données d’une étape analytique à la suivante.
Néanmoins, une vigilance architecturale s’impose concernant l’écrasement potentiel de tables. Écrire une étape sous la forme DATA Echantillon; SET Echantillon; est syntaxiquement valide mais méthodologiquement périlleux : une erreur d’encodage dans le code intermédiaire détruirait irréversiblement la table initiale en cas d’interruption du processus d’exécution. Il convient d’adopter systématiquement une stratégie d’adressage distincte en nommant une table cible explicite (par exemple, DATA Echantillon_Derive; SET Echantillon;), garantissant ainsi la reproductibilité ascendante des opérations.
3.2 Application des opérateurs arithmétiques conventionnels
La dérivation directe de nouvelles variables numériques s’effectue au moyen d’instructions d’affectation faisant intervenir les opérateurs arithmétiques conventionnels. SAS prend en charge les opérations standard d’addition (+), de soustraction (-), de multiplication (*) et de division (/), ainsi que l’opérateur d’exponentiation symbolisé par le double astérisque (**). L’évaluation de ces expressions suit les axiomes mathématiques classiques de précédence opératoire, où la puissance prime sur la multiplication et la division, qui prévalent à leur tour sur l’addition et la soustraction.
L’utilisation de parenthèses imbriquées s’avère hautement recommandée dans la construction d’expressions arithmétiques complexes. Au-delà de lever toute équivoque quant à l’ordre d’évaluation exécuté par le compilateur, les parenthèses améliorent substantiellement la lisibilité du code pour les pairs auditeurs. Par exemple, le calcul d’un taux de variation relative s’écrira systématiquement sous la forme TauxVariation = (ScorePost – ScorePre) / ScorePre; afin d’empêcher une division prématurée de ScorePre par lui-même.
Il est fondamental de noter que les opérateurs arithmétiques de base possèdent une caractéristique structurelle critique : la propagation universelle des valeurs manquantes. Si l’un quelconque des termes participant à une opération binaire ou unaire est manquant (représenté par un point en SAS), le résultat de l’affectation sera irrévocablement évalué à la valeur manquante numérique, et une note d’avertissement sera consignée dans le journal d’exécution (SAS Log) pour signaler l’occurrence d’opérations sur des opérandes non initialisés ou nuls.
3.3 Exemple appliqué : Calcul d’indices composites et de scores agrégés
Considérons une situation d’évaluation neuropsychologique où des cliniciens mesurent simultanément l’efficience exécutive d’un individu à travers deux métriques continues distinctes : le temps de réponse brut (en millisecondes) et le nombre d’erreurs d’inattention commises lors d’une tâche d’attention soutenue. Pour synthétiser ces deux flux en une mesure clinique unifiée, nous souhaitons dériver un indice de performance globale pondéré, ainsi qu’un ratio d’efficience cognitive comparant la précision brute à la vitesse de traitement.
Le code SAS ci-après illustre comment exploiter l’instruction SET sur une table source pour créer simultanément ces deux nouvelles variables dérivées :
DATA AnalyseNeuro_Derivee;
SET AnalyseNeuro_Source;
/* Calcul d’un indice composite pénalisant les erreurs et les temps lents */
IndiceComposite = (TempsReponse * 0.4) + (NombreErreurs * 12.5);
/* Dérivation d’un ratio de précision : inversé par rapport au temps */
RatioEfficience = (100 – NombreErreurs) / (TempsReponse / 1000);
/* Application d’une transformation quadratique */
ScorePenalise = IndiceComposite ** 1.5;
RUN;
Dans cet exemple, pour chaque ligne lue dans AnalyseNeuro_Source, SAS évalue les trois expressions arithmétiques séquentiellement. Les variables IndiceComposite, RatioEfficience et ScorePenalise sont instantanément matérialisées dans le PDV et injectées dans la table cible AnalyseNeuro_Derivee. L’indépendance de ces opérations permet d’utiliser immédiatement la variable IndiceComposite fraîchement calculée pour dériver le ScorePenalise au cours de la même itération du PDV, éliminant ainsi toute redondance de calcul computationnel.
4. Création de variables conditionnelles avec les structures IF-THEN / ELSE
4.1 Fondements de la logique booléenne dans l’étape DATA
L’attribution de valeurs conditionnelles constitue le socle algorithmique de la recodification catégorielle et de la prise de décision automatisée dans SAS. Les instructions conditionnelles reposent sur l’évaluation booléenne d’expressions logiques liant une ou plusieurs variables à des seuils déterminés. Dans l’écosystème SAS, une expression logique retourne invariablement une valeur numérique : la valeur 1 représente la condition vraie (True), tandis que la valeur 0 traduit la fausseté de la proposition (False). Toute valeur numérique non nulle et non manquante est également interprétée comme vraie par le compilateur.
Pour formaliser ces assertions, SAS met à disposition des opérateurs de comparaison relationnels déclinables sous deux formes équivalentes : mnémonique ou symbolique. On retrouve ainsi l’égalité (EQ ou =), la non-égalité (NE ou ^=), la supériorité stricte (GT ou >), l’infériorité stricte (LT ou <), la supériorité ou égalité (GE ou >=) et l’infériorité ou égalité (LE ou <=). Ces propositions atomiques peuvent être articulées en constructions logiques complexes grâce aux opérateurs conjonctifs AND (&), disjonctifs OR (|) et négatifs NOT (~).
L’évaluation booléenne au sein de l’instruction IF-THEN commande l’exécution exclusive de l’instruction subordonnée située après le mot-clé THEN. Si l’expression logique est évaluée comme vraie, l’assignation de la nouvelle variable est actée dans le PDV. Si elle est fausse, le pointeur d’exécution ignore le bloc d’assignation et bascule immédiatement vers la ligne de code subséquente, maintenant la variable dans son état antérieur ou indéterminé.
4.2 Imbrication d’instructions IF-THEN/ELSE pour segmentations mutuellement exclusives
Lorsque la dérivation d’une variable exige de répartir les observations au sein d’un continuum de classes ordonnées ou nominales étanches, l’enchaînement séquentiel d’instructions IF-THEN isolées s’avère computationnellement inefficace et méthodologiquement risqué. L’adjonction de la clause conditionnelle alternative ELSE permet de structurer une hiérarchie décisionnelle mutuellement exclusive, optimisant le temps de calcul tout en assurant l’intégrité logique du modèle de partitionnement.
L’avantage fondamental de la structure IF-THEN / ELSE réside dans son mécanisme d’évaluation court-circuitée. Dès lors qu’une condition logique préliminaire est validée pour une observation donnée, SAS exécute l’assignation associée et contourne l’ensemble des branches ELSE subordonnées pour cette ligne du PDV. Ce comportement évite l’évaluation inutile de multiples tests redondants, réduisant significativement la charge CPU sur des tables contenant plusieurs millions d’enregistrements. En outre, ce chaînage prévient les écrasements accidentels de variables causés par des intervalles mal délimités dans des blocs IF indépendants.
La clause finale ELSE, dépourvue de condition logique restrictive, agit comme un filet de sécurité statistique indispensable. Elle capture l’intégralité des observations résiduelles qui n’ont satisfait à aucun des critères discriminants antérieurs. Dans la pratique du nettoyage de données scientifiques, ce bloc terminal est couramment exploité pour isoler les valeurs aberrantes imprévues, consigner des codes d’erreur explicites ou affecter formellement des valeurs manquantes à des profils empiriquement non répertoriés.
4.3 Cas clinique pratique : Stratification de la sévérité d’un trouble
Illustrons la puissance opérationnelle de l’imbrication IF-THEN/ELSE à travers la stratification nosologique d’une cohorte clinique en psychiatrie. Les participants sont évalués au moyen d’un score d’anxiété continu issu de l’échelle standardisée de Hamilton (HAM-A), oscillant théoriquement entre 0 et 56 points. Les seuils consensuels définissent quatre strates diagnostiques : absence d’anxiété significative (0-17), anxiété légère à modérée (18-24), anxiété modérée à sévère (25-30) et anxiété très sévère (supérieure à 30).
Le programme ci-dessous réalise ce recodage clinique avec rigueur, en intégrant en amont une vérification systématique de l’absence de valeurs manquantes afin d’éviter tout artefact de classification :
DATA CohortePsychiatrique_Classifiee;
SET CohortePsychiatrique;
/* Déclaration explicite de la longueur de la variable textuelle */
LENGTH CategorieSeverite $ 20;
IF MISSING(ScoreHAMA) THEN CategorieSeverite = ‘Indéterminé’;
ELSE IF ScoreHAMA < 18 THEN CategorieSeverite = ‘Absente/Minime’;
ELSE IF ScoreHAMA <= 24 THEN CategorieSeverite = ‘Légère/Modérée’;
ELSE IF ScoreHAMA <= 30 THEN CategorieSeverite = ‘Modérée/Sévère’;
ELSE IF ScoreHAMA > 30 THEN CategorieSeverite = ‘Très Sévère’;
ELSE CategorieSeverite = ‘Hors Limites’;
RUN;
L’inspection du code démontre que l’ordre des conditions suit rigoureusement la progression de l’échelle d’évaluation. L’exclusion préalable des valeurs manquantes via la fonction MISSING() est ici impérative, car dans le modèle interne de SAS, une valeur numérique manquante (.) est considérée comme infiniment petite, c’est-à-dire inférieure à n’importe quel nombre réel négatif ou positif. Sans cette garde-fou initiale, un score manquant aurait été classé à tort comme ‘Absente/Minime’ par la condition ScoreHAMA < 18.
5. Utilisation de l’instruction SELECT-WHEN pour des affectations multiples
5.1 Structure comparée entre blocs SELECT et enchaînements IF-ELSE
Lorsque la logique de dérivation d’une nouvelle variable dépend d’un ensemble étendu de modalités qualitatives ou de valeurs entières discrètes, l’accumulation de clauses IF-THEN / ELSE peut rapidement dégrader la lisibilité structurelle du script et accroître la complexité cognitive requise pour auditer le code. L’architecture de contrôle SELECT-WHEN offre une alternative syntaxique élégante, claire et hautement standardisée, particulièrement adaptée aux recodages multimodaux.
L’instruction SELECT existe sous deux formes distinctes dans l’étape DATA : la forme avec argument et la forme sans argument. La forme avec argument, formulée sous la syntaxe SELECT (variable_source); suivie de multiples clauses WHEN (valeur_cible) instruction;, compare l’expression source à des valeurs précises. La forme sans argument, structurée sous la forme SELECT; WHEN (condition_booleenne) instruction;, opère comme un sélecteur conditionnel universel fonctionnellement comparable à une série d’instructions IF-THEN, mais avec un niveau d’imbrication visuelle beaucoup plus lisible.
Sur le plan de l’optimisation système, le compilateur SAS peut optimiser l’arborescence des blocs SELECT en générant une table de sauts (jump table) lorsque l’expression cible est une variable discrète finie. Cette optimisation interne accélère l’évaluation par rapport à un défilement séquentiel de conditions IF non hiérarchisées, tout en offrant aux développeurs une structure rigide encadrée impérativement par une instruction de clôture END.
5.2 Gestion des cas non répertoriés avec la clause OTHERWISE
L’un des traits distinctifs les plus critiques du bloc SELECT-WHEN réside dans son exigence d’exhaustivité logique vis-à-vis des données entrantes. Contrairement à l’instruction IF-THEN qui ignore silencieusement les observations ne satisfaisant aucune condition, un bloc SELECT dont aucune clause WHEN n’est vérifiée cherchera impérativement une directive de secours incarnée par l’instruction OTHERWISE.
Si une observation soumise à l’évaluation d’un bloc SELECT ne remplit aucune des conditions WHEN stipulées et qu’aucune clause OTHERWISE n’est définie dans le bloc, SAS interrompt brutalement l’exécution de l’étape DATA en levant une erreur fatale dans le journal (ERROR: No WHEN condition was true and no OTHERWISE was specified). Cette interruption critique bloque la création de la table de sortie, signalant une anomalie majeure dans la couverture des modalités prévues par le programmeur.
L’intégration systématique d’une clause OTHERWISE constitue donc une bonne pratique de programmation défensive absolue. Elle permet de capturer les valeurs inattendues, les erreurs typographiques issues des saisies manuelles ou les catégories émergentes non documentées dans le protocole. En affectant une valeur de contrôle ou en émettant une notification explicite dans le journal système via l’instruction PUT, l’analyste préserve l’intégrité de son flux de traitement tout en isolant les anomalies de terrain.
5.3 Exemple concret : Affectation de profils de réponse neuropsychologique
Imaginons un paradigme expérimental en neurosciences cognitives dans lequel des sujets sont soumis à des tâches informatisées renvoyant des codes de complétion alphanumériques standardisés (COMP_OK, PART_ERR, TIMEOUT, ABORT_SUBJ, TECH_FAIL). L’objectif méthodologique consiste à dériver une nouvelle variable de statut expérimental (StatutProtocole) encodant l’éligibilité de la session pour l’analyse statistique finale.
Le bloc de code ci-dessous matérialise cette catégorisation au moyen d’un bloc SELECT avec argument, exploitant des listes de valeurs dans les clauses WHEN et sécurisant le processus avec OTHERWISE :
DATA AnalyseSessions_Derivees;
SET AnalyseSessions_Brutes;
LENGTH StatutProtocole $ 15 DescriptionAction $ 40;
SELECT (CodeReponse);
WHEN (‘COMP_OK’) DO;
StatutProtocole = ‘Valide’;
DescriptionAction = ‘Inclusion analyse principale’;
END;
WHEN (‘PART_ERR’, ‘TIMEOUT’) DO;
StatutProtocole = ‘Dégradé’;
DescriptionAction = ‘Analyse de sensibilité secondaire’;
END;
WHEN (‘ABORT_SUBJ’) DO;
StatutProtocole = ‘Exclu’;
DescriptionAction = ‘Retrait volontaire du participant’;
END;
WHEN (‘TECH_FAIL’) DO;
StatutProtocole = ‘Non-Évaluable’;
DescriptionAction = ‘Panne matérielle ou réseau’;
END;
OTHERWISE DO;
StatutProtocole = ‘Anomalie’;
DescriptionAction = ‘Code non répertorié à auditer’;
PUT ‘ATTENTION: Code de session inconnu détecté : ‘ CodeReponse= ‘pour ID=’ ParticipantID=;
END;
END;
RUN;
L’utilisation conjointe des blocs DO…END à l’intérieur des clauses WHEN permet d’exécuter simultanément plusieurs assignations pour une modalité unique, consolidant deux nouvelles variables (StatutProtocole et DescriptionAction). En outre, l’instruction PUT logée dans la clause OTHERWISE trace instantanément dans le journal toute anomalie empirique, offrant un retour en temps réel sur la qualité des saisies sans stopper le traitement des données valides.
6. Fonctions mathématiques et statistiques intégrées pour nouvelles variables
6.1 Agrégation horizontale au niveau de chaque observation
L’étape DATA requiert couramment la synthèse de multiples colonnes au sein d’une seule et même ligne d’observation. Cette opération d’agrégation horizontale diffère conceptuellement des agrégations verticales réalisées via la procédure PROC MEANS ou le langage SQL. Pour agréger des vecteurs de scores transversaux, SAS met à disposition une batterie de fonctions statistiques hautement optimisées, telles que SUM, MEAN, MIN, MAX, STD, VAR ou MEDIAN.
La puissance syntaxique de ces fonctions réside notamment dans leur capacité à ingérer des listes abrégées de variables grâce au mot-clé OF. Au lieu d’énumérer fastidieusement chaque colonne dans les arguments de la fonction, l’analyste peut spécifier des plages ordonnées ou des motifs nominaux, tels que MEAN(OF Item1-Item20) pour calculer la moyenne de vingt items consécutifs, ou SUM(OF Score_:) pour additionner l’ensemble des variables débutant par le préfixe ‘Score_’.
Il importe de distinguer rigoureusement la moyenne calculée à partir d’un ensemble de métriques du score brut total cumulé. Les fonctions statistiques internes de SAS ajustent automatiquement les dénominateurs computationnels en fonction des dimensions réelles des arguments fournis, garantissant des estimations mathématiques exactes et exemptes de distorsions d’échelles, ce qui est capital lors du traitement de questionnaires psychométriques complexes.
6.2 Opérateurs arithmétiques versus fonctions SAS face aux données manquantes
L’un des pièges méthodologiques les plus fréquents et dévastateurs rencontrés lors de la création de nouvelles variables dans SAS concerne la divergence comportementale majeure entre l’usage d’opérateurs arithmétiques conventionnels (+, -) et l’appel aux fonctions statistiques intégrées (SUM, MEAN) en présence de valeurs manquantes (missing data).
Considérons trois variables numériques : A, B et C. Si un analyste programme l’instruction d’assignation Total = A + B + C;, la présence d’une seule valeur manquante parmi les trois variables entraînera inévitablement la conversion de Total en valeur manquante (.), anéantissant l’information véhiculée par les deux autres mesures valides. À l’inverse, si l’analyste emploie la fonction Total_Fonction = SUM(A, B, C);, SAS ignore la valeur manquante et calcule la somme arithmétique exclusive des valeurs numériques observées, renvoyant un résultat numérique valide.
Cependant, cette tolérance intrinsèque de la fonction SUM introduit un péril méthodologique insidieux : l’équivalence artificielle entre un score complet et un score calculé sur des données tronquées. Si le participant a répondu uniquement à l’item A (valeur 10) et a omis les items B et C, SUM(A, B, C) renverra 10, tout comme un individu ayant répondu 3, 3 et 4 à l’ensemble du protocole. Il est donc impératif de conditionner l’usage de ces fonctions statistiques à des seuils minimaux de complétude d’items au moyen de la fonction NMISS (nombre de valeurs manquantes) ou de la fonction N (nombre de valeurs valides présentées).
6.3 Exemple de transformation : Normalisation et calcul de scores Z
Dans les études quantitatives impliquant des données distribuées selon des lois asymétriques ou mesurées sur des métriques incomparables, la standardisation et la normalisation non linéaire constituent des étapes obligatoires. Les scores Z permettent de repositionner chaque observation sur une échelle standardisée centrée sur zéro avec un écart-type unitaire, tandis que les transformations logarithmiques (LOG) ou de racine carrée (SQRT) corrigent les asymétries positives marquées.
Le bloc de code ci-dessous démontre la création conjointe d’une variable log-transformée pour corriger l’asymétrie d’un biomarqueur d’inflammation (CRP), suivie du calcul d’un score Z standardisé basé sur des paramètres normatifs de population préalablement établis (Moyenne = 2.5 mg/L, Écart-type = 0.8 mg/L) :
DATA Biomarqueurs_Normalises;
SET DonneesBiologiques;
/* Transformation logarithmique naturelle pour réduire l’asymétrie positive */
IF CRP_Brute > 0 THEN Log_CRP = LOG(CRP_Brute);
ELSE IF CRP_Brute = 0 THEN Log_CRP = LOG(CRP_Brute + 0.001); /* Constante de translation */
ELSE Log_CRP = .;
/* Standardisation sous forme de score Z normatif */
IF NOT MISSING(CRP_Brute) THEN DO;
Z_Score_CRP = (CRP_Brute – 2.5) / 0.8;
/* Arrondi métrologique à trois décimales significatives */
Z_Score_Arrondi = ROUND(Z_Score_CRP, 0.001);
END;
ELSE DO;
Z_Score_CRP = .;
Z_Score_Arrondi = .;
END;
RUN;
L’utilisation de la fonction ROUND avec un argument de précision explicite (0.001) permet de contrôler finement la représentation décimale de la nouvelle variable, éliminant les artéfacts infinitésimaux inhérents à l’arithmétique binaire à virgule flottante. Par ailleurs, la gestion prudente de la borne zéro via une constante d’ajustement prévient toute levée d’erreur mathématique lors de l’application de la fonction LOG sur des valeurs nulles ou négatives.
7. Manipulation et génération de variables de type caractère
7.1 Gestion cruciale de la longueur avec l’instruction LENGTH
L’une des particularités les plus critiques du moteur de données SAS concerne la détermination statique de la longueur mémoire des variables de type caractère lors de la phase de compilation de l’étape DATA. Contrairement aux environnements à typage dynamique allouant la mémoire élastiquement en fonction du contenu textuel instantané, SAS fixe irrévocablement la longueur d’une variable caractère dès sa première mention dans le flux séquentiel du script.
Cette particularité architecturale induit le phénomène notoire de « troncature silencieuse ». Si une nouvelle variable textuelle est instanciée pour la première fois au sein d’une instruction conditionnelle courte telle que IF Sexe = ‘M’ THEN GroupeLabel = ‘Homme’;, SAS analyse la chaîne ‘Homme’ lors de la compilation et alloue définitivement une longueur de 5 octets à GroupeLabel dans le PDV. Lorsque le programme évalue l’observation suivante et exécute ELSE GroupeLabel = ‘Femme_Enceinte’;, la chaîne sera impitoyablement tronquée à cinq caractères, produisant la valeur corrompue ‘Femme’ sans qu’aucun avertissement explicite d’erreur fatale ne soit nécessairement mis en exergue dans le journal.
Pour immuniser le traitement contre ce péril, la déclaration préalable de la taille maximale au moyen de l’instruction LENGTH est obligatoire. Positionnée stratégiquement tout en haut de l’étape DATA, avant même l’instruction SET ou les blocs conditionnels, l’instruction LENGTH définit l’enveloppe mémorielle maximale requise (par exemple, LENGTH GroupeLabel $ 25;), garantissant que toute chaîne de caractères ultérieurement assignée disposera d’un espace suffisant pour préserver son intégrité textuelle intégrale.
7.2 Fonctions fondamentales de traitement des chaînes de caractères
La génération de nouvelles variables textuelles requiert fréquemment le découpage, le nettoyage typographique et la concaténation de segments d’information hétérogènes. SAS offre une suite complète de fonctions de manipulation de chaînes hautement performantes, au premier rang desquelles figurent SUBSTR, SCAN, STRIP, UPCASE, LOWCASE et la famille des fonctions CAT.
La fonction SUBSTR extrait une sous-chaîne à partir d’une position indicielle de départ et d’une longueur spécifiée, s’avérant idéale pour parser des structures à colonnage fixe. Pour l’extraction sémantique basée sur des séparateurs arbitraires (virgules, barres obliques, espaces), la fonction SCAN surpasse largement SUBSTR : elle isole directement le n-ième mot d’une chaîne sans nécessiter le calcul manuel des décalages d’octets. Parallèlement, les fonctions UPCASE et LOWCASE standardisent la casse des caractères, éliminant les disparités d’encodage (‘Positif’, ‘POSITIF’, ‘positif’) préalablement aux jointures ou aux classifications.
Pour agréger plusieurs composantes textuelles en une seule variable, les fonctions de la famille CAT doivent systématiquement supplanter l’opérateur traditionnel de concaténation double barre (||). L’opérateur brut ne supprime pas les espaces de remplissage résiduels situés à droite des variables caractères, produisant des chaînes disjointes peu ergonomiques. La fonction CATS élimine automatiquement tous les espaces de tête et de fin avant d’unir les éléments, tandis que la fonction CATX insère en outre un séparateur personnalisé entre chaque segment concaténé, rationalisant considérablement le code de mise en forme.
7.3 Exemple empirique : Création d’identifiants uniques de participants
Dans les essais cliniques multicentriques, l’anonymisation et la constitution d’identifiants uniques universels constituent un impératif méthodologique de premier ordre. Il est fréquent que les données sources possèdent des informations distribuées dans trois colonnes distinctes : le code du centre hospitalier (CentreNum), le libellé du protocole (ProtocoleID) et le numéro d’ordre séquentiel du patient (PatientIndex). Pour harmoniser le suivi longitudinal, nous devons dériver une variable textuelle standardisée unique au format ‘PROT-CENTRE-PATIENT’.
Le bloc de code ci-dessous met en œuvre l’instruction LENGTH conjointe aux fonctions CATX, STRIP et PUT pour générer cette clé primaire sans espaces parasites :
DATA SujetsInclus_Identifies;
SET Recrutement_Brut;
/* Allocation sécurisée de la mémoire textuelle */
LENGTH CodePatientUnique $ 25 CodePatientStandard $ 25;
/* Nettoyage et extraction des composantes */
Centre_Nettoye = STRIP(CentreNum);
Protocole_Maj = UPCASE(STRIP(ProtocoleID));
/* Formatage du numéro séquentiel numérique en chaîne avec zéros non significatifs */
Patient_Formate = PUT(PatientIndex, Z4.);
/* Concaténation sécurisée avec délimiteur tiret */
CodePatientUnique = CATX(‘-‘, Protocole_Maj, Centre_Nettoye, Patient_Formate);
/* Alternative utilisant CATS sans séparateur fixe */
CodePatientStandard = CATS(Protocole_Maj, ‘_’, Centre_Nettoye, ‘_’, Patient_Formate);
RUN;
L’utilisation de la fonction PUT(PatientIndex, Z4.) transforme élégamment l’entier numérique en une chaîne de quatre caractères paddée de zéros à gauche (par exemple, 7 devient ‘0007’). La fonction CATX assemble ensuite ces trois fragments avec le délimiteur ‘-‘, produisant une métrique finale rigoureusement standardisée (ex: ‘ONCO01-CTR12-0007’), garantissant l’unicité stricte de l’identifiant pour toutes les étapes ultérieures de fusion relationnelle et d’analyses longitudinales.
8. Création de variables temporelles et de dates dans SAS
8.1 Architecture interne du système de dates SAS
La temporalité constitue un axe central de l’analyse statistique, particulièrement en épidémiologie, en économétrie et dans les modèles de survie. Cependant, appréhender le traitement des dates dans SAS requiert de s’affranchir de leur apparence visuelle textuelle pour comprendre leur architecture numérique sous-jacente. SAS ne dispose pas d’un type mémoriel distinct pour les dates : toute variable de date est stockée sous la forme d’un nombre entier relatif représentant le nombre de jours écoulés depuis une origine arbitraire fixée au 1er janvier 1960.
Sous cette convention, le 1er janvier 1960 correspond à la valeur entière 0. Les dates postérieures à ce point zéro sont représentées par des entiers positifs (par exemple, le 1er janvier 2024 équivaut à 23 376), tandis que les dates antérieures sont encodées par des entiers négatifs (le 1er janvier 1950 correspond à -3 652). De manière analogue, les variables de temps (Time) mesurent le nombre de secondes écoulées depuis minuit, et les variables d’horodatage combiné (Datetime) quantifient le nombre de secondes écoulées depuis le 1er janvier 1960 à 00:00:00.
Cette représentation sous forme scalaire confère une puissance analytique remarquable : la différence mathématique brute entre deux variables de date SAS (DateFin – DateDebut) fournit instantanément la durée exacte en jours calendaires séparant les deux événements, sans requérir d’algorithmes de conversion complexes. Néanmoins, pour qu’un entier comme 23376 devienne lisible pour un auditeur humain, l’association d’un format d’affichage (tel que DATE9., DDMMYY10. ou YYMMDD10.) via l’instruction FORMAT est formellement requise.
8.2 Fonctions de construction et de manipulation temporelle
L’élaboration de nouvelles variables de date au sein de l’étape DATA fait appel à un ensemble de fonctions dédiées capables de composer, décomposer ou échantillonner le temps. La fonction MDY (Month, Day, Year) constitue l’outil princeps pour assembler une date SAS valide à partir de trois grandeurs numériques indépendantes figurant dans les données brutes, évitant ainsi les erreurs d’interprétation liées aux formats textuels régionaux.
À l’inverse, si l’on dispose d’une variable de date unifiée, les fonctions d’extraction YEAR, MONTH, DAY, QTR (trimestre) et WEEKDAY (jour de la semaine) isolent instantanément les composantes chronologiques souhaitées, facilitant la création de covariables saisonnières ou de cohortes de naissance. Pour ancrer le traitement des données dans la temporalité dynamique du système informatique au moment précis de l’exécution, les fonctions sans argument TODAY() ou DATE() retournent la date système courante sous forme de valeur de date SAS.
Enfin, pour manipuler les incréments temporels sans encourir les pièges des années bissextiles ou des variations de durée des mois calendaires, les fonctions INTCK et INTNX s’avèrent indispensables. INTCK compte le nombre d’intervalles franchis (semaines, mois, années) entre deux bornes temporelles, tandis qu’INTNX décale une date initiale d’un nombre déterminé d’intervalles en gérant rigoureusement l’alignement temporel au début, au milieu ou à la fin de la période considérée.
8.3 Exemple d’application clinique : Calcul précis de l’âge chronologique
Dans les registres épidémiologiques et les essais cliniques pharmacologiques, le calcul rigoureux de l’âge chronologique des patients au moment de la visite de randomisation (VisiteDate) à partir de leur date de naissance exacte (DateNaissance) constitue une exigence fondamentale. L’application d’une approximation arithmétique simpliste consistant à diviser la différence brute de jours par 365.25 introduit des erreurs de troncature chez les individus nés lors d’années bissextiles.
Le script SAS suivant illustre la création méthodologiquement exacte de la variable AgeChronologique au moyen de la fonction biomédicale spécialisée YRDIF, ainsi que le calcul de la durée d’exposition au traitement avec application de formats de restitution :
DATA AnalyseClinique_Dates;
SET DossiersPatients_Source;
/* Construction d’une date SAS à partir de champs séparés */
DateConsentement = MDY(MoisConsentement, JourConsentement, AnneeConsentement);
/* Calcul de l’âge exact en années révolues selon la convention ACT/ACT */
IF NOT MISSING(DateNaissance) AND NOT MISSING(DateConsentement) THEN DO;
AgeExact = YRDIF(DateNaissance, DateConsentement, ‘ACT/ACT’);
AgeRevolu = FLOOR(AgeExact);
END;
ELSE DO;
AgeExact = .;
AgeRevolu = .;
END;
/* Calcul de la durée de suivi thérapeutique en semaines calendaires */
DureeSuiviSemaines = INTCK(‘WEEK’, DateConsentement, DateFinTraitement);
/* Attribution de formats pour garantir une restitution visuelle intelligible */
FORMAT DateConsentement DateFinTraitement DATE9. AgeExact 6.2;
RUN;
L’utilisation de la fonction YRDIF avec le standard ‘ACT/ACT’ (Actual/Actual) calcule le ratio temporel exact en tenant compte de la longueur réelle de chaque année calendaire traversée. L’application subordonnée de la fonction FLOOR permet de dériver l’âge révolu légal, éliminant tout arrondi prématuré vers le haut. La spécification finale du format DATE9. garantit que la variable DateConsentement apparaîtra dans les rapports sous une forme normalisée sans ambiguïté internationale (ex: 15JAN2024), tout en demeurant un entier manipulable mathématiquement dans le PDV.
9. Automatisation de la création de variables via les tableaux (ARRAY)
9.1 Définition et structure des tableaux temporaires de variables
Lorsque la structure expérimentale d’une étude requiert d’appliquer une transformation uniforme sur un ensemble étendu de variables de même type (par exemple, recoder cinquante items d’une échelle psychométrique, centrer cinquante variables biochimiques ou convertir des dizaines de métriques d’unités impériales en unités métriques), la programmation séquentielle ligne par ligne devient répétitive, sujette aux erreurs de saisie et prohibitive en maintenance logicielle. SAS résout cette problématique par l’intermédiaire de la structure de tableau, désignée par l’instruction ARRAY.
Un ARRAY dans l’étape DATA ne constitue pas une structure de données physique additionnelle stockée dans la table résultante. Il s’agit exclusivement d’un artifice syntaxique de compilation, une grille de référence temporaire qui regroupe logiquement un sous-ensemble de variables déjà existantes ou devant être créées au sein du PDV. La syntaxe canonique d’instanciation s’énonce sous la forme ARRAY NomTableau {dimension} $ variable_1 … variable_n;. L’omission du dollar indique un tableau de variables numériques.
L’accès à chaque élément individuel du tableau s’effectue au moyen d’une indexation numérique entière entourée d’accolades ou de parenthèses (par exemple, NomTableau{1} renvoie à la première variable référencée). L’analyste peut ainsi manipuler un groupe entier de colonnes au sein d’une abstraction vectorielle unifiée, ouvrant la voie à des automatisations puissantes et condensées lors de l’exécution séquentielle du PDV.
9.2 Itération et boucles DO pour transformations massives
La pleine puissance opérationnelle des instructions ARRAY se manifeste lorsqu’elles sont conjuguées aux boucles itératives DO…TO…END. Cette conjonction algorithmique permet d’exécuter un bloc de transformations mathématiques ou logiques sur l’ensemble des éléments référencés dans le tableau, en quelques lignes de code seulement, pour chaque observation transitant par le PDV.
Dans ce modèle itératif, l’indice de la boucle DO sert de pointeur d’index pour parcourir séquentiellement les cases du tableau. L’utilisation de la fonction dynamique DIM(NomTableau) comme borne supérieure de l’indice de boucle constitue une pratique exemplaire : elle calcule automatiquement le nombre exact d’éléments contenus dans le tableau, immunisant l’algorithme contre tout risque de dépassement de limite de tableau (OutOfBounds) si des variables devaient être ultérieurement ajoutées ou retirées de la liste source.
Ce traitement vectoriel réduit la taille du script source de manière drastique, substituant des centaines d’instructions conditionnelles ou arithmétiques redondantes par une boucle compacte. La compacité syntaxique ainsi obtenue minimise le risque de disparités de traitement entre variables sœurs et simplifie l’audit du code par des organismes certificateurs indépendants, tout en optimisant le chemin d’exécution au niveau du microprocesseur.
9.3 Exemple psychométrique : Recodage simultané d’items inversés
Dans les enquêtes psychologiques ou managériales utilisant des échelles d’attitude de type Likert en 5 points (de 1 = ‘Pas du tout d’accord’ à 5 = ‘Totalement d’accord’), il est d’usage d’inverser la polarité sémantique de certains items afin de neutraliser les biais d’acquiescement passif. Pour les items inversés, un score initial de 1 doit devenir 5, un score de 2 doit devenir 4, et ainsi de suite. L’équation de transformation linéaire théorique s’écrit formellement : NouveauScore = (ValeurMax + ValeurMin) – AncienScore, soit 6 – AncienScore.
Le bloc de code ci-dessous illustre comment instancier simultanément dix nouvelles variables recodées (ItemRev1 à ItemRev10) à partir de dix items bruts (Item1 à Item10) grâce à la définition de deux tableaux synchronisés au sein d’une boucle itérative :
DATA Psychometrie_Recodee;
SET Enquete_Brute;
/* Déclaration du tableau référençant les variables d’origine */
ARRAY ItemsOrig {10} Item1 – Item10;
/* Déclaration du tableau matérialisant dix NOUVELLES variables */
ARRAY ItemsInverses {10} ItemRev1 – ItemRev10;
/* Boucle itérative de recodage vectoriel */
DO i = 1 TO DIM(ItemsOrig);
IF NOT MISSING(ItemsOrig{i}) THEN DO;
/* Transformation arithmétique d’inversion */
ItemsInverses{i} = 6 – ItemsOrig{i};
END;
ELSE DO;
ItemsInverses{i} = .;
END;
END;
/* Suppression de la variable indicielle de boucle du jeu de données final */
DROP i;
RUN;
Lors de la compilation, l’instruction ARRAY ItemsInverses {10} ItemRev1 – ItemRev10; commande à SAS de créer dix nouveaux emplacements de variables numériques dans le PDV. Lors de l’exécution de la boucle DO pour chaque participant, le compilateur affecte instantanément à chaque case de ItemsInverses la valeur inversée de l’item d’origine correspondant. L’instruction finale DROP i; garantit que le compteur de boucle, rendu inutile une fois les itérations achevées, ne viendra pas encombrer inutilement la table analytique finale.
10. Création de variables cumulatives et rétention d’état avec l’instruction RETAIN
10.1 Mécanisme de réinitialisation automatique du PDV et nécessité du RETAIN
L’un des axiomes directeurs de l’étape DATA réside dans l’amnésie délibérée du PDV d’une observation à la suivante. Par défaut, à chaque début d’itération de la boucle d’exécution (c’est-à-dire lors de la lecture d’une nouvelle ligne de données), SAS réinitialise à la valeur manquante (. ou espace) toutes les variables créées ou calculées directement au sein de l’étape DATA, à l’exception notable de celles lues depuis une table source via l’instruction SET ou créées par une instruction de somme implicite.
Cette réinitialisation systématique vise à empêcher qu’une valeur calculée pour l’observation précédente ne contamine accidentellement l’observation en cours si cette dernière ne répondait pas aux conditions logiques d’affectation. Cependant, cette amnésie mémorielle interdit par défaut tout calcul inter-observations, tel que le calcul de totaux cumulés au fil du temps, la conservation d’une valeur de référence baseline ou l’incrémentation d’un compteur séquentiel d’événements.
L’instruction RETAIN intervient précisément pour désactiver cette purge automatique du PDV. En spécifiant RETAIN VariableNom [valeur_initiale];, l’analyste ordonne formellement au compilateur SAS de préserver la valeur résidente de cette variable en mémoire vive à travers toutes les itérations successives de l’étape DATA, jusqu’à ce qu’une instruction de réassignation explicite vienne écraser son contenu. Cette rétention d’état permet d’établir une continuité temporelle au sein de jeux de données strictement séquentiels.
10.2 Calcul de sommes cumulées et d’indicateurs de trajectoire
La création de variables de sommation progressive au fil des enregistrements représente l’une des applications les plus courantes de la mémoire persistante. SAS offre deux approches pour implémenter une sommation cumulative : l’instruction RETAIN couplée à un opérateur d’addition standard, ou l’utilisation plus compacte de l’instruction d’addition implicite, couramment appelée « instruction de somme » (Sum Statement).
L’instruction d’addition implicite s’articule selon la syntaxe VariableCumulative + Increment;. Cette écriture possède deux particularités majeures : d’une part, elle implique automatiquement l’effet de rétention RETAIN sur la variable située à gauche de l’opérateur plus (+), l’initialisant implicitement à zéro avant la première itération ; d’autre part, elle gère intrinsèquement les valeurs manquantes en les traitant comme des zéros neutres, empêchant la propagation destructive de la valeur manquante sur le cumul progressif de la trajectoire.
Cette méthodologie est fondamentale pour créer des indicateurs d’exposition cumulative à des toxiques ou à des traitements médicamenteux. Elle permet également de construire des compteurs dynamiques d’événements indésirables, documentant pour chaque observation le rang séquentiel exact de l’occurrence clinique au sein de l’historique médical individuel d’un patient.
10.3 Exemple longitudinal : Traitement par groupes avec l’instruction BY
Dans les cohortes épidémiologiques longitudinales comportant des mesures répétées par patient, les calculs cumulatifs ne doivent généralement pas s’étendre sur l’ensemble de la table entière, mais être réinitialisés à zéro dès que l’étape DATA entame le traitement des observations d’un nouveau participant. Cette partition logique exige l’utilisation conjointe du tri préalable via la procédure PROC SORT, de l’instruction BY et des variables automatiques FIRST. et LAST.
Le programme ci-dessous illustre la création d’une variable d’exposition médicamenteuse cumulative (DoseCumulee) et d’un compteur séquentiel de visites (NumeroVisite), tous deux réinitialisés au début de chaque sous-groupe de patient identifié par PatientID :
/* Étape préalable obligatoire : tri de la table par patient et par date */
PROC SORT DATA=VisitesCliniques_Source OUT=Visites_Triees;
BY PatientID DateVisite;
RUN;
DATA TrajectoireClinique_Derivee;
SET Visites_Triees;
BY PatientID DateVisite;
/* Déclaration de persistance d’état et initialisation */
RETAIN DoseCumulee 0 NumeroVisite 0;
/* Réinitialisation impérative lors de la première observation de chaque sujet */
IF FIRST.PatientID THEN DO;
DoseCumulee = 0;
NumeroVisite = 0;
END;
/* Incrémentation séquentielle */
NumeroVisite = NumeroVisite + 1;
IF NOT MISSING(DoseJournaliereAdmin) THEN DO;
DoseCumulee = DoseCumulee + DoseJournaliereAdmin;
END;
/* Variable drapeau indiquant la fin du suivi d’un sujet */
DerniereVisiteFlag = LAST.PatientID;
RUN;
Dans cette architecture, SAS génère automatiquement en mémoire les variables temporaires FIRST.PatientID et LAST.PatientID. Dès qu’un nouveau patient est rencontré dans le flux de données, FIRST.PatientID prend la valeur 1, ce qui déclenche la remise à zéro des accumulateurs. Les variables DoseCumulee et NumeroVisite sont ensuite actualisées et conservées pour les enregistrements suivants de ce même patient grâce à RETAIN. Enfin, la variable booléenne DerniereVisiteFlag capture l’achèvement du suivi, offrant une variable filtre précieuse pour les futures analyses de survie ou de fin de protocole.
11. Gestion rigoureuse des valeurs manquantes lors de la création de variables
11.1 Typologie et représentation des valeurs manquantes dans SAS
La présence de valeurs manquantes (données non collectées, refus de réponse, abandons ou échantillons biologiques insuffisants) constitue une constante inévitable de l’analyse quantitative. Pour éviter des biais d’estimation ou des classifications erronées, la création de nouvelles variables doit s’appuyer sur une compréhension exacte de la représentation interne des valeurs manquantes dans l’environnement SAS.
Pour les variables de type caractère, la valeur manquante est uniformément matérialisée par une chaîne vide, représentée dans le code par une apostrophe double ou simple sans contenu (‘ ‘ ou « »), correspondant à un remplissage d’espaces blancs occupant l’intégralité de la longueur déclarée dans le PDV. Pour les variables numériques, la valeur manquante standard est représentée par un point unique (.).
Toutefois, SAS pousse la granularité méthodologique plus loin en offrant 27 valeurs manquantes spéciales supplémentaires pour les variables numériques : le point suivi d’une lettre (.A à .Z) ainsi que le point souligné (._). Cette fonctionnalité exclusive permet d’encoder la cause sémiologique de la non-réponse directement au sein du scalaire manquant (par exemple, .A pour ‘Absence justifiée’, .R pour ‘Refus de consentir’, .P pour ‘Panne technique’). Sur le plan mathématique, toutes ces valeurs manquantes numériques sont traitées par le compilateur comme des grandeurs infiniment négatives, une particularité aux répercussions majeures lors des tests conditionnels d’infériorité.
11.2 Fonctions de détection et préservation de la validité statistique
Face à la complexité de l’ordonnancement mémoriel des valeurs manquantes, la formulation empirique de tests conditionnels directs tels que IF Variable = . THEN… s’avère insuffisante, car elle ne détecte pas les valeurs manquantes spéciales (.A à .Z) et échoue sur les variables de type caractère. Pour garantir une détection universelle et robuste, SAS fournit la fonction système MISSING().
La fonction MISSING() prend en paramètre une variable quelconque (qu’elle soit numérique, caractère ou une valeur manquante spéciale) et renvoie la valeur booléenne 1 si l’argument est manquant, et 0 s’il est rigoureusement valide et documenté. L’adoption de la fonction MISSING() au sein des filtres préalables de l’étape DATA constitue le standard de programmation défensive le plus fiable pour prémunir les calculs de dérivation contre l’injection inopinée de données absentes.
Parallèlement, les fonctions matricielles transversales NMISS (pour les listes de variables numériques) et CMISS (opérant indifféremment sur des arguments numériques et textuels) permettent d’évaluer d’un bloc le volume de données incomplètes au sein d’une ligne d’observation. L’évaluation préventive de ces compteurs de complétude évite de générer des scores composites non représentatifs, garantissant ainsi le respect strict des hypothèses statistiques sous-tendant les inférences ultérieures.
11.3 Exemple méthodologique : Création d’indicateurs d’attrition et de non-réponse
Dans les enquêtes épidémiologiques transversales ou les batteries d’évaluations cognitives, il est indispensable de créer une nouvelle variable méthodologique attestant de l’exhaustivité de la participation du sujet. Une règle psychométrique conventionnelle stipule qu’un score global ne doit être calculé que si le participant a complété au moins 80 % des items de la batterie, le protocole étant jugé non évaluable en deçà de ce seuil de représentativité.
Le bloc de code ci-dessous matérialise la création d’un ensemble d’indicateurs d’attrition et de qualité de remplissage pour une batterie psychologique comportant cinq dimensions obligatoires (Item1 à Item5) :
DATA EvaluationQualite_Donnees;
SET Questionnaire_Source;
/* Calcul du nombre de réponses manquantes sur la ligne */
Nb_Items_Manquants = NMISS(Item1, Item2, Item3, Item4, Item5);
/* Calcul du nombre de réponses valides documentées */
Nb_Items_Valides = N(Item1, Item2, Item3, Item4, Item5);
/* Dérivation du taux individuel de complétude */
TauxCompletude = (Nb_Items_Valides / 5) * 100;
/* Création d’un indicateur booléen d’incomplétude critique (plus de 20% manquant) */
IF TauxCompletude >= 80 THEN DO;
ProtocoleValideFlag = 1;
/* Calcul autorisé du score moyen imputé proportionnellement */
ScoreSynthese = MEAN(OF Item1-Item5);
END;
ELSE DO;
ProtocoleValideFlag = 0;
/* Neutralisation délibérée du score pour non-conformité */
ScoreSynthese = .M; /* Utilisation de la valeur manquante spéciale .M pour ‘Missing’ */
END;
RUN;
Dans ce scénario, la variable booléenne ProtocoleValideFlag partitionne sans ambiguïté les observations éligibles des profils non conformes. L’assignation de la valeur manquante spéciale .M à la variable ScoreSynthese documente explicitement la raison de l’absence de score lors des audits statistiques postérieurs, distinguant une invalidation méthodologique d’une omission purement accidentelle de saisie brute dans la base de données.
12. Bonnes pratiques, documentation et validation des nouvelles variables
12.1 Documentation sémantique : instructions LABEL et FORMAT
La génération technique d’une nouvelle variable au sein de l’étape DATA ne saurait être considérée comme achevée sans une formalisation documentaire rigoureuse inscrite au cœur même de la table des descripteurs. Des noms de variables informatiques courts (tels que SC_TOT_ADJ ou GAD7_CAT) s’avèrent cryptiques pour des auditeurs externes ou des co-investigateurs. L’instruction LABEL permet d’associer à chaque variable une étiquette sémantique descriptive explicite pouvant atteindre 256 caractères.
Conjointement aux étiquettes textuelles, l’attribution de règles d’affichage personnalisées via l’instruction FORMAT confère une lisibilité immédiate aux données brutes sans altérer leur valeur sous-jacente. Grâce à la procédure PROC FORMAT, l’analyste peut préalablement cartographier des entiers numériques discrets vers des libellés verbaux explicites (par exemple, 0 = ‘Non exposé’, 1 = ‘Exposé thérapeutique’), puis lier ce format à la nouvelle variable créée dans l’étape DATA.
L’intégration systématique des instructions LABEL et FORMAT enrichit le dictionnaire de données interne de la table SAS. Lors de l’édition automatique des rapports de synthèse statistique via les procédures PROC FREQ, PROC MEANS ou PROC TABULATE, SAS substitue par défaut les noms de codes austères par ces libellés documentés, éliminant ainsi les risques d’incompréhension ou de contresens analytique lors de la diffusion des résultats empiriques.
12.2 Optimisation des tables : instructions KEEP et DROP
Au fil du déroulement d’une étape DATA complexe, un nombre important de variables secondaires, d’accumulateurs temporaires, d’indices de boucles itératives et de constantes intermédiaires sont instanciés dans le PDV pour achever les calculs finaux. Si ces variables accessoires sont conservées dans la table finale, elles augmentent inutilement le volume physique du fichier sur disque et ralentissent considérablement les opérations d’entrée/sortie (I/O) lors des procédures analytiques ultérieures.
Les instructions DROP et KEEP (ainsi que leurs options de table homologues DROP= et KEEP=) permettent d’élaguer sélectivement le vecteur de sortie. L’instruction DROP énumère l’ensemble des colonnes parasites à exclure de l’écriture sur disque, tandis que l’instruction KEEP spécifie restrictivement les seules variables autorisées à intégrer la table finale. Sur le plan de la maintenance, KEEP est généralement préférable dans les tables de livraison analytique finale : elle immunise la structure contre l’adjonction inopinée de variables parasites non documentées.
Il est capital de différencier l’instruction autonome DROP/KEEP placée au corps de l’étape DATA de l’option de table (DROP= / KEEP=) accolée à l’instruction DATA ou SET. L’option de table SET Echantillon(KEEP= ID Age Score); n’extrait du disque dur vers le PDV que les trois colonnes désignées, allégeant instantanément la bande passante mémoire du système dès la phase de lecture initiale, ce qui représente un levier d’optimisation majeur pour le traitement du Big Data ou des données génomiques massives.
12.3 Procédures de contrôle qualité et audit empirique
La dernière étape, indissociable de toute création de variable dans un cadre académique ou industriel réglementé, consiste à valider empiriquement le comportement des nouvelles distributions numériques et qualitatives générées. L’analyste ne doit jamais présumer de l’exactitude de ses formules d’assignation sans soumettre immédiatement la table résultante à des procédures de contrôle qualité automatisées.
Pour les variables quantitatives continues nouvellement dérivées, l’exécution conjointe des procédures PROC MEANS et PROC UNIVARIATE permet de passer au crible les valeurs extrêmes, les minima et maxima théoriques, les quartiles ainsi que les indices d’asymétrie et d’aplatissement (skewness et kurtosis). Une valeur minimale négative sur un score de durée ou une valeur maximale excédant l’intervalle nominal d’une échelle signale instantanément une anomalie algorithmique sous-jacente dans l’étape DATA.
Pour les variables qualitatives et les stratifications conditionnelles issues de structures IF-THEN/ELSE ou SELECT-WHEN, la procédure PROC FREQ constitue l’instrument d’audit par excellence. La mise en œuvre de tables de contingence à double entrée croisant la variable d’origine et la nouvelle variable catégorisée (ex: TABLES VariableOrigine * NouvelleCategorie / LIST MISSING;) permet de vérifier l’étanchéité des intervalles, la distribution exacte des effectifs et l’absence totale de données orphelines égarées dans des catégories d’erreurs, parachevant ainsi la validation scientifique du processus d’ingénierie des données.
Références
- Cody, R. (2018). Learning SAS by Example: A Programmer’s Guide (2nd ed.). SAS Institute Inc. https://support.sas.com/en/books.html
- Delwiche, L. D., & Slaughter, S. J. (2019). The Little SAS Book: A Primer (6th ed.). SAS Institute Inc. https://support.sas.com/en/books.html
- Institut National de la Statistique et des Études Économiques. (2021). Bonnes pratiques de programmation sous SAS pour la statistique publique. Insee Méthodes. https://www.insee.fr/
- SAS Institute Inc. (2020). SAS 9.4 Language Reference: Concepts (6th ed.). SAS Institute Inc. https://support.sas.com/documentation/cdl/en/lrcon/69852/HTML/default/viewer.htm
- SAS Institute Inc. (2023). Base SAS 9.4 Procedures Guide: Statistical Procedures (5th ed.). SAS Institute Inc. https://support.sas.com/documentation/cdl/en/procstat/69629/HTML/default/viewer.htm
- UCLA: Statistical Consulting Group. (2022). Creating and Recoding Variables in SAS Data Step. UCLA Advanced Research Computing. https://stats.oarc.ucla.edu/sas/