R, l’alternative à SAS retenue par les organisations
Dans l’univers de la data, les traitements massifs de données opérés par les grandes entreprises ainsi que les institutions nécessitent parfois des outils et des langages de programmation robustes et dédiés. Historiquement, SAS est l’une des technologies et langage utilisés pour ces types de traitements.
Néanmoins, le modèle économique de l’éditeur du logiciel SAS constitue un frein et les dépenses en licence et serveurs sont parfois faramineuses. Ainsi, la course à la rentabilité ainsi que la recherche d’une optimisation des ressources poussent aujourd’hui les décideurs et utilisateurs (DSI, départements Data et/ou Marketing) à s’orienter vers une technologie moins onéreuse, mais tout aussi robuste. Le Big Data ainsi que les collectes massives de données étant devenus le fer de lance de la compétitivité des entreprises, l’alternative pertinente souvent retenue par les organisations est R.
R constitue à la fois un langage, mais permet également de travailler dans un studio de développement éponyme. Il peut être adressé et compatible avec la quasi-totalité des technologies du Big Data.
La conversion SAS vers R nécessite un travail indispensable en amont et qui peut être fastidieux. Cet impératif de cadrage et d’identification est primordial pour la bonne tenue du projet ainsi que l’exécution réussie des programmes migrés.
L’absence ou le manque de préparation pourraient avoir de lourdes conséquences tant sur le plan opérationnel que technique. Démarrer un tel projet de conversion en l’amputant de ce cadrage comporte un vrai risque de voir le projet échouer, et ce, en dépit des investissements humains et pécuniaires engagés.
Migration de SAS vers R : adapter l’architecture cible
Cet article présentera une série de recommandations ainsi que des mesures à prendre avant et pendant les développements techniques.
Avant toute chose, il est nécessaire d’avoir une bonne visibilité sur l’existant et de cartographier l’architecture de l’application et de l’ordonnancement des macro-SAS à convertir.
Cette identification stricte et exacte du périmètre et de l’ordonnancement des calculs permettra d’énumérer les données en entrée, les tables intermédiaires, les adhérences entre les macros pour enfin avoir toute la visibilité nécessaire sur les outputs finaux attendus (éléments en sortie : tables, indicateurs, graphiques).
Une cartographie de l’existant permettra également la création ainsi que la stabilisation d’un environnement R adéquat et pertinent, et évitera ainsi une perte de temps sur les modifications de structure et d’architecture de l’application cible. Dans ce cadre, il est d’ailleurs important de préciser qu’il y a des différences fondamentales, systémiques et intrinsèques entre les deux approches. L’initialisation de variables n’est pas forcément réalisée de manière strictement identique lorsque l’on est sous SAS ou R. Il est, par conséquent, fortement recommandé – nécessaire – de travailler avec des experts et précisément des collaborateurs maitrisant les architectures et en mesure d’en proposer une (architecture) optimale pour la migration de l’application, en conversion, vers R.
Par ailleurs, l’architecture cible ne doit pas être répliquée de manière identique et ISO, mais plutôt différente, adaptée et spécifique à R. Selon les cas et l’usage, il sera également possible, voire nécessaire, de supprimer ou de mutualiser certaines variables ou certaines tables. Ces variables et tables à travailler en amont peuvent engendrer des temps de développement et de réponse allant jusqu’à quelques heures ou quelques minutes si les bons packages sont utilisés :
Dans cet exemple, le temps de lecture d’un document xml (>200 Mo) passe de 9346 secondes- soit 2h36 minutes- à 678 secondes- soit à 11 minutes.
Outre la définition de l’environnement et de l’architecture réalisée durant la phase d’initialisation, il est important de prévoir et d’allouer une charge à la définition de scripts de compilation et d’ordonnancement des traitements et notamment lorsqu’une interface Shiny est prévue. En outre et pour certaines fonctions, il sera fondamental de s’assurer de la bonne qualité des données traitées (ex : prévoir des scripts pour dédoublonner les observations ; l’utilisation d’un Rbind permet d’identifier et de supprimer les doublons de manière systématique). Toutes les bonnes pratiques recommandées par la communauté R doivent être systématiquement appliquées pour tous les développements et pour chaque package utilisé. L’ajout des packages reconnus et fiables est fortement encouragé. Ex : lubridate, log4r, xml2
Enfin et en termes opérationnels, il est à garder à l’esprit que l’échantillonnage ainsi que les méthodes de calculs des moyennes diffèrent selon le langage. Ainsi, un échantillon ou un panel réalisé avec R comportera le même nombre d’observations, mais celles-ci ne seront certainement pas les mêmes. Il convient alors de prévoir des sessions communes avec les métiers afin de convenir de l’acceptabilité de certaines différences. De même, pour un échantillon diffèrent, il sera admis que les tables et les résultats en sortie seront différents. Par ailleurs, cela est également valable pour le calcul des arrondis et des décimales. Il faudra alors avoir convenu d’un cadre en amont. Ces sessions préparatoires communes permettront également de fixer des éléments tels que le cahier de tests et de recette.
Migration SAS vers R : s’assurer de la disponibilité et de l’expertise des équipes
Il est important de privilégier la disponibilité des équipes techniques et métier et un travail collaboratif en mode agile pour assurer une amélioration continue de la production de code et éviter de revenir sur des corrections trop chronophages (notamment pour les variables et calculs intermédiaires).
Aussi, un cadre agile permettra d’intégrer la stratégie de tests, qui se voudra itérative et nécessitera aussi la disponibilité des équipes et un travail collaboratif. À noter que l’environnement de test et de recette devront être identiques et ISO à celui de la production. Les répertoires vers lesquels pointent les variables et calculs devront, eux aussi, être disponibles pour apprécier au mieux les résultats en termes de temps de réponses et de bonne exécution des programmes (succès en conditions opérationnelles réalistes).
Identifier, définir et rendre disponibles les prérequis – tels que les la cartographie et/ ou l’ordonnancement de l’existant et de la cible – se fera de manière itérative dans ce cadre propice.
Une autre recommandation consiste à constituer une équipe pluridisciplinaire et de haut niveau composée d’au moins un expert SAS et son pendant R, de développeurs R, d’une chefferie/ direction de projet disponible et à l’écoute de la MOA et des besoins du métier.
Enfin, l’utilisation d’un outillage dédié, agile et mettant en avant l’intelligence collective est requise. À titre d’exemple, les développements seront, de préférence, mis à disposition dans un répertoire partagé type GIT, permettant ainsi d’assurer un versionning. En termes d’animation et de gestion, Klaxoon, Monday ou Trello porteront la dynamique du projet.
Enfin et à l’instar des tests, une documentation réalisée au fur et à mesure est aussi gage de succès et sera revue et validée de manière exhaustive et récurrente avec l’utilisateur final.
En outre, la création d’un fichier Readme.md et la mise en place de logs permettront la mise à disposition d’un cadre défini, constitué d’un premier document technique contenant, par exemple, l’architecture du programme ainsi que d’un journal d’exécution des programmes R permettant d’identifier rapidement les bugs. Pour fluidifier le travail, des fichiers Description, Namespace et .git, les procédures de compilation et de déploiement claires doivent être créés dans le dossier package R.
Conclusion
Tout projet de migration, indépendamment des technologies et/ou des langages impliqués, requiert de la rigueur dans son exécution. En outre, en vue d’un déploiement effectif et opérationnel, une méthodologie adaptée reste une valeur sûre et un gage de réussite. Ces deux éléments constituent des facteurs clés du succès du projet.
La rédaction vous conseille
> Plan de migration d’application SAS vers R ou Python : nos 4 prérequis
