Démarrer avec la programmation SAS : concepts de base et bonnes pratiques

Cet article en deux mots :

Plongez dans l'univers de la programmation SAS et maîtrisez les fondamentaux de l'analyse de données. De la structure des étapes DATA aux astuces de débogage dans la Log, ce guide pratique vous donne les clés pour écrire un code propre, documenté et efficace dès votre premier script.

Si l'on vous parle de « SAS », vous pensez peut-être spontanément à une compagnie aérienne scandinave ou aux forces spéciales britanniques prêtes à sauter en parachute... Rassurez-vous, sur nicolas-housset.fr, on ne vous demandera pas de sauter d'un avion en vol ! SAS est en réalité un logiciel d'analyse de données extrêmement puissant.


Contrairement à la plupart des logiciels modernes qui vous prennent par la main avec des tas de boîtes de dialogue et de boutons clignotants, SAS est beaucoup moins « convivial » de ce point de vue. Ici, pas de clics magiques : le système attend de vous que vous écriviez un programme et que vous le soumettiez à son moteur d'exécution. Pourquoi ce côté austère ? Parce que dans le monde réel (et la recherche), les projets durent longtemps et sont gérés par des équipes entières : avoir un script codé de A à Z permet de garder une trace exacte de toutes les manipulations de données et analyses effectuées.


Préparez vos claviers, on plonge dans les bases !

1. L'anatomie d'un programme SAS : L'étape DATA et l'étape PROC

Un programme SAS classique se divise souvent en deux grandes phases : l'étape DATA (pour créer, lire ou manipuler les données) et l'étape PROC (pour exécuter des procédures spécifiques comme faire des calculs ou afficher des tableaux).

Le langage SAS n'est pas sensible à la casse (majuscules ou minuscules n'ont pas d'importance). Cependant, une bonne pratique de programmation consiste à écrire les mots-clés du langage SAS en MAJUSCULES et vos propres noms de variablesColonnes d'une table SAS contenant des données spécifiques (numériques ou caractères). Elles possèdent des attributs comme le nom, le type, la longueur, l'étiquette et le format d'affichage. ou de tables en minuscules pour faciliter la lecture. Les noms de variablesColonnes d'une table SAS contenant des données spécifiques (numériques ou caractères). Elles possèdent des attributs comme le nom, le type, la longueur, l'étiquette et le format d'affichage. (et de jeux de données) sont limités à 32 caractères et peuvent contenir des lettres, des chiffres et des tirets du bas _, à condition de ne jamais commencer par un chiffre.


Voici un programme d'exemple 100% franchouillard pour analyser une fromagerie :

SAS


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/* Auteur : Nicolas Housset
Date de création : Aujourd'hui
Objectif : Premier programme SAS - Gestion d'une fromagerie
*/


* -- ÉTAPE DATA : Création du jeu de données -- ;
DATA table_fromages;
* Le symbole $ indique que nom_fromage est une variable de type texte ;
* Les chiffres 1-12 indiquent la position des caractères ;
INPUT nom_fromage $ 1-12 poids_kg prix_euro;

* Création d'une nouvelle variable avec un calcul arithmétique simple ;
prix_au_kg = prix_euro / poids_kg;

* Insertion des données brutes en ligne ;
DATALINES;
Camembert 0.25 3.50
Roquefort 0.20 4.20
Comte 0.30 6.00
Maroilles 0.50 7.50
;
RUN;

* -- ÉTAPE PROC : Affichage du jeu de données -- ;
PROC PRINT DATA = table_fromages;
TITLE "
Ma liste de Fromages Français";
RUN;


Note technique : Pour lire des variablesColonnes d'une table SAS contenant des données spécifiques (numériques ou caractères). Elles possèdent des attributs comme le nom, le type, la longueur, l'étiquette et le format d'affichage. textuelles, il est impératif de placer le symbole $ juste après le nom de la variable dans l'instruction INPUT.


2. L'art du Point-Virgule et des Commentaires (Les commandements du bon codeur)

Si vous ne deviez retenir qu'une seule règle vitale en SAS : chaque instruction se termine impérativement par un point-virgule.


L'erreur la plus fréquente en SAS, même pour les experts, est d'oublier ce fameux point-virgule. Que se passe-t-il alors ? SAS va tout simplement continuer à lire la ligne suivante en pensant qu'il s'agit de la suite de la même instruction jusqu'à ce qu'il croise enfin un point-virgule. Cela déclenche des erreurs de syntaxe particulièrement frustrantes, et c'est à vous de repérer que l'erreur vient d'un oubli à la ligne précédente. À l'inverse, ce fonctionnement permet d'écrire plusieurs instructions sur une même ligne, tant que chacune a son point-virgule.


La seconde bonne pratique est de commenter généreusement votre code. Il existe deux façons de le faire en SAS :


  1. Les commentaires d'une seule ligne qui commencent par une étoile * et se terminent par un point-virgule ;.

  2. Les blocs de commentaires (idéals pour les en-têtes) qui commencent par /* et se terminent par */, sans avoir besoin de point-virgule.

Ces commentaires sont cruciaux pour garder une trace des modifications (qui a écrit le script, quand et pourquoi) et pour le travail en équipe.


3. Ne fuyez pas la SAS Log : Lisez le journal !

Une fois que vous avez écrit et soumis votre programme, le premier réflexe d'un bon développeur SAS n'est pas de regarder le résultat, mais de se précipiter sur la fenêtre Log (le journal).


C'est ici que SAS vous raconte comment il a traité vos requêtes, avec un code couleur. Vous y trouverez :



  • Des Notes (Notes) : Généralement de bonnes nouvelles, elles vous informent que tout s'est bien passé.


  • Des Avertissements (Warnings) : Des éléments potentiellement inquiétants que le logiciel a réussi à contourner, mais que vous devriez vérifier.


  • Des Erreurs (Errors) : Le drame... Elles vous expliquent pourquoi le programme a échoué.

Comme dans toute programmation, il est très rare qu'un programme fonctionne parfaitement du premier coup. Comprendre ce que le journal essaie de vous dire est une compétence indispensable pour corriger vos bugs.


💡 L'astuce du pro : Nettoyez vos fenêtres ! Lorsque vous modifiez et relancez votre programme à plusieurs reprises pour le corriger, la fenêtre Log et la fenêtre de Résultats vont accumuler des tonnes de textes obsolètes. Pour éviter de vous emmêler les pinceaux et de lire une vieille erreur par accident, il est fortement conseillé d'effacer tout le contenu de vos fenêtres avant de soumettre à nouveau votre code final.


Si vous maîtrisez l'étape DATA, les procédures de base, la chasse aux points-virgules et la lecture attentive de la Log, vous êtes déjà sur la voie rapide pour devenir un as de la programmation SAS !

Nicolas Housset

Passionné d'informatique, je suis Consultant et expert technique SAS VIYA, également co-fondateur de la société Flexcelite. Spécialisé dans les technologies SAS (Viya, 9.4) et les infrastructures associées (Linux, Hadoop, Azure), ce blog est mon espace pour partager mes mémos techniques et retours d'expérience.