SAS Viya ne remplace pas SAS 9 par une mise à niveau technique. La plateforme change le modèle d’exécution, l’administration, le stockage des métadonnées et la façon de préparer une migration SAS. Vous devez donc inventorier les traitements, qualifier les écarts de compatibilité et organiser une recette chiffrée avant toute bascule.
En bref
- SAS 9 repose principalement sur des serveurs spécialisés et des traitements souvent centralisés, tandis que SAS Viya s’appuie sur une architecture cloud conteneurisée et des services distribués.
- La compatibilité du code SAS doit être vérifiée objet par objet, car un programme Base SAS, un flux DI Studio et un rapport Visual Analytics ne suivent pas les mêmes chemins de reprise.
- Une migration SAS doit commencer par les usages réels, les dépendances de données et les règles de gestion, non par le déploiement de la cible technique.
- Le calcul distribué peut réduire certains temps de traitement, mais il ne corrige ni les données incohérentes ni les règles de calcul enfouies dans d’anciens programmes.
Ce contenu s’adresse aux responsables BI, administrateurs SAS et chefs de projet qui préparent le passage de SAS 9 vers SAS Viya. Il traite des socles décisionnels, des flux, des rapports et de la recette. Les sujets de sécurité d’infrastructure, de protection des données personnelles et de négociation contractuelle relèvent de spécialistes distincts.
Comment l’architecture de SAS Viya change le fonctionnement de SAS 9
SAS 9 est construit autour d’un ensemble de composants historiques. Le serveur de métadonnées, les serveurs de calcul, les serveurs de contenu, les bibliothèques SAS et les outils clients forment un environnement cohérent, mais souvent fortement dépendant de l’installation initiale. Dans de nombreux parcs, les traitements batch, les programmes SAS, les flux ETL et les rapports cohabitent depuis plusieurs années sur les mêmes serveurs.
SAS Viya adopte une logique différente. La plateforme s’appuie sur des services déployés dans des conteneurs et orchestrés par Kubernetes. Ce point ne doit pas être traité comme un détail d’exploitation. Il modifie le déploiement, la supervision, la montée de version et la répartition des traitements. La documentation SAS décrit cette organisation dans sa présentation de SAS Viya et de ses services de plateforme, consultée en 2026.
Dans SAS 9, un programme lancé depuis Enterprise Guide ou en batch s’exécute fréquemment sur un serveur SAS identifié. Les journaux, les fichiers temporaires et les bibliothèques de travail sont alors liés à cette exécution précise. Dans SAS Viya, plusieurs services coopèrent. CAS, pour Cloud Analytic Services, constitue le moteur de calcul distribué le plus visible. Il charge les données en mémoire, répartit les calculs et restitue les résultats aux applications qui en ont besoin.
Ce changement apporte une capacité de calcul adaptée à des volumes plus élevés ou à des traitements parallélisables. Il ne faut toutefois pas promettre une accélération mécanique. Un programme SAS qui lit ligne par ligne des fichiers locaux, multiplie les tris intermédiaires ou appelle des macros dépendantes d’un répertoire partagé ne devient pas distribué par sa seule exécution dans une nouvelle plateforme. La performance dépend du code, du stockage, du réseau et du mode de chargement des tables dans CAS.
Les composants qui doivent être cartographiés avant une migration SAS
Une architecture SAS 9 contient rarement un seul point d’entrée. Les équipes utilisent parfois SAS Management Console pour les métadonnées, Enterprise Guide pour l’exécution interactive, DI Studio pour les flux, Web Report Studio ou SAS Visual Analytics pour la restitution. Il faut aussi relever les tâches planifiées, les fichiers de configuration, les comptes techniques et les connexions aux bases de données.
Le tableau suivant croise les objets les plus fréquents avec leur traitement lors d’un passage vers SAS Viya. Il ne constitue pas une garantie de reprise automatique. Il sert à dimensionner l’inventaire et à éviter de classer tous les objets dans une même catégorie de difficulté.
| Objet source SAS 9 | Fonction dans le socle | Traitement envisagé dans SAS Viya | Point de contrôle de compatibilité |
|---|---|---|---|
| Programme Base SAS | Préparation, calcul ou édition batch | Conservation, adaptation ou conversion partielle | Accès fichiers, macros, bibliothèques et sorties ODS |
| Flux SAS Data Integration Studio | Intégration données et ordonnancement | Reconstruction dans les outils retenus | Mappings, reprises, dépendances et planification |
| Rapport SAS Visual Analytics | Restitution interactive | Reprise fonctionnelle dans SAS Viya | Filtres, agrégats, droits et calculs d’objets |
| Métadonnées SAS 9 | Référentiel d’objets et d’autorisations | Analyse sélective et recréation contrôlée | Groupes, rôles, dossiers et connexions techniques |
Ce tableau doit être complété par les objets moins visibles. Une condition dans un rapport, une table de correspondance maintenue à la main ou une macro appelée par un ordonnanceur peuvent porter une règle de gestion déterminante. La partie la plus coûteuse n’est pas toujours celle qui apparaît dans les catalogues d’objets.
L’architecture cloud de SAS Viya doit donc être évaluée comme un changement d’exploitation et de fonctionnement, pas comme un simple remplacement de serveurs. Le prochain travail porte sur les écarts fonctionnels, car une plateforme unifiée ne supprime pas les dépendances accumulées dans le socle existant.
Quelles différences entre SAS 9 et SAS Viya affectent vos traitements décisionnels
La première différence concerne le modèle de calcul. SAS 9 exécute traditionnellement les programmes sur des serveurs SAS avec une logique éprouvée de bibliothèques, de tables WORK et de traitements batch. SAS Viya peut continuer à exécuter une partie du code SAS, mais son moteur CAS introduit une autre manière de charger, transformer et analyser les données. Une table CAS n’est pas une table SAS locale. Son comportement, son emplacement et son cycle de vie doivent être documentés.
Le second écart concerne les interfaces. SAS 9 a fait cohabiter plusieurs clients selon les générations de produits. SAS Enterprise Guide, SAS Display Manager, DI Studio, SAS Management Console et les portails web ne partagent pas tous les mêmes usages. SAS Viya recentre les parcours autour d’applications web et d’une plateforme unifiée. Cette convergence est utile pour l’administration des contenus, mais elle impose de revoir les habitudes de production et de support.
Un troisième point porte sur la persistance des données. Dans un fonctionnement CAS, les tables en mémoire peuvent être chargées pour une session ou rendues disponibles plus durablement selon le paramétrage retenu. L’équipe projet doit décider quels jeux sont permanents, quels jeux sont recalculés et quelles sources restent de référence. Sans cette décision, une anomalie de redémarrage peut être interprétée à tort comme un défaut de données alors qu’elle résulte d’une table non rechargée.
La compatibilité du code SAS ne se mesure pas au nombre de fichiers
La compatibilité ne signifie pas que chaque programme SAS 9 doit être recopié dans SAS Viya. Un inventaire de mille fichiers .sas ne dit rien sur leur niveau de criticité. Une partie peut être inactive, dupliquée ou limitée à des extractions ponctuelles. À l’inverse, un programme court peut alimenter une mesure financière utilisée dans plusieurs rapports.
Le classement utile repose sur des critères concrets. Il faut identifier les programmes exécutés sur douze mois, leur fréquence, les tables sources, les tables produites, les dépendances externes et les utilisateurs qui valident le résultat. Les journaux d’ordonnancement et les métadonnées apportent une première lecture. Ils doivent être rapprochés des usages métiers, car un traitement trimestriel peut ne pas apparaître dans une fenêtre d’observation trop courte.
- Les programmes qui utilisent uniquement des procédures SAS standard et des bibliothèques relationnelles sont souvent plus faciles à conserver, sous réserve de vérifier les accès et les sorties.
- Les traitements qui reposent sur des fichiers locaux, des commandes système ou des macros partagées demandent une analyse d’exploitation détaillée.
- Les flux provenant de SAS Data Integration Studio doivent être examinés au niveau des transformations, pas seulement au niveau du nombre de jobs.
- Les rapports Visual Analytics doivent être comparés sur leurs filtres, leurs agrégats et leurs droits avant toute validation utilisateur.
Un rapport de synthèse peut afficher un écart faible tout en masquant une anomalie forte sur une population précise. Un filtre de statut, une exclusion géographique ou une règle sur les dates de validité doit être testé sur des échantillons ciblés. La recette ne consiste donc pas à comparer une seule ligne de total. Elle doit expliquer tout écart supérieur à la tolérance convenue.
Pour les restitutions, l’analyse des usages de SAS Visual Analytics dans un socle décisionnel aide à séparer les tableaux réellement pilotés des contenus consultés de façon marginale. Cette distinction évite de financer la reprise de rapports qui ne portent plus aucune décision.
Le passage vers une analytique moderne ne doit pas effacer les contrôles déjà acquis. Il doit rendre visibles les règles de calcul, les dépendances de sources et les responsabilités de validation qui étaient parfois dispersées dans SAS 9.
Comment inventorier un périmètre de migration SAS avant de choisir la cible
Une migration SAS commence par un relevé d’usage, non par l’installation de SAS Viya. Cette séquence peut sembler administrative, mais elle détermine la charge réelle. Un parc riche de plusieurs centaines de programmes contient souvent des doublons, des traitements abandonnés et des chaînes qui n’ont plus de destinataire connu. Reprendre cet ensemble sans tri revient à déplacer la dette décisionnelle vers une plateforme plus récente.
Le périmètre doit inclure les traitements, les données, les restitutions et les droits. Il faut aussi intégrer les mécanismes d’automatisation. Un job planifié hors de SAS, un script shell déclenché par un ordonnanceur ou une extraction déposée sur un partage réseau ne figurent pas toujours dans les métadonnées SAS. Pourtant, leur absence peut bloquer un processus de clôture ou une alimentation de tableau de bord.
La documentation officielle SAS recommande de préparer la migration en évaluant les contenus et les scénarios d’évolution. Le point utile est moins le terme de modernisation que la nécessité de choisir entre coexistence, reprise progressive et remplacement de composants. Les parcours présentés par SAS pour la migration vers Viya, consultés en 2026, confirment que l’adoption peut être graduelle selon les produits et les usages.
Un calcul de charge doit isoler la reprise technique de la recette
Une estimation sans hypothèses ne permet aucun arbitrage. Prenons un périmètre de 180 programmes SAS, 45 flux d’intégration et 60 rapports. Supposons que 90 programmes soient conservés avec une adaptation légère de 3 heures, que 50 demandent 10 heures d’analyse et d’adaptation, et que 40 soient arrêtés après validation métier. La charge des programmes atteint alors 770 heures, soit 90 × 3 plus 50 × 10.
Ajoutons 45 flux à reconstruire ou à remplacer. Avec un ratio de 18 à 35 heures par flux, incluant analyse du mapping et reprise technique mais excluant recette métier, le volume représente 810 à 1 575 heures. Pour 60 rapports, un ratio de 6 à 14 heures selon le niveau de calcul et de sécurité conduit à 360 à 840 heures. Le périmètre technique se situe donc entre 1 940 et 3 185 heures, avant recette complète, formation, reprise des habilitations et conduite du changement.
Ces ratios sont des hypothèses de chiffrage, pas des tarifs ni une promesse de calendrier. Ils deviennent insuffisants si les règles de gestion ne sont pas documentées ou si la qualité des données doit être corrigée pendant le chantier. Ils peuvent être revus à la baisse lorsque les objets non utilisés sont retirés après validation formelle.
Le découpage suivant permet de produire un inventaire exploitable par un comité de pilotage.
- Extraire les listes de programmes, flux, rapports, bibliothèques et comptes techniques depuis les outils disponibles.
- Rapprocher ces listes des logs d’exécution et de consultation sur une période couvrant les cycles mensuels, trimestriels et annuels.
- Qualifier chaque objet selon son usage, son propriétaire métier, ses sources et son niveau de risque.
- Classer les objets en arrêt, maintien temporaire, adaptation ou reconstruction.
- Chiffrer séparément l’analyse, la reprise technique, la recette, les droits et l’exploitation.
Le point d’arrêt est clair. Si aucun propriétaire métier ne valide un objet et si les logs confirment son absence d’usage sur une période suffisante, cet objet ne doit pas entrer automatiquement dans la migration SAS. Le bon périmètre n’est pas celui qui contient tout l’historique, mais celui qui soutient encore le pilotage réel.
Comment organiser la recette entre SAS 9 et SAS Viya sans promettre des chiffres identiques
La bascule ne doit jamais reposer sur l’affirmation que SAS Viya produira exactement les mêmes chiffres que SAS 9. Cette promesse est difficile à tenir et dangereuse dans un contexte financier ou opérationnel. Une différence de moteur, de type de données, d’arrondi, de filtre ou de date de chargement peut générer un écart. Le travail de recette consiste à qualifier cet écart, à le mesurer et à obtenir son acceptation documentée.
La première étape consiste à définir une population de contrôle. Pour un indicateur de chiffre d’affaires, il faut préciser les entités concernées, la période, le statut des écritures, la devise, la date de référence et les exclusions. Comparer deux totaux sans fixer ces paramètres conduit à des débats sans fin. Les équipes se retrouvent à corriger le rapport cible alors que l’écart vient d’une règle déjà présente dans le traitement historique.
Le protocole de comparaison doit être appliqué aux données détaillées avant les restitutions. Une table de rapprochement peut comparer les clés métiers, les montants, les statuts et les dates. Les lignes absentes de l’un des deux environnements doivent être comptées puis réparties par cause. Une date de chargement différente, une valeur non convertie ou une jointure qui produit des doublons ne relèvent pas du même correctif.
Le double run sert à arbitrer, pas à retarder indéfiniment la bascule
Un double run consiste à produire simultanément les résultats SAS 9 et SAS Viya sur un même cycle de données. Cette phase doit avoir une durée définie et des critères de sortie. Sans seuil de tolérance, les équipes peuvent discuter longtemps sur des écarts faibles qui ne modifient aucune décision. Sans contrôle détaillé, un écart majeur peut être dilué dans un total global acceptable.
Pour un indicateur financier, la tolérance peut être fixée à zéro sur le total consolidé et à une valeur limitée sur les écarts d’arrondi. Pour un indicateur commercial, une tolérance peut être exprimée en nombre de lignes, en pourcentage de population ou en montant. La règle doit être validée par le responsable de l’indicateur avant les tests. Elle ne peut pas être décidée le jour où un écart apparaît.
Les tests doivent couvrir les cas attendus et les exceptions. Une période vide, un changement d’organisation, un client inactif, une devise inhabituelle ou une annulation tardive peuvent révéler une condition oubliée. Les données historiques ne suffisent pas toujours. Il faut également tester les scénarios qui ont posé problème dans le passé, car ils concentrent souvent les règles implicites.
La restitution a son propre niveau de contrôle. Un rapport peut utiliser une mesure correcte et afficher une lecture erronée si l’agrégation, le filtre de page ou le droit d’accès diffère. Les rapports de SAS Visual Analytics doivent donc être validés sur les objets visuels, les sélections et les profils utilisateurs. Une recette réalisée uniquement par un administrateur ne remplace pas la validation des utilisateurs responsables des chiffres.
La séquence suivante offre un cadre opérationnel. Les équipes comparent d’abord les sources et les volumes, puis les jeux détaillés, ensuite les agrégats et enfin les écrans. Chaque anomalie reçoit une cause, un responsable, une date de correction et une décision de validation. La bascule devient alors un arbitrage documenté plutôt qu’une décision fondée sur l’impression générale que les tableaux semblent corrects.
Une migration réussie ne produit pas une identité abstraite entre deux environnements. Elle produit des écarts connus, expliqués, bornés et acceptés par les personnes qui utilisent les indicateurs.
Dans quels cas faut-il conserver une coexistence entre SAS 9 et SAS Viya
Le remplacement complet de SAS 9 n’est pas toujours le premier choix rationnel. Certaines organisations disposent de programmes batch stables, d’interfaces anciennes ou de dépendances applicatives qui ne peuvent pas être reprises dans le même calendrier que les nouveaux besoins décisionnels. Une coexistence temporaire peut réduire le risque, à condition d’être limitée dans son périmètre et dans sa durée.
La coexistence devient coûteuse lorsqu’elle maintient deux référentiels de règles, deux circuits d’habilitation et deux chaînes de production sans trajectoire de sortie. Elle reste utile lorsque SAS 9 porte des traitements réglementés ou très spécifiques, pendant que SAS Viya accueille de nouveaux usages d’analyse, de visualisation ou de calcul distribué. La frontière doit être écrite. Sans cette discipline, les nouveaux développements continuent de partir dans l’ancien socle par habitude.
Le choix dépend aussi de la maturité des composants existants. Un programme SAS stable n’est pas nécessairement un programme à migrer immédiatement. S’il est peu modifié, documenté, couvert par des contrôles et exécuté dans une fenêtre maîtrisée, son maintien transitoire peut être moins risqué qu’une réécriture précipitée. En revanche, un flux difficile à maintenir, dépendant d’outils abandonnés ou d’administrateurs rares doit être traité en priorité.
Une plateforme unifiée n’efface pas les responsabilités d’exploitation
SAS Viya réunit des services de calcul, de contenu, d’intégration données et d’administration dans une même plateforme unifiée. Cette organisation facilite certains échanges entre équipes. Elle ne remplace pas les responsabilités de production. Les équipes doivent définir qui administre les identités, qui contrôle les chargements CAS, qui surveille les traitements, qui valide les mises à jour et qui pilote la consommation des ressources.
La question de l’automatisation doit également être examinée avec précision. Un job planifié dans SAS 9 peut dépendre d’un calendrier métier, d’un fichier attendu ou d’un traitement externe. Le déplacer dans un nouvel outil sans reconstituer ses préconditions crée un risque de production. Il faut relever la fréquence, la fenêtre d’exécution, les dépendances amont, les contrôles de fin et les destinataires des alertes.
Un scénario raisonnable consiste à migrer d’abord un domaine dont les données, les responsables métiers et les indicateurs sont clairement identifiés. Les résultats de recette servent alors à ajuster le protocole avant d’aborder des domaines plus sensibles. Cette démarche ne constitue pas une promesse de délai. Elle réduit surtout la probabilité de découvrir en fin de programme une règle majeure que personne n’avait documentée.
Il faut aussi accepter le cas inverse. Si le volume actif est faible, si les rapports sont vieillissants et si les règles sont peu récupérables, la reconstruction sélective peut coûter moins cher que la reprise détaillée. À l’inverse, un parc important de traitements critiques, avec des règles accumulées depuis longtemps, justifie souvent une analyse de compatibilité plus poussée et une coexistence contrôlée.
Avant de décider, sortez les journaux d’exécution et de consultation sur douze mois, puis associez chaque objet à un responsable métier. Le dimensionnement de la migration SAS dépend d’abord de cette preuve d’usage, bien avant le nombre de serveurs ou de licences affiché dans l’inventaire technique.
SAS Viya remplace-t-il automatiquement tous les outils SAS 9 ?
Non. Les programmes, flux, rapports, métadonnées et mécanismes d’ordonnancement doivent être évalués séparément. Certains objets peuvent être conservés temporairement, adaptés, reconstruits ou arrêtés après validation métier.
Le code Base SAS est-il compatible avec SAS Viya ?
Une partie du code peut être conservée, mais la compatibilité doit être contrôlée pour les accès fichiers, les macros, les bibliothèques, les sorties ODS, les commandes système et les traitements dépendants du serveur historique.
Pourquoi faut-il réaliser un double run entre SAS 9 et SAS Viya ?
Le double run permet de comparer les résultats sur une même période de données, de quantifier les écarts et d’en identifier la cause. Il ne sert pas à promettre une identité parfaite entre les deux environnements.
Faut-il migrer tous les rapports SAS Visual Analytics ?
Non. Les logs de consultation, la fréquence d’usage et la validation des responsables métiers doivent déterminer le périmètre. Un rapport non consulté ou remplacé par un autre ne doit pas être repris par défaut.
Le dossier complet Chantiers de migration : chiffrer la charge et sécuriser la bascule
