Migration SAS vers Python/R ou SAS Viya : comment décider en 2026

Le coût des licences SAS grimpe, les experts SAS se raréfient, et l'envie d'ouvrir à l'écosystème Python/R se fait pressante. La question « faut-il quitter SAS ? » se pose dans presque toutes les directions data de la banque, de l'assurance, de la pharma et du secteur public. La mauvaise réponse n'est pas de rester ou de partir — c'est de décider à l'aveugle. Voici comment trancher avec méthode.

Trois trajectoires, pas deux

On présente souvent le choix comme binaire : garder SAS ou tout réécrire en Python. La réalité offre une troisième voie, souvent la meilleure :

• Rester sur SAS 9 — pertinent pour les traitements réglementés et critiques déjà validés.
• Moderniser vers SAS Viya — conserver le patrimoine SAS tout en gagnant le cloud, le calcul distribué, l'IA et l'interopérabilité Python/R.
• Migrer vers Python/R — faire disparaître la licence sur les traitements éligibles, au prix d'un effort de réécriture et de validation.

La bonne décision n'est presque jamais « tout l'un » ou « tout l'autre ». C'est un arbitrage traitement par traitement, fondé sur la criticité, le coût et le risque.

Commencer par l'audit du parc, jamais par l'outil

Avant toute décision, il faut cartographier l'existant : inventaire des programmes, des jobs, des dépendances et des usages réels (beaucoup de programmes SAS tournent encore sans que personne ne lise leurs résultats). Cet audit chiffre l'effort de migration, identifie les quick wins — les traitements simples qui peuvent sortir vite et alléger la facture — et isole les zones sensibles à ne pas toucher. C'est la même rigueur que notre démarche d'audit de contrats logiciels.

Le piège : la biostatistique réglementée

En pharma et clinique, les analyses et les soumissions FDA/EMA reposent sur la validation et la traçabilité de SAS. Y migrer pour économiser une licence peut coûter infiniment plus cher en risque réglementaire. Sur ce périmètre, la prudence est la règle : on n'y touche que par étapes très contrôlées, ou pas du tout. C'est précisément là qu'un prestataire « 100 % Python », qui pousse à tout réécrire, devient dangereux.

Le coût des licences : modéliser avant de bouger

L'argument numéro un de la sortie de SAS est financier. Encore faut-il le chiffrer correctement : économies de licences nettes du coût de réécriture, de validation et de montée en compétence des équipes. Sur un périmètre bien choisi, le retour sur investissement est rapide ; sur un périmètre mal choisi, la migration coûte plus qu'elle ne rapporte. La modélisation honnête des deux scénarios est le cœur de la décision.

Pourquoi l'indépendance change tout

Un revendeur SAS vous dira de rester. Un intégrateur Python vous dira de partir. Les deux ont un biais. Sextant est intégrateur et revendeur SAS et spécialiste de l'audit et de la migration : nous connaissons SAS de l'intérieur, donc nous savons exactement ce qu'il fait de mieux — et quand le quitter est justifié. C'est ce qui rend notre verdict crédible.

Si la question de sortir de SAS se pose chez vous, commencez par la regarder en face, chiffres à l'appui : découvrez notre approche dédiée sur la page alternative à SAS, ou demandez un audit de votre parc.