Le contexte : pourquoi tant d'organisations migrent
SAS 9 est une plateforme solide, stable et massivement déployée dans les secteurs réglementés (banque, assurance, pharma, secteur public). Mais depuis 2020, la convergence de plusieurs facteurs accélère les migrations vers des plateformes modernes comme Dataiku :
- Coût de la licence SAS : pour les grandes organisations, les coûts de maintenance annuels sont devenus difficiles à justifier au moment des revues budgétaires - Pression réglementaire : les régulateurs (notamment la BCE et l'ACPR en France) poussent à des architectures plus transparentes et auditables, ce que les notebooks SAS ne facilitent pas - Recrutement : il est plus facile de recruter des Data Scientists maîtrisant Python et Spark que des experts SAS en 2026 - Capacités IA : SAS Viya propose des capacités ML/IA, mais Dataiku bénéficie d'une intégration native avec les LLMs et les frameworks open source modernes
Les coûts visibles (ceux que vous budgétez)
Avant d'arriver aux coûts cachés, rappelons les coûts que la plupart des organisations budgètent correctement :
- Licence Dataiku : typiquement 150 000 à 400 000€ annuels selon la taille de l'organisation et le nombre d'utilisateurs (les prix varient significativement selon les négociations) - Formation initiale : Dataiku Academy, certification Practitioner, sessions en présentiel. Budget : 1 500 à 3 000€ par utilisateur - Infrastructure : serveur(s) Dataiku DSS ou déploiement cloud. Budget : 30 000 à 80 000€ selon les dimensions - Intégration technique : connexion aux sources de données existantes, authentification SSO, intégration avec le Data Warehouse. Budget : 20 000 à 50 000€
Les coûts cachés : ce que personne ne dit en avant-vente
1. Le recodage du code SAS legacy : le poste le plus sous-estimé
La migration du code SAS vers Python/Spark est rarement une traduction mécanique. SAS a ses propres paradigmes (DATA step, PROC, macro variables, ODS) qui n'ont pas d'équivalents directs.
Coût réel observé : entre 3 et 8 fois le coût estimé initialement. Une organisation qui a 500 programmes SAS en production ne migre pas en 6 mois. Chaque programme doit être audité (est-il encore utilisé ?), compris (quelle logique métier ?), retesté et validé.
Les macro SAS sont particulièrement problématiques : ce sont essentiellement des générateurs de code dynamiques que aucun traducteur automatique ne restitue correctement. Une macro de 200 lignes peut générer 2 000 lignes de SQL/Python, avec une logique conditionnelle complexe.
2. Les procédures SAS/STAT sans équivalent open source direct
SAS/STAT et SAS/ETS incluent des centaines de procédures statistiques et économétriques que les équipes utilisent depuis des années. PROC MIXED, PROC GENMOD, PROC SURVEYLOGISTIC, PROC ARIMA, PROC X13 — certaines de ces procédures n'ont pas d'équivalents Python directs avec exactement le même comportement numérique.
Dans les secteurs réglementés, obtenir l'approbation des équipes de validation pour un modèle Python qui "produit les mêmes résultats" qu'un modèle SAS/STAT certifié peut prendre 6 à 18 mois de travail de validation. C'est un coût humain et calendaire que les roadmaps de migration ignorent systématiquement.
3. La reconversion des équipes analytiques (pas des Data Scientists)
Les équipes Data Science modernes adoptent Dataiku rapidement — c'est souvent ce qu'elles demandaient depuis des années. Le vrai défi, c'est la reconversion des analystes SAS qui utilisent SAS depuis 10 ou 20 ans et qui ne sont pas des développeurs.
Ces utilisateurs ont appris à lire et écrire du SAS. Ils ne sont pas en difficulté parce qu'ils n'ont pas les capacités : ils sont en difficulté parce que leur fluency dans SAS représente des années d'investissement. La migration Dataiku leur demande de recommencer à zéro dans un environnement différent, avec un paradigme différent.
Budget réel de reconversion (incluant le temps perdu de productivité) : 6 à 12 mois de salaire par analyste converti, selon le profil et l'accompagnement.
4. La gestion des dépendances et du périmètre "long tail"
Chaque organisation a un portefeuille de programmes SAS avec une distribution en longue traîne : 20% des programmes qui couvrent 80% des cas d'usage courants... et 80% de programmes qui sont utilisés rarement mais qui sont critiques le jour où ils le sont.
Les projets de migration migrent généralement les 20% en premier (ROI immédiat, visibilité forte). Mais les 80% restants finissent par revenir sur la table deux ans plus tard, avec des budgets épuisés et des équipes fatiguées. Le résultat fréquent : une coexistence SAS/Dataiku qui dure bien au-delà du planning initial, avec les coûts de double licence et de double maintien associés.
5. La validation réglementaire des modèles migrés
Dans les secteurs réglementés (banque, assurance), les modèles de scoring, de provisionnement ou de gestion des risques sont soumis à validation interne (équipe de validation indépendante) et parfois externe (BCE, ACPR). Un modèle qui existait en SAS depuis 5 ans et qui a été validé une fois n'a pas besoin d'être revalidé. Une fois migré en Python/Spark dans Dataiku, il doit être revalidé comme s'il était nouveau — avec toute la documentation, les tests de backtesting et les analyses de sensibilité que cela implique.
Coût : 30 000 à 150 000€ par modèle critique en coût direct de validation, plus les délais calendaires qui peuvent bloquer des projets stratégiques.
Les facteurs qui font doubler les budgets
Documentation absente ou incorrecte : le code SAS legacy de 15 ans n'est souvent pas documenté. La rétro-documentation pour comprendre la logique métier avant de migrer peut prendre autant de temps que la migration elle-même.
Données de test insuffisantes : comparer les outputs SAS et les outputs Python nécessite des données de test exhaustives, souvent couvrant des cas limites qui ne se produisent que dans certaines périodes.
Périmètre qui s'étend : une fois que le projet de migration est lancé, les parties prenantes identifient de nouvelles dépendances et de nouveaux périmètres. Le périmètre d'un projet de migration SAS rarement diminue.
Turnover des équipes : les projets de migration s'étalent sur 2 à 4 ans. Le turnover des équipes data pendant cette période implique des pertes de connaissance métier qu'il faut reconstruire.
Ce que font les projets qui réussissent
1. Audit complet avant de commencer : cartographier l'intégralité du périmètre SAS — programmes, utilisateurs actifs, fréquences d'utilisation, criticité métier — avant de définir le périmètre du projet.
2. Prioriser par valeur et non par facilité : migrer d'abord les programmes les plus utilisés et les plus visibles, même s'ils ne sont pas les plus simples. Le ROI visible finance la suite du projet.
3. Prévoir une phase de coexistence : ne pas promiser une décommission SAS dans les 18 mois. Prévoir une période de 3 à 5 ans de coexistence et budgéter les deux licences pendant cette période.
4. Investir dans la formation des analystes : les Data Scientists s'adaptent seuls. Les analystes SAS nécessitent un accompagnement continu, pas une formation ponctuelle de 3 jours.
5. Valider en parallèle : faire tourner les modèles SAS et Python en parallèle pendant 6 à 12 mois avant de basculer, pour identifier les divergences avant qu'elles aient un impact en production.
Conclusion : la migration vaut-elle le coup ?
Oui — dans la grande majorité des cas, une organisation qui investit dans une migration bien préparée en tire des bénéfices réels : meilleure maintenabilité du code, accès aux modèles open source modernes, recrutement facilité, coûts de licence inférieurs à terme.
Mais la question n'est pas "faut-il migrer ?" — c'est "à quel rythme et avec quel budget réaliste ?" Les organisations qui réussissent leur migration SAS → Dataiku sont celles qui acceptent dès le départ que c'est un programme pluriannuel, pas un projet de 12 mois.
Sources
Dataiku — Documentation officielle et ressources de migration SAS. doc.dataiku.com
SAS Institute — "Moving from SAS 9 to SAS Viya: A Migration Guide". support.sas.com
Gartner — Magic Quadrant for Data Science and Machine Learning Platforms, 2025.
ACPR — "Principes directeurs pour les modèles d'IA dans les institutions financières", 2024. acpr.banque-france.fr